| Oracle® Fusion Middleware Administrator's Guide for Oracle WebCenter Interaction 10g Release 4 (10.3.3.0.0) Part Number E14107-05 |
|
|
View PDF |
| Oracle® Fusion Middleware Administrator's Guide for Oracle WebCenter Interaction 10g Release 4 (10.3.3.0.0) Part Number E14107-05 |
|
|
View PDF |
This appendix describes how to deploy Single Sign-On (SSO) capabilities in the portal environment.
It includes the following sections:
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 Microsoft Active Directory.
To deploy SSO in your portal, configure the following resources so that they can share user and domain authentication information:
SSO Authentication Server. See Configuring an SS0 Authentication Provider for Use with the Portal.
Remote server. See Creating or Editing a Remote Server.
Authentication web service. See Creating or Editing an Authentication Web Service.
Authentication source. See Creating a Single Sign-On Authentication Source.
Portal. See Configuring the Portal for SSO.
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.
Follow these steps to configure Oracle Single Sign-On for your SSO deployment:
Install the following software as described in the associated documentation:
Oracle Internet Directory or Oracle Virtual Directory (or any other LDAP server supported by Oracle WebCenter Interaction)
Oracle Http Server (OHS)
Apache Tomcat
Oracle WebCenter Interaction
Oracle WebCenter Identity Service for LDAP
Oracle Single Sign-On
Enable proxy support in Oracle HTTP Server:
In a text editor, open httpd.conf. By default, this file is located in OHS_install_dir\ohs\conf.
Add the following lines:
LoadModule proxy_module modules/mod_proxy.so LoadModule proxy_connect_module modules/mod_proxy_connect.so LoadModule proxy_http_module modules/mod_proxy_http.so
At the end of the configuration file, add the following parameter (this will forward all requests to OHS to the application server hosting the portal):
ProxyPass /portal/ http://portal_host_name:port/portal/ ProxyPassReverse /portal/ http://portal_host_name:port/portal/
Save the file.
Restart the Oracle HTTP Server.
Edit the URL mappings in portalconfig.xml, so that Oracle WebCenter Interaction creates links using the FQDN and port number of the Oracle HTTP Server:
In a text editor, open portalconfig.xml. By default, this file is located in File is usually located in the following directory: portal_install_dir\settings\portal.
In the URL Mappings section, edit the default to look like the following (this assumes a security mode 0 for Oracle WebCenter Interaction):
<setting name="URLFromRequest0"> <value xsi:type="xsd:string">*</value> </setting> <setting name="ApplicationURL0"> <value xsi:type="xsd:string">http://ohs_host_fqdn:ohs_port/portal/server.pt</value> </setting> <setting name="SecureApplicationURL0"> <value xsi:type="xsd:string">https://ohs_host_fqdn:ohs_port/portal/server.pt</value> </setting> <clients> <client name="portal"/> </clients>
Save the file.
Restart the Tomcat instance hosting Oracle WebCenter Interaction for the changes to take effect.
Note:
You might also need to update the AdminSiteBaseURL value in the configuration.xml file (located in portal_install_dir/settings) to point to the FQDN of the OHS host.
Create an authentication source, connecting to the same LDAP server used by the Oracle Single Sign-On:
Perform the steps described in Creating a Single Sign-On Authentication Source, selecting the LDAP authentication Web service, specifying connection information for the LDAP server used by Oracle Single Sign-On.
Run the authentication source job to synchronize the users and groups.
Confirm that one of the synchronized users can log in to the portal.
Configure settings in portalconfig.xml to enable SSO, specifying information about headers and cookies being generated by the Oracle Single Sign-On policies you configured:
In a text editor, open portalconfig.xml. By default, this file is located in File is usually located in the following directory: portal_install_dir\settings\portal.
Set the DefaultAuthSourcePrefix value to the Authentication Source Category you specified when you created the authentication source.
Configure the following settings:
<setting name="SSOVendor"> <value xsi:type="xsd:integer">6</value> </setting> <setting name="AllowDefaultLoginPageAuthSource"> <value xsi:type="xsd:integer">2</value> </setting> <setting name="DefaultAuthSourcePrefix"> <value xsi:type="xsd:string">Authentication_Source_Category</value> </setting> <setting name="CookiePath"> <value xsi:type="xsd:string">/</value> </setting> <setting name="CookieDomain"> <value xsi:type="xsd:string">.my.company.com</value> </setting> <setting name="SSOCookieIsSecure"> <value xsi:type="xsd:integer">0</value> </setting>
Uncomment the configuration block located underneath the portal:SSOVendor component, and configure to look like the following:
<component name="portal:SSOVendor" type="http://www.plumtree.com/config/component/types/portal/ssovendor">
<setting name="NameHeader">
<value xsi:type="xsd:string">uid</value>
</setting>
<setting name="PrefixHeader">
<value xsi:type="xsd:string"/>
</setting>
<setting name="PasswordHeader">
<value xsi:type="xsd:string"/>
</setting>
<setting name="Cookie">
<value xsi:type="xsd:string"/>
</setting>
<setting name="SecureHeader">
<value xsi:type="xsd:string"/>
</setting>
<setting name="LogoutURL">
<value xsi:type="xsd:string">Partner_Single_Sign-Off_URL?p_done_url=Landing_URL</value>
</setting>
<clients>
<client name="portal"/>
</clients>
</component>
Note:
The NameHeader value will be used in the Oracle Single Sign-On policy configuration, and should correspond to the User Name Attribute specified during the creation of the authentication source. You can instead have Oracle WebCenter Interaction try to get the name of the authenticated user from a server variable by changing the UseRemoteUser value to 1. For example:
<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>
Replace Partner_Single_Sign-Off_URL with the sign-off URL shown in the Partner Application Setting of Oracle WebCenter Interaction in Oracle Single Sign-On.
Replace Landing_URL with the URL of the page on which you want the user to land after Oracle Single Sign-On sign off. This value is usually the same as Apache reverse proxy Oracle Single Sign-On login URL for Oracle WebCenter Interaction.
Save the file.
Restart the Tomcat instance hosting Oracle WebCenter Interaction for the changes to take effect.
Create a new partner application in Oracle Single Sign-On for Oracle WebCenter Interaction:
Navigate to the Oracle Single Sign-On administrative user interface.
Click Login and log in as orcladmin with the password you created when you installed Oracle Single Sign-On.
Click Single Sign-On Server Administration.
Click Administer Partner Applications.
Click Add Partner Application.
Type a name for the partner application.
In the Home URL box, type http://portal_url.
In the Success URL box, type http://portal_url/osso_login_success.
In the Logout URL box, type http://portal_url/osso_logout_success.
Leave end date blank.
Click OK.
Create an osso.conf file:
Click the pencil icon next to the partner application you created.
Create a text file with the following text, replacing the variables with the settings from the Oracle Single Sign-On user interface:
sso_server_version=v1.4 cipher_key=Encryption_Key site_id=Site_ID site_token=Site_Token login_url=Single_Sign-On_URL logout_url=Single_Sign-Off_URL cancel_url=http://portal_url
Note:
The cancel_url should point to where you want the user to end up if they click Cancel instead of logging in.
Save this file to: \ohs\conf\osso\osso.conf.txt.
Open a command prompt and cd to the folder.
Run the following command: ..\..\bin\apobfuscate.exe osso.conf.txt osso.conf
Running the command generates an obfuscated copy of the config file used by mod_osso. In a production deployment, delete osso.conf.txt to avoid storing the cipher key in clear text.
Configure OHS:
Open \ohs\conf\httpd.conf in a text editor.
Confirm that the following line exists and is not commented out:
Include the mod_osso configuration file
include "OHS_install_dir\ohs\conf\mod_osso.conf"
Comment out the default auth modules:
#LoadModule auth_module modules/mod_auth.so #LoadModule auth_anon_module modules/mod_auth_anon.so #LoadModule auth_dbm_module modules/mod_auth_dbm.so
Save the file.
Open mod_osso.conf in a text editor.
Add the following lines:
LoadModule osso_module modules/mod_osso.so
<IfModule mod_osso.c>
OssoConfigFile conf/osso/osso.ensemble.conf
OssoIpCheck off
OssoIdleTimeout off
<Location /authenticateWithApplicationServer>
require valid-user
AuthType Basic
</Location>
</IfModule>
Save the file.
Restart OHS.
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. From the Tools menu, choose Security, then 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.
In the portal environment where SSO via WIA is deployed, the portal does not pass user passwords as Basic Authentication Headers to remote servers.
Follow these basic steps to configure Netegrity SiteMinder Policy Server for use with the portal:
Configure the Netegrity SiteMinder Policy Server. See Configuring Netegrity SiteMinder Policy Server.
Configure Netegrity SiteMinder Web Agent. See the section that applies to the version of SiteMinder you run:
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.
(For 5.5, 5.5 SP3, or 6.0.2.5) Create a host conf object:
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.
Create an agent:
In the left pane, right-click Agents and choose Create Agent.
In the Name box, type the name of the portal.
(For 4.6 only) In the address box, type the IP address of the portal or use SiteMinder controls to perform DNS lookup.
(For 4.6 only) In the shared secret box, type a string that matches one to be set on the Web Agent host.
Click Apply and then OK.
(For 5.5, 5.5 SP3, or 6.0.2.5) Create an Agent Conf Object:
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 or 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 PortalServerIISDefaultSettings or PortalServerApacheDefaultSettings.
In the Configuration Values group, double-click DefaultAgentName; uncomment the parameter (remove the leading #) and specify as its value the name of the agent you created.
(For 5.5 SP3 or 6.0.2.5) In the Configuration Values group, double-click BadURLChars and modify its value to the following: //,./,/.,/*,*.,~,\
(For 5.5 SP3 or 6.0.2.5) 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.
Create a 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.
Create a 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 you created.
Click Apply and then OK.
Create a 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.
In the Resource Filter box, type /portal/sso for 4.6 or 5.5 or type /portal/SSOServlet for 5.5 SP3 or 6.0.2.5, 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.
Create a rule for the realm:
In the left pane, expand the policy domain tree so it displays named realms; right-click the realm you created 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
Create a 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 the Add/Remove Rules button to add the rule you created above.
Click Apply and then OK.
To configure SiteMinder Web Agent 4.6 or 5.5 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, from the Start menu, choose Programs, then SiteMinder, then Web Agent Configuration Wizard to open the wizard.
When the wizard prompts for components to configure, choose IIS.
Click Configure.
In the Policy Server box, type the name of the Policy Server you set up.
In the Agent name box, type the name of the agent you created.
In the Cookie domain box, 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.
In the IIS Proxy User Name and Password box, type a user name and password to run the SiteMinder ISAPI filter on IIS. This user must have administrator rights on the IIS host.
In the Shared Secret box, type a string that exactly matches the name of the Agent object you created on the Policy Server.
Open the IIS Web Management Console. From the Start menu, choose Programs, then SiteMinder, then IIS, then WebManagement Console.
Click the Settings tab, and select Enable Web Agent and Enable Policies.
Click the Single Sign On tab. 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.
Restart IIS to apply the modified settings.
To configure SiteMinder Web Agent 5.5 SP3 or 6.0 on Windows 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, from the Start menu, choose Programs, then SiteMinder, then 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 and Host Configuration Object name.
In the siteminder_webagent_install_location\IIS\bin\WebAgent.conf file, set the EnableWebAgent parameter to yes.
To configure SiteMinder Web Agent 5.5 SP3 or 6.0 on UNIX or Linux for your deployment:
If you have not done so already, on the host computer for the portal, install Apache HTTPd.
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 and 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: source /opt/netegrity/siteminder/webagent/nete_wa_env.sh.
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:
...
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 oracle.conf.
Modify the following settings in /opt/httpd/conf/WebAgent.conf:
Ensure: enablewebagent=”YES”
Add: ServerPath=”/opt/httpd/conf/httpd.conf”
Restart the Apache Web server.
Follow these basic steps to configure the Oblix components for use with the portal:
Install and configure the Oblix suite 6.5, 7.0, or 7.0.4.
Configure Oblix Access Server for the portal. See the section that applies to the Web server you use:
Install and configure a corresponding Oblix Webgate for Apache. See Configuring Oblix WebGate for Apache.
If necessary, configure Oblix WebGate to work with remote servers. See Configuring Oblix WebGate to Work with Remote Servers.
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 a 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.
Create an 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.
Create a 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.
Create an authorization rule for everyone. The Oblix server parses the rule 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.
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 to Anyone and click Save.
Note:
The name of the user displayed here does not necessarily match the name you enter during Oblix login.
Create a default rule:
Click Default Rules tab, then click Add.
Click the Authentication Rule sub-tab, and 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.
Click the Expression sub-sub-tab, and add the Allow Everyone Rule you created previously (or select the rule by the name you 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.
Create an authorization rule for the policy you created:
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.
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 a 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.
Create an 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 Oracle WebCenter Interaction deployments.
Note:
Do not enter the full path to the server.
Click Save.
Create a 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 (in this example, /portal/sso).
Leave the other fields blank and click Save.
Create an authorization rule. The Oblix server parses the rule 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.
Create an authorization rule for the policy you created:
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.
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.
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.”
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 ../netpoint/webcomponent/access/oblix/apps/webgate/webgatestatic.lst file.
At the beginning of the file, set IPValidation to false. The beginning of the file should look something like this:
BEGIN:vCompoundList DenyOnNotProtected:false CachePragmaHeader:no-cache CacheControlHeader:no-cacheIPValidation:false
Save the webgatestatic.lst file, and restart the remote server. You do not need to restart the portal.
Oracle WebCenter 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.
Create a remote server. See Creating or Editing a Remote Server.
Create an authentication Web service. See Creating or Editing an Authentication Web Service.
Create an authentication source. See Creating a Single Sign-On Authentication Source.
Follow special configuration requirements for BasicSSO described in Modifying the Portal Configuration for BasicSSO.
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.
Create a remote server. See Creating or Editing a Remote Server.
Create an authentication Web service. See Creating or Editing an Authentication Web Service.
Create an authentication source. See Creating a Single Sign-On Authentication Source.
Follow special configuration requirements for CustomSSO described in Modifying the Portal Configuration for CustomSSO Service.
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.
This section describes how to modify the portal configuration to enable SSO in the following cases:
Modifying the Portal Configuration for Integration with Netegrity Authentication Servers
Modifying the Portal Configuration for Integration with Oblix Authentication Servers
Note:
You must configure the appropriate SSO settings described in this section on each portal server for which you want to deploy SSO.
Oracle WebCenter 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 authentication source you created, as described in Creating a Single Sign-On Authentication Source.
Configure settings in the portalconfig.xml file, as described in the following table and subsequent example.
Table E-1 SSO Settings in portalconfig.xml
| Setting | Values |
|---|---|
|
SSOVendor |
|
|
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
|
|
CookiePath |
Set this value to Example:
|
|
CookieDomain |
Set this value to the fully qualified domain name for which you want the cookie to be forwarded. For example, if you specify The string must start with a period (.) and include a minimum of two periods. Example:
|
|
SSOCookieIsSecure |
Set this value to 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:
|
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 E-2 <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
|
|
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
|
|
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 < |
|
Cookie |
Set this value to the name of a header containing a cookie if one is required by remote portlets to authenticate login. To specify multiple values, separate values with semi-colons (;). For example:
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. To specify multiple values, separate values with semi-colons (;). |
|
UseRemoteUser |
To extract the name of the authenticated user from a server variable instead of a user name header, set the value to 1. For example:
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 |
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>
Oracle WebCenter 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 (as described in Creating a Single Sign-On Authentication Source), you need only configure settings in portalconfig.xml.
Configure settings in the portalconfig.xml file, as described in the following table and subsequent example.
Table E-3 SSO settings in portalconfig.xml for configuring integration with WIA
| Setting | Value |
|---|---|
|
SSOVendor |
|
|
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:
Additionally, set:
|
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 E-4 <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 the value to
Additionally, configure the |
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>
Oracle WebCenter 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 E-5 SSO Settings in portalconfig.xml
| Setting | Values |
|---|---|
|
SSOVendor |
|
|
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:
|
|
CookiePath |
Set this value to Example:
|
|
CookieDomain |
Set this value to the fully qualified domain name for which you want the cookie to be forwarded. For example, if you specify The string must start with a period (.) and include a minimum of two periods. Example:
|
|
SSOCookieIsSecure |
Set this value to 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:
|
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>
Oracle WebCenter 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 E-6 SSO Settings in portalconfig.xml
| Setting | Values |
|---|---|
|
SSOVendor |
|
|
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:
|
|
CookiePath |
Set this value to Example:
|
|
CookieDomain |
Set this value to the fully qualified domain name for which you want the cookie to be forwarded. For example, if you specify The string must start with a period (.) and include a minimum of two periods. Example:
|
|
SSOCookieIsSecure |
Set this value to 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:
|
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>
Oracle WebCenter 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.”
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 example.
Table E-7 SSO Settings in portalconfig.xml
| Setting | Values |
|---|---|
|
SSOVendor |
Set this value to 100 or above.
|
|
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:
|
|
CustomSSOAssembly |
(.NET only) Set this value to the name of the assembly that contains the .NET class you specified with the CustomSSOClass setting. Example:
|
|
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:
|
|
CookiePath |
Set this value to Example:
|
|
CookieDomain |
Set this value to the fully qualified domain name for which you want the cookie to be forwarded. For example, if you specify The string must start with a period (.) and include a minimum of two periods. Example:
|
|
SSOCookieIsSecure |
Set this value to 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:
|
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>
This section contains links to common SSO questions and the answers.
Why Can't I Access the Portal Through SSOLogin.aspx or the SSOServlet?
Why Isn't the SSO Cookie Forwarded to Remote Servers or Portlets?
How Do I Configure Reverse Proxy with My SSO Deployment Using Apache HTTP Server?
How Do I Configure Reverse Proxy with My SSO Deployment Using a Java Application Server?
Examine the following settings or events to diagnose the cause of this problem:
In portalconfig.xml, the user name prefix must match the value for the Authentication Source Category set in the authentication source portal object. Ensure these strings are identical.
Use Oracle WebCenter Logging Spy to see if the SSO authentication server is passing the user name to the portal. If you see an error message in red type that indicates SSO integration returned a null user name. Exiting SSOLoginPage, then there is something wrong with the configuration. Ensure that you have configured the authentication server correctly to forward the user name after authentication to the portal.
Examine the following settings or events to diagnose the cause of this problem:
In portalconfig.xml, ensure the value of the <CookieDomain> element begins with a period.
In portalconfig.xml, ensure the value of the <CookiePath> element is the standard value, <CookiePath value="/"/>, or otherwise is a reasonable value.
In the authentication server, ensure the value of the cookie object enables the cookie to be forwarded.
Examine the configurations for the authentication server and the portal to ensure fully qualified domain names are specified for all servers.
If you are unable to diagnose the problem with these methods, use a TCP tracing tool to see the value returned by the SSO provider. The path and domain must match the values for <CookiePath> and <CookieDomain> in portalconfig.xml.
Guests can access the portal while SSO is enabled. Guest access is controlled by the AllowGuestAccess setting in the Authentication section of portalconfig.xml. When guest access is disabled, users can browse the portal without logging in. When users click Log In in the portal banner or when they attempt to visit a page for which the guest user does not have access, the portal redirects them to the SSO login page, and they are prompted by the SSO product for their login credentials.
If users already have an SSO cookie from another application, they still browse the portal as the guest user until they click Log In. At which point, they are logged in without entering their user name and password.
Guest access can be enabled or disabled independently from SSO. If guest access and SSO are both disabled, users have to log in before accessing any part of the portal.
If you must log in as Administrator or other portal user from within an SSO session, you can perform the following steps:
Click Log Off in the portal banner.
This logs you out of the portal and takes you to the portal login page, as if SSO were disabled.
From this page you can log in as a non-SSO user or you can browse the portal as guest.
When you want to log back in as an SSO user, click Log In in the portal banner.
You are automatically logged in to the portal in an SSO session.
The first time you access the portal after you deploy SSO, you must access the portal from the main portal URL: http://servername/portal/server.pt.
If you try to access the portal through /portal/sso/SSOLogin.aspx (.NET) or /portal/SSOServlet (Java), your request fails and the following error appears in Oracle WebCenter Logging Spy trace logs: The SSO Login Page was unable to retrieve the request URL from the session. Will use a relative redirect to return to the main page.
The portal and other Oracle WebCenter products, such as Oracle WebCenter Collaboration, periodically send HTTP requests to the Image Service to check the version of the JavaScript components stored on the Image Service. These requests are not associated with a particular user's session and do not send an SSO cookie or other credentials. If the Image Service is protected by your SSO solution, the request from the portal is blocked from checking the JavaScript versions. As a result, the portal cannot load the proper JavaScript files and end users encounter JavaScript errors and possibly other errant behavior. To resolve this problem, do not configure your SSO authentication server to protect the Image Service, but only the portal. You do not must protect the Image Service as it 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.
The portal provides built-in trace statements that are useful for debugging SSO integration. For example, when a user attempts to log in using SSO, the contents of all headers are traced. To enable this tracing, turn on all tracing for the Portal UI - Infrastructure component.
Install Oblix NetPoint Access Server, including NetPoint Access Manager, NetPoint COREid, and Oblix Apache WebGate. WebGate must be installed on the same server as the Apache HTTP server. For detailed instructions, refer to Oblix documentation.
Use Oblix Access Manager to create the portal protection policy. For detailed instructions, refer to Oblix documentation.
Configure Oblix NetPoint Access Server. For detailed instructions, see Configuring an Oblix Authentication Provider.
Configure the Apache HTTP server for reverse proxy. For detailed instructions, see the procedures that follow these steps.
Configure the portal for SSO. For detailed instructions, see Configuring the Portal for SSO.
Configure the portal application server for reverse proxy. For detailed instructions, see the procedures following these steps.
Restart services to apply configuration modifications.
Install the version of the Apache HTTP server recommended by the Oblix Installation Guide.
For Netpoint 6.5, Oblix recommends the latest version of the Apache, v1.3 line. The configuration described in this example has been tested with version v1.3.29.
Turn on the proxy module inside of the Apache configuration.
To do so, edit apache_install_dir/conf/httpd.conf to uncomment the lines titled LoadModule proxy_module modules/mod_proxy.so and AddModule mod_proxy.c. (To uncomment a line, remove the pound symbol (#) at the beginning of the line).
Configure Apache to act as a reverse proxy for your portal.
To do so, add lines similar to the following example at the end of httpd.conf:
ProxyRequests Off ProxyPass /portal http://your_portal_server.domain.com:7001/portal ProxyPassReverse /portal http://your_portal_server.domain.com:7001/portal
This example configuration redirects requests from the Apache Web server (http://proxy_server.domain.com:80/portal/xyz) to the portal application server (http://your_portal_server.domain.com:7001/portal/xyz). You must specify the fully qualified domain name here and for all other times you type in the server names. For more information on Apache reverse proxy, see http://httpd.apache.org/docs/mod/mod_proxy.html.
Start or restart the Apache HTTP server.
Open install_dir/ptportal/10.3.3/settings/config/portalconfig.xml for editing.
Configure the <URLMapping> element so that it is similar to the following example:
<URLFromRequest0 value="*"/> <ApplicationURL0 value="http://proxy_server.domain.com/portal/server.pt"/> <SecureApplicationURL0 value="*"/>
Replace proxy_server.domain.com with the fully qualified domain name for the Apache HTTP server.
Configure the <SSOVirtualDirectoryPath> element so that it is similar to the following example:
<SSOVirtualDirectoryPath value="http://proxy_server.domain.com/portal/"/>
Replace proxy_server.domain.com with the fully qualified domain name for the Apache HTTP server.
Restart the application server.
|
 Copyright © 2011, 2013, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|