deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Dijou <paul.dijou....@gmail.com>
Subject Re: [DISCUSS] DELTASPIKE-76 Authentication API
Date Wed, 07 Mar 2012 13:31:11 GMT
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 <boleslaw.dawidowicz@gmail.com>

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

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