Note: Variations between the account services, including verification of identities of those who own an account, and that anyone can acquire an FPS account, mean that you should not treat the services as equivalent, unless you understand the risks or make run-time decisions based on the logged-in Cosign realm. Most websites should probably only allow Access Accounts: the instructions below are for that use case.
OneID: The WebAccess service has not changed its login process since the launch of OneID: there are still the two realms, and they still have the values as shown below. For other areas at Penn State, FPS accounts are now referred to as Limited Accounts, while Access Accounts are Standard Accounts.
WebAccess Login Process
For support of multiple realms, the WebAccess login process first checks the Access Account realm. If the account name and password are not a match (or the account is locked), then the FPS realm is checked.
If an FPS account attempts to view a website restricted to Access Accounts, they’ll be redirected here, which explains the situation. Conversely, an Access Account attempting to view an FPS-only website is redirected here.
If your website requires 2FA, you don’t have to check the realm as 2FA is only available to Access Accounts.
How to Differentiate Account Types/Authorization …
… By using Cosign Configuration
Here’s how to enable the feature on the various platforms. The examples below are for a website limited to Access Accounts; for an FPS-only website, change
fops.psu.edu. (Yes, “fops”, not “fps”.)
In the Apache httpd.conf configuration file (or included file) where you have your CosignService directive, add this line right after it
then restart httpd.
IIS 7+ (CosignModule)
Your current <service> element is most likely a single tag similar to
<service name="cosign-www.dept.psu.edu" />
To make this change, you’ll need to split it into a start and end tag surrounding a new <add> element, like
<service name="cosign-www.dept.psu.edu"> <add factor="dce.psu.edu" /> </service>
then restart IIS.
Your cosignConfig.xml file will have a section for your web site similar to
<service name = "cosign-www.dept.psu.edu"> <protected>/cosign-secure/protected/</protected> <service>
Modify it similar to this
<service name = "cosign-www.dept.psu.edu"> <reqfactor> <factor>dce.psu.edu</factor> </reqfactor> <protected>/cosign-secure/protected/</protected> <service>
then restart your Java service.
… By Server-side Programming
If you’re using server-side authorization checks (e.g., an explicit list of account names in a list, such as Apache’s “Require user” directive; checking an account’s attributes in LDAP or other database, etc.), you may not need to add any other checks (if you can verify the ownership of any FPS accounts allowed access). Otherwise, you probably need to check the account name in combination with the account’s realm.
The Cosign filter in your Web server sets a
REMOTE_REALM variable/header in addition to the
REMOTE_USER (account name), which can be used to differentiate between Access and FPS accounts. Here are each realm and its corresponding value
Friends of Penn State (FPS) Account