deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Struberg <strub...@yahoo.de>
Subject Re: IDM impl feedback
Date Fri, 27 Jul 2012 10:04:20 GMT
+1

LieGrue,
strub



----- Original Message -----
> From: Mehdi Heidarzadeh <heidarzadeh2@gmail.com>
> To: deltaspike-dev@incubator.apache.org
> Cc: 
> Sent: Friday, July 27, 2012 11:27 AM
> Subject: Re: IDM impl feedback
> 
> +1 for 4b
> 
> On Fri, Jul 27, 2012 at 1:21 PM, Boleslaw Dawidowicz <
> boleslaw.dawidowicz@gmail.com> wrote:
> 
>>  This sounds reasonable to me as well.
>> 
>>  On Jul 27, 2012, at 1:10 AM, Shane Bryzak <sbryzak@redhat.com> 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
>>  >>>
>>  >
>>  >
>> 
>> 
> 
> 
> -- 
> Mehdi Heidarzadeh Ardalani
> Independent JEE Consultant, Architect and Developer.
> http://www.TheBigJavaBlog.com
> 

Mime
View raw message