deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gerhard Petracek <gerhard.petra...@gmail.com>
Subject Re: [DISCUSS] DELTASPIKE-76 Authentication API
Date Wed, 07 Mar 2012 14:08:00 GMT
hi paul,

we already had a short (irc) discussion about it and imo we have the same
(or at least a similar) opinion about it.

regards,
gerhard



2012/3/7 Paul Dijou <paul.dijou.dev@gmail.com>

> Hi,
>
> I still think the Authenticator should only authenticate and doesn't have
> to know anything about how the application handle the notion of User, Group
> and Role. Authenticator should take Credentials in entry, knows where to
> check (database, ldap, ...) and return the result (success, fail, on going,
> ...). That's all. So the Authenticator interface shouldn't have a
> set/getUser() in my opinion. This method could be on the IdentityManager.
>
> I'm saying that because I think about a generic authenticator used by
> several applications connected to a central LDAP for example but each one
> having it's own system around User/Group/Role.
>
> In practice, if an implementation of the Authenticator wants to modify
> directly the User, I'm fine with that, but the API should be as minimalist
> as possible.
>
> Regards,
>
> Paul.
>
> 2012/3/6 Boleslaw Dawidowicz <boleslaw.dawidowicz@gmail.com>
>
> > I like this idea. However my concern is that it will need clear
> > distinction in the IDM API between all roles (including session ones) and
> > persisted roles (identity store level).
> >
> > Bolek
> >
> > On Mar 5, 2012, at 11:45 PM, Shane Bryzak wrote:
> >
> > > Ok I've been thinking about this over the last few days (and come up
> > with a number of solutions I wasn't happy with), however there is one
> idea
> > in particular I quite like.  To take a step back for a moment though, the
> > reason we were contemplating adding the extra state to the User class was
> > so that we could convey that state between the authentication process and
> > the user's Identity.  This state (which represents the user's group and
> > role privileges) is then used for the duration of the user's session
> > whenever the Identity.hasRole() or Identity.hasGroup() methods are
> invoked,
> > to control the user's access to the restricted operations of the
> > application and so forth.
> > >
> > > Until now I believed that the challenge we had was how we integrate the
> > mechanism for this state transfer with the Identity Management API,
> however
> > I have now come to the conclusion that it should be integrated with the
> > Identity Management API itself, with the IdentityManager bean managing
> all
> > privilege assignment, both persistent and temporary.  With that in mind,
> > I'd like to propose we add the following methods to the IdentityManager
> > interface:
> > >
> > > grantRoleForSession(User user, Role role);
> > > grantGroupForSession(User user, Group group);
> > >
> > > We can see these methods in action by building on top of the
> > SimpleAuthenticator example we saw earlier to now include role and group
> > assignment:
> > >
> > > public class SimpleAuthenticator extends BaseAuthenticator implements
> > Authenticator
> > > {
> > >    @Inject
> > >    Credentials credentials;
> > >
> > >    @Inject
> > >    IdentityManager idm;
> > >
> > >    public void authenticate()
> > >   {
> > >        if ("demo".equals(credentials.getUsername()) &&
> > >                credentials.getCredential() instanceof
> PasswordCredential
> > &&
> > >                "demo".equals(((PasswordCredential)
> > credentials.getCredential()).getValue()))
> > >        {
> > >            setUser(new SimpleUser("demo"));
> > >            idm.grantRoleForSession(getUser(), new SimpleRole("ADMIN",
> > "USERS"));
> > >            idm.grantGroupForSession(getUser(), new
> SimpleGroup("USERS"));
> > >            setStatus(AuthenticationStatus.SUCCESS);
> > >        }
> > >        else
> > >        {
> > >            setStatus(AuthenticationStatus.FAILURE);
> > >        }
> > >    }
> > > }
> > >
> > > This solution is clean, keeps the User class free of additional state
> > and consolidates all user privilege management in one place.  It also
> opens
> > up a number of exciting possibilities, one such example being session
> > management (manipulation of user privileges at runtime) and makes much
> > easier to implement features such as more complex role assignment such as
> > temporal based (i.e. grant role X to user Y between the hours of 8am and
> > 5pm server time) or expiring (grant role X to user Y for exactly 30
> days).
> >  It also means auditing can be performed all in one class.
> > >
> > >
> > >
> > > On 02/03/12 06:41, Boleslaw Dawidowicz wrote:
> > >> On Feb 29, 2012, at 10:25 PM, Shane Bryzak wrote:
> > >>
> > >>>> currently i'm thinking about the dis-/advantages of moving those
> > methods to
> > >>>> User (or something like AuthenticatedUser)
> > >>> I think this would create complications when we start getting into
> the
> > Identity Management API.  The User object is intended to be a
> > self-contained, atomic representation of a single user and isn't intended
> > to contain state regarding the user's relationships or membership
> > privileges.  It's used in many Identity Management related operations and
> > the addition of this extra state would likely be problematic - I'm sure
> > Bolek could add more to this.
> > >> I support Shane on this. It could lead to a lot of complications and
> > not sure what would be benefits of having this.
> > >>
> > >> Bolek
> > >>
> > >
> >
> >
>

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