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
