> Administrator Guide > Deploying Single Sign-On

Administrator Guide

     Previous  Next    Open TOC in new window  Open Index in new window  View as PDF - New Window  Get Adobe Reader - New Window
Content starts here

Deploying Single Sign-On

This appendix describes how to deploy Single Sign-On (SSO) capabilities in the portal environment. This appendix includes the following sections:

 

About SSO

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:

  1. SSO Authentication Server. See Configuring an SS0 Authentication Provider for Use with the Portal.
  2. Authentication Source. See Configuring an Authentication Source .
  3. Portal. See Configuring the Portal for SSO .

 

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:

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

  1. Open the IIS Internet Service Manager.
  2. In the left pane, expand the Web server folder and then its portal virtual directory subfolder; right-click the sso folder and choose Properties.
  3. Click the Directory Security tab.
  4. In the Anonymous access and authentication control group, click the Edit button.
  5. In the Authenticated Access group, select the Integrated Windows Authentications box. Leave the remaining boxes unselected.
  6. Click OK to accept changes to Directory Security settings.
  7. Click OK to accept changes to Properties.
    8. 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:
    1. Choose Tools | Security | Local Intranet.
    2. Click Sites.
    3. Click Advanced.
    4. Add the address for the portal Web site.
      5. 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:

  1. Configure SiteMinder Policy Server. For detailed instructions, see Configuring Netegrity SiteMinder Policy Server.
  2. Configure SiteMinder Web Agent. For detailed instruction, see Configuring Netegrity SiteMinder Web Agent (4.6).

Configuring Netegrity SiteMinder Policy Server

To configure SiteMinder Policy Server for your SSO deployment:

  1. Install the server as described in Netegrity documentation.
  2. Open the SiteMinder administrative tool and log in as a user that can create objects.
  3. 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
    1. In the left pane, right-click Agents and choose Create Agent.
    2. In the Name box, type the name of the portal.
    3. In the address box, type the IP address of the portal or use SiteMinder controls to perform DNS lookup.
    4. In the shared secret box, type a string that matches one to be set on the Web Agent host.
    5. Click Apply and then OK.
    User Directory
    1. In the left pane, right-click User Directories and choose Create User Directory.
    2. In the Name box, type a descriptive name for the object, for example Iplanet.
    3. 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.
    4. Click Apply.
    5. To display user groups that have been imported into the Policy Server, click View Contents.
    6. To verify that users have been imported, click Search and query LDAP for specific users.
    7. Click Apply and then OK.
    Policy Domain
    1. In the left pane, right-click Policy Domain and choose Create Policy Domain.
    2. In the name box, type a descriptive name for the domain, for example Portal.
    3. In the add directory box, specify the User Directory created above.
    4. Click Apply and then OK.
    Realm
    1. In the left pane, click the Domains tab.
    2. Right-click the domain created above and choose Create Realm.
    3. In the name box, type a descriptive name for the realm, for example SSO.
    4. In the Resource group, from the Agent drop-down list box, select the agent you created above.
    5. In the Resource Filter box, type /portal/sso, which is the directory the portal uses to authenticate against SSO services.
    6. In the Authentication Scheme box, choose Basic Authentication.
    7. Click Apply and then OK.
    Rule for the Realm
    1. 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.
    2. In the name box, type a descriptive name for the rule, for example Allow Access.
    3. In the Realm and Resource group, choose the realm created above; in the resource box, specify /*.
    4. In the Allow/Deny and Enable/Disable group, enable the rule and set it to Allow Access when the rule fires.
    5. In the Action box, click Web Agent Actions and then GET, POST, and PUT.
    6. Click Apply and then OK.
    Policy for the Realm
    1. Under the domain created above, right-click Policies and choose Create Policy.
    2. In the Name box, type a descriptive name for the Policy, for example Normal Case.
    3. Click the Users tab and use the controls to add users or groups for whom this policy applies.
    4. Click the Rules tab and use Add/Remove Rules button to add the rule you created above.
    5. Click Apply and then OK.

Configuring Netegrity SiteMinder Web Agent (4.6)

To configure SiteMinder Web Agent for your deployment:

  1. Install the Web Agent setup program on the same host as the portal.
  2. 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.

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

  3. To open the IIS Web Agent Management Console, click Start | Programs | SiteMinder | IIS Web Agent Management Console.

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

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

  1. Configure the Netegrity SiteMinder Policy Server.

    2. For detailed instructions, see Configuring Netegrity SiteMinder Policy Server.

  2. Configure Netegrity SiteMinder Web Agent.

Configuring Netegrity SiteMinder Policy Server

To configure SiteMinder Policy Server for your deployment:

  1. Install the server as described in Netegrity documentation.
  2. Open the SiteMinder administrative tool and log in as a user that can create objects.
  3. 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
    1. In the left pane, click Host Conf Object.
    2. In the right pane, right-click the Default Host Configuration Object and choose Duplicate Configuration Object.
    3. In the Name box, type a host name, such as policyserver.
    4. 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.
    5. Click Apply and then OK.
    Agents
    1. In the left pane, right-click Agents and choose Create Agent.
    2. In the Name box, type the name of the portal.
    3. Click Apply and then OK.
    AgentConf Objects
    1. In the left pane, click Agent Conf Objects.
    2. In the right pane, right-click the type of server that approximates the default settings (for example, IISDefaultSettings) and choose Duplicate Configuration Object.
    3. In the Name box, type a descriptive name for the object, typically the host name followed by the configuration object name, for example PortalServerIISDefaultSettings.
    4. 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
    5. Click Apply and then OK.
    User Directory
    1. In the left pane, right-click User Directories and choose Create User Directory.
    2. In the Name box, type a descriptive name for the object, for example Iplanet.
    3. 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.
    1. Click Apply.
    2. To display user groups that have been imported into the Policy Server, click View Contents.
    3. To verify that users have been imported, click Search and query LDAP for specific users.
    4. Click Apply and then OK.
    Policy Domain
    1. In the left pane, right-click Policy Domain and choose Create Policy Domain.
    2. In the name box, type a descriptive name for the domain, for example Portal.
    3. In the add directory box, specify the User Directory created above.
    4. Click Apply and then OK.
    Realm
    1. In the left pane, click the Domains tab.
    2. Right-click the domain created above and choose Create Realm.
    3. In the name box, type a descriptive name for the realm, for example SSO.
    4. In the Resource group, from the Agent drop-down list box, select the agent you created above.
    5. In the Resource Filter box, type /portal/sso, which is the directory the portal uses to authenticate against SSO services.
    6. In the Authentication Scheme box, choose Basic Authentication.
    7. Click Apply and then OK.
    Rule for the Realm
    1. 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.
    2. In the name box, type a descriptive name for the rule, for example Allow Access.
    3. In the Realm and Resource group, choose the realm created above; in the resource box, specify /*.
    4. In the Allow/Deny and Enable/Disable group, enable the rule and set it to Allow Access when the rule fires.
    5. In the Action box, click Web Agent Actions and then GET, POST, and PUT.
    6. Click Apply and then OK.
    Policy for the Realm
    1. Under the domain created above, right-click Policies and choose Create Policy.
    2. In the Name box, type a descriptive name for the Policy, for example Normal Case.
    3. Click the Users tab and use the controls to add users or groups for whom this policy applies.
    4. Click the Rules tab and use Add/Remove Rules button to add the rule you created above.
    5. Click Apply and then OK.

Configuring Netegrity SiteMinder Web Agent (5.5)

To configure SiteMinder Web Agent for your deployment:

  1. Install the Web Agent setup program on the same host as the portal.
  2. 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.

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

  3. To open the IIS Web Agent Management Console, click Start | Programs | SiteMinder | IIS Web Agent Management Console.

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

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

  1. Install and configure the SiteMinder Policy Server. For details, see Configuring Netegrity SiteMinder Policy Server.
  2. Install and configure a corresponding SiteMinder Web Agent. For details, see Configuring Netegrity SiteMinder Web Agent (5.5 SP3 or 6.0) on Linux/Unix.

Configuring Netegrity SiteMinder Policy Server

To configure SiteMinder Policy Server for your deployment:

  1. On a remote host computer, install SiteMinder Policy Server 5.5 and SP3, or 6.0.2.5, as described in Netegrity documentation.
  2. Open the SiteMinder administrative tool and log in as a user that can create objects.
  3. 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
    1. In the left pane, click Host Conf Object.
    2. In the right pane, right-click the Default Host Configuration Object and choose Duplicate Configuration Object.
    3. In the Name box, type a host name, such as policyserver.
    4. 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:
      5. 10.1.140.124,44441,44442,44443
    5. Click Apply and then OK.
    Agents
    1. In the left pane, right-click Agents and choose Create Agent.
    2. In the Name box, type the name of host computer for the portal.
    3. Click Apply and then OK.
    AgentConf Objects
    1. In the left pane, click Agent Conf Objects.
    2. In the right pane, right-click the type of server that approximates the default settings (for example, ApacheDefaultSettings) and choose Duplicate Configuration Object.
    3. In the Name box, type a descriptive name for the object, typically the host name followed by the configuration object name, for example PortalServerApacheDefaultSettings.
    4. 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.
    5. In the Configuration Values group, double-click BadURLChars and modify its value to the following:
      6. //,./,/.,/*,*.,~,\
    6. In the Configuration Values group, configure LogAppend, LogConsole, LogFileName, LogLevel, and Logfile to your preferences. For details, refer to the online help.
    7. Click Apply and then OK.
    User Directory
    1. In the left pane, right-click User Directories and choose Create User Directory.
    2. In the Name box, type a descriptive name for the object, for example Iplanet.
    3. 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.
    4. Click Apply.
    5. To display user groups that have been imported into the Policy Server, click View Contents.
    6. To verify that users have been imported, click Search and query LDAP for specific users.
    7. Click Apply and then OK.
    Policy Domain
    1. In the left pane, right-click Policy Domain and choose Create Policy Domain.
    2. In the name box, type a descriptive name for the domain, for example Portal.
    3. In the add directory box, specify the User Directory created above.
    4. Click Apply and then OK.
    Realm
    1. In the left pane, click the Domains tab.
    2. Right-click the domain created above and choose Create Realm.
    3. In the name box, type a descriptive name for the realm, for example SSO.
    4. In the Resource group, from the Agent drop-down list box, select the agent you created above.
    5. In the Resource Filter box, type /portal/SSOServlet, which is the service the portal uses to authenticate against SSO services.
    6. In the Authentication Scheme box, choose Basic Authentication.
    7. Click Apply and then OK.
    Rule for the Realm
    1. 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.
    2. In the name box, type a descriptive name for the rule, for example Allow Access.
    3. In the Realm and Resource group, choose the realm created above; in the resource box, specify *.
    4. In the Allow/Deny and Enable/Disable group, enable the rule and set it to Allow Access when the rule fires.
    5. In the Action box, click Web Agent Actions and then GET, POST, and PUT.
    6. Click Apply and then OK.
    Policy for the Realm
    1. Under the domain created above, right-click Policies and choose Create Policy.
    2. In the Name box, type a descriptive name for the Policy, for example Normal Case.
    3. Click the Users tab and use the controls to add users or groups for whom this policy applies.
    4. Click the Rules tab and use Add/Remove Rules button to add the rule you created above.
    5. 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:

  1. 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.
  2. On the portal host computer, install:

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

  3. Invoke the SiteMinder configuration utility, for example, from the command-line, enter:
    4. ./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/.

  4. Source the Netegrity environment script. From the command-line, enter:
    5. source /opt/netegrity/siteminder/webagent/nete_wa_env.sh
  5. 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:
    6. ...
    LoadModule sm_module /opt/netegrity/siteminder/webagent/lib/mod2_sm.so
    ...
    # SSO Configuration
    SmInitFile /opt/httpd/conf/WebAgent.conf
    Alias /siteminderagent/pwcgi/ "/opt/netegrity/siteminder/webagent/pw"
    <Directory "/opt/netegrity/siteminder/webagent/pw">
            Options Indexes MultiViews ExecCGI
            AllowOverride None
            Order allow,deny
            Allow from all
    </Directory>
    Alias /siteminderagent/pw/  "/opt/netegrity/siteminder/webagent/pw"
    <Directory "/opt/netegrity/siteminder/webagent/pw">
            Options Indexes MultiViews ExecCGI
            AllowOverride None
            Order allow,deny
            Allow from all
    </Directory>
    Alias /siteminderagent/  "/opt/netegrity/siteminder/webagent/samples/
    <Directory "/opt/netegrity/siteminder/webagent/samples/">
            Options Indexes MultiViews
            AllowOverride None
            Order allow,deny
            Allow from all
    </Directory>
    ##SITEMINDER .exe ##
    AddHandler cgi-script .exe
    ##SITEMINDER .fcc ##
    AddHandler smformsauth-handler .fcc
    ##SITEMINDER .scc ##
    AddHandler smadvancedauth-handler .scc
    ##SITEMINDER .ccc ##
    AddHandler smcookieprovider-handler .ccc
    ...

    The lines that configure SiteMinder Web Agent must be before lines that include a Web application server configuration file, such as bea.conf.

  6. Modify the following settings in /opt/httpd/conf/WebAgent.conf:
    • Ensure: enablewebagent="YES"
    • Add: ServerPath="/opt/httpd/conf/httpd.conf"
  7. Restart the Apache Web server.

Configuring Netegrity SiteMinder Web Agent on (5.5 SP3 or 6.0) Windows

To configure SiteMinder Web Agent for your deployment:

  1. Install the Web Agent setup program on the same host as the portal. See Configuring Netegrity SiteMinder Web Agent (5.5 SP3 or 6.0) on Linux/Unix for the supported Netegrity versions.
  2. 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.
  3. When prompted, specify the settings you configured in the previous section for the following objects:
    • Policy Server IP Address
    • Host Configuration Object name
  4. 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:

  1. Install and configure the Oblix suite 6.5, 7.0, or 7.0.4. For details, see Configuring Oblix Access Server for a Portal Running on Tomcat or Configuring Oblix Access Server for a Portal Running on IIS.
  2. Install and configure a corresponding Oblix Webgate for Apache. For details, see Configuring Oblix WebGate for Apache.

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:

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

    2. For information on installing Oblix products, refer to Oblix product documentation.

  2. Open NetPoint Access Manager, typically http://oblix_access_server:port/access/oblix.
  3. 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
    1. In the left pane, click Create Policy Domain.
    2. Type a descriptive name for the policy domain and click Save.
    3. Click Modify.
    4. Enable the policy domain and click Save.
    HTTP Resource
    1. Click the Resources tab and then click Add.
    2. In the Resource drop-down list, choose HTTP.
    3. In the URL-prefix drop-down list, choose the backslash(/) and type portal.
    4. Click Save.
    Policy
    1. Click the Policies tab and then click Add.
    2. In the Name box, type a descriptive name for the policy, for example allow access.
    3. In the Resource Type drop-down list, choose HTTP.
    4. In the Resource Operations group, click GET and POST.
    5. In the Resource group, select all.
    6. 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.
    7. 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.
    1. Click the Authorization Rules tab, and then click Add.
    2. In the name box, type a descriptive name for the rule, for example allow everyone rule.
    3. Enable the rule and click Save.
    4. Click the Allow Access sub-tab and then click Add to display controls for adding users or groups to allow access to this resource.
    5. 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
    1. Click Default Rules tab, then click Add.
    2. On the Authentication Rule sub-tab, enter a Name and Description.
    3. In the Authentication Scheme drop-down menu, select NetPoint None Authentication. This authentication scheme is created automatically by the Oblix installation.
    4. Click Save.
    5. Click the Authorization Expression sub-tab, and click Add.
    6. 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.
    7. Click the Actions sub-sub-tab, then click Add.
    8. 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.
    9. Click Save.
    Authentication Rule
    1. Click the Policies tab.
    2. Click the name of the policy created above to select it.
    3. 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.

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

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

    2. For information on installing Oblix products, refer to Oblix product documentation.

  2. Open NetPoint Access Manager, typically http://oblix_access_server:port/access/oblix.
  3. 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
    1. In the left pane, click Create Policy Domain.
    2. Type a descriptive name for the policy domain and click Save.
    3. Click Modify.
    4. Enable the policy domain and click Save.
    HTTP Resource
    1. Click the Resources tab and then click Add.
    2. In the Resource drop-down list, choose HTTP.
    3. 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.

    1. Click Save.
    Policy
    1. Click the Policies tab and then click Add.
    2. In the Name box, type a descriptive name for the policy, for example allow access.
    3. In the Resource Type drop-down list, choose HTTP.
    4. In the Resource Operations group, click GET and POST.
    5. In the Resource group, select the resource you created above (in this example, /portal/sso).
    6. 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.
    1. Click the Authorization Rules tab, and then click Add.
    2. In the name box, type a descriptive name for the rule, for example, forward user name.
    3. Enable the rule and click Save.
    4. Click Actions, then click Add.
    5. 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.

    1. Click Save.
    2. Click the Allow Access sub-tab and then click Add to display controls for adding users or groups to allow access to this resource.
    3. Add appropriate users and groups. Any user/group that needs access to the portal should be included here.
    4. Click Save.
    Authentication Rule
    1. Click the Policies tab.
    2. Click the name of the policy created above to select it.
    3. 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.

    1. Click Save.
    2. Click the Authorization Expression sub-tab, then click Add.
    3. In the Select the Authorization Rule box, choose the rule you created above.
    4. 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:

  1. 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.
  2. On the host computer for the portal, install Oblix WebGate for Apache. For details, refer to Oblix documentation.
  3. 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.

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

  1. Open the webgatestatic.lst file in the ../netpoint/webcomponent/access/oblix/apps/webgate/ directory.
  2. At the beginning of the file, set IPValidation to false. The beginning of the file should look something like this:
    3. BEGIN:vCompoundList
    DenyOnNotProtected:false
    CachePragmaHeader:no-cache
    CacheControlHeader:no-cache
    IPValidation:false
  3. 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:

 

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.
For detailed procedures, see Importing Users and Groups from Authentication Sources.
Note: When you configure the remote server and Web service, specify the configuration settings for the SSO partner you set up in Configuring an SS0 Authentication Provider for Use with the Portal.
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:

Note: 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:
<setting name="DefaultAuthSourcePrefix">

<value xsi:type="xsd:string">HQ</value>

</setting>
For details on configuring an authentication source, see Importing Users and Groups from Authentication Sources
CookiePath
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">.plumtree.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 configuration enables BasicSSO: 

<setting name="SSOVendor">
	<value xsi:type="xsd:integer">50</value>
</setting>
<setting name="DefaultAuthSourcePrefix">
	<value xsi:type="xsd:string"/>
</setting>
<setting name="CookiePath">
	<value xsi:type="xsd:string">/</value>
</setting>
<setting name="CookieDomain">
	<value xsi:type="xsd:string">.it.company.com</value>
</setting>
<setting name="SSOCookieIsSecure">
	<value xsi:type="xsd:integer">0</value>
</setting>

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:
<setting name="Cookie">

<value xsi:type="xsd:string">ssocookie1;ssocookie2</value>

</setting>
You configure cookie attributes in the portalconfig.xml file. For information, see Configuring portalconfig.xml.
SecureHeader
Set this value to the name of a header that should not be forwarded to remote portlets.
The value you specify is understood as a prefix: headers that start with this value are not forwarded.
You can configure 0, 1, or many entries.
UseRemoteUser
To extract the name of the authenticated user from a server variable instead of a user name header, set
<setting name="UseRemoteUser">

<value xsi:type="xsd:integer">1</value>

</setting>.
For Java implementations, the server variable is REMOTE_USER.
In .NET, the variable is AUTH_USER.
By default, this value is set to 0 (false).
If <NameHeader> is not specified, the value of <UseRemoteUser> must be set to 1.

The following example configuration summarizes settings for BasicSSO: 

<component name="portal:SSOVendor" type="http://www.plumtree.com/config/component/types/portal/ssovendor">
<setting name="NameHeader">
	<value xsi:type="xsd:string">pt_user</value>
</setting>
<setting name="PrefixHeader">
	<value xsi:type="xsd:string">pt_domain</value>
</setting>
<setting name="PasswordHeader">
	<value xsi:type="xsd:string">pt_password</value>
</setting>
<setting name="Cookie">
	<value xsi:type="xsd:string">PTSSOCookie</value>
</setting>
<setting name="SecureHeader">
	<value xsi:type="xsd:string">authorization</value>
</setting>
<setting name="LogoutURL">
	<value xsi:type="xsd:string"/>
</setting>
<clients>
	<client name="portal"/>
</clients>
</component>

To extract the name of the authenticated user from a server variable instead of a user name header: 

<component name="portal:SSOVendor" type="http://www.plumtree.com/config/component/types/portal/ssovendor">
<setting name="UseRemoteUser">
	<value xsi:type="xsd:integer">1</value>
</setting>
</component>

Configuring Integration with WIA

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: 
<setting name="DefaultAuthSourcePrefix">

<value xsi:type="xsd:string">HQ</value> 

</setting>
Additionally, set:
<setting name="UseDomain">

<value xsi:type="xsd:integer">0</value>

</setting>
For details on configuring an authentication source, see Importing Users and Groups from Authentication Sources.

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: 

<component name="portal:SSOVendor" type="http://www.plumtree.com/config/component/types/portal/ssovendor">
<setting name="UseDomain">
	value xsi:type="xsd:integer">0</value>
</setting>
</component>

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:
<setting name="DefaultAuthSourcePrefix">

<value xsi:type="xsd:string">HQ</value>

</setting>
For details on configuring an authentication source, see Importing Users and Groups from Authentication Sources.
CookiePath
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:
<setting name="DefaultAuthSourcePrefix">

<value xsi:type="xsd:string">HQ</value>

</setting>
For details on configuring an authentication source, see Importing Users and Groups from Authentication Sources.
CookiePath
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.
Example:
<setting name="CustomSSOClass">

<value xsi:type="xsd:string">com.company.portaluiinfrastructure.sso.integrations.SSOTest</value>

</setting>
CustomSSOAssembly
(.NET only)
Set this value to the name of the assembly that contains the .NET class you specified with the CustomSSOClass setting.
Example:
<setting name="CustomSSOAssembly">

<value xsi:type="xsd:string"/>portaluiinfrastructure</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:
<setting name="DefaultAuthSourcePrefix">

<value xsi:type="xsd:string">HQ</value>

</setting>
For details on configuring an authentication source, see Importing Users and Groups from Authentication Sources.
CookiePath
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 uses CustomSSO to enable integration with an unsupported authentication server on a .NET platform: 

<setting name="SSOVendor">
	<value xsi:type="xsd:integer">100</value>
</setting>
<setting name="CustomSSOClass">

<value xsi:type="xsd:string">com.company.portaluiinfrastructure.sso.integrations.SSOTest</value> 

</setting>
<setting name="CustomSSOAssembly">
	<value xsi:type="xsd:string">portaluiinfrastructure</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>

The following example uses CustomSSO to enable integration with an unsupported authentication server on a Java platform: 

<setting name="SSOVendor">
	<value xsi:type="xsd:integer">100</value>
</setting>
<setting name="CustomSSOClass">

<value xsi:type="xsd:string">com.company.portaluiinfrastructure.sso.integrations.SSOTest</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>


  Back to Top       Previous  Next