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 <[email protected]> > 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 <[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 > >>> > > > > > >
