The J2EE Role Profile Selection Handler is used to select a profile for a user by matching the J2EE roles that the user is in, to a corresponding role specified in a profile.
For matching purposes, this handler class uses the HttpServletRequest isUserInRole(..)
method to compare each Role (Segment) that was specified on each of the profiles within the profile set.
The definition file for this handler is in located in:
The content of the handler definition file is as follows:
<Handler name="J2EE Role Handler">
<Description>Handler that maps a users J2EE roles to a matching Profile.</Description>
<SegmentList class="com.bowstreet.profiles.J2EERoleProfileSelection" />
The J2EERoleProfileSelection implements both the ProfileSelection and SegmentList interfaces so it is specified as the Selection class and the SegmentList class.
J2EE application servers are only required to give you actual username and/or J2EE Application role information, for and within protected (by security constraint) resources. You should not rely on the J2EE security APIs such as request.getRemoteUser()
from non-protected (public) models/JSPs. Also, any WebSphere® Portlet Factory code that relies on these underlying J2EE Servlet security APIs, such as webAppAccess.getUserInfo(), J2EE Optional Authorization handler (based on model security property specified roles), and/or J2EE Role based profile selection, should ONLY be used within protected (by security constraint) models.
The J2EE Servlet security API request.isUserInRole()
, whether used directly in your code, or used within the optional J2EE Role based Profile Selection handler, appears to only be guaranteed to work for all roles you are in if all those roles are listed in the security constraint protecting the resource (WebApp based model LJOs/Java, Profile Selection, and/or JSP). For example, if you are in role A, role B and role C, but you only list role A as required to access /webengine/myProtectedModels/MyWebApp
, then request.isUserInRole("roleB")
may return false, since you were not required to be in role B to access this resource. The J2EE Servlet spec is not completely clear on the right behavior around this. We recommend you be conservative and list all roles in the security constraint which are allowed to access that resource, where any one of those roles may also be used in a request.isUserInRole(rolename)
call (as is done with the J2EE Role based Profile Selection Handler) within the execution of that resource.
Parent topic: Using sample handlers