Authentication Package Refactoring

Goals

• Flexible configuration and configuration independent of buisness classes, support for "Dependency Injection" and possible usage of spring or other dependency injection containers for configuring the login modules.
• Back to the "roots" in the way that the current hiding of JAAS shall be stopped and JAAS will become visible to the user
• Erase the dependency of login modules and credentials to "an authentication method".
• Using of Callbackhandlers for retrieving credentials (beside or replaceing the using of public credentials)
• Provide a lot of credentials and also callbacks for - SAML1.1 Assertions, SAML 2.2 Assertions, SAML Responses, UserName, Password etc.
• Provide the flexiblity of JAAS in the sence that more then one login module can be active at the same time and also work together to provide a login chain.
• The JAAS Parameters "Sufficient, Optional, Required ..." shall be supported.
• Providing of login modules for 52n-Services (e.g a WAS Login Module, a Authn-Login Module) instead (or besides) of writing service clients.

Tasks

1. Provide the configuration facilities
   • create a Pojo - Configuration class
   • create one or more XMLConfigurationReaders which build a Configuration class out of the xml file
     1. one for the old as-configuration schema
     2. one for a new more fexible schema
2. Provide a flexible login mechanim for widely usage
   • analyze the current credential classes and refactor these or create new ones
   • create a flexible CallbackHandler for more log-in abstraction. We need callback classes which are associated with the credentials, e.g. a callback which asks for a SAML 1.1 credential.
   • refactor the login modules to use callbacks instead of credentials.
     1. Give a possiblity to let a login module ask for external resources (e.g. DB Connections), this is possible by using Callbacks, or alternatively by using the configuraion options, provided by an (JAAS) AppConfigurationEntry.
     2. Check for "seemless" authentication e.g. if one login module asks for a password the second one shall reuse it, if the first is a non sufficient module. For this rules can be found in the JAAS documentation.
   • check the current principal classes, i think the key/value approach is not the best for stable application code, because the keys can differ from application to application, therewith common attributes like 'email', 'username', 'identity provider' ... shall become concrete principal classes.
3. Provide a login module for the 52n-WAS.