I spent some time this summer implementing Oracle's CoreID product (now known as Oracle Access Manager) as a solution to bypass the PeopleSoft sign in screen. It works as an add-in module in Apache, IIS or IHS that intercepts requests and checks to see if the URL is protected in the Access Manager component. If it is protected, Access Manager executes the security rules as specified. Our rules redirect the user to an IIS web server which performed Integrated Windows Authentication. After the user was successfully authenticated, it redirected the user back into PeopleSoft using the original URL that the user requested. But in addition to redirecting the user back, it added the user's EMPLID (which was retrieved from Active Directory) as an HTTP header in the request.
On the PeopleSoft side, I enabled the WWW_Authenticate signin PeopleCode to retrieve the EMPLID header, look up the Operator ID, and do a Switch User to sign in as that operator. I did put some code to make spoofing the EMPLID header a bit more difficult for a wannabe hacker.
But CoreID is a relatively complicated product meant to work with multiple web applications. If you're wanting to just do Kerberos authentication with PeopleSoft to bypass the sign in screen, you might look at the following options:
Please let me hear from you if you've tried any of these approaches and let me know what worked and what didn't.
Comment from Kiran
written by Kiran, October 11, 2006
...
written by Brent Martin, October 12, 2006
Comment from Kiran
written by Kiran, October 12, 2006
...
written by Brent Martin, October 12, 2006
Changing Sign-On Language on the fly
written by Manoj, March 19, 2009
On the PeopleSoft side, I enabled the WWW_Authenticate signin PeopleCode to retrieve the EMPLID header, look up the Operator ID, and do a Switch User to sign in as that operator. I did put some code to make spoofing the EMPLID header a bit more difficult for a wannabe hacker.
But CoreID is a relatively complicated product meant to work with multiple web applications. If you're wanting to just do Kerberos authentication with PeopleSoft to bypass the sign in screen, you might look at the following options:
- WebLogic "should" be able to do this, but the version that's delivered with PeopleSoft seems to be missing the Kerberos security policy functionality. It might be worth checking with PS to see if you can get a full version, otherwise consider purchasing it
- Investigate WebSphere or Oracle Application Server's Kerberos authentication options.
- Use IIS as a reverse proxy server (it has native Integrated Windows Authentication). Having been down this path, I know IIS authenticates the user but doesn't want to pass the username/password over to your app server. You might have to write your own ISAPI filter to make it happen.
- There are network devices that do the authentication and cache application username/password combinations. When the user hits the web site, the network device signs the user in based on the authentication so the user never sees the signin screen. Although this sounds like a maintenance nightmare, but I know of one company that is VERY happy with this solution and it's relatively cheap to deploy.
- Probably the most common approach I've seen is to write some type of ASP script that users could hit via URL which would use IIS's native Integrated Windows Authentication to authenticate the user, generate a PSTOKEN (via Component Interface) and redirect them back into PeopleSoft. Not bad if your users start from the same point in the app, but it's not so good if users expect to be able to click on any URL and get straight into the app w/ no signin.
Please let me hear from you if you've tried any of these approaches and let me know what worked and what didn't.
Trackback(0)
TrackBack URI for this entry
Comments (7)
Subscribe to this comment's feed
written by Kiran, October 11, 2006
"Probably the most common approach I've seen is to write some type of ASP script that users could hit via URL which would use IIS's native Integrated Windows Authentication to authenticate the user, generate a PSTOKEN (via Component Interface) and redirect them back into PeopleSoft"
I'm interested in using this option. I am hoping I can have my users get into PeopleSoft by first invoking an ASP where, I would authenticate them against Active Directory and then redirect them into PeopleSoft.
Do you know of the specifics of generating the PS_TOKEN? The call to PRTL_SS_CI assumes you already have the token, whereas in my case I somehow need to be able to generate it? --Thanks
I'm interested in using this option. I am hoping I can have my users get into PeopleSoft by first invoking an ASP where, I would authenticate them against Active Directory and then redirect them into PeopleSoft.
Do you know of the specifics of generating the PS_TOKEN? The call to PRTL_SS_CI assumes you already have the token, whereas in my case I somehow need to be able to generate it? --Thanks
-
- +0
-
-
written by Brent Martin, October 12, 2006
I took another look at my current client's implementation of this, and I was wrong about the CI piece. Here's how it actually works:
* IIS is configured for Integrated Windows Authentication.
* default.asp retrieves the AUTH_USER server variable, encrypts it along with the SESSION_ID, and redirects the user to PeopleSoft.
* PeopleSoft fires Sign-in PeopleCode which decrypts the AUTH_USER and SESSION_ID variables, verifies that the Referer was the our ASP page, verifies the username exists in Active Directory, and uses SetAuthenticationResult to sign the user on.
This isn't incredibly secure since the Referrer could be spoofed and the encryption/decryption logic isn't very strong. One thing they were considering was having the ASP script insert the session ID into the database where the Signon PeopleCode could verify that it matched the value sent from default.asp.
* IIS is configured for Integrated Windows Authentication.
* default.asp retrieves the AUTH_USER server variable, encrypts it along with the SESSION_ID, and redirects the user to PeopleSoft.
* PeopleSoft fires Sign-in PeopleCode which decrypts the AUTH_USER and SESSION_ID variables, verifies that the Referer was the our ASP page, verifies the username exists in Active Directory, and uses SetAuthenticationResult to sign the user on.
This isn't incredibly secure since the Referrer could be spoofed and the encryption/decryption logic isn't very strong. One thing they were considering was having the ASP script insert the session ID into the database where the Signon PeopleCode could verify that it matched the value sent from default.asp.
-
- -1
-
-
written by Kiran, October 12, 2006
Hello Brent,
Thank you so much for your reply - I think it took me several steps closer to a solution!
However, I did want to understand how you passed info (in your case, encrypted AUTH_USER+SESSION_ID) to PS? was it
- using the header - Response.addHeader?
- setting a cookie - Response.Cookies?
- adding to the query string?
Thanks,
Kiran
Thank you so much for your reply - I think it took me several steps closer to a solution!
However, I did want to understand how you passed info (in your case, encrypted AUTH_USER+SESSION_ID) to PS? was it
- using the header - Response.addHeader?
- setting a cookie - Response.Cookies?
- adding to the query string?
Thanks,
Kiran
-
- +0
-
-
written by Brent Martin, October 12, 2006
You could certainly use any one of these methods, but the example I was talking about used the query string. It actually sets three variables: userid and pwd (which have special meaning to PeopleSoft), and a custom value called loc.
Userid was set to the session ID, pwd was set to session id, loc was set to AUTH_USER.
I'm guessing userid and pwd were populated so that PS would try to authenticate the user and fire the PeopleCode -- otherwise you have to set up the application for Anonymous Access (which is how the WWW_AUTHENTICATE function works). There's really no special reason to populate userid and pwd with Session ID, but this particular asp script encrypted the loc value based on the session ID (which may improve security a bit) so the PeopleCode function needed the session ID to decrypt it.
&#xRe;quest.GetParameter() was used to retrieve the value of loc, which was what the PeopleCode function actually used to sign the user in as (after it was decrypted).
Userid was set to the session ID, pwd was set to session id, loc was set to AUTH_USER.
I'm guessing userid and pwd were populated so that PS would try to authenticate the user and fire the PeopleCode -- otherwise you have to set up the application for Anonymous Access (which is how the WWW_AUTHENTICATE function works). There's really no special reason to populate userid and pwd with Session ID, but this particular asp script encrypted the loc value based on the session ID (which may improve security a bit) so the PeopleCode function needed the session ID to decrypt it.
&#xRe;quest.GetParameter() was used to retrieve the value of loc, which was what the PeopleCode function actually used to sign the user in as (after it was decrypted).
-
- +2
-
-
written by Manoj, March 19, 2009
Hi
Is it possible to change the Sign-On Language using the Webserver based Authentication. The Language Code will as a Responsed.Header value. Is it possible to possible to change the language Code?
I tried using the SetLanguage() after SetAuthentication (), but the language still remains in English. Is it possible to change the language programatically in the SignOn PeopleCode or any other workaround?
Is it possible to change the Sign-On Language using the Webserver based Authentication. The Language Code will as a Responsed.Header value. Is it possible to possible to change the language Code?
I tried using the SetLanguage() after SetAuthentication (), but the language still remains in English. Is it possible to change the language programatically in the SignOn PeopleCode or any other workaround?
-
- +2
-
-
Write comment
| < Prev | Next > |
|---|
Last Updated on Monday, 02 October 2006 15:16.
http://blog.greysparling.com/2006/04/peoplesoft-single-signon.html
We ended up having enough people ask about it, that we built out a product just for this, so of course that would be another option to list :-)