deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pete Muir <pm...@redhat.com>
Subject Re: IDM impl feedback
Date Thu, 26 Jul 2012 23:12:57 GMT
Having looked at what we had in 0.2 (https://github.com/apache/incubator-deltaspike/tree/5e4a7eb4de01004206f24ae22b9850e643bffe54/deltaspike/modules/security/api/src/main/java/org/apache/deltaspike/security/api
is the link into the tag :-), I think this would be a good point to stay with. The authorization
API looks good, and the basic Authentication API that is there is very useful for those on
some projects. It was very popular in Seam 2 (to which it is similar) I know :-)

On 27 Jul 2012, at 00:10, Shane Bryzak wrote:

> I had a quick chat with Pete and Jason and they brought me up to speed.  After much consideration
I think the best way to proceed would be 4.b), with the more complex features such as IDM
and permission management handled external to DS.
> 
> On 27/07/12 08:41, Mark Struberg wrote:
>> Oki, here we go.
>> 
>> We had a quick chat about where we basically stand today.
>> 
>> 
>> This is not intended to be a a 'what shall be' but more a 'what do we have' + 'what
do we really need' email.
>> 
>> 
>> 1.) What we have today:
>> I've looked at the Security module and what I understand it's pretty powerful and
complex.
>> There are aprox. 30++ Interfaces which are very flexible but also very hard to get
right. Having lots of flexibility also makes it easy to do things wrong as user. E.g. IdentityManager
which allows to create users. The RoleQuery and the whole Role management is pretty complete
from the API level but I've never seen it used in such detail in any application yet. Most
times there is an additional mapping role -> rights. And the right is what gets used in
the application (e.g. in rendered= ).
>> 
>> 2.) What is available in projects:
>> In my last 10 projects we never had the choice to define our own login logic. Some
customers had radius, others authenticated against SAP or kerberos. Then there are some LDAP
and we even have a single sign on based on Smalltalk. And there is absolutely no way to get
rid of those! Most of the time you cannot even create your own users... Of course there is
the need for a simple html based user login for _some_ applications. But this is most times
only needed for green-field projects. Whenever you do projects for a bigger company you most
likely will find some well established SSO in place.
>> 
>> 3.) what is needed in those projects:
>> I did quite some integration already in the past and the only thing which we did
really need was
>> 
>>   3.a.) to express some interrest: "current user likes to do actionX"
>> This can be done via a @Secured interceptor, via @ViewConfig, via @PageBean etc ->
might get provided by DS.
>> 
>>   3.b.) to evaluate the "is the current user allowed to do actionX"
>> Like with JAAS Voters this can be done via a simple Interface which returns a boolean.
This is really similar to what Seam2 had and also what CODI did.
>> All the evaluation and binding to an existing authorisation and authentication can
be done in this AccessVoter/checkPermission. -> we might provide the Interfaces in DS.
The impl is _always_ up to the user.
>> 
>> 4.) what are our options:
>> 
>>   4.a.) fully implement our own security manager. This will surely still take some
time as this is a complex topic! Many of the interfaces are ok but there is not yet an impl
behind it. My personal estimation is that we now hit the 15% line, and a few people already
spent a good amount of power for it. So this will not be finished for the next 5 months I
fear.
>>  4.b) implement a simple Voter + @Secured and let the user deal with the rest. In
both Seam2 and CODI this turned out to not only be extremely flexible, but it is also rather
easy to integrate [1]. We could also provide an additional module which contains a composite
component with login userId + pwd fields + a simple backend for it. But just as a small additional
module which might optionally be used for easier integration into JSF apps if there is not
yet an existing SSO implementation.
>> 
>> LieGrue,
>> strub
>> 
>> 
>> [1] https://github.com/struberg/lightweightEE/blob/master/gui/src/main/java/de/jaxenter/eesummit/caroline/gui/security/AdminAccessVoter.java#L36
>> 
>> 
>> ----- Original Message -----
>>> From: Jason Porter <lightguard.jp@gmail.com>
>>> To: deltaspike-dev@incubator.apache.org
>>> Cc:
>>> Sent: Thursday, July 26, 2012 9:03 PM
>>> Subject: IDM impl feedback
>>> 
>>> T he implementation that's in HEAD right now is incomplete. There are many
>>> methods which are basic IDE generated stubs in multiple classes. I'll hold
>>> off on any feedback until it's complete.
>>> 
>>> -- 
>>> Jason Porter
>>> http://lightguard-jp.blogspot.com
>>> http://twitter.com/lightguardjp
>>> 
>>> Software Engineer
>>> Open Source Advocate
>>> Author of Seam Catch - Next Generation Java Exception Handling
>>> 
>>> PGP key id: 926CCFF5
>>> PGP key available at: keyserver.net, pgp.mit.edu
>>> 
> 
> 


Mime
View raw message