Chapter 8 Authentication Options

Sun Java™ System Access Manager 6 2005Q1 provides a framework for authentication, which is a process that verifies the identities of users accessing applications within an enterprise. A user must pass an authentication process before accessing the Access Manager console, or any other Access Manager-protected resource. Authentication is implemented through plug-ins that validate the user’s identity. (This plug-in architecture is described more fully in the Access Manager Developer’s Guide.)

The Access Manager console is used to set the default values, to add authentication modules, to create an authentication template and to enable the associated authentication module. This chapter provides an overview of the authentication modules and instructions for adding them. It contains the following sections:

Core Authentication

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 organization. Chapter 21, “Core Authentication Attributes” contains a detailed listing of the Core attributes.

Adding and Enabling the Core Service

Go to the organization for which the Core module is to be added.

Choose Services from the View menu.

Click Add in the Navigation pane.

A list of available modules displays in the Data pane.

Select the checkbox for Core Authentication and click Add.

The Core Authentication module will appear in the Navigation pane assuring the administrator that it has been added.

Click the Core Authentication Properties arrow.

The message A template does not currently exist for this service. Do you want to create one now? appears in the Data pane.

Click Create.

The Core attributes appear in the Data pane. Modify the attributes as necessary. An explanation of the Core attributes can be found in Chapter 21, “Core Authentication Attributes” or by clicking the Help link in the upper right corner of the console.

Active Directory Authentication

The Active Directory authentication module performs authentication in a similar manner to the LDAP Directory Authentication 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 organization.

Adding and Enabling Active Directory Authentication

You must log in to Access Manager as the Organization Administrator or Top-Level Administrator.


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

Go to the organization for which Membership Authentication is to be added.

Choose Services from the View menu.

The Core module, if already added, displays in the Navigation pane. If it is not already added, it can be done concurrently with the Active Directory authentication module.

Click Add in the Navigation pane.

A list of available modules displays in the Data pane.

Select the checkbox for Active Directory authentication and click Add.

The Active Directory authentication module will appear in the Navigation pane assuring the administrator that it has been added.

Click the Active Directory Authentication Properties arrow.

The message A template does not currently exist for this module. Do you want to create one now? appears in the Data pane.

Click Create.

The Active Directory authentication attributes appear in the Data pane. Modify the attributes as necessary.

Click Save.

The Active Directory authentication module has been enabled.

Logging In Using Active Directory Authentication

In order to log in using Active Directory authentication, the Core authentication module attribute “Organization Authentication Modules” on page 298 must be modified to enable and select Active Directory authentication. This ensures that when the user logs in using http://hostname:port/deploy_URI/UI/Login?module=AD, (note case sensitivity) the user will see the Active Directory authentication login window. Based on the authentication type that is being used (such as service, role, user, organization), if the authentication module is configured as the default, there is no need to specify the module name in the URL.

Anonymous Authentication

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.

Adding and Enabling Anonymous Authentication

You must log in to Access Manager as the Organization Administrator or Top-Level Administrator.

Go to the organization for which Anonymous Authentication is to be added.

Choose Services from the View menu.

The Core module, if already added, displays in the Navigation pane. If it is not already added, it can be done concurrently with the Anonymous Authentication module.

Click Add in the Navigation pane.

A list of available modules displays in the Data pane.

Select the checkbox for Anonymous Authentication and click Add.

The Anonymous Authentication module will appear in the Navigation pane assuring the administrator that it has been added.

Click the Anonymous Authentication Properties arrow.

The message A template does not currently exist for this service. Do you want to create one now? appears in the Data pane.

Click Create.

The Anonymous Authentication attributes appear in the Data pane. Modify the attributes as necessary. An explanation of these attributes can be found in Chapter 19, "Anonymous Authentication Attributes" or by clicking the Help link in the upper right corner of the console.

Click Save.

The Anonymous Authentication module has been enabled.

Logging In Using Anonymous Authentication

In order to log in using Anonymous Authentication, the Core Authentication module attribute “Organization Authentication Modules” on page 298 must be modified to enable and select Anonymous Authentication. This ensures that when the user logs in using http(s)://hostname:port/SERVER_DEPLOY_URI//UI/Login?module=Anonymous&org=org_name. To login without the Anonymous Authentication login window, use the following syntax:

http(s)://hostname:port/SERVER_DEPLOY_URI//UI/Login?module=Anonymous&org=org_name&Login.Token1=user_id

Based on the authentication type that is being used (such as service, role, user, organization), if the authentication module is configured as the default, there is no need to specify the module name in the URL.


Note	The Default Anonymous User Name attribute value in the Anonymous Authentication module is anonymous. This is the name users use to log in. A default Anonymous User must be created within the organization. The user id should be identical to the user name specified in the Anonymous Authentication attributes. This can optionally be case sensitive.

Certificate-based Authentication

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 an organization. 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 for these initial Web Server configuration steps. This document can be found at the following location:

Or, see the Sun ONE Application Sever Administrator’s Guide to Security at the following location:

Adding and Enabling Certificate-based Authentication


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.

Go to the organization for which Certificate-based Authentication is to be added.

Choose Services from the View menu.

The Core module, if already added, displays in the Navigation pane. If it is not already added, it can be done concurrently with the Certificate-based Authentication module.

Click Add in the Navigation pane.

A list of available modules displays in the Data pane.

Select the checkbox for Certificate-based Authentication and click Add.

The Certificate-based Authentication module will appear in the Navigation pane assuring the administrator that it has been added.

Click the Certificate-based Authentication Properties arrow.

The message A template does not currently exist for this service. Do you want to create one now? appears in the Data pane.

Click Create.

The Certificate-based Authentication attributes appear in the Data pane. Modify the attributes as necessary. An explanation of these attributes can be found in Chapter 20, "Certificate Authentication Attributes" or by clicking the Help link in the upper right corner of the console.

Click Save.

Adding a Server URL in Platform Server List for Certificate-based Authentication

In order to add this module, you must log in to Access Manager as the Organization Administrator and have Access Manager and the web container configured for SSL and with client authentication enabled. For more information, see “Configuring Access Manager in SSL Mode” on page 63.

Logging In Using Certificate-based Authentication

In order to make certificate-based authentication the default authentication method, the Core Authentication module attribute Organization Authentication Modules (see page 298) must be modified. This ensures that when the user logs in using https://hostname:port/deploy_URI/UI/Login?module=Cert, the user will see the Certificate-based Authentication login window. Based on the authentication type that is being used (such as role, user, organization), if the authentication module is configured as the default, there is no need to specify the module name in the URL.

HTTP Basic Authentication

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). For more information, see Adding and Enabling LDAP Authentication. Once the user successfully authenticates, he/she will be able to re-authenticate without being prompted for username and password.

Adding and Enabling HTTP Basic Authentication

You must log in to Access Manager as the Organization Administrator or Top-Level Administrator and have the LDAP authentication module already registered.

Go to the organization for which HTTP Basic Authentication is to be added.

Choose Services from the View menu.

The Core module, if already added, displays in the Navigation pane. If it is not already added, it can be done concurrently with the HTTP Basic Authentication module.

Click Add in the Navigation pane.

A list of available modules displays in the Data pane.

Select the checkbox for HTTP Basic Authentication and click Add.

The HTTP Basic Authentication module will appear in the Navigation pane assuring the administrator that it has been added.

Click the HTTP Basic Authentication Properties arrow.

The message A template does not currently exist for this service. Do you want to create one now? appears in the Data pane.

Click Create.

The HTTP Basic Authentication attributes appear in the Data pane. Modify the attributes as necessary. An explanation of these attributes can be found in Chapter 22, "HTTP Basic Authentication Attributes" or by clicking the Help link in the upper right corner of the console.

Click Save.

The HTPP Basic Authentication module has been enabled.

Logging In Using HTTP Basic Authentication

In order to log in using HTTP Authentication, the Core Authentication module attribute “Organization Authentication Modules” on page 298 must be modified to enable and select HTTP Basic authentication. This ensures that when the user logs in using http://hostname:port/server_deploy_URI/UI/Login?module=HTTPBasic, the user will see the authentication login window. Based on the authentication type that is being used (such as service, role, user, organization), if the authentication module is configured as the default, there is no need to specify the module name in the URL. If authentication fails, a new instance should be opened and the user should login again. To logout completely after using HTTP Basic authentication, all of the existing browser instances must be closed, and a new browser instance must be started.

JDBC Authentication

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.

Adding and Enabling JDBC Authentication

You must log in to Identity Server as the Organization Administrator or Top-Level Administrator.


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

Go to the organization for which JDBC Authentication is to be added.

Choose Services from the View menu

The Core module, if already added, displays in the Navigation pane. If it is not already added, it can be done concurrently with the JDBC Authentication module.

Click Add in the Navigation pane.

A list of available modules displays in the Data pane.

Select the checkbox for JDBC Authentication and click Add.

The JDBC Authentication module will appear in the Navigation pane assuring the administrator that it has been added.

Click the JDBC Authentication Properties arrow.

The message A template does not currently exist for this service. Do you want to create one now? appears in the Data pane.

Click Create.

The JDBC Authentication attributes appear in the Data pane. Modify the attributes as necessary.

Click Save.

The JDBC Authentication module has been enabled.

Logging In Using JDBC Authentication

In order to log in using JDBC Authentication, the Core Authentication module attribute “Organization Authentication Modules” on page 298 must be modified to enable and select JDBC Authentication. This ensures that when the user logs in using http://hostname:port/deploy_URI/UI/Login?module=JDBC, (note case sensitivity) the user will see the JDBC Authentication login window. Based on the authentication type that is being used (such as service, role, user, organization), if the authentication module is configured as the default, there is no need to specify the module name in the URL.

LDAP Directory Authentication

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 organization-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 organization.The following instructions are provided in the event that the module is disabled.

Adding and Enabling LDAP Authentication

You must log in to Access Manager as the Organization Administrator or Top-Level Administrator.

Go to the organization for which LDAP Authentication is to be added.

Choose Services from the View menu.

The Core module, if already added, displays in the Navigation pane. If it is not already added, it can be done concurrently with the LDAP Authentication module.

Click Add in the Navigation pane.

A list of available modules displays in the Data pane.

Select the checkbox for LDAP Authentication and click Add.

The LDAP Authentication module will appear in the Navigation pane assuring the administrator that it has been added.

Click the LDAP Authentication Properties arrow.

The message A template does not currently exist for this service. Do you want to create one now? appears in the Data pane.

Click Create.

The LDAP Authentication attributes appear in the Data pane. Modify the attributes as necessary. An explanation of these attributes can be found in Chapter 24, "LDAP Authentication Attributes" or by clicking the Help link in the upper right corner of the console.

Enter the password in the Password for Root User Bind attribute. By default, the amldapuser password that was entered during installation is used as the bind user. If your Directory Server allows anonymous access to read user entries, you can skip this step.

To use a different bind user, change the DN of the user in the DN For Root User Bind attribute, and enter the password for that user in the Password for Root User Bind attribute.

Click Save.

The LDAP Authentication module has been enabled.

Logging In Using LDAP Authentication

In order to log in using LDAP Authentication, the Core Authentication module attribute “Organization Authentication Modules” on page 298 must be modified to enable and select LDAP Authentication. This ensures that when the user logs in using http://hostname:port/server_deploy_URI/UI/Login?module=LDAP, the user will see the LDAP Authentication login window. Based on the authentication type that is being used (such as service, role, user, organization), if the authentication module is configured as the default, there is no need to specify the module name in the URL.

Enabling LDAP Authentication Failover

The LDAP authentication attributes include a value field for both a primary and a secondary Directory Server. Access Manager will look to the second server for authentication if the primary server becomes unavailable. For more information, see the LDAP attributes Primary LDAP Server and Secondary LDAP Server.

Multiple LDAP Configuration

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 configurations under one organization. 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 information on multiple LDAP configuration, see “Multi LDAP Configuration” in the Access Manager Developer’s Guide.

Membership Authentication

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.

Adding and Enabling Membership Authentication

You must log in to Access Manager as the Organization Administrator or Top-Level Administrator.

Go to the organization for which Membership Authentication is to be added.

Choose Services from the View menu.

The Core module, if already added, displays in the Navigation pane. If it is not already added, it can be done concurrently with the Membership Authentication module.

Click Add in the Navigation pane.

A list of available modules displays in the Data pane.

Select the checkbox for Membership Authentication and click Add.

The Membership Authentication module will appear in the Navigation pane assuring the administrator that it has been added.

Click the Membership Authentication Properties arrow.

The message A template does not currently exist for this service. Do you want to create one now? appears in the Data pane.

Click Create.

The Membership Authentication attributes appear in the Data pane. Modify the attributes as necessary. An explanation of these attributes can be found in Chapter 25, "Membership Authentication Attributes" or by selecting the Help link in the upper right corner of the console.

Enter the password in the Password for Root User Bind attribute. By default, the amldapuser password that was entered during installation is used as the bind user.

To use a different bind user, change the DN of the user in the DN For Root User Bind attribute, and enter the password for that user in the Password for Root User Bind attribute.

Click Save.

The Membership Authentication module has been enabled.

Logging In Using Membership Authentication

In order to log in using Membership Authentication, the Core Authentication module attribute “Organization Authentication Modules” on page 298 must be modified to enable and select Membership Authentication. This ensures that when the user logs in using http://hostname:port/deploy_URI/UI/Login?module=Membership, (note case sensitivity) the user will see the Membership Authentication login (Self Registration) window. Based on the authentication type that is being used (such as module, role, user, organization), if the authentication module is configured as the default, there is no need to specify the module name in the URL.

MSISDN Authentication

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.

Adding and Enabling MSISDN Authentication

You must log in to Identity Server as the Organization Administrator or Top-Level Administrator.

Go to the organization for which MSISDN Authentication is to be added.

Choose Services from the View menu

The Core module, if already added, displays in the Navigation pane. If it is not already added, it can be done concurrently with the MSISDN Authentication module.

Click Add in the Navigation pane.

A list of available modules displays in the Data pane.

Select the checkbox for MSISDN Authentication and click Add.

The MSISDN Authentication module will appear in the Navigation pane assuring the administrator that it has been added.

Click the MSISDN Authentication Properties arrow.

The message A template does not currently exist for this service. Do you want to create one now? appears in the Data pane.

Click Create.

The MSISDN Authentication attributes appear in the Data pane. Modify the attributes as necessary.

Click Save.

The MSISDN Authentication module has been enabled.

Logging In Using MSISDN Authentication

In order to log in using MSISDN Authentication, the Core Authentication module attribute “Organization Authentication Modules” on page 298 must be modified to enable and select MSISDN Authentication. This ensures that when the user logs in using http://hostname:port/deploy_URI/UI/Login?module=MSISDN, (note case sensitivity) the user will see the MSISDN Authentication login window. Based on the authentication type that is being used (such as service, role, user, organization), if the authentication module is configured as the default, there is no need to specify the module name in the URL.

Windows NT Authentication

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.

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

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. For more information, see NT Authentication Attributes.

Add and enable the Windows NT authentication module.

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:

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.

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

Adding and Enabling Windows NT Authentication

You must log in to Access Manager as the Organization Administrator or Top-Level Administrator.


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.

Go to the organization for which Windows NT Authentication is to be added.

Choose Services from the View menu.

The Core module, if already added, displays in the Navigation pane. If it is not already added, it can be done concurrently with the Windows NT Authentication module.

Click Add in the Navigation pane.

A list of available modules displays in the Data pane.

Select the checkbox for Windows NT Authentication and click Add.

The Windows NT Authentication module will appear in the Navigation pane assuring the administrator that it has been added.

Click the Windows NT Authentication Properties arrow.

The message A template does not currently exist for this service. Do you want to create one now? appears in the Data pane.

Click Create.

The Windows NT Authentication attributes appear in the Data pane. Modify the attributes as necessary. An explanation of these attributes can be found in Chapter 27, "NT Authentication Attributes" or by selecting the Help link in the upper right corner of the console.

Click Save.

The Windows NT Authentication module has been enabled.

Logging In Using Windows NT Authentication

In order to log in using Windows NT Authentication, the Core Authentication module attribute “Organization Authentication Modules” on page 298 must be modified to enable and select NT Authentication. This ensures that when the user logs in using http://hostname:port/deploy_URI/UI/Login?module=NT, the user will see the Windows NT Authentication login window. Based on the authentication type that is being used (such as service, role, user, organization), if the authentication module is configured as the default, there is no need to specify the module name in the URL.

RADIUS Server Authentication

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:

Configure the RADIUS server.

For detailed instructions, see the RADIUS server documentation.

Adding and Enabling RADIUS Authentication

Go to the organization for which RADIUS Authentication is to be added.

Choose Services from the View menu.

The Core module, if already added, displays in the Navigation pane. If it is not already added, it can be done concurrently with the RADIUS Authentication module.

Click Add in the Navigation pane.

A list of available modules displays in the Data pane.

Select the checkbox for RADIUS Authentication and click Add.

The RADIUS Authentication module will appear in the Navigation pane assuring the administrator that it has been added.

Click the RADIUS Authentication Properties arrow.

The message A template does not currently exist for this service. Do you want to create one now? appears in the Data pane.

Click Create.

The RADIUS Authentication attributes appear in the Data pane. Modify the attributes as necessary. An explanation of these attributes can be found in Chapter 28, "RADIUS Authentication Attributes" or by selecting the Help link in the upper right corner of the console.

Click Save.

The RADIUS Authentication module has been enabled.

Logging In Using RADIUS Authentication

In order to log in using RADIUS Authentication, the Core Authentication module attribute “Organization Authentication Modules” on page 298 must be modified to enable and select RADIUS Authentication. This ensures that when the user logs in using http://hostname:port/deploy_URI/UI/Login?module=RADIUS, the user will see the RADIUS Authentication login window. Based on the authentication type that is being used (such as service, role, user, organization), if the authentication module is configured as the default, there is no need to specify the module name in the URL.

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:

connect

listen

resolve

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: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 Authentication

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.

Adding and Enabling SafeWord Authentication

You must log in to Access Manager as the Organization Administrator or Top-Level Administrator.

Go to the organization for which SafeWord Authentication is to be added.

Choose Services from the View menu.

The Core module, if already added, displays in the Navigation pane. If it is not already added, it can be done concurrently with the SafeWord Authentication module.

Click Add in the Navigation pane.

A list of available modules displays in the Data pane.

Select the checkbox for SafeWord Authentication and click Add.

The SafeWord Authentication module will appear in the Navigation pane, assuring the administrator that it has been added.

Click the SafeWord Authentication Properties arrow.

The message A template does not currently exist for this service. Do you want to create one now? appears in the Data pane.

Click Create.

The SafeWord Authentication attributes appear in the Data pane. Modify the attributes as necessary. An explanation of these attributes can be found in Chapter 29, "SafeWord Authentication Attributes", or by clicking the Help link on the upper right corner of the console.

Click Save.

The SafeWord Authentication module has been enabled.

Logging In Using SafeWord Authentication

In order to log in using SafeWord Authentication, the Core Authentication module attribute “Organization Authentication Modules” on page 298 must be modified to enable and select SafeWord Authentication. This ensures that when the user logs in using http://hostname:port/deploy_URI/UI/Login?module=SafeWord, the user will see the SafeWord Authentication login window. Based on the authentication type that is being used (such as role, user, organization), if the authentication module is configured as the default, there is no need to specify the module name in the URL.

Configuring SafeWord with Sun ONE 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:

connect

listen

resolve

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

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.

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 Authentication

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 2004Q2 to Access Manager 2005Q1).

Adding and Enabling SAML Authentication

You must log in to Access Manager as the Organization Administrator or Top-Level Administrator and have the LDAP authentication module already registered.

Go to the organization for which SAML Authentication is to be added.

Choose Services from the View menu.

The Core module, if already added, displays in the Navigation pane. If it is not already added, it can be done concurrently with the SAML Authentication module.

Click Add in the Navigation pane.

A list of available modules displays in the Data pane.

Select the checkbox for SAML Authentication and click Add.

The SAML Authentication module will appear in the Navigation pane assuring the administrator that it has been added.

Click the SAML Authentication Properties arrow.

The message A template does not currently exist for this service. Do you want to create one now? appears in the Data pane.

Click Create.

The SAML Authentication attributes appear in the Data pane. Modify the attributes as necessary. An explanation of these attributes can be found in Chapter 22, "HTTP Basic Authentication Attributes" or by clicking the Help link in the upper right corner of the console.

Click Save.

The SAML Authentication module has been enabled.

Logging In Using SAML Authentication

In order to log in using SAML Authentication, the Core Authentication module attribute “Organization Authentication Modules” on page 298 must be modified to enable and select HTTP Basic authentication. This ensures that when the user logs in using http://hostname:port/server_deploy_URI/UI/Login?module=SAML, the user will see the authentication login window. Based on the authentication type that is being used (such as service, role, user, organization), if the authentication module is configured as the default, there is no need to specify the module name in the URL.

SecurID Authentication

Access Manager can be configured to handle SecureID 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 “The amsecuridd Helper” on page 255.

Adding and Enabling SecurID Authentication

You must log in to Access Manager as the Organization Administrator or Top-Level Administrator.


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.

Go to the organization for which SecurID Authentication is to be added.

Choose Services from the View menu.

The Core module, if already added, displays in the Navigation pane. If it is not already added, it can be done concurrently with the SecurID Authentication module.

Click Add in the Navigation pane.

A list of available modules displays in the Data pane.

Select the checkbox for SecurID Authentication and click Add.

The SecurID Authentication module will appear in the Navigation pane, assuring the administrator that it has been added.

Click the SecurID Authentication Properties arrow.

The message A template does not currently exist for this service. Do you want to create one now? appears in the Data pane.

Click Create.

The SecurID Authentication attributes appear in the Data pane. Modify the attributes as necessary. An explanation of these attributes can be found in Chapter 31, "SecurID Authentication Attributes", or by clicking the Help link on the upper right corner of the console.

Click Save.

The SecurID Authentication module has been enabled.

Logging In Using SecurID Authentication

In order to log in using SecurID Authentication, the Core Authentication module attribute “Organization Authentication Modules” on page 298 must be modified to enable and select SecurID Authentication. This ensures that when the user logs in using http://hostname:port/deploy_URI/UI/Login?module=SecurID, the user will see the SecurID Authentication login window. Based on the authentication type that is being used (such as role, user, organization), if the authentication module is configured as the default, there is no need to specify the module name in the URL.

Unix Authentication

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 organizational 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 organizations.

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:

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 portnumber and ipaddress 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.

Adding and Enabling Unix Authentication

You must log in to the Access Manager as Top-Level Administrator for the following steps.

Select the Service Configuration module.

Click on the Unix Authentication Properties arrow in the Service Name list.

Several Global and one Organization attributes are displayed. Because one Unix helper serves all of the Access Manager server's organizations, most of the Unix attributes are global. An explanation of these attributes can be found in Chapter 32, "Unix Authentication Attributes", or by clicking the Help link in the upper right corner of the console.

Click Save to save the new values for the attributes.

You may log in to Access Manager as the Organization Administrator to enable Unix Authentication for an organization.

Go to the organization for which Unix Authentication is to be added.

Choose Services from the View menu.

The Core module, if already added, displays in the Navigation pane. If it is not already added, it can be done concurrently with the Unix Authentication module.

Click Add in the Navigation pane.

A list of available modules displays in the Data pane.

Select the checkbox for Unix Authentication and click Add.

The Unix Authentication module will appear in the Navigation pane, assuring the administrator that it has been added.

Click the Unix Authentication Properties arrow.

The message A template does not currently exist for this service. Do you want to create one now? appears in the date pane.

Click Create.

The Unix Authentication organization attribute appears in the Data pane. Modify the Authentication Level attribute as necessary. An explanation of this attribute can be found in Chapter 32, "Unix Authentication Attributes", or by clicking the Help link in the upper right corner of the console.

Click Save. The Unix Authentication module is enabled.

Logging In Using Unix Authentication

In order to log in using Unix Authentication, the Core Authentication module attribute “Organization Authentication Modules” on page 298 must be modified to enable and select Unix Authentication. This ensures that when the user logs in using http://hostname:port/deploy_URI/UI/Login?module=Unix, the user will see the Unix Authentication login window. Based on the authentication type that is being used (such as service, role, user, organization), if the authentication module is configured as the default, there is no need to specify the module name in the URL.

Windows Desktop SSO Authentication

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.

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.

Adding and Enabling Windows Desktop SSO Authentication


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.

Create a User in the Windows 2000 Domain Controller.

Setup Internet Explorer.

Add and Configure the Windows Desktop SSO Authentication module.

To Create a User in the Windows 2000 Domain Controller

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

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

Select Active Directory Users and Computers.

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.

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

Restart the server.

To 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.

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

Select the Integrated Windows Authentication option.

Go to Security>Local Internet.

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

Go to Sites and select all of the options.

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

Known Restriction with Internet Explorer

To Add and Configure Windows Desktop SSO Authentication

You must log in to Access Manager as the Organization Administrator or Top-Level Administrator.

Go to the organization for which Windows Desktop SSO Authentication is to be added.

Choose Services from the View menu.

The Core module, if already added, displays in the Navigation pane. If it is not already added, it can be done concurrently with the Windows Desktop SSO Authentication module.

Click Add in the Navigation pane.

A list of available modules displays in the Data pane.

Select the checkbox for Windows Desktop SSO Authentication and click Add.

The Windows Desktop SSO Authentication module will appear in the Navigation pane assuring the administrator that it has been added.

Click the Windows Desktop SSO Authentication Properties arrow.

The message A template does not currently exist for this service. Do you want to create one now? appears in the Data pane.

Click Create.

The Windows Desktop SSO Authentication attributes appear in the Data pane. Modify the attributes as necessary. An explanation of these attributes can be found in Chapter 33, "Windows Desktop SSO Authentication Attributes" or by selecting the Help link in the upper right corner of the console.

Click Save. The Windows Desktop SSO Authentication module is enabled.

Logging In Using Windows Desktop SSO Authentication

In order to log in using Windows Desktop SSO Authentication, the Core Authentication module attribute “Organization Authentication Modules” on page 298 must be modified to enable and select Windows Desktop SSO Authentication. This ensures that when the user logs in from a host which is part of the Windows 2000 Domain Controller and has logged in as a domain user using http://hostname:port/deploy_URI/UI/Login?module=WindowsDesktopSSO, the user will be authenticated. Based on the authentication type that is being used (such as service, role, user, organization), if the authentication module is configured as the default, there is no need to specify the module name in the URL.

Previous Contents Index Next
Sun Java System Access Manager 6 2005Q1 Administration Guide