Responding to Anil and Jay's points jointly.
On 27 Jul 2012, at 17:02, Jay Balunas wrote:
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).
They use DS security API for both authentication and authorization. When they need to do
IDM operations (i.e. CRUD the user), they use a PicketLink IDM API.
We would recommend that they encapsulate any READ operations in their own application I
think.
The IDM integration would be "swappable" then, or could be
added in later in app dev cycle.
Yes, the key here is that IDM operations impact very very small amounts of application
code, especially if you encapsulate any read operations.
>>
>> 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
Agree with Anil.
This would still be Application based, or are we jumping to container
IDM? I could see the need/want for both.
We're probably mixing what IDM means here.
The PicketLink IDM project is a set of connectors and APIs allowing an application to load
info about identity, and manage identity. It connects to an identity provider, such as
LDAP, JPA, ActiveDirectory etc.
We could connect to a container IDM, but I'm not sure of the use cases here.
>
>>
>> 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>
>>>> 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