Integrating ALES with Application Environments

Integrating with BEA Workshop for WebLogic Platform

This section describes how to use AquaLogic Enterprise Security with BEA Workshop for WebLogic Platform. It covers how to:

Add security-related annotations to your EJB code and
Use the ALES Tag Library in your Java Servlet Pages (JSPs) to get user roles and entitlements for a user and a particular resource, and to determine whether access is allowed to that resource.

It includes the following topics:

Overview of the ALES Annotations Plug-in

BEA Workshop for WebLogic Platform is an IDE for developing standards-based enterprise-level applications that integrates standard and open source technologies such as Java EE, Eclipse and Apache Beehive. Using Workshop, you can easily add annotations to your Java code. Annotations is a feature of J2SE 5.0 that enables adding metadata to Java code. Later, the metadata can be used for different purposes such as generation of documentation, compile-time validation, and creation of deployment descriptors. The metadata can also be accessed during runtime.

AquaLogic Enterprise Security includes a plug-in for Workshop that gives you the ability to annotate EJB objects in Workshop with security related metadata. The metadata can then help you to:

Generate policy files, with lists of resources and their attributes, that you can then import into ALES.
Facilitate creation of policy rules by providing a higher level of indirection, achieved by writing the policies against the predefined metadata instead of against EJB class and method names.
Divide responsibilities of an EJB developer and a security specialist.
Improve maintainability of the security model. For example, since seurity policies are written against the metadata, you don't need to modify them if an EJB class or EJB method name has been changed or added until the proper metadata is attached.

Setting Up the ALES Annotations Plug-in for Workshop

To set up the ALES Annotations plug-in for Workshop:

Install WebLogic Server with BEA Workshop for WebLogic Platform. For information about installing WebLogic Server, see the BEA Products Installation Guide.
Install the ALES Administration Server. For information about installing the ALES Administration Server, see Installing the Administration Server.
Copy the plug-in JAR file from ALES to Workshop. The Workshop plug-in for AquaLogic Enterprise Security is a JAR file named com.bea.wlw.ales.annotations_9.2.0.jar, which is located at ALES_ADMIN_HOME/lib/eclipsePlugins. To install the plug-in, copy com.bea.wlw.ales.annotations_9.2.0.jar to BEA_HOME/WORKSHOP_HOME/workshop4WP/eclipse/plugins.

The next time you start Workshop, you will see the ALES Annotations facet in a new or existing WebLogic EJB project.

Figure 10-1 Project Facets

Project Facets

Example: Using ALES Annotations in a WebLogic Bean Class

This section describes how you might use Workshop with the ALES Annotations plug-in. In this example, we show how to:

Create a WebLogic SessionBean

The first step in this example is to use Workshop to create a WebLogic SessionBean:

Create a new project named EjbExample.
Select EjbExample in the left panel, right click the src node and select New > Package. Name the package beans.
Right click on beans, select New > WebLogic Session Bean, and set the file name to AccountService.

Add ALES Annotations to the WebLogic Bean Class

Next, we will use Workshop to add security annotations to our AccountService class.

In the edit window for the Weblogic Session Bean class AccountService.java, import the following two classes:

import com.bea.security.annotations.type.ALESResource;
import com.bea.security.annotations.type.ALESAttribute;

Define the Bean class AccountService as an ALES resource:

Before the class definition, add the annotation @ALESResource. The ALESResource -Annotation property appears in the Annotations viewer.
Under ALESResource, right click attributes and click Add Member com.bea.security.annotations.type.ALESAttribute. We can now assign attributes to this resource.

Figure 10-2 Assigning ALESAttributes

Assigning ALESAttributes

Expand the ALESAttribute node under ALESResource > attributes in the right panel and set the name and value of the ALESAttribute to beantype = account.
Similarly, we can define any methods inside this class as ALES resources and assign ALES attributes to these resources using the ALES Annotations plug-in. For example, annotate the ejbCreate() method to define it as an ALES resource with the ALESAttribute operation = create.

@ALESResource(attributes={@ALESAttribute(name = "operation", value = "create")})

Configure ALES Annotations Properties

Next, we configure ALES-specific properties for our project:

In the left panel of Workshop, right click the EjbExample project node and click Properties. The Properties window for the project EjbExample appears.

Figure 10-3 ALES Annotation Project Properties

ALES Annotation Project Properties

Select ALES annotations and configure the following four properties:

SSM configuration — the ALES SSM name we are going to bind the EJB application with; for example, wls-ssm.
EJB application — the name of the EJB application we are going to deploy; for example, BankingApp.
EJB module — the name of the EJB module we are going to deploy; for example, AccountModule.
Policy file — the absolute path of the policy file to which we may export the ALES annotations.

Export the ALES Policy File from Workshop

After annotating the project in the example, we can export the security policy file from Workshop. This security policy file can then be imported and deployed through ALES:

In the Package Explorer or Navigator panel of Workshop, right click the project node (EjbExample in our example), select Export > ALES Export Policy File, and then click Next.

Figure 10-4 ALES Policy File Export Window

ALES Policy File Export Window

In the ALES Policy File Export window, specify the project name and the pathname for the policy file (for example, EjbExamplePolicy.xml). If the Leave unspecified checkbox is checked, the resulting policy file includes tokens for SSM configuration, EJB application, and EJB module instead of the values you have specified for them. Later, the EJB application deployer can replace these tokens. This functionality is useful when the developer does not know all the deployment parameters of the target machine, or the EJB application is going to be deployed on multiple machines with different configurations.

Import an ALES Annotations policy using policyIX

This section describes how to use the ALES policyIX utility to load the ALES Annotations policy file we created in Export the ALES Policy File from Workshop into ALES.

If you did not already load the admin policies, start the ALES Administration Server and load them by running the install_ales_schema script.
If, when you created the policy file, you checked Leave unspecified, your policy file includes tokens, rather than specific values for SSM configuration, EJB application, and EJB module. Before you import the policy file into ALES, you need to replace these tokens with their actual values. In ALES_ADMIN_HOME/config/annotation_config.properties, replace the following tokens with the corresponding values:

ap.ssm.id - SSM configuration
ap.ejb.app - EJB application
ap.ejb.mod - EJB module
exported.res.file - pathname of the policy file

After you modify the annotation_config.properties file, run ALES_ADMIN_HOME/bin/annotation_transform to create the policy file with actual values substituted for the tokens. The created policy file will have the same name as the exported.res.file parameter with the extension .import appended.

After the ALES Administration Server has started, use the policyIX utility to import the policy file. For example:

C:\ALES_ADMIN_HOME/bin> policyIX -import config.xml EjbExamplePolicy.xml

For more information, see policyIX in the Administration Reference.

After you import the policy file into ALES, you can use the ALES Administration Console to view the protected resources and resource attributes. Under wls-ssm/BankingApp/ejb/AccountModule, you can see:

AccountService has the ALES attribute beantype="account"
The AccountService.create method inherits the ALES attribute beantype="account" and has its own attribute operation="create".

Figure 10-5 Resource Attributes for the create Method

Resource Attributes for the create Method

Use the Resources Defined with ALES Annotations to Write Policies

Now that we have imported the policy file created in Workshop with ALES Annotations, we can define rules to access the resources defined with ALES annotations. For example, the following rule will grant the execute privilege to the AccountManagerRole for all the resources under BankingApp if beantype="account":

grant( //priv/execute, //app/policy/wls-ssm/BankingApp, //role/AccountManagerRole) if beantype="account"

Since all methods inherit attributes of the bean class, the resource AccountService and all its methods satisfy the constraint, defining this rule enables the AccountManagerRole to execute all AccountService methods.

The following rule allows a user with the Customer role to execute any method in the banking application, but only if the method is annotated with the attribute accessLevel="customer". The rule also allows a user with the Customer role to create an instance of the EJB by calling create method of the corresponding EJB's home interface:

grant( //priv/execute, //app/policy/wls-ssm/BankingApp, //role/Customer) if accessLevel="customer" or operation="create"

ALES Tag Library Plug-in for Workshop

This section describes the ALES Tag Library for Workshop, which you can use to add ALES security functionality to your Java Server Pages (JSPs).

ALES Tag Library Overview

The ALES tag library allows you to easily secure JSP-page-level components (ALES resources) using ALES tags, and to retrieve information such as the set of roles a user has from the ALES security system.

Tag libraries provide a way to abstract functionality used by a JSP page, which allows for less-complex JSP pages. A tag library packages functions into a tag handler class. Your JSP does not have to directly invoke this tag handler. Instead, you place simple tags in your JSP pages. When the container executes a JSP at runtime and comes across a tag, the tag handler is invoked and provides the desired functionality.

ALES Tag Library Tags

The following tags are available in the ALES Tag Library for Workshop. See ALES Tag Library Reference for additional information and attributes.

isAccessAllowed - If access is allowed, display the body of the tag. If not, skip the body. It returns true or false and a variable to the body of the JSP that can be used later to process responses.
isAccessNotAllowed - If access is not allowed, display the body of the tag. Otherwise, skip the body. It returns true or false and a variable to the body of the JSP that can be used later to process responses.
isAccessAllowedQueryResources - This tag returns the set of granted and denied responses from the query resources functionality of isAccessAllowed. This returns a variable to the JSP that can be used later to process responses.
getUserRoles - Makes the set of user roles available to the application. This returns a variable to the JSP that can be used later for processing.
isUserInRole - Returns true if the current user has a specific role.
recordEvent - Passes an audit event into ALES. This tag is an event tag that provides input to the ALES auditing system.
setSecurityContext - This sets up data for the other tags. You set a value to be used as a prefix for all other resources on the page. For example: <setSecurityContext value="/mybank/loanApplicationForm"/>. Later on the page, when a resource is specified for an isAccessAllowed call, it will be prepended with /mybank/loanApplicationForm.

Any attributes set within the tag are passed to every ALES API call. For example if you set foo=1 in the security context and then use the isAccessAllowed tag, foo=1 would be available during policy evaluation as an application context variable.

ALES Tag Library Walk-Through

On the local system, in your JSP you determine the set of components that you want to protect. You can query the security system for data, such as which roles the user has.

As a more elaborate usage, you could use query resources to return a collection that could populate a drop down list. An example might be the set of currencies to which a trader can convert.

On the local system, create your JSP pages. These JSP pages utilize the ALES tags to determine whether access is allowed to the components you developed in Step 1.

The ALES tags can wrap the JSP components and they will be rendered if allowed. There is also an else tag for the case where a component is denied.

Use the ALES Administration Console to create policies for the resources you developed in Step 1. The fully qualified name (using the optional <setSecurityContext-Value>) for such a resource is

//app/policy/<binding node>/<setSecurityContext-Value>/resource
Use the ALES Administration Console to distribute the policy data to the WLS 9.x SSM running on the local system.
Deploy your application on the local system.
When the WebLogic Server container on the local system executes a JSP at runtime and encounters an ALES tag, the tag handler is invoked and interacts with the WLS 9.x SSM to determine if access is allowed to the resource, get the user roles, and so forth.

Authenticated Subject is Determined by WebLogic Server

You do not need to supply an authenticated subject to the ALES tags for Workshop. This is because the container, WebLogic Server, determines and authenticates the subject and then makes the authenticated subject available for authorization decisions. You do not need to take any special action in your JSP page.

Example of Using ALES Tags in a JSP Page

This section provides an example of using ALES tags in a JSP page.

Consider the example JSP page shown in Listing 10-1:

Listing 10-1 Example JSP Page With ALES Tags

<%@ taglib prefix="ales" uri="http://www.bea.com/ales/tags"%>

<%@ taglib  prefix="c" uri="http://java.sun.com/jsp/jstl/core"%>

<%@ page language="java" contentType="text/html; charset=ISO-8859-1"

pageEncoding="ISO-8859-1"%>

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">

<html>

<head>

<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">

<title>IsAccessAllowedSample</title>

</head>

<ales:setSecurityContext value="/testtagapp">

<ales:attribute name="foo" value="1"/>

</ales:setSecurityContext>

<body>

<ales:isAccessAllowed resource="/isAllowed" action="view">

<ales:then>You are allowed to see the secret text</ales:then>

<ales:else>DenyReason: <c:out value='${responses["denyreason"]}'/> </ales:else>

</ales:isAccessAllowed>

</body>

</html>

In Listing 10-1 the <@taglib prefix="ales" uri=http://www.bea.com/ales/tags%> line signifies that all tags prefixed with ales: will call the ALES tag library.

The ales:isAccessAllowed tag takes a resource and an action.

Resources on the JSP page are relative to the WLS SSM's binding node. In addition, one of the parameters you pass in to the (optional) setSecurityContext tag is a resource URI. This URI is relative and is prepended with the SSM binding node at runtime. In the example, the resource URI is testtagapp.

Therefore, after adding the binding node and resource URI, at runtime the fully qualified resource in Listing 10-1 is //app/policy/<binding_node>/testtagapp/isAllowed.

After you have written the JSP in Listing 10-1 you would then:

Secure your container with an ALES SSM.
Use the ALES Administration Console to create policies for the resources on your page.

Based on the example, we would create a resource //app/policy/<binding_node>/testtagapp/isAllowed where <binding_node> would be the SSM's binding node from Step 1. We could then write policies based on that reasource to determine what users are allowed to see the secret text.

When the WebLogic Server container on the local system executes a JSP at runtime and encounters an ALES tag, the tag handler is invoked and interacts with the WLS 9.x SSM to determine if access is allowed to the resource, get the user roles, and so forth.

Adding the ALES Tag Library to Workshop

This section describes how to integrate the ALES Tags in Workshop.

Integration Prerequisites

Before you begin, you must ensure that the following prerequisites are satisfied:

Note:

You can test your JSP page without having ALES deployed in your development environment. JSP pages with ALES tags do not fail to compile or run when a WLS SSM is not installed.

Note:

If you were to deploy the JSP page on an instance of WLS without ALES, the tags do not break. Instead, the security tags allow both the allow- and deny cases to display on the page, and data retrieval methods return empty results.

The system that serves the JSP pages with the embedded ALES tags (assumed here to be the local machine) must have BEA Workshop for WebLogic Platform version 9.2 installed, and must use WebLogic Server 9.2 as the container.
The WLS 9.x SSM must be installed on the local machine.
You must have access to an ALES Administration Console on a version 2.6 ALES Administration Server on either the local machine or a remote machine. You need the Administration server in order to import the resource definitions and distribute the resulting policy to the WLS 9.x SSM.

Integrating the Tag Library with Workshop: Main Steps

The tag library is packaged in its own jar file, alestags.jar, which contains all of the tag library supporting classes.

The alestags.jar is itself packaged in the BEA_HOME\ales26-admin\lib\eclipsePlugins\com.bea.wlw.ales.tags_9.2.0.jar file.

Follow these steps to integrate the tag library JAR file:

Copy BEA_HOME\ales26-admin\lib\eclipsePlugins\com.bea.wlw.ales.tags_9.2.0.jar to your BEA_HOME\workshop92\workshop4WP\eclipse\plugins directory.
Start or restart Workshop.
If creating a new project:

Create a new dynamic web project.
Name your new project and click Next.
Check the ALES Tag Support project facet.
Click Finish.
Click Window->Show View->JSP Design Palette to display the JSP Design Palette.

You should now have alestags.jar file in your web-inf/lib directory. In addition, in your JSP Design Palette you should see the ALES Tags.

If adding to an existing project:

Right click on the project.
Click properties.
Click the project facets properties in the left navigation bar of the popup.
Click add/remove facets.
Check the ALES Tag Support project facet.
Click finish.
Click Window->Show View->JSP Design Palette to display the JSP Design Palette.

You should now have alestags.jar in your web-inf/lib directory. In addition, in your JSP Design Palette you should see the ALES tags, as shown in Figure 10-6.

Figure 10-6 Workshop Integration Screen

Workshop Integration Screen

Using Tag Resources in Your ALES Policy Definitions

You typically define the resources for your application as a part of defining the ALES tags. Take note of these resource names and the actions you want to perform on them.

The parameter you pass in to the (optional) ALES setSecurityContext tag is a resource URI, which is a value to be used as a prefix for all other resources on the page. For example: <setSecurityContext value="/mybank/loanApplicationForm"/>.

This URI is relative and is prepended with the SSM binding node at runtime. This resource URI uniquely identifies the resources.

Any attributes set within setSecurityContext are passed to every ALES API call. For example if you set foo=1 in the security context and then use the isAccessAllowed tag, foo=1 would be available to policies as an application context variable.

Use the resources and actions you specified in the tags to create your ALES policy definitions.

When you then create ALES policies to manage these resources, be aware that the fully qualified name of the resource is

//app/policy/<binding node>/<SecurityContext-Value>/resource

How to Write Policies That Return Response Attributes

There is nothing unique about the ALES policies that you create to protect a resource referenced in a JSP file by a tag library, beyond the general requirement that the resource names and actions you specify in tags must correlate with the policy.

However, if you use result and response attributes such as isAccessAllowed.resultVar, you can create a policy that returns response attributes and then test those attributes.

As described in Using Response Attributes, response attributes are typically specified using built-in evaluation functions that report name/value pairs. There are two functions for returning attributes: report() and report_as(). These functions always return TRUE (if there are no errors), and their information is passed to your application as response attributes.

The JSP Standard Tag Library (JSTL) provides a set of core functionality common to most web applications. This functionality includes generic iterators and Boolean checks. As such, the ALES tag library does not implement its own set of iterators. The data returned by the ALES tags to the JSP can be processed using the JSTL.

Therefore, in your JSP file you could use a JSTL tag in the following way:

<ales:isAccessAllowed resource="/creditScore" action="view" resultVar="canViewCreditScore">

:

<c:if test="${canViewCreditScore == true}">

Show customer credit score

</c:if>

ALES Tag Library Reference

This section describes reference and usage information for the ALES tag library.

isAccessAllowed

The isAccessAllowed tag calls the ALES runtime to see if the user is allowed to perform the requested action on the requested resource. If true is returned, it allows the container to continue processing the body of the tag.

For convenience, the result of calling isAccessAllowed can be placed within the resultVar for later use.

isAccessAllowed looks for the ARME configuration file in the system properties. If not found, all elements in the body tag are displayed.

Table 10-1 isAccessAllowed
Attribute	Return Type	Description	Required
resource	n/a	The resource used when calling isAccessAllowed	Yes
action	n/a	The action used when calling isAccessAllowed. The default action is view	No
resultVar	Boolean	The name of the scripting variable used to tell if access is allowed.	No
resultVarScope	n/a	The scope of the resultVar (page, request, session, or application). The default scope is page.	No
responseVar	Collection of Strings	The name of the variable used for returning responses from calling isAccessAllowed	No
responseVarScope	n/a	The scope of the variable containing responses from is access allowed (page, request, session, or application). The default scope is page.	No

isAccessAllowed Concepts

Listing 10-2 shows the concepts of using isAccessAllowed in a JSP.

Listing 10-2 Using isAccessAllowed in a JSP

<%-- set up the global context for this jsp page --%>

<ales:setSecurityContext value="/mybank/loanApplicationForm">

	<%-- An attribute to pass to the ALES application context for all calls on this page--%>

 	<attribute name="loanAppId" value="<%= request.getParameter(\"appId\")%>"/>

</ales:setSecurityContext>

<ales:isAccessAllowed resource="/creditScore" action="view" resultVar="canViewCreditScore">

	<%-- An attribute to pass to the ALES application context for this call--%>

	<attribute name="customerId" value="<%=request.getParameter(\"customerId\")%>

<ales:then>

       <bankapp:displayCreditScore>

</ales:then>

<ales:else>

 	<B>You are not authorized to view the customer's credit score</B>

</ales:else>

</ales:isAccessAllowed>

Alternatively, after the isAccessAllowed tag with the resultVar canViewCreditScore attribute, you could use a JSTL tag in the following way:

<c:if test="${canViewCreditScore == true}">

Show customer credit score

</c:if>

isAccessNotAllowed

The isAccessNotAllowed tag calls the ALES runtime to see if the user is allowed to perform the requested action on the requested resource. If true is returned, it allows the container to continue processing the body of the tag.

For convenience, the result of calling isAccessAllowed can be placed within the resultVar for later use.

isAccessNotAllowed looks for the authorization and role mapping engine (ARME) configuration file in the system properties. If not found, all elements in the body tag are displayed.

Table 10-2 isAccessNotAllowed
Attribute	Return Type	Description	Required
Resource	n/a	The resource used when calling isAccessAllowed	Yes
Action	n/a	The action used when calling isAccessAllowed. The default action is view	No
resultVar	Boolean	The name of the scripting variable used to tell if access is allowed.	No
resultVarScope	n/a	The scope of the resultVar (page, request, session, or application). The default scope is page.	No
responseVar	Collection of Strings	The name of the variable used for returning responses from calling isAccessAllowed	No
responseVarScope	n/a	The scope of the variable containing responses from is access allowed (page, request, session, or application). The default scope is page.	No

isAccessNotAllowed Concepts

Listing 10-3 shows the concepts of using isAccessNotAllowed in a JSP.

Listing 10-3 Using isAccessNotAllowed in a JSP

<%-- set up the global context for this jsp page --%>

<ales:setSecurityContext value="/mybank/loanApplicationForm">

	<%-- An attribute to pass to the ALES application context for all calls on this page--%>

 	<attribute name="loanAppId" value="<%= request.getParameter(\"appId\")%>"/>

</ales:setSecurityContext>

<ales:isAccessNotAllowed resource="/creditScore" action="view" resultVar="canNotViewCreditScore">

<ales:then>

<B>You are not authorized to view the customer's credit score</B>

</ales:then>

<ales:else>

	<%-- An attribute to pass to the ALES application context for this call--%>

 	<attribute name="customerId" value="<%= request.getParameter(\"customerId\")%>

 	<bankapp:displayCreditScore>

</ales:else>

</ales:isAccessNotAllowed>

Alternatively, after the isAccessNotAllowed tag using the resultVar canNotViewCreditScore attribute, you could use a JSTL tag in the following way:

<c:if test="${canNotViewCreditScore == false}">

  Show customer credit score

</c:if>

isAccessAllowedQueryResources

The isAccessAllowedQueryResources tag calls the ALES runtime using the query resource extra attribute. This tag does not have a body associated with it. Instead, it returns a set of data that can be consumed by the JSP.

The grantedVar attribute sets a variable containing the granted response set from the ARME. The deniedVar attribute sets a variable containing the denied response set from the ARME.

If the ARME configuration file is not found, this tag does not set any data for the JSP to consume.

Table 10-3 isAccessAllowedQueryResources
Attribute	Return type	Description	Required
resource	n/a	The resource used when calling isAccessAllowed	Yes
action	n/a	The action used when calling isAccessAllowed. The default action is view	No
responseVar	Collection of Strings	The name of the variable used for returning responses from calling isAccessAllowed	No
responseVarScope	n/a	The scope of the variable containing responses from is access allowed (page, request, session, or application). The default scope is page.	No
grantedVar	Collection of Strings	The set of granted responses returned from the ARME	No
grantedVarScope	n/a	The scope of the grantedVar variable (page, request, session, or application). The default scope is page.	No
deniedVar	Collection of Strings	The set of denied responses returned from the ARME	No
deniedVarScope	n/a	The scope of the deniedVar variable (page, request, session, or application). The default scope is page	No

isAccessAllowedQueryResources Concepts

Listing 10-4 shows the concepts of using isAccessAllowedQueryResources in a JSP.

Listing 10-4 Using isAccessAllowedQueryResources in a JSP

<%-- Get a list of currencies that a trader can exchange to put inside a dropdown list --%>

<ales:isAccessAllowedQueryResources resource=" /mybank/currencyTrader/availableCurrencies" grantedVar="grantedCurrencies">

	<attribute name="currencyToTradeFrom" value="USD"/>

</ales:isAccessAllowedQueryResources>

<%--This fake sample tag takes in a collection of strings and lists them in a drop down--%>

<myuitag:dropdownlist values="${%grantedCurrencies%}"/>

getUserRoles

The getUserRoles tag queries the ALES system for the set of roles that a user currently has in the system for the requested action and requested resource. It will return the collection of role names as a variable defined by the resultVar attribute.

Table 10-4 getUser Roles
Attribute	Return Type	Description	Required
Resource	n/a	The resource used when calling getRoles	Yes
Action	n/a	The action used when calling getRoles. The default action is view	No
resultVar	Collection of Strings	The name of the variable to set that contains the list of user's roles	Yes
Scope		The scope of the variable containing responses from is access allowed (page, request, session, or application). The default scope is page.	No

getUserRoles Concepts

Listing 10-5 shows the concepts of using getUserRoles in a JSP.

Listing 10-5 Using getUserRoles in a JSP

<%-- Get the list of roles the user has for a particular resource --%>

<ales:getUserRoles resource="/mybank/loanApprovalForm" resultVar="userRoles">

 	<attribute name="customerId" value="${currentCustomerId}"/>

</ales:getUserRoles>

<%--iterate over each role and print it out--%>

<c:forEach var="userRole" items="${userRoles}">

	<c:out value="${userRole}"/>

</c:forEach>

isUserInRole

The isUserInRole tag is a conditional and cooperative tag. If the user is in the role specified, the body of the tag will be processed. If the user has the role passed into the tag Attribute, the body of the tag will be processed. In addition. the resultVar can be used for later processing.

Table 10-5 isUserInRole
Attribute	Return Type	Description	Required
Role	n/a	The name of the role to check against the user	Yes
Resource	n/a	The name of the resource to check the user's roles against. The default value will be the current JSP page	No
Action	n/a	The action against the resource to check the user's role against. The default value will be view	No
resultVar	Boolean	A variable to hold the result from isUserInRole for use later	No

isUserInRole Concepts

Listing 10-6 shows the concepts of using getUserRoles in a JSP.

Listing 10-6 Using isUserInRole in a JSP

<%-- Check if the user is in the appropriate role before showing the buttons on the page --%>

<isUserInRole role="Administrator" Resource="/myBankingApp/loanApproval/submit">

	<fake:submitButton .../>

</isUserInRole>

setSecurityContext

The setSecurityContext tag is used to set the base resource for all elements on a JSP page. If you use setSecurityContext, the value of this tag will be prepended to all other resource attributes on the page. In addition, variables that should be set globally for the application context can be set in the body of this tag.

Table 10-6 setSecurityContext
Attribute	Return Type	Description	Required
Value	n/a	The value of the security context will be used to specify the prefix for all ales tags that have a resource attribute on the page.	Yes

setSecurityContext Concepts

Listing 10-7 shows the concepts of using setSecurityContext in a JSP.

Listing 10-7 Using setSecurityContext in a JSP

<%-- Set the security context for this page --%>

<ales:setSecurityContext value="/mybank/loanApplicationForm"/>

 	<ales:attribute name="customer_name"

 		value="<%=request.getParameter(\"customerId\")%=>"

</ales:setSecurityContext>

recordEvent

The recordEvent tag is an input tag that causes an audit message to be written to the audit log of ALES. The body of this tag can also take an attribute tag, as described in Attribute. All attributes are added to the audit context as additional information for the audit event.

Table 10-7 recordEvent
Attribute	Return Type	Description	Required
Severity	n/a	The severity of the audit message. The possible values are: ERROR, FAILURE, or INFORMATIONAL. The default value is INFORMATIONAL	No
Message	n/a	The message to be passed to the audit log	YES

recordEvent Concepts

Listing 10-8 shows the concepts of using recordEvent in a JSP.

Listing 10-8 Using recordEvent in a JSP

<c:if test=${trade_submitted == true}>

 	<%--record that the trade has been successfully committed to the system—%>

	<ales:recordEvent message="Trade successfully submitted to the system">

 		<%--include the person who submitted this trade in the audit log--%>

		<attribute name="traderId" value="<%traderId%>"/>

 		<%--Include the trading confirmation number in the audit log--%>

		<attribute name="trade_confirmation" value="<%trade_confirmation%>

	</ales:recordEvent>

</c:if>

Attribute

The attribute tag can be used by any of the other ALES tags to pass extra attributes down in the ALES application context. Any of these variables can then be used to write constraints against in ALES policies.

Table 10-8 attribute
Attribute	Return Type	Description	Required
Name	n/a	The name of the attribute to set in the ALES application context	YES
Value	n/a	The value of the attribute to set in the ALES application context	YES

attribute Concepts

Listing 10-9 shows the concepts of using attribute in a JSP.

Listing 10-9 Using attribute in a JSP

<%-- set up the global context for this jsp page --%>

<ales:setSecurityContext value="/mybank/loanApplicationForm">

	<%-- An attribute to pass to the ALES application context for all calls on this page--%>

 	<attribute name="loanAppId" value="<%= request.getParameter(\"appId\")%>"/>

</ales:setSecurityContext>

<ales:isAccessAllowed resource="/creditScore" action="view" resultVar="canViewCreditScore">

	<%-- An attribute to pass to the ALES application context for this call--%>

	<attribute name="customerId" value="<%=request.getParameter(\"customerId\")%>

	<bankapp:displayCreditScore>

<else>

 	<B>You are not authorized to view the customer's credit score</B>

</ales:isAccessAllowed>