hi paul, we already had a short (irc) discussion about it and imo we have the same (or at least a similar) opinion about it.
regards, gerhard 2012/3/7 Paul Dijou <[email protected]> > Hi, > > I still think the Authenticator should only authenticate and doesn't have > to know anything about how the application handle the notion of User, Group > and Role. Authenticator should take Credentials in entry, knows where to > check (database, ldap, ...) and return the result (success, fail, on going, > ...). That's all. So the Authenticator interface shouldn't have a > set/getUser() in my opinion. This method could be on the IdentityManager. > > I'm saying that because I think about a generic authenticator used by > several applications connected to a central LDAP for example but each one > having it's own system around User/Group/Role. > > In practice, if an implementation of the Authenticator wants to modify > directly the User, I'm fine with that, but the API should be as minimalist > as possible. > > Regards, > > Paul. > > 2012/3/6 Boleslaw Dawidowicz <[email protected]> > > > 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 > > >> > > > > > > > >
