Note: I'm not asking you [Pete] to have all of these answers. I just wanted to bring them up for discussion, and clarification. How will PicketLink IDM interact with or integrate with DeltaSpike security api/spi?

Will users of DeltaSpike security somehow configure PicketLink-IDM to manage the applications users? Or would it literally be separate i.e. an app uses DS APIs, and separately sets up IDM with PL?

Would there be a UI for this, even if it's just a default/basic one? If so where would it exist? Would the PicketLink IDM provide it as an example?

-Jay On Jul 27, 2012, at 10:20 AM, Pete Muir wrote: > > Begin forwarded message: > >> From: Pete Muir <pmuir(a)redhat.com&gt; >> Subject: DeltaSpike, IDM, Authentication and Authorization >> Date: 27 July 2012 15:17:42 GMT+01:00 >> To: security-dev(a)lists.jboss.org >> >> Until recently, it looked like Apache DeltaSpike would define an IDM API, but now it looks like most people are in agreement that DeltaSpike should not cover IDM. >> >> http://apache-deltaspike-incubator-discussions.2316169.n4.nabble.com/IDM-... >> >> It would still provide an API and SPI for authentication and authorization, as defined in http://incubator.apache.org/deltaspike/security.html >> >> >> Does it matter that DeltaSpike won't do IDM? >> ------------------------------------------------------------ >> >> The big reason for us to do things in DeltaSpike, is to give our users a portable way to write applications. As DeltaSpike is a collaborative project between individuals and companies, there is lots of effort put into ensuring portability, and provides a good vendor neutral location to do that. If we consider where portability matters: >> >> * in application code, typically measured by the number of classes, views etc. in a typical application that must be changed to move between frameworks/libraries/runtimes >> * in configuration, typically measured by number of files that must be altered to move between frameworks/libraries/runtimes >> >> Typically the number of classes is much greater than the number of configuration files. >> >> We can use this to "measure" how much portability matters for a given topic, by looking at the number of files that must be changed to move between frameworks/libraries/runtimes. >> >> Taking our security topics: >> >> * Authentication: typically impacts a low number of classes and views. Some configuration required. Portability doesn't matter too much >> * Authorization: typically impacts most classes and views. Portability is critical. >> * Identity Management: typically impacts very a very few classes, and some configuration. Perhaps the only real impact on code is accessing user information for display (e.g. the classic "Welcome Pete"). This can easily be encapsulated by a single application class, and is perhaps a pattern we should recommend >> >> Therefore, we can see that whilst portability in IDM would be nice, it's not critical. >> >> >> Do we (JBoss) need IDM? Is there a demand for IDM in the community? >> ------------------------------------------------------------------------------------------------- >> >> I believe the short answer, and one we are all agreed on, is yes and yes :-) >> >> >> How do we move forward? >> ------------------------------------ >> >> The proposal is that we rehouse the IDM work done by Shane so far in PicketLink IDM [1]. This would consist of: >> >> * An IDM API >> * An IDM SPI (to allow IDM providers to be written) >> * An IDM impl (which loads the relevant provider and delegates calls to it) >> * A set of providers for the SPI such as JPA, LDAP etc. >> >> Both of these would be plain Java SE implementations, with minimal dependencies to allow maximum reuse by other JBoss projects. >> >> Furthermore, we would provide PicketLink CDI, which would provide an implementation of the authorization and authentication provider SPIs in DeltaSpike, that use the IDM backend. The module would also contain authorization providers for the various authorization frameworks PicketLink supports, as well provide authentication API implementations as needed. >> >> When will this be ready? >> -------------------------------- >> >> I'll let Shane chime in here, but I hope we can get something out fast, as we have a lot of code today. >> >> Thoughts? >> >> Pete

On Jul 27, 2012, at 11:56 AM, Anil Saldhana wrote: > On 07/27/2012 10:53 AM, Jay Balunas wrote: >> Note: I'm not asking you [Pete] to have all of these answers. I just wanted to bring them up for discussion, and clarification. >> >> How will PicketLink IDM interact with or integrate with DeltaSpike security api/spi? > As Pete said, we are going to inject PL IDM entry point into DS > security code. Then DS will be able to make the interactions. ok, so from an application developer point of view they are still just using the DS security API (for the most part).

The IDM integration would be "swappable" then, or could be added in later in app dev cycle.

>> >> Will users of DeltaSpike security somehow configure PicketLink-IDM to manage the applications users? Or would it literally be separate i.e. an app uses DS APIs, and separately sets up IDM with PL? > IMO IDM configuration/setup is outside of DS interaction. In my view, it > is done by administrators using any of the consoles with the identity > store - database brower, ldap browser, ldif loads, db import etc

This would still be Application based, or are we jumping to container IDM? I could see the need/want for both.

> >> >> Would there be a UI for this, even if it's just a default/basic one? If so where would it exist? Would the PicketLink IDM provide it as an example? > If there is a console, we will probably have it as part of PL. The > projects such as GateIn can have their own consoles interacting with the > IDM SPI/API. Makes sense to me. > >> >> -Jay >> >> >> On Jul 27, 2012, at 10:20 AM, Pete Muir wrote: >> >>> >>> Begin forwarded message: >>> >>>> From: Pete Muir <pmuir(a)redhat.com&gt; >>>> Subject: DeltaSpike, IDM, Authentication and Authorization >>>> Date: 27 July 2012 15:17:42 GMT+01:00 >>>> To: security-dev(a)lists.jboss.org >>>> >>>> Until recently, it looked like Apache DeltaSpike would define an IDM API, but now it looks like most people are in agreement that DeltaSpike should not cover IDM. >>>> >>>> http://apache-deltaspike-incubator-discussions.2316169.n4.nabble.com/IDM-... >>>> >>>> It would still provide an API and SPI for authentication and authorization, as defined in http://incubator.apache.org/deltaspike/security.html >>>> >>>> >>>> Does it matter that DeltaSpike won't do IDM? >>>> ------------------------------------------------------------ >>>> >>>> The big reason for us to do things in DeltaSpike, is to give our users a portable way to write applications. As DeltaSpike is a collaborative project between individuals and companies, there is lots of effort put into ensuring portability, and provides a good vendor neutral location to do that. If we consider where portability matters: >>>> >>>> * in application code, typically measured by the number of classes, views etc. in a typical application that must be changed to move between frameworks/libraries/runtimes >>>> * in configuration, typically measured by number of files that must be altered to move between frameworks/libraries/runtimes >>>> >>>> Typically the number of classes is much greater than the number of configuration files. >>>> >>>> We can use this to "measure" how much portability matters for a given topic, by looking at the number of files that must be changed to move between frameworks/libraries/runtimes. >>>> >>>> Taking our security topics: >>>> >>>> * Authentication: typically impacts a low number of classes and views. Some configuration required. Portability doesn't matter too much >>>> * Authorization: typically impacts most classes and views. Portability is critical. >>>> * Identity Management: typically impacts very a very few classes, and some configuration. Perhaps the only real impact on code is accessing user information for display (e.g. the classic "Welcome Pete"). This can easily be encapsulated by a single application class, and is perhaps a pattern we should recommend >>>> >>>> Therefore, we can see that whilst portability in IDM would be nice, it's not critical. >>>> >>>> >>>> Do we (JBoss) need IDM? Is there a demand for IDM in the community? >>>> ------------------------------------------------------------------------------------------------- >>>> >>>> I believe the short answer, and one we are all agreed on, is yes and yes :-) >>>> >>>> >>>> How do we move forward? >>>> ------------------------------------ >>>> >>>> The proposal is that we rehouse the IDM work done by Shane so far in PicketLink IDM [1]. This would consist of: >>>> >>>> * An IDM API >>>> * An IDM SPI (to allow IDM providers to be written) >>>> * An IDM impl (which loads the relevant provider and delegates calls to it) >>>> * A set of providers for the SPI such as JPA, LDAP etc. >>>> >>>> Both of these would be plain Java SE implementations, with minimal dependencies to allow maximum reuse by other JBoss projects. >>>> >>>> Furthermore, we would provide PicketLink CDI, which would provide an implementation of the authorization and authentication provider SPIs in DeltaSpike, that use the IDM backend. The module would also contain authorization providers for the various authorization frameworks PicketLink supports, as well provide authentication API implementations as needed. >>>> >>>> When will this be ready? >>>> -------------------------------- >>>> >>>> I'll let Shane chime in here, but I hope we can get something out fast, as we have a lot of code today. >>>> >>>> Thoughts? >>>> >>>> Pete > _______________________________________________ > security-dev mailing list > security-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/security-dev _______________________________________________ security-dev mailing list security-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/security-dev

On Jul 27, 2012, at 5:56 PM, Anil Saldhana <Anil.Saldhana(a)redhat.com&gt; wrote: > On 07/27/2012 10:53 AM, Jay Balunas wrote: >> Note: I'm not asking you [Pete] to have all of these answers. I just wanted to bring them up for discussion, and clarification. >> >> How will PicketLink IDM interact with or integrate with DeltaSpike security api/spi? > As Pete said, we are going to inject PL IDM entry point into DS > security code. Then DS will be able to make the interactions. >> >> Will users of DeltaSpike security somehow configure PicketLink-IDM to manage the applications users? Or would it literally be separate i.e. an app uses DS APIs, and separately sets up IDM with PL? > IMO IDM configuration/setup is outside of DS interaction. In my view, it > is done by administrators using any of the consoles with the identity > store - database brower, ldap browser, ldif loads, db import etc. I imagine it will be a role of PicketLink CDI project to provide this integration. I think DeltaSpike will end up having simpler generic API for authentication and authorisation and it will be possible to plug PicketLink IDM to handle all the calls. Then for identity model and IDM operations (user, group, role handling) it will be API defined in PicketLink IDM project to be used.

> >> >> Would there be a UI for this, even if it's just a default/basic one? If so where would it exist? Would the PicketLink IDM provide it as an example? > If there is a console, we will probably have it as part of PL. The > projects such as GateIn can have their own consoles interacting with the > IDM SPI/API. I think we must have it and it should be a requirement to provide basic example one covering API usage. For the pure IDM aspect there is work done by Viliam in JQuery that should be very easy to adapt: https://github.com/vrockai/picketlink-idm-webapp IIRC he was willing to move this repo into picketlink space. I will try to check next week with him and ask him to donate the repo. For authorisation part Shane already started to work on example web application as part of his DeltaSpike work. > >> >> -Jay >> >> >> On Jul 27, 2012, at 10:20 AM, Pete Muir wrote: >> >>> >>> Begin forwarded message: >>> >>>> From: Pete Muir <pmuir(a)redhat.com&gt; >>>> Subject: DeltaSpike, IDM, Authentication and Authorization >>>> Date: 27 July 2012 15:17:42 GMT+01:00 >>>> To: security-dev(a)lists.jboss.org >>>> >>>> Until recently, it looked like Apache DeltaSpike would define an IDM API, but now it looks like most people are in agreement that DeltaSpike should not cover IDM. >>>> >>>> http://apache-deltaspike-incubator-discussions.2316169.n4.nabble.com/IDM-... >>>> >>>> It would still provide an API and SPI for authentication and authorization, as defined in http://incubator.apache.org/deltaspike/security.html >>>> >>>> >>>> Does it matter that DeltaSpike won't do IDM? >>>> ------------------------------------------------------------ >>>> >>>> The big reason for us to do things in DeltaSpike, is to give our users a portable way to write applications. As DeltaSpike is a collaborative project between individuals and companies, there is lots of effort put into ensuring portability, and provides a good vendor neutral location to do that. If we consider where portability matters: >>>> >>>> * in application code, typically measured by the number of classes, views etc. in a typical application that must be changed to move between frameworks/libraries/runtimes >>>> * in configuration, typically measured by number of files that must be altered to move between frameworks/libraries/runtimes >>>> >>>> Typically the number of classes is much greater than the number of configuration files. >>>> >>>> We can use this to "measure" how much portability matters for a given topic, by looking at the number of files that must be changed to move between frameworks/libraries/runtimes. >>>> >>>> Taking our security topics: >>>> >>>> * Authentication: typically impacts a low number of classes and views. Some configuration required. Portability doesn't matter too much >>>> * Authorization: typically impacts most classes and views. Portability is critical. >>>> * Identity Management: typically impacts very a very few classes, and some configuration. Perhaps the only real impact on code is accessing user information for display (e.g. the classic "Welcome Pete"). This can easily be encapsulated by a single application class, and is perhaps a pattern we should recommend >>>> >>>> Therefore, we can see that whilst portability in IDM would be nice, it's not critical. >>>> >>>> >>>> Do we (JBoss) need IDM? Is there a demand for IDM in the community? >>>> ------------------------------------------------------------------------------------------------- >>>> >>>> I believe the short answer, and one we are all agreed on, is yes and yes :-) >>>> >>>> >>>> How do we move forward? >>>> ------------------------------------ >>>> >>>> The proposal is that we rehouse the IDM work done by Shane so far in PicketLink IDM [1]. This would consist of: >>>> >>>> * An IDM API >>>> * An IDM SPI (to allow IDM providers to be written) >>>> * An IDM impl (which loads the relevant provider and delegates calls to it) >>>> * A set of providers for the SPI such as JPA, LDAP etc. >>>> >>>> Both of these would be plain Java SE implementations, with minimal dependencies to allow maximum reuse by other JBoss projects. >>>> >>>> Furthermore, we would provide PicketLink CDI, which would provide an implementation of the authorization and authentication provider SPIs in DeltaSpike, that use the IDM backend. The module would also contain authorization providers for the various authorization frameworks PicketLink supports, as well provide authentication API implementations as needed. >>>> >>>> When will this be ready? >>>> -------------------------------- >>>> >>>> I'll let Shane chime in here, but I hope we can get something out fast, as we have a lot of code today. >>>> >>>> Thoughts? >>>> >>>> Pete > _______________________________________________ > security-dev mailing list > security-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/security-dev _______________________________________________ security-dev mailing list security-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/security-dev

Authorization doesn't plug straight into pure IDM, but instead plugs into a permission resolver, which in turn uses the IDM in order to turn the rights of a user into permissions to perform an action. This would come as part of PicketLink IDM AIUI. I need to do a bit more research here to complete the picture. I'll try to ping back in a bit.

Hi, some few open questions inline. On Friday, July 27, 2012 at 1:35 PM, Pete Muir wrote: > > Authentication > ------------------- Which IDM domain model should I use, picketlink idm or DeltaSpike? I might be wrong, but probably those entities belongs to the IDM? > https://github.com/apache/incubator-deltaspike/blob/5e4a7eb4de01004206f24... > > This contains methods to log in, log out, get the current user, and > check if a user is logged in or not. In order to log in/log out, a > LoginCredential is provided: How do they fit together? -> https://github.com/picketlink/picketlink-idm/blob/master/picketlink-idm-a... -> https://github.com/apache/incubator-deltaspike/blob/5e4a7eb4de01004206f24... > > https://github.com/apache/incubator-deltaspike/blob/5e4a7eb4de01004206f24... > > We also have a very basic representation of a user, which contains > some unique identifier for the user: > > https://github.com/apache/incubator-deltaspike/blob/5e4a7eb4de01004206f24... > > This isn't useful on it's own of course, but would plug into whatever > IDM solution you happen to use. In our case PicketLink IDM. Why not make use of same entity model from PicketLink IDM? https://github.com/picketlink/picketlink-idm/blob/master/picketlink-idm-a.... Or create some level of abstraction like that. How do I extend the User class to include a token and the email attribute?

- Bruno _______________________________________________ security-dev mailing list security-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/security-dev

On 30 Jul 2012, at 23:15, Shane Bryzak wrote: > On 31/07/12 04:40, Bruno Oliveira wrote: > > Hi, some few open questions inline. > > On Friday, July 27, 2012 at 1:35 PM, Pete Muir wrote: > > > > > > > > Authentication > > > ------------------- > > > > > > > Which IDM domain model should I use, picketlink idm or DeltaSpike? I might be wrong, but probably those entities belongs to the IDM? > > > > As Shane said, DS IDM is no more. > > > https://github.com/apache/incubator-deltaspike/blob/5e4a7eb4de01004206f24... > > > > > > This contains methods to log in, log out, get the current user, and check if a user is logged in or not. In order to log in/log out, a LoginCredential is provided: > > How do they fit together? > > > > -> https://github.com/picketlink/picketlink-idm/blob/master/picketlink-idm-a... > > > > -> https://github.com/apache/incubator-deltaspike/blob/5e4a7eb4de01004206f24... > > > > > > https://github.com/apache/incubator-deltaspike/blob/5e4a7eb4de01004206f24... > > > > > > We also have a very basic representation of a user, which contains some unique identifier for the user: > > > > > > https://github.com/apache/incubator-deltaspike/blob/5e4a7eb4de01004206f24... > > > > > > This isn't useful on it's own of course, but would plug into whatever IDM solution you happen to use. In our case PicketLink IDM. > > Why not make use of same entity model from PicketLink IDM? https://github.com/picketlink/picketlink-idm/blob/master/picketlink-idm-a.... Or create some level of abstraction like that. > > > > How do I extend the User class to include a token and the email attribute? > > All of this has been removed from DeltaSpike for now, and while the plan is to eventually add a simple authentication API (I'm not sure why we couldn't just use the one we already had) I don't think we can depend on this for now, so I'll be re-implementing all of it again in the PicketLink CDI module. We should try to use the DS stuff if possible. Once 0.3 is out, let's push to get this added into DS. If not, we do it in Picket, I agree. > > Shane > > > > > - Bruno > >