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 <lightguard...@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.petra...@gmail.com> wrote: >>> >>>> hi @ all, >>>> >>>> since also everybody involved in the original implementation agreed with >>>> 4b, i've created a jira-ticket [1] for the first two steps. >>>> please review the changes for step #1. if there are no objections, i'll >>>> push it to our repository in two days and i'll close the jira-tickets >>>> related to those topics. >>>> >>>> regards, >>>> gerhard >>>> >>>> [1] https://issues.apache.org/jira/browse/DELTASPIKE-249 >>>> >>>> >>>> >>>> 2012/7/27 Marius Bogoevici <marius.bogoev...@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" >>> <strub...@yahoo.de> wrote: >>>>>> >>>>>> Oki, here we go. >>>>>>> >>>>>>> We had a quick chat about where we basically stand today. >>>>>>> >>>>>>> >>>>>>> This is not intended to be a a 'what shall be' but >>> more a 'what do we >>>>>>> have' + 'what do we really need' email. >>>>>>> >>>>>>> >>>>>>> 1.) What we have today: >>>>>>> I've looked at the Security module and what I understand >>> it's pretty >>>>>>> powerful and complex. >>>>>>> There are aprox. 30++ Interfaces which are very flexible but >>> also very >>>>>>> hard to get right. Having lots of flexibility also makes it >>> easy to do >>>>>>> things wrong as user. E.g. IdentityManager which allows to >>> create >>>> users. >>>>>>> The RoleQuery and the whole Role management is pretty complete >>> from the >>>>>>> API >>>>>>> level but I've never seen it used in such detail in any >>> application >>>> yet. >>>>>>> Most times there is an additional mapping role -> rights. >>> And the right >>>>>>> is >>>>>>> what gets used in the application (e.g. in rendered= ). >>>>>>> >>>>>>> 2.) What is available in projects: >>>>>>> In my last 10 projects we never had the choice to define our >>> own login >>>>>>> logic. Some customers had radius, others authenticated against >>> SAP or >>>>>>> kerberos. Then there are some LDAP and we even have a single >>> sign on >>>>>>> based >>>>>>> on Smalltalk. And there is absolutely no way to get rid of >>> those! Most >>>> of >>>>>>> the time you cannot even create your own users... Of course >>> there is >>>> the >>>>>>> need for a simple html based user login for _some_ >>> applications. But >>>> this >>>>>>> is most times only needed for green-field projects. Whenever >>> you do >>>>>>> projects for a bigger company you most likely will find some >>> well >>>>>>> established SSO in place. >>>>>>> >>>>>>> 3.) what is needed in those projects: >>>>>>> I did quite some integration already in the past and the only >>> thing >>>> which >>>>>>> we did really need was >>>>>>> >>>>>>> 3.a.) to express some interrest: "current user likes >>> to do actionX" >>>>>>> This can be done via a @Secured interceptor, via @ViewConfig, >>> via >>>>>>> @PageBean etc -> might get provided by DS. >>>>>>> >>>>>>> 3.b.) to evaluate the "is the current user allowed to >>> do actionX" >>>>>>> Like with JAAS Voters this can be done via a simple Interface >>> which >>>>>>> returns a boolean. This is really similar to what Seam2 had >>> and also >>>> what >>>>>>> CODI did. >>>>>>> All the evaluation and binding to an existing authorisation >>> and >>>>>>> authentication can be done in this >>> AccessVoter/checkPermission. -> we >>>>>>> might >>>>>>> provide the Interfaces in DS. The impl is _always_ up to the >>> user. >>>>>>> >>>>>>> 4.) what are our options: >>>>>>> >>>>>>> 4.a.) fully implement our own security manager. This will >>> surely >>>> still >>>>>>> take some time as this is a complex topic! Many of the >>> interfaces are >>>> ok >>>>>>> but there is not yet an impl behind it. My personal estimation >>> is that >>>> we >>>>>>> now hit the 15% line, and a few people already spent a good >>> amount of >>>>>>> power >>>>>>> for it. So this will not be finished for the next 5 months I >>> fear. >>>>>>> >>>>>>> 4.b) implement a simple Voter + @Secured and let the user deal >>> with the >>>>>>> rest. In both Seam2 and CODI this turned out to not only be >>> extremely >>>>>>> flexible, but it is also rather easy to integrate [1]. We >>> could also >>>>>>> provide an additional module which contains a composite >>> component with >>>>>>> login userId + pwd fields + a simple backend for it. But just >>> as a >>>> small >>>>>>> additional module which might optionally be used for easier >>> integration >>>>>>> into JSF apps if there is not yet an existing SSO >>> implementation. >>>>>>> >>>>>>> LieGrue, >>>>>>> strub >>>>>>> >>>>>>> >>>>>>> [1] >>>>>>> https://github.com/struberg/**lightweightEE/blob/master/gui/** >>>>>>> src/main/java/de/jaxenter/**eesummit/caroline/gui/** >>>>>>> security/AdminAccessVoter.**java#L36< >>>> >>> https://github.com/struberg/lightweightEE/blob/master/gui/src/main/java/de/jaxenter/eesummit/caroline/gui/security/AdminAccessVoter.java#L36 >>>>> >>>>>>> >>>>>>> >>>>>>> ----- Original Message ----- >>>>>>> >>>>>>>> From: Jason Porter <lightguard...@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 >>> >
