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