[security-dev] PicketLink AS Subsystem

[Pete Muir]

It's definitely a requirement to be able to configure the subsystem from within the deployment. Ideally via a programmatic API and XML.

Understood re mapping the xsd. Not sure what we can do about that.

On 20 Feb 2013, at 17:30, Pedro Igor Silva <psilva at redhat.com> wrote:

> ----- Original Message -----
>> From: "Bolesław Dawidowicz" <bdawidow at redhat.com>
>> To: security-dev at lists.jboss.org
>> Cc: "Stian Thorgersen" <stian at redhat.com>
>> Sent: Tuesday, February 19, 2013 8:13:46 AM
>> Subject: [security-dev] PicketLink AS Subsystem
>> 
>> Hi
>> 
>> We are doing some prototyping with PicketBox and PicketLink 3. As
>> part
>> of this it makes sense for use to put it in separate subystem in AS7.
>> 
>> There is existing PicketLink 2.x one here:
>> 
>> https://github.com/picketlink/as-subsystem
> 
> 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.
> 
>> 
>> From what I learned from Anil while it is on the roadmap PicketLink
>> 3.x
>> subsystem won't happens soon. I would like to discus requirements for
>> it
>> as we may be able to contribute something - at least some initial
>> work.
>> 
>> I would also like to discuss how independent PicketLink service
>> should
>> be exposed and consumed in applications. Most natural way would be to
>> provide both CDI integration and REST interface. Any thoughts on
>> that?
>> 
>> As part of our prototyping we would like to avoid investing time into
>> something that would duplicate existing functionality or go against
>> already agreed design.
>> 
>> Bolek
>> _______________________________________________
>> security-dev mailing list
>> security-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/security-dev
>> 
> 
> _______________________________________________
> security-dev mailing list
> security-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/security-dev