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