[jira] [Resolved] (DELTASPIKE-77) review and discuss Identity API
[ https://issues.apache.org/jira/browse/DELTASPIKE-77?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek resolved DELTASPIKE-77. Resolution: Won't Fix Fix Version/s: 0.3-incubating we agreed on keeping the authorization api and remove the rest for now - later on we might add a very simple authentication module (api, jsf component/s,...). we will create new jira tickets for such a module as soon as we start with it. (details are available at http://s.apache.org/w1) review and discuss Identity API --- Key: DELTASPIKE-77 URL: https://issues.apache.org/jira/browse/DELTASPIKE-77 Project: DeltaSpike Issue Type: Sub-task Components: Security-Module Affects Versions: 0.1-incubating Reporter: Shane Bryzak Assignee: Shane Bryzak Fix For: 0.3-incubating -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (DELTASPIKE-77) review and discuss Identity API
[ https://issues.apache.org/jira/browse/DELTASPIKE-77?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13424636#comment-13424636 ] Gerhard Petracek edited comment on DELTASPIKE-77 at 7/29/12 10:21 PM: -- we agreed on keeping the authorization api and remove the rest for now - later on we might add a very simple authentication module (api, jsf component/s,...). we will create new jira tickets for such a module as soon as we start with it. (details are available at http://s.apache.org/w1 ) was (Author: gpetracek): we agreed on keeping the authorization api and remove the rest for now - later on we might add a very simple authentication module (api, jsf component/s,...). we will create new jira tickets for such a module as soon as we start with it. (details are available at http://s.apache.org/w1) review and discuss Identity API --- Key: DELTASPIKE-77 URL: https://issues.apache.org/jira/browse/DELTASPIKE-77 Project: DeltaSpike Issue Type: Sub-task Components: Security-Module Affects Versions: 0.1-incubating Reporter: Shane Bryzak Assignee: Shane Bryzak Fix For: 0.3-incubating -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (DELTASPIKE-77) review and discuss Identity API
[ https://issues.apache.org/jira/browse/DELTASPIKE-77?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek reassigned DELTASPIKE-77: -- Assignee: Gerhard Petracek (was: Shane Bryzak) review and discuss Identity API --- Key: DELTASPIKE-77 URL: https://issues.apache.org/jira/browse/DELTASPIKE-77 Project: DeltaSpike Issue Type: Sub-task Components: Security-Module Affects Versions: 0.1-incubating Reporter: Shane Bryzak Assignee: Gerhard Petracek -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (DELTASPIKE-77) review and discuss Identity API
[ https://issues.apache.org/jira/browse/DELTASPIKE-77?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek reassigned DELTASPIKE-77: -- Assignee: Shane Bryzak (was: Gerhard Petracek) review and discuss Identity API --- Key: DELTASPIKE-77 URL: https://issues.apache.org/jira/browse/DELTASPIKE-77 Project: DeltaSpike Issue Type: Sub-task Components: Security-Module Affects Versions: 0.1-incubating Reporter: Shane Bryzak Assignee: Shane Bryzak -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [DISCUSS] Identity API
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
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 Bryzaksbry...@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
[jira] [Updated] (DELTASPIKE-77) review and discuss Identity API
[ https://issues.apache.org/jira/browse/DELTASPIKE-77?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated DELTASPIKE-77: --- Affects Version/s: 0.1-incubating Summary: review and discuss Identity API (was: review and discuss Identity) review and discuss Identity API --- Key: DELTASPIKE-77 URL: https://issues.apache.org/jira/browse/DELTASPIKE-77 Project: DeltaSpike Issue Type: Sub-task Components: Security-Module Affects Versions: 0.1-incubating Reporter: Shane Bryzak Assignee: Shane Bryzak -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [DISCUSS] Identity API
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 sbry...@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
*
*
Re: [DISCUSS] Identity API
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
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 rdebussc...@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 sbry...@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
[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
*/
SetRole getRoles();
/**
