000022060 - Configuring PeopleSoft and RSA ClearTrust integration

Document created by RSA Customer Support Employee on Jun 16, 2016Last modified by RSA Customer Support Employee on Apr 21, 2017
Version 2Show Document
  • View in full screen mode

Article Content

Article Number000022060
Applies ToRSA ClearTrust 5.5.2
PeopleSoft 8.1.9
Microsoft Windows 2000
Single Sign-On (SSO)
Microsoft Integrated Windows Authentication (IWA)
IssueConfiguring PeopleSoft and RSA ClearTrust integration
After Integrated Windows Authentication (IWA) Single Sign-On (SSO) authentication between RSA ClearTrust and the PeopleSoft interface (http://machinename.domain/portal/...), the user navigates to http://machinename.domain/servlets/... and encounters a PeopleSoft warning:

"PeopleSoft 8

The web server appears to be incorrectly configured. System detected that multiple web server sessions are being generated during login. Please, contact your system administrator for assistance."
User accesses http://machinename.domain/servlets/... resource again and is redirected to the contents
CausePeopleSoft documents that a condition that results in the "Web Server is incorrectly configured" error page includes navigating to a URL resource that contains a trailing ampersand "&" character
ResolutionTo correct this issue, modify the URL such that the trailing ampersand character is not present. Then the Integrated Windows Authentication (IWA) Single Sign-On (SSO) experience will operate as expected.

---------------

Further detail can be found within PeopleSoft's solution text: Solution 200750617 - E-WS: Web server appears to be incorrectly configured.


CASE 7:
Customer was trying to bring up a custom page via directlink.html and they were receiving the above error. Found that they had an ampersand (&)at the end of the url and once they removed the ampersand the page started working. An incident is open to address this issue and the id is 691214000.

----------------

Resolution Details:  Solution 200750617 - E-WS: webserver appears to be incorrectly configured

Specific to:
All

ISSUE:
The following error is reported during sign-on to PT 8.19 and higher.

"webserver appears to be incorrectly configured.  System detected that multiple webserver sessions are being generated during login."


SOLUTION:
As the message suggests, this indicates that several connections are being initiated from the browser to the webserver. This can happen because the webserver is not able to read back the cookie it submitted to the browser.

----------
Background:
Cookies have primarily 3 attributes, a name, a value and a domain to which they are associated. The PeopleSoft webserver uses a cookie to track user sessions. Typically, the cookie name follows the naming convention "<hostname>-<port>-WebLogicSession",  where hostname is the local name of the webserver, and port refers to the port the webserver is listening on for incoming http connections.
Examples are: tssun-7001-WebLogicSession , psofthr-80-WebLogicSession, etc.
For WebLogic, the cookie name is set in the configuration.properties file for WL 5.1, and in config.xml for WL 6.1 and higher.

(Note: WebSphere imposes the J2EE convention more strictly and does not allow the cookie name to be changed, its always "JSESSIONID" .
On some systems, the cookie may have the suffix "JSESSIONID" instead of "WebLogicSession" )

The cookie value is set by the application, and is a unique identifier that ties the http session to the session object created within the webserver.

The cookie domain is set by the webserver. When a user accesses a webserver, the browser will only submit cookies that match the domain of the URL being accessed.
For e.g. if the URL is http://pshr.peoplesoft.com/ps/signon.html  then all cookies that have the domain ".peoplesoft.com" will be submitted to the webserver, similarly, if the URL is http://www.pshr.peoplesoft.com/ps/signon.html  then all cookies with the domain ".peoplesoft.com" or ".pshr.peoplesoft.com" will be submitted.  Note that cookies with the domain ".psfn.peoplesoft.com" will *not* be submitted to either of these URLs.
Using a domain in the URL is optional, if its not being used, the cookie will be associated with the server name, rather than the domain name. If you plan to use PeopleSoft's Single Sign-On feature, you will need to use a domain qualified URL.
---------

The issue mentioned above occurs if the webserver sends a cookie to the browser, and then redirects it to another link expecting to read the cookie back, but somehow is not able to, e.g. the browser does not send the cookie back to the domain it came from. The following scenarios have been identified:


CASE 1:
Cookies are disabled on the browser.

For Internet Explorer, check the status bar (lower right corner) for the zone your domain is on. Then go to Tools/Internet Options/Security, select the Zone, and select Custom settings. Make sure cookies are enabled.


CASE 2:
The domain name in the cookie does not match the domain name in the URL.

Note the domain name in the URL you are using to access the webserver. If you are running WL 5.1, the weblogic.properties file, and the configuration.properties file should have the domain name. See example below:

In configuration.properties:

AuthTokenDomain=.corp.peoplesoft.com

In weblogic.properties:

weblogic.httpd.session.cookie.name=tssun01-5000-WebLogicSession
weblogic.httpd.session.cookie.domain=.corp.peoplesoft.com

Check the following properties are set correctly if you are not using a domain name in the URL

In configuration.properties:

AuthTokenDomain=

In weblogic.properties:

weblogic.httpd.session.cookie.name=tssun01-7001-WebLogicSession
#weblogic.httpd.session.cookie.domain=

Bad configuration examples:

Example 1: ( Reason: weblogic.httpd.session.cookie.domain is empty)
configuration.properties
AuthTokenDomain=.corp.peoplesoft.com

weblogic.properties
weblogic.httpd.session.cookie.name=tssun01-5000-WebLogicSession
weblogic.httpd.session.cookie.domain=

Example 2: ( Reason: weblogic.httpd.session.cookie.domain should be commented out if not using Domains)
configuration.properties
AuthTokenDomain=

weblogic.properties
weblogic.httpd.session.cookie.name=tssun01-7001-JSESSIONID
weblogic.httpd.session.cookie.domain=

Example 3: (Reason: Cookie domain in weblogic.properties does not match AuthTokenDomain)
configuration.properties
AuthTokenDomain=.corp.peoplesoft.com

weblogic.properties
weblogic.httpd.session.cookie.name=tssun01-7001-WebLogicSession
weblogic.httpd.session.cookie.domain=.peoplesoft.com

Example 4: (Reason: MYSESSIONID may not be recognized by cookierules.xml )
configuration.properties
AuthTokenDomain=.corp.peoplesoft.com

weblogic.properties
weblogic.httpd.session.cookie.name=tssun01-7001-MYSESSIONID weblogic.httpd.session.cookie.domain=.corp.peoplesoft.com

Lastly make sure that these parameters are not duplicated in the weblogic.properties file. An aborted or incorrect installation may cause the parameters to appear more than once, in which case WebLogic only recognizes the last one.


CASE 3:
You are not using a domain in the URL, but the cookie has a domain, or vice-versa.

For example, if the configuration.properties file has
AuthTokenDomain=.peoplesoft.com
but you are using
http://tssun01/ps/signon.html
to access the webserver.

Alternatively, the configuration.properties contains
AuthTokenDomain=
but you are using
http://tssun01.peoplesoft.com/signon.html


CASE 4:
Cookies are being set in other parts of the application, or by other content providers(for portal)  that exceed the 20 cookies per domain limit for the browser. When more than 20 cookies are set, the browser starts discarding cookies randomly.

Type in "javascript:document.cookie" in your browser address bar to get  a dump of all cookies associated with the current site. Each NAME=VALUE; pair identifies one cookie.


CASE 5:
A bad cookie has been set that cannot be parsed by the webserver, causing all cookies to be discarded. For example, with WebLogic 5.1 SP12, commas are no longer allowed in the cookie value. If a cookie containing commas(,) is encountered by the webserver, it rejects the http header, causing the sign-on cookie to be lost too. Same situation can happen with cookies whose value exceeds 4 KB which is the maximum size limit for a cookie data.
Note: WebLogic 5.1 SP9 and WebLogic 6.1 SP1 allowed commas in cookie values, so some of the code within the PeopleSoft application used them as delimiters. Since PT 8.43.03, this has been changed to use "|"(pipe) instead. If you are mixing pre-PT 8.41.03 and post-PT 8.41.04 (including PT 8.19 or later) releases you might see cookies being set by one webserver with commas that get blocked when they hit the other webserver. For example, this can happen with a pre-PT 8.41.03 portal accessing  content on PT 8.19.

If you are accessing different PeopleTools releases and have single sign-on, or if you are running PeopleSoft Portal with content hosted on different PeopleTools releases, make sure that all the PeopleTools release either use commas in cookies, or none of them do. As a rule of thumb, all versions later than PT 8.41.03 and PT 8.18, do not use commas.
When a cookie that uses commas gets submitted to a webserver that does not allow it, you'll get the following error:

Mon Jul 28 21:09:06 PDT 2003:<E> <ServletContext-General> Got bad Cookie header: in cookie 'SignOnDefault; http%3a%2f%2fitnt19.scu.edu%3a8100%2fpsp%2fcpdev84%2femployee%2fempl%2frefresh=list: %3ftab%3demployee_page,%3ftab%3dfaculty_homepage,%3ftab%3dpxxxxest; tssun01-80-WebLogicSession=PyXzYetWTYWhCAxTtuYAdwSvdQrOBmU57yNnTYyPyWiK2pyQa6Y9|-4419809228241818902/-2116942805/6/80/80/443/443/80/-1' character ',' at position 148 is illegal from User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)

weblogic.servlet.internal.MalformedCookieHeaderException: in cookie 'SignOnDefault; http%3a%2f%2fitnt19.scu.edu%3a8100%2fpsp%2fcpdev84%2femployee%2fempl%2frefresh=list: %3ftab%3demployee_page,%3ftab%3dfaculty_homepage,%3ftab%3dpapp_guest; tssun01-80-WebLogicSession=PyXzYetWTYWhCAxTtuYAdwSvdQrOBmU57yNnTYyPyWiK2pyQa6Y9|-4419809228241818902/-2116942805/6/80/80/443/443/80/-1' character ',' at position 148 is illegal
at weblogic.servlet.internal.CookieParser.parseNetscapeCookie(CookieParser.java:222)
at weblogic.servlet.internal.CookieParser.parse(CookieParser.java:111)
at weblogic.servlet.internal.CookieParser.getCookies(CookieParser.java:104)
at weblogic.servlet.internal.CookieParser.parseCookies(CookieParser.java:93)
at weblogic.servlet.internal.ServletRequestImpl.parseCookies(ServletRequestImpl.java:1300)
                     at weblogic.servlet.internal.ServletRequestImpl.getCookies(ServletRequestImpl.java:1285)
at weblogic.servlet.internal.ServletRequestImpl.initSessionInfo(ServletRequestImpl.java:1452)
at weblogic.servlet.internal.ServletRequestImpl.getSession(ServletRequestImpl.java:1332)
at weblogic.servlet.internal.ServletContextImpl.checkA(ServletContextImpl.java:2005)
at weblogic.servlet.internal.ServletContextImpl.checkAccess(ServletContextImpl.java:1804)
at weblogic.servlet.internal.ServletContextImpl.invokeServlet(ServletContextImpl.java:942)
at weblogic.servlet.internal.ServletContextImpl.invokeServlet(ServletContextImpl.java:909)
at weblogic.servlet.internal.ServletContextManager.invokeServlet(ServletContextManager.java:269)
at weblogic.socket.MuxableSocketHTTP.invokeServlet(MuxableSocketHTTP.java:392)
at weblogic.socket.MuxableSocketHTTP.execute(MuxableSocketHTTP.java:274)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:130)


CASE 6:
Following the UNC, there should not be underscores in the webserver name or the domain name in the URL. Hyphens are okay.

Bad: http://ps_hr.peoplesoft.com/ps/signon.html
Bad: http://pshr.people_soft.com/ps/signon.html
Bad: http://ps_hr/ps/signon.html
Good: http://ps-hr.peoplesoft.com/ps/signon.html
Good: http://ps-hr.peoplesoft.com/ps_test/signon.html
Good: http://pshr/ps-test/signon.html

Note: PT 8.1.x allows underscores in domain names whereas PT 8.4.x does not.


CASE 7:
Customer was trying to bring up a custom page via directlink.html and they were receiving the above error. Found that they had an ampersand (&)at the end of the url and once they removed the ampersand the page started working. An incident is open to address this issue and the id is 691214000.


CASE 8:
Determined that the issue was a result of a local browser setting.  Must enable "Always Allow Session Cookies" in Internet Explorer 6.

Internet Explorer 6.x for PCs:
From inside the IE window:

> Go to Tools, then click on Internet Options.
> Click on the Privacy tab.
> Click on the button Advanced.
> Check the box Override Automatic Cookie Handling.
> Check the box Always Allow Session Cookies.


WORKAROUND:
N/A
Legacy Article IDa26604

Attachments

    Outcomes