SSO is an authentication system that permits users to access multiple servers in a domain through a single point of entry. When SSO is deployed in the portal, user sessions are authenticated transparently by an SSO service against authentication sources commonly deployed in the enterprise, such as LDAP or Active Directory.
To deploy SSO in your portal, configure the following resources so that they can share user and domain authentication information:
Configuring an SS0 Authentication Provider for Use with the Portal
This section describes how to configure authentication servers to protect the portal. The following topics provide configuration details for supported and unsupported servers:
You configure the SSO authentication server to protect the portal. You do not need to configure the SSO server to protect the Image Service. If you do, communication between the portal and Image Service can result in errors. The Image Service contains only static public content that ships with every portal installation. No data specific to users or to your organization is ever stored on the Image Service.
Configuring the Windows Integrated Authentication Service
Follow these steps to configure the Windows Integrated Authentication (WIA) service (formerly known as Windows NT LAN Manager (NTLM)) for your SSO deployment:
Open the IIS Internet Service Manager.
In the left pane, expand the Web server folder and then its portal virtual directory subfolder; right-click the sso folder and choose Properties.
Click the Directory Security tab.
In the Anonymous access and authentication control group, click the Edit button.
In the Authenticated Access group, select the Integrated Windows Authentications box. Leave the remaining boxes unselected.
Click OK to accept changes to Directory Security settings.
Click OK to accept changes to Properties.
Note:
In the portal environment where SSO via WIA is deployed, Internet Explorer users are not prompted for a user name and password when they attempt to log into the portal Web site if the following provisions have been made by the client:
The user must be logged into a Windows NT domain as a user that has rights to access the portal.
An HTTP proxy must not reside between the client computer and the portal Web site.
Internet Explorer must be configured to recognize the portal Web site as a local intranet site. If the site is not in the local intranet zone by default, add it from the browser:
Choose Tools | Security | Local Intranet.
Click Sites.
Click Advanced.
Add the address for the portal Web site.
Note:
Netscape Navigator versions prior to 7.1 are not supported. For Netscape Navigator 7.1 (and later), users are prompted for user name and password when they attempt to log in to the portal Web site.
Note:
In the portal environment where SSO via WIA is deployed, the portal does not pass user passwords as Basic Authentication Headers to remote servers.
Configuring Netegrity SiteMinder 4.6
Follow these basic steps to configure Netegrity SiteMinder 4.6 for use with the portal:
To configure SiteMinder Policy Server for your SSO deployment:
Install the server as described in Netegrity documentation.
Open the SiteMinder administrative tool and log in as a user that can create objects.
Create the following objects in the order they are presented.
Table D-1 Procedures for Creating Objects in Netegrity SiteMinder Policy Server 4.6
Object
To create the object:
Agents
In the left pane, right-click Agents and choose Create Agent.
In the Name box, type the name of the portal.
In the address box, type the IP address of the portal or use SiteMinder controls to perform DNS lookup.
In the shared secret box, type a string that matches one to be set on the Web Agent host.
Click Apply and then OK.
User Directory
In the left pane, right-click User Directories and choose Create User Directory.
In the Name box, type a descriptive name for the object, for example Iplanet.
In the NameSpace box, choose the appropriate namespace, for example:
WinNT. If you choose WinNT, specify the Windows NT domain name in the Windows Domain text box.
LDAP. If you choose LDAP, specify the IP address and port number for server that hosts the LDAP user directory and use the LDAP Search and LDAP User DN Lookup group controls to configure search and lookup according to the conventions and examples described in the context-sensitive online help for the Netegrity administration tool.
Click Apply.
To display user groups that have been imported into the Policy Server, click View Contents.
To verify that users have been imported, click Search and query LDAP for specific users.
Click Apply and then OK.
Policy Domain
In the left pane, right-click Policy Domain and choose Create Policy Domain.
In the name box, type a descriptive name for the domain, for example Portal.
In the add directory box, specify the User Directory created above.
Click Apply and then OK.
Realm
In the left pane, click the Domains tab.
Right-click the domain created above and choose Create Realm.
In the name box, type a descriptive name for the realm, for example SSO.
In the Resource group, from the Agent drop-down list box, select the agent you created above.
In the Resource Filter box, type /portal/sso, which is the directory the portal uses to authenticate against SSO services.
In the Authentication Scheme box, choose Basic Authentication.
Click Apply and then OK.
Rule for the Realm
In the left pane, expand the policy domain tree so it displays named realms; right-click the realm created above and choose Create Rule under Realm.
In the name box, type a descriptive name for the rule, for example Allow Access.
In the Realm and Resource group, choose the realm created above; in the resource box, specify /*.
In the Allow/Deny and Enable/Disable group, enable the rule and set it to Allow Access when the rule fires.
In the Action box, click Web Agent Actions and then GET, POST, and PUT.
Click Apply and then OK.
Policy for the Realm
Under the domain created above, right-click Policies and choose Create Policy.
In the Name box, type a descriptive name for the Policy, for example Normal Case.
Click the Users tab and use the controls to add users or groups for whom this policy applies.
Click the Rules tab and use Add/Remove Rules button to add the rule you created above.
Click Apply and then OK.
Configuring Netegrity SiteMinder Web Agent (4.6)
To configure SiteMinder Web Agent for your deployment:
Install the Web Agent setup program on the same host as the portal.
When setup is complete, you are prompted to complete the Web Agent Configuration Wizard. If you choose to run the wizard at a different time, click Start | Programs | SiteMinder | Web Agent Configuration Wizard to open the wizard.
When the wizard prompts for components to configure, choose IIS, click Configure, and complete the following configuration information.
Table D-2 Netegrity SiteMinder Web Agent Configuration Wizard Pages
Prompt
Value
Policy Server
Type the name of the Policy Server you set up in the previous section.
Agent name
Type the name of the agent you created in the previous section.
Cookie domain
Type the fully qualified domain name for which you want the authentication cookie to be forwarded. For example, if you specify .company.com, the cookie enables access to all domains that end in company.com. If you specify .sub.company.com, the cookie enables access only to domains that end in sub.company.com.
IIS Proxy User Name and Password
Type a user name and password to run the SiteMinder ISAPI filter on IIS. This user must have administrator rights on the IIS host.
Shared Secret
Type a string that exactly matches the name of the Agent object you created on the Policy Server.
To open the IIS Web Agent Management Console, click Start | Programs | SiteMinder | IIS Web Agent Management Console.
Modify the configuration as described in the following table.
Table D-3 Web Agent Management Console Configuration
Console Control
To modify settings:
Settings tab
Click the Settings tab and specify the following settings:
Enable Web Agent
Enforce Policies
Single Sign On tab
Click the Single Sign On tab and specify the following settings:
Select Require Cookies and clear the other two boxes.
Set the Cookie Domain to the fully qualified domain name for which you want the cookie to be forwarded. For example, if you specify .company.com, the cookie enables access to all domains that end in company.com. If you specify .sub.company.com, the cookie enables access only to domains that end in sub.company.com.
Restart IIS to apply the modified settings.
Configuring Netegrity SiteMinder 5.5
Follow these basic steps to configure Netegrity SiteMinder Policy Server 5.5 for use with the portal:
To configure SiteMinder Policy Server for your deployment:
Install the server as described in Netegrity documentation.
Open the SiteMinder administrative tool and log in as a user that can create objects.
Create the following objects in the order they are presented.
Table D-4 Procedures for Creating Objects with Netegrity SiteMinder Policy Server 5.5
Object
To create the object:
Host Conf Objects
In the left pane, click Host Conf Object.
In the right pane, right-click the Default Host Configuration Object and choose Duplicate Configuration Object.
In the Name box, type a host name, such as policyserver.
In the Configuration Values group, double-click the policyserver object and use the controls to set the IP address for the policy server address and the three ports, typically 44441, 44442, 44443. For example, type 10.1.140.124,44441,44442,44443.
Click Apply and then OK.
Agents
In the left pane, right-click Agents and choose Create Agent.
In the Name box, type the name of the portal.
Click Apply and then OK.
AgentConf Objects
In the left pane, click Agent Conf Objects.
In the right pane, right-click the type of server that approximates the default settings (for example, IISDefaultSettings) and choose Duplicate Configuration Object.
In the Name box, type a descriptive name for the object, typically the host name followed by the configuration object name, for example PortalServerIISDefaultSettings.
In the Configuration Values group, double-click DefaultAgentName; uncomment the parameter (remove the leading # from) and specify as its value the name of the agent created in the previous step
Click Apply and then OK.
User Directory
In the left pane, right-click User Directories and choose Create User Directory.
In the Name box, type a descriptive name for the object, for example Iplanet.
In the NameSpace box, choose the appropriate namespace, for example:
WinNT. If you choose WinNT, specify the Windows NT domain name in the Windows Domain text box.
LDAP. If you choose LDAP, specify the IP address and port number for the server that hosts the LDAP user directory and use the LDAP Search and LDAP User DN Lookup group controls to configure search and lookup according to the conventions and examples described in the context-sensitive online help for the Netegrity administration tool.
Click Apply.
To display user groups that have been imported into the Policy Server, click View Contents.
To verify that users have been imported, click Search and query LDAP for specific users.
Click Apply and then OK.
Policy Domain
In the left pane, right-click Policy Domain and choose Create Policy Domain.
In the name box, type a descriptive name for the domain, for example Portal.
In the add directory box, specify the User Directory created above.
Click Apply and then OK.
Realm
In the left pane, click the Domains tab.
Right-click the domain created above and choose Create Realm.
In the name box, type a descriptive name for the realm, for example SSO.
In the Resource group, from the Agent drop-down list box, select the agent you created above.
In the Resource Filter box, type /portal/sso, which is the directory the portal uses to authenticate against SSO services.
In the Authentication Scheme box, choose Basic Authentication.
Click Apply and then OK.
Rule for the Realm
In the left pane, expand the policy domain tree so it displays named realms; right-click the realm created above and choose Create Rule under Realm.
In the name box, type a descriptive name for the rule, for example Allow Access.
In the Realm and Resource group, choose the realm created above; in the resource box, specify /*.
In the Allow/Deny and Enable/Disable group, enable the rule and set it to Allow Access when the rule fires.
In the Action box, click Web Agent Actions and then GET, POST, and PUT.
Click Apply and then OK.
Policy for the Realm
Under the domain created above, right-click Policies and choose Create Policy.
In the Name box, type a descriptive name for the Policy, for example Normal Case.
Click the Users tab and use the controls to add users or groups for whom this policy applies.
Click the Rules tab and use Add/Remove Rules button to add the rule you created above.
Click Apply and then OK.
Configuring Netegrity SiteMinder Web Agent (5.5)
To configure SiteMinder Web Agent for your deployment:
Install the Web Agent setup program on the same host as the portal.
When setup is complete, you are prompted to complete the Web Agent Configuration Wizard. If you choose to run the wizard at a different time, click Start | Programs | SiteMinder | Web Agent Configuration Wizard to open the wizard.
When the wizard prompts for components to configure, choose IIS, click Configure, and complete the following configuration information.
Table D-5 Netegrity SiteMinder Web Agent Configuration Wizard Pages
Prompt
Value
Policy Server
Type the name of the Policy Server you set up in the previous section.
Agent name
Type the name of the agent you created in the previous section.
Cookie domain
Type the fully qualified domain name for which you want the authentication cookie to be forwarded. For example, if you specify .company.com, the cookie enables access to all domains that end in company.com. If you specify .sub.company.com, the cookie enables access only to domains that end in sub.company.com.
IIS Proxy User Name and Password
Type a user name and password to run the SiteMinder ISAPI filter on IIS. This user must have administrator rights on the IIS host.
Shared Secret
Type a string that exactly matches the name of the Agent object you created on the Policy Server.
To open the IIS Web Agent Management Console, click Start | Programs | SiteMinder | IIS Web Agent Management Console.
Modify the configuration as described in the following table.
Table D-6 Web Agent Management Console Configuration
Console Control
To modify settings:
Settings tab
Click the Settings tab and specify the following settings:
Enable Web Agent
Enforce Policies
Single Sign On tab
Click the Single Sign On tab and specify the following settings:
Select Require Cookies and clear the other two boxes.
Set the Cookie Domain to the fully qualified domain name for which you want the cookie to be forwarded. For example, if you specify .company.com, the cookie enables access to all domains that end in company.com. If you specify .sub.company.com, the cookie enables access only to domains that end in sub.company.com.
Restart IIS to apply the modified settings.
Configuring a Netegrity SiteMinder 5.5 SP3 and 6.0.2.5
These instructions apply to SSO integration with Netegrity SiteMinder 5.5 SP3, and 6.0.2.5.
Follow these basic steps to configure SiteMinder Policy Server for use with the portal:
To configure SiteMinder Policy Server for your deployment:
On a remote host computer, install SiteMinder Policy Server 5.5 and SP3, or 6.0.2.5, as described in Netegrity documentation.
Open the SiteMinder administrative tool and log in as a user that can create objects.
Create the following objects in the order they are presented.
Table D-7 Procedures for Creating Objects with Netegrity SiteMinder Policy Server
Object
To create the object:
Host Conf Objects
In the left pane, click Host Conf Object.
In the right pane, right-click the Default Host Configuration Object and choose Duplicate Configuration Object.
In the Name box, type a host name, such as policyserver.
In the Configuration Values group, double-click the policyserver object and use the controls to set the IP address for the policy server address and the three ports, typically 44441, 44442, 44443. For example, type:
10.1.140.124,44441,44442,44443
Click Apply and then OK.
Agents
In the left pane, right-click Agents and choose Create Agent.
In the Name box, type the name of host computer for the portal.
Click Apply and then OK.
AgentConf Objects
In the left pane, click Agent Conf Objects.
In the right pane, right-click the type of server that approximates the default settings (for example, ApacheDefaultSettings) and choose Duplicate Configuration Object.
In the Name box, type a descriptive name for the object, typically the host name followed by the configuration object name, for example PortalServerApacheDefaultSettings.
In the Configuration Values group, double-click DefaultAgentName; uncomment the parameter (remove the leading # from) and specify as its value the name of the agent created in the previous step.
In the Configuration Values group, double-click BadURLChars and modify its value to the following:
//,./,/.,/*,*.,~,\
In the Configuration Values group, configure LogAppend, LogConsole, LogFileName, LogLevel, and Logfile to your preferences. For details, refer to the online help.
Click Apply and then OK.
User Directory
In the left pane, right-click User Directories and choose Create User Directory.
In the Name box, type a descriptive name for the object, for example Iplanet.
In the NameSpace box, choose the appropriate namespace, for example, if you choose LDAP, specify the IP address and port number for the server that hosts the LDAP user directory and use the LDAP Search and LDAP User DN Lookup group controls to configure search and lookup according to the conventions and examples described in the context-sensitive online help for the Netegrity administration tool.
Click Apply.
To display user groups that have been imported into the Policy Server, click View Contents.
To verify that users have been imported, click Search and query LDAP for specific users.
Click Apply and then OK.
Policy Domain
In the left pane, right-click Policy Domain and choose Create Policy Domain.
In the name box, type a descriptive name for the domain, for example Portal.
In the add directory box, specify the User Directory created above.
Click Apply and then OK.
Realm
In the left pane, click the Domains tab.
Right-click the domain created above and choose Create Realm.
In the name box, type a descriptive name for the realm, for example SSO.
In the Resource group, from the Agent drop-down list box, select the agent you created above.
In the Resource Filter box, type /portal/SSOServlet, which is the service the portal uses to authenticate against SSO services.
In the Authentication Scheme box, choose Basic Authentication.
Click Apply and then OK.
Rule for the Realm
In the left pane, expand the policy domain tree so it displays named realms; right-click the realm created above and choose Create Rule under Realm.
In the name box, type a descriptive name for the rule, for example Allow Access.
In the Realm and Resource group, choose the realm created above; in the resource box, specify *.
In the Allow/Deny and Enable/Disable group, enable the rule and set it to Allow Access when the rule fires.
In the Action box, click Web Agent Actions and then GET, POST, and PUT.
Click Apply and then OK.
Policy for the Realm
Under the domain created above, right-click Policies and choose Create Policy.
In the Name box, type a descriptive name for the Policy, for example Normal Case.
Click the Users tab and use the controls to add users or groups for whom this policy applies.
Click the Rules tab and use Add/Remove Rules button to add the rule you created above.
Click Apply and then OK.
Configuring Netegrity SiteMinder Web Agent (5.5 SP3 or 6.0) on Linux/Unix
To set up SiteMinder Web Agent:
If you have not done so already, on the host computer for the portal, install Apache HTTPd. For details, see the Installation and Upgrade Guide for AquaLogic Interaction.
On the portal host computer, install:
Either these components:
SiteMinder Web Agent 5.5
SiteMinder Web Agent 5.5 Quarterly Maintenance Release (QMR) 6
SiteMinder Web Agent 5.5 QMR 6 CR007
Or these components:
SiteMinder Web Agent 6.0
SiteMinder Web Agent 6.0 Quarterly Maintenance Release (QMR) 2
SiteMinder Web Agent 6.0 QMR 2 CR005
For details on installing Netegrity SiteMinder components, refer to the Netegrity Customer Care Web site and Netegrity SiteMinder documentation.
For an example of installing the SiteMinder Web Agent, Web Agent QMR, and hotfix, see Knowledge Base article DA_236222, "Netegrity Siteminder 5.5 Web Agent Installation Tips."
Invoke the SiteMinder configuration utility, for example, from the command-line, enter:
./nete-wa-config
When prompted, enter your preferences but be sure to specify the settings you configured in the previous section for the following objects:
Policy Server IP Address
Host Configuration Object name
When prompted, enter the location for the Apache Web server root directory, for example, /opt/httpd/.
Source the Netegrity environment script. From the command-line, enter:
Modify the Apache Web server httpd.conf configuration file to enable the SiteMinder Web Agent. The lines in the following excerpt show an httpd.conf file that enables the SiteMinder Web Agent:
When setup is complete, you are prompted to complete the Web Agent Configuration Wizard. If you choose to run the wizard at a different time, click Start | Programs | SiteMinder | Web Agent Configuration Wizard to open the wizard.
When prompted, specify the settings you configured in the previous section for the following objects:
Policy Server IP Address
Host Configuration Object name
In the <siteminder_webagent_install_location>\IIS\bin\WebAgent.conf file, set the EnableWebAgent parameter to yes.
Configuring an Oblix Authentication Provider
AquaLogic Interaction can integrate Oblix 6.5, 7.0, and 7.0.4 for SSO.
Follow these basic steps to configure the Oblix components for use with the portal:
Configuring Oblix Access Server for a Portal Running on Tomcat
Follow these basic steps to configure Oblix Access Server for use with a portal running on Tomcat:
Install Oblix suite 6.5, 7.0, or 7.0.4. Each Oblix suite includes the following components: COREid, WebPass, Access Server, and Access Manager.
For information on installing Oblix products, refer to Oblix product documentation.
Open NetPoint Access Manager, typically http://oblix_access_server:port/access/oblix.
Create the following objects in the order they are presented.
Table D-8 Procedures for Creating Objects with Oblix NetPoint Policy Server
Object
To create the object:
Policy Domain
In the left pane, click Create Policy Domain.
Type a descriptive name for the policy domain and click Save.
Click Modify.
Enable the policy domain and click Save.
HTTP Resource
Click the Resources tab and then click Add.
In the Resource drop-down list, choose HTTP.
In the URL-prefix drop-down list, choose the backslash(/) and type portal.
Click Save.
Policy
Click the Policies tab and then click Add.
In the Name box, type a descriptive name for the policy, for example allow access.
In the Resource Type drop-down list, choose HTTP.
In the Resource Operations group, click GET and POST.
In the Resource group, select all.
In the URL Pattern field, enter {SSOServlet[;!]*,SSOServlet/.../*,SSOServlet} URLS that contain the string "SSOServlet" and other variations of "SSOServlet" will be forced to authenticate. Without a URL pattern, Oblix issue an authentication prompt for all requests, however, this would prevent portal Guest functionality.
Leave the other fields blank and click Save.
Authorization Rules
The Oblix server parses these rules to send the user name attribute to the portal, enabling the user to log in as a known user with user-defined roles, privileges, views, and so forth.
Click the Authorization Rules tab, and then click Add.
In the name box, type a descriptive name for the rule, for example allow everyone rule.
Enable the rule and click Save.
Click the Allow Access sub-tab and then click Add to display controls for adding users or groups to allow access to this resource.
Add appropriate users and groups. Any user/group that needs access to the portal should be included here. Change the "Role" drop down to "Any one" and click Save.
Note:
The name of the user displayed here does not necessarily match the name you enter during Oblix login.
Default Rules
Click Default Rules tab, then click Add.
On the Authentication Rule sub-tab, enter a Name and Description.
In the Authentication Scheme drop-down menu, select NetPoint None Authentication. This authentication scheme is created automatically by the Oblix installation.
Click Save.
Click the Authorization Expression sub-tab, and click Add.
On the Expression sub-sub-tab, add the Allow Everyone Rule you created previously (or select the rule by the name you originally gave it). You must click Add so that the name appears in the Authorization Expression box.
Click the Actions sub-sub-tab, then click Add.
Under Authorization Success, fill in the last line of fields:
For Type, enter a descriptive name such as headerVar.
For Name, enter UID.
For Return Attribute, enter the value of the UID header sent to portal. Typically, this value is UID if using LDAP or samaccountname if using Active Directory.
Click Save.
Authentication Rule
Click the Policies tab.
Click the name of the policy created above to select it.
Click the Authentication Rule sub-tab and add a method appropriate to your configuration, for example, Basic over LDAP.
Note:
Basic over LDAP is a rule created during Oblix installation. If it is not available, Oblix was not installed properly.
Click Save.
Configuring Oblix Access Server for a Portal Running on IIS
Follow these basic steps to configure Oblix Access Server for use with a portal running on IIS:
Install Oblix suite 6.5, 7.0, or 7.0.4. Each Oblix suite includes the following components: COREid, WebPass, Access Server, and Access Manager.
For information on installing Oblix products, refer to Oblix product documentation.
Open NetPoint Access Manager, typically http://oblix_access_server:port/access/oblix.
Create the following objects in the order they are presented.
Table D-9 Procedures for Creating Objects with Oblix NetPoint Policy Server
Object
To create the object:
Policy Domain
In the left pane, click Create Policy Domain.
Type a descriptive name for the policy domain and click Save.
Click Modify.
Enable the policy domain and click Save.
HTTP Resource
Click the Resources tab and then click Add.
In the Resource drop-down list, choose HTTP.
In the URL-prefix drop-down list, choose the backslash(/) and type the path to the SSO virtual directory in the adjacent text box, for example, portal/sso for typical AquaLogic Interaction deployments.
Note:
Do not enter the full path to the server.
Click Save.
Policy
Click the Policies tab and then click Add.
In the Name box, type a descriptive name for the policy, for example allow access.
In the Resource Type drop-down list, choose HTTP.
In the Resource Operations group, click GET and POST.
In the Resource group, select the resource you created above (in this example, /portal/sso).
Leave the other fields blank and click Save.
Authorization Rules
The Oblix server parses these rules to send the user name attribute to the portal, enabling the user to log in as a known user with user-defined roles, privileges, views, and so forth.
Click the Authorization Rules tab, and then click Add.
In the name box, type a descriptive name for the rule, for example, forward user name.
Enable the rule and click Save.
Click Actions, then click Add.
Under Authorization Success, fill in the last line of fields:
For Type, enter a descriptive name such as headerVar.
For Name, enter UID.
For Return Attribute, enter the name of the attribute used by the authentication source to map to the user name in the user directory. For example, IPlanet LDAP uses the uid attribute by default. Other LDAP repositories, and Active Directory, use cn or samaccountname by default.
Note:
Do not configure an action to return a value.
Click Save.
Click the Allow Access sub-tab and then click Add to display controls for adding users or groups to allow access to this resource.
Add appropriate users and groups. Any user/group that needs access to the portal should be included here.
Click Save.
Authentication Rule
Click the Policies tab.
Click the name of the policy created above to select it.
Click the Authentication Rule sub-tab and add a method appropriate to your configuration, for example, Basic over LDAP.
Note:
Basic over LDAP is a rule created during Oblix installation. If it is not available, Oblix was not installed properly.
Click Save.
Click the Authorization Expression sub-tab, then click Add.
In the Select the Authorization Rule box, choose the rule you created above.
Click Save.
Configuring Oblix WebGate for Apache
Use the version of Oblix WebGate that is compatible with your Oblix suite. For example, if you use Oblix NetPoint 6.5, configure Oblix WebGate 6.5; if you use Oblix COREid 7.0, use Oblix WebGate 7.0.
To set up Oblix WebGate for Apache:
On the host computer for the portal, install the version of Apache required by Oblix WebGate:
For WebGate 6.5, install Apache 1.3.
For WebGate 7.0 or 7.0.4, install Apache 1.3 or Apache 2.0.
Note:
The version of Apache provided by BEA and described in the Installation and Upgrade Guide for AquaLogic Interaction cannot be used with the Oblix WebGate. You must download the required Apache version from the Apache Web site.
On the host computer for the portal, install Oblix WebGate for Apache. For details, refer to Oblix documentation.
On the host computer for the portal, on the Web application server to which the portal application is deployed, modify the Web application server setting to turn off URL rewrites.
For information about modifying the Web application server to turn off URL rewrites, refer to the Web application server documentation or Knowledge Base article DA_239501, "Configuring Web Application Servers to not Rewrite URLs."
Configuring Oblix WebGate to Work with Remote Servers
To enable SSO token delegation to a remote tier, for all remote portlet servers that have WebGate installed, turn off IP validation in the WebGate configuration file:
Open the webgatestatic.lst file in the ../netpoint/webcomponent/access/oblix/apps/webgate/ directory.
At the beginning of the file, set IPValidation to false. The beginning of the file should look something like this:
Save the webgatestatic.lst file, and restart the remote server. You do not need to restart the portal.
Integrating With Other Authentication Providers
AquaLogic Interaction does not provide out of the box integrations with other authentication vendors. However you can integrate with other vendors using the following SSO configuration options:
BasicSSO. We recommend that you implement SSO for unsupported authentication servers using the BasicSSO method whenever possible.
Follow these basic steps for the BasicSSO method:
Install and configure your authentication server as described in your vendor's documentation.
CustomSSO. We recommend that you implement SSO for unsupported authentication servers using the BasicSSO method whenever possible. Use CustomSSO only if BasicSSO is not sufficient to implement the SSO solution needed for your deployment.
Follow these basic steps for the CustomSSO method:
Install and configure your authentication server as described in your vendor's documentation.
For information on developing CustomSSO integration code, see "Developing Custom SSO Objects to Integrate Third-Party SSO Servers with the Portal: DA_217750," which is available from the Knowledge Base of the Support Center.
Configuring an Authentication Source
Follow the steps described in the following table to set up an authentication source for SSO in the portal.
Table D-10 Procedures to Set Up an Authentication Source for SSO in the Portal
Step
Procedure
Configure the authentication Web service (AWS) and select the authentication source to use for SSO.
Note: When you configure the authentication source:
On the Main Settings page, specify a string for Category. Make a note of this string, In most cases, this string is the value you must configure for the DefaultAuthSourcePrefix setting in the portalconfig.xml file.
On the Synchronization page, in the This Authentication Source supports section, select Synchronization.
On the Synchronization page, from the Authentication Partners drop-down list, select SSO Authentication Source.
Set other synchronization preferences as you like, but do not set up authorization for users.
Configuring the Portal for SSO
This section describes how to modify the portal configuration to enable SSO in the following cases:
You must configure the appropriate SSO settings described in this section on each portal server for which you want to deploy SSO.
Modifying the Portal Configuration for BasicSSO
AquaLogic Interaction provides a built-in BasicSSO service that enables integration with any authentication server. To configure the BasicSSO service, you configure portalconfig.xml so the portal can derive authentication information from the remote authentication source or LDAP configuration source you configured in Configuring an Authentication Source.
Configuring portalconfig.xml
Configure settings in the portalconfig.xml file, as described in the following table and subsequent example.
Table D-11 SSO Settings in portalconfig.xml
Setting
Values
SSOVendor
<setting name="SSOVendor">
<value xsi:type="xsd:integer">50</value>
</setting>
DefaultAuthSourcePrefix
This setting can be omitted if the value of the PrefixHeader setting matches the Authentication Source Category string you configured for your remote or LDAP authentication source.
Otherwise, set the value of this setting to the Authentication Source Category string.
For example, if your Authentication Source Category string is HQ, set DefaultAuthSourcePrefix to HQ, as shown in the following example:
Set this value to /. Specify a different setting only if your SSO authentication server requires a different convention.
Example:
<setting name="CookiePath">
<value xsi:type="xsd:string">/</value>
</setting>
CookieDomain
Set this value to the fully qualified domain name for which you want the cookie to be forwarded. For example, if you specify .company.com, the cookie enables access to all domains that end in company.com. If you specify .sub.company.com, the cookie enables access only to domains that end in sub.company.com.
The string must start with a period (.) and include a minimum of two periods.
Next, modify the settings of the <portal:SSOVendor> component in the portalconfig.xml file, as described in the following table and subsequent example.
Table D-12 <portal:SSOVendor> Component
Setting
Values
NameHeader
Set this value to the name of the user name header your authentication server sends to the portal.
The value must be a legal header name.
If you want the user name extracted from the Base64-decoded Authentication Header, specify Authorization.
<NameHeader> requires a valid value if <UseRemoteUser> is not specified or is set to 0.
PrefixHeader
Set this value to the name of the header containing an authentication source prefix if one is required by remote portlets to authenticate login.
If you want the prefix extracted from the Base64-decoded Authentication Header, specify Authorization.
<PrefixHeader> can be set to an empty string but must be present in portalconfig.xml.
PasswordHeader
Set this value to the name of the header containing a password if one is required by remote portlets to authenticate login.
If you want the password extracted from the Base64-decoded Authentication Header, specify Authorization.
<PasswordHeader> can be set to empty string but must be present in portalconfig.xml.
Cookie
Set this value to the name of a header containing a cookie if one is required by remote portlets to authenticate login.
You can configure 0, 1, or many entries using this format:
AquaLogic Interaction provides built-in integration with WIA. Instead of configuring BasicSSO service, follow the procedures in this section to configure SSO integration with WIA.
If you specify the Windows NT domain name as the name for the Authentication Source Category when you set up your authentication source in Configuring an Authentication Source, you need to configure only settings of portalconfig.xml.
Configuring portalconfig.xml
Configure settings in the portalconfig.xml file, as described in the following table and subsequent example.
Table D-13 SSO Settings in portalconfig.xml
Setting
Values
SSOVendor
<setting name="SSOVendor">
<value xsi:type="xsd:integer">5</value>
</setting>
DefaultAuthSourcePrefix
This setting can be omitted if you set the Authentication Source Category value to the appropriate Windows NT domain name when you configure your remote authentication source.
For example, if your Windows domain name is USA and your Authorization Source Category string is USA, this setting can be empty.
If you set the Authentication Source Category to a value other than the Windows NT domain name, specify that string.
For example, if your Authentication Source Category string is HQ, set DefaultAuthSourcePrefix to HQ, as shown in the following example:
The following example configuration enables integration with WIA:
<setting name="SSOVendor">
<value xsi:type="xsd:integer">5</value>
</setting>
<setting name="DefaultAuthSourcePrefix">
<value xsi:type="xsd:string"/>
</setting>
Next (if applicable) modify the settings of the <portal:SSOVendor> component in the portalconfig.xml file, as described in the following table and subsequent example.
Table D-14 <portal:SSOVendor> Settings
Setting
Values
UseDomain
If you set the Authentication Source Category to the Windows NT domain name, you do not need to configure this setting.
If you set the Authentication Source Category to a value other than the Windows NT domain name, set
<setting name="UseDomain">
<value xsi:type="xsd:integer">0</value>
</setting>.
Additionally, configure the <DefaultAuthSourcePrefix> setting in portalconfig.xml, as described in Configuring portalconfig.xml.
The following example configuration summarizes settings that can be configured for integration with WIA:
Modifying the Portal Configuration for Integration with Netegrity Authentication Servers
AquaLogic Interaction provides built-in integration with Netegrity authentication servers. Instead of configuring BasicSSO service, follow the procedures in this section to configure SSO integration with a Netegrity authentication server.
Configure settings in the portalconfig.xml file, as described in the following table and subsequent example.
Table D-15 SSO Settings in portalconfig.xml
Setting
Values
SSOVendor
<setting name="SSOVendor">
<value xsi:type="xsd:integer">2</value>
</setting>
DefaultAuthSourcePrefix
Set this value to a string that matches the value you entered for Authentication Source Category when you configured your authentication source.
For example, if your Authentication Source Category string is HQ, set DefaultAuthSourcePrefix to HQ, as shown in the following example:
Set this value to /. Specify a different setting only if your SSO authentication server requires a different convention.
Example:
<setting name="CookiePath">
<value xsi:type="xsd:string">/</value>
</setting>
CookieDomain
Set this value to the fully qualified domain name for which you want the cookie to be forwarded. For example, if you specify .company.com, the cookie enables access to all domains that end in company.com. If you specify .sub.company.com, the cookie enables access only to domains that end in sub.company.com.
The string must start with a period (.) and include a minimum of two periods.
Example:
<setting name="CookieDomain">
<value xsi:type="xsd:string">.company.com</value>
</setting>>
SSOCookieIsSecure
Set this value to 0 or 1.
0 (the default) specifies the connection to the remote server does not require SSL for the cookie to be forwarded.
1 specifies SSL is required.
Example:
<setting name="SSOCookieIsSecure">
<value xsi:type="xsd:integer">0</value>
</setting>
The following example enables integration with a Netegrity authentication server:
<setting name="SSOVendor">
<value xsi:type="xsd:integer">2</value>
</setting>
<setting name="DefaultAuthSourcePrefix">
<value xsi:type="xsd:string">HQ</value>
</setting>
<setting name="CookiePath">
<value xsi:type="xsd:string">/</value>
</setting>
<setting name="CookieDomain">
<value xsi:type="xsd:string">.company.com</value>
</setting>
<setting name="SSOCookieIsSecure">
<value xsi:type="xsd:integer">0</value>
</setting>
Modifying the Portal Configuration for Integration with Oblix Authentication Servers
AquaLogic Interaction provides built-in integration with Oblix authentication servers. Instead of configuring BasicSSO service, follow the procedures in this section to configure SSO integration with an Oblix authentication server.
Note: By default, the portal expects the Oblix server to forward the user name header named uid. If you configure your Oblix server to forward a user name header with a different name, you must configure your SSO implementation as BasicSSO service. For information about BasicSSO service, see Modifying the Portal Configuration for BasicSSO.
Configure settings in the portalconfig.xml file, as described in the following table and subsequent example.
Table D-16 SSO Settings in portalconfig.xml
Setting
Values
SSOVendor
<setting name="SSOVendor">
<value xsi:type="xsd:integer">3</value>
</setting>
DefaultAuthSourcePrefix
Set this value to a string that matches the value you entered for Authentication Source Category when you configured your authentication source.
For example, if your Authentication Source Category string is HQ, set DefaultAuthSourcePrefix to HQ, as shown in the following example:
Set this value to /. Specify a different setting only if your SSO authentication server requires a different convention.
Example:
<setting name="CookiePath"
<value xsi:type="xsd:string"/>/</value>
</setting>
CookieDomain
Set this value to the fully qualified domain name for which you want the cookie to be forwarded. For example, if you specify .company.com, the cookie enables access to all domains that end in company.com. If you specify .sub.company.com, the cookie enables access only to domains that end in sub.company.com.
The string must start with a period (.) and include a minimum of two periods.
Example:
<setting name="CookieDomain">
<value xsi:type="xsd:string">.company.com</value>
</setting>
SSOCookieIsSecure
Set this value to 0 or 1.
0 (the default) specifies the connection to the remote server does not require SSL for the cookie to be forwarded.
1 specifies SSL is required.
Example:
<setting name="SSOCookieIsSecure">
<value xsi:type="xsd:integer">0</value>
</setting>
The following example enables integration with an Oblix authentication server:
<setting name="SSOVendor">
<value xsi:type="xsd:integer">3</value>
</setting>
<setting name="DefaultAuthSourcePrefix">
<value xsi:type="xsd:string">HQ</value>
</setting>
<setting name="CookiePath">
<value xsi:type="xsd:string">/</value>
</setting>
<setting name="CookieDomain">
<value xsi:type="xsd:string">.company.com</value>
</setting>
<setting name="SSOCookieIsSecure">
<value xsi:type="xsd:integer">0</value>
</setting>
Modifying the Portal Configuration for CustomSSO Service
AquaLogic Interaction supports custom integration with unsupported authentication servers for which you have developed integration code. For information on developing integration code, see "Developing Custom SSO Objects to Integrate Third-Party SSO Servers with the Portal: DA_217750," which is available from the Knowledge Base in the AquaLogic User Interaction Support Center.
Instead of configuring BasicSSO service, follow the procedures in this section to configure integration with your CustomSSO service.
Configure settings in the portalconfig.xml file, as described in the following table and subsequent exampe.l
Table D-17 SSO Settings in portalconfig.xml
Setting
Values
SSOVendor
<setting name="SSOVendor">
<value xsi:type="xsd:integer">100</value> (or any value 100 or above)
</setting>
CustomSSOClass
Set this value to the fully qualified class name for the object you developed to integrate an SSO authentication server with the portal.
Set this value to /. Specify a different setting only if your SSO authentication server requires a different convention.
Example:
<setting name="CookiePath"
<value xsi:type="xsd:string"/>/</value>
</setting>
CookieDomain
Set this value to the fully qualified domain name for which you want the cookie to be forwarded. For example, if you specify .company.com, the cookie enables access to all domains that end in company.com. If you specify .sub.company.com, the cookie enables access only to domains that end in sub.company.com.
The string must start with a period (.) and include a minimum of two periods.