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.