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 >
