Sun Java System Access Manager 7 2005Q4 Administration Guide

Part II Access Control

This is part two of the Sun Java System Access ManagerTM 7 2005Q4 Administration Guide. The Access Control interface provides a way to create and manage authentication and authorization services to protect and regulate realm-based resources. When an enterprise user requests information, Access Manager verifies the user's identity and authorizes the user to access the specific resource that the user has requested. The part contains the following chapters:

Chapter 4 The Access Manager Console

The Access Manager console is a web interface that allows administrators with different levels of access to, among other things, create realms and organizations, create or delete users to and from those realms and establish enforcement policies that protect and limit access to realms' resources. In addition, administrators can view and terminate current user sessions and manage their federation configurations (create, delete and modify authentication domains and providers). Users without administrative privileges, on the other hand, can manage personal information (name, e-mail address, telephone number, and so forth), change their password, subscribe and unsubscribe to groups, and view their roles. The Access Manager Console has two, basic views:

Administration View

When a user with an administrative role authenticates to Access Manager, the default view is the Administration view. In this view, the administrator can perform most administrative tasks related to Access Manager. Access Manager can be installed in two different modes; Realms mode and Legacy Mode. Each mode has its own console. For more information on Realm and Legacy Modes, see theSun Java System Access Manager 7 2005Q4 Technical Overview.

Realms Mode Console

The Realms mode console enables administrators to manage realm-based access control, default service configuration, Web services and Federation. To access the administrator login screen, use the following address syntax in your browser:

protocol://servername/amserver/UI/Login

protocol is either http: or https, depending upon your deployment.

Figure 4–1 Realms Mode Administration View

Access Manager Console, Realms mode administration view

Legacy Mode Console

Legacy Mode console is based on the Access Manager 6.3 architecture. This legacy Access Manager architecture uses the 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. In Legacy Mode, the Directory Management tab is available for Access Manager-based identity management.

To access the administrator login screen, use the following address syntax in your browser:

protocol://servername/amserver/console

protocol is either http: or https, depending upon your deployment.

Figure 4–2 Legacy Mode Administration View

Access Manager console, Legacy mode administration view

Legacy Mode 6.3 Console

Some features of Access Manager 6.3 are not available in the Access Manager 7.0 console. Because of this, administrators can log into the 6.3 console through a 7.0 Legacy deployment. This console is typically used 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. Other features, such Delegated Administration and Class of Service, are accessed only through this console.


Note –

Do not interchange between using the 6.3 and 7.0 Legacy mode consoles.


To access the 6.3 console, use the following address syntax in your browser:

protocol://servername/amconsole

protocol is either http: or https, depending upon your deployment.

Figure 4–3 Legacy 6.3–based Console

Access Manager Legacy mode 6.3–based Console

User Profile View

When a user who has not been assigned an administrative role authenticates to the Access Manager the default view is the user's own User Profile. The User Profile view can be accessed in either Realm or Legacy Mode. The user must enter the user's own username and password at the Login page in order to access this view.

In this view the user can modify the values of the attributes particular to the user's personal profile. This can include, but is not limited to, name, home address and password. The attributes displayed in the User Profile View can be extended.

Figure 4–4 User Profile View

Access Manager Console — User Profile View

Chapter 5 Managing Realms

An access control realm is a group of authentication properties and authorization policies you can associate with a user or group of users. Realm data is stored in a proprietary information tree that Access Manager creates within a data store you specify. The Access Manager framework aggregates policies and properties contained in each realm within the Access Manager information tree. By default, Access Manager 7 automatically inserts the Access Manager information tree as a special branch in Sun Java Enterprise System Directory Server, apart from the user data. You can use access control realms while using any LDAPv3 database.

For more information on realms, see the Sun Java System Access Manager 7 2005Q4 Technical Overview.

In the Realms tab, you can configure the following properties for access control:

Creating and Managing Realms

This section describes how to create and manage realms.

ProcedureTo Create a New Realm

  1. Select New from the Realms list under the Access Control tab.

  2. Define the following general attributes:

    Name

    Enter a name for the Realm.

    Parent

    Defines the location of the realm that you are creating. Select the parent realm under which the new realm will exist.

  3. Define the following realm attributes:

    Realm Status

    Choose a status of active or inactive. The default is active. This can be changed at any time during the life of the realm by selecting the Properties icon. Choosing inactive disables user access when logging in.

    Realm/DNS Aliases

    Allows you to add alias names for the DNS name for the realm. This attribute only accepts “real” domain aliases (random strings are not allowed).

  4. Click OK to save or Cancel to return to the previous page.

General Properties

The General Properties page displays the basic attributes for a realm. To modify these properties, click the realm from the Realm Names list under the Access Control tab. Then, edit the following properties:

Realm Status

Choose a status of active or inactive. The default is active. This can be changed at any time during the life of the realm by selecting the Properties icon. Choosing inactive disables user access when logging in.

Realm/DNS Aliases

Allows you to add alias names for the DNS name for the realm. This attribute only accepts “real” domain aliases (random strings are not allowed).

Once you edit the properties, click Save.

Authentication

The general authentication service must be registered as a service to a realm before any user can log in using the other authentication modules. The core authentication service allows the Access Manager 7 administrator to define default values for a realm'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.

For more information, see Chapter 7, Managing Authentication

Services

In Access Manager, a service is a group of attributes that are managed together by the Access Manager console. The attributes can be just bits of related information such as an employee's name, job title, and email address. But attributes are typically used as configuration parameters for a software module such as a mail application or payroll service.

Through the Services tab, you can add and configure a number of Access Manager default services to a realm. You can add the following services:


Note –

Access Manager enforces that required attributes in service .xml files have some default values. If you have services with required attributes with no values, you need to add default values and reload the service.


ProcedureTo Add a Service to a Realm

  1. Click the name of the realm for which you wish to add a new service.

  2. Select the Services tab.

  3. Click Add in the Services list.

  4. Select the service you wish to add for the realm.

  5. Click Next.

  6. Configure the service by defining the realm attributes. See Configuration in the online help for a description of the service attributes.

  7. Click Finish.

  8. To edit the properties of a service, click the name in the Service list.

Privileges

Privileges define the access permissions to roles or groups that exist within a realm. The roles or groups are used as policy subject definitions for the Access Manager Identity Subject type. To assign or modify privileges, click the name of the role or group you wish to edit. The privileges you can assign are:

Chapter 6 Data Stores

A data store is a database where you can store user attributes and user configuration data.

Access Manager provides an identity repository plug-in that connects to an identity repository framework. This new model enables you to view and retrieve Access Manager user information without having to make changes in your existing user database. 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 the universal identity in authentication and authorization processes among more than one identity repository. The virtual user identity is destroyed when the user's session ends.

LDAPv3 Data Store

You can create a new, data store instance for any generic LDAPv3 repository when Access Manager is installed in both Realms and Legacy mode. You should choose the LDAPv3 repository type under the following conditions:

ProcedureTo Create a New LDAPv3 Data Store

The following section describes the steps to connect a generic LDAPv3 data store.

  1. Select the realm to which you wish to add a new data store.

  2. Click the Data Store tab.

  3. Click New from the Data Stores list.

  4. Enter a name for the data store.

  5. Define the attributes for the LDAPv3 repository plug-in.

  6. Click Finish.

LDAPv3 Repository Plug-in Attributes

The following attributes are used to configure a LDAPv3 repository plug-in:

Primary LDAP Server

Enter the name of the LDAP server to which you will be connection. The format should be hostname.domainname:portnumber.

If more than one host:portnumber entries are entered, an attempt is made to connect to the first host in the list. The next entry in the list is tried only if the attempt to connect to the current host fails.

LDAP Bind DN

Specifies the DN name that Access Manager will use to authenticate to the LDAP server to which you are currently connected. The user with the DN name used to bind should have the correct add/modification/delete privileges that you configured in the LDAPv3 Supported Types and Operations attribute.

LDAP Bind Password

Specifies the DN password that Access Manager will use to authenticate to the LDAP server to which you are currently connected

LDAP Bind Password (confirm)

Confirm the password.

LDAP Organization DN

The DN to which this data store repository will map. This will be the base DN of all operations performed in this data store.

Enable LDAP SSL

When enabled, Access Manager will connect to the primary server using the HTTPS protocol.

LDAP Connection Pool Minimum Size

Specifies the initial number of connections in the connection pool. The use of connection pool avoids having to create a new connection each time.

LDAP Connection Pool Maximum Size

Specifies the maximum number of connections to allowed.

Maximum Results Returned from Search

Specifies the maximum number of entries returned from a search operation. If this limit is reached, Directory Server returns any entries that match the search request.

Search Timeout

Specifies the maximum number of seconds allocated for a search request. If this limit is reached, Directory Server returns any search entries that match the search request.

LDAP Follows Referral

If enabled, this option specifies that referrals to other LDAP servers are followed automatically.

LDAPv3 Repository Plugin Class Name

Specifies the location of the class file which implements the LDAPv3 repository.

Attribute Name Mapping

Enables common attributes known to the framework to be mapped to the native data store. For example, if the framework uses inetUserStatus to determine user status, it is possible that the native data store actually uses userStatus. The attribute definitions are case-sensitive.

LDAPv3 Plugin Supported Types and Operations

Specifies the operations that are permitted to or can be performed on this LDAP server. The default operations that are the only operations that are supported by this LDAPv3 repository plug-in. The following are operations supported by LDAPv3 Repository Plugin:

You can remove permissions

from the above based on your LDAP server settings and the tasks, but you can not add more permissions.

LDAP Users Search Attribute

This field defines the attribute type for which to conduct a search on a user. For example, if the user's dn is uid=k user5,ou=people,dc=iplanet,dc=com, then the naming attribute is uid. (uid=*) will be appended to the search filter for user.

LDAP Users Search Filter

Specifies the search filter to be used to find user entries. for example, if LDAP Users Search Attribute is uid and LDAP Users Search Filter is (objectClass=inetorgperson), then the actual user search filter will be: (&(uid=*)(objectClass=inetorgperson)).

LDAP User Object Class

Specifies the object classes for a user. When a user is created, this list of user object classes will be added to the user's attributes list.

LDAP User Attributes

Defines the list of attributes associated with a user. Any attempt to read/write user attributes that are not on this list is not allowed. The attributes are case-sensitive. The object classes and attribute schema must be defined in Directory Server before you define the object classes and attribute schema here.

LDAP Groups Search Attribute

This field defines the attribute type for which to conduct a search on a group. For example, if the group dn is cn=group1,ou=groups,dc=iplanet,dc=com, the naming attribute for group is cn and (cn=*) will be appended to the group search filter.

LDAP Groups Search Filter

Specifies the search filter to be used to find group entries. for example, if "LDAP Groups Search Attribute" is cn and "LDAP Groups Search Filter" is (objectclass=groupOfUniqueNames), the actual group search filter will be (&(cn=*)(objectclass=groupOfUniqueNames)).

LDAP Groups Container Naming Attribute

Specifies the naming attribute for a group container, if groups resides in a container. Otherwise, this attribute is left empty. For example, if a group DN of cn=group1,ou=groups,dc=iplanet,dc=comresides in ou=groups, then the group container naming attribute is ou.

LDAP Groups Container Value

Specifies the value for the group container. For example, a group DN of cn=group1,ou=groups,dc=iplanet,dc=com resides in a container name ou=groups, then the group container value would be groups.

LDAP Groups Object Class

Specifies the object classes for groups. When a group is created, this list of group object classes will be added to the group's attributes list.

LDAP Groups Attributes

Defines the list of attributes associated with a group. Any attempt to read/write group attributes that are not on this list is not allowed. The attributes are case-sensitive. The object classes and attribute schema must be defined in Directory Server before you define the object classes and attribute schema here.

Attribute Name for Group Membership

Specifies the name of the attribute whose values are the names of all the groups to which DN belongs. The default is memberOf.

Attribute Name of Group Member

Specifies the attribute name whose values is a DN belonging to this group. The default is uniqueMember.

Attribute Name of Group Member URL

Specifies the name of the attribute whose value is an LDAP URL which resolves to members belonging to this group. The default is memberUrl.

LDAP People Container Naming Attribute

Specifies the naming attribute of the people container if a user resides in a people container. This field is left blank if the user does not reside in a people container. For example, given a user dn uid=kuser5,ou=people,dc=iplanet,dc=com, if ou=people is the name of the people container, then the naming attribute isou.

LDAP People Container Value

Specifies the value of the people container. The default is people. For example, given a user dn uid=kuser5,ou=people,dc=iplanet,dc=com, if ou=people is the name of the people container, then the naming attribute is ou and people is the "LDAP People Container Value."

LDAP Agents Search Attribute

This field defines the attribute type for which to conduct a search on an agent. The default is uid. For example, if the agent's dn is uid=kagent1,ou=agents,dc=iplanet,dc=com, then the agent's naming attribute is uid. (uid=*) will be appended to the search filter for the agent.

LDAP Agents Container Naming Attribute

The naming attribute of the agent container if the agent resides in a agent container. This field is left blank if the agent does not reside in agent container. For example, given a user dn uid=kagent1,ou=agents,dc=iplanet,dc=com, the agent naming attribute is ou.

LDAP Agents Container Value

Specifies the value of the agent container. It is left blank if the agent does not reside in agent container. In the previous example, the agents container value would be agents.

LDAP Agents Search Filter

Defines the filter used to search for an agent. The LDAP Agent Search attribute is prepended to this field to form the actual agent search filter.

For example, if the LDAP Agents Search Attribute is uid and LDAP Users Search Filter is (objectClass=sunIdentityServerDevice), then the actual user search filter will be: (&(uid=*)(objectClass=sunIdentityServ erDevice))

LDAP Agents Object Class

Defines the object classes for agents. When an agent is created, the list of user object classes will be added to the agent's attributes list

LDAP Agents Attributes

Defines the list of attributes associated with an agent. Any attempt to read/write agent attributes that are not on this list is not allowed. The attributes are case-sensitive. The object classes and attribute schema must be defined in Directory Server before you define the object classes and attribute schema here.

Persistent Search Base DN

Defines the base DN to use for persistent search. Some LDAPv3 servers only support persistent search at the root suffix level.

Persistent Search Maximum Idle Time Before Restart

Defines the maximum idle time before restarting the persistence search. The value must be greater than 1. Values less than or equal to 1 will restart the search irrespective of the idle time of the connection.

If Access Manager is deployed with a load balancer, some load balancers will time out if it has been idle for a specified amount of time. In this case, you should set the Persistent Search Maximum Idle Time Before Restart to a value less than the specified time for the load balancer.

Maximum Number of Retries After Error Codes

Defines the maximum number of retries for the persistent search operation if it encounters the error codes specified in LDAPException Error Codes to Retry On.

The Delay Time Between Retries

Specifies the time to wait before each retry. This only applies to persistent search connection.

LDAPException Error Codes to Retry On

Specifies the error codes to initiate a retry for the persistent search operation. This attribute is only applicable for the persistent search, and not for all LDAP operations.

AMSDK Repository Plug-in

The AMSDK identity repositories is automatically intermingled with the Access Manager information tree when Access Manager is installed in Legacy mode. In Realms mode, you can choose to install the AMSDK repository, but the identity repositories are not intermingled with the Access Manager information tree. You should choose the AMSDK repository type under the following conditions:

ProcedureTo Create a New AMSDK Repository Plugin

  1. Select the realm in which you wish to configure the Access Manager repository plug-in.

  2. Click the Data Store tab.

  3. Click New from the Data Stores list.

  4. Enter a name for the repository plug-in.

  5. Select Access Manager Repository Plugin.

  6. Click Next.

  7. Define the following fields:

    Access Manager Plugin Class Name

    Specifies the location of the class file which implements the Access Manager repository plug-in.

    Access Manager Organization

    The DN that points an organization in the Directory Server to be managed by Access Manager. This will be the base DN of all operations performed in this data store.

  8. Click Finish.

Chapter 7 Managing Authentication

The Authentication Service provides a web-based user interface for all of the default authentication types installed in the Access Manager deployment. This interface provides a dynamic and customizable means for gathering authentication credentials by displaying the login requirement screens (based on the invoked authentication module) to a user requesting access. The interface is built using Sun Java System™ Application Framework (sometimes referred to as JATO), a Java 2 Enterprise Edition (J2EE) presentation framework used to help developers build functional web applications.

Configuring Authentication

This section describes how to configure authentication for your deployment. The first section outlines the default authentication module types and provides any necessary pre-configuration instructions. You can configure multiple configuration instances of the same authentication module type for realms, users, roles, and so forth. Additionally, you can add authentication chains so that authentication must pass the criteria for multiple instance before authentication is successful. This section includes:

Authentication Module Types

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 a user provides information that meets the authentication criteria, then the user is granted access to the requested resource. If the user provides information that does not meet authentication criteria, the user is denied access to the requested resource. Access Manager is installed with 15 types of authentication modules:


Note –

Some of the authentication module types require pre-configuration before they can be used as authentication instances. The configuration steps, if necessary, are listed in the module type descriptions.


Core

Access Manager provides, by default, fifteen different authentication modules, as well as a Core authentication module. The Core authentication module provides overall configuration for the authentication module. Before adding and enabling Active Directory, Anonymous, Certificate-based, HTTP Basic, JDBC, LDAP, any authentication module, the Core authentication must be added and enabled. Both the Core and LDAP Authentication modules are automatically enabled for the default realm.

Clicking the Advanced Properties button displays the Core authentication attributes that can be defined for the realm. The global attributes are not applicable to the realm so they are not displayed.

Active Directory

The Active Directory authentication module performs authentication in a similar manner to the LDAP module, but uses Microsoft’s Active Directory™ server (as opposed to Directory Server in LDAP authentication module). Although the LDAP authentication module can be configured for an Active Directory server, this module allows you have both LDAP and Active Directory authentication exist under the same realm.


Note –

For this release, the Active Directory authentication module only supports user authentication. Password policy is only supported in the LDAP authentication module.


Anonymous

By default, when this module is enabled, a user can log in to Access Manager as an anonymous user. A list of anonymous users can also be defined for this module by configuring the Valid Anonymous User List attribute. Granting anonymous access means that it can be accessed without providing a password. Anonymous access can be limited to specific types of access (for example, access for read or access for search) or to specific subtrees or individual entries within the directory.

Certificate

Certificate-based Authentication involves using a personal digital certificate (PDC) to identify and authenticate a user. A PDC can be configured to require a match against a PDC stored in Directory Server, and verification against a Certificate Revocation List.

There are a number of things that need to be accomplished before adding the Certificate-based Authentication module to a realm. First, the web container that is installed with the Access Manager needs to be secured and configured for Certificate-based Authentication. Before enabling the Certificate-based module, see Chapter 6, “Using Certificates and Keys” in the Sun ONE Web Server 6.1 Administrator’s Guide (located at http://docs.sun.com/source/817-1831-10/agcert.html) for the initial Web Server configuration steps. If using Application Server see the Sun ONE Application Server Administrator’s Guide to Security (located at http://docs.sun.com/source/816-7158-10/sgcerts.html).


Note –

Each user that will authenticate using the certificate-based module must request a PDC for the user’s browser. Instructions are different depending upon the browser used. See your browser’s documentation for more information.


In order to add this module, you must log in to Access Manager as the realm Administrator and have Access Manager and the web container configured for SSL and with client authentication enabled. For more information, see Chapter 3, Configuring Access Manager in SSL Mode.

HTTP Basic

This module uses basic authentication, which is the HTTP protocol’s built-in authentication support. The web server issues a client request for username and password, and sends that information back to the server as part of the authorized request. Access Manager retrieves the username and password and then internally authenticates the user to the LDAP authentication module. In order for HTTP Basic to function correctly, the LDAP authentication module must be added (adding the HTTP Basic module alone will not work). Once the user successfully authenticates, the user will be able to re-authenticate without being prompted for username and password.

JDBC

The Java Database Connectivity (JDBC) Authentication module provides a mechanism to allow Access Manager to authenticate users through any SQL databases that provide JDBC technology-enabled drivers. The connection to the SQL database can be either directly through a JDBC driver, or a JNDI connection pool.


Note –

This module has been tested on MySQL4.0 and Oracle 8i.


LDAP

With the LDAP Authentication module, when a user logs in, he or she is required to bind to the LDAP Directory Server with a specific user DN and password. This is the default authenticating module for all realm-based authentication. If the user provides a user ID and password that are in the Directory Server, the user is allowed access to, and is set up with, a valid Access Manager session. Both the Core and LDAP Authentication modules are automatically enabled for the default realm

Membership

Membership authentication is implemented similarly to personalized sites such as my.site.com, or mysun.sun.com. When this module is enabled, a user creates an account and personalizes it without the aid of an administrator. With this new account, the user can access it as a added user. The user can also access the viewer interface, saved on the user profile database as authorization data and user preferences.

MSISDN

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

Access Manager can be configured to work with a RADIUS server that is already installed. This is useful if there is a legacy RADIUS server being used for authentication in your enterprise. Enabling the RADIUS authentication module is a two-step process:

  1. Configure the RADIUS server.

    For detailed instructions, see the RADIUS server documentation.

  2. Register and enable the RADIUS authentication module.

Configuring RADIUS with Sun Java System Application Server

When the RADUIS client forms a socket connection to its server, by default, only the connect permission of the SocketPermissions is allowed in the Application Server’s server.policy file. In order for RADUIS authentication to work correctly, permissions need to be granted for the following actions:

To grant a permission for a socket connection, you must add an entry into Application Server’s server.policy file. A SocketPermission consists of a host specification and a set of actions specifying ways to connect to that host. The host is specified as the following:

host = hostname | IPaddress:portrange:portrange = portnumber 
| -portnumberportnumber-portnumber

The host is expressed as a DNS name, as a numerical IP address, or as local host (for the local machine). The wildcard “*” may be included once in a DNS name host specification. If it is included, it must be in the left-most position, as in *.example.com.

The port (or port range) is optional. A port specification of the form N-, where N is a port number, signifies all ports numbered N and above. A specification of the form -N indicates all ports numbered N and below.

The listen action is only meaningful when used with a localhost. The resolve (resolve host/IP name service lookups) action is implied when any of the other actions are present.

For example, when creating SocketPermissions, note that if the following permission is granted to some code, it allows that code to connect to port 1645 on machine1.example.com, and to accept connections on that port:

permission java.net.SocketPermission machine1.example.com:1645, "connect,accept";

Similarly, if the following permission is granted to some code, it allows that code to accept connections on, connect to, or listen to any port between 1024 and 65535 on the local host:

permission java.net.SocketPermission "machine1.example.com:1645", "connect,accept";
permission java.net.SocketPermission "localhost:1024-", "accept,connect,listen";

Note –

Granting code permission to accept or make connections to remote hosts may cause problems, because malevolent code can then more easily transfer and share confidential data among parties who may not otherwise have access to the data. Make sure to give only appropriate permissions by specifying exact port number instead of allowing a range of port numbers


SafeWord

Access Manager can be configured to handle SafeWord Authentication requests to Secure Computing’s SafeWord™ or SafeWord PremierAccess™ authentication servers. Access Manager provides the client portion of SafeWord authentication. The SafeWord server may exist on the system on which Access Manager is installed, or on a separate system.

Configuring SafeWord with Sun Java System Application Server

When the SafeWord client forms a socket connection to its server, by default, only the connect permission of the SocketPermissions is allowed in the Application Server’s server.policy file. In order for SafeWord authentication to work correctly, permissions need to be granted for the following actions:

To grant a permission for a socket connection, you must add an entry into Application Server’s server.policy file. A SocketPermission consists of a host specification and a set of actions specifying ways to connect to that host. The host is specified as the following:

host = (hostname | IPaddress)[:portrange] portrange = 
portnumber | -portnumberportnumber-[portnumber]

The host is expressed as a DNS name, as a numerical IP address, or as localhost (for the local machine). The wildcard “*” may be included once in a DNS name host specification. If it is included, it must be in the left-most position, as in *.example.com.

The port (or portrange) is optional. A port specification of the form N-, where N is a port number, signifies all ports numbered N and above. A specification of the form -N indicates all ports numbered N and below.

The listen action is only meaningful when used with a localhost. The resolve (resolve host/IP name service lookups) action is implied when any of the other actions are present.

For example, when creating SocketPermissions, note that if the following permission is granted to some code, it allows that code to connect to port 1645 on machine1.example.com, and to accept connections on that port:

permission java.net.SocketPermission machine1.example.com:5030, "connect,accept";

Similarly, if the following permission is granted to some code, it allows that code to accept connections on, connect to, or listen to any port between 1024 and 65535 on the local host:

permission java.net.SocketPermission "machine1.example.com:5030", "connect,accept";
permission java.net.SocketPermission "localhost:1024-", "accept,connect,listen";

Note –

Granting code permission to accept or make connections to remote hosts may cause problems, because malevolent code can then more easily transfer and share confidential data among parties who may not otherwise have access to the data. Make sure to give only appropriate permissions by specifying exact port number instead of allowing a range of port numbers


SAML

The Security Assertion Markup Language (SAML) authentication module receives and validates SAML Assertions on a target server. SAML SSO will only work if this module is configured on the target machine, including after an upgrade (for example, Access Manager 2005Q1 to Access Manager 2005Q4).

SecurID

Access Manager can be configured to handle SecurID Authentication requests to RSA’s ACE/Server authentication servers. Access Manager provides the client portion of SecurID authentication. The ACE/Server may exist on the system on which Access Manager is installed, or on a separate system. In order to authenticate locally-administered userids (see admintool (1M)), root access is required.

SecurID Authentication makes use of an authentication helper, amsecuridd, which is a separate process from the main Access Manager process. Upon startup, this helper listens on a port for configuration information. If Access Manager is installed to run as nobody, or a userid other than root, then the AccessManager-base/SUNWam/share/bin/amsecuridd process must still execute as root. For more information on the amsecuridd helper, see Chapter 20, The amsecuridd Helper.


Note –

For this release of Access Manager, the SecurID Authentication module is not available for the Linux or Solaris x86 platforms and this should not be registered, configured, or enabled on these two platforms. It is only available for SPARC systems.


UNIX

Access Manager can be configured to process authentication requests against Unix userids and passwords known to the Solaris or Linux system on which Access Manager is installed. While there is only one realm attribute, and a few global attributes for Unix authentication, there are some system-oriented considerations. In order to authenticate locally-administered userids (see admintool (1M)), root access is required

Unix Authentication makes use of an authentication helper, amunixd, which is a separate process from the main Access Manager process. Upon startup, this helper listens on a port for configuration information. There is only one Unix helper per Access Manager to serve all of its realms.

If Access Manager is installed to run as nobody, or a userid other than root, then the AccessManager-base/SUNWam/share/bin/amunixd process must still execute as root. The Unix authentication module invokes the amunixd daemon by opening a socket to localhost:58946 to listen for Unix authentication requests. To run the amunixd helper process on the default port, enter the following command:

./amunixd

To run amunixd on a non-default port, enter the following command:

./amunixd [-c portnm] [ipaddress]

The ipaddress and portnumber is located in the UnixHelper.ipadrs (in IPV4 format) and UnixHelper.port attributes in AMConfig.properties . You can run amunixd through the amserver command line utility (amserver runs the process automatically, retrieving the port number and IP address from AMConfig.properties).

The passwd entry in the /etc/nsswitch.conf file determines whether the /etc/passwd and /etc/shadow files, or NIS are consulted for authentication.

Windows Desktop SSO

The Windows Desktop SSO Authentication module is a Kerberos-based authentication plug-in module used for Windows 2000™. It allows a user who has already authenticated to a Kerberos Distribution Center (KDC) to authenticate to Access Manager without re-submitting the login criteria (Single Sign-on).

The user presents the Kerberos token to the Access Manager through the SPNEGO (Simple and Protected GSS-API Negotiation Mechanism) protocol. In order to perform Kerberos-based Single Sign-on to Access Manager through this authentication module, the user must, on the client side, support the SPNEGO protocol to authenticate itself. In general, any user that supports this protocol should be able to use this module to authenticate to Access Manager. Depending on the availability of the token on the client side, this module provides a SPENGO token or a Kerberos token (in both cases, the protocols are the same). Microsoft Internet Explorer (5.01 or later) running on Windows 2000 (or later) currently supports this protocol. In addition, Mozilla 1.4 on Solaris (9 and 10) has SPNEGO support, but the token returned is only a KERBEROS token, because SPNEGO is not supported on Solaris.


Note –

You must use JDK 1.4 or above to utilize the new features of Kerberos V5 authentication module and Java GSS API to perform Kerberos based SSO in this SPNEGO module.


Known Restriction with Internet Explorer

If you are using Microsoft Internet Explorer 6.x when for WindowsDesktopSSO authentication and the browser does not have access to the user’s Kerberos/SPNEGO token that matches the (KDC) realm configured in the WindowsDesktopSSO module, the browser will behave incorrectly to other modules after it fails authenticating to the WindowsDesktopSSO module. The direct cause of the problem is that after Internet Explorer fails the WindowsDesktopSSO module, the browser becomes incapable of passing callbacks (of other modules) to Access Manager, even if the callbacks are prompted, until the browser is restarted. Therefore all the modules coming after WindowsDesktopSSO will fail due to null user credentials.

See the following documentation for related information:

http://support.microsoft.com/default.aspx?scid=kb;en-us;308074

http://www.wedgetail.com/jcsi/sso/doc/guide/troubleshooting.html#ieNTLM

Configuring Windows Desktop SSO

Enabling Windows Desktop SSO Authentication is a two-step process:

  1. Create a User in the Windows 2000 Domain Controller.

  2. Setup Internet Explorer.

ProcedureTo Create a User in the Windows 2000 Domain Controller

  1. In the domain controller, create a user account for the Access Manager authentication module.

    1. From the Start menu, go to Programs>Administration Tools.

    2. Select Active Directory Users and Computers.

    3. Create a new user with the Access Manager host name as the User ID (login name). The Access Manager host name should not include the domain name.

  2. Associate the user account with a service provider name and export the keytab files to the system in which Access Manager is installed. To do so, run the following commands:


    ktpass -princ host/hostname.domainname@DCDOMAIN -pass password -mapuser userName-out 
    hostname.host.keytab
    ktpass -princ HTTP/hostname.domainname@DCDOMAIN -pass 
    password -mapuser userName-out hostname
    .HTTP.keytab

    The ktpass command accepts the following parameters:

    hostname. The host name (without the domain name) on which Access Manager runs.

    domainname . The Access Manager domain name.

    DCDOMAIN. The domain name of the domain controller. This may be different from the Access Manager domain name.

    password . The password of the user account. Make sure that password is correct, as ktpass does not verify passwords.

    userName. The user account ID. This should be the same as hostname.


    Note –

    Make sure that both keytab files are kept secure.


    The service template values should be similar to the following example:

    Service Principal: HTTP/machine1.EXAMPLE.COM@ISQA.EXAMPLE.COM

    Keytab File Name: /tmp/machine1.HTTP.keytab

    Kerberos Realm: ISQA.EXAMPLE.COM

    Kerberos Server Name: machine2.EXAMPLE.com

    Return Principal with Domain Name: false

    Authentication Level: 22

  3. Restart the server.

ProcedureTo Set Up Internet Explorer

These steps apply to Microsoft Internet Explorer™ 6 and later. If you are using an earlier version, make sure that Access Manager is in the browser’s internet zone and enable Native Windows Authentication.

  1. In the Tool menu, go to Internet Options>Advanced/Security>Security.

  2. Select the Integrated Windows Authentication option.

  3. Go to Security>Local Internet.

    1. Select Custom Level. In the User Authentication/Logon panel, select the Automatic Logon Only in Intranet Zone option.

    2. Go to Sites and select all of the options.

    3. Click Advanced and add the Access Manager to the local zone (if it is not added already).

Windows NT

Access Manager can be configured to work with an Windows NT /Windows 2000 server that is already installed. Access Manager provides the client portion of NT authentication.

  1. Configure the NT server. For detailed instructions, see the Windows NT server documentation.

  2. Before you can add and enable the Windows NT authentication module, you must obtain and install a Samba client to communicate with Access Manager on your Solaris system.

Installing the Samba Client

In order to activate the Windows NT Authentication module, Samba Client 2.2.2 must be downloaded and installed to the following directory:

AccessManager-base/SUNWam/bin

Samba Client 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.

Red Hat Linux ships with a Samba client, located in the following directory:

/usr/bin

In order to authenticate using the Windows NT Authentication module for Linux, copy the client binary to the following Access Manager directory:

AccessManager-base/sun/identity/bin

Note –

If you have multiple interfaces, extra configuration is required. Multiple interfaces can be set by configuration in the smb.conf file so it passes to the mbclient.


Authentication Module Instances

Multiple authentication module instances can be crated for the realm, based on the default authentication modules. You can add individually configured multiple instances of the same authentication module.

ProcedureTo Create a New Authentication Module Instance

  1. Click the name of the realm for which you wish to add a new authentication module instance.

  2. Select the Authentication tab.


    Note –

    The Administrator Authentication Configuration button defines the authentication service for administrators only. This attribute can be used if the authentication module for administrators needs to be different from the module for end users. The modules configured in this attribute are picked up when the Access Manager console is accessed.


  3. Click New in the Module Instances list.

  4. Enter a Name for the authentication module instance. The names must be unique.

  5. Select the Type of authentication module type for the realm.

  6. Click Create.

  7. Click the name of the newly created module instance and edit the properties for that module. See the Authentication section in the online help for definitions for the properties for each module type.

  8. Repeat these steps to add multiple module instances.

Authentication 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 the Authentication Configuration service.

ProcedureTo Create a New Authentication Chain

  1. Click the name of the realm for which you wish to add a new authentication chain.

  2. Select the Authentication tab.

  3. Click New in the Authentication Chaining list.

  4. Enter a name for the authentication chain.

  5. Click Create.

  6. Click Add to define the authentication module instance that you wish to include in the chain. To do so, select the module instance name from the Instance list. The module instance names displayed in this list are created in the Module Instances attribute.

  7. Select the criteria for the chain. These flags establish an enforcement criteria for the authentication module for which they are defined. There is hierarchy for enforcement. Required is the highest and Optional is the lowest:

    Requisite

    The module instance is required to succeed. If it succeeds, authentication continues down the Authentication Chaining list. If it fails, control immediately returns to the application (authentication does not proceed down the Authentication Chaining 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 module instance is not required to succeed. If it does succeed, control immediately returns to the application (authentication does not proceed down the module instance list). If it fails, authentication continues down the Authentication Chaining list.

    Optional

    The module instance is not required to succeed. If it succeeds or fails, authentication still continues to proceed down the Authentication Chaining list.

  8. Enter options for the chain. This enables additional options for the module as a key=value pair. Multiple options are separated by a space.

  9. Define the following attributes:

    Successful Login URL

    Specifies the URL that the user will be redirected to upon successful authentication.

    Failed Login URL

    Specifies the URL that the user will be redirected to upon unsuccessful authentication.

    Authentication Post Processing Class

    Defines the name of the Java class used to customize the post authentication process after a login success or failure.

  10. Click Save.

Authentication Types

The Authentication Service provides different ways in which authentication can be applied. These different authentication methods can be accessed by specifying Login URL parameters, or through the authentication APIs (see Chapter 5, Using Authentication APIs and SPIs, in Sun Java System Access Manager 7 2005Q4 Developer’s Guide in the Developer's Guide for more information). Before an authentication module can be configured, the Core authentication service attribute realm Authentication Modules must be modified to include the specific authentication module name.

The Authentication Configuration service is used to define authentication modules for any of the following authentication types:

Once an authentication module is defined for one of these authentication types, the module can be configured to supply redirect URLs, as well as a post-processing Java class specification, based on a successful or failed authentication process.

How Authentication Types Determine Access

For each of these methods, the user can either pass or fail the authentication. Once the determination has been made, each method follows this procedure. Step 1 through Step 3 follows a successful authentication; Step 4 follows both successful and failed authentication.

  1. Access Manager confirms whether the authenticated user(s) is defined in the Directory Server data store and whether the profile is active.

    The User Profile attribute in the Core Authentication module can be defined as Required, Dynamic, Dynamic with User Alias, or Ignored. Following a successful authentication, Access Manager confirms whether the authenticated user(s) is defined in the Directory Server data store and, if the User Profile value is Required, confirms that the profile is active. (This is the default case.) If the User Profile is Dynamically Configured, the Authentication Service will create the user profile in the Directory Server data store. If the User Profile is set to Ignore, the user validation will not be done.

  2. Execution of the Authentication Post Processing SPI is accomplished.

    The Core Authentication module contains an Authentication Post Processing Class attribute which may contain the authentication post-processing class name as its value. AMPostAuthProcessInterface is the post-processing interface. It can be executed on either successful or failed authentication or on logout.

  3. The following properties are added to, or updated in, the session token and the user’s session is activated.

    realm. This is the DN of the realm to which the user belongs.

    Principal. This is the DN of the user.

    Principals. This is a list of names to which the user has authenticated. (This property may have more then one value defined as a pipe separated list.)

    UserId. This is the user’s DN as returned by the module, or in the case of modules other than LDAP or Membership, the user name. (All Principals must map to the same user. The UserID is the user DN to which they map.)


    Note –

    This property may be a non-DN value.


    UserToken. This is a user name. (All Principals must map to the same user. The UserToken is the user name to which they map.)

    Host. This is the host name or IP address for the client.

    authLevel. This is the highest level to which the user has authenticated.

    AuthType. This is a pipe separated list of authentication modules to which the user has authenticated (for example, module1|module2|module3).

    clientType. This is the device type of the client browser.

    Locale. This is the locale of the client.

    CharSet. This is the determined character set for the client.

    Role. Applicable for role-based authentication only, this is the role to which the user belongs.

    Service. Applicable for service-based authentication only, this is the service to which the user belongs.

  4. Access Manager looks for information on where to redirect the user after either a successful or failed authentication.

    URL redirection can be to either an Access Manager page or a URL. The redirection is based on an order of precedence in which Access Manager looks for redirection based on the authentication method and whether the authentication has been successful or has failed. This order is detailed in the URL redirection portions of the following authentication methods sections.

URL Redirection

In the Authentication Configuration service, you can assign URL redirection for successful or unsuccessful authentication. The URLs, themselves, are defined in the Login Success URL and Login Failure URL attributes in this service. In order to enable URL redirection, you must add the Authentication Configuration service to your realm to make it available to configure for a role, realm, or user. Make sure that you add an authentication module, such as LDAP - REQUIRED, when adding the Authentication Configuration service.

Realm-based Authentication

This method of authentication allows a user to authenticate to an realm or sub-realm. It is the default method of authentication for Access Manager . The authentication method for an realm is set by registering the Core Authentication module to the realm and defining the realm Authentication Configuration attribute.

Realm-based Authentication Login URLs

The realm for authentication can be specified in the User Interface Login URL by defining the realm Parameter or the domain Parameter. The realm of a request for authentication is determined from the following, in order of precedence:

  1. The domain parameter.

  2. The realm parameter.

  3. The value of the DNS Alias Names attribute in the Administration Service.

    After calling the correct realm, the authentication module(s) to which the user will authenticate are retrieved from the realm Authentication Configuration attribute in the Core Authentication Service. The login URLs used to specify and initiate realm-based authentication are:


    http://server_name.domain_name:port/amserver/UI/Login
    http://server_name.domain_name:port/amserver/UI/Login?domain=domain_name
    http://server_name.domain_name:port/amserver/UI/Login?realm=realm_name

    If there is no defined parameter, the realm will be determined from the server host and domain specified in the login URL.

Realm-based Authentication Redirection URLs

Upon a successful or failed organization-based authentication, Access Manager looks for information on where to redirect the user. Following is the order of precedence in which the application will look for this information.

Successful realm-based Authentication Redirection URLs

The redirection URL for successful realm-based authentication is determined by checking the following places in order of precedence:

  1. A URL set by the authentication module.

  2. A URL set by a goto Login URL parameter.

  3. A URL set in the clientType custom files for the iplanet-am-user-success-url attribute of the user’s profile ( amUser.xml).

  4. A URL set in the clientType custom files for the iplanet-am-auth-login-success-url attribute of the user’s role entry.

  5. A URL set in the clientType custom files for the iplanet-am-auth-login-success-url attribute of the user’s realm entry.

  6. A URL set in the clientType custom files for the iplanet-am-auth-login-success-url attribute as a global default.

  7. A URL set in the iplanet-am-user-success-url attribute of the user’s profile (amUser.xml).

  8. A URL set in the iplanet-am-auth-login-success-url attribute of the user’s role entry.

  9. A URL set in the iplanet-am-auth-login-success-url attribute of the user’s realm entry.

  10. A URL set in the iplanet-am-auth-login-success-url attribute as a global default.

Failed Realm-based Authentication Redirection URLs

The redirection URL for failed realm-based authentication is determined by checking the following places in the following order:

  1. A URL set by the authentication module.

  2. A URL set by a gotoOnFail Login URL parameter.

  3. A URL set in the clientType custom files for the iplanet-am-user-failure-url attribute of the user’s entry ( amUser.xml).

  4. A URL set in the clientType custom files for the iplanet-am-auth-login-failure-url attribute of the user’s role entry.

  5. A URL set in the clientType custom files for the iplanet-am-auth-login-failure-url attribute of the user’s realm entry.

  6. A URL set in the clientType custom files for the iplanet-am-auth-login-failure-url attribute as a global default.

  7. A URL set for the iplanet-am-user-failure-url attribute in the user’s entry (amUser.xml).

  8. A URL set for the iplanet-am-auth-login-failure-url attribute of the user’s role entry.

  9. A URL set for the iplanet-am-auth-login-failure-url attribute of the user’s realm entry.

  10. A URL set for the iplanet-am-auth-login-failure-url attribute as the global default.

To Configure Realm-Based Authentication

Authentication modules are set for realms by first adding the Core Authentication service to the realm.

ProcedureTo Configure The Realms’s Authentication Attributes

  1. Navigate to the realm for which you wish to add the Authentication Chain.

  2. Click the Authentication tab.

  3. Select the Default Authentication Chain from the pull down menu.

  4. Select the Administrator Authentication Chain from the pull down menu. This attribute can be used if the authentication module for administrators needs to be different from the module for end users. The default authentication module is LDAP.

  5. Once you have defined the authentication chains, click Save.

Organization-based Authentication

This authentication type only applies to Access Manager deployments that have been installed in Legacy mode.

This method of authentication allows a user to authenticate to an organization or sub-organization. It is the default method of authentication for Access Manager . The authentication method for an organization is set by registering the Core Authentication module to the organization and defining the Organization Authentication Configuration attribute.

Organization-based Authentication Login URLs

The organization for authentication can be specified in the User Interface Login URL by defining the org Parameter or the domain Parameter. The organization of a request for authentication is determined from the following, in order of precedence:

  1. The domain parameter.

  2. The org parameter.

  3. The value of the DNS Alias Names (Organization alias names) attribute in the Administration Service.

    After calling the correct organization, the authentication module(s) to which the user will authenticate are retrieved from the Organization Authentication Configuration attribute in the Core Authentication Service. The login URLs used to specify and initiate organization-based authentication are:


    http://server_name.domain_name:port/amserver/UI/Login
    http://server_name.domain_name:port/amserver/UI/Login?domain=domain_name
    http://server_name.domain_name:port/amserver/UI/Login?org=org_name

    If there is no defined parameter, the organization will be determined from the server host and domain specified in the login URL.

Organization-based Authentication Redirection URLs

Upon a successful or failed organization-based authentication, Access Manager looks for information on where to redirect the user. Following is the order of precedence in which the application will look for this information.

Successful Organization-based Authentication Redirection URLs

The redirection URL for successful organization-based authentication is determined by checking the following places in order of precedence:

  1. A URL set by the authentication module.

  2. A URL set by a goto Login URL parameter.

  3. A URL set in the clientType custom files for the iplanet-am-user-success-url attribute of the user’s profile ( amUser.xml).

  4. A URL set in the clientType custom files for the iplanet-am-auth-login-success-url attribute of the user’s role entry.

  5. A URL set in the clientType custom files for the iplanet-am-auth-login-success-url attribute of the user’s organization entry.

  6. A URL set in the clientType custom files for the iplanet-am-auth-login-success-url attribute as a global default.

  7. A URL set in the iplanet-am-user-success-url attribute of the user’s profile (amUser.xml).

  8. A URL set in the iplanet-am-auth-login-success-url attribute of the user’s role entry.

  9. A URL set in the iplanet-am-auth-login-success-url attribute of the user’s organization entry.

  10. A URL set in the iplanet-am-auth-login-success-url attribute as a global default.

Failed Organization-based Authentication Redirection URLs

The redirection URL for failed organization-based authentication is determined by checking the following places in the following order:

  1. A URL set by the authentication module.

  2. A URL set by a gotoOnFail Login URL parameter.

  3. A URL set in the clientType custom files for the iplanet-am-user-failure-url attribute of the user’s entry ( amUser.xml).

  4. A URL set in the clientType custom files for the iplanet-am-auth-login-failure-url attribute of the user’s role entry.

  5. A URL set in the clientType custom files for the iplanet-am-auth-login-failure-url attribute of the user’s organization entry.

  6. A URL set in the clientType custom files for the iplanet-am-auth-login-failure-url attribute as a global default.

  7. A URL set for the iplanet-am-user-failure-url attribute in the user’s entry (amUser.xml).

  8. A URL set for the iplanet-am-auth-login-failure-url attribute of the user’s role entry.

  9. A URL set for the iplanet-am-auth-login-failure-url attribute of the user’s organization entry.

  10. A URL set for the iplanet-am-auth-login-failure-url attribute as the global default.

To Configure Organization-Based Authentication

Authentication modules are set for an organization by first adding the Core Authentication service to the organization.

ProcedureTo Configure The Organizations’s Authentication Attributes

  1. Navigate to the organization for which you wish to add the Authentication Chain.

  2. Click the Authentication tab.

  3. Select the Default Authentication Chain from the pull down menu.

  4. Select the Administrator Authentication Chain from the pull down menu. This attribute can be used if the authentication module for administrators needs to be different from the module for end users. The default authentication module is LDAP.

  5. Once you have defined the authentication chains, click Save.

Role-based Authentication

This method of authentication allows a user to authenticate to a role (either static or filtered) within an realm or sub realm.


Note –

The Authentication Configuration Service must first be registered to the realm before it can be registered as an instance to the role.


For authentication to be successful, the user must belong to the role and they must authenticate to each module defined in the Authentication Configuration Service instance configured for that role. For each instance of role-based authentication, the following attributes can be specified:

Conflict Resolution Level. This sets a priority level for the Authentication Configuration Service instance defined for different roles that both may contain the same user. For example, if User1 is assigned to both Role1 and Role2, a higher conflict resolution level can be set for Role1 so when the user attempts authentication, Role1 will have the higher priority for success or failure redirects and post-authentication processes.

Authentication Configuration. This defines the authentication modules configured for the role’s authentication process.

Login Success URL. This defines the URL to which a user is redirected on successful authentication.

Login Failed URL. This defines the URL to which a user is redirected on failed authentication.

Authentication Post Processing Classes. This defines the post-authentication interface.

Role-based Authentication Login URLs

Role-based authentication can be specified in The User Interface Login URL by defining a role Parameter. After calling the correct role, the authentication module(s) to which the user will authenticate are retrieved from the Authentication Configuration Service instance defined for the role.

The login URLs used to specify and initiate this role-based authentication are:

http://server_name.domain_name:port/amserver/UI/Login?role=role_name
http://server_name.domain_name:port/amserver/UI/Login?realm=realm_name&role=role_name

If the realm Parameter is not configured, the realm to which the role belongs is determined from the server host and domain specified in the login URL itself.

Role-based Authentication Redirection URLs

Upon a successful or failed role-based authentication, Access Manager looks for information on where to redirect the user. Following is the order of precedence in which the application will look for this information.

Successful Role-based Authentication Redirection URLs

The redirection URL for successful role-based authentication is determined by checking the following places in the following order:

  1. A URL set by the authentication module.

  2. A URL set by a goto Login URL parameter.

  3. A URL set in the clientType custom files for the iplanet-am-user-success-url attribute of the user’s profile ( amUser.xml).

  4. A URL set in the clientType custom files for the iplanet-am-auth-login-success-url attribute of the role to which the user has authenticated.

  5. A URL set in the clientType custom files for the iplanet-am-auth-login-success-url attribute of another role entry of the authenticated user. (This option is a fallback if the previous redirection URL fails.)

  6. A URL set in the clientType custom files for the iplanet-am-auth-login-success-url attribute of the user’s realm entry.

  7. A URL set in the clientType custom files for the iplanet-am-auth-login-success-url attribute as a global default.

  8. A URL set in the iplanet-am-user-success-url attribute of the user’s profile (amUser.xml).

  9. A URL set in the iplanet-am-auth-login-success-url attribute of the role to which the user has authenticated.

  10. A URL set in the iplanet-am-auth-login-success-url attribute of another role entry of the authenticated user. (This option is a fallback if the previous redirection URL fails.)

  11. A URL set in the iplanet-am-auth-login-success-url attribute of the user’s realm entry.

  12. A URL set in the iplanet-am-auth-login-success-url attribute as a global default.

Failed Role-based Authentication Redirection URLs

The redirection URL for failed role-based authentication is determined by checking the following places in the following order:

  1. A URL set by the authentication module.

  2. A URL set by a goto Login URL parameter.

  3. A URL set in the clientType custom files for the iplanet-am-user-failure-url attribute of the user’s profile ( amUser.xml).

  4. A URL set in the clientType custom files for the iplanet-am-auth-login-failure-url attribute of the role to which the user has authenticated.

  5. A URL set in the clientType custom files for the iplanet-am-auth-login-failure-url attribute of another role entry of the authenticated user. (This option is a fallback if the previous redirection URL fails.)

  6. A URL set in the clientType custom files for the iplanet-am-auth-login-failure-url attribute of the user’s realm entry.

  7. A URL set in the clientType custom files for the iplanet-am-auth-login-failure-url attribute as a global default.

  8. A URL set in the iplanet-am-user-failure-url attribute of the user’s profile (amUser.xml).

  9. A URL set in the iplanet-am-auth-login-failure-url attribute of the role to which the user has authenticated.

  10. A URL set in the iplanet-am-auth-login-failure-url attribute of another role entry of the authenticated user. (This option is a fallback if the previous redirection URL fails.)

  11. A URL set in the iplanet-am-auth-login-failure-url attribute of the user’s realm entry.

  12. A URL set in the iplanet-am-auth-login-failure-url attribute as a global default.

ProcedureTo Configure Role-Based Authentication

  1. Navigate to the realm (or organization) to which you will add the authentication configuration service.

  2. Click the Subjects tab.

  3. Filtered Roles or Roles.

  4. Select the role for which to set the authentication configuration.

    If the Authentication Configuration service has not been added to the role, click Add, select Authentication Service and click Next.

  5. Select the Default Authentication Chain that you wish to enable from the pull down menu.

  6. Click Save.


    Note –

    If you are creating a new role, the Authentication Configuration service is not automatically assigned to it. Make sure that you select the Authentication Configuration service option at the top of the role profile page before you create it.

    When role-based authentication is enabled, the LDAP authentication module can be left as the default, as there is no need to configure Membership.


Service-based Authentication

This method of authentication allows a user to authenticate to a specific service or application registered to an realm or sub realm. The service is configured as a Service Instance within the Authentication Configuration Service and is associated with an Instance Name. For authentication to be successful, the user must authenticate to each module defined in the Authentication Configuration service instance configured for the service. For each instance of service-based authentication, the following attributes can be specified:

Authentication Configuration. This defines the authentication modules configured for the service’s authentication process.

Login Success URL. This defines the URL to which a user is redirected on successful authentication.

Login Failed URL. This defines the URL to which a user is redirected on failed authentication.

Authentication Post Processing Classes. This defines the post-authentication interface.

Service-based Authentication Login URLs

Service-based authentication can be specified in the User Interface Login URL by defining a service Parameter. After calling the service, the authentication module(s) to which the user will authenticate are retrieved from the Authentication Configuration service instance defined for the service.

The login URLs used to specify and initiate this service-based authentication are:

http://server_name.domain_name:port/amserver/UI/
Login?service=auth-chain-name

and

http://server_name.domain_name:port/amserver/UI/Login?realm=realm_name&service=auth-chain-name
e

If there is no configured org parameter, the realm will be determined from the server host and domain specified in the login URL itself.

Service-based Authentication Redirection URLs

Upon a successful or failed service-based authentication, Access Manager looks for information on where to redirect the user. Following is the order of precedence in which the application will look for this information.

Successful Service-based Authentication Redirection URLs

The redirection URL for successful service-based authentication is determined by checking the following places in the following order:

  1. A URL set by the authentication module.

  2. A URL set by a goto Login URL parameter.

  3. A URL set in the clientType custom files for the iplanet-am-user-success-url attribute of the user’s profile ( amUser.xml).

  4. A URL set in the clientType custom files for the iplanet-am-auth-login-success-url attribute of the service to which the user has authenticated.

  5. A URL set in the clientType custom files for the iplanet-am-auth-login-success-url attribute of the user’s role entry.

  6. A URL set in the clientType custom files for the iplanet-am-auth-login-success-url attribute of the user’s realm entry.

  7. A URL set in the clientType custom files for the iplanet-am-auth-login-success-url attribute as a global default.

  8. A URL set in the iplanet-am-user-success-url attribute of the user’s profile (amUser.xml).

  9. A URL set in the iplanet-am-auth-login-success-url attribute of the service to which the user has authenticated.

  10. A URL set in the iplanet-am-auth-login-success-url attribute of the user’s role entry.

  11. A URL set in the iplanet-am-auth-login-success-url attribute of the user’s realm entry.

  12. A URL set in the iplanet-am-auth-login-success-url attribute as a global default.

Failed Service-based Authentication Redirection URLs

The redirection URL for failed service-based authentication is determined by checking the following places in the following order:

  1. A URL set by the authentication module.

  2. A URL set by a goto Login URL parameter.

  3. A URL set in the clientType custom files for the iplanet-am-user-failure-url attribute of the user’s profile ( amUser.xml).

  4. A URL set in the clientType custom files for the iplanet-am-auth-login-failure-url attribute of the service to which the user has authenticated.

  5. A URL set in the clientType custom files for the iplanet-am-auth-login-failure-url attribute of the user’s role entry.

  6. A URL set in the clientType custom files for the iplanet-am-auth-login-failure-url attribute of the user’s realm entry.

  7. A URL set in the clientType custom files for the iplanet-am-auth-login-failure-url attribute as a global default.

  8. A URL set in the iplanet-am-user-failure-url attribute of the user’s profile (amUser.xml).

  9. A URL set in the iplanet-am-auth-login-failure-url attribute of the service to which the user has authenticated.

  10. A URL set in the iplanet-am-auth-login-failure-url attribute of the user’s role entry.

  11. A URL set in the iplanet-am-auth-login-failure-url attribute of the user’s realm entry.

  12. A URL set in the iplanet-am-auth-login-failure-url attribute as a global default.

ProcedureTo Configure Service-Based Authentication

Authentication modules are set for services after adding the Authentication Configuration service. To do so:

  1. Chose the realm to which you wish to configure service-based authentication.

  2. Click the Authentication tab.

  3. Create the authentication module instances.

  4. Create the authentication chains.

  5. Click Save.

  6. To access service-based authentication for the realm, enter the following address:

    http://server_name.domain_name:port/amserver/UI/Login?realm=realm_name&service=auth-chain-name

User-based Authentication

This method of authentication allows a user to authenticate to an authentication process configured specifically for the user. The process is configured as a value of the User Authentication Configuration attribute in the user’s profile. For authentication to be successful, the user must authenticate to each module defined.

User-based Authentication Login URLs

User-based authentication can be specified in the User Interface Login URL by defining a user Parameter. After calling the correct user, the authentication module(s) to which the user will authenticate are retrieved from the User Authentication Configuration instance defined for the user.

The login URLs used to specify and initiate this role-based authentication are:

http://server_name.domain_name:port/amserver/UI/Login?user=user_name
http://server_name.domain_name:port/amserver/UI/Login?org=org_name&user=user_name

If there is no configured realm Parameter, the realm to which the role belongs will be determined from the server host and domain specified in the login URL itself.

User Alias List Attribute

On receiving a request for user-based authentication, the Authentication service first verifies that the user is a valid user and then retrieves the Authentication Configuration data for them. In the case where there is more then one valid user profile associated with the value of the user Login URL parameter, all profiles must map to the specified user. The User Alias Attribute (iplanet-am-user-alias-list ) in the User profile is where other profiles belonging to the user can be defined. If mapping fails, the user is denied a valid session. The exception would be if one of the users is a top-level admin whereby the user mapping validation is not done and the user is given top—level Admin rights.

User-based Authentication Redirection URLs

Upon a successful or failed user-based authentication, Access Manager looks for information on where to redirect the user. Following is the order of precedence in which the application will look for this information.

Successful User-based Authentication Redirection URLs

The redirection URL for successful user-based authentication is determined by checking the following places in order of precedence:

  1. A URL set by the authentication module.

  2. A URL set by a goto Login URL parameter.

  3. A URL set in the clientType custom files for the iplanet-am-user-success-url attribute of the user’s profile ( amUser.xml).

  4. A URL set in the clientType custom files for the iplanet-am-auth-login-success-url attribute of the user’s role entry.

  5. A URL set in the clientType custom files for the iplanet-am-auth-login-success-url attribute of the user’s realm entry.

  6. A URL set in the clientType custom files for the iplanet-am-auth-login-success-url attribute as a global default.

  7. A URL set in the iplanet-am-user-success-url attribute of the user’s profile (amUser.xml).

  8. A URL set in the iplanet-am-auth-login-success-url attribute of the user’s role entry.

  9. A URL set in the iplanet-am-auth-login-success-url attribute of the user’s realm entry.

  10. A URL set in the iplanet-am-auth-login-success-url attribute as a global default.

Failed User-based Authentication Redirection URLs

The redirection URL for failed user-based authentication is determined by checking the following places in the following order:

  1. A URL set by the authentication module.

  2. A URL set by a gotoOnFail Login URL parameter.

  3. A URL set in the clientType custom files for the iplanet-am-user-failure-url attribute of the user’s entry ( amUser.xml).

  4. A URL set in the clientType custom files for the iplanet-am-auth-login-failure-url attribute of the user’s role entry.

  5. A URL set in the clientType custom files for the iplanet-am-auth-login-failure-url attribute of the user’s realm entry.

  6. A URL set in the clientType custom files for the iplanet-am-auth-login-failure-url attribute as a global default.

  7. A URL set for the iplanet-am-user-failure-url attribute in the user’s entry (amUser.xml).

  8. A URL set for the iplanet-am-auth-login-failure-url attribute of the user’s role entry.

  9. A URL set for the iplanet-am-auth-login-failure-url attribute of the user’s realm entry.

  10. A URL set for the iplanet-am-auth-login-failure-url attribute as the global default.

ProcedureTo Configure User-Based Authentication

  1. Navigate to the realm in which you wish to configure authentication for the user.

  2. Click the Subjects tab and click Users.

  3. Click the name of the user you wish to modify

    The User Profile is displayed.


    Note –

    If you are creating a new user, the Authentication Configuration service is not automatically assigned to the user. Make sure that you select the Authentication Configuration service option in the Service profile before you create the user. If this option is not selected, the user will not inherit the authentication configuration defined at for the role.


  4. In the User Authentication Configuration attribute, select the authentication chain you wish to apply.

  5. Click Save.

Authentication Level-based Authentication

Each authentication module can be associated with an integer value for its authentication level. Authentication levels can be assigned by clicking the authentication module’s Properties arrow in Service Configuration, and changing the corresponding value for the module’s Authentication Level attribute. Higher authentication levels define a higher level of trust for the user once that user has authenticated to one or more authentication modules.

The authentication level will be set on a user’s SSO token after the user has successfully authenticated to the module. If the user is required to authenticate to multiple authentication modules, and does so successfully, the highest authentication level value will be set in user’s SSO token.

If a user attempts to access a service, the service can determine if the user is allowed access by checking the authentication level in user’s SSO token. It then redirects the user to go through the authentication modules with a set authentication level.

Users can also access authentication modules with specific authentication level. For example, a user performs a login with the following syntax:

http://hostname:port/deploy_URI/UI/Login?authlevel=
auth_level_value

All modules whose authentication level is larger or equal to auth_level_value will be displayed as an authentication menu for the user to choose. If only one matching module is found, then the login page for that authentication module will be directly displayed.

This method of authentication allows an administrator to specify the security level of the modules to which identities can authenticate. Each authentication module has a separate Authentication Level attribute and the value of this attribute can be defined as any valid integer. With Authentication Level-based authentication, the Authentication Service displays a module login page with a menu containing the authentication modules that have authentication levels equal to or greater then the value specified in the Login URL parameter. Users can select a module from the presented list. Once the user selects a module, the remaining process is based on Module-based Authentication.

Authentication Level-based Authentication Login URLs

Authentication level-based authentication can be specified in the User Interface Login URL by defining the authlevel Parameter. After calling the login screen with the relevant list of modules, the user must choose one with which to authenticate. The login URLs used to specify and initiate authentication level-based authentication are:

http://server_name.domain_name:port/amserver/UI/Login?authlevel=authentication_level

and

http://server_name.domain_name:port/amserver/UI/
Login?realm=realm_name&authlevel=authentication_level

If there is no configured realm parameter, the realm to which the user belongs will be determined from the server host and domain specified in the login URL itself.

Authentication Level-based Authentication Redirection URLs

Upon a successful or failed authentication level-based authentication, Access Manager looks for information on where to redirect the user. Following is the order of precedence in which the application will look for this information.

Successful Authentication Level-based Authentication Redirection URLs

The redirection URL for successful authentication level-based authentication is determined by checking the following places in order of precedence:

  1. A URL set by the authentication module.

  2. A URL set by a goto Login URL parameter.

  3. A URL set in the clientType custom files for the iplanet-am-user-success-url attribute of the user’s profile (amUser.xml).

  4. A URL set in the clientType custom files for the iplanet-am-auth-login-success-url attribute of the user’s role entry.

  5. A URL set in the clientType custom files for the iplanet-am-auth-login-success-url attribute of the user’s realm entry.

  6. A URL set in the clientType custom files for the iplanet-am-auth-login-success-url attribute as a global default.

  7. A URL set in the iplanet-am-user-success-url attribute of the user’s profile (amUser.xml).

  8. A URL set in the iplanet-am-auth-login-success-url attribute of the user’s role entry.

  9. A URL set in the iplanet-am-auth-login-success-url attribute of the user’s realm entry.

  10. A URL set in the iplanet-am-auth-login-success-url attribute as a global default.

Failed Authentication Level-based Authentication Redirection URLs

The redirection URL for failed authentication level-based authentication is determined by checking the following places in the following order:

  1. A URL set by the authentication module.

  2. A URL set by a gotoOnFail Login URL parameter.

  3. A URL set in the clientType custom files for the iplanet-am-user-failure-url attribute of the user’s entry ( amUser.xml).

  4. A URL set in the clientType custom files for the iplanet-am-auth-login-failure-url attribute of the user’s role entry.

  5. A URL set in the clientType custom files for the iplanet-am-auth-login-failure-url attribute of the user’s realm entry.

  6. A URL set in the clientType custom files for the iplanet-am-auth-login-failure-url attribute as a global default.

  7. A URL set for the iplanet-am-user-failure-url attribute in the user’s entry (amUser.xml).

  8. A URL set for the iplanet-am-auth-login-failure-url attribute of the user’s role entry.

  9. A URL set for the iplanet-am-auth-login-failure-url attribute of the user’s realm entry.

  10. A URL set for the iplanet-am-auth-login-failure-url attribute as the global default.

Module-based Authentication

Users can access a specific authentication module using the following syntax:

http://hostname:port/deploy_URI/UI/Login?module=
module_name

Before the authentication module can be accessed, the Core authentication service attribute realm Authentication Modules must be modified to include the authentication module name. If the authentication module name is not included in this attribute, the “authentication module denied” page will be displayed when the user attempts to authenticate.

This method of authentication allows a user to specify the module to which they will authenticate. The specified module must be registered to the realm or sub-realm that the user is accessing. This is configured in the realm Authentication Modules attribute of the realm’s Core Authentication Service. On receiving this request for module-based authentication, the Authentication Service verifies that the module is correctly configured as noted, and if the module is not defined, the user is denied access.

Module-based Authentication Login URLs

Module-based authentication can be specified in the User Interface Login URL by defining a module Parameter. The login URLs used to specify and initiate module-based authentication are:

http://server_name.domain_name:port/amserver/UI/Login?module=authentication_module_name
http://server_name.domain_name:port/amserver/UI/
Login?org=org_name&module=authentication_module_name

If there is no configured org parameter, the realm to which the user belongs will be determined from the server host and domain specified in the login URL itself.

Module-based Authentication Redirection URLs

Upon a successful or failed module-based authentication, Access Manager looks for information on where to redirect the user. Following is the order of precedence in which the application will look for this information.

Successful Module-based Authentication Redirection URLs

The redirection URL for successful module-based authentication is determined by checking the following places in order of precedence:

  1. A URL set by the authentication module.

  2. A URL set by a goto Login URL parameter.

  3. A URL set in the clientType custom files for the iplanet-am-user-success-url attribute of the user’s profile ( amUser.xml).

  4. A URL set in the clientType custom files for the iplanet-am-auth-login-success-url attribute of the user’s role entry.

  5. A URL set in the clientType custom files for the iplanet-am-auth-login-success-url attribute of the user’s realm entry.

  6. A URL set in the clientType custom files for the iplanet-am-auth-login-success-url attribute as a global default.

  7. A URL set in the iplanet-am-user-success-url attribute of the user’s profile (amUser.xml).

  8. A URL set in the iplanet-am-auth-login-success-url attribute of the user’s role entry.

  9. A URL set in the iplanet-am-auth-login-success-url attribute of the user’s realm entry.

  10. A URL set in the iplanet-am-auth-login-success-url attribute as a global default.

Failed Module-based Authentication Redirection URLs

The redirection URL for failed module-based authentication is determined by checking the following places in the following order:

  1. A URL set by the authentication module.

  2. A URL set by a gotoOnFail Login URL parameter.

  3. A URL set in the clientType custom files for the iplanet-am-user-failure-url attribute of the user’s entry ( amUser.xml).

  4. A URL set in the clientType custom files for the iplanet-am-auth-login-failure-url attribute of the user’s role entry.

  5. A URL set in the clientType custom files for the iplanet-am-auth-login-failure-url attribute of the user’s realm entry.

  6. A URL set in the clientType custom files for the iplanet-am-auth-login-failure-url attribute as a global default.

  7. A URL set for the iplanet-am-auth-login-failure-url attribute of the user’s role entry.

  8. A URL set for the iplanet-am-auth-login-failure-url attribute of the user’s realm entry.

  9. A URL set for the iplanet-am-auth-login-failure-url attribute as the global default.

The User Interface Login URL

The Authentication Service user interface is accessed by entering a login URL into the Location Bar of a web browser. This URL is:

http://AccessManager-root/.domain_name:port /service_deploy_uri /UI/Login


Note –

During installation, the service_deploy_uri is configured as amserver. This default service deployment URI will be used throughout this document.


The user interface login URL can also be appended with Login URL Parameters to define specific authentication methods or successful/failed authentication redirection URLs.

Login URL Parameters

A URL parameter is a name/value pair appended to the end of a URL. The parameter starts with a question mark (?) and takes the form name=value. A number of parameters can be combined in one login URL, for example:

http://server_name.domain_name:port/amserver/UI/
Login?module=LDAP&locale=ja&goto=http://www.sun.com

If more than one parameter exists, they are separated by an ampersand (&). The combinations though must adhere to the following guidelines:

The following sections describe parameters that, when appended to the User Interface Login URL and typed in the Location bar of a web browser, achieve various authentication functionality.


Note –

To simplify an authentication URL and parameters for distribution throughout an realm, an administrator might configure an HTML page with a simple URL that possesses links to the more complicated login URLs for all configured authentication methods.


goto Parameter

A goto=successful_authentication_URL parameter overrides the value defined in the Login Success URL of the Authentication Configuration service. It will link to the specified URL when a successful authentication has been achieved. A goto=logout_URL parameter can also be used to link to a specified URL when the user is logging out. For an example of a successful authentication URL:

http://server_name.domain_name:port/amserver/
UI/Login?goto=http://www.sun.com/homepage.html

An example goto logout URL:

http://server_name.domain_name:port/amserver/
UI/Logout?goto=http://www.sun.com/logout.html.

Note –

There is an order of precedence in which Access Manager looks for successful authentication redirection URLs. Because these redirection URLs and their order are based on the method of authentication, this order (and related information) is detailed in the Authentication Types section.


gotoOnFail Parameter

A gotoOnFail=failed_authentication_URL parameter overrides the value defined in the Login Failed URL of the Authentication Configuration service. It will link to the specified URL if a user has failed authentication. An example gotoOnFail URL might be http:// server_name.domain_name:port /amserver/UI/Login?gotoOnFail=http://www.sun.com/auth_fail.html.


Note –

There is an order of precedence in which Access Manager looks for failed authentication redirection URLs. Because these redirection URLs and their order are based on the method of authentication, this order (and related information) is detailed in Authentication Types section.


realm Parameter

The org=realmName parameter allows a user to authenticate as a user in the specified realm.


Note –

A user who is not already a member of the specified realm will receive an error message when they attempt to authenticate with the realm parameter. A user profile, though, can be dynamically created in the Directory Server if all of the following are TRUE:

From this parameter, the correct login page (based on the realm and its locale setting) will be displayed. If this parameter is not set, the default is the top-level realm. For example, an org URL might be:

http://server_name.domain_name:port/amserver/UI/Login?realm=sun

org Parameter

The org=orgName parameter allows a user to authenticate as a user in the specified organization.


Note –

A user who is not already a member of the specified organization will receive an error message when they attempt to authenticate with the org parameter. A user profile, though, can be dynamically created in the Directory Server if all of the following are TRUE:

From this parameter, the correct login page (based on the organization and its locale setting) will be displayed. If this parameter is not set, the default is the top-level organization. For example, an org URL might be:

http://server_name.domain_name:port/amserver/UI/Login?org=sun

user Parameter

The user=userName parameter forces authentication based on the module configured in User Authentication Configuration attribute of the user’s profile. For example, one user’s profile can be configured to authenticate using the Certification module while another user might be configured to authenticate using the LDAP module. Adding this parameter sends the user to their configured authentication process rather than the method configured for their organization. For example:

http://server_name.domain_name:port/amserver/UI/Login?user=jsmith

role Parameter

A role=roleName parameter sends the user to the authentication process configured for the specified role. A user who is not already a member of the specified role will receive an error message when they attempt to authenticate with this parameter. For example:

http://server_name.domain_name:port/amserver/UI/Login?role=manager.

locale Parameter

Access Manager has the capability to display localized screens (translated into languages other than English) for the authentication process as well as for the console itself. The locale=localeName parameter allows the specified locale to take precedence over any other defined locales. The login locale is displayed by the client after searching for the configuration in the following places, order-specific:

  1. Value of locale parameter in Login URL

    The value of the locale=localeName parameter takes precedence over all other defined locales.

  2. Locale defined in user’s profile

    If there is no URL parameter, the locale is displayed based on the value set in the User Preferred Language attribute of the user profile.

  3. Locale defined in the HTTP header

    This locale is set by the web browser.

  4. Locale defined in Core Authentication Service

    This is the value of the Default Auth Locale attribute in the Core Authentication module.

  5. Locale defined in Platform Service

    This is the value of the Platform Locale attribute in the Platform service.

Operating system locale

The locale derived from this pecking order is stored in the user’s session token and Access Manager uses it for loading the localized authentication module only. After successful authentication, the locale defined in the User Preferred Language attribute of the user’s profile is used. If none is set, the locale used for authentication will be carried over. For example:


http://server_name.domain_name:port/amserver/UI/Login?locale=ja.

Note –

Information on how to localize the screen text and error messages can be found in the Access Manager.


module Parameter

The module=moduleName parameter allows authentication via the specified authentication module. Any of the modules can be specified although they must first be registered under the realm to which the user belongs and selected as one of that realm’s authentication modules in the Core Authentication module. For example:

http://server_name.domain_name:port/amserver/UI/Login?module=Unix.

Note –

The authentication module names are case-sensitive when used in a URL parameter.


service Parameter

The service=serviceName parameter allows a user to authenticate via a service’s configured authentication scheme. Different authentication schemes can be configured for different services using the Authentication Configuration service. For example, an online paycheck application might require authentication using the more secure Certificate Authentication module while an realm’s employee directory application might require only the LDAP Authentication module. An authentication scheme can be configured, and named, for each of these services. For example:

http://server_name.domain_name:port/amserver/UI/Login?service=sv1.

Note –

The Authentication Configuration service is used to define a scheme for service-based authentication.


arg Parameter

The arg=newsession parameter is used to end a user’s current session and begin a new one. The Authentication Service will destroy a user’s existing session token and perform a new login in one request. This option is typically used in the Anonymous Authentication module. The user first authenticates with an anonymous session, and then hits the register or login link. For example:

http://server_name.domain_name:port/amserver/UI/Login?arg=newsession.

authlevel Parameter

An authlevel=value parameter tells the Authentication Service to call a module with an authentication level equal to or greater than the specified authentication level value. Each authentication module is defined with a fixed integer authentication level. For example:

http://server_name.domain_name:port/amserver/UI/Login?authlevel=1.

Note –

The Authentication Level is set in each module’s specific profile. .


domain Parameter

This parameter allows a user to login to an realm identified as the specified domain. The specified domain must match the value defined in the Domain Name attribute of the realm’s profile. For example:

http://server_name.domain_name:port/amserver/UI/Login?domain=sun.com.

Note –

A user who is not already a member of the specified domain/realm will receive an error message when they attempt to authenticate with the org parameter. A user profile, though, can be dynamically created in the Directory Server if all of the following points are TRUE:


iPSPCookie Parameter

The iPSPCookie=yes parameter allows a user to login with a persistent cookie. A persistent cookie is one that continues to exist after the browser window is closed. In order to use this parameter, the realm to which the user is logging in must have Persistent Cookies enabled in their Core Authentication module. Once the user authenticates and the browser is closed, the user can login with a new browser session and will be directed to console without having to re-authenticate. This will work until the value of the Persistent Cookie Max Time attribute specified in the Core Service elapses. For example:

http://server_name.domain_name:port/amserver/UI/Login?org=example&iPSPCookie=yes

IDTokenN Parameters

This parameter option to enables a user to pass authentication credentials using a URL or HTML forms. With the IDTokenN=value parameters, a user can be authenticated without accessing the Authentication Service User Interface. This process is called Zero Page Login. Zero page login works only for authentication modules that use one login page. The values of IDToken0, IDToken1, ..., IDTokenN map to the fields on the authentication module’s login page. For example, the LDAP authentication module might use IDToken1 for the userID information, and IDToken2 for password information. In this case, the LDAP module IDTokenN URL would be:

http://server_name.domain_name:port/amserver/UI/
Login?module=LDAP&IDToken1=userID&IDToken2=password

(module=LDAP can be omitted if LDAP is the default authentication module.)

For Anonymous authentication, the login URL parameter would be:

http://server_name.domain_name:port/amserver/UI/Login?module=Anonymous&IDToken1=anonymousUserID.

Note –

The token names Login.Token0, Login.Token1, ..., Login.TokenN (from previous releases) are still supported but will be deprecated in a future release. It is recommended to use the new IDTokenN parameters.


Account Locking

The Authentication Service provides a feature where a user will be locked out from authenticating after n failures. This feature is turned off by default, but can be enabled using the Access Manager console.


Note –

Only modules that throw an Invalid Password Exception can leverage the Account Locking feature.


The Core Authentication service contains attributes for enabling and customizing this feature including (but not limited to):

Email notifications are sent to administrators regarding any account lockouts. (Account locking activities are also logged.)


Note –

For special instructions when using this feature on a Microsoft® Windows 2000 operating system, see “Simple Mail Transfer Protocol (SMTP)” in Appendix A, “AMConfig.properties File.”


Access Manager supports two types of account locking are supported: Physical Locking and Memory Locking, defined in the following sections.

Physical Locking

This is the default locking behavior for Access Manager The locking is initiated by changing the status of a LDAP attribute in the user’s profile to inactive. The Lockout Attribute Name attribute defines the LDAP attribute used for locking purposes.


Note –

An aliased user is one that is mapped to an existing LDAP user profile by configuring the User Alias List Attribute (iplanet-am-user-alias-list in amUser.xml) in the LDAP profile. Aliased users can be verified by adding iplanet-am-user-alias-list to the Alias Search Attribute Name field in the Core Authentication Service. That said, if an aliased user is locked out, the actual LDAP profile to which the user is aliased will be locked. This pertains only to physical lockout with authentication modules other than LDAP and Membership.


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. Following are some special considerations when using the memory locking feature:


Note –

If the Failure URL attribute is set in the user’s profile, neither the lockout warning message nor the message indicating that their account has been locked will not be displayed; the user will be redirected to the defined URL.


Authentication Service Failover

Authentication service failover automatically redirects an authentication request to a secondary server if the primary server fails because of a hardware or software problem or if the server is temporarily shut down.

An authentication context must first be created on an instance of Access Manager where the authentication service is available. If this instance of Access Manager is not available, an authentication context can then be created on a different instance of Access Manager through the authentication failover mechanism. The authentication context will check for server availability in the following order:

  1. The authentication service URL is passed to the AuthContext API. For example:


    AuthContext(orgName, url)

    If this API is used, it will only use the server referenced by the URL. No failover will occur even if the authentication service is available on that server.

  2. The authentication context will check the server defined in the com.iplanet.am.server* attribute of the AMConfig.properties file.

  3. If step 2 fails, then the authentication context queries the platform list from a server where the Naming service is available This platform list is automatically created when multiple instances of Access Manager are installed (generally, for failover purposes) sharing a one instance of Directory Server.

    For example, if the platform list contains URLs for Server1, Server2 and Server3, then the authentication context will loop through Server1 , Server2 and Server3 until authentication succeeds on one of them.

    The platform list may not always be obtained from the same server, as it depends on the availability of the Naming service. Furthermore, Naming service failover may occur first. Multiple Naming service URLs are specified in the com.iplanet.am.naming.url property (in AMConfing.properties ). The first available Naming service URL will be used to identify the server, which will contain the list of servers (in its platform server list) on which authentication failover will occur.

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 (such as specifying a partial host name or IP address to access protected resources). FQDN mapping is enabled by modifying the com.sun.identity.server.fqdnMap attribute in the AMConfig.properties file. The format for specifying this property is:

com.sun.identity.server.fqdnMap[invalid-name ]=valid-name

The value invalid-name would be a possible invalid FQDN host name that may be typed by the user, and valid-name would be the actual host name to which the filter will redirect the user. Any number of mappings can be specified (as illustrated in Code Example 1-1) as long as they conform to the stated requirements. If this property is not set, the user would be sent to the default server name configured in the com.iplanet.am.server.host= server_name property also found in the AMConfig.properties file.


Example 7–1 FQDN Mapping Attribute In AMConfig.properties


com.sun.identity.server.fqdnMap[isserver]=isserver.mydomain.com
com.sun.identity.server.fqdnMap[isserver.mydomain]=isserver.mydomain.com
com.sun.identity.server.fqdnMap[
            IP address]=isserver.mydomain.com


         

Possible Uses For FQDN Mapping

This property can be used for creating a mapping for more than one host name which may be the case if applications hosted on a server are accessible by more than one host name. This property can also be used to configure Access Manager to not take corrective action for certain URLs. For example, if no redirect is required for users who access applications by using an IP address, this feature can be implemented by specifying a map entry such as:

com.sun.identity.server.fqdnMap[IP address ]=IP address.


Note –

If more than one mapping is defined, ensure that there are no overlapping values in the invalid FQDN name. Failing to do so may result in the application becoming inaccessible.


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 re-authenticate. The name of the cookie is defined by the com.iplanet.am.pcookie.name property in AMConfig.properties; the default value is DProPCookie . The cookie value is a 3DES-encrypted string containing the userDN, realm name, authentication module name, maximum session time, idle time, and cache time.

ProcedureTo Enable Persistent Cookies

  1. Turn on the Persistent Cookie Mode in the Core Authentication module.

  2. Configure a time value for the Persistent Cookie Maximum Time attribute in the Core Authentication module.

  3. Append the iPSPCookie Parameter with a value of yes to the User Interface Login URL.

    Once the user authenticates using this URL, if the browser is closed, they can open a new browser window and will be redirected to the console without re-authenticating. This will work until the time defined in Step 2 elapses.

    Persistent Cookie Mode can be turned on using the Authentication SPI method:

    AMLoginModule.setPersistentCookieOn().

Multi-LDAP Authentication Module Configuration In Legacy Mode

As a form of failover or to configure multiple values for an attribute when the Access Manager console only provides one value field, an administrator can define multiple LDAP authentication module configurations under one realm. Although these additional configurations are not visible from the console, they work in conjunction with the primary configuration if an initial search for the requesting user’s authorization is not found. For example, one realm can define a search through LDAP servers for authentication in two different domains or it can configure multiple user naming attributes in one domain. For the latter, which has only one text field in the console, if a user is not found using the primary search criteria, the LDAP module will then search using the second scope. Following are the steps to configure additional LDAP configurations.

ProcedureTo Add An Additional LDAP Configuration

  1. Write an XML file including the complete set of attributes and new values needed for second (or third) LDAP authentication configuration.

    The available attributes can be referenced by viewing the amAuthLDAP.xml located in etc/opt/SUNWam/config/xml. This XML file created in this step though, unlike the amAuthLDAP.xml, is based on the structure of the amadmin.dtd. Any or all attributes can be defined for this file. Code Example 1-2 is an example of a sub-configuration file that includes values for all attributes available to the LDAP authentication configuration.


    <?xml version="1.0" encoding="ISO-8859-1"?>
    <!--
      Copyright (c) 2002 Sun Microsystems, Inc. All rights reserved.
      Use is subject to license terms.
    -->
    <!DOCTYPE Requests
        PUBLIC "-//iPlanet//Sun ONE Access Manager 6.0 Admin CLI DTD//EN"
        "jar://com/iplanet/am/admin/cli/amAdmin.dtd"
    >
    <!--
      Before adding subConfiguration load the schema with
    GlobalConfiguration defined and replace corresponding
     serviceName and subConfigID in this sample file OR load
     serviceConfigurationRequests.xml before loading this sample
    -->
    <Requests>
    <realmRequests DN="dc=iplanet,dc=com">
        <AddSubConfiguration subConfigName = "ssc"
            subConfigId = "serverconfig"
            priority = "0" serviceName="iPlanetAMAuthLDAPService">
    
                  <AttributeValuePair>
                <Attribute name="iplanet-am-auth-ldap-server"/>
                <Value>vbrao.red.iplanet.com:389</Value>
            </AttributeValuePair>
            <AttributeValuePair>
                <Attribute name="iplanet-am-auth-ldap-base-dn"/>
                <Value>dc=iplanet,dc=com</Value>
            </AttributeValuePair>
            <AttributeValuePair>
                <Attribute name="planet-am-auth-ldap-bind-dn"/>
                <Value>cn=amldapuser,ou=DSAME Users,dc=iplanet,dc=com</Value>
            </AttributeValuePair>
            <AttributeValuePair>
                <Attribute name="iplanet-am-auth-ldap-bind-passwd"/>
                <Value>
                      plain text password</Value>
            </AttributeValuePair>
            <AttributeValuePair>
                <Attribute name="iplanet-am-auth-ldap-user-naming-attribute"/>
                <Value>uid</Value>
            </AttributeValuePair>
            <AttributeValuePair>
                <Attribute name="iplanet-am-auth-ldap-user-search-attributes"/>
                <Value>uid</Value>
            </AttributeValuePair>
            <AttributeValuePair>
                <Attribute name="iplanet-am-auth-ldap-search-scope"/>
                <Value>SUBTREE</Value>
            </AttributeValuePair>
            <AttributeValuePair>
                <Attribute name="iplanet-am-auth-ldap-ssl-enabled"/>
                <Value>false</Value>
            </AttributeValuePair>
            <AttributeValuePair>
                <Attribute name="iplanet-am-auth-ldap-return-user-dn"/>
                <Value>true</Value>
            </AttributeValuePair>
            <AttributeValuePair>
                <Attribute name="iplanet-am-auth-ldap-auth-level"/>
                <Value>0</Value>
            </AttributeValuePair>
            <AttributeValuePair>
                <Attribute name="iplanet-am-auth-ldap-server-check"/>
                <Value>15</Value>
            </AttributeValuePair>
    
        </AddSubConfiguration>
    
    </realmRequests>
    </Requests>
    
    
                   
  2. Copy the plain text password as the value for the iplanet-am-auth-ldap-bind-passwd in the XML file created in Step 1.

    The value of this attribute is formatted in bold in the code example.

  3. Load the XML file using the amadmin command line tool.


    ./amadmin -u amadmin -w administrator_password -v -t name_of_XML_file.

    Note that this second LDAP configuration can not be seen or modified using the console.


    Tip –

    There is a sample available for multi-LDAP configuration. See the serviceAddMultipleLDAPConfigurationRequests .xml command line template in /AccessManager-base /SUNWam/samples/admin/cli/bulk-ops/. Instructions can be found in Readme.html at /AccesManager-base /SUNWam/samples/admin/cli/.


Session Upgrade

The Authentication service enables you to upgrade a valid session token based on a second, successful authentication performed by the same user to one realm. If a user with a valid session token attempts to authenticate to a resource secured by his current realm 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 realm, the user will receive a message asking whether they would like to authenticate to the new realm. The user can, at this point, maintain the current session or attempt to authenticate to the new realm. Successful authentication will result in the old session being destroyed and a new one being created.

During session upgrade, if a login page times out, redirection to the original success URL will occur. Timeout values are determined based on:

The values of com.iplanet.am.invalidMaxSessionTimeout and iplanet-am-max-session-time should be greater than the page timeout value, or the valid session information during session upgrade will be lost and URL redirection to the previous successful URL will fail.

Validation Plug-in Interface

An administrator can write username or password validation logic suitable to their realm, 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 plug-in. If the validation is successful, authentication continues; if it fails, an authentication failed page will be thrown. The plug-in extends the com.iplanet.am.sdk.AMUserPasswordValidation class which is part of the Service Management SDK. Information on this SDK can be found in the com.iplanet.am.sdk package in the Access Manager Javadocs.

ProcedureTo Write and Configure a Validation Plug-in

  1. The new plug-in class will extend the com.iplanet.am.sdk. AMUserPasswordValidation class and implement the validateUserID() and validatePassword() methods. AMException should be thrown if validation fails.

  2. Compile the plug-in class and place the .class file in the desired location. Update the classpath so that it is accessible by the Access Manager during runtime.

  3. Login to the Access Manager console as top-level administrator. Click on the Service Management tab, and get to the attributes for the Administration Service. Type the name of the plug-in class (including the package name) in the UserID & Password Validation Plugin Class field.

  4. Logout and login.

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:

Upon failure, the module prompts for its required credentials. After failed authentication, the module stops running, or the logout shared state clears.

Enabling JAAS Shared State

To configure the JAAS shared state:

Upon failure, the authentication module will prompt for the required credentials as per the tryFirstPass option behavior suggested in the JAAS specification.

JAAS Shared State Store Option

To configure the JAAS shared state store option:

After a commit, an abort or a logout, the shared state will be cleared.

Chapter 8 Managing Policies

This chapter describes the Policy Management feature of Sun Java™ System Access Manager. Access Manager’s Policy Management feature enables the top-level administrator or top-level policy administrator to view, create, delete and modify policies for a specific service that can be used across all realms. It also provides a way for a realm or sub realm administrator or policy administrator to view, create, delete and modify policies at the realm level.

This chapter contains the following sections:

Overview

A policy defines rules that specify access privileges to an organization’s protected resources. Businesses posses resources, applications and services that they need to protect, manage and monitor. Policies control the access permissions and usage of these resources by defining when and how a user can perform an action on a given resource. A policy defines the resources for a particular principal.


Note –

A principal can be an individual, a corporation, a role, or a group; anything that can have an identity. for more information, see the Java™ 2 Platform Standard Edition Javadoc.


A single policy can define either binary or non-binary decisions. A binary decision is yes/no, true/ false or allow/deny. A non-binary decision represents the value of an attribute. For example, a mail service might include a mailboxQuota attribute with a maximum storage value set for each user. In general, a policy is configured to define what a principal can do to which resource and under what conditions.

Policy Management Feature

The Policy Management feature provides a policy service for creating and managing policies. The policy service allows administrators to define, modify, grant, revoke and delete permissions to protect resources within the Access Manager deployment. Typically, a policy service includes a data store, a library of interfaces that allows for the creation, administration and evaluation of policies, and a policy enforcer or policy agent. By default, Access Manager uses Sun Java Enterprise System Directory Server for data storage, and provides Java and C APIs for policy evaluation and policy service customization (see the Sun Java System Access Manager 7 2005Q4 Developer’s Guide for more information). It also allows administrator to use the Access Manager console for policy management. Access Manager provides one policy—enabled service, the URL Policy Agent service, which uses down-loadable policy agents to enforce the policies.

URL Policy Agent Service

Upon installation, Access Manager provides the URL Policy Agent service to define policies to protect HTTP URLs. This service allows administrators to create and manage policies through a policy enforcer or policy agent.

Policy Agents

The Policy Agent is the Policy Enforcement Point (PEP) for a server on which an enterprise’s resources are stored. The policy agent is installed separately from Access Manager onto a web server and serves as an additional authorization step when a user sends a request for a web resource that exists on the protected web server. This authorization is in addition to any user authorization request which the resource performs. The agent protects the web server, and in turn, the resource is protected by the authorization plug-in.

For example, a Human Resources web server protected by a remotely-installed Access Manager might have an agent installed on it. This agent would prevent personnel without the proper policy from viewing confidential salary information or other sensitive data. The policies are defined by the Access Manager administrator, stored within the Access Manager deployment and used by the policy agent to allow or deny users access to the remote web server’s content.

The most current Access Manager Policy Agents can be downloaded from the Sun Microsystems Download Center.

More information on installing and administrating the policy agents can be found in the Sun Java System Access Manager Policy Agent 2.2 User’s Guide.


Note –

Policy is evaluated in no particular order although as they are evaluated, if one action value evaluates to deny, subsequent policies are not evaluated, unless the Continue Evaluation On Deny Decision attribute is enabled in the Policy Configuration service.


Access Manager Policy agents enforce decisions only on web URLs (http://... , or https//...). However, agents can be written using the Java and C Policy Evaluation APIs to enforce policy on other resources.

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.

The Policy Agent Process

The process for protected web resources begins when a web browser requests a URL that resides on a server protected by the policy agent. The server’s installed policy agent intercepts the request and checks for existing authentication credentials (a session token).

If the agent has intercepted a request and validated the existing session token, the following process is followed.

  1. If the session token is valid, the user is allowed or denied access. If the token is invalid, the user is redirected to the Authentication Service, as outlined in the following steps.

    Assuming the agent has intercepted a request for which there is no existing session token, the agent redirects the user to the login page even if the resource is protected using a different authentication method.

  2. Once the user’s credentials are properly authenticated, the agent issues a request to the Naming Service which defines the URLs used to connect to Access Manager’s internal services.

  3. If the resource matches the non-enforced list, configured at the agent, access is allowed.

  4. The Naming Service returns locators for the policy service, session service and logging service.

  5. The agent sends a request to the Policy Service to get policy decisions applicable to the user.

  6. Based on the policy decisions for the resource being accessed, the user is either allowed or denied access. If advice on the policy decision indicates a different authentication level or authentication mechanism, the agent redirects the request to the Authentication Service until all criteria is validated.

Policy Types

There are two types of policies that can be configured using Access Manager:

Normal Policy

In Access Manager, a policy that defines access permissions is referred to as a normal policy. A normal policy consists of rules , subjects, conditions, and response providers.

Rules

A rule contains a resource, one or more actions, and a value. Each action can have one or more values.


Note –

It is acceptable to define an action without resources for some services.


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 general rule for subjects is that the policy would apply only if the user is a member of at least one subject in the policy. The default subjects are:

AM Identity Subject

The identities you create and manage under the Realms Subject tab can be added as values of the subject.

Access Manager Roles

Any LDAP role can be added as a value of this subject. An LDAP Role is any role definition that uses the Directory Server role capability. These roles have object classes mandated by Directory Server role definition. The LDAP Role Search filter can be modified in the Policy Configuration Service to narrow the scope and improve performance.

Authenticated Users

Any user with a valid SSOToken is a member of this subject. All authenticated users would be member of this Subject, even if they have authenticated to an organization that is different from the organization in which the policy is defined. This is useful if the resource owner would like to give access to resources that is managed for users from other organizations.

LDAP Groups

Any member of an LDAP group can be added as a value of this subject.

LDAP Roles

Any LDAP role can be added as a value of this subject. An LDAP Role is any role definition that uses the Directory Server role capability. These roles have object classes mandated by Directory Server role definition. The LDAP Role Search filter can be modified in the Policy Configuration Service to narrow the scope and improve performance.

LDAP Users

Any LDAP user can be added as a value of this subject.

Organization

Any member of an organization is a member of this subject

Web Services Clients

Valid values are the DNs of trusted certificates in the local JKS keystore, which correspond to the certificates of trusted WSCs. This subject has dependency on the Liberty Web Services Framework and should be used only by Liberty Service Providers to authorize WSCs. A web service client (WSC) identified by the SSOToken is a member of this subject, if the DN of any principal contained in the SSOToken matches any selected value of this subject.

Make sure that you have created the keystore before you add this Subject to a policy. Information on setting up the keystore can be found in the following location:

AccessManager-base /SUNWam/samples/saml/xmlsig/keytool.html

Access Manager Roles Versus LDAP Roles

An Access Manager role is created using Access Manager These roles have object classes mandated by Access Manager. An LDAP role is any role definition that uses the Directory Server role capability. These roles have object classes mandated by Directory Server role definition. All Access Manager roles can be used as Directory Server roles. However, all Directory Server roles are not necessarily Access Manager roles. LDAP roles can be leveraged from an existing directory by configuring the Policy Configuration Service. Access Manager roles can only be accessed through the hosting Access Manager Policy Service. The LDAP Role Search filter can be modified in the Policy Configuration Service to narrow the scope and improve performance.

Nested Roles

Nested roles can be evaluated correctly as LDAP Roles in the subject of a policy definition.

Conditions

A condition allows you to define constraints on the policy. For example, if you are defining policy for a paycheck application, you can define a condition on this action limiting access to the application only during specific hours. Or, you may wish to define a condition that only grants this action if the request originates from a given set of IP addresses or from a company intranet.

The condition might additionally be used to configure different policies on different URIs on the same domain. For example, http://org.example.com/hr/*jsp can only be accessed by org.example.net from 9 a.m. to 5 p.m., yet http://org.example.com/finance/*.jsp can be accessed by org.example2.net from 5 a.m. to 11 p.m. This can be achieved by using an IP Condition along with a Time Condition. And specifying the rule resource as http://org.example.com/hr/*.jsp, the policy would apply to all the JSPs under http://org.example.com/hr including those in the sub directories.


Note –

The terms referral, rule, resource, subject, condition, action and value correspond to the elements Referral, Rule, ResourceName, Subject, Condition , Attribute and Value in the policy.dtd.


The default conditions you can add are:

Authentication Level

The policy applies if the user’s authentication level is greater than or equal to the Authentication level set in the condition.

This attribute indicates the level of trust for authentication.

The authentication level condition can be used to specify levels other than those from the registered authentication module levels for that realm. This is useful when a policy applies to user authenticated from another realm.

For LE Authentication, the policy applies if the user’s authentication level is less than or equal to the Authentication level set in the condition. The authentication level condition can be used to specify levels other than those from the registered authentication module levels for that realm. This is useful when a policy applies to user authenticated from another realm.

Authentication Scheme

Choose the authentication scheme(s) for the condition from the pull-down menu. These authentication schemes are the authentication modules defined in the Core authentication service at the realm.

IP Address

Sets the condition based on a range of IP Addresses. The fields you can define are:

  • IP Address From/To — Specifies the range of the IP address.

  • DNS Name — Specifies the DNS name. This field can be a fully qualified hostname or a string in one of the following formats:

    domainname

    *.domainname

Session

Sets the condition based on user session data. The fields you can modify are:

  • Max Session Time — Specifies the maximum duration to which the policy is applicable starting from when the session was initiated.

  • Terminate Session — If selected, the user session will be terminated if the session time exceeds the maximum allowed as defined in the Max Session Time field.

    You can use this condition to protect sensitive resources so that the resources are available only for a limited time after authentication.

Session Property

Decides whether a policy is applicable to the request based on values of properties set in the user's Access Manager session. During policy evaluation, the condition returns true only if the user's session has every property value defined in the condition. For properties defined with multiple values in the condition, it is sufficient if the token has at least one value listed for the property in the condition. For example, you can use this condition to apply policies based on attributes in external repositories. A post-authentication plug-in can set up the session properties based on the external attributes.

Time

Sets the condition based on time constraints. The fields are:

  • Date From/To — Specifies the range of the date.

  • Time — Specifies the range of time within a day.

  • Day — Specifies a range of days.

  • Timezone — Specifies a timezone, either standard or custom. Custom timezones can only be a timezone ID recognized by Java (for example, PST). If no value is specified, the default value is the Timezone set in the Access Manager JVM.

Response Providers

Response providers are plug-ins that provide policy-based response attributes. The response provider attributes are sent with policy decisions to the PEP. Access Manager includes one implementation, the IDResponseProvider. Custom response providers are not supported in this version of Access Manager. Agents, PEPs, typically pass these response attributes as headers to applications. Applications typically use these attributes to personalize application pages such as a portal page.

Policy Advices

If a policy is not applicable as determined by the condition, the condition can produce advice messages that indicates why the policy was not applicable to the request. These advice messages are propagated in the policy decision to the Policy Enforcement Point. The Policy Enforcement Point can retrieve this advice and try to take the appropriate action, such as redirecting the user back to the authentication mechanism to authenticate to a higher level. The user may then be prompted for higher level authentication and may be able to access to the resource, if the policy becomes applicable, after proper action for the advice is taken.

More information can be found in the following class:

com.sun.identity.policy.ConditionDecision.getAdvices()

Only AuthLevelCondiiton and AuthSchemeCondition provide advices if the condition is not satisfied.

AuthLevelCondition advice is associated with the following key:

com.sun.identity.policy.plugin.AuthLevelCondition.AUTH_LEVEL_CONDITION_ADVICE

AuthSchemeCondition advice is associated with the following key:

com.sun.identity.policy.plugin.AuthLevelCondition.AUTH_SCHEME_CONDITION_ADVICE

Custom conditions can also produce advices. However, the Access Manager Policy Agents respond only for Auth Level Advice and Auth Scheme Advice. Custom agents could be written to understand and respond to more advices and existing Access Manager agents can be extended to understand and respond to more advices. For more information, see the Sun Java System Access Manager Policy Agent 2.2 User’s Guide.

Referral Policy

An administrator may need to delegate one realm's policy definitions and decisions to another realm. (Alternatively, policy decisions for a resource can be delegated to other policy products.) A referral policy controls this policy delegation for both policy creation and evaluation. It consists of one or more rules and one or more referrals.

Rules

A rule defines the resource whose policy definition and evaluation is being referred.

Referrals

The referral defines the organization to which the policy evaluation is being referred. By default, there are two types of referrals: peer realm and sub realm. They delegate to an realm on the same level and an realm on a sub level, respectively. See Creating Policies for Peer Realms and Sub Realms for more information.


Note –

The realm that is referred to can define or evaluate policies only for those resources (or sub-resources) that have been referred to it. This restriction, however, does not apply to the top-level realm.


Policy Definition Type Document

Once a policy is created and configured, it is stored in Directory Server in XML. In Directory Server, the XML-encoded data is stored in one place. Although policy is defined and configured using the amAdmin.dtd (or the console), it is actually stored in Directory Server as XML that is based on the policy.dtd . The policy.dtd contains the policy element tags extracted from the amAdmin.dtd (without the policy creation tags). So, when the Policy Service loads policies from Directory Server, it parses the XML based on the policy.dtd. The amAdmin.dtd is only used when creating policy with the command line. This section describes the structure of policy.dtd. The policy.dtd exists in the following location:

AccessManager-base/SUNWam/dtd (Solairs)
AccessManager-base/identity/dtd (Linux)

Note –

Throughout the rest of this chapter, only the Solaris directory information will be given. Please note that the directory structure for Linux is different.


Policy Element

Policy is the root element that defines the permissions or rules of a policy and to whom/what the rule applies or the subject. It also defines whether or not the policy is a referral (delegated) policy and whether there are any restrictions (or conditions) to the policy. It may contain one or more of the following sub-elements: Rule, Conditions, Subjects,Referrals, or response providers. The required XML attribute is name which specifies the name of the policy. The referralPolicy attribute identifies whether or not the policy is a referral policy; it defaults to a normal policy if not defined. Optional XML attributes include name and description.


Note –

When tagging a policy as referral, subjects and conditions are ignored during policy evaluation. Conversely, when tagging a policy as normal, any Referrals are ignored during policy evaluation.


Rule Element

The Rule element defines the specifics of the policy and can take three sub-elements: ServiceName, ResourceName , or AttributeValuePair. It defines the type of service or application for which the policy has been created as well as the resource name and the actions which are performed on it. A rule can be defined without any actions; for example, a referral policy rule doesn’t have any actions.


Note –

It is acceptable to have a defined policy that does not include a defined ResourceName element.


ServiceName Element

The ServiceName element defines the name of the service to which the policy applies. This element represents the service type. It contains no other elements. The value is exactly as that defined in the service’s XML file (based on the sms.dtd). The XML service attribute for the ServiceName element is the name of the service (which takes a string value).

ResourceName Element

The ResourceName element defines the object that will be acted upon. The policy has been specifically configured to protect this object. It contains no other elements. The XML service attribute for the ResourceName element is the name of the object. Examples of a ResourceName might be http://www.sunone.com:8080/images on a web server or ldap://sunone.com:389/dc=example,dc=com on a directory server. A more specific resource might be salary://uid=jsmith,ou=people,dc=example,dc=com where the object being acted upon is the salary information of John Smith.

AttributeValuePair Element

The AttributeValuePair element defines an action and its values. It is used as a sub-element to Subject Element, Referral Element and Condition Element. It contains both the Attribute and Value elements and no XML service attributes.

Attribute Element

The Attribute element defines the name of the action. An action is an operation or event that is performed on a resource. POST or GET are actions performed on web server resources, READ or SEARCH are actions performed on directory server resources. The Attribute element must be paired with a Value element. The Attribute element itself contains no other elements. The XML service attribute for the Attribute element is the name of the action.

Value Element

The Value element defines the action values. Allow/deny or yes/no are examples of action values. Other action values can be either boolean, numeric, or strings. The values are defined in the service’s XML file (based on the sms.dtd). The Value element contains no other elements and it contains no XML service attributes.


Note –

Deny rules always take precedence over allow rules. For example, if one policy denies access and another allows it, the result is a deny (provided all other conditions for both policies are met). It is recommended that deny policies be used with extreme caution as they can lead to potential conflicts. If explicit deny rules are used, policies assigned to a user through different subjects (such as role and/or group membership) may result in denied access. Typically, the policy definition process should only use allow rules. The default deny may be used when no other policies apply.


Subjects Element

The Subjects sub-element identifies a collection of principals to which the policy applies; this collection is chosen based on membership in a group, ownership of a role or individual users. It takes the Subject sub-element. The XML attributes that can be defined are:

name. This defines a name for the collection.

description. This defines a description of the subject

includeType. This is not currently used.

Subject Element

The Subject sub-element identifies a collection of principals to which the policy applies; this collection pinpoints more specific objects from the collection defined by the Subjects element. Membership can be based on roles, group membership or simply a listing of individual users. It contains a sub-element, the AttributeValuePair Element. The required XML attribute is type, which identifies a generic collection of objects from which the specifically defined subjects are taken. Other XML attributes include name which defines a name for the collection and includeType which defines whether the collection is as defined, or whether the policy applies to users who are NOT members of the subject.


Note –

When multiple subjects are defined, at least one of the subjects should apply to the user for the policy to apply. When a subject is defined with includeType set to false, the user should not be a member of that subject for the policy to apply.


Referrals Element

The Referrals sub-element identifies a collection of policy referrals. It takes the Referral sub-element. The XML attributes it can be defined with are name which defines a name for the collection and description which takes a description.

Referral Element

The Referral sub-element identifies a specific policy referral. It takes as a sub-element the AttributeValuePair Element. It’s required XML attribute is type which identifies a generic collection of assignments from which the specifically defined referrals are taken. It can also include the name attribute which defines a name for the collection.

Conditions Element

The Conditions sub-element identifies a collection of policy restrictions (time range, authentication level, and so forth). It must contain one or more of the Condition sub-element. The XML attributes it can be defined with are name which defines a name for the collection and description which takes a description.


Note –

The conditions element is an optional element in a policy.


Condition Element

The Condition sub-element identifies a specific policy restriction (time range, authentication level, and sor forth). It takes as a sub-element the AttributeValuePair Element. Its required XML attribute is type which identifies a generic collection of restrictions from which the specifically defined conditions are taken. It can also include the name attribute which defines a name for the collection.

Adding a Policy Enabled Service

You can define policies for resources of a given service only if the service schema has the <Policy> element configures to sms.dtd .

By default, Access Manager provides the URL Policy Agent service ( iPlanetAMWebAgentService). This service is defined in an XML file located in the following directory:

/etc/opt/SUNWam/config/xml/

You can, however add additional policy services to Access Manager. Once the policy service is created, you add it to Access Manager through the amadmin command line utility.

ProcedureTo Add a New Policy Enabled Service

  1. Develop the new policy service in an XML file based on the sms.dtd. Access Manager provides two policy service XML files that you may wish to use as the basis for the new policy service file:

    amWebAgent.xml - This the XML file for the default URL Policy Agent service. It is located in /etc/opt/SUNWam/config/xml/.

    SampleWebService.xml . - This is the sample policy service file located inAccessManager-base/samples/policy .

  2. Save the XML file to the directory from which you will load the new policy service. For example:


    /config/xml/newPolicyService.xml
  3. Load the new policy service with the amadmin command line utility. For example:


    AccessManager-base/SUNWam/bin/amadmin
        --runasdn “uid=amAdmin,ou=People,default_org,
    root_suffix
        --password password
        --schema /config/xml/newPolicyService.xml
  4. After you load the new policy service, you can define rules for the policy definitions through the Access Manager console or by loading a new policy through amadmin.

Creating Policies

You can create, modify and delete policies through the Policy API and the Access Manager console, and create and delete policies through the amadmin command line tool. You can also get and list policies in XML using the amadmin utility. This section focuses on creating policies through the amadmin command line utility and through the Access Manager console. For more information on the Policy APIs, see the Sun Java System Access Manager 7 2005Q4 Developer’s Guide.

Policies are generally created using an XML file and added to Access Manager through the amadmin command line utility and then managed using the Access Manager console (although policies can be created using the console). This is because policies cannot be modified using amadmin directly. To modify a policy, you must first delete the policy from Access Manager and then add the modified policy using amadmin.

In general, policy is created at the realm (or sub realm) level to be used throughout the realm’s tree.

ProcedureTo Create Policies with amadmin

  1. Create the policy XML file based on the amadmin.dtd. This file is located in the following directory:

    AccessManager-base /SUNWam/dtd

  2. Once the policy XML file is developed, you can use the following command to load it:


    AccessManager-base/SUNWam/bin/amadmin
    --runasdn "uid=amAdmin,ou=People,default_org,
    root_suffix"
    --password password
    --data policy.xml
    

    To add multiple policies simultaneously, place the policies in one XML file, as opposed to having one policy in each XML file. If you load policies with multiple XML files in quick succession, the internal policy index may become corrupted and some policies may not participate in policy evaluation.

    When creating policies through amadmin, ensure that the authentication module is registered with the realm while creating authentication scheme condition; that the corresponding LDAP objects realms, groups, roles and users) exist while creating realms, LDAP groups, LDAP roles and LDAP user subjects; that Access Manager roles exist while creating IdentityServerRoles subjects; and that the relevant realms exist while creating sub realm or peer realm referrals.

    Please note that in the text of Value elements in SubrealmReferral, PeerRealmReferral, Realm subject, IdentityServerRoles subject, LDAPGroups subject, LDAPRoles subject and LDAPUsers subject need to be the full DN.

ProcedureTo Create a Normal Policy With the Access Manager Console

  1. Choose the realm for which you would like to create a policy.

  2. Click the Policies tab.

  3. Click New Policy from the Policies list.

  4. Add a name and a description for the policy.

  5. If you wish the policy to be active, select Yes in the Active attribute.

  6. It is not necessary to define all of the fields for normal policies at this time. You may create the policy, then add rules, subjects, conditions, and response providers later. See Managing Policies for more information.

  7. Click Create.

ProcedureTo Create a Referral Policy With the Access Manager Console

  1. Choose the realm for which you would like to create the policy.

  2. Click New Referral from the Policies tab.

  3. Add a name and a description for the policy.

  4. If you wish the policy to be active, select Yes in the Active attribute.

  5. It is not necessary to define all of the fields for referral policies at this time. You may create the policy, then add rules and referrals later. See Managing Policies for more information.

  6. Click Create.

Creating Policies for Peer Realms and Sub Realms

In order to create policies for peer or sub realms, you must first create a referral policy in the parent (or another peer) realm. The referral policy must contain, in its rule definition, the resource prefix that is being managed by the sub realm. Once the referral policy is created in the parent realm (or another peer realm) normal policies can be created at the sub realm (or peer realm).

In this example, o=isp is the parent realm and o=example.com is the sub realm that manages resources and sub-resources of http://www.example.com.

ProcedureTo Create a Policy for a Sub Realm

  1. Create a referral policy at o=isp. For information on referral policies, see the procedure Modifying a Referral Policy.

    The referral policy must define http://www.example.com as the resource in the rule, and must contain a SubRealmReferral with example.com as the value in the referral.

  2. Navigate to the sub realm example.com.

  3. Now that the resource is referred to example.com by isp, normal policies can be created for the resource http://www.example.com , or for any resource starting with http://www.example.com .

    To define policies for other resources managed by example.com, additional referral policies must be created at o= isp.

Managing Policies

Once a normal or referral policy is created and added to Access Manager, you can manage the policy through the Access Manager console by modifying the rules, subjects, conditions and referrals.

Modifying a Normal Policy

Through the Policies tab, you can modify a normal policy that defines access permissions. You can define and configure multiple rules, subjects, conditions and resource comparators. This section lists and describes the steps to do so.

ProcedureTo Add or Modify a Rule to a Normal Policy

  1. If you have already created the policy, click the name of the policy for which you wish to add the rule. If not, see To Create a Normal Policy With the Access Manager Console.

  2. Under the Rules menu, click New.

  3. Select one of the following default service types for the rule. You may see a larger list if more services are enabled for the policy:

    Discovery Service

    Defines the authorization actions for Discovery service query and modify protocol invocations by web services clients for a specified resource.

    Liberty Personal Profile Service

    Defines the authorization actions for Liberty Personal Profile service query and modify protocol invocations by web services clients for a specified resource.

    URL Policy Agent

    Provides the URL Policy Agent service for policy enforcement. This service allows administrators to create and manage policies through a policy enforcer or policy agent.

  4. Click Next.

  5. Enter a name and resource name for the rule.

    Currently, Policy Agents only support http:// and https:// resources and do not support IP addresses in place of the hostname.

    Wildcards are supported for host, port, and resource names. For example:


    http*://*:*/*.html

    For the URL Policy Agent service, if a port number is not entered, the default port number is 80 for http://, and 443 for https://.

  6. Select the action for the rule. If you are using the URL Policy Agent service, you can select the following:

    • GET

    • POST

  7. Select the Action Values.

    • Allow — Enables you to access the resource matching the resource defined in the rule.

    • Deny — Denies access to the resource matching the resource defined in the rule.

    • Denial rules always take precedence over allow rules. For example, if you have two policies for a given resource, one denying access and the other allowing access, the result is a deny access (provided that the conditions for both policies are met). It is recommended that deny policies be used with extreme caution as they may lead to potential conflicts between the policies. The policy definition process should only use allow rules. If no policy is applicable to a resource, access is automatically denied.

      If explicit deny rules are used, policies that are assigned to a given user through different subjects (such as role and/or group membership) may result in denied access to a resource even if one or more of the policies allow access. For example, if there is a deny policy for a resource applicable to an Employee role and there is another allow policy for the same resource applicable to Manager role, policy decisions for users assigned both Employee and Manager roles would be denied.

      One way to resolve such problems is to design policies using Condition plug-ins. In the case above, a “role condition” that applies the deny policy to users authenticated to the Employee role and applies the allow policy to users authenticated to the Manager role helps differentiate the two policies. Another way could be to use the authentication level condition, where the Manager role authenticates at a higher authentication level.

  8. Click Finish.

ProcedureTo Add or Modify a Subject to a Normal Policy

  1. If you have already created the policy, click the name of the policy for which you wish to add the subject. If you have not yet created the policy, see To Create a Normal Policy With the Access Manager Console.

  2. Under the Subject list, click New.

  3. Select one of the default subject types. For descriptions of the subject types, see Subjects

  4. Click Next.

  5. Enter a name for the subject.

  6. Select or deselect the Exclusive field.

    If this field is not selected (default), the policy applies to an identity that is a member of the subject. If the field is selected, the policy applies to an identity that is not a member of the subject.

    If multiple subjects exist in the policy, the policy applies to the identity when the identity is a member of at least one subject.

  7. Perform a search in order to display the identities to add to the subject. This step is not applicable for the Authenticated Users subject or Web Services Client subjects.

    The default (*) search pattern will display all entries.

  8. Select the individual identities you wish to add for the subject, or click Add All to add all of the identities at once. Click Add to move the identities to the Selected list. This step is not applicable for the Authenticated Users subject.

  9. Click Finish.

  10. To remove a subject from a policy, select the subject and click Delete. You can edit any subject definition by clicking on the subject name.

ProcedureTo Add a Condition to a Normal Policy

  1. If you have already created the policy, click the name of the policy for which you wish to add the condition. If you have not yet created the policy, see To Create a Normal Policy With the Access Manager Console

  2. Under the Conditions list, click New.

  3. Select the condition type and click Next.

  4. Define the fields for the condition type. For a description of the condition types, see Conditions.

  5. Click Finish.

ProcedureTo Add a Response Provider to a Normal Policy

  1. If you have already created the policy, click the name of the policy for which you wish to add the response provider. If you have not yet created the policy, see To Create a Normal Policy With the Access Manager Console.

  2. Under the Response Providers list, click New.

  3. Enter a name for the response provider.

  4. Define the following values:

    StaticAttribute

    The response attribute with name and values defined in the instance of IDResponseProvider and stored in the policy.

    DynamicAttribute

    The response attributes chosen here need to first be defined in the Policy Configuration Service for the corresponding realm. The attribute names defined should be the same as those existing in the configured datastore. For details on how to define the attributes see the Policy Configuration attribute definitions in the Access Manager online help.

  5. Click Finish.

  6. To remove response provider from a policy, select the subject and click Delete. You can edit any response provider definition by clicking on the name.

Modifying a Referral Policy

You can delegate policy definitions and decisions of a realm to different realms using referral policies. Custom referrals can used to get policy decisions from any policy destination point. Once you have created a referral policy, you can add or modify associated the rules, referrals, and resource providers.

ProcedureTo Add or Modify a Rule to a Referral Policy

  1. If you have already created the policy, click the name of the policy for which you wish to add the rule. If not, see To Create a Referral Policy With the Access Manager Console.

  2. Under the Rules list, click New.

  3. Select one of the following default service types for the rule. You may see a larger list if more services are enabled for the policy:

    Discovery Service

    Defines the authorization actions for Discovery service query and modify protocol invocations by web services clients for a specified resource.

    Liberty Personal Profile Service

    Defines the authorization actions for Liberty Personal Profile service query and modify protocol invocations by web services clients for a specified resource.

    URL Policy Agent

    Provides the URL Policy Agent service for policy enforcement. This service allows administrators to create and manage policies through a policy enforcer or policy agent.

  4. Click Next.

  5. Enter a name and resource name for the rule.

    Currently, Policy Agents only support http:// and https:// resources and do not support IP addresses in place of the hostname.

    Wildcards are supported for resource names, port number, and protocol. For example:


    http://*:*/*.html

    For the URL Policy Agent service, if a port number is not entered, the default port number is 80 for http://, and 443 for https://.

    To allow the management of resource for all servers installed on a specific machine, you can define the resource as http://host*:*. Additionally, you can define the following resource to grant an administrator to a specific organization authority for all of the services in that organization:


    http://*.subdomain.domain.topleveldomain
    
  6. Click Finish.

ProcedureTo Add or Modify Referrals to a Policy

  1. If you have already created the policy, click the name of the policy for which you wish to add the response provider. If you have not yet created the policy, see To Create a Referral Policy With the Access Manager Console.

  2. Under the Rules list, click New.

  3. Select the Service type.

  4. Define the resource in the Rules fields. The fields are:

    Referral— Displays the current referral type.

    Name— Enter the name of the referral.

    Resource Name— Enter the name of the resource.

    Filter— Specifies a filter for the organization names that will be displayed in the Value field. By default, it will display all organization names.

    Value — Select the organization name of the referral.

  5. Click Finish.

    To remove a referral from a policy, select the referral and click Delete.

    You can edit any referral definition by clicking on the Edit link next to the referral name.

ProcedureTo Add a Response Provider to a Referral Policy

  1. If you have already created the policy, click the name of the policy for which you wish to add the response provider. If you have not yet created the policy, see To Create a Normal Policy With the Access Manager Console.

  2. Under the Response Providers list, click New.

  3. Enter a name for the response provider.

  4. Define the following values:

    StaticAttribute

    The response attribute with name and values defined in the instance of IDResponseProvider and stored in the policy.

    DynamicAttribute

    The response attribute with only names selected in the instance of IDResponseProvider in the policy. The values are read from IDRepostitories based on the user identity request during policy evaluation.

  5. Click Finish.

  6. To remove response provider from a policy, select the subject and click Delete. You can edit any response provider definition by clicking on the name.

Policy Configuration Service

The Policy Configuration service is used to configure policy-related attributes for each organization through the Access Manager console. You can also define resource name implementations and Directory Server data stores for use with the Access Manager policy framework. The Directory Server specified in the Policy Configuration Service is used for membership evaluation of LDAP Users, LDAP Groups, LDAP Roles, and organization policy subjects.

Subjects Result Time To Live

To improve policy evaluation performance, membership evaluations are cached for a period of time as defined by the Subjects Result Time To Live attribute in the Policy Configuration service. These cached membership decisions are used until the time defined in the Subjects Result Time To Live attribute has elapsed. Membership evaluation after this is used to reflect the current state of users in the directory.

Dynamic Attributes

These are the allowed dynamic attribute names which are displayed in a list and chosen to define policy response provider dynamic attributes. The names that are defined need to be same as attribute names as defined in the data repository.

amldapuser Definition

amldapuser is a user created during installation used by default to the Directory Server specified in the Policy Configuration service. This can be changed, as necessary, by the administrator or policy administrator of the realm.

Adding Policy Configuration Services

When the realm is created, Policy Configuration service attributes are automatically set for the realm. You can, however, modify the attributes as needed.

Resource—Based Authentication

Some organizations require an advanced authentication scenario where a user authenticates against a particular module based on the resource that they are attempting to access. Resource-based authentication is a feature of Access Manager in which a user must authenticate to a specific authentication module protecting the resource, and not to the default authentication module. This feature is only applicable to first time user authentications.


Note –

This is a separate feature than the resource-based authentication described in Session Upgrade. That particular feature does not have any limitations.


Limitations

Resource—based authentication contains the following limitations:

ProcedureTo Configure Resource—based Authentication

Once both the Access Manager and a policy agent have been installed, resource—based authentication can be configured. To do this, it is necessary to point Access Manager to the Gateway servlet.

  1. Open AMAgent.properties.

    AMAgent.properties can be found (in a Solaris environment) in /etc/opt//SUNWam/agents/config/ .

  2. Comment out the following line:

    #com.sun.am.policy.am.loginURL = http://Access Manager_server_host.domain_name:port/amserver/UI/Login.

  3. Add the following line to the file:

    com.sun.am.policy.am.loginURL = http://AccessManager_host.domain_name:port/amserver/gateway


    Note –

    The gateway servlet is developed using the Policy Evaluation APIs and can be used to write a custom mechanism to accomplish resource-based authentication. See the Chapter 6, Using the Policy APIs, in Sun Java System Access Manager 7 2005Q4 Developer’s Guide in the Access Manager Developer's Guide.


  4. Restart the agent.

Chapter 9 Managing Subjects

The Subjects interface enables basic identity management within a realm. Any identity that you create in the Subjects interface can be used in the subject definition in the for a policy created with the Access Manager Identity Subject type.

The identities you can create and modify are:

User

A user represents an individual’s identity. Users can be created and deleted in groups and can be added or removed from roles and/or groups. You can also assign services to the user.

ProcedureTo Create or Modify a User

  1. Click on the User tab.

  2. Click New.

  3. Enter data for the following fields:

    UserId. This field takes the name of the user with which he or she will log into Access Manager. This property may be a non-DN value.

    First Name. This field takes the first name of the user.

    Last Name. This field takes the last name of the user.

    Full Name — This field takes the full name of the user.

    Password. — This field takes the password for the name specified in the User Id field.

    Password (Confirm) — Confirm the password.

    User Status. This option indicates whether the user is allowed to authenticate through Access Manager.

  4. Click Create.

  5. Once the user is created, you can edit the user information by clicking the name of the user. For information on the user attributes, see the User attributes. Other modifications you can perform:

ProcedureTo Add a User to Roles and Groups

  1. Click the name of the user you wish to modify.

  2. Select Roles or Groups. Only the roles and groups that have already been assigned to the user are displayed.

  3. Select the roles or groups from the Available list and click Add.

  4. Once the roles or groups are displayed in the Selected list, click Save.

ProcedureTo Add Services to an Identity

  1. Select the identity to which you wish to add services.

  2. Click on the Services tab.

  3. Click Add.

  4. Depending on the identity type you selected, the following list of services are displayed:

    • Authentication Configuration

    • Discovery Service

    • Liberty Personal Profile Service

    • Session

    • User

  5. Select the service you with to add and click Next.

  6. Edit the attributes for the service. For a description of the services, click on the service name in Step 4.

  7. Click Finish.

Agents

Access Manager Policy Agents protect content on web servers and web proxy servers from unauthorized intrusions. They control access to services and web resources based on the policies configured by an administrator.

The agent object defines a Policy Agent profile, and allows Access Manager to store authentication and other profile information about a specific agent that is protecting an Access Manager resource. Through the Access Manager console, administrators can view, create, modify and delete agent profiles.

the agent object creation page is the location where you can define the UID/password with which the the agent authenticated to Access Manager. If you have a multiple AM/WS setup using the same Access Manager, this gives you the option of enabling multiple IDs for different agents and to enable and disable them independently from Access Manager. You can also manage some preference values for the agents centrally, rather than editing the AMAgent.properties on each machine.

ProcedureTo Create or Modify an Agent

  1. Click the Agents tab.

  2. Click New.

  3. Enter the values for the following fields:

    Name. Enter the name or identity of the agent. This is the name that the agent will use to log into Access Manager. Multi-byte names are not accepted.

    Password. Enter the agent password. This password must be different than the password used by the agent during LDAP authentication.

    Confirm Password. Confirm the password.

    Device Status. Enter the device status of the agent. If set to Active, the agent will be able to authenticate to and communicate with Access Manager. If set to Inactive, the agent will not be able to authenticate to Access Manager.

  4. Click Create.

  5. Once you have crated the agent, you can additionally edit the following fields:

    Description. Enter a brief description of the agent. For example, you can enter the agent instance name or the name of the application it is protecting.

    Agent Key Value. Set the agent properties with a key/value pair. This property is used by Access Manager to receive agent requests for credential assertions about users. Currently, only one property is valid and all other properties will be ignored. Use the following format:

    agentRootURL=http:// server_name:port/

Creating a Unique Policy Agent Identity

By default, when you create multiple policy agents in a trusted environment, the policy agents contain the same UID and password. Because the UID and passwords are shared, Access Manager cannot distinguish between the agents, which may leave the session cookie open to interception.

The weakness may be present when an Identity Provider provides authentication, authorization and profile information about a user to application(s) (or Service Providers) that are developed by third parties or by unauthorized groups within the enterprise. Possible security issues are:

ProcedureTo Create a Unique Policy Agent Identity

  1. Use the Access Manager administration console to make an entry for each agent.

  2. Run the following command on the password that was entered during the creation of the agent. This command should be invoked on the host where the agent is installed.

    AccessManager-base/SUNWam/agents/bin/crypt_util agent123

    This will give the following output:

    WnmKUCg/y3l404ivWY6HPQ==

  3. Change AMAgent.properties to reflect the new value, and then and restart the agent. Example:

    # The username and password to use for the Application 
    authentication module.
    
    com.sun.am.policy.am.username = agent123
    com.sun.am.policy.am.password = WnmKUCg/y3l404ivWY6HPQ==
    
    # Cross-Domain Single Sign On URL
    # Is CDSSO enabled.
    com.sun.am.policy.agents.cdsso-enabled=true
    
    # This is the URL the user will be redirected to after successful login
    # in a CDSSO Scenario.
    com.sun.am.policy.agents.cdcservletURL = http://server.example.com:port
    /amserver/cdcservlet
  4. Change AMConfig.properties where Access Manager is installed to reflect the new values, and then and restart Access Manager. Example:

    com.sun.identity.enableUniqueSSOTokenCookie=true
    com.sun.identity.authentication.uniqueCookieName=sunIdentityServerAuthNServer
     
    com.sun.identity.authentication.uniqueCookieDomain=.example.com
  5. In the Access Manager console, choose Configuration>Platform.

  6. In the Cookie Domains list, change the cookie domain name:

    1. Select the default iplanet.com domain, and then click Remove.

    2. Enter the host name of the Access Manager installation, and then click Add.

      Example: server.example.com

      You should see two cookies set on the browser:

      • iPlanetDirectoryPro – server.example.com (hostname)

      • sunIdentityServerAuthNServer – example.com (hostname)

Filtered Role

A filtered role is a dynamic role created through the use of an LDAP filter. All users are funneled through the filter and assigned to the role at the time of the role’s creation. The filter looks for any attribute value pair (for example, ca=user*) in an entry and automatically assign the users that contain the attribute to the role.

ProcedureTo Create a Filtered Role

  1. In the Navigation pane, go the organization where the role will be created.

  2. Click New.

  3. Enter a name for the filtered role.

  4. Enter the information for the search criteria.

    For example,


    (&(uid=user1)(|(inetuserstatus=active)(!(inetuserstatus=*))))

    If the filter is left blank, by default, the following role is created:


    (objectclass = inetorgperson)
  5. Click Create to initiate the search based on the filter criteria. The identities defined by the filter criteria are automatically assigned to the role.

  6. Once the filtered role is created click the name of the role to view the Users that belong to the role. You can also add services to the role by clicking the Services tab.

Roles

A role’s members are LDAP entries that posses the role. The criteria of the role itself is defined as an LDAP entry with attributes, identified by the Distinguished Name (DN) attribute of the entry. Once the role is created, you manually add services and users.

ProcedureTo Create or Modify a Role

  1. Click the Role tab.

  2. Click New in the Role list.

  3. Enter a name for the role.

  4. Click Create.

ProcedureTo Add Users to a Role or Group

  1. Click the name of the role or group for which you wish to add users.

  2. Click the Users tab.

  3. Select the users you wish to add from the Available list and click Add.

  4. Once the users are displayed in the Selected list, click Save.

Groups

A group represents a collection of users with a common function, feature or interest. Typically, this grouping has no privileges associated with it. Groups can exist at two levels; within an organization and within other managed groups.

ProcedureTo Create or Modify a Group

  1. Click the Group tab.

  2. Click New from the Group list.

  3. Enter a name for the group.

  4. Click Create.

    Once you have created the group, you can add users to the group by clicking the name of the group and then the User tab.