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 22:29:28 GMT
I'd rather have the mini-auth + some composite components + a small default login handling
in a separate module.

LieGrue,
strub



----- Original Message -----
> From: Jason Porter <lightguard.jp@gmail.com>
> To: deltaspike-dev@incubator.apache.org
> Cc: 
> Sent: Saturday, July 28, 2012 12:11 AM
> Subject: Re: IDM impl feedback
> 
>G erhard, you heard my thoughts on adding the authentication stuff back in.
> I'd like to suggest doing this either for v0.3 or v0.4 if we don't add 
> it
> in to v0.3.
> 
> On Fri, Jul 27, 2012 at 3:01 PM, Gerhard Petracek <
> gerhard.petracek@gmail.com> wrote:
> 
>>  hi @ all,
>> 
>>  since also everybody involved in the original implementation agreed with
>>  4b, i've created a jira-ticket [1] for the first two steps.
>>  please review the changes for step #1. if there are no objections, i'll
>>  push it to our repository in two days and i'll close the jira-tickets
>>  related to those topics.
>> 
>>  regards,
>>  gerhard
>> 
>>  [1] https://issues.apache.org/jira/browse/DELTASPIKE-249
>> 
>> 
>> 
>>  2012/7/27 Marius Bogoevici <marius.bogoevici@gmail.com>
>> 
>>  > 4b looks a good way to go for me as well.
>>  >
>>  >
>>  > On 2012-07-27 9:44 AM, Cody Lerum wrote:
>>  >
>>  >> +1 4b
>>  >> On Jul 26, 2012 4:41 PM, "Mark Struberg" 
> <struberg@yahoo.de> 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<
>> 
> 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<
>>  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://lightguard-jp.blogspot.com>
>>  >>>> http://twitter.com/**lightguardjp 
> <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
>>  >>>>
>>  >>>>
>>  >
>> 
> 
> 
> 
> -- 
> 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