hi shane, imo it's better than the first draft -> +1 for committing it.
regards, gerhard 2012/3/5 Shane Bryzak <[email protected]> > 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 >> >> >
