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