[security-dev] PicketLink IDM subsystem

Wed Apr 3 07:11:22 EDT 2013

This may not work at the moment, but should be fixed IMO. I think it should be possible to create a global IDM configuration through standalone.xml, or maybe even multiple (and some mechanism to select config for a deployment). By default the global configuration would be overridden by the application specific configuration (as in your example).

Not sure if there would be an IDM config OOTB, so a user would either have to configure one in standalone.xml or provide on in their applications.

There may also be a case for having an option to override application specific configurations, but that probably wouldn't be a very important feature to have.

----- Original Message -----
> From: "Pete Muir" <pmuir at redhat.com>
> To: "Bolesław Dawidowicz" <bdawidow at redhat.com>
> Cc: security-dev at lists.jboss.org
> Sent: Tuesday, 2 April, 2013 4:18:26 PM
> Subject: Re: [security-dev] PicketLink IDM subsystem
> 
> PicketLink IDM allows for programmatic configuration like
> https://github.com/picketlink/picketlink/blob/master/idm/tests/src/test/java/org/picketlink/test/idm/config/JPAIdentityStoreConfigurationTestCase.java#L94
> - can we still use something like this with the subsystem?
> 
> On 28 Mar 2013, at 20:10, Bolesław Dawidowicz <bdawidow at redhat.com> wrote:
> 
> > I'm not sure I fully follow. Could you give some example?
> > 
> > On 03/28/2013 03:31 PM, Pete Muir wrote:
> >> With Stian's approach, is it possible to hook into the bootstrap of the
> >> container managed IDM, and provide custom programmatic config?
> >> 
> >> As that would be enough for a Beta imo.
> >> 
> >> On 28 Mar 2013, at 14:28, Bolesław Dawidowicz <bdawidow at redhat.com> wrote:
> >> 
> >>> I think xml can wait a bit. Initial version can just boostrap default
> >>> stuff - JPA store. Then we add more proper config.
> >>> 
> >>> Just initialization of JPA store and exposing it to applications is
> >>> enough to kickstart the subsystem IMO - and this is what Stian
> >>> developed. At least that is pretty much what we need for now to move on.
> >>> 
> >>> I propose that we really start small but with common codebase under
> >>> picketlink umbrella and then discuss more detailed design and add more
> >>> features. And just release often.
> >>> 
> >>> On 03/28/2013 03:20 PM, Anil Saldhana wrote:
> >>>> We need to start the design discussions on the IDM subsystem right away.
> >>>> 
> >>>> We need to at least decide the schema and how the xml elements look.
> >>>> 
> >>>> On 03/28/2013 09:18 AM, Bolesław Dawidowicz wrote:
> >>>>> What Stian is proposing (and it was main reason to send this email) is
> >>>>> that we extract our work and put it in picketlink as a base for new
> >>>>> subsystem. Obviously if it matches expectations and goes in same
> >>>>> direction that you expect.
> >>>>> 
> >>>>> We don't want to duplicate work. The soon we align the better - and we
> >>>>> have a bit of time to help right now.
> >>>>> 
> >>>>> On 03/28/2013 03:05 PM, Anil Saldhana wrote:
> >>>>>> Hi Stain,
> >>>>>>      we will have the subsystem as one of the projects in the PL
> >>>>>>      github.
> >>>>>> That work has to start soon.  So it makes sense  to migrate some of
> >>>>>> the
> >>>>>> work you have done. Since Pedro did the PL2 subsystem, he will be
> >>>>>> coordinating the work on the PL3 subsystem.
> >>>>>> 
> >>>>>> Regards,
> >>>>>> Anil
> >>>>>> 
> >>>>>> On 03/28/2013 08:23 AM, Stian Thorgersen wrote:
> >>>>>>> As part of our project we need a basic JBoss AS subsystem for
> >>>>>>> PicketLink IDM. We hope to either contribute this to PicketLink, or
> >>>>>>> to be able to replace it with an official subsystem once it's
> >>>>>>> available. If there is any interest in what we've done so far, we
> >>>>>>> would welcome feedback and/or help to complete it.
> >>>>>>> 
> >>>>>>> I thought this would be a good time to send this mail as we have
> >>>>>>> something very basic working. It's available on github
> >>>>>>> (https://github.com/stianst/eventjuggler-services/tree/idm). It's
> >>>>>>> the Identity subsystem (identity/impl) that provides the PL IDM
> >>>>>>> subsystem equivalent.
> >>>>>>> 
> >>>>>>> To enable the Identity subsystem a deployment adds a dependency on
> >>>>>>> "org.eventjuggler.services.identity", this causes the deployment
> >>>>>>> processors in the Identity subsystem to:
> >>>>>>> 
> >>>>>>> * Add a dependency on our PL 3 module
> >>>>>>> * Install CDI extensions that provides the beans from PL jars + a
> >>>>>>> producer for EntityManager that uses an EntityManagerFactory created
> >>>>>>> by the Identity service
> >>>>>>> 
> >>>>>>> This in return means that the deployment doesn't have to include PL
> >>>>>>> jars or any PL configuration for the identity store.
> >>>>>>> 
> >>>>>>> We have an example application that uses this service. It uses only
> >>>>>>> PL 3 api's for authentication/authorization. That's also available
> >>>>>>> on github (https://github.com/stianst/eventjuggler/tree/idm/).
> >>>>>>> 
> >>>>>>> To try it out, first download JBoss EAP 6.1.0.Alpha, then run the
> >>>>>>> following:
> >>>>>>> 
> >>>>>>>        git clone https://github.com/stianst/eventjuggler-services.git
> >>>>>>>        cd eventjuggler-services
> >>>>>>>        git checkout origin/idm -b idm
> >>>>>>>        mvn -Djboss.zip=<location of jboss-eap-6.1.0.Alpha.zip>
> >>>>>>>        install
> >>>>>>>        build/target/jboss-eap-6.1/bin/standalone.sh
> >>>>>>> 
> >>>>>>> If you also want to try the example application run the following:
> >>>>>>> 
> >>>>>>>        git clone https://github.com/stianst/eventjuggler.git
> >>>>>>>        cd eventjuggler
> >>>>>>>        git checkout origin/idm -b idm
> >>>>>>>        mvn clean install
> >>>>>>>        mvn -pl ear jboss-as:deploy
> >>>>>>> 
> >>>>>>> Now you should be able to open
> >>>>>>> http://localhost:8080/eventjuggler-client and select register and
> >>>>>>> login to check that authentication works.
> >>>>>>> 
> >>>>>>> We haven't put to much effort into exactly what we're doing as we
> >>>>>>> wanted some feedback first. A few things that we've been thinking
> >>>>>>> about includes:
> >>>>>>> 
> >>>>>>> * Split idm and core into separate subsystems + modules
> >>>>>>> * Allow configuring the identity store (jpa, ldap or file) through
> >>>>>>> JBoss AS management
> >>>>>>> * Support multiple identity store configurations and a mechanism to
> >>>>>>> select which to use for a specific deployment
> >>>>>>> 
> >>>> _______________________________________________
> >>>> 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
> >> 
> > 
> 
> 
> _______________________________________________
> security-dev mailing list
> security-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/security-dev