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