IDM impl feedback

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: IDM impl feedback

Pete Muir
Apologies, I meant "have it in eventually e.g. 0.4" not "have it in this release" :-).

On 30 Jul 2012, at 11:25, Pete Muir wrote:

> 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 <[hidden email]>
>>> To: [hidden email]
>>> 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 <
>>> [hidden email]> 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 <[hidden email]>
>>>>
>>>>> 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"
>>> <[hidden email]> 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 <[hidden email]>
>>>>>>>> To: deltaspike-dev@incubator.**apache.org<
>>>> [hidden email]>
>>>>>>>> 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
>>>
>

Reply | Threaded
Open this post in threaded view
|

Re: IDM impl feedback

Pete Muir
And by "it" I mean the mini-authentication API + credentials + events we had in 0.2 :-)

On 30 Jul 2012, at 11:29, Pete Muir wrote:

> Apologies, I meant "have it in eventually e.g. 0.4" not "have it in this release" :-).
>
> On 30 Jul 2012, at 11:25, Pete Muir wrote:
>
>> 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 <[hidden email]>
>>>> To: [hidden email]
>>>> 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 <
>>>> [hidden email]> 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 <[hidden email]>
>>>>>
>>>>>> 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"
>>>> <[hidden email]> 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 <[hidden email]>
>>>>>>>>> To: deltaspike-dev@incubator.**apache.org<
>>>>> [hidden email]>
>>>>>>>>> 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
>>>>
>>
>

12