Proposed Changes for PL 2.1.0
I would like to start a discussion and to document some of the proposed changes for PL 2.1.0.
Some of the changes described here were previously discussed in internal chats by Anil, Stefan and me. The objective is to do a brainstorm and gather ideas to make PL yet more easier for users and developers. These items are not in order of priorization.
- Allow users to configure a page when some error occurs.
When some error occur like AuthnFailed, IssuerNotTrused, signature validation, etc, PL displays a blank page. See https://community.jboss.org/thread/197488.
- Remove the attribute IDPWebBrowserSSOValve.assertionValidity. This attribute seems to be unnecessary because the IDP uses the configurations in core-sts.xml. For specific SAML configurations, prefer the core-sts/picketlink-sts configuration file.
- When using signatures, the attribute IDPWebBrowserSSOValve.validatingAliasToTokenIssuer must be used to tell PL to use the issuer during the signature validation process. If this attribute is not used PL tries to validate the signature using the request.getRemoteAddr.
Using request.getRemoteAddr to validate signatures forces the pl-idfed.xml to have a ValidationAlias for each client, what is almost impossible. Maybe we can make the validatingAliasToTokenIssuer as the default behavior and the request.getRemoteAddr as fallback.
- The SPRedirect/Post Valves have a property called idpAddress. Considering that when using signatures the SPs will always receive a SAML Assertion issued by the IDP, this attribute seems to be unnecessary since we can have its value from the IdentityURL configured in pl-idfed.xml.
- Consolidate the configurations in a single file. For specific SAML configurations, prefer the core-sts/picketlink-sts configuration file.
Today PL uses context.xml/jboss-web.xml, picketlink-handlers.xml and picketlink-idfed.xml. Maybe we can consolidate all this configurations in a single file.
- We can use the concept of COC (Circle of Trust) while configuring the differents providers(STS, SP,IDP) grouping them in a Federation. Each federation has its own digital certificates configuration(keystores), saml specific configurations and so forth. These configurations are common and shared by all different providers. We can also provide ways to create a new federation extending the configurations from another.
- Today the configuration files reside inside the WAR and it is quite common to have different environments like dev, prod, stage, etc. Those configurations usually change from one environment to another and package promotion or "build once and run everywhere" (dev -> stage -> production, for example) is an practice/approach used by many companies. Maybe we can allow users to specify different locations for the configurations instead of enforcing them to put those inside the WAR. Althought PL provides ways to do that (custom ConfigurationProviders), we can offer a default implementation.
- Why we need the RoleGenerator if we can load roles from the LoginModule ? By the way, today PL ignores the RoleGenerator if any role was loaded before. See RolesGenerationHandler.handleRequestType. If this component is necessary we can at least merge the roles loaded before with the ones generated by this component.
- Security Token Service Clustering. We can use Infinispan to achieve this.
- Enable metrics and statistics for the count of tokens issued, canceled, expired, renewed, average expiration timeout, authentication processing time, successfull/failed authentication count ...
- Optional definition for the SAML2 Handlers.
To make easier the configuration, we can also provide a default handler chain and let users reconfigure it only if necessary, eliminating the need to have always the pl-handlers.xml inside the WARs.
- Optional definition for the Valves.
The valves used are usually the default ones (IDPWebBrowserSSOValve, SPRedirect/Post, etc). We can have simple configurations like : <saml-binding>POST|REDIRECT</saml-binding> instead of requiring the valves definition in context.xml/jboss-web.xml. If users want to change the default ones we should provide ways to do that in the configuration file.
- The attribute IDPWebBrowserSSOValve.ignoreIncomingSignatures and IDPWebBrowserSSOValve.signOutgoingMessagesseems seems to be unnecessary.
When using signature support, if the keyprovider is defined is because the user wants to sign incoming and outgoing messages. It is possible to have a IDP that supports signature but do not validate the incoming messages or sign outgoing messages ?
- PicketLink Auditing Support. See https://community.jboss.org/thread/197893.
- Maybe we can use Arquillian/Selenium to build testcases to test the integration between the entity providers.
- Update documentation.
