[security-dev] PicketLink AS Subsystem

[Pete Muir]

On 20 Feb 2013, at 08:23, Bolesław Dawidowicz <bdawidow at redhat.com> wrote:

> 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

Yep, definitely. This could be our picketlink.xml. We should make sure it's consistent with the style of standalone.xml, then it should be easy to use a similar/same schema there.

> 
> Another question... should the code still live in separate repo?

I think so. One day, we'll probably want this in the app server?

> 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:
>> 
>> On 19 Feb 2013, at 11:13, Bolesław Dawidowicz <bdawidow at redhat.com> wrote:
>> 
>>> 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
>>> 
>>> From what I learned from Anil while it is on the roadmap PicketLink 3.x
>>> subsystem won't happens soon.
>> 
>> The focus has been on making something thats easily consumable however it's packaged initially, but with the idea it should be available as AS7 service at some point.
>> 
>>> I would like to discus requirements for it
>>> as we may be able to contribute something - at least some initial work.
>> 
>> Awesome :-)
>> 
>>> 
>>> 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?
>> 
>> Via the Java API should be the top priority IMO. A REST interface would be awesome, but probably lower priority.
>> 
>> For a Java API, my proposal would be to expose the various managers (IdentityManager, PermissionManager) via JNDI. We can also provide a default CDI producer that can allow them to be injected using CDI for application.
>> 
>> We also need to think about how this alters configuring PicketLink. To date, this is via a programmatic API. Do we want to offer this via the service (Ideally yes, but not sure how, maybe some callback when the app starts?)? We definitely want to be able to configure from standalone/domain.xml, what does this look like? Should there be a PicketLink xml (if we can do it via the programmatic API still, then I think not).
>> 
>>> 
>>> 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.
>> 
>> AFAIK, the above is as far as Shane and I have got :-)
>> 
>>> 
>>> Bolek
>>> _______________________________________________
>>> security-dev mailing list
>>> security-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/security-dev
>> 
>