[security-dev] PicketLink IDM subsystem

Pedro Igor Silva psilva at redhat.com
Thu Mar 28 11:04:44 EDT 2013 

I agree. Just think that one of the requirements can be to allow parsing an existing pl configuration from the deployment. But I know we can start without that right now.

I took a quick look at Stain's work (going to pull his code and run locally later) and it looks fine. Maybe we should also consider what was done with PL 2 given that it provides:

    - Automatically PL dependency configuration (as Stain's)
    - Code for parsing the XML schema from the standalone/domain.xml. I think we can reuse a lot of code and add the PL-IDM schema very easily.
    - Specific configuration for a given deployment, based on the config defined inside the standalone/domain.xml.
    - Others features specific for the federation deployments, such as statistics and support for most of the federation configuration.
    - Unit and Integration tests.

Today, the PL 2 subsystem is specific for the Federation stuff. But I think we can refactor a bit to accommodate the new requirements (and other pl projects). I think we can merge Stain's work with the PL 2 subsystem very easily.

The XML schema for the PL 2 subsystem is :

     https://github.com/picketlink2/as-subsystem/blob/master/src/test/resources/picketlink-subsystem.xml

We can review the schema above to something like:

<subsystem>
     <federations>
          <!-- PL Federation configuration -->
     </federations>

     <identity-management>
          <!-- PL IDM configuration -->
     </identity-management>
</subsystem>

What do you think ?

Regards.
Pedro Igor

----- Original Message -----
From: "Bolesław Dawidowicz" <bdawidow at redhat.com>
To: security-dev at lists.jboss.org
Sent: Thursday, March 28, 2013 11:28:09 AM
Subject: Re: [security-dev] PicketLink IDM subsystem

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

More information about the security-dev mailing list