View All Resources

Central Authentication & Authorization: WebLogin Resource

Penn WebLogin is the central PennKey authentication process for restricting access to web applications and static web pages.

SP Validation
Shibboleth SP Validation Guide

The purpose of this document is to validate that a Shibboleth SP is properly configured to federate with either the Penn or InCommon IdPs. Upon successful completion of this guide, the SP will be receiving the attributes necessary to authorize users to use your application.


The following must be prepared in order to validate a Shibboleth SP configuration:

  • The Shibboleth SP must be installed on a web server, such as Apache or IIS.
  • The metadata and configuration file from Penn have been put in place.
  1. Navigate your web browser to the following address: Be sure that you use https and that your SP was configured to use SSL.
  2. If the SP has been properly set up with the IdP’s metadata, you should be redirected to a login page from the IdP.
  3. Attempt to log in. If you proceed past the login screen and on to the original address, then the SP is successfully configured for federation with either Penn or InCommon. If you see an error at this point that is not connected to the IdP (such as a 404 error), then do not worry¬—this does not necessarily mean the SP is misconfigured, only that there is nothing to display at that address. For testing purposes, you may add a simple html page with the filename index.html into the secure directory to avoid the error page.
  4. To check whether or not the correct attributes have been communicated to the SP, navigate to the SP’s Session page.
Common Issues

Error 404 when accessing protected content

If you receive this error when you would normally be redirected to the IdP’s login page, then there are multiple possible causes:

If the error occurs before the redirect to the IdP:

  • The address may have been typed into the browser incorrectly. Check that it is correct and try again.
  • The SP and/or web server may not be running. Ensure that they are up and running with no errors and try again.

If the error occurs after the redirect:

  • There may be an error with the metadata for the IdP. Ensure that the correct metadata for the IdP is imported into the SP.
  • The IdP may be currently down/non-responsive. Check the Penn WebLogin Status page at Click the Authentication link under WebLogin server and find the Shibboleth server’s status.
  • The SP’s host machine may not be able to reach the IdP’s host machine. Attempt to reach the IdP directly from the SP host machine. Attempt to telnet into the secure port if this fails. If this fails as well, contact the team responsible for managing your local network.

Shibboleth metadata error

There is an error in the configuration file for the SP. Check the entityID for the IdP in the shibboleth2.xml configuration file and make sure that it is accurate.

Failure to log in

Ensure that you have an account on the IdP and that it was inputted correctly. If you are still having issues, contact the Penn WebLogin Team.

Signing Error

Shibboleth may give this error when returning to the protected page after logging in. If you receive this error, then there are two possible causes:

  • The security certificate in the IdP’s metadata does not match the security certificate that the SP has access to. Contact the Penn WebLogin Team to resolve this issue.
  • The security certificate in the SP’s metadata does not match the security certificate that the IdP has access to. Contact the Penn WebLogin Team to correct the metadata or certificates.

Incorrect or missing attributes

You may notice this when looking at the Sessions page for the SP. Contact the Penn WebLogin Team to ensure that all necessary attributes are being sent. The attributes may need to be verified in the application itself.

Attributes with incorrect values

If the attributes sent over by the IdP contain the wrong values, the mapping for the attributes may be incorrect. Contact the Penn WebLogin Team and ensure that the correct values are being mapped to the attributes that they are sending.

Unable to meet security requirements

Typically, this is the result of trying to access the IdP before the service provider’s metadata is in place. If the service provider’s metadata was recently transferred to the IdP, allow time for processing. Otherwise, contact the Penn WebLogin Team.

Best Practices when Integrating with the University of Pennsylvania Identity Provider

Using our Attributes

Please consult our attribute information to see detailed information about the attributes which are releasable to service providers. 

sample SAMLResponse is available for review. Please consult this to see how the attributes are sent in practice from our Identity Provider.

Unique Identifiers

By default, the unique user identifier is eduPersonPrincipalName. In cases where there is a special need and eduPersonPrincipalName can not be used, we have released employeeNumber. Please contact us if you feel your service provider has this need and we can discuss the requirement.


The e-mail address field is both suppressible and is non-verified user supplied data. If your service provider has a requirement for e-mail address we suggest they proceed as follows:

  1. If the e-mail address is provided in the SAML asssertion, use it. If it is different from the previous e-mail address for that ePPN, business rules should determine what to do.
  2. If the e-mail address is not provided in the SAML assertion and no e-mail address is known from a previous authentication, prompt the user for one and store it locally.

In either of the above cases, the user should be able to access their profile and modify their e-mail address as needed directly within the application. 

Note: E-mail address should never be used as a unique user identifier for mapping authentications to accounts.

Secure Cookies

Service providers create their own session cookie after a user has logged into the system. These session cookies must have the secure flag set. This prevents a cookie from being sent over an unencrypted HTTP request.


Logout requires the destruction of several sessions cookies to effectively log the user out of the university single sign-on system. We have tools in place to log the user out of the identity provider session, and the WebLogin master session. The service provider must handle their own sessions and destroy them appropriately. We do not offer a "Single Logout" solution.

In general, the logout mechanism should be handled as follows:

  1. Service Provider Responsiblity: Provide a logout button/link. Upon clicking this link the service provider should destroy the user's browser cookie for the domain they control. Then, re-direct the user to
  2. Identity Provider Responsibility: Destroy the user's browser cookie for the Identity Provider session. Then, re-direct the user to
  3. WebLogin Responsibility: Provide a logout page where the user can click a "Logout" button to destroy their single sign-on session.

#2 and #3 are provided through existing functionality. #1 is the missing piece which must be implemented at the service provider. The Shibboleth project has some information about the single logout issue which can be found here:

Confirming a WebLogin Page is Legitimate

Phishing attempts against PennKey credentials have been increasing. Here are some tips to quickly verify you are on the authentic weblogin page.

Verify the URL

Web authentication for PennKey credentials should only come from: 

Note: By confirming the trailing / in the domain name, you can ensure you are on a upenn domain. 

Verify you are on a Secure Page

WebLogin will only request your credentials from a secure page. The page URL will always be prefixed with https://. In addition, the WebLogin pages use an extended validation certificate. The display of extended validation certification is different across browsers, but typically have the following qualities:

  1. A text description showing the owner of the certificate: "University of Pennsylvania"
  2. A green color in the address bar.

Below are some examples of extended validation certificate displays in common browsers: 



Google Chrome




Internet Explorer


Problem Logging in?

If you're having trouble logging into an external application or service using SSO, please check your directory settings as a first step:

  • On the directory page login with the button on the top-right.
  • Once logged in, select "My Profile" in the top-right.
  • Review the "Manage Penn Profile" and "Manage Public Profile" sections of the directory.
  • Some services require your e-mail address and/or a first/last name to be released when you login.

If you have elected to withhold your information, you may not be able to log in to some services. Any changes you make to your directory settings will take up to one hour to be available to the SSO system.