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 Mon, 30 Jul 2012 10:25:09 GMT
I would like us to have this bit in, whether it's in a separate module, or core, that is fine
by me.

On 27 Jul 2012, at 23:29, Mark Struberg wrote:

> 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