|
| |
| Sun Java System Access Manager 6 2005Q1 Technical Overview | |
Chapter 3
Access ManagementSun Java™ System Access Manager 6 2005Q1 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, Access Manager 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 Access Manager access management features and functionality.
Topics included in this chapter are:
AuthenticationAuthentication is the process of verifying that a person is who he says he is. Access Manager 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. Access Manager compares the user’s input with data stored in Directory Server. If Access Manager finds a match for the user name, and if the given password matches the password stored in Directory Server, then Access Manager can verify the user’s identity, and the user is authenticated. Access is granted, and the corporate phone book is displayed to the user.
Basic Authentication Concepts
The Authentication Service has a user interface that is separate from the Access Manager administration console. The user interface provides a dynamic and customizable means for gathering authentication credentials. When a user requests access to a protected resource, the Authentication Service presents a web-based login page. In Figure 3-1, the default Access Manager login page, is displayed and prompts the user for user name and password.
Figure 3-1 LDAP Authentication User Interface
In Access Manager, authentication is achieved through the use of authentication modules and features. These are described in the following sections:
Authentication Modules
Access Manager is installed with a set of default authentication modules. An authentication module is a plug-in that collects user information such as a user ID and password, and then checks the information against entries in a database. If the user information provided meets the authentication criteria, then the user is granted access to the requested resource; otherwise, the user is denied access to the requested resource.
After granting or denying access, Access Manager checks for information on where to redirect the user. There is an order of precedence in which Access Manager checks for this information. The order is based on whether the user was granted or denied access to the protected resource, and on the type of authentication specified. See Authentication Types for more information on authentication types.
You can use the Access Manager administration console to enable and the configure authentication modules that come with Access Manager by default. See the Administration Guide for detailed information on enabling and configuring default authentication modules.
You can also write your own custom authentication modules to plug in to the Access Manager authentication framework. For more information on writing custom modules see the Developer’s Guide.
The following are the authentication modules that are installed by default when you install Access Manager.
Active Directory Authentication Module
This module works similarly to the LDAP authentication module, but uses the Microsoft Active Directory instead of an LDAP directory. Using this module makes it possible to have both LDAP and Active Directory coexist under the same organization.
Anonymous Authentication Module
This module allows a user to log in without specifying credentials. You can create an Anonymous user so that anyone can log in as Anonymous without having to provide a password. Anonymous connections are usually customized by the Access Manager administrator so that Anonymous users have limited access to the server.
Certificate Authentication Module
This module allows a user to log in through a personal digital certificate (PDC). The module can require the use of the Online Certificate Status Protocol (OCSP) to determine the state of a certificate. Use of the OCSP is optional. The user is granted or denied access to a resource based on whether or not the certificate is valid.
Figure 3-2 Certificate-based Authentication Login Requirement Screen
HTTP Basic Authentication Module
This module allows login using the HTTP’s basic authentication with no data encryption. A user name and password are requested through the use of a web browser. Credentials are validated internally using the LDAP authentication module.
Figure 3-3 HTTP Basic Authentication Login Requirement Screen
JDBC Authentication Module
The Java Database Connectivity (JDBC) authentication module makes it possible for Access Manager to authenticate users through any Structured Query Language (SQL) databases that provide JDBC-enabled drivers. The connection to the SQL database can be either directly through a JDBC driver or through a JNDI connection pool.
LDAP Authentication Module
This module allows for authentication using LDAP bind, a Directory Server operation which associates a user ID password with a particular LDAP entry. You can define multiple LDAP authentication configurations for an organization.
Membership Authentication Module
Membership authentication is implemented similarly to personalized sites such as my.site.com, or mysun.sun.com. When membership authentication is enabled, a user can self-register. This means the user can create an account, personalize it, and access it as a registered user—all without the help of an administrator.
MSISDN Authentication Module
The Mobile Station Integrated Services Digital Network (MSISDN) authentication module enables authentication using a mobile subscriber ISDN associated with a device such as a cellular telephone. It is a non-interactive module. The module retrieves the subscriber ISDN and validates it against the Directory Server to find a user that matches the number.
RADIUS Authentication Module
This module allows for authentication using an external Remote Authentication Dial-In User Service (RADIUS) server.
SAML Authentication Module
The Security Assertion Markup Language (SAML) authentication module receives and validates SAML Assertions on a target server.
SafeWord Authentication Module
This module allows for authentication using Secure Computing’s SafeWord® PremierAccess™ server software and SafeWord tokens.
SecurID Authentication Module
This module allows for authentication using RSA ACE/Server software and RSA SecurID authenticators.
UNIX® Authentication Module
This Solaris only module allows for authentication using a user’s UNIX identification and password.
Windows Desktop SSO Module
This module is specific to Windows and is also known as Kerebos authentication. The user presents a Kerberos token to Access Manager through the Simple and Protected GSS-API Negotiation Mechanism (SPNEGO) protocol. The Windows Desktop SSO authentication plug-in module provides a client (user) with desktop single sign-on. This means that a user who has already authenticated with a key distribution center can be authenticated with Access Manager without having to provide the login information again.
Windows NT Authentication Module
This module allows for authentication against a Microsoft Windows® NT server.
Note
In order to actualize the NT authentication module, Samba 2.2.2 must be downloaded and installed. Samba is a file and print server for blending Windows and UNIX® machines together without requiring a separate Windows NT/2000 Server. More information, and the download itself, can be accessed at http://wwws.sun.com/software/download/products/3e3af224.html.
Authentication Services
Two authentication services comprise the framework for integrating pluggable and customized authentication modules into Access Manager: Core authentication service, and authentication configuration service.
Core Authentication Service
This is a general authentication service used for server-related attribute configuration. Some of the attributes described in this service are default attributes for all Access Manager authentication modules.
The core authentication service must be registered as a service to an organization before any user can log in using the other authentication modules. The core authentication service allows the Access Manager administrator to define default values for an organization’s authentication parameters. These values can then be used if no overriding value is defined in the specified authentication module. The default values for the Core Authentication Service are defined in the amAuth.xml file and stored in Directory Server after installation.
Authentication Configuration Service
This services describes all the dynamic attributes for service-based authentication.This service is used for roles. When you assign a service to a role, you can also assign other attributes such as a success URL or an authentication post-processing class to the role.
Client Detection
An initial step in the authenticating process is to identify the type of client making the HTTP(S) request. This Access Manager feature is known as client detection. The URL information is used to retrieve the client’s characteristics. Based on these characteristics, the appropriate authentication pages are returned. For example, when a Netscape browser is used to request a web page, Access Manager displays an HTML login page. Once the user is validated, the client type ( Netscape browser) is added to the session token.
Authentication Types
When you install Access Manager, a number of authentication types are automatically configured for you. Each type of authentication uses configured login URLs and a redirection URL in order of precedence. The following types of authentication are available to you by default when you install Access Manager.
Organization-based Authentication. This method of authentication allows a user to authenticate to an organization or sub-organization in the directory information tree.
Role-based Authentication. This method of authentication allows a user to authenticate to a role within an organization or sub-organization of the directory information tree. A role is a grouping of like items in the directory. A static role is created when an attribute is assigned to a specific user or container in the directory. A filtered role is dynamically generated based on an attribute contained in the a user’s or container’s LDAP entry. For example, all users that contain a particular attribute, for example employee, can be automatically included in a filtered role named employees.
Service-based Authentication.This method of authentication allows a user to authenticate to a specific service or application registered to an organization or sub-organization.
User-based Authetnication.This method of authentication allows a user to authenticate using an authentication process configured specifically for him or her.
Authentication Level-based Authentication.This method of authentication allows an administrator to specify the security level of the modules to which identities can authenticate.
Module-based Authentication. This method of authentication allows a user to specify the module to which they will authenticate.
Redirection URLs
Upon a successful or failed authentication, Access Manager looks for information on where to redirect the user. There is an order of precedence in which the application will look for this information based on the authentication method and whether the authentication has been successful or has failed. A detailed description of the order of precedence is described in the Access Manager Administration Guide.
Account Locking
The Authentication Service provides a feature that can lock out, or prevent a user from completing the authentication process, after n failures. This feature is disabled by default, but can be enabled using the Access Manager console. Only modules that throw an Invalid Password Exception can leverage the Account Locking feature. Email notifications are sent to administrators regarding any account lockouts. Account locking activities are also logged.
Access Manager supports two types of account locking are supported: Physical Locking and Memory Locking.
Physical Locking. By default, user accounts are active, or physically unlocked. Physical locking is initiated by changing the status of an LDAP attribute in the user’s profile to inactive. The account is locked until the attribute is changed to active.
Memory Locking. Memory locking is enabled by changing the Login Failure Lockout Duration attribute to a value greater then 0. The user’s account is then locked in memory for the number of minutes specified. The account will be unlocked after the time period has passed.
Authentication Module Chaining
One or more authentication modules can be configured so a user must pass authentication credentials to all of them. This is referred to as authentication chaining. Authentication chaining in Access Manager is achieved using the JAAS framework integrated in the Authentication Service. Module chaining is configured under organization, user, role, or service Authentication Configuration. Each registered module is assigned one of the following control flags:
Requisite. The LoginModule is required to succeed. If it succeeds, authentication continues down the LoginModule list. If it fails, control immediately returns to the application (authentication does not proceed down the LoginModule list).
Required. Authentication to this module is required to succeed. If any of the required modules in the chain fails, the whole authentication chain will ultimately fail. However, whether a required module succeeds or fails, the control will continue down to the next module in the chain.
Sufficient. The LoginModule is not required to succeed. If it does succeed, control immediately returns to the application (authentication does not proceed down the LoginModule list). If it fails, authentication continues down the LoginModule list.
Optional. The LoginModule is not required to succeed. If it succeeds or fails, authentication still continues to proceed down the LoginModule list.
Once authentication to all modules in the chain is successful, control is returned to the Authentication Service (from the JAAS framework) which validates all the user IDs used to authenticate, and then maps them to one user. The mapping is achieved by configuring the User Alias List attribute in the user’s profile. If all the maps are correct, then a valid session token is issued to the user. If all the maps are not correct, then the user is denied a valid session token.
Fully Qualified Domain Name Mapping
Fully Qualified Domain Name (FQDN) mapping enables the Authentication Service to take corrective action in the case where a user may have typed in an incorrect URL. This is necessary, for example, when a user may specifies a partial host name or IP address to access protected resources.
Persistent Cookie
A persistent cookie is one that continues to exist after the web browser is closed, allowing a user to login with a new browser session without having to reauthenticate.
Session Upgrade
The Authentication Service allows for the upgrading of a valid session token based on a second, successful authentication performed by the same user to one organization. If a user with a valid session token attempts to authenticate to a resource secured by his current organization and this second authentication request is successful, the session is updated with the new properties based on the new authentication. If the authentication fails, the user’s current session is returned without an upgrade. If the user with a valid session attempts to authenticate to a resource secured by a different organization, the user will receive a message asking whether they would like to authenticate to the new organization. The user can, at this point, maintain the current session or attempt to authenticate to the new organization. Successful authentication will result in the old session being destroyed and a new one being created.
Validation Plug-in Interface
An Administrator can write username or password validation logic suitable to their organization, and plug this into the Authentication Service. (This functionality is supported only by the LDAP and Membership authentication modules.) Before authenticating the user or changing the password, Access Manager will invoke this plugin. If the validation is successful, authentication continues; if it fails, an authentication failed page will be thrown. The plugin extends the com.iplanet.am.sdk.AMUserPasswordValidation class which is part of the Service Management SDK.
JAAS Shared State
The JAAS shared state provides sharing of both user ID and password between authentication modules. Options are defined for each authentication module for:
If the module fails with the credentials from the shared state, it restarts the authentication by prompting for its required credentials. If it fails again, the module is marked failed.
After a commit, an abort or a logout, the shared state will be cleared.
Authentication Interfaces
The Authentication Service provides two means by which you can implement authentication in your enterprise:
Use the User Interface when you want to enable or to customize authentication modules that are installed by default with Access Manager. Use the Programming Interfaces when you want to develop a new authentication module.
User Interface
A user with a web browser can authenticate to Access Manager using the authentication user interface. This interface is accessed by entering the Authentication Service User Interface login URL in the browser’s location bar. After entering the URL, the user is prompted to submit verifying credentials based on the invoked authentication module(s). Once the credentials have been passed back to Access Manager (assuming successful authentication), the user can gain access based on their privileges:
- Administrators can access the administration portion of the Access Manager console to manage their organization’s identity data.
- Users can access their own profiles to modify personal data.
- A user can access a resource defined as a redirection URL parameter appended to the login URL.
- A user can access the resource protected by a policy agent.
Programming Interfaces
Access Manager provides Java APIs and SPIs, as well as C-APIs.
Authentication Via The Java API
External Java applications can authenticate to Access Manager using the Authentication API For Java Applications. This API provides interfaces to initiate the authentication process and communicate authentication credentials to the Authentication Service; the Access Manager API are based on the Java Authentication and Authorization Service (JAAS) specification. JAAS are Java packages that enable services to authenticate and enforce access controls upon users. They implement a version of the standard Pluggable Authentication Module (PAM) framework, and support user-based authorization.
Note
The JAAS packages, starting with javax.security.auth, can be found in the Javadocs for Java 2 Platform, Standard Edition (J2SE), version 1.4.2.
Developers can incorporate the API classes and methods into their Java applications to allow communication with the Authentication Service. The external application’s Java request is converted to an XML message format and passed to Access Manager over HTTP(S). Once received, the XML message is converted back into a Java request which can be interpreted by the Authentication Service.
The Authentication Service returns login requirement screens based on the authentication module being accessed. The user returns authentication credentials and is allowed or denied access based on these credentials. See the Javadoc for a comprehensive listing of Java APIs.
Authentication Via The C API
Access Manager also includes an Authentication API for C applications to authenticate to the Access Manager. 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. See the Access Manager 6 Developer’s Reference for a comprehensive listing of C-APIs.
Policy Management and ConfigurationA policy is a rule that describes who is allowed or authorized to access a specific web resource. Access Manager provides a policy management service and policy configuration service for creating such rules and evaluating policies. Policy agents are an integral part of an Access Manager 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 Access Manager 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 Access Manager. All of the Access Manager 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 Access Manager, 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 Access Manager administrator, stored within the Access Manager 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 Access Manager Policy Agents Guide
Policy Types
There are two types of policies that can be configured using Access Manager: 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.
- A resource defines the specific object that is being protected; for instance, an HTML page or a user’s salary information accessed using a human resources service.
- An action is the name of an operation that can be performed on the resource; examples of web server actions are POST or GET. An allowable action for a human resources service might be canChangeHomeTelephone.
- A value defines the permission for the action, i.e: allow or deny.
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-4. 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-4 Root-level policies
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-5 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-5 Policy Management 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, Access Manager 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 Access Manager 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.
Single Sign-On
When a user wants to access multiple resources protected by Access Manager, 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 Access Manager this functionality.
Cross-Domain Single Sign-On
A user authenticated to Access Manager 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 Access Manager: 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-6 Single-domain SSO vs. Cross-domain SSO
Figure 3-6 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 Access Manager 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 Access Manager 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 Access Manager 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 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 (5).
