deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Romain Manni-Bucau <>
Subject Re: IDM impl feedback
Date Thu, 26 Jul 2012 22:49:55 GMT
great summary!

of course 4b) is IMO more reasonnable. Then the question should be do we
start from scratch? -> new api, new conf, new impls

- Romain

2012/7/27 Mark Struberg <>

> 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]
> ----- Original Message -----
> > From: Jason Porter <>
> > To:
> > 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
> >
> >
> >
> > Software Engineer
> > Open Source Advocate
> > Author of Seam Catch - Next Generation Java Exception Handling
> >
> > PGP key id: 926CCFF5
> > PGP key available at:,
> >

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message