I wrote a post about PeopleSoft Single Signon back in April.



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 :-)

"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 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.

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

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.



%Request.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).