WebSEAL authentication

WebSEAL authentication

+
Search Tips | Advanced Search

Basic authentication

By default, WebSEAL is configured for authentication over HTTPS using Basic Authentication (BA). To enable Basic Authentication over HTTP edit webseald.conf and change the [ba] stanza.
    # Enable authentication using the Basic Authentication mechanism
    # One of <http, https, both, none>
    ba-auth = https
If you decide to use basic authentication in your configuration you might want to consider changing the security realm displayed in the dialogue window by changing the basic-auth-realm setting.
    # Realm name.  This is the text that is displayed in the
    # browser's dialog box when prompting the user for login data.
    # By default, the string 'Access Manager' is used.
    basic-auth-realm = ITSO Applications
Restart the WebSEAL instance to make the changes effective. To test the settings point your browser to the root of your WebSEAL server.

Once the user is logged in, the only way to close the WebSEAL session is that the user has to close the browser. The browser caches the credentials and automatically authenticates the user again even if WebSEAL closed the session.

Form-based authentication

To configure Form based Authentication in WebSEAL, edit webseald.conf and then restart WebSEAL. Open webseald.conf file and locate the [ba] stanza and set ba-auth = none, then locate the [forms] stanza and change as below:
    # Enable authentication using the forms authentication mechanism
    # One of <http, https, both, none>
    forms-auth = https
Restart your WebSEAL instance to make changes effective, then we can test the configurations by accessing a protected page.
Once the user is logged in you want to close the WebSEAL session the user will need to close he browser or preferably the application could redirect the user to the pkmslogout page. After the user hit this page WebSEAL will destroy the session and displays the logout message.
If you are going to use Form based authentication we can tailor your login and logout pages to match with your applications design by modifying the login.html and logout.html in the directory...
<webseal_instance_root>/lib/html/C/

Client certificate based authentication

To configure certificate based authentication in WebSEAL, edit webseald.conf and then restart WebSEAL.
Using certificates to authenticate clients requires server and client configuration, on the WebSEAL side, open webseald.conf file and locate the [ba] stanza and set the ba-auth=none entry, then locate the [certificate] stanza and change as shown below...
    # When to accept a certificate from HTTPS clients.  
    # 
    # Options are:
    # 
    # never            Never request a client certificate.
    # 
    # required         Always request a client certificate.  Do not accept the
    #                  connection if the client does not present a certificate.
    # 
    # optional         Always request a client certificate.  If presented, use it.
    # 
    # prompt_as_needed Certificates will only be prompted for and processed when
    #                  certificate authentication is necessary (due to an ACL or
    #                  POP check failure).

    accept-client-certs = required
After doing the change, find the [authentication-mechanisms] stanza, uncomment the line and change <cert-ssl-library> for your cert-ssl library. Below we can see the change for AIX, read the WebSEAL Administration Guide, IBM Tivoli Access Manager V5.1,SC32-1359 for information about the specific libraries for the operating system used.
    # Certificates
    cert-ssl     = libsslauthn.a
The second step is to create and load a client certificate into the client browser.
If using self-signed certificates the certificate will also have to be loaded into the WebSEAL keystore as a signer certificate.
If using your own Certificate Authority (CA) then the CA public key certificate will be loaded in the WebSEAL keystore as a signer certificate. WebSEAL does a one-to-one DN (Distinguished Name) matching of the certificate with LDAP. In this sample we will use a self-signed certificate.
First we create the user for the sample user01, with the user create command in pdadmin. The user must be made valid with the user modify command and then the information about the new user can be seen with the user show command in pdadmin.
    # pdadmin -a sec_master
    Enter Password:
    pdadmin sec_master> user create -no-password-policy user01 cn=user01,ou=users,o=itso,c=US user01 " " test
    pdadmin sec_master> user modify user01 account-valid yes
    pdadmin sec_master> user show user01
    Login ID: user01
    LDAP DN: cn=user01,ou=users,o=itso,c=US
    LDAP CN: user01
    LDAP SN:
    Description:
    Is SecUser: Yes
    Is GSO user: No
    Account valid: Yes
    Password valid: Yes
The next step is to create a self-signed certificate which exactly matches the following DN:
    LDAP DN: cn=user01,ou=users,o=itso,c=US
We can create the certificate using the ikeyman tool, refer to the WebSphere Security Fundamentals, REDP3944, for more information about ikeyman and creating a self-signed certificate.
Extract the certificate as Base64-encoded ASCII data (*.arm file) to later import in the WebSEAL keystore. Also Export the certificate as PKCS12 (*.p12 file) to import it into the browser.
Use the ikeyman utility and open the WebSEAL keystore located at...
<webseal_instance_root>\certs\pdsrv.kdb

...the default password is pdsrv.
Import the certificate you exported above with the .arm extension. Restart the WebSEAL instance to pick-up the changes.
Load the certificate into your browser, use the PKCS12 certificate (*.p12 file).
We can test the configuration by accessing a secured resource with your browser. You should be able to login without entering the username or password. Depending on your security settings and browser you might be presented with a certificate request, that allow you to chose the certificate to use.

Token authentication

Token authentication is used in a two-factor authentication, this is used when the users must provide two forms of identification. For example, a single factor of identification, such as a password, plus a second factor in the form of an authentication token. The two-factor method is based on something the user knows plus something the user possesses. It provides a more reliable level of user authentication than reusable passwords.
Tivoli Access Manager provides a built-in two-factor authentication library, xtokenauth. It is a client implementation for the RSA SecurID token authentication server (ACE/Server) and is written against the RSA Authorization API. WebSEAL provides RSA token authentication client (ACE/Agent) functions, and is certified as SecurID Ready.
By default, this built-in shared library for token authentication is hard-coded to map SecurID (RSA) token passcode data. This default token authentication mechanism expects the user name used by the client to map to an existing user account in the Access Manager LDAP registry.
For information about configuring Token Authentication refer to the WebSEAL Administration Guide, IBM Tivoli Access Manager V5.1,SC32-135.

HTTP header authentication

Tivoli Access Manager WebSEAL provides an authentication module that authenticates users based on information obtained from custom HTTP headers supplied by the client or a proxy agent. This module consists of a mapping function that maps header data to an Access Manager identity.
WebSEAL trusts that this custom HTTP header data is the result of a previous authentication. The WebSEAL authentication module is built specifically to map data obtained from Entrust Proxy headers. When you enable HTTP header authentication using the built-in authentication module, you should disable all other authentication methods. You should accept connections only from the Entrust Proxy. By disabling other authentication methods eliminates methods that could be used to impersonate custom HTTP header data.
For information about configuring Token Authentication refer to the WebSEAL Administration Guide, IBM Tivoli Access Manager V5.1,SC32-135.

Kerberos and SPNEGO authentication

WebSEAL supports the SPNEGO protocol and Kerberos authentication for use with Windows clients to achieve Windows desktop Single Sign-On. The SPNEGO protocol allows for a negotiation between the client (browser) and the server regarding the authentication mechanism to use. The client identity presented by the browser can be verified by WebSEAL using Kerberos authentication mechanisms.
WebSEAL's support for Kerberos authentication has been implemented specifically to support a Windows desktop Single Sign-On solution. This solution requires that the WebSEAL server be configured into an Active Directory domain, and that WebSEAL be able to access a Kerberos Key Distribution Center (KDC). In addition, the Internet Explorer client must be configured to use the SPNEGO protocol and Kerberos authentication when contacting WebSEAL.
For information about configuring Kerberos SPNEGO Authentication refer to the WebSEAL Administration Guide, IBM Tivoli Access Manager V5.1,SC32-135.