10 Implementing Authorization Programmatically

You create visitor entitlement roles using the WebLogic Portal Administration Console, as described in Chapter 8, "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:

Section 10.1, "Verifying Whether a User Is Assigned a Specific Role"
Section 10.2, "Verifying Whether a User Has Access to a Resource"

10.1 Verifying Whether a User Is Assigned a Specific Role

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 Oracle Fusion Middleware Java API Reference for Oracle WebLogic Portal for detailed instructions on using this tag.

10.2 Verifying Whether a User Has Access to a Resource

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:

Identify the taxonomy of the resource to be entitled. For example, if you are entitling a link on a JSP, the taxonomy is: JSP > link. Set the resourceId attribute to this value.
Create a security policy using the SecurityPolicyManager API using the resourceId from step 1. The policy can be predicated on WebLogic Portal roles.
In the WebLogic Portal Administration Console, create and define a visitor role that can access the resource you are entitling.
Add the <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.

10.2.1 Attributes

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.

Table 10-1 isAccessAllowed Tag Attributes

Tag	Description
id	Required \| String \| Can use runtime expressions: No The name of a variable that holds the result of the tag evaluation. Set to `true` or `false`.
resourceId	Required \| String \| Can use runtime expressions: Yes The application-defined taxonomy (hierarchy of resources) including the resource being requested. For example, if you are entitling a link on a JSP, the taxonomy is: JSP > link.
capability	Optional \| String \| Can use runtime expressions: Yes The requested capability for the resource. If no capability is specified (there is no capability name on the policy), a general security policy is searched for and used.
inheritSecurityPolicy	Optional \| Boolean \| Can use runtime expressions: No Allows a hierarchical taxonomy evaluation of security policies for authorization, instead of a single, first-found, evaluation. If this attribute is set to `false`, the first security policy found is used. If this attribute is set to `true`, any inherited security policies are used. The default is `false`.
needContextHandler	Optional \| Boolean \| Can use runtime expressions: No Must be set to `true` if there is the possibility that an in-scope role policy will be predicated on user profile attributes. The default is `true`.
roleScope	Optional \| Integer \| Can use runtime expressions: Yes Determines the level in the taxonomy at which role policies are evaluated to allow or deny access to the resource. If you do not use this attribute, the search for the role is up to the `enterprise-application` scope (ENT_APP_ROLE_INHERITANCE). Possible values include the following: `<%=EntitlementConstants.GLOBAL_ROLE_INHERITANCE%>` – Looks for role policies that are defined in the WebLogic Server Administration Console at a global scope. `<%=EntitlementConstants.APPLICATION_INHERITANCE%>` – Looks for role policies that are defined in the WebLogic Server Administration Console at an application scope. `<%=EntitlementConstants.ENT_APP_ROLE_INHERITANCE%>` – Looks for role policies at an enterprise application and global scope. `<%=EntitlementConstants.WEBAPP_ROLE_INHERITANCE%>` – Looks for role policies at a web application, enterprise application, and global scope. `<%=EntitlementConstants.LEAF_NODE_ROLE_INHERITANCE%>` – Looks for role policies at a resource leaf node and global scope only. `<%=EntitlementConstants.HIERARCHICAL_ROLE_INHERITANCE%>` – Looks for role policies at each level up the taxonomy: leaf node, web application, enterprise application, and global scope.
subject	Optional \| Subject object \| Can use runtime expressions: Yes The subject (which maps to a user) for which the request is evaluated. If no subject is provided, the subject on the current request is used.

For more information on the IsAccessAllowedTag class, see the Oracle Fusion Middleware Java API Reference for Oracle WebLogic Portal.

10.2.2 Example

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 Example 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.

Example 10-1 Sample Code That Checks Entitlements on a JSP

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

10.2.3 Other Tools

The following tools are alternatives to the <auth:isAccessAllowed> tag:

Java – Work directly with the com.bea.p13n.entitlements.servlets.jsp.taglib.IsAccessAllowedTag class. For more information, see the Oracle Fusion Middleware Java API Reference for Oracle WebLogic Portal.
In the WebLogic Portal Administration Console, create and define a visitor role that will be able to access the resource you are entitling. You can also view the policies for each role.