You create visitor entitlement roles using the WebLogic Portal Administration Console, as described in Configuring Visitor Entitlements. In addition, there are specific runtime checks that you can perform in your portal applications to customize a visitor’s path through a portal based on their roles. You can use the JSP tags described in this chapter to perform authorization checks dynamically in portal applications. The access privileges are defined depending on the roles the user is assigned.
The <auth:isAccessAllowed>
and <auth:isUserInRole>
JSP tags enable you to customize a user’s path through a portal by determining what their access privileges are.
The <auth:isUserInRole>
JSP tag evaluates the current user’s role at runtime so you can selectively authorize access to an application resource. The <auth:isAccessAllowed>
JSP tag performs fine-grained entitlement-checking on application resources for which entitlements are not available by default.
This chapter includes the following sections:
The <auth:isUserInRole>
tag enables you to evaluate the current user’s role at runtime so you can selectively authorize access to an application resource. By requiring authorization of the user accessing the JSP, you can restrict the display of application content wrapped by the tag. If used within an entitled portlet, this allows multiple levels of authorization.
The role being verified is compared to the set of valid roles for the user. Enterprise-application and web-application scoped visitor entitlement roles created using the WebLogic Portal Administration Console and global roles created with the WebLogic Server Administration Console are evaluated. Any role mapping provider that has roles mapped to the portal resource hierarchy is also evaluated.
Note: | Each call to <auth:isUserInRole> causes all visitor roles for the current web application to be evaluated. This has performance implications if the role set is large. The map of computed roles is evaluated at most once per request, but is not cached across requests. |
See the Javadoc for detailed instructions on using this tag.
The <auth:isAccessAllowed>
tag performs fine-grained entitlement-checking on application resources for which entitlements are not available by default. These are application-defined (non-portal) resources for which you have created your own security policies.
This tag provides a runtime check for authorizing access to an application resource. If access is allowed, the id return value is set to true
. If access is denied, the id return value is set to false
and the body of the tag is skipped.
Perform the following steps to use this tag:
<auth:isAccessAllowed>
tag to your JSP, wrapped around the resource you want to entitle, and set the appropriate tag attributes. You can use an empty body form of this tag. If the attribute’s value can be evaluated when the JSP tag is rendered at runtime, the attribute contains a Yes in the following table.
Caution: | For more information on the IsAccessAllowedTag class, see the
Javadoc. |
This example checks entitlements for a link in a JSP. The resourceId and id attribute values are read from variables declared earlier in the code.
The code in Listing 10-1 shows how to use <auth:isAccessAllowed> to check role policies. Because the roleScope attribute value is set to HIERARCHICAL_ROLE_INHERITANCE, the tag looks for existing role policies starting at the leaf node and up each level in the resource taxonomy. If the user does not belong to a role allowing access to this resource, the user will not see the link.
<%@ taglib "http://www.bea.com/servers/p13n/tags/auth" prefix="auth" %>
...
<auth:isAccessAllowed resourceId="<%=resourceId%>" id="<%=evalResult%>"
roleScope="<%=EntitlementConstants.HIERARCHICAL_ROLE_INHERITANCE%>" >
<p>
<a href="HRpersonnel.jsp">Click here for secure personnel information.</a>
</auth:isAccessAllowed>
The following tools are alternatives to the <auth:isAccessAllowed>
tag:
com.bea.p13n.entitlements.servlets.jsp.taglib.IsAccessAllowedTag
class. For more information, see the
Javadoc.