Understanding the Authentication Domain
The portal authentication domain is the domain in which the portal is running and across which the single signon authentication token is valid. It's specified as a web server property and is used extensively throughout the PeopleSoft Pure Internet Architecture and portal runtime systems. An authentication domain is expressed as a string that completes the domain portion of a URL, for example, .example.com.
Note: The leading period is required. The correct string is, for example, .example.com, and not example.com.
The authentication domain supports the following functionality:
Cross-frame JavaScript updates between the PeopleSoft Pure Internet Architecture and the portal.
Failure to set the authentication domain correctly for the portal and PeopleSoft Pure Internet Architecture applications causes JavaScript security errors to appear in the browser when PeopleSoft Pure Internet Architecture pages are accessed through a portal frame-based template. (The default template through which all PeopleSoft Pure Internet Architecture pages are displayed is frame-based.) The authentication domain must be set for both the portal web server and other PeopleSoft content web servers.
PeopleCode global variable sharing between components on the homepage and components within a frame.
Failure to set the authentication domain correctly for the portal and PeopleSoft Pure Internet Architecture applications that use different web servers causes a new, incompatible session to be created on the PeopleSoft Pure Internet Architecture web server when the user accesses a PeopleSoft Pure Internet Architecture component through a frame-based template.
Single signon among PeopleSoft applications.
Failure to specify the authentication domain correctly prevents the PeopleSoft authentication cookie from being passed to the target PeopleSoft application and forces the target system to reauthenticate the user.
Cookie sharing between the portal and third-party web applications.
If cookies need to be shared between web applications, then each web application must be accessed over a common domain name.
To share cookies, specify the authentication domain as the Cookies Passed to Server (forwarding domain) property in the portal's web profile. You specify this property on the web Profile Configuration - Cookie Rules page.
Base-Level and Extended Authentication Domains
You can define the portal authentication domain as a base-level authentication domain and as an extended authentication domain.
You define the base-level authentication domain during the PeopleSoft Pure Internet Architecture setup. This domain is stored as part of your web server configuration. It enables PeopleCode global variable sharing, which is required for initial access to the portal. The portal uses the base-level domain if you don't define an extended authentication domain.
Important! You must specify a base-level authentication domain during the setup of every PeopleSoft application with which your portal interacts. The authentication domain must be identical and be stored on the web server of each application.
See PeopleTools Installation for your database platform.
You can define an optional extended authentication domain in your portal web profile. An extended authentication domain overrides, but must be compatible with, the base-level authentication domain. For example, if you entered .example.com during the PeopleSoft Pure Internet Architecture setup, only values such as .us.example.com and .fr.example.com would be valid.
Note: If you defined a base-level or extended authentication domain, you must use it in all URLs that you specify in your portal. For example, if your authentication domain is .example.com, then instead of using the URL http://mymachine:8080/pshome/signon.html, you must use the URL http://mymachine.example.com:8080/pshome/signon.html.
You specify the extended authentication domain on General tab of the Web Profile Configuration page.
An Example of Multiple Applications on a Portal
Image: Example of the portal system and several PeopleSoft applications within the same authentication domain
In the following example, the CRM and HRMS web profiles need to be defined with Domain Name Server (DNS) names that include the same authentication domain as the DNS name of the portal web server. They also each need the Authentication Domain property in their web profiles set to this value.
Web servers that don't have the same server domain as the portal (such as sales.i) can still be used to serve content to the portal. However, cookies set by the portal are not forwarded to these servers. The sales.i server in the example can provide pages and applications to the portal, but it cannot host a PeopleSoft application that supports single signon functionality with the portal.