Developing Secure Applications With Sun Java System Access Manager, Part 2: Advanced Authorization

Print-friendly Version

In today's digital world, properly authenticating and authorizing users of heterogenous application platforms is a common challenge. By integrating service-oriented architecture (SOA) according to standards, you enable collaboration and communication among services and applications. However, all that software requires application-level security so that only preauthorized users can access the applications. Through centralization of identity and access management within enterprises, you can control what resources are accessed when and by whom.

Part 1 of this series shows how to authorize users for a fictional health-care insurance company, EB Health, with Sun Java System Access Manager (henceforth, Access Manager). Here in Part 2, you learn how to satisfy some of the most common yet complex enterprise deployment and quality requirements, again with Access Manager and through the EB Health example.

This part assumes the following:

• A good understanding of Part 1
• Experience in installing, configuring, and deploying Access Manager
• A working knowledge of Web services and Java XML API for Web services (JAX-WS)

As a result of acquisitions, EB Health now owns many multiplatform applications written in the Java or .NET programming language and must build a Single Sign-On (SSO) strategy that caters to the platforms EB Health supports. Here are the requirements:

• An SSO architecture for both Java and non-Java applications with Access Manager.
  
  
• Enhancement of the fine-grained model for faster performance. Applications with many secure widgets on a page require multiple invocations to the Access Manager for policy evaluation; hence, performance deteriorates.
  
  
• Extension of the Role-Based Access Control (RBAC) authorization to support non-Java applications in the fine-grained authorization model.

Read on for the details of the EB Health solution and the design that fosters the required capabilities. The solution builds on top of the concepts described in Part 1.

The overall architecture is the same as that for Part 1. Thanks to Access Manager Policy Agents, you can secure applications on platforms such as .NET by installing a Policy Agent on Microsoft Internet Information Services (IIS) Web server. Afterward, the IIS agent achieves SSO by authenticating users at the centralized Access Manager instance and allowing users access to the secured applications. Access Manager Policy Agents are supported on most industry-standard Web and Java EE containers.

Figure 1 shows the architecture with updated Java and non-Java application platforms.

Figure 1: Architecture

You can configure the Policy Agents for IIS and Apache Web servers in either of these two modes:

• URL_POLICY mode, in which the Policy Agents intercept all incoming HTTP or HTTPS requests and validate them for authentication, session validity, and authorization.
  
  
• SSO_ONLY mode, in which the Policy Agents intercept all incoming HTTP or HTTPS requests and validate them for authentication and session validity only.

Subsequently, SSO becomes a reality across multiple platforms, propagating user information to the container in which the users are executing.

Once a user authenticates and is authorized to access the URL in question, application components created with JavaServer Pages or Active Server Pages technology can extract the SSO session token to further invoke Access Manager and perform additional authorization calls. See Part 1 for details.

This section elaborates on how to satisfy the performance requirements for applications that secure pages with many fields on a single page. The development of fine-grained authorization discussed in Part 1 is through the Access Manager SDK, which evaluates policies for the page's resources. When multiple objects require authorization, multiple calls are made to Access Manager by the SDK.

To alleviate performance concerns about applications that secure many resources, EB Health uses a few Access Manager server-side APIs to build a hierarchy-based resource model that represents an application's resources. Figure 2 illustrates the design of the resource hierarchy.

Figure 2: Resource Hierarchy

Here, instead of defining a single resource, a string defines a parent and children by delimiting the resource hierarchy with forward slashes. For example:

ClaimsApp/UserForm/SSN_FORM_FIELD
ClaimsApp/UserForm/UID_FIELD
ClaimsApp/UserForm/PHONE_NUM_FIELD

ClaimsApp is the application name; UserForm is the page; and SSN_FORM_FIELD, UD_FIELD, and PHONE_NUM_FIELD are the fields on the page.

Here's another example:

MacMail/NewMessageWindow/AddressButton

To define a resource, EB Health follows the procedure described in Part 1 (see Figure 3), but adheres to the new naming convention, that is, denotes the resource hierarchy with forward slashes.

Figure 3: Definition of a Resource

The resource model now requires a service on the server side, where EB Health deployed Access Manager to invoke the API for evaluating policies. Bottom line: EB Health must invoke the service for the parent resource and acquire the authorization level for the parent and its resources. EB Health adopts the Transfer Object pattern, which enhances performance by making a single invocation instead of multiple ones across the network.

JAX-WS now comes into play. The service encapsulates the Access Manager API calls by exposing a single Web-service endpoint to its clients and thus highlights itself as a JAX-WS service.

The design of the authorization service fulfills EB Health's last requirement: Institute fine-grained authorization to non-Java clients by creating an interoperable Web service.

The Web-service endpoint serves as an interoperable service that EB Health can invoke with Simple Object Access Protocol (SOAP) over HTTPS from Java and .NET applications. See Figure 4 for the architecture.

Figure 4: Architecture for Web-Service Endpoint

On the client side, both the Java and .NET applications are protected by the Access Manager Policy Agent to secure access and to ensure the validity of the SSO token. That translates to an enforcement of the policy on the URL level and an SSO architecture across application platforms. The clients achieve fine-grained authorization by invoking the Web service through their Web-service APIs.

EB Health implements the authorization service as a JAX-WS Web-service endpoint that runs in the same container as Access Manager to make use of the server-side Access Manager APIs. The Web service evaluates the policy and returns the decisions—access levels—to the requestor (application).

Consider this example—a method signature of the Web service:

public AccessLevelResultSet authorize(String ssoTokenStr, String serviceName, String resource)

The method involves three parameters:

• ssoTokenStr, the SSO Token string from Access Manager after successful authentication. The application can extract this string from the cookie iPlanetDirectoryPro (in the case of a .NET application) or from HttpServletRequest (in the case of a Java application) with Access Manager SDK APIs.
  
  
• serviceName, the custom policy-enabled service in which to define the rules and resources. An example is CustomClaimsAppPolicyService.xml created in Part 1.
  
  
• resource, a string representation of the resource being evaluated by Access Manager.
  
  For instance, when EB Health requests all the permissions for the ClaimsApp resource—
  
  

  authorize (ssoTokenStr, "CustomClaimsAppPolicyService", "ClaimsApp/UserForm");

   
  

  —the SDK returns the ClaimsApp access level and its children:

  ClaimsApp/UserForm = ALL ClaimsApp/UserForm/SSN_FORM_FIELD = READ ClaimsApp/UserForm/UID_FIELD = UPDATE ClaimsApp/UserForm/PHONE_NUM_FIELD = UPDATE

   
  Consequently, each application can decide when to invoke an authorization method for the desired performance.

EB Health develops the Web service in the NetBeans IDE, which contains an intuitive interface for building Java applications and Web services alike. A configuration tab is available for plugging into Web containers, resulting in a fast deployment.

Configuration and Deployment
EB Health configures, deploys, and executes the service within the GlassFish Application Server container along with Access Manager. Figure 5 shows the main window of the NetBeans IDE.

Figure 5: NetBeans IDE (Click image for larger view.)

This code fragment shows the server-side components that evaluate policies:

/**
 * Web service operation
 */
@WebMethod
public AccessLevelResultSet
    authorize(@WebParam(name = "ssoTokenStr")String ssoTokenStr, @WebParam(name =
"serviceName") String serviceName, @WebParam(name = "resource") String resource) {
    AccessLevelResultSet results = null;

    try {
    // Use the SSOTokenManager to get an instance of the SSOToken object from
    // the string passed from the client.

 	SSOTokenManager tokenMgr = SSOTokenManager.getInstance();
	SSOToken ssoToken = tokenMgr.createSSOToken(ssoTokenStr);

	PolicyEvaluator polEval = new PolicyEvaluator(serviceName);
	Set resourceResults = polEval.getResourceResults(ssoToken,resource,ResourceResult.SUBTREE_SCOPE,new HashMap());
	results = new AccessLevelResultSet(resourceResults);
    }
    catch (SSOException ssoe) {
    }
    catch (NameNotFoundException nnfe) {
    }
    catch (PolicyException pe) {
    }
    return results;
}

By way of explanation—

• PolicyEvaluator, the evaluator's server-side version, enables policy evaluation according to the resource in question.
  
  
• ResourceResult specifies the scoping level on which to base the policy decision.
  
  
• ResourceResult.SUBTREE_SCOPE obtains policy decisions for only the resource or for the resource and its subresources.
  
  
• AccessLevelResultSet, a serializable class, represents with primitive objects the access-level values for the resources from the Access Manager policy evaluator. To ensure interoperability between the Java and .NET platforms, EB Health codes this class with simple data types.

Testing
To test the Web service, EB Health first generates a client in the NetBeans IDE and then employs the client code as a Business Delegate within the Web application to encapsulate the intricacies associated with invoking JAX-WS. That is, EB Health incorporates the code in the application to perform authorization calls with the Web service endpoint.

To generate client stubs within the IDE, choose New > Web Service Client. A window is then displayed in which to specify the location of the Web service endpoint. See Figure 6.

Figure 6: Generation of Client in NetBeans IDE

With the location of the Web Services Description Language (WSDL), the NetBeans IDE can obtain the information on the Web service and generate the appropriate client artifacts.

This Java-client snippet invokes the Web service within an application:

public AccessLevelResultSet authorize(String resource) {
    AccessLevelResultSet results = null
    try {
        EBHealthAuthZWSService service = new com.ebhealth.claims.EBHealthAuthZWSService();
	EBHealthAuthZWS port = service.getEBHealthAuthZWSPort();

	results = port.authorize(ssoTokenStr, serviceName, resource);
    }
    catch (Exception ex)
    {}

    return results;
}

Assuming that the application is protected by a Policy Agent, the authorize call requires an SSO token string that the application can extract from either HttpServletRequest or the cookie. The policy service is the custom service (CustomClaimsAppPolicyService) that hosts the rules for the application. The resource is the unique string that denotes an application, module, or page; or a widget on a page.

The following code segment is an equivalent C# for invoking the Web service:

public AccessLevelResultSet authorize(String resource) {
    AccessLevelResultSet result = null;

try {
        EBHealthAuthZWS authZWS = new AuthZWS();

	authorizeRequest request = new authorize();
	authorizeRequest.String_1 = ssoTokenStr;
	authorizeRequest.String_2 = serviceName;
	authorizeRequest.String_3 = resource;

    authorizeResponse response = authZWS.authorize(myPermissionRequest);
    result = Converter.toAccessLevelResultSet(response.result);
    }
    catch (SecurityServiceException sse)
    {}
    return(result);
}

For details on Web services and .NET framework, see the References section below. To learn about method signatures in the Web service, see Sun Java System Access Manager 7.1 API.

The EB Health example demonstrates how you can extend Access Manager to meet some of the common enterprise requirements for access management. The Policy Agent's architecture caters to many industry-standard application servers, offering authentication, authorization, and SSO capabilities. In addition, because of its APIs and configurable service layer, Access Manager is ideal for achieving fine-grained authorization for both Java and non-Java applications.

Our appreciation to Bartosz Adamczyk, Dilli Dorai, Ramesh Nagappan, and Pat Patterson at Sun for their prompt reviews and excellent comments.

• Sun Java System Access Manager
  • Main page
  • Developer home
  • Software Forum
  • Related documentation
    • Technical Overview
    • Postinstallation Guide
    • Administration Guide
    • API
    • Policy Agent 2.2 User's Guide
  
  
• Technologies and IDE
  • Web Services and the .NET Framework
  • Core J2EE Patterns
  • Core Security Patterns
  • NetBeans IDE
  
  
• Related open-source projects
  • OpenSSO
  • GlassFish
  • Metro
  
  
• Related article: Securing Applications With Identity Services
  • Part 1: Authentication
  • Part 2: Authorization
  
  
• Sun developer services
  • Support
  • Training and certification