+1 LieGrue, strub
----- Original Message ----- > From: Mehdi Heidarzadeh <[email protected]> > To: [email protected] > 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 < > [email protected]> wrote: > >> This sounds reasonable to me as well. >> >> On Jul 27, 2012, at 1:10 AM, Shane Bryzak <[email protected]> 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 <[email protected]> >> >>> To: [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://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 >
