You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@deltaspike.apache.org by Shane Bryzak <sb...@redhat.com> on 2012/02/12 23:33:18 UTC
[DISCUSS] Identity API
I've created an umbrella issue to track the work we do on the security
module [1], and the first task is to review and discuss the Identity
API. This API forms the core of the security module, and all other
features build on top of it to implement a complete security framework.
The Identity interface represents an individual, current user of an
application and its implementation must be session-scoped to provide
security services for the entirety of a user's session. I'm going to
paste the (slightly modified) code from Seam as it's mostly well
documented, and so we have a baseline from which to further discuss:
public interface Identity {
public static final String RESPONSE_LOGIN_SUCCESS = "success";
public static final String RESPONSE_LOGIN_FAILED = "failed";
public static final String RESPONSE_LOGIN_EXCEPTION = "exception";
/**
* Simple check that returns true if the user is logged in, without
attempting to authenticate
*
* @return true if the user is logged in
*/
@Secures
@LoggedIn
boolean isLoggedIn();
/**
* Returns true if the currently authenticated user has provided their
correct credentials
* within the verification window configured by the application.
*
* @return
*/
boolean isVerified();
/**
* Will attempt to authenticate quietly if the user's credentials are set
and they haven't
* authenticated already. A quiet authentication doesn't throw any
exceptions if authentication
* fails.
*
* @return true if the user is logged in, false otherwise
*/
boolean tryLogin();
/**
* Returns the currently authenticated user
*
* @return
*/
User getUser();
/**
* Attempts to authenticate the user. This method raises the following
events in response
* to whether authentication is successful or not. The following events
may be raised
* during the call to login():
* <p/>
* org.apache.deltaspike.security.events.LoggedInEvent - raised when
authentication is successful
* org.apache.deltaspike.security.events.LoginFailedEvent - raised when
authentication fails
* org.apache.deltaspike.security.events.AlreadyLoggedInEvent - raised if
the user is already authenticated
*
* @return String returns RESPONSE_LOGIN_SUCCESS if user is authenticated,
* RESPONSE_LOGIN_FAILED if authentication failed, or
* RESPONSE_LOGIN_EXCEPTION if an exception occurred during
authentication. These response
* codes may be used to control user navigation. For deferred
authentication methods, such as Open ID
* the login() method will return an immediate result of
RESPONSE_LOGIN_FAILED (and subsequently fire
* a LoginFailedEvent) however in these conditions it is the
responsibility of the Authenticator
* implementation to take over the authentication process, for example by
redirecting the user to
* another authentication service.
*
*/
String login();
/**
* Attempts a quiet login, suppressing any login exceptions and not creating
* any faces messages. This method is intended to be used primarily as an
* internal API call, however has been made public for convenience.
*/
void quietLogin();
/**
* Logs out the currently authenticated user
*/
void logout();
/**
* Checks if the authenticated user is a member of the specified role.
*
* @param role String The name of the role to check * @param group String
the name of the group in which the role exists
* @return boolean True if the user is a member of the specified role
*/
boolean hasRole(String role, String group);
/**
* Adds a role to the authenticated user. If the user is not logged in,
* the role will be added to a list of roles that will be granted to the
* user upon successful authentication, but only during the authentication
* process.
*
* @param role The name of the role to add * @param group The name of the
group in which to create the role
*/
boolean addRole(String role, String group);
/**
* Checks if the authenticated user is a member of the specified group
*
* @param name The name of the group
* @return true if the user is a member of the group
*/
boolean inGroup(String name);
/**
* Adds the user to the specified group. See hasRole() for semantics in
* relationship to the authenticated status of the user.
*
* @param name The name of the group
* @return true if the group was successfully added
*/
boolean addGroup(String name);
/**
* Removes the currently authenticated user from the specified group
*
* @param name The name of the group
*/
void removeGroup(String name);
/**
* Removes a role from the authenticated user
*
* @param role The name of the role to remove
*/
void removeRole(String role, String group);
/**
* Checks that the current authenticated user is a member of
* the specified role.
*
* @param role String The name of the role to check
* @throws AuthorizationException if the authenticated user is not a
member of the role
*/
void checkRole(String role, String group);
/**
* @param group
* @param groupType
*/
void checkGroup(String group);
/**
* Returns an immutable set containing all the current user's granted roles
*
* @return
*/
Set<Role> getRoles();
/**
* Returns an immutable set containing all the current user's group
memberships
*
* @return
*/
Set<Group> getGroups();
}
Some particular points to review:
1. Should we attempt to use the security classes provided by Java SE,
such as Principal, Subject, etc or use our own User API - this will
affect what is returned by the getUser() method above. Keep in note
that we will have at least a simple User/Role/Group API as part of
Identity Management. In Seam 2 we originally used the built-in Java
classes (which made more sense because the authentication process was
based on JAAS), however in Seam 3 (where we removed JAAS because it
doesn't support asynchronous authentication as required by OpenID etc)
we based the security module on the PicketLink User API. IMHO, this is
not a critical choice either way - the Java security classes have the
advantage of being familiar to many users, while on the flipside if we
provide our own User API we have the flexibility of being able to extend
it in the future. So both options have their own advantages.
2. The addRole() and addGroup() methods are intended to be only used
during the authentication process to grant particular user memberships
for the duration of their session only. A few users have found this a
little confusing, as they were using identity management, and expected
these methods to grant a permanent membership for the user. One
solution may be to simply rename these methods to addSessionRole() and
addSessionGroup() - thoughts?
3. We're touching a little bit on the authorization API here also with
the hasRole() / inGroup() methods. I'll provide a quick description of
these core security API concepts here:
* User - represents an individual user of an application. Can either be
human or non-human, and can represent either a user managed locally
(i.e. through the IDM API) or an externally authenticated User, such as
one that has logged in with OpenID.
* Group - a collection of users and other groups. The intent is that
privileges can be either assigned to individual users, groups or roles.
Groups have a hierarchical structure and can be a member of zero or more
other groups.
* Role - represent a particular real life role of a user. Roles are
defined as a three-way relationship between user, group and role type.
For example, user "Bob" might be an "accounts clerk" (the role type) at
"head office" (the group). It is also possible for a user to have a
role in a group, without being a member of that group.
[1] https://issues.apache.org/jira/browse/DELTASPIKE-76
[2]
https://github.com/seam/security/blob/develop/api/src/main/java/org/jboss/seam/security/Identity.java
Re: [DISCUSS] Identity API
Posted by Shane Bryzak <sb...@redhat.com>.
On 13/02/12 18:15, Rudy De Busscher wrote:
> Hi,
>
> I think it is also important that you can work with permissions. It is
> much more fine grained then roles but more flexible. It becomes much easier
> to change what a group of people can do, even without changing the code. I
> never use roles in an application, only permissions.
>
> I'm not saying we need to do the implementation of it by default in
> deltaspike but should have at least something like
> boolean hasPermission(String permissionName)
> in the identity API.
I agree, we should have support for permissions by default - the
Identity class actually does define a hasPermission() method already.
>
>
> my idea about security.
>
>
> regards
> Rudy
>
> On 12h February 2012 23:33, Shane Bryzak<sb...@redhat.com> wrote:
>
>> I've created an umbrella issue to track the work we do on the security
>> module [1], and the first task is to review and discuss the Identity API.
>> This API forms the core of the security module, and all other features
>> build on top of it to implement a complete security framework.
>>
>> The Identity interface represents an individual, current user of an
>> application and its implementation must be session-scoped to provide
>> security services for the entirety of a user's session. I'm going to paste
>> the (slightly modified) code from Seam as it's mostly well documented, and
>> so we have a baseline from which to further discuss:
>>
>> public interface Identity {
>> public static final String RESPONSE_LOGIN_SUCCESS = "success";
>> public static final String RESPONSE_LOGIN_FAILED = "failed";
>> public static final String RESPONSE_LOGIN_EXCEPTION = "exception";
>> /**
>> * Simple check that returns true if the user is logged in, without
>> attempting to authenticate
>> *
>> * @return true if the user is logged in
>> */
>> @Secures
>> @LoggedIn
>> boolean isLoggedIn();
>> /**
>> * Returns true if the currently authenticated user has provided their
>> correct credentials
>> * within the verification window configured by the application.
>> *
>> * @return
>> */
>> boolean isVerified();
>> /**
>> * Will attempt to authenticate quietly if the user's credentials are set
>> and they haven't
>> * authenticated already. A quiet authentication doesn't throw any
>> exceptions if authentication
>> * fails.
>> *
>> * @return true if the user is logged in, false otherwise
>> */
>> boolean tryLogin();
>> /**
>> * Returns the currently authenticated user
>> *
>> * @return
>> */
>> User getUser();
>>
>> /**
>> * Attempts to authenticate the user. This method raises the following
>> events in response
>> * to whether authentication is successful or not. The following events may
>> be raised
>> * during the call to login():
>> *<p/>
>> * org.apache.deltaspike.**security.events.LoggedInEvent - raised when
>> authentication is successful
>> * org.apache.deltaspike.**security.events.**LoginFailedEvent - raised
>> when authentication fails
>> * org.apache.deltaspike.**security.events.**AlreadyLoggedInEvent - raised
>> if the user is already authenticated
>> *
>> * @return String returns RESPONSE_LOGIN_SUCCESS if user is authenticated,
>> * RESPONSE_LOGIN_FAILED if authentication failed, or
>> * RESPONSE_LOGIN_EXCEPTION if an exception occurred during authentication.
>> These response
>> * codes may be used to control user navigation. For deferred
>> authentication methods, such as Open ID
>> * the login() method will return an immediate result of
>> RESPONSE_LOGIN_FAILED (and subsequently fire
>> * a LoginFailedEvent) however in these conditions it is the responsibility
>> of the Authenticator
>> * implementation to take over the authentication process, for example by
>> redirecting the user to
>> * another authentication service.
>> *
>> */
>> String login();
>> /**
>> * Attempts a quiet login, suppressing any login exceptions and not creating
>> * any faces messages. This method is intended to be used primarily as an
>> * internal API call, however has been made public for convenience.
>> */
>> void quietLogin();
>> /**
>> * Logs out the currently authenticated user
>> */
>> void logout();
>> /**
>> * Checks if the authenticated user is a member of the specified role.
>> *
>> * @param role String The name of the role to check * @param group String
>> the name of the group in which the role exists
>> * @return boolean True if the user is a member of the specified role
>> */
>> boolean hasRole(String role, String group);
>> /**
>> * Adds a role to the authenticated user. If the user is not logged in,
>> * the role will be added to a list of roles that will be granted to the
>> * user upon successful authentication, but only during the authentication
>> * process.
>> *
>> * @param role The name of the role to add * @param group The name of the
>> group in which to create the role
>> */
>> boolean addRole(String role, String group);
>> /**
>> * Checks if the authenticated user is a member of the specified group
>> *
>> * @param name The name of the group
>> * @return true if the user is a member of the group
>> */
>> boolean inGroup(String name);
>> /**
>> * Adds the user to the specified group. See hasRole() for semantics in
>> * relationship to the authenticated status of the user.
>> *
>> * @param name The name of the group
>> * @return true if the group was successfully added
>> */
>> boolean addGroup(String name);
>> /**
>> * Removes the currently authenticated user from the specified group
>> *
>> * @param name The name of the group
>> */
>> void removeGroup(String name);
>> /**
>> * Removes a role from the authenticated user
>> *
>> * @param role The name of the role to remove
>> */
>> void removeRole(String role, String group);
>> /**
>> * Checks that the current authenticated user is a member of
>> * the specified role.
>> *
>> * @param role String The name of the role to check
>> * @throws AuthorizationException if the authenticated user is not a member
>> of the role
>> */
>> void checkRole(String role, String group);
>> /**
>> * @param group
>> * @param groupType
>> */
>> void checkGroup(String group);
>> /**
>> * Returns an immutable set containing all the current user's granted roles
>> *
>> * @return
>> */
>> Set<Role> getRoles();
>> /**
>> * Returns an immutable set containing all the current user's group
>> memberships
>> *
>> * @return
>> */
>> Set<Group> getGroups();
>> }
>>
>>
>> Some particular points to review:
>>
>> 1. Should we attempt to use the security classes provided by Java SE, such
>> as Principal, Subject, etc or use our own User API - this will affect what
>> is returned by the getUser() method above. Keep in note that we will have
>> at least a simple User/Role/Group API as part of Identity Management. In
>> Seam 2 we originally used the built-in Java classes (which made more sense
>> because the authentication process was based on JAAS), however in Seam 3
>> (where we removed JAAS because it doesn't support asynchronous
>> authentication as required by OpenID etc) we based the security module on
>> the PicketLink User API. IMHO, this is not a critical choice either way -
>> the Java security classes have the advantage of being familiar to many
>> users, while on the flipside if we provide our own User API we have the
>> flexibility of being able to extend it in the future. So both options have
>> their own advantages.
>>
>> 2. The addRole() and addGroup() methods are intended to be only used
>> during the authentication process to grant particular user memberships for
>> the duration of their session only. A few users have found this a little
>> confusing, as they were using identity management, and expected these
>> methods to grant a permanent membership for the user. One solution may be
>> to simply rename these methods to addSessionRole() and addSessionGroup() -
>> thoughts?
>>
>> 3. We're touching a little bit on the authorization API here also with the
>> hasRole() / inGroup() methods. I'll provide a quick description of these
>> core security API concepts here:
>>
>> * User - represents an individual user of an application. Can either be
>> human or non-human, and can represent either a user managed locally (i.e.
>> through the IDM API) or an externally authenticated User, such as one that
>> has logged in with OpenID.
>> * Group - a collection of users and other groups. The intent is that
>> privileges can be either assigned to individual users, groups or roles.
>> Groups have a hierarchical structure and can be a member of zero or more
>> other groups.
>> * Role - represent a particular real life role of a user. Roles are
>> defined as a three-way relationship between user, group and role type. For
>> example, user "Bob" might be an "accounts clerk" (the role type) at "head
>> office" (the group). It is also possible for a user to have a role in a
>> group, without being a member of that group.
>>
>>
>>
>> [1] https://issues.apache.org/**jira/browse/DELTASPIKE-76<https://issues.apache.org/jira/browse/DELTASPIKE-76>
>> [2] https://github.com/seam/**security/blob/develop/api/src/**
>> main/java/org/jboss/seam/**security/Identity.java<https://github.com/seam/security/blob/develop/api/src/main/java/org/jboss/seam/security/Identity.java>
>>
>
>
Re: [DISCUSS] DELTASPIKE-77 Identity API
Posted by Gerhard Petracek <ge...@gmail.com>.
hi shane,
@#tryLogin:
ok - since we can provide a simplified handling for important use-cases ->
i'm ok with it.
@#login:
matt answered it already (it even works with jsf 1.2)
@#hasRole (overloaded)
agreed - i also don't like that one. if we keep #tryLogin, we should use
the same naming convention for both.
#tryHasRole might not be the best name, however, we could think about an
alternative prefix or we just keep it for such methods in general (for all
modules - we already have such methods e.g. in ClassUtils).
@#addXyz by example
current usage:
@Inject
private Identity identity;
//...
identity.removeRole(...);
identity.logout();
suggested usage to keep the api simpler for 90+ % of all use-cases:
@Inject
private Identity identity;
//...
identity.logout();
and as soon as users need the "write-methods" which aren't intended to be
used frequently, they just change it to:
@Inject
private EditableIdentity identity;
//...
identity.removeRole(...);
identity.logout();
that works because EditableIdentity extends Identity and there is just one
producer internally (so they could even cast the injected instance - if
they prefer it).
regards,
gerhard
2012/2/14 Shane Bryzak <sb...@redhat.com>
> On 13/02/12 19:55, Gerhard Petracek wrote:
>
>> hi shane,
>>
>> i'm sure there are good reasons for most/all details. since i don't know
>> them, i just list the topics which come to my mind after reading the
>> provided information.
>>
>> #tryLogin
>> i don't see the need for it compared to #login, because it can be done by
>> users easily (if needed).
>> at least at the beginning i would keep the api as minimal as possible. we
>> can add further parts based on concrete and important use-cases.
>>
>
> There are actually two quite important use cases for this - applications
> that implement some kind of "Remember Me" function must be able to
> authenticate without producing the usual events/messages generated when
> performing a conscious authentication. The same goes for stateless
> applications that must authenticate on every request. We can probably
> remove the quietLogin() method and make it an implementation detail.
>
>
>> #login
>> uses string as return type instead of an enum.
>> in>general< : we should define a general rule for the usage of exceptions
>> which should be used by most deltaspike apis.
>>
>
> This method returns a String to make it easy to write navigation rules for
> JSF. The three possible values are "success", "failure" or "exception",
> which allows the navigation rules to redirect the user to an appropriate
> page based on the result. I'm happy to hear alternatives here if someone
> has other suggestions.
>
>
>> #quietLogin
>>
>>> is method is intended to be used primarily as an internal API call
>>>
>> ... then it shouldn't be part of the api. (that's related to a 2nd topic.
>> see api vs. spi)
>>
>
> See comment above.
>
>
>> #hasRole
>>
>>> Checks if the authenticated user is a member of the specified role.
>>>
>> #checkRole
>>
>>> Checks that the current authenticated user is a member of the specified
>>>
>> role.
>>
>> #hasRole and #checkRole look very similar - if the exception is the only
>> difference: see my comment about #tryLogin. at least we should think about
>> unified names.
>>
>
> We can probably merge these into a single method / overloaded methods:
>
> hasRole(String role, String group) // default doesn't throw exception
> hasRole(String role, String group, boolean throwException) // throws
> exception is throwException == true
>
> I personally think this looks ugly though. Another alternative is to just
> remove the checkRole() method altogether. Since most authorization now
> should be performed using the typesafe security bindings, it can simply be
> left to the authorizer method to implement the desired behaviour. Same
> thing goes for checkGroup().
>
>
>> #addXyz
>> that's a general topic we have to discuss. in myfaces codi we have all
>> "write-methods" which aren't intended to be used frequently in the spi to
>> keep the api simple and small ([1] and [2] illustrate it in case of the
>> initial refactoring of @Secured for deltaspike - the naming convention is
>> always Editable[ApiName]).
>>
>
> I agree that it would be nice to separate these methods into an SPI class.
> The reason they're in the API is so that developers can simply inject a
> single class (Identity) into their custom authentication class and have all
> the things they need there to perform authentication. I'll try to think of
> a more suitable alternative that doesn't put too much additional burden on
> the developer.
>
>
>> @type "string" in the api:
>> i know - it's easy, generic and sometimes just needed to use strings.
>> however, at least we should re-visit them and just use them if there is no
>> useful alternative.
>>
>> @rudy:
>> i agree with you.
>>
>> for v0.1 we always started to discuss the basic use-cases and requirements
>> and afterwards the concrete api.
>>
>>> imo< that leads to a better api and we should try to keep this approach
>>>
>> (for sure the content of v0.1 was easier).
>>
>> regards,
>> gerhard
>>
>> [1] http://s.apache.org/4sL
>> [2] http://s.apache.org/j2E
>>
>>
>>
>> 2012/2/13 Rudy De Busscher<rdebusscher@gmail.com**>
>>
>> Hi,
>>>
>>> I think it is also important that you can work with permissions. It is
>>> much more fine grained then roles but more flexible. It becomes much
>>> easier
>>> to change what a group of people can do, even without changing the code.
>>> I
>>> never use roles in an application, only permissions.
>>>
>>> I'm not saying we need to do the implementation of it by default in
>>> deltaspike but should have at least something like
>>> boolean hasPermission(String permissionName)
>>> in the identity API.
>>>
>>>
>>> my idea about security.
>>>
>>>
>>> regards
>>> Rudy
>>>
>>> On 12h February 2012 23:33, Shane Bryzak<sb...@redhat.com> wrote:
>>>
>>> I've created an umbrella issue to track the work we do on the security
>>>> module [1], and the first task is to review and discuss the Identity
>>>> API.
>>>> This API forms the core of the security module, and all other features
>>>> build on top of it to implement a complete security framework.
>>>>
>>>> The Identity interface represents an individual, current user of an
>>>> application and its implementation must be session-scoped to provide
>>>> security services for the entirety of a user's session. I'm going to
>>>>
>>> paste
>>>
>>>> the (slightly modified) code from Seam as it's mostly well documented,
>>>>
>>> and
>>>
>>>> so we have a baseline from which to further discuss:
>>>>
>>>> public interface Identity {
>>>> public static final String RESPONSE_LOGIN_SUCCESS = "success";
>>>> public static final String RESPONSE_LOGIN_FAILED = "failed";
>>>> public static final String RESPONSE_LOGIN_EXCEPTION = "exception";
>>>> /**
>>>> * Simple check that returns true if the user is logged in, without
>>>> attempting to authenticate
>>>> *
>>>> * @return true if the user is logged in
>>>> */
>>>> @Secures
>>>> @LoggedIn
>>>> boolean isLoggedIn();
>>>> /**
>>>> * Returns true if the currently authenticated user has provided their
>>>> correct credentials
>>>> * within the verification window configured by the application.
>>>> *
>>>> * @return
>>>> */
>>>> boolean isVerified();
>>>> /**
>>>> * Will attempt to authenticate quietly if the user's credentials are set
>>>> and they haven't
>>>> * authenticated already. A quiet authentication doesn't throw any
>>>> exceptions if authentication
>>>> * fails.
>>>> *
>>>> * @return true if the user is logged in, false otherwise
>>>> */
>>>> boolean tryLogin();
>>>> /**
>>>> * Returns the currently authenticated user
>>>> *
>>>> * @return
>>>> */
>>>> User getUser();
>>>>
>>>> /**
>>>> * Attempts to authenticate the user. This method raises the following
>>>> events in response
>>>> * to whether authentication is successful or not. The following events
>>>>
>>> may
>>>
>>>> be raised
>>>> * during the call to login():
>>>> *<p/>
>>>> * org.apache.deltaspike.****security.events.LoggedInEvent - raised when
>>>> authentication is successful
>>>> * org.apache.deltaspike.****security.events.****LoginFailedEvent -
>>>> raised
>>>> when authentication fails
>>>> * org.apache.deltaspike.****security.events.****AlreadyLoggedInEvent -
>>>> raised
>>>> if the user is already authenticated
>>>> *
>>>> * @return String returns RESPONSE_LOGIN_SUCCESS if user is
>>>> authenticated,
>>>> * RESPONSE_LOGIN_FAILED if authentication failed, or
>>>> * RESPONSE_LOGIN_EXCEPTION if an exception occurred during
>>>>
>>> authentication.
>>>
>>>> These response
>>>> * codes may be used to control user navigation. For deferred
>>>> authentication methods, such as Open ID
>>>> * the login() method will return an immediate result of
>>>> RESPONSE_LOGIN_FAILED (and subsequently fire
>>>> * a LoginFailedEvent) however in these conditions it is the
>>>>
>>> responsibility
>>>
>>>> of the Authenticator
>>>> * implementation to take over the authentication process, for example by
>>>> redirecting the user to
>>>> * another authentication service.
>>>> *
>>>> */
>>>> String login();
>>>> /**
>>>> * Attempts a quiet login, suppressing any login exceptions and not
>>>>
>>> creating
>>>
>>>> * any faces messages. This method is intended to be used primarily as an
>>>> * internal API call, however has been made public for convenience.
>>>> */
>>>> void quietLogin();
>>>> /**
>>>> * Logs out the currently authenticated user
>>>> */
>>>> void logout();
>>>> /**
>>>> * Checks if the authenticated user is a member of the specified role.
>>>> *
>>>> * @param role String The name of the role to check * @param group String
>>>> the name of the group in which the role exists
>>>> * @return boolean True if the user is a member of the specified role
>>>> */
>>>> boolean hasRole(String role, String group);
>>>> /**
>>>> * Adds a role to the authenticated user. If the user is not logged in,
>>>> * the role will be added to a list of roles that will be granted to the
>>>> * user upon successful authentication, but only during the
>>>> authentication
>>>> * process.
>>>> *
>>>> * @param role The name of the role to add * @param group The name of the
>>>> group in which to create the role
>>>> */
>>>> boolean addRole(String role, String group);
>>>> /**
>>>> * Checks if the authenticated user is a member of the specified group
>>>> *
>>>> * @param name The name of the group
>>>> * @return true if the user is a member of the group
>>>> */
>>>> boolean inGroup(String name);
>>>> /**
>>>> * Adds the user to the specified group. See hasRole() for semantics in
>>>> * relationship to the authenticated status of the user.
>>>> *
>>>> * @param name The name of the group
>>>> * @return true if the group was successfully added
>>>> */
>>>> boolean addGroup(String name);
>>>> /**
>>>> * Removes the currently authenticated user from the specified group
>>>> *
>>>> * @param name The name of the group
>>>> */
>>>> void removeGroup(String name);
>>>> /**
>>>> * Removes a role from the authenticated user
>>>> *
>>>> * @param role The name of the role to remove
>>>> */
>>>> void removeRole(String role, String group);
>>>> /**
>>>> * Checks that the current authenticated user is a member of
>>>> * the specified role.
>>>> *
>>>> * @param role String The name of the role to check
>>>> * @throws AuthorizationException if the authenticated user is not a
>>>>
>>> member
>>>
>>>> of the role
>>>> */
>>>> void checkRole(String role, String group);
>>>> /**
>>>> * @param group
>>>> * @param groupType
>>>> */
>>>> void checkGroup(String group);
>>>> /**
>>>> * Returns an immutable set containing all the current user's granted
>>>>
>>> roles
>>>
>>>> *
>>>> * @return
>>>> */
>>>> Set<Role> getRoles();
>>>> /**
>>>> * Returns an immutable set containing all the current user's group
>>>> memberships
>>>> *
>>>> * @return
>>>> */
>>>> Set<Group> getGroups();
>>>> }
>>>>
>>>>
>>>> Some particular points to review:
>>>>
>>>> 1. Should we attempt to use the security classes provided by Java SE,
>>>>
>>> such
>>>
>>>> as Principal, Subject, etc or use our own User API - this will affect
>>>>
>>> what
>>>
>>>> is returned by the getUser() method above. Keep in note that we will
>>>>
>>> have
>>>
>>>> at least a simple User/Role/Group API as part of Identity Management.
>>>> In
>>>> Seam 2 we originally used the built-in Java classes (which made more
>>>>
>>> sense
>>>
>>>> because the authentication process was based on JAAS), however in Seam 3
>>>> (where we removed JAAS because it doesn't support asynchronous
>>>> authentication as required by OpenID etc) we based the security module
>>>> on
>>>> the PicketLink User API. IMHO, this is not a critical choice either way
>>>>
>>> -
>>>
>>>> the Java security classes have the advantage of being familiar to many
>>>> users, while on the flipside if we provide our own User API we have the
>>>> flexibility of being able to extend it in the future. So both options
>>>>
>>> have
>>>
>>>> their own advantages.
>>>>
>>>> 2. The addRole() and addGroup() methods are intended to be only used
>>>> during the authentication process to grant particular user memberships
>>>>
>>> for
>>>
>>>> the duration of their session only. A few users have found this a
>>>> little
>>>> confusing, as they were using identity management, and expected these
>>>> methods to grant a permanent membership for the user. One solution may
>>>>
>>> be
>>>
>>>> to simply rename these methods to addSessionRole() and addSessionGroup()
>>>>
>>> -
>>>
>>>> thoughts?
>>>>
>>>> 3. We're touching a little bit on the authorization API here also with
>>>>
>>> the
>>>
>>>> hasRole() / inGroup() methods. I'll provide a quick description of
>>>> these
>>>> core security API concepts here:
>>>>
>>>> * User - represents an individual user of an application. Can either be
>>>> human or non-human, and can represent either a user managed locally
>>>> (i.e.
>>>> through the IDM API) or an externally authenticated User, such as one
>>>>
>>> that
>>>
>>>> has logged in with OpenID.
>>>> * Group - a collection of users and other groups. The intent is that
>>>> privileges can be either assigned to individual users, groups or roles.
>>>> Groups have a hierarchical structure and can be a member of zero or
>>>> more
>>>> other groups.
>>>> * Role - represent a particular real life role of a user. Roles are
>>>> defined as a three-way relationship between user, group and role type.
>>>>
>>> For
>>>
>>>> example, user "Bob" might be an "accounts clerk" (the role type) at
>>>> "head
>>>> office" (the group). It is also possible for a user to have a role in a
>>>> group, without being a member of that group.
>>>>
>>>>
>>>>
>>>> [1] https://issues.apache.org/****jira/browse/DELTASPIKE-76<https://issues.apache.org/**jira/browse/DELTASPIKE-76>
>>>> <
>>>>
>>> https://issues.apache.org/**jira/browse/DELTASPIKE-76<https://issues.apache.org/jira/browse/DELTASPIKE-76>
>>> >
>>>
>>>> [2] https://github.com/seam/****security/blob/develop/api/src/****<https://github.com/seam/**security/blob/develop/api/src/**>
>>>> main/java/org/jboss/seam/****security/Identity.java<
>>>>
>>> https://github.com/seam/**security/blob/develop/api/src/**
>>> main/java/org/jboss/seam/**security/Identity.java<https://github.com/seam/security/blob/develop/api/src/main/java/org/jboss/seam/security/Identity.java>
>>>
>>>>
>>>>
>>>
>>> --
>>> Rudy De Busscher
>>>
>>>
>
Re: [DISCUSS] DELTASPIKE-77 Identity API
Posted by Shane Bryzak <sb...@redhat.com>.
>>> #login
>>> uses string as return type instead of an enum.
>>> in>general< : we should define a general rule for the usage of exceptions
>>> which should be used by most deltaspike apis.
>>
>> This method returns a String to make it easy to write navigation rules for
>> JSF. The three possible values are "success", "failure" or "exception",
>> which allows the navigation rules to redirect the user to an appropriate
>> page based on the result. I'm happy to hear alternatives here if someone
>> has other suggestions.
> e.g. documentation of h:commandButton in JSF 2.1 docs says of @action
> "The expression must evaluate to a public method that takes no
> parameters, and returns an Object (the toString() of which is called
> to derive the logical outcome) which is passed to the
> NavigationHandler for this application." I read from this that an
> enum is as good for JSF as anything else we might return here.
>
> Matt
>
If that's the case then +1 for an enum result from me.
Re: [DISCUSS] DELTASPIKE-77 Identity API
Posted by Matt Benson <gu...@gmail.com>.
On Tue, Feb 14, 2012 at 3:34 PM, Shane Bryzak <sb...@redhat.com> wrote:
> On 13/02/12 19:55, Gerhard Petracek wrote:
>>
>> hi shane,
>>
>> i'm sure there are good reasons for most/all details. since i don't know
>> them, i just list the topics which come to my mind after reading the
>> provided information.
>>
>> #tryLogin
>> i don't see the need for it compared to #login, because it can be done by
>> users easily (if needed).
>> at least at the beginning i would keep the api as minimal as possible. we
>> can add further parts based on concrete and important use-cases.
>
>
> There are actually two quite important use cases for this - applications
> that implement some kind of "Remember Me" function must be able to
> authenticate without producing the usual events/messages generated when
> performing a conscious authentication. The same goes for stateless
> applications that must authenticate on every request. We can probably
> remove the quietLogin() method and make it an implementation detail.
>
>>
>> #login
>> uses string as return type instead of an enum.
>> in>general< : we should define a general rule for the usage of exceptions
>> which should be used by most deltaspike apis.
>
>
> This method returns a String to make it easy to write navigation rules for
> JSF. The three possible values are "success", "failure" or "exception",
> which allows the navigation rules to redirect the user to an appropriate
> page based on the result. I'm happy to hear alternatives here if someone
> has other suggestions.
e.g. documentation of h:commandButton in JSF 2.1 docs says of @action
"The expression must evaluate to a public method that takes no
parameters, and returns an Object (the toString() of which is called
to derive the logical outcome) which is passed to the
NavigationHandler for this application." I read from this that an
enum is as good for JSF as anything else we might return here.
Matt
>
>>
>> #quietLogin
>>>
>>> is method is intended to be used primarily as an internal API call
>>
>> ... then it shouldn't be part of the api. (that's related to a 2nd topic.
>> see api vs. spi)
>
>
> See comment above.
>
>>
>> #hasRole
>>>
>>> Checks if the authenticated user is a member of the specified role.
>>
>> #checkRole
>>>
>>> Checks that the current authenticated user is a member of the specified
>>
>> role.
>>
>> #hasRole and #checkRole look very similar - if the exception is the only
>> difference: see my comment about #tryLogin. at least we should think about
>> unified names.
>
>
> We can probably merge these into a single method / overloaded methods:
>
> hasRole(String role, String group) // default doesn't throw exception
> hasRole(String role, String group, boolean throwException) // throws
> exception is throwException == true
>
> I personally think this looks ugly though. Another alternative is to just
> remove the checkRole() method altogether. Since most authorization now
> should be performed using the typesafe security bindings, it can simply be
> left to the authorizer method to implement the desired behaviour. Same
> thing goes for checkGroup().
>
>>
>> #addXyz
>> that's a general topic we have to discuss. in myfaces codi we have all
>> "write-methods" which aren't intended to be used frequently in the spi to
>> keep the api simple and small ([1] and [2] illustrate it in case of the
>> initial refactoring of @Secured for deltaspike - the naming convention is
>> always Editable[ApiName]).
>
>
> I agree that it would be nice to separate these methods into an SPI class.
> The reason they're in the API is so that developers can simply inject a
> single class (Identity) into their custom authentication class and have all
> the things they need there to perform authentication. I'll try to think of
> a more suitable alternative that doesn't put too much additional burden on
> the developer.
>
>>
>> @type "string" in the api:
>> i know - it's easy, generic and sometimes just needed to use strings.
>> however, at least we should re-visit them and just use them if there is no
>> useful alternative.
>>
>> @rudy:
>> i agree with you.
>>
>> for v0.1 we always started to discuss the basic use-cases and requirements
>> and afterwards the concrete api.
>>>
>>> imo< that leads to a better api and we should try to keep this approach
>>
>> (for sure the content of v0.1 was easier).
>>
>> regards,
>> gerhard
>>
>> [1] http://s.apache.org/4sL
>> [2] http://s.apache.org/j2E
>>
>>
>>
>> 2012/2/13 Rudy De Busscher<rd...@gmail.com>
>>
>>> Hi,
>>>
>>> I think it is also important that you can work with permissions. It is
>>> much more fine grained then roles but more flexible. It becomes much
>>> easier
>>> to change what a group of people can do, even without changing the code.
>>> I
>>> never use roles in an application, only permissions.
>>>
>>> I'm not saying we need to do the implementation of it by default in
>>> deltaspike but should have at least something like
>>> boolean hasPermission(String permissionName)
>>> in the identity API.
>>>
>>>
>>> my idea about security.
>>>
>>>
>>> regards
>>> Rudy
>>>
>>> On 12h February 2012 23:33, Shane Bryzak<sb...@redhat.com> wrote:
>>>
>>>> I've created an umbrella issue to track the work we do on the security
>>>> module [1], and the first task is to review and discuss the Identity
>>>> API.
>>>> This API forms the core of the security module, and all other features
>>>> build on top of it to implement a complete security framework.
>>>>
>>>> The Identity interface represents an individual, current user of an
>>>> application and its implementation must be session-scoped to provide
>>>> security services for the entirety of a user's session. I'm going to
>>>
>>> paste
>>>>
>>>> the (slightly modified) code from Seam as it's mostly well documented,
>>>
>>> and
>>>>
>>>> so we have a baseline from which to further discuss:
>>>>
>>>> public interface Identity {
>>>> public static final String RESPONSE_LOGIN_SUCCESS = "success";
>>>> public static final String RESPONSE_LOGIN_FAILED = "failed";
>>>> public static final String RESPONSE_LOGIN_EXCEPTION = "exception";
>>>> /**
>>>> * Simple check that returns true if the user is logged in, without
>>>> attempting to authenticate
>>>> *
>>>> * @return true if the user is logged in
>>>> */
>>>> @Secures
>>>> @LoggedIn
>>>> boolean isLoggedIn();
>>>> /**
>>>> * Returns true if the currently authenticated user has provided their
>>>> correct credentials
>>>> * within the verification window configured by the application.
>>>> *
>>>> * @return
>>>> */
>>>> boolean isVerified();
>>>> /**
>>>> * Will attempt to authenticate quietly if the user's credentials are set
>>>> and they haven't
>>>> * authenticated already. A quiet authentication doesn't throw any
>>>> exceptions if authentication
>>>> * fails.
>>>> *
>>>> * @return true if the user is logged in, false otherwise
>>>> */
>>>> boolean tryLogin();
>>>> /**
>>>> * Returns the currently authenticated user
>>>> *
>>>> * @return
>>>> */
>>>> User getUser();
>>>>
>>>> /**
>>>> * Attempts to authenticate the user. This method raises the following
>>>> events in response
>>>> * to whether authentication is successful or not. The following events
>>>
>>> may
>>>>
>>>> be raised
>>>> * during the call to login():
>>>> *<p/>
>>>> * org.apache.deltaspike.**security.events.LoggedInEvent - raised when
>>>> authentication is successful
>>>> * org.apache.deltaspike.**security.events.**LoginFailedEvent - raised
>>>> when authentication fails
>>>> * org.apache.deltaspike.**security.events.**AlreadyLoggedInEvent -
>>>> raised
>>>> if the user is already authenticated
>>>> *
>>>> * @return String returns RESPONSE_LOGIN_SUCCESS if user is
>>>> authenticated,
>>>> * RESPONSE_LOGIN_FAILED if authentication failed, or
>>>> * RESPONSE_LOGIN_EXCEPTION if an exception occurred during
>>>
>>> authentication.
>>>>
>>>> These response
>>>> * codes may be used to control user navigation. For deferred
>>>> authentication methods, such as Open ID
>>>> * the login() method will return an immediate result of
>>>> RESPONSE_LOGIN_FAILED (and subsequently fire
>>>> * a LoginFailedEvent) however in these conditions it is the
>>>
>>> responsibility
>>>>
>>>> of the Authenticator
>>>> * implementation to take over the authentication process, for example by
>>>> redirecting the user to
>>>> * another authentication service.
>>>> *
>>>> */
>>>> String login();
>>>> /**
>>>> * Attempts a quiet login, suppressing any login exceptions and not
>>>
>>> creating
>>>>
>>>> * any faces messages. This method is intended to be used primarily as an
>>>> * internal API call, however has been made public for convenience.
>>>> */
>>>> void quietLogin();
>>>> /**
>>>> * Logs out the currently authenticated user
>>>> */
>>>> void logout();
>>>> /**
>>>> * Checks if the authenticated user is a member of the specified role.
>>>> *
>>>> * @param role String The name of the role to check * @param group String
>>>> the name of the group in which the role exists
>>>> * @return boolean True if the user is a member of the specified role
>>>> */
>>>> boolean hasRole(String role, String group);
>>>> /**
>>>> * Adds a role to the authenticated user. If the user is not logged in,
>>>> * the role will be added to a list of roles that will be granted to the
>>>> * user upon successful authentication, but only during the
>>>> authentication
>>>> * process.
>>>> *
>>>> * @param role The name of the role to add * @param group The name of the
>>>> group in which to create the role
>>>> */
>>>> boolean addRole(String role, String group);
>>>> /**
>>>> * Checks if the authenticated user is a member of the specified group
>>>> *
>>>> * @param name The name of the group
>>>> * @return true if the user is a member of the group
>>>> */
>>>> boolean inGroup(String name);
>>>> /**
>>>> * Adds the user to the specified group. See hasRole() for semantics in
>>>> * relationship to the authenticated status of the user.
>>>> *
>>>> * @param name The name of the group
>>>> * @return true if the group was successfully added
>>>> */
>>>> boolean addGroup(String name);
>>>> /**
>>>> * Removes the currently authenticated user from the specified group
>>>> *
>>>> * @param name The name of the group
>>>> */
>>>> void removeGroup(String name);
>>>> /**
>>>> * Removes a role from the authenticated user
>>>> *
>>>> * @param role The name of the role to remove
>>>> */
>>>> void removeRole(String role, String group);
>>>> /**
>>>> * Checks that the current authenticated user is a member of
>>>> * the specified role.
>>>> *
>>>> * @param role String The name of the role to check
>>>> * @throws AuthorizationException if the authenticated user is not a
>>>
>>> member
>>>>
>>>> of the role
>>>> */
>>>> void checkRole(String role, String group);
>>>> /**
>>>> * @param group
>>>> * @param groupType
>>>> */
>>>> void checkGroup(String group);
>>>> /**
>>>> * Returns an immutable set containing all the current user's granted
>>>
>>> roles
>>>>
>>>> *
>>>> * @return
>>>> */
>>>> Set<Role> getRoles();
>>>> /**
>>>> * Returns an immutable set containing all the current user's group
>>>> memberships
>>>> *
>>>> * @return
>>>> */
>>>> Set<Group> getGroups();
>>>> }
>>>>
>>>>
>>>> Some particular points to review:
>>>>
>>>> 1. Should we attempt to use the security classes provided by Java SE,
>>>
>>> such
>>>>
>>>> as Principal, Subject, etc or use our own User API - this will affect
>>>
>>> what
>>>>
>>>> is returned by the getUser() method above. Keep in note that we will
>>>
>>> have
>>>>
>>>> at least a simple User/Role/Group API as part of Identity Management.
>>>> In
>>>> Seam 2 we originally used the built-in Java classes (which made more
>>>
>>> sense
>>>>
>>>> because the authentication process was based on JAAS), however in Seam 3
>>>> (where we removed JAAS because it doesn't support asynchronous
>>>> authentication as required by OpenID etc) we based the security module
>>>> on
>>>> the PicketLink User API. IMHO, this is not a critical choice either way
>>>
>>> -
>>>>
>>>> the Java security classes have the advantage of being familiar to many
>>>> users, while on the flipside if we provide our own User API we have the
>>>> flexibility of being able to extend it in the future. So both options
>>>
>>> have
>>>>
>>>> their own advantages.
>>>>
>>>> 2. The addRole() and addGroup() methods are intended to be only used
>>>> during the authentication process to grant particular user memberships
>>>
>>> for
>>>>
>>>> the duration of their session only. A few users have found this a
>>>> little
>>>> confusing, as they were using identity management, and expected these
>>>> methods to grant a permanent membership for the user. One solution may
>>>
>>> be
>>>>
>>>> to simply rename these methods to addSessionRole() and addSessionGroup()
>>>
>>> -
>>>>
>>>> thoughts?
>>>>
>>>> 3. We're touching a little bit on the authorization API here also with
>>>
>>> the
>>>>
>>>> hasRole() / inGroup() methods. I'll provide a quick description of
>>>> these
>>>> core security API concepts here:
>>>>
>>>> * User - represents an individual user of an application. Can either be
>>>> human or non-human, and can represent either a user managed locally
>>>> (i.e.
>>>> through the IDM API) or an externally authenticated User, such as one
>>>
>>> that
>>>>
>>>> has logged in with OpenID.
>>>> * Group - a collection of users and other groups. The intent is that
>>>> privileges can be either assigned to individual users, groups or roles.
>>>> Groups have a hierarchical structure and can be a member of zero or
>>>> more
>>>> other groups.
>>>> * Role - represent a particular real life role of a user. Roles are
>>>> defined as a three-way relationship between user, group and role type.
>>>
>>> For
>>>>
>>>> example, user "Bob" might be an "accounts clerk" (the role type) at
>>>> "head
>>>> office" (the group). It is also possible for a user to have a role in a
>>>> group, without being a member of that group.
>>>>
>>>>
>>>>
>>>> [1] https://issues.apache.org/**jira/browse/DELTASPIKE-76<
>>>
>>> https://issues.apache.org/jira/browse/DELTASPIKE-76>
>>>>
>>>> [2] https://github.com/seam/**security/blob/develop/api/src/**
>>>> main/java/org/jboss/seam/**security/Identity.java<
>>>
>>>
>>> https://github.com/seam/security/blob/develop/api/src/main/java/org/jboss/seam/security/Identity.java
>>>>
>>>>
>>>
>>>
>>> --
>>> Rudy De Busscher
>>>
>
Re: [DISCUSS] DELTASPIKE-77 Identity API
Posted by Shane Bryzak <sb...@redhat.com>.
On 13/02/12 19:55, Gerhard Petracek wrote:
> hi shane,
>
> i'm sure there are good reasons for most/all details. since i don't know
> them, i just list the topics which come to my mind after reading the
> provided information.
>
> #tryLogin
> i don't see the need for it compared to #login, because it can be done by
> users easily (if needed).
> at least at the beginning i would keep the api as minimal as possible. we
> can add further parts based on concrete and important use-cases.
There are actually two quite important use cases for this - applications
that implement some kind of "Remember Me" function must be able to
authenticate without producing the usual events/messages generated when
performing a conscious authentication. The same goes for stateless
applications that must authenticate on every request. We can probably
remove the quietLogin() method and make it an implementation detail.
>
> #login
> uses string as return type instead of an enum.
> in>general< : we should define a general rule for the usage of exceptions
> which should be used by most deltaspike apis.
This method returns a String to make it easy to write navigation rules
for JSF. The three possible values are "success", "failure" or
"exception", which allows the navigation rules to redirect the user to
an appropriate page based on the result. I'm happy to hear alternatives
here if someone has other suggestions.
>
> #quietLogin
>> is method is intended to be used primarily as an internal API call
> ... then it shouldn't be part of the api. (that's related to a 2nd topic.
> see api vs. spi)
See comment above.
>
> #hasRole
>> Checks if the authenticated user is a member of the specified role.
> #checkRole
>> Checks that the current authenticated user is a member of the specified
> role.
>
> #hasRole and #checkRole look very similar - if the exception is the only
> difference: see my comment about #tryLogin. at least we should think about
> unified names.
We can probably merge these into a single method / overloaded methods:
hasRole(String role, String group) // default doesn't throw exception
hasRole(String role, String group, boolean throwException) // throws
exception is throwException == true
I personally think this looks ugly though. Another alternative is to
just remove the checkRole() method altogether. Since most authorization
now should be performed using the typesafe security bindings, it can
simply be left to the authorizer method to implement the desired
behaviour. Same thing goes for checkGroup().
>
> #addXyz
> that's a general topic we have to discuss. in myfaces codi we have all
> "write-methods" which aren't intended to be used frequently in the spi to
> keep the api simple and small ([1] and [2] illustrate it in case of the
> initial refactoring of @Secured for deltaspike - the naming convention is
> always Editable[ApiName]).
I agree that it would be nice to separate these methods into an SPI
class. The reason they're in the API is so that developers can simply
inject a single class (Identity) into their custom authentication class
and have all the things they need there to perform authentication. I'll
try to think of a more suitable alternative that doesn't put too much
additional burden on the developer.
>
> @type "string" in the api:
> i know - it's easy, generic and sometimes just needed to use strings.
> however, at least we should re-visit them and just use them if there is no
> useful alternative.
>
> @rudy:
> i agree with you.
>
> for v0.1 we always started to discuss the basic use-cases and requirements
> and afterwards the concrete api.
>> imo< that leads to a better api and we should try to keep this approach
> (for sure the content of v0.1 was easier).
>
> regards,
> gerhard
>
> [1] http://s.apache.org/4sL
> [2] http://s.apache.org/j2E
>
>
>
> 2012/2/13 Rudy De Busscher<rd...@gmail.com>
>
>> Hi,
>>
>> I think it is also important that you can work with permissions. It is
>> much more fine grained then roles but more flexible. It becomes much easier
>> to change what a group of people can do, even without changing the code. I
>> never use roles in an application, only permissions.
>>
>> I'm not saying we need to do the implementation of it by default in
>> deltaspike but should have at least something like
>> boolean hasPermission(String permissionName)
>> in the identity API.
>>
>>
>> my idea about security.
>>
>>
>> regards
>> Rudy
>>
>> On 12h February 2012 23:33, Shane Bryzak<sb...@redhat.com> wrote:
>>
>>> I've created an umbrella issue to track the work we do on the security
>>> module [1], and the first task is to review and discuss the Identity API.
>>> This API forms the core of the security module, and all other features
>>> build on top of it to implement a complete security framework.
>>>
>>> The Identity interface represents an individual, current user of an
>>> application and its implementation must be session-scoped to provide
>>> security services for the entirety of a user's session. I'm going to
>> paste
>>> the (slightly modified) code from Seam as it's mostly well documented,
>> and
>>> so we have a baseline from which to further discuss:
>>>
>>> public interface Identity {
>>> public static final String RESPONSE_LOGIN_SUCCESS = "success";
>>> public static final String RESPONSE_LOGIN_FAILED = "failed";
>>> public static final String RESPONSE_LOGIN_EXCEPTION = "exception";
>>> /**
>>> * Simple check that returns true if the user is logged in, without
>>> attempting to authenticate
>>> *
>>> * @return true if the user is logged in
>>> */
>>> @Secures
>>> @LoggedIn
>>> boolean isLoggedIn();
>>> /**
>>> * Returns true if the currently authenticated user has provided their
>>> correct credentials
>>> * within the verification window configured by the application.
>>> *
>>> * @return
>>> */
>>> boolean isVerified();
>>> /**
>>> * Will attempt to authenticate quietly if the user's credentials are set
>>> and they haven't
>>> * authenticated already. A quiet authentication doesn't throw any
>>> exceptions if authentication
>>> * fails.
>>> *
>>> * @return true if the user is logged in, false otherwise
>>> */
>>> boolean tryLogin();
>>> /**
>>> * Returns the currently authenticated user
>>> *
>>> * @return
>>> */
>>> User getUser();
>>>
>>> /**
>>> * Attempts to authenticate the user. This method raises the following
>>> events in response
>>> * to whether authentication is successful or not. The following events
>> may
>>> be raised
>>> * during the call to login():
>>> *<p/>
>>> * org.apache.deltaspike.**security.events.LoggedInEvent - raised when
>>> authentication is successful
>>> * org.apache.deltaspike.**security.events.**LoginFailedEvent - raised
>>> when authentication fails
>>> * org.apache.deltaspike.**security.events.**AlreadyLoggedInEvent - raised
>>> if the user is already authenticated
>>> *
>>> * @return String returns RESPONSE_LOGIN_SUCCESS if user is authenticated,
>>> * RESPONSE_LOGIN_FAILED if authentication failed, or
>>> * RESPONSE_LOGIN_EXCEPTION if an exception occurred during
>> authentication.
>>> These response
>>> * codes may be used to control user navigation. For deferred
>>> authentication methods, such as Open ID
>>> * the login() method will return an immediate result of
>>> RESPONSE_LOGIN_FAILED (and subsequently fire
>>> * a LoginFailedEvent) however in these conditions it is the
>> responsibility
>>> of the Authenticator
>>> * implementation to take over the authentication process, for example by
>>> redirecting the user to
>>> * another authentication service.
>>> *
>>> */
>>> String login();
>>> /**
>>> * Attempts a quiet login, suppressing any login exceptions and not
>> creating
>>> * any faces messages. This method is intended to be used primarily as an
>>> * internal API call, however has been made public for convenience.
>>> */
>>> void quietLogin();
>>> /**
>>> * Logs out the currently authenticated user
>>> */
>>> void logout();
>>> /**
>>> * Checks if the authenticated user is a member of the specified role.
>>> *
>>> * @param role String The name of the role to check * @param group String
>>> the name of the group in which the role exists
>>> * @return boolean True if the user is a member of the specified role
>>> */
>>> boolean hasRole(String role, String group);
>>> /**
>>> * Adds a role to the authenticated user. If the user is not logged in,
>>> * the role will be added to a list of roles that will be granted to the
>>> * user upon successful authentication, but only during the authentication
>>> * process.
>>> *
>>> * @param role The name of the role to add * @param group The name of the
>>> group in which to create the role
>>> */
>>> boolean addRole(String role, String group);
>>> /**
>>> * Checks if the authenticated user is a member of the specified group
>>> *
>>> * @param name The name of the group
>>> * @return true if the user is a member of the group
>>> */
>>> boolean inGroup(String name);
>>> /**
>>> * Adds the user to the specified group. See hasRole() for semantics in
>>> * relationship to the authenticated status of the user.
>>> *
>>> * @param name The name of the group
>>> * @return true if the group was successfully added
>>> */
>>> boolean addGroup(String name);
>>> /**
>>> * Removes the currently authenticated user from the specified group
>>> *
>>> * @param name The name of the group
>>> */
>>> void removeGroup(String name);
>>> /**
>>> * Removes a role from the authenticated user
>>> *
>>> * @param role The name of the role to remove
>>> */
>>> void removeRole(String role, String group);
>>> /**
>>> * Checks that the current authenticated user is a member of
>>> * the specified role.
>>> *
>>> * @param role String The name of the role to check
>>> * @throws AuthorizationException if the authenticated user is not a
>> member
>>> of the role
>>> */
>>> void checkRole(String role, String group);
>>> /**
>>> * @param group
>>> * @param groupType
>>> */
>>> void checkGroup(String group);
>>> /**
>>> * Returns an immutable set containing all the current user's granted
>> roles
>>> *
>>> * @return
>>> */
>>> Set<Role> getRoles();
>>> /**
>>> * Returns an immutable set containing all the current user's group
>>> memberships
>>> *
>>> * @return
>>> */
>>> Set<Group> getGroups();
>>> }
>>>
>>>
>>> Some particular points to review:
>>>
>>> 1. Should we attempt to use the security classes provided by Java SE,
>> such
>>> as Principal, Subject, etc or use our own User API - this will affect
>> what
>>> is returned by the getUser() method above. Keep in note that we will
>> have
>>> at least a simple User/Role/Group API as part of Identity Management. In
>>> Seam 2 we originally used the built-in Java classes (which made more
>> sense
>>> because the authentication process was based on JAAS), however in Seam 3
>>> (where we removed JAAS because it doesn't support asynchronous
>>> authentication as required by OpenID etc) we based the security module on
>>> the PicketLink User API. IMHO, this is not a critical choice either way
>> -
>>> the Java security classes have the advantage of being familiar to many
>>> users, while on the flipside if we provide our own User API we have the
>>> flexibility of being able to extend it in the future. So both options
>> have
>>> their own advantages.
>>>
>>> 2. The addRole() and addGroup() methods are intended to be only used
>>> during the authentication process to grant particular user memberships
>> for
>>> the duration of their session only. A few users have found this a little
>>> confusing, as they were using identity management, and expected these
>>> methods to grant a permanent membership for the user. One solution may
>> be
>>> to simply rename these methods to addSessionRole() and addSessionGroup()
>> -
>>> thoughts?
>>>
>>> 3. We're touching a little bit on the authorization API here also with
>> the
>>> hasRole() / inGroup() methods. I'll provide a quick description of these
>>> core security API concepts here:
>>>
>>> * User - represents an individual user of an application. Can either be
>>> human or non-human, and can represent either a user managed locally (i.e.
>>> through the IDM API) or an externally authenticated User, such as one
>> that
>>> has logged in with OpenID.
>>> * Group - a collection of users and other groups. The intent is that
>>> privileges can be either assigned to individual users, groups or roles.
>>> Groups have a hierarchical structure and can be a member of zero or more
>>> other groups.
>>> * Role - represent a particular real life role of a user. Roles are
>>> defined as a three-way relationship between user, group and role type.
>> For
>>> example, user "Bob" might be an "accounts clerk" (the role type) at "head
>>> office" (the group). It is also possible for a user to have a role in a
>>> group, without being a member of that group.
>>>
>>>
>>>
>>> [1] https://issues.apache.org/**jira/browse/DELTASPIKE-76<
>> https://issues.apache.org/jira/browse/DELTASPIKE-76>
>>> [2] https://github.com/seam/**security/blob/develop/api/src/**
>>> main/java/org/jboss/seam/**security/Identity.java<
>> https://github.com/seam/security/blob/develop/api/src/main/java/org/jboss/seam/security/Identity.java
>>>
>>
>>
>> --
>> Rudy De Busscher
>>
Re: [DISCUSS] Identity API
Posted by Gerhard Petracek <ge...@gmail.com>.
hi shane,
i'm sure there are good reasons for most/all details. since i don't know
them, i just list the topics which come to my mind after reading the
provided information.
#tryLogin
i don't see the need for it compared to #login, because it can be done by
users easily (if needed).
at least at the beginning i would keep the api as minimal as possible. we
can add further parts based on concrete and important use-cases.
#login
uses string as return type instead of an enum.
in >general< : we should define a general rule for the usage of exceptions
which should be used by most deltaspike apis.
#quietLogin
>is method is intended to be used primarily as an internal API call
... then it shouldn't be part of the api. (that's related to a 2nd topic.
see api vs. spi)
#hasRole
>Checks if the authenticated user is a member of the specified role.
#checkRole
>Checks that the current authenticated user is a member of the specified
role.
#hasRole and #checkRole look very similar - if the exception is the only
difference: see my comment about #tryLogin. at least we should think about
unified names.
#addXyz
that's a general topic we have to discuss. in myfaces codi we have all
"write-methods" which aren't intended to be used frequently in the spi to
keep the api simple and small ([1] and [2] illustrate it in case of the
initial refactoring of @Secured for deltaspike - the naming convention is
always Editable[ApiName]).
@type "string" in the api:
i know - it's easy, generic and sometimes just needed to use strings.
however, at least we should re-visit them and just use them if there is no
useful alternative.
@rudy:
i agree with you.
for v0.1 we always started to discuss the basic use-cases and requirements
and afterwards the concrete api.
>imo< that leads to a better api and we should try to keep this approach
(for sure the content of v0.1 was easier).
regards,
gerhard
[1] http://s.apache.org/4sL
[2] http://s.apache.org/j2E
2012/2/13 Rudy De Busscher <rd...@gmail.com>
> Hi,
>
> I think it is also important that you can work with permissions. It is
> much more fine grained then roles but more flexible. It becomes much easier
> to change what a group of people can do, even without changing the code. I
> never use roles in an application, only permissions.
>
> I'm not saying we need to do the implementation of it by default in
> deltaspike but should have at least something like
> boolean hasPermission(String permissionName)
> in the identity API.
>
>
> my idea about security.
>
>
> regards
> Rudy
>
> On 12h February 2012 23:33, Shane Bryzak <sb...@redhat.com> wrote:
>
> > I've created an umbrella issue to track the work we do on the security
> > module [1], and the first task is to review and discuss the Identity API.
> > This API forms the core of the security module, and all other features
> > build on top of it to implement a complete security framework.
> >
> > The Identity interface represents an individual, current user of an
> > application and its implementation must be session-scoped to provide
> > security services for the entirety of a user's session. I'm going to
> paste
> > the (slightly modified) code from Seam as it's mostly well documented,
> and
> > so we have a baseline from which to further discuss:
> >
> > public interface Identity {
> > public static final String RESPONSE_LOGIN_SUCCESS = "success";
> > public static final String RESPONSE_LOGIN_FAILED = "failed";
> > public static final String RESPONSE_LOGIN_EXCEPTION = "exception";
> > /**
> > * Simple check that returns true if the user is logged in, without
> > attempting to authenticate
> > *
> > * @return true if the user is logged in
> > */
> > @Secures
> > @LoggedIn
> > boolean isLoggedIn();
> > /**
> > * Returns true if the currently authenticated user has provided their
> > correct credentials
> > * within the verification window configured by the application.
> > *
> > * @return
> > */
> > boolean isVerified();
> > /**
> > * Will attempt to authenticate quietly if the user's credentials are set
> > and they haven't
> > * authenticated already. A quiet authentication doesn't throw any
> > exceptions if authentication
> > * fails.
> > *
> > * @return true if the user is logged in, false otherwise
> > */
> > boolean tryLogin();
> > /**
> > * Returns the currently authenticated user
> > *
> > * @return
> > */
> > User getUser();
> >
> > /**
> > * Attempts to authenticate the user. This method raises the following
> > events in response
> > * to whether authentication is successful or not. The following events
> may
> > be raised
> > * during the call to login():
> > * <p/>
> > * org.apache.deltaspike.**security.events.LoggedInEvent - raised when
> > authentication is successful
> > * org.apache.deltaspike.**security.events.**LoginFailedEvent - raised
> > when authentication fails
> > * org.apache.deltaspike.**security.events.**AlreadyLoggedInEvent - raised
> > if the user is already authenticated
> > *
> > * @return String returns RESPONSE_LOGIN_SUCCESS if user is authenticated,
> > * RESPONSE_LOGIN_FAILED if authentication failed, or
> > * RESPONSE_LOGIN_EXCEPTION if an exception occurred during
> authentication.
> > These response
> > * codes may be used to control user navigation. For deferred
> > authentication methods, such as Open ID
> > * the login() method will return an immediate result of
> > RESPONSE_LOGIN_FAILED (and subsequently fire
> > * a LoginFailedEvent) however in these conditions it is the
> responsibility
> > of the Authenticator
> > * implementation to take over the authentication process, for example by
> > redirecting the user to
> > * another authentication service.
> > *
> > */
> > String login();
> > /**
> > * Attempts a quiet login, suppressing any login exceptions and not
> creating
> > * any faces messages. This method is intended to be used primarily as an
> > * internal API call, however has been made public for convenience.
> > */
> > void quietLogin();
> > /**
> > * Logs out the currently authenticated user
> > */
> > void logout();
> > /**
> > * Checks if the authenticated user is a member of the specified role.
> > *
> > * @param role String The name of the role to check * @param group String
> > the name of the group in which the role exists
> > * @return boolean True if the user is a member of the specified role
> > */
> > boolean hasRole(String role, String group);
> > /**
> > * Adds a role to the authenticated user. If the user is not logged in,
> > * the role will be added to a list of roles that will be granted to the
> > * user upon successful authentication, but only during the authentication
> > * process.
> > *
> > * @param role The name of the role to add * @param group The name of the
> > group in which to create the role
> > */
> > boolean addRole(String role, String group);
> > /**
> > * Checks if the authenticated user is a member of the specified group
> > *
> > * @param name The name of the group
> > * @return true if the user is a member of the group
> > */
> > boolean inGroup(String name);
> > /**
> > * Adds the user to the specified group. See hasRole() for semantics in
> > * relationship to the authenticated status of the user.
> > *
> > * @param name The name of the group
> > * @return true if the group was successfully added
> > */
> > boolean addGroup(String name);
> > /**
> > * Removes the currently authenticated user from the specified group
> > *
> > * @param name The name of the group
> > */
> > void removeGroup(String name);
> > /**
> > * Removes a role from the authenticated user
> > *
> > * @param role The name of the role to remove
> > */
> > void removeRole(String role, String group);
> > /**
> > * Checks that the current authenticated user is a member of
> > * the specified role.
> > *
> > * @param role String The name of the role to check
> > * @throws AuthorizationException if the authenticated user is not a
> member
> > of the role
> > */
> > void checkRole(String role, String group);
> > /**
> > * @param group
> > * @param groupType
> > */
> > void checkGroup(String group);
> > /**
> > * Returns an immutable set containing all the current user's granted
> roles
> > *
> > * @return
> > */
> > Set<Role> getRoles();
> > /**
> > * Returns an immutable set containing all the current user's group
> > memberships
> > *
> > * @return
> > */
> > Set<Group> getGroups();
> > }
> >
> >
> > Some particular points to review:
> >
> > 1. Should we attempt to use the security classes provided by Java SE,
> such
> > as Principal, Subject, etc or use our own User API - this will affect
> what
> > is returned by the getUser() method above. Keep in note that we will
> have
> > at least a simple User/Role/Group API as part of Identity Management. In
> > Seam 2 we originally used the built-in Java classes (which made more
> sense
> > because the authentication process was based on JAAS), however in Seam 3
> > (where we removed JAAS because it doesn't support asynchronous
> > authentication as required by OpenID etc) we based the security module on
> > the PicketLink User API. IMHO, this is not a critical choice either way
> -
> > the Java security classes have the advantage of being familiar to many
> > users, while on the flipside if we provide our own User API we have the
> > flexibility of being able to extend it in the future. So both options
> have
> > their own advantages.
> >
> > 2. The addRole() and addGroup() methods are intended to be only used
> > during the authentication process to grant particular user memberships
> for
> > the duration of their session only. A few users have found this a little
> > confusing, as they were using identity management, and expected these
> > methods to grant a permanent membership for the user. One solution may
> be
> > to simply rename these methods to addSessionRole() and addSessionGroup()
> -
> > thoughts?
> >
> > 3. We're touching a little bit on the authorization API here also with
> the
> > hasRole() / inGroup() methods. I'll provide a quick description of these
> > core security API concepts here:
> >
> > * User - represents an individual user of an application. Can either be
> > human or non-human, and can represent either a user managed locally (i.e.
> > through the IDM API) or an externally authenticated User, such as one
> that
> > has logged in with OpenID.
> > * Group - a collection of users and other groups. The intent is that
> > privileges can be either assigned to individual users, groups or roles.
> > Groups have a hierarchical structure and can be a member of zero or more
> > other groups.
> > * Role - represent a particular real life role of a user. Roles are
> > defined as a three-way relationship between user, group and role type.
> For
> > example, user "Bob" might be an "accounts clerk" (the role type) at "head
> > office" (the group). It is also possible for a user to have a role in a
> > group, without being a member of that group.
> >
> >
> >
> > [1] https://issues.apache.org/**jira/browse/DELTASPIKE-76<
> https://issues.apache.org/jira/browse/DELTASPIKE-76>
> > [2] https://github.com/seam/**security/blob/develop/api/src/**
> > main/java/org/jboss/seam/**security/Identity.java<
> https://github.com/seam/security/blob/develop/api/src/main/java/org/jboss/seam/security/Identity.java
> >
> >
>
>
>
> --
> Rudy De Busscher
>
Re: [DISCUSS] Identity API
Posted by Rudy De Busscher <rd...@gmail.com>.
Hi,
I think it is also important that you can work with permissions. It is
much more fine grained then roles but more flexible. It becomes much easier
to change what a group of people can do, even without changing the code. I
never use roles in an application, only permissions.
I'm not saying we need to do the implementation of it by default in
deltaspike but should have at least something like
boolean hasPermission(String permissionName)
in the identity API.
my idea about security.
regards
Rudy
On 12h February 2012 23:33, Shane Bryzak <sb...@redhat.com> wrote:
> I've created an umbrella issue to track the work we do on the security
> module [1], and the first task is to review and discuss the Identity API.
> This API forms the core of the security module, and all other features
> build on top of it to implement a complete security framework.
>
> The Identity interface represents an individual, current user of an
> application and its implementation must be session-scoped to provide
> security services for the entirety of a user's session. I'm going to paste
> the (slightly modified) code from Seam as it's mostly well documented, and
> so we have a baseline from which to further discuss:
>
> public interface Identity {
> public static final String RESPONSE_LOGIN_SUCCESS = "success";
> public static final String RESPONSE_LOGIN_FAILED = "failed";
> public static final String RESPONSE_LOGIN_EXCEPTION = "exception";
> /**
> * Simple check that returns true if the user is logged in, without
> attempting to authenticate
> *
> * @return true if the user is logged in
> */
> @Secures
> @LoggedIn
> boolean isLoggedIn();
> /**
> * Returns true if the currently authenticated user has provided their
> correct credentials
> * within the verification window configured by the application.
> *
> * @return
> */
> boolean isVerified();
> /**
> * Will attempt to authenticate quietly if the user's credentials are set
> and they haven't
> * authenticated already. A quiet authentication doesn't throw any
> exceptions if authentication
> * fails.
> *
> * @return true if the user is logged in, false otherwise
> */
> boolean tryLogin();
> /**
> * Returns the currently authenticated user
> *
> * @return
> */
> User getUser();
>
> /**
> * Attempts to authenticate the user. This method raises the following
> events in response
> * to whether authentication is successful or not. The following events may
> be raised
> * during the call to login():
> * <p/>
> * org.apache.deltaspike.**security.events.LoggedInEvent - raised when
> authentication is successful
> * org.apache.deltaspike.**security.events.**LoginFailedEvent - raised
> when authentication fails
> * org.apache.deltaspike.**security.events.**AlreadyLoggedInEvent - raised
> if the user is already authenticated
> *
> * @return String returns RESPONSE_LOGIN_SUCCESS if user is authenticated,
> * RESPONSE_LOGIN_FAILED if authentication failed, or
> * RESPONSE_LOGIN_EXCEPTION if an exception occurred during authentication.
> These response
> * codes may be used to control user navigation. For deferred
> authentication methods, such as Open ID
> * the login() method will return an immediate result of
> RESPONSE_LOGIN_FAILED (and subsequently fire
> * a LoginFailedEvent) however in these conditions it is the responsibility
> of the Authenticator
> * implementation to take over the authentication process, for example by
> redirecting the user to
> * another authentication service.
> *
> */
> String login();
> /**
> * Attempts a quiet login, suppressing any login exceptions and not creating
> * any faces messages. This method is intended to be used primarily as an
> * internal API call, however has been made public for convenience.
> */
> void quietLogin();
> /**
> * Logs out the currently authenticated user
> */
> void logout();
> /**
> * Checks if the authenticated user is a member of the specified role.
> *
> * @param role String The name of the role to check * @param group String
> the name of the group in which the role exists
> * @return boolean True if the user is a member of the specified role
> */
> boolean hasRole(String role, String group);
> /**
> * Adds a role to the authenticated user. If the user is not logged in,
> * the role will be added to a list of roles that will be granted to the
> * user upon successful authentication, but only during the authentication
> * process.
> *
> * @param role The name of the role to add * @param group The name of the
> group in which to create the role
> */
> boolean addRole(String role, String group);
> /**
> * Checks if the authenticated user is a member of the specified group
> *
> * @param name The name of the group
> * @return true if the user is a member of the group
> */
> boolean inGroup(String name);
> /**
> * Adds the user to the specified group. See hasRole() for semantics in
> * relationship to the authenticated status of the user.
> *
> * @param name The name of the group
> * @return true if the group was successfully added
> */
> boolean addGroup(String name);
> /**
> * Removes the currently authenticated user from the specified group
> *
> * @param name The name of the group
> */
> void removeGroup(String name);
> /**
> * Removes a role from the authenticated user
> *
> * @param role The name of the role to remove
> */
> void removeRole(String role, String group);
> /**
> * Checks that the current authenticated user is a member of
> * the specified role.
> *
> * @param role String The name of the role to check
> * @throws AuthorizationException if the authenticated user is not a member
> of the role
> */
> void checkRole(String role, String group);
> /**
> * @param group
> * @param groupType
> */
> void checkGroup(String group);
> /**
> * Returns an immutable set containing all the current user's granted roles
> *
> * @return
> */
> Set<Role> getRoles();
> /**
> * Returns an immutable set containing all the current user's group
> memberships
> *
> * @return
> */
> Set<Group> getGroups();
> }
>
>
> Some particular points to review:
>
> 1. Should we attempt to use the security classes provided by Java SE, such
> as Principal, Subject, etc or use our own User API - this will affect what
> is returned by the getUser() method above. Keep in note that we will have
> at least a simple User/Role/Group API as part of Identity Management. In
> Seam 2 we originally used the built-in Java classes (which made more sense
> because the authentication process was based on JAAS), however in Seam 3
> (where we removed JAAS because it doesn't support asynchronous
> authentication as required by OpenID etc) we based the security module on
> the PicketLink User API. IMHO, this is not a critical choice either way -
> the Java security classes have the advantage of being familiar to many
> users, while on the flipside if we provide our own User API we have the
> flexibility of being able to extend it in the future. So both options have
> their own advantages.
>
> 2. The addRole() and addGroup() methods are intended to be only used
> during the authentication process to grant particular user memberships for
> the duration of their session only. A few users have found this a little
> confusing, as they were using identity management, and expected these
> methods to grant a permanent membership for the user. One solution may be
> to simply rename these methods to addSessionRole() and addSessionGroup() -
> thoughts?
>
> 3. We're touching a little bit on the authorization API here also with the
> hasRole() / inGroup() methods. I'll provide a quick description of these
> core security API concepts here:
>
> * User - represents an individual user of an application. Can either be
> human or non-human, and can represent either a user managed locally (i.e.
> through the IDM API) or an externally authenticated User, such as one that
> has logged in with OpenID.
> * Group - a collection of users and other groups. The intent is that
> privileges can be either assigned to individual users, groups or roles.
> Groups have a hierarchical structure and can be a member of zero or more
> other groups.
> * Role - represent a particular real life role of a user. Roles are
> defined as a three-way relationship between user, group and role type. For
> example, user "Bob" might be an "accounts clerk" (the role type) at "head
> office" (the group). It is also possible for a user to have a role in a
> group, without being a member of that group.
>
>
>
> [1] https://issues.apache.org/**jira/browse/DELTASPIKE-76<https://issues.apache.org/jira/browse/DELTASPIKE-76>
> [2] https://github.com/seam/**security/blob/develop/api/src/**
> main/java/org/jboss/seam/**security/Identity.java<https://github.com/seam/security/blob/develop/api/src/main/java/org/jboss/seam/security/Identity.java>
>
--
Rudy De Busscher
Re: [DISCUSS] Identity API
Posted by Shane Bryzak <sb...@redhat.com>.
On 13/02/12 19:47, Boleslaw Dawidowicz wrote:
> On Feb 12, 2012, at 11:33 PM, Shane Bryzak wrote:
>
>> Some particular points to review:
>>
>> 1. Should we attempt to use the security classes provided by Java SE, such as Principal, Subject, etc or use our own User API - this will affect what is returned by the getUser() method above. Keep in note that we will have at least a simple User/Role/Group API as part of Identity Management. In Seam 2 we originally used the built-in Java classes (which made more sense because the authentication process was based on JAAS), however in Seam 3 (where we removed JAAS because it doesn't support asynchronous authentication as required by OpenID etc) we based the security module on the PicketLink User API. IMHO, this is not a critical choice either way - the Java security classes have the advantage of being familiar to many users, while on the flipside if we provide our own User API we have the flexibility of being able to extend it in the future. So both options have their own advantages.
>>
>> 2. The addRole() and addGroup() methods are intended to be only used during the authentication process to grant particular user memberships for the duration of their session only. A few users have found this a little confusing, as they were using identity management, and expected these methods to grant a permanent membership for the user. One solution may be to simply rename these methods to addSessionRole() and addSessionGroup() - thoughts?
> This implies question if API related to authentication and IDM operations should be de coupled or not - as this would be side effect of relying on Java SEE security classes.
My +1 is for providing our own user API, and not depending on the Java
SE security classes. I think this will reduce confusion for developers
who can simply work with the User, Group and Role objects rather than
trying to understand Principal, Subject, etc.
>
>> 3. We're touching a little bit on the authorization API here also with the hasRole() / inGroup() methods. I'll provide a quick description of these core security API concepts here:
>>
>> * User - represents an individual user of an application. Can either be human or non-human, and can represent either a user managed locally (i.e. through the IDM API) or an externally authenticated User, such as one that has logged in with OpenID.
>> * Group - a collection of users and other groups. The intent is that privileges can be either assigned to individual users, groups or roles. Groups have a hierarchical structure and can be a member of zero or more other groups.
> I would personally vote for having clear three structure - so group can belong to zero (under root) or 1 other group (parent). Having flexible hierarchy leads to fairly complex structure. This can easily lead to more cluttered API. From my observations tree structure covers 95% of use cases and many organizations need to integrate with their LDAP which is exactly this kind of shape.
I'm happy to have this kind of restrictriction on the group hierarchy, I
agree it will reduce problems in many environments.
>
>> * Role - represent a particular real life role of a user. Roles are defined as a three-way relationship between user, group and role type. For example, user "Bob" might be an "accounts clerk" (the role type) at "head office" (the group). It is also possible for a user to have a role in a group, without being a member of that group.
> Does it imply having separate notion of membership between user and group? For me it is the same as "Bob" being "member" (the role type) at "employees" (the group). One thing less to cover in the API which can make it simpler.
If you're referring to the IdentityObjectRelationship SPI class that we
currently have in PicketLink IDM 1.x, then my +1 is to not provide an
SPI and instead handle this kind of thing transparently at the
IdentityStore level.
>
>>
>>
>> [1] https://issues.apache.org/jira/browse/DELTASPIKE-76
>> [2] https://github.com/seam/security/blob/develop/api/src/main/java/org/jboss/seam/security/Identity.java
Re: [DISCUSS] Identity API
Posted by Boleslaw Dawidowicz <bo...@gmail.com>.
We are both with Shane on the JSR 351 EG and spec is really high level having more big use cases in mind. Think federation, healthcare, permissions to see patients data based on some complex conditions, inter org agreements around auth/authz and etc.
Check:
http://java.net/projects/identity-api-spec/pages/Home
http://java.net/projects/identity-api-spec/pages/UseCases
I'm not saying that DeltaSpike should not align with it - it should where possible. Just making a point that DeltaSpike is probably more web application developer focused and interested in providing simple and usable APIs.
Just to give an example. As far as I remember initial discussion around Attribute interface it was considered that it can have "anything java" as a possible value with an option to reference separate service to retrieve the actual value. Additional it will probably have whole separate metadata layer. It perfectly makes sense for use cases that JSR 351 aims to cover but I'm not sure this is something people would want to deal with in DeltaSpike APIs. It is like dealing directly with current JAAS/JACC layer in web security.
Early Attribute interface proposal here:
http://java.net/projects/identity-api-spec/lists/jsr351-experts/archive/2012-01/message/35
related discussion:
http://java.net/downloads/identity-api-spec/minutes/minutes-jsr351-jan24-2012.txt
Again - not saying DeltaSpike shouldn't align where it makes sense. It should.
Bolek
On Feb 13, 2012, at 4:00 PM, Antoine Sabot-Durand wrote:
> Shouldn't we try to contact JSR 351 EG[1] to brainstorm with them and try to see if our identity management module could implement this spec ?
>
>
> [1] http://jcp.org/en/jsr/detail?id=351
>
> Antoine SABOT-DURAND
>
>
> Le 13 févr. 2012 à 11:19, Gerhard Petracek a écrit :
>
>> @supporting tree-structures:
>> +1 (that was one reason for my comment [1] about the usage of strings.)
>>
>> @definition of a role:
>> imo it's easier to collect basic use-cases and ideas in a wiki and discuss
>> them step by step (>similar< to [2]).
>> it also provides an overview of the basic decisions and in- and excluded
>> parts.
>>
>> regards,
>> gerhard
>>
>> [1] http://s.apache.org/Myi
>> [2]
>> https://cwiki.apache.org/confluence/display/DeltaSpike/SE+Feature+Ranking
>>
>>
>>
>> 2012/2/13 Boleslaw Dawidowicz <bo...@gmail.com>
>>
>>>
>>> On Feb 12, 2012, at 11:33 PM, Shane Bryzak wrote:
>>>
>>>> Some particular points to review:
>>>>
>>>> 1. Should we attempt to use the security classes provided by Java SE,
>>> such as Principal, Subject, etc or use our own User API - this will affect
>>> what is returned by the getUser() method above. Keep in note that we will
>>> have at least a simple User/Role/Group API as part of Identity Management.
>>> In Seam 2 we originally used the built-in Java classes (which made more
>>> sense because the authentication process was based on JAAS), however in
>>> Seam 3 (where we removed JAAS because it doesn't support asynchronous
>>> authentication as required by OpenID etc) we based the security module on
>>> the PicketLink User API. IMHO, this is not a critical choice either way -
>>> the Java security classes have the advantage of being familiar to many
>>> users, while on the flipside if we provide our own User API we have the
>>> flexibility of being able to extend it in the future. So both options have
>>> their own advantages.
>>>>
>>>> 2. The addRole() and addGroup() methods are intended to be only used
>>> during the authentication process to grant particular user memberships for
>>> the duration of their session only. A few users have found this a little
>>> confusing, as they were using identity management, and expected these
>>> methods to grant a permanent membership for the user. One solution may be
>>> to simply rename these methods to addSessionRole() and addSessionGroup() -
>>> thoughts?
>>>
>>> This implies question if API related to authentication and IDM operations
>>> should be de coupled or not - as this would be side effect of relying on
>>> Java SEE security classes.
>>>
>>>>
>>>> 3. We're touching a little bit on the authorization API here also with
>>> the hasRole() / inGroup() methods. I'll provide a quick description of
>>> these core security API concepts here:
>>>>
>>>> * User - represents an individual user of an application. Can either be
>>> human or non-human, and can represent either a user managed locally (i.e.
>>> through the IDM API) or an externally authenticated User, such as one that
>>> has logged in with OpenID.
>>>> * Group - a collection of users and other groups. The intent is that
>>> privileges can be either assigned to individual users, groups or roles.
>>> Groups have a hierarchical structure and can be a member of zero or more
>>> other groups.
>>>
>>> I would personally vote for having clear three structure - so group can
>>> belong to zero (under root) or 1 other group (parent). Having flexible
>>> hierarchy leads to fairly complex structure. This can easily lead to more
>>> cluttered API. From my observations tree structure covers 95% of use cases
>>> and many organizations need to integrate with their LDAP which is exactly
>>> this kind of shape.
>>>
>>>> * Role - represent a particular real life role of a user. Roles are
>>> defined as a three-way relationship between user, group and role type. For
>>> example, user "Bob" might be an "accounts clerk" (the role type) at "head
>>> office" (the group). It is also possible for a user to have a role in a
>>> group, without being a member of that group.
>>>
>>> Does it imply having separate notion of membership between user and group?
>>> For me it is the same as "Bob" being "member" (the role type) at
>>> "employees" (the group). One thing less to cover in the API which can make
>>> it simpler.
>>>
>>>>
>>>>
>>>>
>>>> [1] https://issues.apache.org/jira/browse/DELTASPIKE-76
>>>> [2]
>>> https://github.com/seam/security/blob/develop/api/src/main/java/org/jboss/seam/security/Identity.java
>>>
>>>
>
Re: [DISCUSS] Identity API
Posted by Shane Bryzak <sb...@redhat.com>.
On 14/02/12 02:11, Matt Benson wrote:
> On Mon, Feb 13, 2012 at 9:00 AM, Antoine Sabot-Durand
> <an...@sabot-durand.net> wrote:
>> Shouldn't we try to contact JSR 351 EG[1] to brainstorm with them and try to see if our identity management module could implement this spec ?
> I thought this had come up before, but Syncope [1] has recently been
> voted as an incubating project as well; it may pay to work with them,
> though I would hope that a JSR-351 implementation might be among their
> goals as well.
I think I mentioned this already, but it would be no problem to provide
an IdentityStore implementation that integrates with a Syncope back-end,
and I agree it would be great to have this feature.
>
> Matt
>
>>
>> [1] http://jcp.org/en/jsr/detail?id=351
>>
>> Antoine SABOT-DURAND
>>
>>
>> Le 13 févr. 2012 à 11:19, Gerhard Petracek a écrit :
>>
>>> @supporting tree-structures:
>>> +1 (that was one reason for my comment [1] about the usage of strings.)
>>>
>>> @definition of a role:
>>> imo it's easier to collect basic use-cases and ideas in a wiki and discuss
>>> them step by step (>similar< to [2]).
>>> it also provides an overview of the basic decisions and in- and excluded
>>> parts.
>>>
>>> regards,
>>> gerhard
>>>
>>> [1] http://s.apache.org/Myi
>>> [2]
>>> https://cwiki.apache.org/confluence/display/DeltaSpike/SE+Feature+Ranking
>>>
>>>
>>>
>>> 2012/2/13 Boleslaw Dawidowicz<bo...@gmail.com>
>>>
>>>> On Feb 12, 2012, at 11:33 PM, Shane Bryzak wrote:
>>>>
>>>>> Some particular points to review:
>>>>>
>>>>> 1. Should we attempt to use the security classes provided by Java SE,
>>>> such as Principal, Subject, etc or use our own User API - this will affect
>>>> what is returned by the getUser() method above. Keep in note that we will
>>>> have at least a simple User/Role/Group API as part of Identity Management.
>>>> In Seam 2 we originally used the built-in Java classes (which made more
>>>> sense because the authentication process was based on JAAS), however in
>>>> Seam 3 (where we removed JAAS because it doesn't support asynchronous
>>>> authentication as required by OpenID etc) we based the security module on
>>>> the PicketLink User API. IMHO, this is not a critical choice either way -
>>>> the Java security classes have the advantage of being familiar to many
>>>> users, while on the flipside if we provide our own User API we have the
>>>> flexibility of being able to extend it in the future. So both options have
>>>> their own advantages.
>>>>> 2. The addRole() and addGroup() methods are intended to be only used
>>>> during the authentication process to grant particular user memberships for
>>>> the duration of their session only. A few users have found this a little
>>>> confusing, as they were using identity management, and expected these
>>>> methods to grant a permanent membership for the user. One solution may be
>>>> to simply rename these methods to addSessionRole() and addSessionGroup() -
>>>> thoughts?
>>>>
>>>> This implies question if API related to authentication and IDM operations
>>>> should be de coupled or not - as this would be side effect of relying on
>>>> Java SEE security classes.
>>>>
>>>>> 3. We're touching a little bit on the authorization API here also with
>>>> the hasRole() / inGroup() methods. I'll provide a quick description of
>>>> these core security API concepts here:
>>>>> * User - represents an individual user of an application. Can either be
>>>> human or non-human, and can represent either a user managed locally (i.e.
>>>> through the IDM API) or an externally authenticated User, such as one that
>>>> has logged in with OpenID.
>>>>> * Group - a collection of users and other groups. The intent is that
>>>> privileges can be either assigned to individual users, groups or roles.
>>>> Groups have a hierarchical structure and can be a member of zero or more
>>>> other groups.
>>>>
>>>> I would personally vote for having clear three structure - so group can
>>>> belong to zero (under root) or 1 other group (parent). Having flexible
>>>> hierarchy leads to fairly complex structure. This can easily lead to more
>>>> cluttered API. From my observations tree structure covers 95% of use cases
>>>> and many organizations need to integrate with their LDAP which is exactly
>>>> this kind of shape.
>>>>
>>>>> * Role - represent a particular real life role of a user. Roles are
>>>> defined as a three-way relationship between user, group and role type. For
>>>> example, user "Bob" might be an "accounts clerk" (the role type) at "head
>>>> office" (the group). It is also possible for a user to have a role in a
>>>> group, without being a member of that group.
>>>>
>>>> Does it imply having separate notion of membership between user and group?
>>>> For me it is the same as "Bob" being "member" (the role type) at
>>>> "employees" (the group). One thing less to cover in the API which can make
>>>> it simpler.
>>>>
>>>>>
>>>>>
>>>>> [1] https://issues.apache.org/jira/browse/DELTASPIKE-76
>>>>> [2]
>>>> https://github.com/seam/security/blob/develop/api/src/main/java/org/jboss/seam/security/Identity.java
>>>>
>>>>
Re: [DISCUSS] Identity API
Posted by Matt Benson <gu...@gmail.com>.
On Mon, Feb 13, 2012 at 9:00 AM, Antoine Sabot-Durand
<an...@sabot-durand.net> wrote:
> Shouldn't we try to contact JSR 351 EG[1] to brainstorm with them and try to see if our identity management module could implement this spec ?
I thought this had come up before, but Syncope [1] has recently been
voted as an incubating project as well; it may pay to work with them,
though I would hope that a JSR-351 implementation might be among their
goals as well.
Matt
>
>
> [1] http://jcp.org/en/jsr/detail?id=351
>
> Antoine SABOT-DURAND
>
>
> Le 13 févr. 2012 à 11:19, Gerhard Petracek a écrit :
>
>> @supporting tree-structures:
>> +1 (that was one reason for my comment [1] about the usage of strings.)
>>
>> @definition of a role:
>> imo it's easier to collect basic use-cases and ideas in a wiki and discuss
>> them step by step (>similar< to [2]).
>> it also provides an overview of the basic decisions and in- and excluded
>> parts.
>>
>> regards,
>> gerhard
>>
>> [1] http://s.apache.org/Myi
>> [2]
>> https://cwiki.apache.org/confluence/display/DeltaSpike/SE+Feature+Ranking
>>
>>
>>
>> 2012/2/13 Boleslaw Dawidowicz <bo...@gmail.com>
>>
>>>
>>> On Feb 12, 2012, at 11:33 PM, Shane Bryzak wrote:
>>>
>>>> Some particular points to review:
>>>>
>>>> 1. Should we attempt to use the security classes provided by Java SE,
>>> such as Principal, Subject, etc or use our own User API - this will affect
>>> what is returned by the getUser() method above. Keep in note that we will
>>> have at least a simple User/Role/Group API as part of Identity Management.
>>> In Seam 2 we originally used the built-in Java classes (which made more
>>> sense because the authentication process was based on JAAS), however in
>>> Seam 3 (where we removed JAAS because it doesn't support asynchronous
>>> authentication as required by OpenID etc) we based the security module on
>>> the PicketLink User API. IMHO, this is not a critical choice either way -
>>> the Java security classes have the advantage of being familiar to many
>>> users, while on the flipside if we provide our own User API we have the
>>> flexibility of being able to extend it in the future. So both options have
>>> their own advantages.
>>>>
>>>> 2. The addRole() and addGroup() methods are intended to be only used
>>> during the authentication process to grant particular user memberships for
>>> the duration of their session only. A few users have found this a little
>>> confusing, as they were using identity management, and expected these
>>> methods to grant a permanent membership for the user. One solution may be
>>> to simply rename these methods to addSessionRole() and addSessionGroup() -
>>> thoughts?
>>>
>>> This implies question if API related to authentication and IDM operations
>>> should be de coupled or not - as this would be side effect of relying on
>>> Java SEE security classes.
>>>
>>>>
>>>> 3. We're touching a little bit on the authorization API here also with
>>> the hasRole() / inGroup() methods. I'll provide a quick description of
>>> these core security API concepts here:
>>>>
>>>> * User - represents an individual user of an application. Can either be
>>> human or non-human, and can represent either a user managed locally (i.e.
>>> through the IDM API) or an externally authenticated User, such as one that
>>> has logged in with OpenID.
>>>> * Group - a collection of users and other groups. The intent is that
>>> privileges can be either assigned to individual users, groups or roles.
>>> Groups have a hierarchical structure and can be a member of zero or more
>>> other groups.
>>>
>>> I would personally vote for having clear three structure - so group can
>>> belong to zero (under root) or 1 other group (parent). Having flexible
>>> hierarchy leads to fairly complex structure. This can easily lead to more
>>> cluttered API. From my observations tree structure covers 95% of use cases
>>> and many organizations need to integrate with their LDAP which is exactly
>>> this kind of shape.
>>>
>>>> * Role - represent a particular real life role of a user. Roles are
>>> defined as a three-way relationship between user, group and role type. For
>>> example, user "Bob" might be an "accounts clerk" (the role type) at "head
>>> office" (the group). It is also possible for a user to have a role in a
>>> group, without being a member of that group.
>>>
>>> Does it imply having separate notion of membership between user and group?
>>> For me it is the same as "Bob" being "member" (the role type) at
>>> "employees" (the group). One thing less to cover in the API which can make
>>> it simpler.
>>>
>>>>
>>>>
>>>>
>>>> [1] https://issues.apache.org/jira/browse/DELTASPIKE-76
>>>> [2]
>>> https://github.com/seam/security/blob/develop/api/src/main/java/org/jboss/seam/security/Identity.java
>>>
>>>
>
Re: [DISCUSS] Identity API
Posted by Antoine Sabot-Durand <an...@sabot-durand.net>.
Shouldn't we try to contact JSR 351 EG[1] to brainstorm with them and try to see if our identity management module could implement this spec ?
[1] http://jcp.org/en/jsr/detail?id=351
Antoine SABOT-DURAND
Le 13 févr. 2012 à 11:19, Gerhard Petracek a écrit :
> @supporting tree-structures:
> +1 (that was one reason for my comment [1] about the usage of strings.)
>
> @definition of a role:
> imo it's easier to collect basic use-cases and ideas in a wiki and discuss
> them step by step (>similar< to [2]).
> it also provides an overview of the basic decisions and in- and excluded
> parts.
>
> regards,
> gerhard
>
> [1] http://s.apache.org/Myi
> [2]
> https://cwiki.apache.org/confluence/display/DeltaSpike/SE+Feature+Ranking
>
>
>
> 2012/2/13 Boleslaw Dawidowicz <bo...@gmail.com>
>
>>
>> On Feb 12, 2012, at 11:33 PM, Shane Bryzak wrote:
>>
>>> Some particular points to review:
>>>
>>> 1. Should we attempt to use the security classes provided by Java SE,
>> such as Principal, Subject, etc or use our own User API - this will affect
>> what is returned by the getUser() method above. Keep in note that we will
>> have at least a simple User/Role/Group API as part of Identity Management.
>> In Seam 2 we originally used the built-in Java classes (which made more
>> sense because the authentication process was based on JAAS), however in
>> Seam 3 (where we removed JAAS because it doesn't support asynchronous
>> authentication as required by OpenID etc) we based the security module on
>> the PicketLink User API. IMHO, this is not a critical choice either way -
>> the Java security classes have the advantage of being familiar to many
>> users, while on the flipside if we provide our own User API we have the
>> flexibility of being able to extend it in the future. So both options have
>> their own advantages.
>>>
>>> 2. The addRole() and addGroup() methods are intended to be only used
>> during the authentication process to grant particular user memberships for
>> the duration of their session only. A few users have found this a little
>> confusing, as they were using identity management, and expected these
>> methods to grant a permanent membership for the user. One solution may be
>> to simply rename these methods to addSessionRole() and addSessionGroup() -
>> thoughts?
>>
>> This implies question if API related to authentication and IDM operations
>> should be de coupled or not - as this would be side effect of relying on
>> Java SEE security classes.
>>
>>>
>>> 3. We're touching a little bit on the authorization API here also with
>> the hasRole() / inGroup() methods. I'll provide a quick description of
>> these core security API concepts here:
>>>
>>> * User - represents an individual user of an application. Can either be
>> human or non-human, and can represent either a user managed locally (i.e.
>> through the IDM API) or an externally authenticated User, such as one that
>> has logged in with OpenID.
>>> * Group - a collection of users and other groups. The intent is that
>> privileges can be either assigned to individual users, groups or roles.
>> Groups have a hierarchical structure and can be a member of zero or more
>> other groups.
>>
>> I would personally vote for having clear three structure - so group can
>> belong to zero (under root) or 1 other group (parent). Having flexible
>> hierarchy leads to fairly complex structure. This can easily lead to more
>> cluttered API. From my observations tree structure covers 95% of use cases
>> and many organizations need to integrate with their LDAP which is exactly
>> this kind of shape.
>>
>>> * Role - represent a particular real life role of a user. Roles are
>> defined as a three-way relationship between user, group and role type. For
>> example, user "Bob" might be an "accounts clerk" (the role type) at "head
>> office" (the group). It is also possible for a user to have a role in a
>> group, without being a member of that group.
>>
>> Does it imply having separate notion of membership between user and group?
>> For me it is the same as "Bob" being "member" (the role type) at
>> "employees" (the group). One thing less to cover in the API which can make
>> it simpler.
>>
>>>
>>>
>>>
>>> [1] https://issues.apache.org/jira/browse/DELTASPIKE-76
>>> [2]
>> https://github.com/seam/security/blob/develop/api/src/main/java/org/jboss/seam/security/Identity.java
>>
>>
Re: [DISCUSS] Identity API
Posted by Gerhard Petracek <ge...@gmail.com>.
@supporting tree-structures:
+1 (that was one reason for my comment [1] about the usage of strings.)
@definition of a role:
imo it's easier to collect basic use-cases and ideas in a wiki and discuss
them step by step (>similar< to [2]).
it also provides an overview of the basic decisions and in- and excluded
parts.
regards,
gerhard
[1] http://s.apache.org/Myi
[2]
https://cwiki.apache.org/confluence/display/DeltaSpike/SE+Feature+Ranking
2012/2/13 Boleslaw Dawidowicz <bo...@gmail.com>
>
> On Feb 12, 2012, at 11:33 PM, Shane Bryzak wrote:
>
> > Some particular points to review:
> >
> > 1. Should we attempt to use the security classes provided by Java SE,
> such as Principal, Subject, etc or use our own User API - this will affect
> what is returned by the getUser() method above. Keep in note that we will
> have at least a simple User/Role/Group API as part of Identity Management.
> In Seam 2 we originally used the built-in Java classes (which made more
> sense because the authentication process was based on JAAS), however in
> Seam 3 (where we removed JAAS because it doesn't support asynchronous
> authentication as required by OpenID etc) we based the security module on
> the PicketLink User API. IMHO, this is not a critical choice either way -
> the Java security classes have the advantage of being familiar to many
> users, while on the flipside if we provide our own User API we have the
> flexibility of being able to extend it in the future. So both options have
> their own advantages.
> >
> > 2. The addRole() and addGroup() methods are intended to be only used
> during the authentication process to grant particular user memberships for
> the duration of their session only. A few users have found this a little
> confusing, as they were using identity management, and expected these
> methods to grant a permanent membership for the user. One solution may be
> to simply rename these methods to addSessionRole() and addSessionGroup() -
> thoughts?
>
> This implies question if API related to authentication and IDM operations
> should be de coupled or not - as this would be side effect of relying on
> Java SEE security classes.
>
> >
> > 3. We're touching a little bit on the authorization API here also with
> the hasRole() / inGroup() methods. I'll provide a quick description of
> these core security API concepts here:
> >
> > * User - represents an individual user of an application. Can either be
> human or non-human, and can represent either a user managed locally (i.e.
> through the IDM API) or an externally authenticated User, such as one that
> has logged in with OpenID.
> > * Group - a collection of users and other groups. The intent is that
> privileges can be either assigned to individual users, groups or roles.
> Groups have a hierarchical structure and can be a member of zero or more
> other groups.
>
> I would personally vote for having clear three structure - so group can
> belong to zero (under root) or 1 other group (parent). Having flexible
> hierarchy leads to fairly complex structure. This can easily lead to more
> cluttered API. From my observations tree structure covers 95% of use cases
> and many organizations need to integrate with their LDAP which is exactly
> this kind of shape.
>
> > * Role - represent a particular real life role of a user. Roles are
> defined as a three-way relationship between user, group and role type. For
> example, user "Bob" might be an "accounts clerk" (the role type) at "head
> office" (the group). It is also possible for a user to have a role in a
> group, without being a member of that group.
>
> Does it imply having separate notion of membership between user and group?
> For me it is the same as "Bob" being "member" (the role type) at
> "employees" (the group). One thing less to cover in the API which can make
> it simpler.
>
> >
> >
> >
> > [1] https://issues.apache.org/jira/browse/DELTASPIKE-76
> > [2]
> https://github.com/seam/security/blob/develop/api/src/main/java/org/jboss/seam/security/Identity.java
>
>
Re: [DISCUSS] Identity API
Posted by Boleslaw Dawidowicz <bo...@gmail.com>.
On Feb 12, 2012, at 11:33 PM, Shane Bryzak wrote:
> Some particular points to review:
>
> 1. Should we attempt to use the security classes provided by Java SE, such as Principal, Subject, etc or use our own User API - this will affect what is returned by the getUser() method above. Keep in note that we will have at least a simple User/Role/Group API as part of Identity Management. In Seam 2 we originally used the built-in Java classes (which made more sense because the authentication process was based on JAAS), however in Seam 3 (where we removed JAAS because it doesn't support asynchronous authentication as required by OpenID etc) we based the security module on the PicketLink User API. IMHO, this is not a critical choice either way - the Java security classes have the advantage of being familiar to many users, while on the flipside if we provide our own User API we have the flexibility of being able to extend it in the future. So both options have their own advantages.
>
> 2. The addRole() and addGroup() methods are intended to be only used during the authentication process to grant particular user memberships for the duration of their session only. A few users have found this a little confusing, as they were using identity management, and expected these methods to grant a permanent membership for the user. One solution may be to simply rename these methods to addSessionRole() and addSessionGroup() - thoughts?
This implies question if API related to authentication and IDM operations should be de coupled or not - as this would be side effect of relying on Java SEE security classes.
>
> 3. We're touching a little bit on the authorization API here also with the hasRole() / inGroup() methods. I'll provide a quick description of these core security API concepts here:
>
> * User - represents an individual user of an application. Can either be human or non-human, and can represent either a user managed locally (i.e. through the IDM API) or an externally authenticated User, such as one that has logged in with OpenID.
> * Group - a collection of users and other groups. The intent is that privileges can be either assigned to individual users, groups or roles. Groups have a hierarchical structure and can be a member of zero or more other groups.
I would personally vote for having clear three structure - so group can belong to zero (under root) or 1 other group (parent). Having flexible hierarchy leads to fairly complex structure. This can easily lead to more cluttered API. From my observations tree structure covers 95% of use cases and many organizations need to integrate with their LDAP which is exactly this kind of shape.
> * Role - represent a particular real life role of a user. Roles are defined as a three-way relationship between user, group and role type. For example, user "Bob" might be an "accounts clerk" (the role type) at "head office" (the group). It is also possible for a user to have a role in a group, without being a member of that group.
Does it imply having separate notion of membership between user and group? For me it is the same as "Bob" being "member" (the role type) at "employees" (the group). One thing less to cover in the API which can make it simpler.
>
>
>
> [1] https://issues.apache.org/jira/browse/DELTASPIKE-76
> [2] https://github.com/seam/security/blob/develop/api/src/main/java/org/jboss/seam/security/Identity.java