How SSO Works

Embed Size (px)

DESCRIPTION

How SSO Works

Citation preview

Objective: This document will guide you through the steps to configure SOX Express to use SiteMinder as its authentication ser

Configuring OpenPages

SiteMinder Authentication Service

Objective

This document will provide an overview of the Single Sign On functionality using Siteminder and Get Access and how its used in the OpenPages 5.5 application. For detailed steps on how to implement the Single Sign on Solution, please refer to the document SSO_Doc_op55. The scope of this document is to provide the framework on how Single Sign On works and the ways to troubleshoot, in the event of a new implementation.Part 1: What is Siteminder and How Siteminder WorksThe SiteMinder product was developed by Netegrity to address the problem of managing logins to heterogeneous web-based services. For example, users that access a web service hosted on a Microsoft IIS Web server are authenticated by a Windows NT domain controller, which maintains user account information. If the same users want to access web services on an iPlanet Web server running on a Sun server, they have to be authenticated by another mechanism, usually through LDAP. Since there is no way to pass authentication verification between these two systems, users must log in twice.

SiteMinder solves this multiple login problem by providing a central point for all authentication. Instead of being authenticated by each web service, users are authenticated by SiteMinder instead. After the user is authenticated, a special encrypted cookie is created and used for subsequent logins to different web-based services and applications. Even though users are automatically authenticated, you can curtail their access rights to specific resources by establishing access control policies through SiteMinder's security policy management features.

How SiteMinder/Get Access WorkThe SiteMinder product provides more than single sign-on capability. A full description of all these features can be found at the Netegrity Web site: http://www.netegrity.com. Included here is a brief description of how SiteMinder works, to give you an idea of how it would be deployed in a corporate environment.

The SiteMinder software consists of two main components:

SiteMinder Policy Server

SiteMinder Web Agent

The Policy Server provides authentication, among other services, to web-based applications. The Web Agent is integrated with a standard web server and is the component that allows the web server to be managed by SiteMinder. It intercepts all requests for resources (URLs), then decides whether the specified resource is under SiteMinder's control. If it is, the Policy Server is contacted.

The Policy Server acts as a front end to whatever authentication method is being deployed within your organization. These include:

Basic authentication (user-name/password)

Basic authentication over SSL

Authentication schemes

ACE/Server (Security Dynamics)

CryptoCard

RADIUS Proxy

Forms-based authentication

X.509 certificates

Custom or third-party schemes

Use some of these schemes in combination to provide stronger authentication. You can establish priority levels for finer control over resources. For example, if users are authenticated by a method that has a lower priority than the resource they are accessing, then an attempt to authenticate them at a higher level is made. Conversely, if users are already authenticated at a high-priority level, then no further authentication is required.

FIGURE 11-1 illustrates how single sign-on is achieved with SiteMinder.

Figure 11-1. SiteMinder Single Sign-on

In FIGURE 11-1, the user accesses an URL that is located on Web server A, which has the SiteMinder Web Agent running on it. The agent checks to see if the requested URL is under SiteMinder control, and if it is, the agent contacts the Policy Server, which authenticates the user according to established policy rules. Once the user is authenticated, an encrypted cookie or user credential is created and passed to the other web servers under SiteMinder control.

When the same user tries to access a URL on Web server B, the Web Agent can then grant access according to the user credential it was passed, eliminating the need for a second user login.

Limitation of SiteMinder

SiteMinder was designed to work in a web server environment, where authentication is triggered upon a URL request. When a user logs into a computer, authentication is handled by the underlying operating system, instead of being initiated by a web server. Since there is no way to pass the authentication information to SiteMinder from the operating system, the user would have to log in again to gain access to web service applications.

Even though SiteMinder is a valuable tool for creating an SSO environment between disparate web applications, the user is still required to log into the platform from which the web applications will be launched. SiteMinder also requires that an agent be installed on each web server that will participate in the SSO environment. The agents are written with web server extension APIs such as ISAPI for Microsoft IIS and NSAPI for iPlanet Web server, and so must be provided by Netegrity.

Part 2: Configuring the SiteMinder Policy Server

1) On the SSO policy server machine, open and log into the SiteMinder Administration Console.

2) Under the System tab on the left side of console click on the Host Conf Objects menu.3) In Host Conf Object List right click on DefaultHostSettings and select Duplicate Configuration Object.

4) Specify the Name of the host configuration object as host-

5) In the list of configuration values edit the PolicyServer property so that the Parameter Name is PolicyServer (without the starting # symbol). Also edit the Parameter Value by replacing with the host name or IP Address of the policy server.

6) Click Apply and then OK to finish creating the host configuration object.

7) Under the System tab on the left side of console right click on the Agents menu and select Create Agent.

8) For Agent Name specify agent-< name of Openpages Application sever>

9) Check the Support 4.x check box.

10) For IP Address or Host Name specify the IP address of the Openpages Application sever machine.

11) For Secret and Confirm Secret enter the value openpages.

12) Click Apply and then OK to finish creating the agent.

13) Under the System tab on the left side of console click on the Agent Conf Objects menu.

14) In Agent Conf Object List right click on the IISDefaultSettings and select Duplicate Configuration Object.

15) Specify the Name of the agent configuration object as agent-16) Edit all configuration parameters that are commented out (begin with # symbol) such that they are no longer commented out. (Just remove the beginning # symbol)17) Edit the DefaultAgentName parameter such the value equals agent-< name of Openpages Application sever>

18) Edit the LogAppend parameter such that value equals yes.19) Edit the LogConsole parameter such that value equals yes.

20) Edit the LogFileName parameter such that value equals sox_sm.log.

21) Edit the LogLevel parameter such that value equals 2.

22) Edit the Logfile parameter such that value equals yes.

23) Edit the ServerErrorFile parameter such that value equals yes.

24) Click Apply and then OK to finish creating the agent configuration object.

25) Select the Domains tab on the left side of the administration console.26) Under the Domains tab right click on the Domains menu and select Create Domain.27) For Domain name enter

28) Add the appropriate user directories to this domain. The user directories specified should contain all of the users that should be able to access Openpages Application sever.

29) Click Apply and then OK to finish creating the domain.

30) Expand the tree under the newly created domain to see all of its sub-components.31) Right click on the Realms sub-component and select Create Realm.

32) For Realm Name enter -sox

33) For Agent click the Lookup button, select the Agent you created earlier (Step 8) and then click OK.

34) For Resource Filter enter /sox/35) Click Apply and then OK to finish creating the realm.

36) Right click on the newly created realm and select Create Rule Under Realm.37) For Rule Name enter soxrule.

38) For Resource enter *.

39) Under the Action section make sure both Get and Post are selected.

40) Click Apply and then OK to finish creating the rule.

41) Right click on the Policies sub-component of the domain and select Create Policy.

42) For Policy Name enter soxpolicy.

43) Under the Users tab add all users that should have access to Openpages Application sever from the user directory.44) Under the Rules tab add the soxrule you created in step 37.

45) Click Apply and then OK to finish creating the policy.

46) Exit the SiteMinder Administration console.

47) Restart all SiteMinder services.

Part 3: Installing the SiteMinder IIS Web Agent

Make sure to read the SiteMinder Web Agent Installation Guide prior to installing to ensure that all required pre-requisites have been met.On the OpenPages application server, do the following:1) Start the SiteMinder Web Agent installer.

2) In the Welcome dialog box, read the information then click Next.3) Read the Software License Agreement and click Yes to accept it.4) Read the Release Notes, then click Next. 5) In the Choose Destination Location dialog box, accept the default installation location or use the Browse button to select a different location. Click Next.6) In the Start Copying Files dialog box, check the configuration settings then click Next.7) In the Setup Complete dialog box, make sure the Launch the Web Agent Configuration Wizard now check box is selected, then click Finish. If you have not registered your system as a trusted host, the Wizard begins the registration process. Proceed to Step 9. If your system is already registered as a trusted host, the Wizard prompts you to configure the Web Agent. Proceed to Step 14.8) Deselect the Enable PKCS11 Cryptographic Hardware box and click Next.10) Complete the following fields to identify an administrator with the rights to

register a trusted host, then click Next:

a) Administrator ( enter the name of the administrator allowed to register the host with the Policy Server. This administrator should already be defined at the Policy Server and have the permission Register Trusted Hosts set. The default administrator is SiteMinder.

b) Password ( Enter the administrators password.

c) Confirm Password ( Re-enter the password.

9) In the Trusted Host Name field, enter the name of the system serving as the trusted host (local computer name), for example, myserver, then click Next.

10) In the Policy Server IP Address field, enter the IP address of the Policy Server where you are registering the host, then click Next.11) In the Host Configuration Object field, enter the name of the Host Configuration Object specified in the Policy Server (Part 2, Step 4), then click Next.

12) Accept the default location of the host configuration file, SmHost.conf or click Browse to select a different location. Click Next. The host is now registered and a host configuration file, SmHost.conf, is created in /config.

13) In the Select Web Server(s) dialog only check the box next to Microsoft IIS and click Next.14) In the Web Agent Configuration for Microsoft IIS dialog click the Configure button.15) In the Agent Configuration Object field, enter the name of the Agent Configuration Object for this Web server instance (Part 2, Step 15) and click Next.

16) In the Servlet Engine for Registration on Microsoft IIS dialog select No Registration Services and click Next.

17) In the Web Agent Configuration dialog box, check the location of the host configuration file and the name of the Agent Configuration Object. If the settings are correct, click Next.18) Confirm that the configuration settings are correct, then click Next.

19) Click Finish to exit the wizard.

20) Open the WebAgent.conf file located in \Bin\IIS. For example: C:\Program Files\Netegrity\SiteMinder Web Agent\Bin\IIS21) Set the EnableWebAgent parameter equal to YES.22) Save the file and restart the Web server (all IIS services).Step 4: Enabling SiteMinder for OpenPagesTo modify the single sign-on settings, you will need to be logged into OpenPages as an administrator that can edit the OpenPages Settings menu item.

To enable the integration of a single sign-on system with OpenPages:1) Click on the Settings link under the Configuration heading in the Action Menu.

2) Navigate to the following location: OpenPages|Applications|Common|Configuration.

3) Click on Show Hidden Settings and change the value to true. 4) Click Save to save your changes.

5) Navigate to the following location: OpenPages|Platform|Security|Single Sign On|Implementations|Header-based.

6) Click on the Session Attribute link.

7) Modify the value (if necessary) to match the session attribute for your single sign-on system. a. Using SiteMinder 6.0 as an example, the value of the Session Attribute parameter would be SMSERVERSESSIONID.8) Save your changes (if necessary) by clicking the Save button, or cancel the edit.

9) Click on the Username Attribute link.

10) Modify the value (if necessary) to match the user name attribute for your single sign-on system.

a. Using SiteMinder 6.0 as an example, the value of the Username Attribute would be SMUSER.11) Save your changes (if necessary) by clicking the Save button, or cancel the edit.

12) Modify the setting Single Sign On | OP and change the value to true. 13) Save your changes.

14) Modify the setting Single Sign On | SOX and change the value to true. 15) Save your changes.

16) Navigate to the following location: OpenPages|Applications|Common|Configuration.

17) Click on Show Hidden Settings and change the value to false.

18) Click Save to save your changes.

19) Start all OpenPages services.

Configuring CommandCenter With a Single Sign-on System

If you are using the CommandCenter application as part of your OpenPages system, you must load an updated redirect JSP so that reports will function properly.

This can be done by loading the redirect JSP through the ObjectManager tool using the CommandCenter-intefration-op-config.xml file. This file is part of the OpenPages installation media and can be found in the OP_5.5_Configuration_Disk_1_of_2 CD (of folder) in the \reporting\CommandCenter\loader-data directory.

To load the file:

1) Locate the CommandCenter-intefration-op-config.xml loader file.

2) Open a command prompt window3) Navigate to the \OpenPages directory on the OpenPages application server.

a. This is where you will find the ObjectManager.cmd file.4) Run the following command:

a. ObjectManager l c OpenPagesAdministrator CommandCenter-integrationAccessing OpenPages With SiteMinder Enabled

To access OpenPages with SiteMinder enabled you should access the URL http:///openpages/home.do. This will bring up the SiteMinder login window. Login with a valid username and password and you should see the home page for that user. Click on a CommandCenter report and verify it runs correctly.NOTE: All users in the SiteMinder user directory MUST have user accounts in the OpenPages application. The passwords for the user accounts in OpenPages application are irrelevant as the password authentication is done by SiteMinder however the user must exist in both the SiteMinder user directory and in the OpenPages application.Objective: Integrate OpenPages 5.1 Application with Single Sign On Infrastructure, customer is using GetAccess from Entrust as SSO solution..

Configuration on the Application servers with GetAccess

The application servers require the installation and configuration of the Microsoft IIS Plug-in, by this mechanism GetAccess will intercept any request to access the Openpages application. The plug-in acts as a proxy, forwarding requests to weblogic(Application server), any request that comes from http://, during this forwarding GetAcess intercepts and authenticates users.

Configuration on the Application:

OpenPages can integrate with a number of single-sign-on solutions, such as GetAccess. The following instructions explain how to configure OpenPages for use with one of these systems.

To modify the single-sign-on settings, you will need to be logged into OpenPages as a user who can edit the OpenPages Settings menu item.

To enable the integration of a single-sign-on system with OpenPages:

1. Click on the Settings link under the Configuration heading in the Action Menu.

2. Navigate to the following location: OpenPages|Applications|Common

|Configuration.

3. Click on the Show Hidden Settings setting and change the value to true (without the quotes).

4. Click Save to save your changes.

5. Navigate to the following location: OpenPages|Platform|Security|Single SignOn|Implementations|Header-based.

6. Click on the Session Attribute link.

7. Modify the value (if necessary) to match the session attribute for your single-sign-on system. Using GetAcess as an example, the value of the Session Attribute parameter would be SESSIONID (without the quotes).

8. Save your changes (if necessary) by clicking the Save button, or cancel the edit.

9. Click on the Username Attribute link.

10. Modify the value (if necessary) to match the user name attribute for your single-signon system. Again using GetAccess as a example, the value of the Username Attribute would be USER.

11. Save your changes (if necessary) by clicking the Save button, or cancel the edit.

12. Modify the setting Single Sign On | OP and change the value to true (without thequotes). Save your changes.

13. Modify the setting Single Sign On | SOX and change the value to true (without the quotes). Save your changes.

14. Navigate to the following location: OpenPages|Applications|Common

|Configuration.

15. Click on the Show Hidden Settings setting and change the value to false (withoutthe quotes).

16. Click Save to save your changes.

Configuring the Single Sign On Logout Destination

Logging out of OpenPages does not log the user out of the single-sign-on system automatically.

If the user uses the Back button of the browser to re-enter OpenPages, the users session will

be recreated for them based on the still-valid third-party credentials.

In order to securely sign out from OpenPages and the single-sign-on system, the logout URL

should be pointed at a URL that invalidates the single-sign-on session.

To redirect the logout URL:

1. Click on the Settings link under the Configuration heading in the Action Menu.

2. Navigate to the following location: OpenPages|Platform|Security.

3. Click on the Logout URL link.

4. Enter a fully-qualified URL. This URL will be displayed when the user clicks the Logout

link in the OpenPages header.

5. Save your changes by clicking the Save button.

Page 11