Towson University has implemented a Shibboleth Identity Provider to provide external service providers (those hosting services outside of the Towson University network) a secure way for faculty, staff and students to authenticate to the service using their university NetID. In its simplest form, this service provides a Towson University login web page for non-Towson University web sites. Browser cookies must be enabled for this service.

The Shibboleth software allows identity providers (those who "own" the accounts) and service providers (the web site external to the university) to interoperate. It is standards-based and used by a growing number of universities. The Shibboleth software is described in detail at http://shibboleth.internet2.edu/about.html.

Individual service providers must register with the Office of Technology Services so that they can properly communicate with the university's Identity Provider; the request process is described below.

To see a sample login page, faculty, staff and students can log into a "test" service provider by clicking here. (This test login is safe. After logging in, close your browser completely in order to log out.)

A university department who is working with a vendor to provide an externally-hosted web service to faculty, staff or students may benefit for this service. The university department/contact person must confirm with the vendor that the vendor's service will support a "Shibboleth Identity Provider." If the vendor supports Shibboleth, then the department can submit a request to OTS via the OTS Help Center to have a new service provider configured for the university's Shibboleth service. The following information should be provided in the request:

• Information from the university department:
  • What is the purpose and description of the service (i.e., the nature of the external web site)?
  • What is a "friendly name" for the service that can appear on the login web page?
  • Who are the university contact person and department for this request?
  • What is the expected usage of the service (e.g., who will be using the service, expected volume of usage, times of day when most frequently accessed)?
  • In some cases, the vendor's web site might redirect a user to a specific web site when that user logs out of their service; if the vendor offers this, is there a particular web site to which users should be sent when they log out (e.g., the department's web site)?
• Information from the vendor:
  • Please note that the vendor should review the FAQ section below, as it addresses most questions.
  • What attributes are expected from Towson's Identity Provider (e.g., first name, last name, e-mail address)? The attributes Towson currently provides by default are listed in the FAQ below. Towson cannot guarantee that additional attributes can be presented.
  • What is the URL to the service providers' metadata (entity descriptor)? If the metadata is not available on the Web, then it must be supplied as a file to OTS (after OTS follows up with the university contact person).
  • Are you a member of InCommon?
  • What is the vendor's contact information for follow-up by OTS? This may be used when initially configuring the new service and performing testing.
  • What is the URL to the web page that will allow OTS to test a login while configuring the service? Will this web page always be available to allow OTS to test logins, in the event that troubleshooting/monitoring is being performed?

The request will be referred to the appropriate workgroup in OTS, who will follow up with the university contact for additional information and/or to set up a conference call with the vendor.

The vendor should be referred to this web page for additional details (see FAQ section below), including specific details about Towson's implementation of the Shibboleth Identity Provider and limitations that might affect the vendor's service.

Below are some frequently asked questions, for both vendors and university staff:

• Q: I am unable to log in. How can I resolve the problem?
  A: There are a few tips to avoid common issues with the login process. First, ensure that browser cookies and JavaScript are enabled. Second, avoid using the Back button during the login process. Also, students, faculty and staff should use their NetID (username), not an e-mail address, when logging in. If you are receiving an error message that your username or password may be incorrect, then try logging into another university service (e.g., e-mail) to ensure that the username and password are correct, and that the account is not locked out. If you are still unable to log in, ensure that the service provider (vendor) web site is online. If you are still unable to log in, you may contact OTS for assistance. OTS regularly monitors its Shibboleth service.

• Q: After logging in and using an application, how can I be sure that I've completely logged out of the application?
  A: Many web applications may have a "Logout" link, but the Towson University Shibboleth Identity Provider and your browser still "think" you're logged in using your Towson NetID; therefore, if you click a "Login" link on the web application again, you may be automatically logged back in. There is currently no ability to "log out" of Shibboleth completely, except by closing all of your browser windows. Closing your browser completely is good practice for any web application, particularly if you're using a public computer.

• Q: I am a vendor. Do you offer a "Single Log Out" (SLO) service?
  A: The Shibboleth Identity Provider software currently does not offer "Single Log Out" capabilities (which would allow a user to be immediately logged out of every service to which they've logged in). Towson currently has no plans to implement any such feature. Users are asked to rely on each service provider's "logout" feature.

• Q: I am a vendor. Do you filter which users can authenticate through the Identity Provider, or offer any authorization capabilities per service?
  A: Towson currently does not filter users in any way -- any individual with a Towson University NetID (account) can authenticate through the Shibboleth Identity Provider. Authorization/filtering of users is left up to each vendor.

• Q: For how long do I stay logged in?
  A: Towson uses the default "timeout" value of 30 minutes, but each vendor can configure their service to have a longer timeout value. Towson's timeout value simply means that if a service doesn't "remember" that a user has logged in, and checks with Towson's Shibboleth Identity Provider after 30 minutes to see if that user has already logged in, the user will be required to log in via the web page again. Unless the vendor configures their service otherwise, closing the browser completely will always log a user out of the service.

• Q: I am a vendor. Where is the metadata for the university's Shibboleth Identity Provider?
  A: Towson provides its metadata (entity descriptor) at: https://shib.towson.edu/idp/shibboleth. This address can be used for a file-backed URL metadata resource. The entityID for the university's Identity Provider is "https://shib.towson.edu/idp/shibboleth".

• Q: I am a vendor or a member of the InCommon Federation. Is Towson a member of InCommon, and can InCommon federation members rely on Towson's Identity Provider automatically?
  A: Towson University has joined the InCommon Federation, and should have its identity provider published by early Summer 2012. Any service provider who is a member of InCommon must still follow the request process described above in order to use Towson's Identity Provider. Towson University's federation Participant Operating Practices (POP) document is available HERE.

• Q: I am a vendor. I need an account to test the Shibboleth authentication process.
  A: Towson University can provide an "affiliate NetID" for testing. Vendors already working with a member of the university’s Office of Technology Services (OTS) should send a request for an “affiliate account for testing” through that contact, and indicate whether the account is temporary or permanent. Otherwise, vendors should send the request to their university contact person, who can relay them to OTS.

• Q: I am a vendor. What attributes are presented to an external service?
  A: As of Spring 2011, the following attributes are presented to all services:

  Attribute Name	Description	Details
  uid	NetID (username)	A short, alphanumeric username identifying the user, which is what each user will use when logging in through the Identity Provider
  mail	E-mail address	The full, primary e-mail address of the user
  sn	Last name (Surname)	Last name of the user, with correct capitalization and punctuation
  givenName	First name	First name of the user, with correct capitalization and punctuation
  displayName	Full name	Full name of the user, in the format of "Last name, First name" with the occasional middle initial for faculty/staff
  eduPersonAffiliation	How the user is related to the university	One or more short descriptions of the user's affiliation with the university. Possible values include: faculty, student, student, affiliate (e.g., vendor), member (every NetID is at least a "member"). Follows the eduPerson standard at http://middleware.internet2.edu/eduperson/.
  eduPersonPrimaryAffiliation	The primary way in which the user is related to the university	A short descriptions of the user's primary affiliation with the university. Possible values include: faculty, student, student, affiliate (e.g., vendor), member (every NetID is at least a "member"). Follows the eduPerson standard at http://middleware.internet2.edu/eduperson/.
  eduPersonScopedAffiliation	How user is related to the university	Identical to eduPersonAffiliation above, except that all affiliations will end with @towson.edu. Follows the eduPerson standard at http://middleware.internet2.edu/eduperson/.
  eduPersonPrincipalName	The NetID (username) with towson.edu scope	Identical to the user's "uid" attribute above, with the @towson.edu suffix (scope). Follows the eduPerson standard at http://middleware.internet2.edu/eduperson/.
  transientId	A temporary, unique ID for the login session	This is a standard Shibboleth attribute used for tracking logins.

  
  

• Q: I am a vendor. My solution requires additional data (attributes) not listed above.
  A: This will require collaboration with the university's Office of Technology Services (OTS). If it is possible to create a new attribute that can be easily supported or provides a potential benefit to multiple service providers, then OTS may choose to build and release that attribute. However, if that's not an option, then a secure FTP-based solution may be an option for synchronizing additional data, while still leveraging Shibboleth for authentication.

• Q: I am a vendor, and cannot support Shibboleth. Is there another alternative (e.g., LDAP) for an external service to authenticate users using Towson University NetIDs?
  A: Shibboleth is the preferred authentication solution for all off-campus services that support it, rather than relying on an LDAP/directory service. If an off-campus vendor supports Shibboleth, then that option must be used over an LDAP solution, even if there is a cost associated with it. Shibboleth is a much more secure alternative to providing direct LDAP access.
  
  If an off-campus service still needs access to an LDAP/directory service for directory synchronization purposes, then a secure FTP-based solution may be an option for synchronizing data, while still leveraging Shibboleth for authentication. If an off-campus vendor does not support Shibboleth, then a request to use the university's LDAP service may be made and must be reviewed by the university's Office of Technology Services (OTS); SSL will be required, and a specific IP address (or small range of IP addresses) must be specified for "whitelisting" in the university's firewall. OTS can provide instructions.
  
  On-campus solutions (applications hosted on servers running in the university's data center) may use the LDAP service. OTS can provide instructions.
  
  Vendors already working with a member of OTS should send questions about LDAP through that contact. Otherwise, vendors should send questions to their university contact person, who can relay them to OTS.