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
>>
>
