Understanding the Authorization Process

Businesses have applications and services that they need to protect. A policy defines rules that specify who or what can access these protected resources. The rules are, in effect, permissions describing when and how a principal can perform an action on a given protected resource. (A principal can be an individual, a corporation, a role, or a group.) In general, the permissions define what a principal can do to which resource and under what conditions. Towards this end, OpenSSO Enterprise provides the Policy Configuration Service to define global and realm preferences that effect the Policy Service which is used to create and manage the policies. (For more on the Policy Configuration Service, see Policy Configuration in Sun OpenSSO Enterprise 8.0 Administration Reference.)

The Policy Service allows administrators to define, modify, grant, revoke and delete the policies that protect resources within the OpenSSO Enterprise deployment. Typically, a policy service includes a repository to store policies, interfaces that allow for the creation, administration and evaluation of policies, and a policy agent to enforce the policies. By default, OpenSSO Enterprise uses the configuration data store for policy storage, and the OpenSSO Enterprise console for policy management. Policy agents specifically developed for OpenSSO Enterprise act as the policy enforcement point (PEP). (OpenSSO Enterprise also provides Java and C interfaces for policy creation, policy evaluation, policy agent development, and Policy Service customization. See the Sun OpenSSO Enterprise 8.0 Developer’s Guide and the Sun OpenSSO Enterprise 8.0 C API Reference for Application and Web Policy Agent Developers for more information.)

The policy agent is installed remotely from OpenSSO Enterprise and serves as an authorization step (following user authentication) when a user requests access to a protected resource. For example, a Human Resources server that is protected by a remote instance of OpenSSO Enterprise has an agent installed on it to act as a PEP. This agent would prevent personnel without the proper permission from viewing confidential salary information or other sensitive data. (More information on installing and administrating the policy agents can be found in the Sun OpenSSO Enterprise Policy Agent 3.0 User’s Guide for J2EE Agents and the Sun OpenSSO Enterprise Policy Agent 3.0 User’s Guide for Web Agents. Most policy agents can be downloaded from the Sun Microsystems Download Center.)

The authorization process begins when a web browser requests a URL that resides on a server protected by the policy agent. The policy agent installed on the server intercepts the request and checks for an existing OpenSSO Enterprise session token (SSOToken) for authentication credentials. If the session token is valid, the user is allowed or denied access based on the applicable configured policy. If the token is invalid or there is no existing session token, the user is redirected to the Authentication Service and the following occurs.

1. The policy agent redirects the user to the Authentication Service login page.

2. The user submits credentials for authentication.

3. Assuming successful authentication, the agent issues a request to the OpenSSO Enterprise Naming Service.

4. The Naming Service returns locators for the Policy Service, the Session Service, and the Logging Service.

5. The policy agent sends a request to the Policy Service for the policy applicable to the requesting user and resource.

6. Based on the returned policy, a decision is reached and the user is allowed or denied access.

   The policy agent may redirect the request back to the Authentication Service if the policy decision indicates a different authentication level or authentication mechanism is needed.

In addition, the Resource Comparator attribute in the Policy Configuration Service would also need to be changed from its default configuration to:

serviceType=Name_of_LDAPService |class=com.sun.identity.policy.plugins.SuffixResourceName|wildcard=*

|delimiter=,|caseSensitive=false

Alternately, providing an implementation such as LDAPResourceName to implement com.sun.identity.policy.interfaces.ResourceName and configuring the Resource Comparator appropriately would also work.