deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gerhard Petracek <>
Subject Re: [DISCUSS] DELTASPIKE-76 Authentication API
Date Tue, 06 Mar 2012 18:11:11 GMT
hi shane,

imo it's better than the first draft -> +1 for committing it.


2012/3/5 Shane Bryzak <>

> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message