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