IBM Digital Experience wiki: Resources for WebSphere Portal administrators and developers: Configuring ‘Single Sign On’ between Web Sphere Portal Server 7.0, Tivoli Access Manager WebSEAL version 6.1 on AIX 6.1

Configuring ‘Single Sign On’ between Web Sphere Portal Server 7.0, Tivoli Access Manager WebSEAL version 6.1 on AIX 6.1

Added by

Ashutosh Rajput | Edited by IBM contributor

David A Batres on December 22, 2014 | Version 5

Edit
More Actions ▼

Abstract

No abstract provided.

ShowTable of Contents

Overview

Single sign-on (SSO) is a mechanism whereby a single action of user authentication and authorization can permit a user to access all computers and systems where he has access permission, without the need to enter multiple passwords. Single sign-on reduces human error, a major component of systems failure and is therefore highly desirable.

This document describes how to enable SSO on WebSphere Portal Server using Tivoli Access Manager – WebSEAL in an AIX environment. the following describe how to accomplish this task.

1. Configuring and enabling Trust Association Interceptor (ETAI)
2. Configuring Tivoli Access Manager WebSEAL
3. Enabling Global Security in the WebSphere Portal Server
4. Updating properties files – For WebSphere Portal Server, which will be used by the scripts
5. Executing scripts for connecting WebSphere Portal Server to Tivoli access Manager –WebSEAL and LDAP

Brief Description of the products used

Tivoli Access Manager Java runtime environment offers a reliable environment for developing and deploying Java applications in a Tivoli Access Manager secure domain.

Tivoli Access Manager Runtime contains runtime libraries and supporting files that applications can use to access Tivoli Access Manager Servers.

Access Manager Application Development Kit provides a development environment that enables you to code third-party applications to query the authorization server for authorization decisions.

Access Manager Authorization Server The Access Manager Authorization Server provides access to the authorization service for third-party applications that use the Tivoli Access Manager authorization API in remote cache mode. The authorization server also acts as a logging and auditing collection server to store records of server activity.

WebSEAL is a high-performance, multi-threaded Web server that applies fine-grained security policy to the Tivoli Access Manager protected Web object space. WebSEAL can provide single sign-on solutions and incorporate back-end Web application server resources into its security policy. WebSEAL normally acts as a reverse Web proxy by receiving HTTP/HTTPS requests from a Web browser and delivering content from its own Web server or from junctioned back-end Web server /application servers. Requests passing through WebSEAL are evaluated by the Tivoli Access Manager Authorization service to determine whether the user is authorized to access the requested resource.

WAS plug-in is WebSphere Application Server Web server plug-in, which forwards HTTP requests from the Web server to a WebSphere application.

IBM HTTP Server is a web server

WebSphere Application Server is the application server

WebSphere Portal Server is the application server

Trust Association Interceptor (TAI) provides a way for users to become known to WebSphere Application Server without having to re-authenticate. The result is a simpler, yet still secure, authentication process for requests flowing throughout the network.

Request Flow

The user presents authentication information to WebSEAL during a request for a resource in the protected object space.

WebSEAL invokes the configured authentication module for that type of authentication information.
The authentication module validates the authentication information and returns an identity to WebSEAL.
WebSEAL uses this identity to create a credential for that user, based on data stored for that user in the user registry. This credential is used during authorization decisions for requests made by this user.

An authenticated client request for a resource is directed to the resource manager server and intercepted by the policy enforcer process. For example, the resource manager can be WebSEAL for Hypertext
Transfer Protocol (HTTP), HTTPS access or another application.
The policy enforcer process uses the authorization API to call the authorization service for an authorization decision.
The authorization service performs an authorization check on the resource.
The decision to accept or deny the request is returned as a recommendation to the resource manager (through the policy enforcer).
If the request is finally approved, the resource manager passes the request on to the application responsible for the resource in this case the WebSphere Portal Server page.
The request is than pass to TAI ++ and which validates it and returns the user identity as either a distinguished name (DN) or a short name. WebSphere Application Server performs a registry lookup to verify the distinguished name or convert the short name to a distinguished name before searching for group memberships for that user. If the registry lookup fails, WebSphereWebSphere Application Server refuses to trust the user. If the registry lookup succeeds, WebSphere Application Server generates a Lightweight Third-Party Authentication (LTPA) token for the user. It stores it as a cookie for subsequent authentication during the user's session.
WebSphere Portal server interacts with its database for other security information.

Configuring Trust Association Interceptor (ETAI)

Installing the package in IBM WebSphere Application Server

The ETAI is packaged in this JAR file: com.ibm.sec.authn.tai.ETAI_6.0.jar

Copy the JAR file into the plugins directory from the installation package.

Run the WAS_HOME/bin/osgiCfgInit script to configure the new oSGI bundle.

Copy the jar file to was_home/lib/ext.
Ensure that the ETAI is installed on all of the IBM WebSphere Application Server instances in the cell.

Configuring IBM WebSphere Application Server

Enable global IBM WebSphere Application Server application security.

Refer to section 2.3 for enabling WebSphere Application Server Global security.

Route requests through a web server.

To route the request through Web server IBM HTTP server needs to be installed with the plug-in for the Web server.
Refer to the WebSphere Portal Server installation document for installing and configuring IBM HTTP Server plug-in

Enable trust association

Log in to WebSphere Portal Server Console using the administrator ID.
Expand Security and select Global Security as shown in figure 1.

Figure 1
Expand Web and SIP security as shown in figure 2.

Figure 2
Click on Trust Association as shown in figure 3.

Figure 3
Select Enable Trust Association check box, Click Interceptors as shown in figure 4.

Figure 4
Click New as shown in figure 5.

Figure 5
Enter com.ibm.sec.authn.tai.TAMETai into the Interceptor class name field in figure 6. Click Apply, and Click Save to apply the configuration changes.
Figure 6

Add custom properties

This section follows on from the configuration steps in the preceding section.

Browse to Security, then select Global Security > Trust Association >Interceptor.

Click on the class name link (created in the previous section) as shown in figure 7.

Figure 7

Enter the entries as mentioned in figure8 and click OK, Click Save on next screen to apply the changes as shown in figure 8.

Figure 8

The value of ‘userid’ should be the user created in the section 1.2 (create a trusted SSO user).

Restart the Tivoli Integrated Portal server after all of the custom properties above are saved.

Note: The application server generates and sets an LTPAToken cookie for all successfully authenticated resource requests, regardless of whether the request is for protected or unprotected web resources. This is the default behavior in WAS 7.0 and can be configured using a custom security property - com.ibm.websphere.security.web.setLTPATokenCookieToUnprotectedURI. For more details, refer to the following link from the knowledge center:

http://www-01.ibm.com/support/knowledgecenter/SSAW57_7.0.0/com.ibm.websphere.nd.doc/info/ae/ae/usec_seccustomprop.html?cp=SSAW57_7.0.0%2F1-16-5-866

Configuring Tivoli Access Manager WebSEAL

For the Extended Trust Association Interceptor to accept requests from WebSEAL, you need to do the following tasks on the WebSEAL server to ensure that an Extended Trust Association Interceptor targeted HTTP request is sent.

Create the junction with the required parameters.
Create a trusted SSO user.
Set the dummy password in the configuration file.

Required junction parameters

There are many parameters available when creating a junction in WebSEAL. The two that are required by the Extended Trust Association Interceptor are:

–b supply
It ensures that WebSEAL passes the BA header in the HTTP request. The Extended Trust Association Interceptor requires the dummy password in the BA header; the username is not used.

–c iv-creds
It ensures that WebSEAL passes the logged in user's credential in an iv-creds header in the HTTP request. The Extended Trust Association Interceptor requires this header or it will not handle the request. Other headers can also be passed, such as iv-user, but the iv-creds header must also be passed.

The following example shows how to create a junction in WebSEAL 6.1

Syntax -
server task "webseal_instance_name" create -b supply -c iv-creds -t tcp -h "websphere_hostname" -p "websphere_app_port_number" "junction_name"

Example-
server task default-webseald- create -b supply -c iv-creds -t tcp -h -p 80 /poc2portal

Create a trusted SSO user

The Extended Trust Association Interceptor requires a user to exist in the user registry that will be used to authenticate trust. This user and their password will become the central part of establishing trust between WebSEAL and WebSphere Application Server. The value of the custom property com.ibm.websphere.security.webseal.loginId will be set to this user, and the dummy password in WebSEAL will be set to this user's password.

Syntax-
user create sso cn=sso,o=ibm,c=au sso sso ssopwd
user modify ssouser account-valid yes

If the custom property com.ibm.websphere.security.webseal.useWebSphereUserRegistry is set to true, this user must be created in the WebSphere Application Server user registry. (See the WebSphere Application Server Info Center for details.)

Set the dummy password

WebSEAL provides a mechanism for predetermining the password that's passed in the basic authentication header of the HTTP request. Set the dummy password in the WebSEAL instance configuration file using the –b supply parameter described inRequired junction parameters. The configuration file to update, webseald-instancename.conf, is in your webseal_home/etc directory.

Browse to /opt/pdweb/etc and open the file webseald-default.conf, search for basicauth-dummy-passwd, and change the value of this property to the password of the trusted SSO user. Save the file and restart your WebSEAL instance so the new property value will take effect.

Create an ACL:

Syntax-

acl create adminACL
acl modify adminACL set group SecurityGroup Tr

Attach ACL:
Syntax-
acl attach /WebSEAL/-default/poc2portal/wps/portal adminACL

Enabling Global Security

Expand Security and select Global Security as shown in figure 9.

Figure 9

Click on “Security Configuration Wizard” as shown in figure 10.

Figure 10

Select enable application security and click Next as shown in figure 11.

Figure 11

Select Standalone registry and click Next as shown in figure 12.

Figure 12

Fill in the below details and Click Next as shown in Figure 13.

Figure 13

Where is the user id with admin access in the user registry to which you are connecting.

Click finish.

Figure 14

Click Save to apply changes to the master configuration and restart the WebSphere Application Server as shown in figure 15.

Figure 15

Updating properties files

wkplc.properties

This property file needs to be updated for WebSphere Application Server, WebSphere Portal Server and LDAP related information required by the scripts mentioned in the next section.

Here are the properties updated:

EngineInstallLocation=<path to ConfigEngine directory>

WasSoapPort=<SOAP port>

WasRemoteHostName=<fully qualified host name>

VirtualHostName=default_host

WasUserid=cn=userId,dc=xyz,dc=com

WasPassword=<password>

WasHome=/usr/IBM/WebSphere/AppServer <AppServer directory path>

WasUserHome=/usr/IBM/WebSphere/wp_profile <wps profile path>

ProfileName=wp_profile <profile_name>

CellName=<cell name>

NodeName=<node name>

ServerName=WebSphere_Portal

WasAdminServer=server1

wasJvmBitType=x64 (specific to AIX 64)

WpsInstallLocation=/usr/IBM/WebSphere/PortalServer <wps installation path>

WpsHostName=<fully qualified host name>

WpsHostPort=

PortalAdminId=cn=userId,dc=xyz,dc=com

PortalAdminPwd=<password>

PortalAdminGroupId=cn=admingroup,dc=xyz,dc=com

standalone.ldap.id=ldapitds <create an id>

standalone.ldap.host=<ldap host name>

standalone.ldap.port=<ldap instance listening port>

standalone.ldap.bindDN=cn=root

standalone.ldap.bindPassword=<bind password>

standalone.ldap.ldapServerType=IDS <If registry is Tivoli Directory Server>

standalone.ldap.userIdMap=*:uid

standalone.ldap.groupIdMap=*:cn

standalone.ldap.groupMemberIdMap=ibm-allGroups:member;ibm-allGroups:uniqueMember

standalone.ldap.userFilter=(&(uid=%v)(objectclass=ePerson))

standalone.ldap.groupFilter=(&(cn=%v)(|(objectclass=groupOfNames)(objectclass=groupOfUniqueNames)(objectclass=groupOfURLs)))

standalone.ldap.serverId=cn=userId,dc=xyz,dc=com

standalone.ldap.serverPassword=<password>

standalone.ldap.primaryAdminId=cn=userId,dc=xyz,dc=com

standalone.ldap.primaryAdminPassword=<password>

standalone.ldap.primaryPortalAdminId=cn=userId,dc=xyz,dc=com

standalone.ldap.primaryPortalAdminPassword=<password>

standalone.ldap.primaryPortalAdminGroup=cn=admingroup,dc=xyz,dc=com

standalone.ldap.baseDN=dc=xyz,dc=com

If you want to change the admin user need to specify these properties:

newAdminId=cn=userId,dc=xyz,dc=com

newAdminPw=<password>

newAdminGroupId=cn=admingroup,dc=xyz,dc=com

wkplc_comp.properties

This property file needs to be updated for Tivoli Access Manager (TAM) related information required by the scripts mentioned in the next section. The properties that need to be updated are as follows. For complete list of properties and there explanation refer to the attached property file:

wp.ac.impl.PDAdminId=<TAM admin user ID>

wp.ac.impl.PDAdminPwd=<TAM admin password>

wp.ac.impl.PDPermPath=${WasHome}/java/jre/PdPerm.properties

wp.ac.impl.PDClasspath=${WasHome}/java/jre/lib/ext/PD.jar

wp.ac.impl.PDHome=${WasHome}/java/jre/PolicyDirector

wp.ac.impl.JavaHome=${WasHome}/java/jre/

wp.ac.impl.CfgFilesPath=${WasHome}/java/jre

wp.ac.impl.TamHost=<fully qualified hostname of TAM>

wp.ac.impl.PDServerName=amwp70 (you can specify instance name you want to create as TAM server instance)

wp.ac.impl.SvrSslCfgPort=7223

wp.ac.impl.SvrSslCfgMode=remote

wp.ac.impl.PDPolicyServerList=<fully qualified hostname> :7135:1

wp.ac.impl.PDAuthzServerList= fully qualified hostname:7136:1

wp.ac.impl.PDKeyPath=${WasHome}/java/jre/lib/pdperm.ks

You can specify the below mentioned properties if you need the scripts to create the junction or you can create through command. Refer to Appendix Section C for the command details:

wp.ac.impl.JunctionType=tcp

wp.ac.impl.JunctionPoint=/wpsv70 <Junction with this name will be created>

wp.ac.impl.WebSealInstance=<web seal instance name>

wp.ac.impl.TAICreds=iv-user,iv-creds

wp.ac.impl.JunctionHost=< fully qualified hostname for junction>

wp.ac.impl.JunctionPort =80

Tivoli Access Manager: WebSphere Application Server WebSEAL TAI parameters. You can specify these parameters and the script will enable TAI and create these custom properties with the values specified. Script installs and configures TAI ++.

So if you want to use ETAI for trust association you can leave these parameters blank and refer to section 2.1. If you want to use TAI++ skip section 2.1 and enter the values to the parameters mentioned below and the script (enable-tam-all) will enable the trust association and will create all the parameters.

wp.ac.impl.loginId=<SSO user id>

wp.ac.impl.BaUserName=<admin id>

wp.ac.impl.BaPassword=<admin password>

wp.ac.impl.checkViaHeader=false

wp.ac.impl.viaDepth=0

wp.ac.impl.ssoPwdExpiry=600

wp.ac.impl.ignoreProxy=false

Tivoli Access Manager: Portal authorization parameters .The following information is used to authenticate with TAM:

wp.ac.impl.PDRoot=/WebSEAL

wp.ac.impl.PDCreateAcl=true

wp_security_ids.properties

These properties are used by wp-modify-ldap-security and wp-update-standalone-ldap scripts to change the registry from WebSphere Application user registry to LDAP Stand alone user registry.

standalone.ldap.id=ldapitds <this will create an id with the name you provide here>

standalone.ldap.host= <fully qualified ldap hostname>

standalone.ldap.port=<ldap instance port>

standalone.ldap.bindDN=cn=root

standalone.ldap.bindPassword=<password>

standalone.ldap.ldapServerType=IDS

standalone.ldap.userIdMap=*:uid

standalone.ldap.groupIdMap=*:cn

standalone.ldap.groupMemberIdMap=ibm-allGroups:member;ibm-allGroups:uniqueMember

standalone.ldap.userFilter=(&(uid=%v)(objectclass=ePerson))

standalone.ldap.groupFilter=(&(cn=%v)(|(objectclass=groupOfNames)(objectclass=groupOfUniqueNames)(objectclass=groupOfURLs)))

standalone.ldap.serverId=cn=userId,dc=xyz,dc=com

standalone.ldap.serverPassword=<password>

standalone.ldap.primaryAdminId=cn=userId,dc=xyz,dc=com

standalone.ldap.primaryAdminPassword=<password>

standalone.ldap.primaryPortalAdminId=cn=userId,dc=xyz,dc=com

standalone.ldap.primaryPortalAdminPassword=<password>

standalone.ldap.primaryPortalAdminGroup=cn=admingroup,dc=xyz,dc=com

standalone.ldap.baseDN=dc=xyz,dc=com

standalone.ldap.personAccountRdnProperties=uid

standalone.ldap.groupRdnProperties=cn

Executing scripts

WebSphere Portal to TAM connection

Configuring and connecting WebSphere Portal Server is 3 step processes. These steps should be executed in the sequence, proceed to next step only after you get the ‘Build Successful” message in the command prompt after each step.

Step 1: Run the following task to create the AMJRTE properties file:

/ConfigEngine.sh run-svrssl-config -DWasUserid= <was admin userid> -DWasPassword=<admin password> -Dwp.ac.impl.PDAdminPwd=<Pdadmin password>

Note: If the configuration task fails, validate the values in the wkplc_comp.properties file.
After successful completion of the task following file will be created:
AppServer_root/java/jre/PolicyDirector/PdPerm.properties

Step 2: Run the following task to validate that the AMJRTE properties exists which was created in the previous step:

./ConfigEngine.sh validate-pdadmin-connection -DWasUserid= <was admin userid> -DWasPassword=<admin password> -Dwp.ac.impl.PDAdminPwd=<Pdadmin password>

Note: If the task does not run successfully. Run the run-svrssl-config task to create the properties file, and then run the validate-pdadmin-connection task again. If it fails again verify the values in wkplc.properties. The fact that the task does not run successfully indicates that your portal cannot connect to the Tivoli Access Manager server.

Step 3: Run the following validation task: This task will take 10 to 15 minutes for the completion and it will create all the junctions, ACL, TAI ++ custom properties:

./ConfigEngine.sh enable-tam-all -DWasUserid= <was admin userid> -DWasPassword=<admin password> -Dwp.ac.impl.PDAdminPwd=<Pdadmin password>

Note: If the task does not run successfully, ensure the values you specified in wkplc_comp.properties are valid.

WebSphere Portal to LDAP connection

WebSphere Portal is configured with the default federated repository with a built-in file repository. Therefore, you must run the wp-modify-ldap-security task to switch to a standalone LDAP user registry.

Run the following task:

./ConfigEngine.sh wp-modify-ldap-security -DWasUserid=<was admin userid> -DWasPassword=<admin password> -Dwp.ac.impl.PDAdminPwd=<Pdadmin password>

Appendices

A. References

Release Notes for ITAM 6.1:
http://pic.dhe.ibm.com/infocenter/tivihelp/v2r1/index.jsp?topic=/com.ibm.itame.doc/am611_relnotes.htm

ITAM 6.1 installation guide:
http://pic.dhe.ibm.com/infocenter/tivihelp/v2r1/topic/com.ibm.itame.doc/am611_install.pdf

IBM HTTP Server installation guide:
ftp://public.dhe.ibm.com/software/webserver/appserv/library/v70/ihs_70.pdf

For windows installation refer the following link:
http://www.ibm.com/developerworks/tivoli/library/t-ssotam/

B. Dfinitions

AMRT	Access Manager Run Time
AMRTJ	Access Manager Runtime or Java
AMWPM	Access Manager Web Portal Manger
TDS Client	Tivoli Directory Server Client
AMADK	Access Manager Development Kit
ITIM	IBM Tivoli Identity Manager
ITAM	IBM Tivoli Access Manager
WAS	WebSphere Application Server

C. Creating User and junction in TAM

Run the command ‘pdadmin’

pdadmin> Login
Enter ser ID: userID
Enter Password:
Pdadmin UserID>

Run the following commands to create groups, users, ACL and junctions:

1. Creating groups:
group create group1 cn=group1 ,dc=xyz,dc=com group1

2. Creating Users:
user create user1 cn=user1,dc=xyz,dc=com user1 user1 user1234 group1

3. Creating ACL:
acl create group1ACL
acl modify group1ACL set group group1 Tr

4. Creating junction:
server task <webseal instance name> create -t tcp -c iv_user -h <target host name> -p 80 /<junction_name>

Name of the object to be attached to the acl is derived by commands as shown below in the padmin:

pdadmin userID> object list
/Management
/WebSEAL
pdadmin userID> object list /WebSEAL
/WebSEAL/<hostname>-default

5. Attaching ACL:

acl attach /WebSEAL/<hostname>-default/junction_name/context root group1ACL

About the author

Ashutosh Rajput
I am currently working as Technical lead with IBM and has 9 years of experience in Java/J2EE technologies including Rational, WebSphere and Tivoli Products
I hold Master of Computer Application (MCA) degree and I am Sun certified Java Programmer (SCJP), Sun Certified Web Component Developer (SCWCD), and Sun Certified Business Component Developer (SCBCD).