Sun Java System Access Manager 7.1 Technical Overview

Chapter 1 Introduction to Access Manager

Sun Java^TM System Access Manager 7.1 integrates authentication and authorization services, policy agents, and identity federation to provide a comprehensive solution for protecting network resources. These functions allow an Access Manager deployment to prevent unauthorized access to web service applications and web content. Topics in this introductory chapter include:

An Access Management Paradigm

Think of all the different types of information a company must store and make available throughout its enterprise. Now consider the various users who must make use of that information in order for the company’s business to run smoothly. For example, the following are routine information transactions that occur every day in a typical company:

An employee looks up a colleague’s phone number in the corporate phone directory.
A manager looks up employee salary histories to help determine an individual’s merit raise.
An administrative assistant adds a new hire to the corporate database, triggering the company’s health insurance provider to add the new hire to its enrollment.
An engineer sends an internal URL for a specification document to another engineer who works for a partner company.
A customer logs into the company’s web site and looks for a product in the company’s online catalog.
A vendor submits an online invoice to the company’s accounting department.

In each of these examples, the company must determine who is allowed to view its information or use its applications. Some information such as the company’s product descriptions and advertising can be made available to everyone, even the public at large, in the company’s online catalog. Other information such as accounting and human resources information must be restricted to employees only. And some internal information is appropriate to share with partners and suppliers, but not with customers.

The Problem

Many enterprises grant access to information on a per-application basis. For example, an employee might have to set up a user name and password to access the company’s health benefits administration web site. The same employee must use a different user name and password to access the Accounting Department online forms. Within the same enterprise, a customer sets up a user name and password to access the public branch of the company web site. For each web site or service, an administrator must convert the enterprise user’s input into a data format that the service can recognize. Each service added to the enterprise must be provisioned and maintained separately.

The Solution

Sun Java System Access Manager reduces the administrative costs and eliminates the redundant user information associated with per-application solutions. Access Manager enables an administrator to assign specific rules or policies that govern the information or services each user can access. Policy agents are deployed on application or web servers to process HTTP requests and to enforce these policies. Together, these access policies and the associated user’s information comprise the user’s enterprise identity. Thus, Access Manager makes it possible for a user to access many resources in the enterprise with just one identity.

What Access Manager Does

When an enterprise user or an external application tries to access content stored on a company’s server, an Access Manager policy agent intercepts the request and directs it to the Access Manager server. Access Manager then asks the user to present credentials such as a username and password. If the credentials match those stored in the appropriate identity repository, Access Manager determines that the user’s credentials are authentic.

Following authentication, the Access Manager policy agent evaluates the policies associated with the user’s identity to determine authorization to access the requested content. Policies are created using Access Manager and identify which users (or groups of users) are allowed to access a particular resource, specifying the conditions under which this authorization is valid. Based upon the policy evaluation results, the policy agent either grants or denies the user access to the information. Figure 1–1 below illustrates one way Access Manager can be configured to act as the gatekeeper to a company’s information resources.

Figure 1–1 Access Manager as Gatekeeper to a Company's Enterprise Resources

This figure illustrates how Access Manager controls
access among customers, employees, and employee administrators.

Access Manager Installation Modes

When you install Access Manager, you are asked to choose either Realm Mode or Legacy Mode. Realm Mode is the new Access Manager architecture; Legacy Mode is based on the Access Manager 6.3 architecture. The following table briefly compares these options. The sections following the table give a more in-depth explanation of each installation modes.

Table 1–1 Comparison of Realm and Legacy Modes


	Realm Mode	Legacy Mode
Supports all new Access Manager 7.1 features.	Yes	Yes
Supports identity repositories in Sun Java System Directory Server and other data stores.	Yes	Yes
Supports Access Manager 6 user management features.	No	Yes
Can coexist with Access Manager 6 2005Q1 in multiple-server installations.	No	Yes
Before installation, identity repository can exist in Sun Java Directory Server .	Yes	Yes
Before installation, identity repository can exist in an LDAP version 3 compliant directory server.	Yes	No

To determine if an already installed instance of Access Manager is running in realm or legacy mode, type the following into the location bar of your web browser:

protocol://FQDN_server:port/amserver/SMSServlet?method=isRealmEnabled

The server will return true if running in realm mode. More information on the installation modes can be found in the following sections:

Realm Mode

Realm mode is based on the Access Manager information tree and Identity Repository Management Service described in previous sections. Realm Mode is appropriate in most new Access Manager deployments where you want to keep identity repositories independent of access management, or where you cannot maintain user data within the required object classes of Sun Java System Directory Server. If you choose Realm Mode at installation, your identity repositories can exist in any of the following configurations:

In the same Directory Server instance and the same suffix as the Access Manager information tree.
In the same Directory Server instance but in a different suffix as the Access Manager information tree.
In a different directory server instance from the Access Manager information tree.

Figure 1–2 is a screen capture of the Access Manager Administration Console when the product has been installed in Realm Mode.

Figure 1–2 Realm Mode User Interface

This figure illustrates the Access Manager administration
console in Realm Mode.

Legacy Mode

Legacy Mode is based on the Access Manager 6.3 architecture. This legacy Access Manager architecture uses the Lightweight Directory Access Protocol (LDAP) directory information tree (DIT) that comes with Sun Java System Directory Server. In Legacy Mode, both user information and access control information are stored in LDAP organizations. When you choose Legacy Mode, an LDAP organization is the equivalent of an access control realm. Realm information is integrated within LDAP organizations.

Legacy Mode is appropriate in deployments where you want to use Access Manager user management. It is typically used in deployments where Access Manager is built upon Sun Java System Portal Server or other Sun Java System communication products that require the use of Sun Java System Directory Server as the central identity repository. If you choose Legacy Mode during installation, the top-level ream resides in the same Directory Server branch as the Access Manager information tree, and user information is intermingled with access information.

Figure 1–3 is a screen capture of the Access Manager Administration Console when the product has been installed in Legacy Mode.

Figure 1–3 Legacy Mode User Interface

In Legacy Mode, a Directory Management tab is
added to the Access Manager administration console.

Access Manager Architecture

Access Manager uses a Java technology-based architecture for scalability, performance, and ease of development. It also leverages industry standards including the HyperText Transfer Protocol (HTTP), the eXtensible Markup Language (XML), the Security Assertion Markup Language (SAML), and SOAP. The internal architecture is multi-layered and includes the following:

A presentation layer
Web services
Core components
Client application programming interfaces (APIs)
Service provider interfaces (SPIs)
An integrated framework
A plug-ins layer

Custom applications access the Access Manager web services through the Access Manager client APIs installed on each protected resource. Custom plug-in modules interact with both the Access Manager SPIs and the plug-ins layer. The plug-in modules retrieve required information from the Access Manager information tree and deliver it to other plug-ins when necessary, and to the Access Manager framework for data processing. Additional information can be found in the following sections.

Access Manager Framework

The Access Manager framework is where the Access Manager business logic is implemented. Each core component uses its own framework to retrieve customer data from the plug-in layer and to provide data to the core components. The Access Manager framework integrates all of these frameworks to form one layer in the architecture that is accessible to all core components and Access Manager plug-ins. Figure 1–4 illustrates the plug-ins layer, Access Manager framework, core components, and web services that form the Access Manager architecture.

Figure 1–4 Access Manager Internal Architecture

Plug-ins layer, framework, core components, and
web services form the Access Manager architecture. Client API is installed
on the protected resource.

Access Manager Information Tree

When installed in Realm Mode, Access Manager creates a special and proprietary branch in an LDAP data store for storing realm configurations, authentication properties, and authorization policies. Access Manager components and plug-ins access the data stored in the Access Manager information tree, and use it for various purposes including the following examples:

Policy runtime accesses policy data for policy evaluation.
Identity Repository plug-in finds configuration information for data stores.
Authentication Service finds authentication configuration information.

By default, the Access Manager information tree is created and maintained by Access Manager as a special branch in Sun Java System Directory Server, apart from any user data (identity repository). Figure 1–5 illustrates this default configuration.

Figure 1–5 Default Configuration for Access Manager Information Tree

Both the identity repository and the Access Manager
information tree can be installed on the same instance of Directory
Server.

But, the Access Manager information tree can also be created in a directory that is separate from the one hosting the Access Manager Identity Repository. Figure 1–6 illustrates this custom configuration.

Figure 1–6 Access Manager Information Tree Configured in Second Data Store

The identity repository can reside in one data
store, and the Access Manager information tree can reside in a different
data store.

The following figure compares two directory information trees: the first illustration represents a default hierarchical LDAP structure while the second represents the structure when the Access Manager information tree is integrated.

Figure 1–7 Directory Server With and Without an Access Manager Information Tree

This figure compares a default directory information
tree (DIT) with a DIT that includes the Access Manager information
tree.

Realms

An Access Manager realm is a grouping of configuration information that you can associate with a user, a group of users, or a collection of protected resources. The configuration information can include, but is not limited to, the following:

A definition of one or more identity repositories, identifying a set of users, groups, and roles to whom the remaining realm configuration information applies.
An authentication configuration, identifying, for example, the location of the authentication repository, and the type of authentication required.
Policy information that will be used to determine which resources protected by Access Manager the subjects can access.
Responder information that allows applications to personalize the user experience, once the user has successfully authenticated and been given access.

The Access Manager framework aggregates realm properties within the proprietary Access Manager information tree. The following figure illustrates how realm data stored in an Access Manager information tree can be grouped by region and by company functions.

Figure 1–8 Realm Data in Access Manager Information Tree

This graphic illustrates how access information
can be grouped by region and by company functions.

Identity Repository Framework

An identity repository is a data store where information about users and groups in a company or organization is stored. The Access Manager Identity Repository Framework and related APIs are a model by which plug-ins can be written that allow communication with different types of identity repositories. Following is an illustration of the Identity Repository Framework and how it is integrated within the other features of Access Manager.

Note –

The information in an identity repository is maintained by provisioning products separate from Access Manager. The supported provisioning product is Sun Java System Identity Manager. See Sun Java System Identity Manager for more information.

The Identity Repository Framework is configured as a service within an Access Manager realm. Multiple identity repository plug-ins can be configured for each realm. Each plug-in configuration includes details about what operations are supported on each of the identity types based on the underlying data store. Once an Access Manager realm is configured to use a plug-in, the Identity Repository Framework will instantiate it and execute operations on the identity repository it supports. This model allows the following:

Data store independence enables you to view and retrieve user information without making changes to your existing user database.
Universal identities allow you to access the many profiles of one identity across multiple data repositories, if necessary.
Caching helps to improve repository read performance.

When deploying Access Manager, you must choose one or more of the supported plug-ins based on the data store. You can configure the Identity Repository Service per realm to use its own list of identity repositories to store service configurations for both users and roles. The Access Manager framework integrates data from the identity repository plug-in with data from other Access Manager plug-ins to form a virtual identity for each user. Access Manager can then use this identity in authentication and authorization processes among more than one identity repositories. The virtual user identity is destroyed when the user’s session ends.

Each new plug-in developed must have a corresponding service management schema defining its configuration attributes. This schema is enveloped into the service management file for the Identity Repository Service (named idRepoService.xml) as a sub schema. Currently, Access Manager provides out-of-the-box plug-in support for the following types of identity repositories:

Access Manager Repository Plug-in (Sun Java System Directory Server)

The Access Manager Repository can reside only in Sun Java System Directory Server. During installation, the repository itself is created in the same instance of Sun Java System Directory Server that holds the Access Manager information tree. (This is the default installation mode when using the Sun Java Enterprise System installer.) The two information trees are configured in separate nodes under a single directory suffix. The Access Manager Repository Plug-in is designed to work with Sun Java System Directory Server as it makes use of features specific to the server including roles and class of service. It uses a DIT structure similar to that of previous versions of Access Manager.

Note –

Previously, the functionality of this plug-in was provided by the AMSDK component. In Access Manager 7.1, the AMSDK functionality still exists, but as a plug-in only. (See AM SDK Plug-in.) Thus, the Access Manager Repository is compatible with previous versions of Access Manager.

When you configure an instance of Access Manager in realm mode for the first time, the following occurs:

An Access Manager Repository is created under the top-level realm.
The Access Manager Repository is populated with internal Access Manager users.

Note –

The Java Enterprise System installer does not set up an Access Manager Repository when you configure an Access Manager instance in legacy mode. Legacy mode requires an identity repository that is mixed with the Access Manager information tree under a single directory suffix.

Active Directory

This data store type uses the LDAP version 3 specification to write identity data to an instance of Microsoft® Active Directory®.

Generic Lightweight Directory Access Protocol (LDAP) version 3

Generic LDAPv3 identity repositories may reside on an instance of any directory that complies with the LDAPv3 specifications. The directory can not make use of features that are not part of the LDAP version 3 specification, and no specific DIT structure can be assumed as LDAPv3 identity repositories are simply DIT branches that contain user and group entries. The identity repositories might or might not reside in the same instance of Sun Java System Directory Server as the Access Manager information tree. Each data store has a name that is unique among a realm's data store names, but not necessarily unique across all realms in the Access Manager information tree. The com.sun.identity.idm.plugins.ldapv3.LDAPv3Repo class provides the default LDAPv3 identity repository implementation.

Note –

This configuration is not compatible with previous versions of Access Manager.

Flat Files Repository

This repository allows you to store data and identities in a flat DIT structure on the local installation of Access Manager without having to create a separate data store. This is generally used for testing or proof of concept deployments.

Note –

If deploying an instance of Access Manager from a single WAR file, the default identity repository is a flat file.

Sun Directory Server With Access Manager Schema

This repository resides in an instance of Sun Java System Directory Server and holds the Access Manager information tree. It differs from the Access Manager Repository Plug-in in that more configuration attributes allow for better customization.

Core Components and Internal Services

The core components provide the logic that performs the main Access Manager functions, working with the services that run within Access Manager. These internal services process data solely for use by Access Manager. The following table lists the core components and internal services with brief descriptions.

Table 1–2 Core Components and Internal Services


Core Component or Internal Service	What it Does
Authentication component	Validates user’s credentials and verifies that the user is who he claims to be.
Authorization (Policy) component	Evaluates policies to determine whether the user has permission to access the requested resource.
SAML component	Provides a protocol-based alternative to using cookies for performing a SSO session.
Federation component	Enables user to access resources provided by multiple business partners in a SSO session.
User Session Management component	Maintains information about user sessions, and enforces timeout limits. Provides continued proof of identity to enable single sign-on sessions.
Logging Service	Tracks a user’s interactions with web applications. Creates log messages to form an audit trail of important events within the system.
Naming Service	Defines URLs for other Access Manager components and internal services, enabling a client to locate them.
Platform Service	Manages configurable attributes used in an Access Manager deployment.
Client Detection Service	Detects the client type of the browser being used to access the Access Manager application. Client types include HyperText Markup Language (HTML) and Wireless Markup Language (WML), among other protocols.

Web Services

Web services follow a standardized way of integrating Web-based applications using XML, SOAP, and other open standards over an Internet protocol backbone. Web services enable applications from various sources to communicate with each other because they are not tied to any one operating system or programming language. Businesses use web services to communicate with each other and their respective clients without having to know detailed aspects of each other's IT systems. Access Manager provides web services that use XML and SOAP over HTTP. These web services are designed to be centrally provided in an enterprise's network for convenient access by client applications. The following table summarizes the web services provided in Access Manager.

Table 1–3 Access Manager Web Services


Web Service Name	Description
Authentication	Verifies that a user really is the person he claims to be.
Policy (Authorization)	Evaluates rules (policies) associated with a user’s identity, and determines whether an authenticated user has permission to access a protected resource.
SAML	Enables single sign-on sessions among different business domains. Allows business partners to securely exchange authentication and authorization information over the Internet.
Federation	Enables a user to log in at one service provider’s site and move to an affiliated service provider site without having to re-authenticate or re-establish identity.
Session	Maintains information about the user’s interaction with various applications the user accesses.

Access Manager uses both XML files and Java interfaces to manage web services and web service configuration data. An Access Manager XML file is based on the structure defined in a Document Type Definition (DTD) file which defines the structure, elements and qualifying attributes needed to form the valid XML document. The DTD files are located in AccessManager-base/SUNWam/dtd. The main sms.dtd file defines the structure for all Access Manager XML service files (located in /etc/opt/SUNWam/config/xml).

Caution –

Do not modify any of the Access Manager DTD files. The Access Manager APIs and their internal parsing functions are based on the default definitions. Alterations to the DTD files may hinder the operation of Access Manager.

SPIs and Plug-ins

The Access Manager SPIs work with plug-ins to provide customer data to the framework for back-end processing. Some customer data comes from external data base applications such as identity repositories while other customer data comes from the Access Manager plug-ins themselves. You can develop additional custom plug-ins to work with the Access Manager SPIs. For a complete listing of Access Manager SPIs, see the Sun Java System Access Manager 7.1 Java API Reference. The following sections contain brief descriptions of the plug-ins installed with Access Manager.

Authentication Plug-in

The Authentication Plug-in accesses user data in a specified identity repository to determine if a user’s credentials are valid.

Delegation Plug-in

The Delegation plug-in aggregates policies and roles to determine the scope of a network administrator’s authority. The Authentication Service and the Policy Service then use the aggregated data to perform authentication and authorization processes. The Delegation plug-in works together with the Identity Repository Management plug-in (where default administrator roles are defined) to form rules that describe the scope of privileges for each network administrator, and specifies the roles to which these rules apply. The following is a list of roles defined by the Identity Repository Management plug-in, and the default rule the Delegation plug-in applies to each.

Table 1–4 Access Manager Administrator Roles and Scope of Privileges


Administrator Role	Delegation Rule
Realm Administrator	Can access all data in all realms of the Access Manager information tree.
Subrealm Administrator	Can access all data within a specific realm of the Access Manager information tree.
Policy Administrator	Can access all policies in all realms of the Access Manager information tree.
Policy Realm Administrator	Can access policies only within the specific realm of the Access Manager information tree.

Note –

The Delegation plug-in code is not public in Access Manager.

Identity Repository Management Plug-in

The Identity Repository Management plug-in returns identity information such as user attributes and membership status for purposes of authentication.

Policy Plug-in

The Policy plug-in aggregates policies and rules to determine whether a user is authorized to access a protected resource.

Service Configuration Plug-in

The Service Configuration plug-in stores and manages configuration data required by the core components and other Access Manager plug-ins. In previous versions of Access Manager, the functionality provided by the Service Configuration plug-in was known as the Service Management Service (SMS).

AM SDK Plug-in

The AM SDK plug-in creates and modifies users and stores information in the user branch of the identity repository. It implements the user management APIs used in previous Access Manager releases.

Client APIs

Enterprise resources cannot be protected by Access Manager until the Access Manager client APIs are installed on the Web Server or Application Server that you want to protect. (The client APIs are automatically installed when you install a policy agent.) The client APIs allow you to customize an application by enabling communication with Access Manager for retrieving user, session, and policy data.

Access Manager Policy Agents

You install an Access Manager Policy Agent on a resource you'd like to protect to enforce the policy decisions determined by the Policy Service. The policy agent intercepts requests from applications, and redirects the requests to Access Manager for authentication. Once the user is authenticated, the policy agent communicates with the Policy Service for authorization. The policy agent allows or denies the user access depending upon the result of policy evaluation. Policy agents are downloaded and installed separately from the Access Manager server. For more information, see Sun Java System Access Manager Policy Agent 2.2 User’s Guide.

How Access Manager Works

When Access Manager starts up, it initializes the Access Manager information tree with configuration data from various Access Manager service plug-ins including those for Authorization, Policy, Identity Repository Management, and Service Configuration. When a browser sends an HTTP request for access to a protected resource, Access Manager immediately binds to the appropriate Identity Repository to obtain user information (which may include definitions for roles, realms, user IDs, and so forth). At the same time, a policy agent installed on the protected resource intercepts the request and examines it. If no session token is found, the policy agent contacts the Access Manager server which will then invoke the authentication and authorization processes. Figure 1–9 illustrates how policy agents protect the enterprise's web servers by directing HTTP requests to a centralized Access Manager server for processing.

Figure 1–9 Basic Access Manager Deployment

Illustrates how policy agents protect the enterprise's
web servers.

Access Manager integrates the following functions into one product. They can be viewed and configured using a single administration console:

Authentication Service

Authentication is the first step in determining whether a user is allowed to access a resource protected by Access Manager. The Access Manager Authentication Service verifies that a user really is the person he claims to be. It consists of the following components:

Plug-in modules
A framework for connecting plug-in modules
A core authentication component
A graphical user interface
Client APIs

The Authentication Service interacts with the Authentication database to validate user credentials, and with Identity Repository Management plug-ins to retrieve user profile attributes. When the Authentication Service determines that a user’s credentials are genuine, a valid user session token is issued, and the user is said to be authenticated.

Policy Service

Authorization is the process with which Access Manager evaluates policies associated with a user’s identity, and determines whether an authenticated user has permission to access a protected resource. The Access Manager Policy Service enables authorization to take place. It consists of the following components:

Policy plug-ins
A framework for connecting policy plug-ins
A core policy component
A graphical user interface
Client APIs

The Policy Service interacts with Access Manager service configurations, a delegation plug-in (which helps to determine a network administrator’s scope of privileges), and identity repository plug-ins to verify that the user has access privileges from a recognized authority.

User Session Management

An Access Manager user session is the interval between the moment a user logs in to a network resource protected by Access Manager, and the moment the user logs out of the resource. During the user session, the Access Manager Session Service maintains information about the interactions the user has with the various applications. Access Manager uses this information to enforce time-dependent rules such as timeout limits. Also during the user session, Access Manager provides continuous proof of the user’s identity. This proof of identity enables the user to access multiple enterprise resources without having to provide credentials each time.

The Access Manager Session Service enables the following types of user sessions:

Basic user session. The user provides credentials to log in to one application, and then logs out of the same application.
Single sign-on (SSO) session. The user provides credentials once, and can then access multiple applications within the same DNS domain.
Cross domain SSO (CDSSO) session. The user provides credentials once, and can then access applications among multiple DNS domains.

SAML Service

Access Manager uses the Security Assertion Markup Language (SAML), an XML-based framework for exchanging security information. While the Session Service enables SSO sessions among different DNS domains within the same intranet, the SAML Service enables CDSSO sessions among different business domains. Using the SAML protocol, business partners can securely exchange authentication and authorization information over the Internet. The SAML Service consists of the following components:

A framework to which web services can connect
A core SAML component
A graphical user interface

Federation Service

Identity federation allows a user to consolidate the many local identities he has configured among multiple service providers. With one federated identity, the user can log in at one service provider’s site and move to an affiliated service provider site without having to re-authenticate or re-establish identity. The Federation Service uses SAML to enable SSO sessions among business partners over the Internet. It consists of the following components:

A framework that complies with the Liberty Alliance Project specifications
A core Federation component
A graphical user interface

Logging

When a user logs in to a resource protected by Access Manager, the Logging component records information about the user's activity. You can write custom log operations and customize log plug-ins to generate log reports for auditing purposes.