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 ?

1. Background

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:

     <subsystem xmlns="urn:jboss:picketlink:1.0">

            <federation alias="my-fed">

                <identity-provider alias="idp.war" url="http://localhost:8080/idp" signOutgoingMessages="false" ignoreIncomingSignatures="true">

                    <trust>

                        <trust-domain name="localhost"/>

                        <trust-domain name="mycompany.com"/>

                    </trust>

                </identity-provider>

                <service-providers>

                    <service-providers>

                        <service-provider alias="sales.war" url="http://localhost:8080/sales" post-binding="true" />

                    </service-providers>

                </service-providers>

            </federation>

     </subsystem>

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:

/subsystem=picketlink/federation=my-fed/identity-provider=idp.war/trust-domain=localhost

/subsystem=picketlink/federation=my-fed/identity-provider=idp.war/trust-domain=mycompany.com:add(name=mycompanycom)

/subsystem=picketlink/federation=my-fed/service-provider=sales.war

It is important that all resources are available via CLI interface.

5. Benefits

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;

6. TODO

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.