Sun Java logo     Previous      Contents      Index      Next     

Sun logo
Sun Java System Identity Server 2004Q2 Technical Overview 

Chapter 3
Access Management

Sun Java™ System Identity Server implements authentication and policy administration to regulate access to the many types of information stored in a company’s enterprise. When an enterprise user requests information, Identity Server verifies that 1) the user is who he says he is, and 2) the user is authorized to access the specific resource he’s requested. This chapter provides an overview view of Identity Server access management features and functionality.

Topics included in this chapter are:


Authentication

Authentication is the process of verifying that a person is who he says he is. Identity Server comes with an authentication service for verifying the identities of users who request access to web resources within an enterprise. For example, a company employee who needs to look up a colleague’s phone number uses a browser to go to the company’s online phone book. To log in to the phone book service, the employee must provide his user name and password. Identity Server compares the user’s input with data stored in Directory Server. If Identity Server finds a match for the user name, and if the given password matches the password stored in Directory Server, then Identity Server can verify the user’s identity, and the user is authenticated. Access is granted, and the user corporate phone book is displayed to the user.

Client Detection

An initial step in the authenticating process is to identify the type of client making the HTTP(S) request. This Identity Server feature is known as client detection. The URL information is used to retrieve the client’s characteristics and, based on these characteristics, the appropriate authentication pages are returned. For example, when a Netscape browser is used to request a web page, Identity Server displays an HTML login page. Once the user is validated, the client type ( Netscape browser) is added to the session token.

Basic Authentication

There are a number of ways to access Identity Server for basic authentication. Java™ and C applications can use the Java and C authentication APIs to connect to Identity Server, while end users open a connection to Identity Server using a web browser.

Users Using A Web Browser

A user with a web browser can authenticate to Identity Server using the Authentication User Interface. The URI for this web-based interface is:

http://identity_server_host.domain_name:port/amserver/UI/Login.

After entering the URL, the user is prompted to submit verifying credentials. Once the credentials have been passed back to Identity Server, the user gains (or is denied) access based on their privileges:

Java Applications

External Java applications can authenticate to the Identity Server to access any of its protected resources using the Authentication API for Java. This API provides interfaces to initiate the authentication process and communicate authentication credentials to the Authentication Service. The API is defined in a Java package called com.sun.identity.authentication. Developers incorporate the classes and methods from this package into their Java applications to allow communication with the Authentication Service. The application’s Java request is first converted to an XML message format and passed to the Identity Server over HTTP(S). Once received, the XML message is converted back into a Java request which can be interpreted by the Authentication Service.

C Applications

Identity Server also includes resources for C applications to authenticate to the Identity Server. This API provides functions to initiate the authentication process and communicate authentication credentials to the Authentication Service. After passing the authentication process, a validated session token is sent back to the C application.

The Authentication User Interface

The Authentication Service has a separate user interface from the Identity Server console. It provides the web-based interface for all authentication modules installed in the Identity Server deployment. The user interface provides a dynamic and customizable means for gathering authentication credentials by presenting the web-based login requirement pages to a user requesting access. Figure 3-1 is a screenshot of the default user interface for LDAP authentication.

Figure 3-1  LDAP Authentication User Interface

Screenshot of default LDAP Authentication User Interface.

Single Sign-On

When a user wants to access multiple resources protected by Identity Server, the Session Service provides proof of authentication.This makes it possible for a user to access more than one service in a single user session without having to re-authenticate.

For example, when a user logs into his email account, he provides his username and password. Once verified, the mail service calls the Single Sign-On (SSO) API to generate an SSO or session token which holds the user’s identity information. The API also generates a token ID, a random identification string associated with the session token. The session token is then sent back to the requesting browser in the form of a cookie.

When the user logs into another service within the same domain, for example the corporate phone book, the same session token is passed to the phone book service and validated, verifying the user’s previous authentication. The user is granted access to the corporate phone book without being asked to re-enter his username and password. This is single sign-on, and the Session Service is what gives Identity Server this functionality.

Cross-Domain Single Sign-On

A user authenticated to Identity Server in one domain can access protected resources in another domain. This functionality is called cross-domain single sign-on (CDSSO). In a single-domain deployment, policy agents are configured to re-direct requests from un-authenticated users to the Authentication Service for login. In a cross-domain SSO deployment, agents are configured to re-direct requests from un-authenticated users to the Cross-Domain Controller servlet for login.

Policy Agents

A policy agent protects the web server or application server on which a resource lives by evaluating and enforcing a user’s assigned policies. Two types of policy agents are supported by Identity Server: the web agent and the J2EE/Java agent. The web agent enforces URL-based policy, while the J2EE/Java agent enforces both J2EE-based security and URL-based policy.

Cross-Domain Controller

The Cross-Domain Controller (CDC) is a servlet that communicates with policy agents outside its own domain, and then checks for a user’s SSO information. If no SSO information exists for the user, request is redirected back to servlet. If SSO information for the user is available, the servlet extracts the information and redirects the browser back to the Policy Agent. After receiving the request from the servlet, the policy agent reads the SSO information and uses it to set the cookie credentials in the foreign domain.

Figure 3-2  Single-domain SSO vs. Cross-domain SSO

The figure illustrates how the CDSSO controller is used in cross-domain Single Sign-On, but not in single-domain Single Sign-On.

Figure 3-2 compares the sequence of SSO events in a home domain (Domain1) with the sequence of SSO events in a foreign domain (Domain2). The home domain contains Identity Server with the CDC enabled. A foreign domain is any domain other than the home domain. In this example, within Domain1, when the user tries to access a protected resource in Domain1 via a browser (A), the request is intercepted by a policy agent installed on the Application Server. The policy agent redirects the request directly to the Identity Server Authentication service (B). The Authentication service checks the user’s credentials in Directory Server (C), and returns an SSO token to the policy agent (D). Once, authenticated, the Application Server displays the protected web content in the browser (E).

In a cross-domain scenario, when the user tries to access a protected resource in Domain2 via a browser (1), the request is intercepted by a policy agent installed on the Application Server. The policy agent redirects the request to cross-domain controller which resides with Identity Server in Domain 1 (2). If SSO information for the user is available in Directory Server (3) the servlet extracts the information and redirects it back to the Domain2 policy agent (4). After receiving the request and the SSO information from the servlet, the Domain2 the policy agent reads the SSO information and uses it to set the cookie in Domain1 for authentication purposes. Once the user is authenticated, the Application Server displays the protected web content in the browser (E).


Policy Management and Configuration

A policy is a rule that describes who is allowed or authorized to access a specific web resource. Identity Server provides a policy management service and policy configuration service for creating such rules and evaluating policies. Policy agents are an integral part of an Identity Server deployment, and they help to enforce access policies.

For example, in a typical enterprise, one policy is applied to an entire organization. The policy specifies that all users within the organization can access all web servers within the enterprise firewall. Another policy is applied to employees in the Human Resources group, and specifies that they are authorized to access all web servers that store Human Resources data. A third policy specifies that employees who are mangers are authorized to confidential personnel records stored on Human Resources web servers. When an employee tries to access the confidential records stored on the Human Resources web servers, the policy service evaluates the policies that apply to the employee requesting the records. The policy service determines that although the employee is authorized to access servers within the firewall, the employee is not member of the Human Resources group nor of any manager group. Therefore the employee is not authorized to view the confidential personnel records he is requesting. An “access denied” message is displayed.

Policy Framework

The Policy Service provides a framework for defining, modifying, granting, revoking and deleting policies within an enterprise. The policy framework interacts with Sun Java System Directory Server for data storage. The policy framework also includes C APIs for policy evaluation, Java™ APIs for both policy evaluation and administration, and a selection of downloadable policy agents that enforce the policies.

Policy Configuration

The Policy Configuration Service is also provided to allow the configuration of policy-related attributes per organization. You can define in this service the resource name implementations and Directory Server data stores to use for authorization. For additional information, see “Chapter 33, Policy Configuration Attributes” of the Sun Java System Identity Server Administration Guide.

Policy Agents

The Policy Agent is the Policy Enforcement Point (PEP) for a server on which enterprise resources are stored. Policy agents are provided as self-contained components, and are separate from Identity Server. All of the Identity Server Policy Agents can be downloaded from the Sun Microsystems Download Center.

In one scenario, for example, a Human Resources web server is protected remotely by Identity Server, and has policy agent installed on it. This agent prevents personnel without the proper credentials and policy from viewing confidential salary information and other sensitive data. The policies are defined by an Identity Server administrator, stored within the Identity Server deployment and used by the policy agent to allow or deny users access to the remote server’s content. More information on installing and managing the policy agents can be found in the Sun Java System Identity Server Policy Agents Guide

Policy Types

There are two types of policies that can be configured using Identity Server: conditional policies and referral policies. A conditional policy, also referred to as a normal policy, specifies two things: 1) a resource, and 2) who is allowed to access the resource. Only a Top-Level Administrator can create or manage conditional policies that apply to the whole directory. A referral policy makes it possible for a Top-Level Administrator to delegate policy configuration tasks to an Organization Administrator.

Conditional Policy

A policy that defines access permissions is a conditional policy, also referred to as a normal policy. A conditional policy consists of Rules, Subjects, and Conditions.

Rules

A rule contains a resource, one or more sets of an action, and a value. It defines the policy.

Subjects

A subject defines the user or collection of users (for instance, a group or those who possess a specific role) that the policy affects. Subjects are assigned to policies. The default subjects are:

Conditions

A condition defines the situations in which a policy is applicable; for instance, a 7 am to 10 am condition defined in a policy restrains the subject(s) to access between 7 am to 10 am.

Referral Policy

A policy used for delegation is a referral policy. A referral policy delegates both policy creation and policy evaluation. It consists of one or more rules and one or more referrals.

For example, consider a deployment whose root level organization is dc=example,dc=com with sub-organizations dc=sunOne,dc=example,dc=com and dc=sunTwo,dc=example,dc=com. See Figure 3-3. In order to define or evaluate policies at dc=sunOne,dc=example,dc=com or dc=sunTwo,dc=example,dc=com, two referral policies must be created. One policy points from the root level to dc=sunOne,dc=example,dc=com. One policy points from the root level to dc=sunTwo,dc=example,dc=com.

Figure 3-3  Root-level policies

The figure illustrates a root-level organization with two suborganizations beneath it.

Each referral policy contains the resource (or resource prefix) being managed. If dc=sunOne,dc=example,dc=com manages http://www.sunOne.com/, the referral policy at dc=example,dc=com contains http://www.sunOne.com/ in its rule and refers policy creation to the dc=sunOne,dc=example,dc=com sub-organization. Only after creating root level referral policies can policies at the sub-organization level be created.

Policy Management Architecture

The Policy management feature allows for the protection of all types of applications and resources. Figure 3-4 illustrates the architecture of the Policy Service. As shown, custom agents or applications can be written to protect other types of resources including services or other applications.

Figure 3-4  Policy Management Architecture

Graphic detailing Policy Service architecture.

The process for protected web resources begins when a web browser requests a URL that resides on a remote server; the server’s installed policy agent intercepts the request and checks for existing authentication credentials (a session token). If none exists or the existing authentication level or policy conditions are insufficient, the request is redirected to the Authentication Service where the user must go through the authentication process.

Once the user session is created or upgraded with a successful authentication, Identity Server responds to the browser request with a redirect to the original resource. The agent now finds a sufficient session token and issues a request to the Naming Service. (The Naming Service defines the URLs that can be used to access Identity Server internal services.) The Naming Service returns locators for the Policy Service which the agent will use to check the user’s policy, and for the Session Service which will be used to verify the user’s session. Based on the aggregate of all policies assigned to the user, the individual is either allowed or denied access to the protected resource.



Previous      Contents      Index      Next     


Copyright 2004 Sun Microsystems, Inc. All rights reserved.