single sign-on implementation

Confidential 26/05/2009

SSO Implementation with PeopleSoft Enterprise Portal

Rupesh Kumar


Table of Content

Table of Content................................................................................................................... 2

1. Introduction ...................................................................................................................... 3 1.1 Understanding SSO .................................................................................................................3 1.2 Understanding NTLM .............................................................................................................4 1.3 Understanding cookies............................................................................................................4

2. SSO Design and Implementation .................................................................................... 6 2.1 Solution Design ........................................................................................................................6 2.2 Implementation ........................................................................................................................8

3. Appendix (SSO).............................................................................................................. 18 3.1 Roles with Special Uses .........................................................................................................18 3.2 Permission List with Special Uses .......................................................................................18 3.3 Further Reading .....................................................................................................................19


1. Introduction

SSOL (Dummy Company Name) wants users to automatically signon to PeopleSoft Enterprise portal 9.0 using their Active Directory Credentials, bypassing Portal SignOn page. The entry point of the user will be the SSOL Intranet site. A link/button will be provided over this site that will take user directly into the Portal. Windows authentication uses Active directory as the user store.

1.1 Understanding SSO

SSO- Single Sign On- is a mechanism that allows the user to use multiple IT applications by having to supply entry credentials only once into one of them, until the expiry of a specified time limit. This one-time authentication obviates the pain of having to remember multiple passwords for multiple applications.

What PeopleSoft Says?

Single signon refers to the ability of users to navigate freely within a system of multiple applications after only being authenticated once. There are three different ways to configure single signon, depending on the participating applications that you have installed, and the middleware platforms on which they run. The following table displays the single signon options.

Single Signon Option Description

PeopleSoft-only This option enables single signon only between multiple PeopleSoft applications, such as PeopleSoft Human Capital Management and PeopleSoft Customer Relationship Management.

Oracle as a Trusted Node If you have Oracle applications and PeopleSoft applications being used in your organization, users, who have been authenticated by the Oracle system, can freely access PeopleSoft applications without having to be re-authenticated.

Oracle as a Partner Application If you are running your PeopleSoft applications on Oracle Application Server 10g this is the recommend option. This option is not available if you are using BEAWebLogic or IBMWebSphere as your web server.

This option has the Oracle Single Signon server performing authentication for both Oracle applications and PeopleSoft applications. That is, end users signing in through a PeopleSoft application get authenticated by the Oracle Single Signon server the same as users signing in through an Oracle application.

In this document we’re discussing another form of SSO - Single Signon with Third Party Authentication (SSO b/w PeopleSoft and 3rd Party System [Non Oracle Application]).

Reference: http://www.opengroup.org/security/sso/sso_intro.htm

http://www.ibm.com/developerworks/websphere/library/techarticles/0108_botzum/botzum.html


1.2 Understanding NTLM

Windows NT Challenge/Response (NTLM) is the authentication protocol used on networks that include systems running the Windows NT operating system and on stand-alone systems.

NTLM credentials are based on data obtained during the interactive logon process and consist of a domain name, a user name, and a one-way hash of the user's password. NTLM uses an encrypted challenge/response protocol to authenticate a user without sending the user's password over the wire. Instead, the system requesting authentication must perform a calculation that proves it has access to the secured NTLM credentials.

NTLM is a good approach to do SSO using a web application. Here we will use IIS server to do the NTLM and then redirect to PeopleSoft Web Server.

1.3 Understanding cookies

A Cookie is a small string of text stored on a user's computer by a web browser . Cookies are a particular means of maintaining 'state' information, so that a web-server 'remembers' where its conversation with a particular web-browser is up to. It is sent to an appropriate web-server along with a request for pages.

At high level the process is as follows:

1. A web-browser requests a page from a web-server;

2. The web-server sends back to the web-browser not just the requested page, but also an instruction to the browser to write a cookie (i.e. a record) into the client-computer's storage;

3. Unless something prevents it, the web-browser does so;

4. Each time a user requests a web-page, the web-browser checks whether a cookie exists that the web-server expects to be sent with the request;

5. If there is such a cookie, the browser transmits the record to the web-server, along with the request for the page;

6. When a web-server receives a request that has a cookie associated with it, the server is able to use the data in the cookie in order to 'remember' something about the user.

Persistent cookies:

A persistent cookie is one stored as a file on user’s computer, and it remains there when user closes the browser for a period of time. This cookie can be read by the Web site that created it when user visits that site again and allows web application to track user’s web activity.

Temporary/Non- Persistent cookies:

A temporary or session or Non- Persistent cookie is stored in the browser memory for the current browsing session and allows web servers to track the user session. The Non-Persistent cookie disappears when the user closes the browser session.

References: http://msdn.microsoft.com/en-us/library/aa378749.aspx http://curl.haxx.se/rfc/ntlm.html


Example of PeopleSoft Cookies:

References: http://www.cookiecentral.com/faq/ http://oreilly.com/catalog/websec2/chapter/ch08.html


2. SSO Design and Implementation

2.1 Solution Design

The Single Signon Solution is based on HTTP cookies passed between Internet Explorer, IIS Web Server, and PeopleSoft’s Web Server.

From the picture shown above we can tell that the Single signon process goes through threes major phases:

1- The user opens a new browser session and redirects to SSOL intranet site. On the SSOL page user clicks on a PeopleSoft Portal link. The request is then sent to the same IIS server that interrogates the user workstation to get the userid and Active Directory domain.


2- After The IIS server gets the user ID it strips it from the Active Directory Domain and put the result in a session cookie. This cookie is sent to the browser and stored only on the browser memory for a very short period of time to allow the redirect to PeopleSoft Web Server

3- The browser then gets redirected to the intended PeopleSoft Enterprise Portal Page. All cookies with the same domain will be sent to the PeopleSoft Web Server.

Note: In order for cookies to be sent from a browser to a Web Server they need to be on the same domain as the target web server. Consequently the IIS Server and the PeopleSoft Enterprise Portal need to be on the same domain.

LOGON_USER Server Variable


2.2 Implementation

Capturing User Name in Cookies:

1. There should be a Link/Button on http:/my.ssol.com/employee_portal (Dummy URL), which will take user directly to the PeopleSoft Enterprise Portal page (Bypassing the SignOn page).

2. We need to have ASP code behind the Link that will capture User’s Login ID and

pass it as a cookie. Code for ASP.Net [code should be similar to this one]

Dim str1, username, url

str1=Request.ServerVariables("LOGON_USER")

The user credentials stored in the variable str1.

username = Right(str1, Len(str1)-InStr(str1, "\"))

Following step will create a cookie named udata:

Cookie Name: udata

Domain( Host): .test.ssol.gov.in

Expires: Current Time + 5 Sec

Path: /

Response.Cookies("udata")= username

Response.Cookies("udata").Domain=" .test.ssol.gov.in"

Response.Cookies("udata").Expires = dateadd("s",5,Now())

Response.Cookies("udata").Path = "/"

Building URL of Portal Default Page and redirecting response to PeopleSoft Web Server:

url= " http://portaldev.test.ssol.gov.in:5190/psp/por9dev/EMPLOYEE/EMPL/h/?tab=DEFAULT"

Response.Redirect(url)

Important Points:

In order for IIS to be able to extract the user ID from the system we need to disable the anonymous logon. For the ASP page that we have created (Intranet Page) we need to do the following, and failure to do so will result is the variable “USER_LOGON” being inaccessible.

1. Change the authentication mode in the Web.config file to Windows as follows:<authentication mode="Windows" />

2. In the Internet Services Manager, right-click the .aspx file or the Web Project folder, and then click Properties.

3. If you clicked Properties for the Web Project folder, click the Directory Security tab. If you clicked Properties for the .aspx file, click the File Security tab.


4. Under Anonymous Access and authentication control, click Edit.

5. In the Authentication methods dialog box, clear the Anonymous Access check box, and then select either the Basic, the Digest or the Integrated (NT Challenge/Response) check box.

6. Click OK to close both dialog boxes.

PeopleSoft Configuration

Step 1 – Create Permission List for Default User Step 2 – Create Role for Default User Step 3 – Creating a default user profile Step 4 – Configure PeopleSoft Web Profile Step 5 – Create custom Single Signon PeopleCode Step 6 – Configure Single Signon PeopleCode

Step 1: Create and Modify Permission List for Default User We will create a new Permission List ‘AS_SSO_PTPT1000’ for Single SignOn. It’s a copy of existing Permission List ‘PTPT1000 ‘ with a slight modification that this permission List has got no Page access.

References: http://support.microsoft.com/kb/251326 http://technet.microsoft.com/hi-in/library/bb878098(en-us).aspx http://support.microsoft.com/kb/306359


We will modify (or create a clone) the permission list PTPT1400 as follow: In the Personalizations Tab of permission List, ‘Deselect All’ the personalization for PS Internet Architecture.

Step 2 – Create Role for Default User

A new role ‘AS_SSO’ has been created for Default User. This role will have following Permission list associated with it: AS_SSO_PTPT1000, PAPP0000, PAPP0001, PAPX0000, and PTPT1400


Step 3: Creating a default user profile

Create a default user ID using PeopleTools Security.

The user ID you specify is just a temporary value used to initiate a secure connection to the application server. The application server then determines the real user ID using signon PeopleCode. The real user ID is contained in the request object, and all the other user information, such as language code, roles, and so on, is already stored in the PeopleSoft system or an LDAP directory server.

For this example, we create the following user profile and password:

User ID: DEFAULT

Password: You should consider creating a long password that is difficult to guess.

Navigate to the menu: PeopleTools > Security > User profiles > User Profiles

Select the tab “Add a New Value” and enter the User ID (i.e. DEFAULT)


On the first tab “General”, you must setup the following fields:

• Symbolic ID -(por9dev)

• Password- Current Password (por9dev_ssol$$)

PS: All other fields should be left blank.

On the tab “ID”, choose the ID Type “None”


And finally on the tab “Roles”, add the role AS_SSO

When connecting to PeopleSoft using the DEFAULT, you should get an empty homepage with no links.


Step 4:

After you’ve created the default user (STEP 1), you can modify the web profile to include the default user signon information. Navigate to the menu: PeopleTools > Web Profile > Web Profile Configuration And choose the Web profile currently used by your Web Server. In General tab please verify that Authentication Domain is same as SSOL Intranet Domain.

On the “Security tab”, to prevent a user ID from being the default user on the signon page, set the Days to Autofill User ID property on the Web Profile Configuration - Security page to 0.

To modify the web profile to include the default user signon information (STEP 1), you first must enable public access to the portal. In the Public Users section of the Web Profile Configuration - Security page, select Allow Public Access to indicate that the system should not prompt users to sign on when they click a direct link to a page. When this is selected, the PeopleSoft system does not display the password page to the user. Instead, the system authenticates


users with the values specified in the User ID and Password fields in the same section of the page. Enter the UserID and password created in Step 1 of this document.

Go to Caching tab and uncheck the Cache Homepage check box.

Step 5: Create custom Single Signon PeopleCode Open Application Designer, and create a new PeopleSoft definition: a Work Record


Add a Field to the Derived/Work Record (i.e. OPRID), this field is used to store the SSO PeopleCode.

In FieldDefault event of OPRID write following peoplecode:

Function SSO_DCD()

&UID = %Request.GetCookieValue("udata");

If &UID <> "" then

SetAuthenticationResult( True, Upper(&UID), "", False);

End-If;

End-Function;

Step 6 : Configure Single Signon PeopleCode

Once the custom SSO PeopleCode method is created, you need to configure it in PeopleSoft in order to initiate it on a authentication connection. Navigate to the menu: PeopleTools > Security > Security Objects > Signon PeopleCode Add a new line to the grid by click on the (+) button and configure it as follows:

• Invoke as : Enter a Super User ID and password (e.g PS)

• Sequence: Add a sequence number

• Enabled: Make sure that this checkbox is selected • Record: Enter the name of the custom record you created in STEP 3 (i.e.

SSO_AUTH_WRK)


• Fieldname: Enter the name of the field where you’ve stored the Peoplecode method (i.e. OPRID)

• Event Name: Enter the event name where the SSO Peoplecode is stored (i.e. FieldDefault)

• Function name: Enter the name of the PeopleCode Function you’ve created in step 3 of this document (i.e. SSO_DCD)

• Exec. Auth. Fail: Leave this checkbox empty.

Save the component and Restart your Application Server and Web Server. (PS: To implement higher degree of Security one can pass user’s credential ( userid) in encrypted form and later that should be decrypted in PeopleCode before passing that value to SetAuthenticationResult function. )


3. Appendix (SSO)

Use section 3.1 and 3.2 to create DEFAULT user’s Role.

3.1 Roles with Special Uses

3.2 Permission List with Special Uses The following table describes permission lists that have special meaning and usage in PeopleSoft Enterprise.


3.3 Further Reading

http://my.oracle.com/portal/page/myo/global/PSFT/PeopleTools/Security

http://jjmpsj.blogspot.com/2007/11/desktop-integrated-signon.html

http://myforums.oracle.com/jive3/thread.jspa?messageID=3180955&#3180955

http://blog.greysparling.com/2006/04/peoplesoft-single-signon.html

single sign-on implementation

Documents