Sun Java System Access Manager 7 2005Q4 Administration Guide

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:

Configure the RADIUS server.

For detailed instructions, see the RADIUS server documentation.
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:

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

accept
connect
listen
resolve

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.

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 –

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:

Create a User in the Windows 2000 Domain Controller.
Setup Internet Explorer.

To Create a User in the Windows 2000 Domain Controller

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.

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

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.

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.

To Create a New Authentication Module Instance

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

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.

Click New in the Module Instances list.

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

Select the Type of authentication module type for the realm.

Click Create.

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.

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.

To Create a New Authentication Chain

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

Select the Authentication tab.

Click New in the Authentication Chaining list.

Enter a name for the authentication chain.

Click Create.

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.

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.

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

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.

Click Save.