Thanks for the summary Pete. We'll try to look in this direction For the configuration part I'm not sure myself yet. Marek is working on the xml config for IDM which could be useful here. Would be good to discuss this with specific use cases in mind Another question... should the code still live in separate repo? Just wondering if as part of all the repo unifications you would want to merge it back. On 02/19/2013 01:20 PM, Pete Muir wrote:

I don't think that expose REST interfaces are a high priority at the moment (doable, but not a priority). But if you're interested in Anil and Pedro started something related, with the basics on picketlink-extensions (https://github.com/picketlink/picketlink-extensions/tree/master/core/src/...). Currently I'm more concerned about the basics: HTTP basic & digest authentication + authorization on RESTful endpoints. -- "The measure of a man is what he does with power" - Plato - @abstractj - Volenti Nihil Difficile On Tuesday, February 19, 2013 at 8:13 AM, Bolesław Dawidowicz wrote:

The subsystem will be critical for AS8 Security. So we need to have a wider discussion on the subsystem design. At a bare minimum, we need a PL subsystem that exposes the IDM. On 02/19/2013 05:13 AM, Bolesław Dawidowicz wrote:

----- Original Message ----- This subsystem aims to allow PicketLink Federation users to configure their IDP and SP applications via standalone/domain xml files. It also provides a domain model that is used by the PicketLink Federation Console to manage deployments. Basically, it reads the configuration from the standalone/domain files and automatically configures the valves for IDPs and SPs. An application can have one of these roles very easyly, without any specific packaging or configuration. When working with this subsystem, I did some initial tests creating the picketlink.xml and adding it during the deployment. Maybe we can use this approach for PL 3, using the XML config that Marek is working on. There are some drawbacks when doing such thing, mainly related with the mapping between the xsd used by picketlink and the one used by the subsystem. But can be an option.

Hello Bolek, I would actually suggest getting some of the integration started for AS8 is something that may want to be looking at sooner rather than later - we have a number of items that still need to be addressed in AS and it makes more sense to be addressing them with the long term solution based on PicketLink IDM rather than some intermediate solution. We are close to looking at if we can switch from the forked HTTP server to Undertow for domain management, I am just currently working on integrating this with the existing realms used for domain management. After that starting to look at switching to PicketLink for IDM would make a lot of sense. That would then allow us to start taking the SASL libraries to the next step with better integration. One thing we need to remember however is that it is more than just a subsystem, with the migration to PicketLink IDM we need to avoid the situation where we have different security solutions in different locations. This means that we need PicketLink IDM to also be integrated for domain management. We do have some options for standalone mode regarding if we use the subsystem but within domain mode this needs to be configurable on the hosts where it will be running in a non-AS process. I will speak with Brian next week regarding some of this as this is a special case where we will want to maximise consistency of configuration between something defined in a subsystem and something defined within the core configuration. When defining the configuration for PicketLink I think we also need to remember that the way this is going to be used is really with two different target audiences. We are all already familiar with developers using our projects but this also needs to be usable by administrators who have an in-depth knowledge of their own infrastructure and environment but limited knowledge of the internals of the application server. I will start another thread for this but fairly closely related we need an overall solution for SSL configuration, in some cases SSL is used just to encrypt the traffic and in others it is used for authentication - we need a unified solution across the application server and this will also tie in with the IDM capabilities of PicketLink. Regards, Darran Lofthouse. On 02/19/2013 11:13 AM, Bolesław Dawidowicz wrote: