Re: [security-dev] PicketLink IDM subsystem

It all sounds good to me. I cannot comment much around Federation part but if it all can fit together it is even better. Let us know how you prefer to proceed on this and we can sync next week and help you. If we could merge stuff together and release some initial version quickly then we would ditch our own prototype and use picketlin idm subsystem instead in our demo application (evenjuggler). On 03/28/2013 04:04 PM, Pedro Igor Silva wrote: > 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/resource... > > 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(a)redhat.com&gt; To: security-dev(a)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 >>>>> >>>>>