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 ?)

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.

1. Background

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:

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.