WWW_Authentication Considerations

If you intend to authenticate your users at the web server level using mutual authentication SSL/TLS (also known as client authentication), the users that are authenticated at the web server level must signon to the system using a different web site than users of the other authentication methods.

When you configure a PeopleSoft site to enable public access, a public user ID and password in the web profile provide automatic authentication. Keep in mind that this enables public access for the entire site. The web server always passes the specified public user ID and password to the application server. So, if you want some users to be authenticated by PeopleSoft rather than at the web server level, they must sign in through a PeopleSoft site that has public access disabled.

Important:

The PeopleCode RevalidatePassword( ) and SwitchUser( ) built-in functions don't work during a user session for which you're using WWW_Authentication.

In WWW_Authentication, PeopleSoft performs no validation of users and their passwords. The Signon PeopleCode simply accepts the web server's word that the user was properly authenticated. Your PeopleSoft application has no way to revalidate the user's password in this case, so you shouldn't call RevalidatePassword or SwitchUser after WWW_Authentication has been used.

You can determine whether WWW_Authentication has been used by examining a global variable. The Signon PeopleCode for WWW_Authentication sets the PeopleCode global variable called &authMethod to the value WWW when a successful signon occurs. In PeopleCode where you want to call RevalidatePassword or SwitchUser, first examine &authMethod. If it's not equal to WWW, you can call those functions.