hi jason, i removed them as well (in the preview), because they don't work without org.apache.deltaspike.security.api.idm.User. since we agreed on a different/new goal, we can re-visit those parts for the upcoming module. (maybe we will re-add e.g. some of the events, but for now we don't know what we will need.)
if we just revert back to what we had in v0.2, we wouldn't change a lot (and we have more or less the same). regards, gerhard 2012/7/28 Jason Porter <[email protected]> > You're thinking in v0.4 then? There's not a LOT of new stuff in v0.3 but we > have waited a while to release, we should probably get started soon on the > release. > > On Fri, Jul 27, 2012 at 4:29 PM, Mark Struberg <[email protected]> wrote: > > > 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 > > > > > > > > > -- > 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 >
