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