In the previous section, you have learned about JAAS authentication and about login modules. So you know that result of authentication, including:
The JAAS Subject with principals for username (UserPrincipal) and for JAAS roles (RolesPrincipal).
Identity object, which encapsulates username, all memberships and all JAAS roles. This Identity object is bound to the IdentityRegistry component.
Authorization in GateIn Portal actually happens on two levels:
Servlet container authorization
First round of authorization is servlet container authorization based on secured URLs from web.xml. You can see above in the web.xml snippet that secured URLs are accessible only for users from the users role:
<auth-constraint>
<role-name>users</role-name>
</auth-constraint>
This actually means that your user needs to be in GateIn Portal role: /platform/users. In other words, if the authentication is successful but your user is not in the /platform/users group, it means that he is not in JAAS role users, which in next turn means that he will have authorization error named 403 Forbidden thrown by the servlet container. For example in LDAP setup, your users may not be in /platform/users by default, but you can use CustomMembershipLoginModule to fix this problem.
You can change the behaviour and possibly add some more auth-constraint elements into web.xml.
However, this protection of resources based on web.xml is not standard GateIn Portal way and it is mentioned here mainly for illustration purposes.
See Login modules for more details.
Portal level authorization
Second round of authorization is based on the UserACL component. See Portal default permission configuration for more details.
You can declare access and edit permissions for portals, pages and/or portlets.
UserACL is then used to check if the user has particular permissions to access or edit specified resource.
The important information about the user roles is mentioned in the Identity object which is created during the JAAS authentication.
Authorization on portal level looks like this:
The user sends the HTTP request to some URLs in portal.
The HTTP request is processed through SetCurrentIdentityFilter, which is declared in gatein/gatein.ear/portal.war/WEB-INF/web.xml.
SetCurrentIdentityFilter reads username of current user from HttpServletRequest.getRemoteUser(). Then it looks for Identity of this user in IdentityRegistry, where Identity has been saved during the authentication. The found Identity is then encapsulated into the ConversationState object and bound into the ThreadLocal variable.
UserACL is able to obtain Identity of current user from the UserACL.getIdentity() method, which simply calls ConversationState.getCurrent().getIdentity() for finding the current Identity bound to ThreadLocal. Now UserACL has identity of user so that it can perform any security checks.