[security-dev] PicketLink IDM subsystem

Pete Muir pmuir at redhat.com
Wed Apr 3 07:41:50 EDT 2013

Agreed, this is how I saw it as well.

On 3 Apr 2013, at 12:11, Stian Thorgersen <stian at redhat.com> wrote:

> 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

More information about the security-dev mailing list