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
