incubator-deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shane Bryzak <sbry...@redhat.com>
Subject Re: [DISCUSS] DELTASPIKE-76 Authentication API
Date Mon, 05 Mar 2012 22:45:14 GMT
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
View raw message