We will need to work on creating a AS7.x subsystem for PicketLink. This is required to jumpstart the PicketLink console project, currently led by Pedro Silva.
What we need to do:
- Work on a schema.
- Bring in the maven dependencies of AS7 code into the PL console project under a sub-project called "as-subsystem".
- Code the Subsystem.
- Generate instructions/cheatsheet to test the subsystem in AS7.x
What can go in the subsystem?
- Ability to configure a central identity provider.
- Ability to configure configuration providers.
- Ability to configure the token providers for the STS.
This basically means that the PL project will have to undergo some internal changes to cater to the subsystem needs (and transitively, the console needs).
Pedro, please add any other information to this discussion. If you want to consolidate all the information, a wiki article for the design would be suitable.
Discussion thread in the AS7 dev mailing list: http://lists.jboss.org/pipermail/jboss-as7-dev/2012-March/005471.html
As Anil said, the idea behind the PicketLink Console is to provide a GWT interface to maintain all the configurations (IDPs, SPs and STS) using the JBoss AS 7 management API to interact with the PicketLink subsystem. This project can be organized in two main parts:
- PicketLink Subsystem: An extension to the JBoss AS 7 subsystem architecture and exposure of the management aspects through the common AS7 layer;
- PicketLink Console: A GWT interface that uses the management API to interact with the PicketLink subsystem.
For the subsystem we must have in mind the following considerations:
- What do we want users to be able to do with the management API when interacting with the PicketLink subsystem ? (schema definition and operations based on PL configuration files, trust management, manage digital certificates and keystores, token registry, token revocation, etc)
- How are we going to deal with the impact of their actions on the running system ? (eg.: restart a application when a configuration change or applying it at runtime ?)
- What management services will be provided ? (eg.: metrics about issued tokens, auditing, erros, alerts, etc)
Using the subsystem architecture is possible to inject PicketLink configurations during deployment, avoiding users to have the configuration files (context.xml, pl-idfex.xml, pl-handlers.xml) inside their application. This allow us to have control of all application's life cycle (IDP and SPs) and a better management of its configurations.
For the GWT interface we must conform with the following requirements:
- It must be a extension of the AS 7 Console and have the same aspects like layout, look&feel, error handling, authentication, logging, etc;
Must only interact with the management infrastructure via a subsystem;
Everything that is manageable in one management interface (console) is manageable in all others (HTTP/JSON, CLI, Native DMR, etc etc);
- Easy to use and intuitive usability;
PicketLink provides federation features for both web applications (SAML Web Browser SSOProfile/IDP/SP) and services (WS-Trust/STS). IMO initially we can consider only the first scenario (SAML Web Browser SSO Profile) and after that work with the STS and Web Services.
What do you think ?
The PicketLink AS7 Subsystem is already under development. The code is versioned at https://github.com/picketlink/as-subsystem.
This code is an initial/proposal architecture for the subsystem supporting the following initial features:
- Deploy an IDP using only the subsystem configuration;
- Deploy an SP using only the subsystem configuration;
The actual code provides a way to deploy an IDP/SP without the valves configuration in jboss-web.xml and the files picketlink-handlers.xml and picketlink-idfed.xm inside the WAR. All the configurations are now defined using the subsystem schema. Here is how the subsystem configuration looks like:
<identity-provider alias="idp.war" url="http://localhost:8080/idp" signOutgoingMessages="false" ignoreIncomingSignatures="true">
<service-provider alias="sales.war" url="http://localhost:8080/sales" post-binding="true" />
2. About the schema
The schema above was defined using the following concepts:
- <federation alias=""> : A federation represents a set of configurations for applications (IDP and SPs) situated in the same security domain. It allows to define configurations for different environments like production, development and testing;
- <identity provider alias="" url="">: A identity-provider represents the configurations to be used by a IDP in a given security domain/federation;
- <trust>: The trust element is just a way to group configurations related with the trust relationship between the IDP and others parties;
- <trust-domain>: The trust-domain represents a domain name which the IDP can trust;
- <service-providers>: The service-providers element is just a way to group all the configurations for service providers given a security domain/federation;
- <service-provider alias="" url="">: The service-provider represents the configurations to be used by a SP in a given security domain/federation.
This schema assumes that only one IDP exists given a federation element.
Today the schema supports only a minimal configuration for both IDP and SP, as you can see. It is a proposal and is subject to change.
3. How to build, install and use
Follow the instructions in the README.md file after cloning the project from github https://github.com/picketlink/as-subsystem.
4. Using the CLI interface to access the subsystem resources
Using the CLI interface is possible to access all the resources and change their configurations:
It is important that all resources are available via CLI interface.
Use a subsystem to manage all PicketLink configurations have some benefits like:
- All the configurations are external from applications, avoiding them to worry about environment configurations during packaging or deployment;
- The configurations can be managed in different ways: HTTP/JSON, CLI, Native DMR, etc.
- Users need to learn a single and consolidated schema;
- The AS7 subsystem provides a flexible architecture to manage all the configurations and to have control over the application's life-cycle;
The actual code for the subsystem supports only a small set configuration of PicketLink. There are another things to do like:
- Support more configurations for PicketLink;
- More discussion about the schema and define it as soon as possible;
- Define the behavior when the model state change at runtime. Define when and how applications need to be restarted.