IDM impl feedback

[Jason Porter <li...@gmail.com>]

The 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

Re: IDM impl feedback

[Pete Muir <pm...@redhat.com>]

My initial reaction is 4b sounds like a good idea.

But I don't think we need to "start from scratch" but simply go back to what we had in 0.2, which provides this.

http://incubator.apache.org/deltaspike/security.html

On 26 Jul 2012, at 23:49, Romain Manni-Bucau wrote:

> great summary!
> 
> of course 4b) is IMO more reasonnable. Then the question should be do we
> start from scratch? -> new api, new conf, new impls
> 
> - Romain
> 
> 
> 2012/7/27 Mark Struberg <st...@yahoo.de>
> 
>> 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 <li...@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
>>> 
>> 

Re: IDM impl feedback

[Romain Manni-Bucau <rm...@gmail.com>]

great summary!

of course 4b) is IMO more reasonnable. Then the question should be do we
start from scratch? -> new api, new conf, new impls

- Romain


2012/7/27 Mark Struberg <st...@yahoo.de>

> 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 <li...@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
> >
>

Re: IDM impl feedback

[Pete Muir <pm...@redhat.com>]

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 <li...@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 <ma...@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" 
>>>> <st...@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 <li...@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
>>>> 
>> 
> 

Re: IDM impl feedback

[Pete Muir <pm...@redhat.com>]

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 <li...@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 <ma...@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" 
>>> <st...@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 <li...@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
>>> 
> 

Re: IDM impl feedback

[Pete Muir <pm...@redhat.com>]

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 <li...@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 <ma...@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" 
>> <st...@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 <li...@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
>> 

Re: IDM impl feedback

[Jason Porter <li...@gmail.com>]

That's fine, we can address this at a later time. I'd prefer to get v0.3
out the door sooner.

On Fri, Jul 27, 2012 at 4:54 PM, Gerhard Petracek <
gerhard.petracek@gmail.com> wrote:

> hi jason,
>
> i removed them as well (in the preview), because they don't work without
> org.apache.deltaspike.security.api.idm.User.
> since we agreed on a different/new goal, we can re-visit those parts for
> the upcoming module.
> (maybe we will re-add e.g. some of the events, but for now we don't know
> what we will need.)
>
> if we just revert back to what we had in v0.2, we wouldn't change a lot
> (and we have more or less the same).
>
> regards,
> gerhard
>
>
>
> 2012/7/28 Jason Porter <li...@gmail.com>
>
> > You're thinking in v0.4 then? There's not a LOT of new stuff in v0.3 but
> we
> > have waited a while to release, we should probably get started soon on
> the
> > release.
> >
> > On Fri, Jul 27, 2012 at 4:29 PM, Mark Struberg <st...@yahoo.de>
> 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 <li...@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 <ma...@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"
> > > > <st...@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 <li...@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
> > > >
> > >
> >
> >
> >
> > --
> > 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
> >
>



-- 
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

Re: IDM impl feedback

[Gerhard Petracek <ge...@gmail.com>]

hi jason,

i removed them as well (in the preview), because they don't work without
org.apache.deltaspike.security.api.idm.User.
since we agreed on a different/new goal, we can re-visit those parts for
the upcoming module.
(maybe we will re-add e.g. some of the events, but for now we don't know
what we will need.)

if we just revert back to what we had in v0.2, we wouldn't change a lot
(and we have more or less the same).

regards,
gerhard



2012/7/28 Jason Porter <li...@gmail.com>

> You're thinking in v0.4 then? There's not a LOT of new stuff in v0.3 but we
> have waited a while to release, we should probably get started soon on the
> release.
>
> On Fri, Jul 27, 2012 at 4:29 PM, Mark Struberg <st...@yahoo.de> 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 <li...@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 <ma...@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"
> > > <st...@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 <li...@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
> > >
> >
>
>
>
> --
> 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
>

Re: IDM impl feedback

[Jason Porter <li...@gmail.com>]

You're thinking in v0.4 then? There's not a LOT of new stuff in v0.3 but we
have waited a while to release, we should probably get started soon on the
release.

On Fri, Jul 27, 2012 at 4:29 PM, Mark Struberg <st...@yahoo.de> 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 <li...@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 <ma...@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"
> > <st...@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 <li...@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
> >
>



-- 
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

Re: IDM impl feedback

[Mark Struberg <st...@yahoo.de>]

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 <li...@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 <ma...@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" 
> <st...@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 <li...@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
> 

Re: IDM impl feedback

[Jason Porter <li...@gmail.com>]

Gerhard, 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 <ma...@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" <st...@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 <li...@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

Re: IDM impl feedback

[Gerhard Petracek <ge...@gmail.com>]

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 <ma...@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" <st...@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 <li...@gmail.com>
>>>> To: deltaspike-dev@incubator.**apache.org<de...@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
>>>>
>>>>
>

Re: IDM impl feedback

[Marius Bogoevici <ma...@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" <st...@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
>>
>>
>> ----- Original Message -----
>>> From: Jason Porter <li...@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
>>>

Re: IDM impl feedback

[Cody Lerum <co...@gmail.com>]

+1 4b
On Jul 26, 2012 4:41 PM, "Mark Struberg" <st...@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
>
>
> ----- Original Message -----
> > From: Jason Porter <li...@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
> >
>

Re: IDM impl feedback

[Jason Porter <li...@gmail.com>]

+1 for 4b

Sent from my iPhone

On Jul 26, 2012, at 17:36, Gerhard Petracek <ge...@gmail.com> wrote:

> since 4b is a slightly improved version of what we have in codi (and it's
> enough imo): +1 for it
> 
> regards,
> gerhard
> 
> 
> 
> 2012/7/27 Pete Muir <pm...@redhat.com>
> 
>> 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/apiis 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 <li...@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
>>>>> 
>>> 
>>> 
>> 
>> 

Re: IDM impl feedback

[Gerhard Petracek <ge...@gmail.com>]

since 4b is a slightly improved version of what we have in codi (and it's
enough imo): +1 for it

regards,
gerhard



2012/7/27 Pete Muir <pm...@redhat.com>

> 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/apiis 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 <li...@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
> >>>
> >
> >
>
>

Re: IDM impl feedback

[Pete Muir <pm...@redhat.com>]

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 <li...@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
>>> 
> 
> 

Re: IDM impl feedback

[Mark Struberg <st...@yahoo.de>]

+1

LieGrue,
strub



----- Original Message -----
> From: Mehdi Heidarzadeh <he...@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 <sb...@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 <li...@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
> 

Re: IDM impl feedback

[Mehdi Heidarzadeh <he...@gmail.com>]

+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 <sb...@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 <li...@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

Re: IDM impl feedback

[Boleslaw Dawidowicz <bo...@gmail.com>]

This sounds reasonable to me as well. 

On Jul 27, 2012, at 1:10 AM, Shane Bryzak <sb...@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 <li...@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
>>> 
> 
> 

Re: IDM impl feedback

[Shane Bryzak <sb...@redhat.com>]

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 <li...@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
>>

Re: IDM impl feedback

[Mark Struberg <st...@yahoo.de>]

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 <li...@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
>