Roadmap Secuirty API 2.1

2.1-M1

2.1-M2

2.1-M3

ToDo

• [Short name] Description

• [Common API] general utility and abstraction classes for common tasks
  1. xml handling
     1. Create xml-schema modul, e.g. for saml, xacml, wss, was, licman, (interfaces, configuration etc..). Schemata shall be placed in a META-INF/xml/schema directory, the structure of this directory shall be a relative tree, wherein the path to a schema is constructed like this organisation/commonname/version/schemaname.xml e.g. META-INF/xml/schema/oasis/saml/1.1/saml-schema-assertion-2.0.xsd
     2. Create entity-mapping.xml, which maps all namespaces to the matching local schema files, this is required to let the ClasspathEntityResolver access the local schemata.
     3. Create xmlbeans modules for at most all required service interfaces, the modules shall not copy the schema files, instead they shall use the xml-schema module.
     4. Create a common/xml package for abstracting typical xml task (this is started but must be reviewed). The package shall abstract DOM based parsing, XMLValidation, XMLSerialization, XPath usage, it shall be performance optimized (e.g. Pooling and Caching), and very good documented, because it will be one of most used packages.
  2. UUID Generation Wrap the jug jar within an own utility package like (common/uuid), with a main interface UUIDGenerator which shall be used in other packages, and not the UUIDGenerator of jug (so we can simple replace it by other implementation classes).
  3. Crypto Handling, we need a common/crypto package which solves at least the following problems
     1. Public/Private Key obtaining and managing. We have to design interfaces and classes to abstract the resolving of cryptographic keys. Classes which need cryptographic keys shall not have knowledge about how to get these keys, they shall utilize something like a KeyPairResolver or CertificateResolver to retrieve the required informations.
     2. Certificate management, the problem is like the one above, but considers also problems of certificate revocation lists and updates of certificates. We have to explore standard mechanisms of certificate management and to design an api to solve the problem of the management of big security infrastructures (e.g. use ldap or the JNDI to find certificates and keys).
     3. Classes to utilize common signing, encryption and verification tasks, which wraps the correct usage of the wss4j and xmlsec apis.

• [Authentication API] link AuthN to new "real JAAS" authentication component (more flexible and more extensible)
  1. exchange API
     1. Create specialized principals and refactor the old one (e.g. SAML Principal ?), this also relates to attribute handling, how to manage the different key identifiers?
     2. Refactor loginmodules to use CallbackHandler instead of Subject.getCredentials() method to obtain credentials, because this is more flexible
     3. Explore principal scoping, which means to explore what is the best to ensure uniqueness of principals of same type but issued by different federation entities.
     4. Try to remove the "login method" semantics and coupling of loginmodules with such a method, because a "login method" is same like accepted types of credentials, and a login module shall be able to handle more as one kind of credential. Special thought: credentials and login modules are application scope, only the principals are shared within authorization (52n library scope) not the credentials, so a third party application shall be able to simple add his own credential types or login modules, as long as supported principals are created all shall be work without problems.
     5. It shall be possible to chain login modules, how it is thought by the JAAS api. This leads to very simple integration of different authentication sources (e.g. WAS/Authn authentication chaining)
  2. refactor config file
     1. I think -> remove the coupling of configuration with running beans! (Pattern : seperate configuration from code) At best my opinion is to replace our (unflexible) configuration files with spring or an other dependency injection framework, which by self leads to seperation of configuration and at best to better code...
  3. Implement login modules for WAS and AuthN, which shall be the default way of 52n-Authentication integration in third party applications, we need to write a good and simple user guide for this.

• [Decision API] refactor to stable flexible api.
  1. Review the api classes for flexibility and integration, currently its structure is a xacml based design, and the question is what happens if someone tries to use an other decision protocol. Which requirements are really needed? Is there a common base structure between different decision protocols?
  2. Refactor the Target class, create an interface, because it is highly coupled with the underlying implementation. Refactor the action and resource properties to use the common/attributes package, because the current simple string is not scalable (extensible).
  3. Review the nameing of PDPResponse and PDPRequest and the PDPProxy. I think a better name for the PDPProxy class is DecisionService, because we can also implement a in memory service, it shall be an interface, not a abstract class. I also like DecisionQuery for PDPRequest and Decision or DecisionResponse for PDPResponse.
  4. Review the common/attribute package for usability and extensiblity, e.g. using a factory, with spi-pattern for registering other attribute types, it also makes sense to create conversion factories or utility classes to convert AttributeValues to saml or xacml attribute values.
  5. Refactor the XACMLPDPProxy and also the PDPService implementation, for better source code integration (code style and performance)

• [Authorization API] refactor to stable flexible and high integrateable api.
  1. Review whole interceptor and transferable design, current design is a big performance and extensibility hole. -> life cycle of interceptors must be reviewed, there is a requirement to have different context attribute scopes (request, application) to share and manage/cache service informations.
  2. Extend the interceptor design to a plugable ObligationHandler chain. Seen problems are lifecycle of obligation handlers, execution order, preventing reexecution.
  3. Interceptor chain shall only handle authorization not authentication, we have to explicite separate this tasks for better integration purpose. The request and response chaining shall also be separated and externally called, so that an integration in axis (1 and 2) handlers or modules are simpler possible.
  4. For flexibility it makes sense to have something like a Authorization event and AuthroizationEventListeners, which can be registered by a authorization chain and are called if the authorization state changes. Possible States can be Request Started, Interceptor Start, Request Denied, Request Permited, Interceptor End, Request End, Response Start ... etc.? This makes it possible to simple create tasks related to such events, e.g. special logging or interceptor extensions. (Thought: with this we can also implement obligation handling -> Event like Obligation Requested ?)

• [Services - All]
  1. Review module structure and api usage -> e.g. usage of LoginModules, configuration files etc.
  2. Use Spring or other dependency injection framework as configuration base
  3. Create specialized exception hierarchy for each service (exception shall be not shared, so that each service can evolve separatly).
  4. Create common design pattern (interfaces, base classes) for tiered service infrastructure (e.g. ServiceOperation(Command)->ServiceInterfaces->PersistentInterfaces) to ensure common architecture of the different services. Currently these are extremly different designed, which leads to repeated errors in xml handling, charset encoding and the design by self, which leads to code understanding problems and confuse code blocks. (I think one of best bad practice samples is the facade web application :-()

Roadmap

Archive