CAS or Shibboleth authentication for web applications

On this page:


At Indiana University, you can integrate CAS or Shibboleth into your web application to provide single sign-on authentication for its users.

To help you determine which authentication solution best suits the requirements of your service, UITS Identity Management Services (IMS) offers the following guidelines, plus a decision tree based on two common use case scenarios.

If you have questions, or need further help deciding, contact your campus Support Center.

Guidelines for choosing a single sign-on solution

Your decision should take into account the number and type of user attributes your service needs to retrieve; for example:

  • Shibboleth can return more user attributes, but is more complex to set up.
  • CAS can return only the username attribute; however, this may be sufficient if your service doesn't rely on other attributes, or if you plan to retrieve required attributes using another method (such as querying ADS using LDAP or referencing your own database).
    With CAS authentication, certain types of information are restricted to allow all-or-nothing access only (for example, to see a person's address, you must have access to everything else in that group).

Use the following table to compare how each solution accommodates select requirements your service may have:

Service User attributes returned Configuration required Accounts supported Protocols supported
Username only; however, you can use the username to return more information by querying ADS using LDAP
Requires no extra software Works for all accounts
Supports only custom IUCAS, CAS 1, and partial CAS 2
ePPN (eduPersonPrincipalName) is returned by default (for example,; other attributes are available by request
Configuration is more involved; service provider has to be set up on the client side
Works for IU accounts only (no guest accounts)
Supports SAML 1 and SAML 2, and features up to Shibboleth 2.4

Use case scenarios and decision tree

Following are two common use case scenarios that may help clarify your options. These are only two of many possible scenarios, and they're intended only to give you an idea of what you may or may not need, and the steps you should take:

  • Scenario 1: You are developing an application for higher education; specifically, online rentals and PDF downloads of books for students. You currently have no data about potential users, but you want to specify that your application is available to active IU students only (that is, and not to faculty, staff, guests, or others). This would necessitate the use of attributes to pull that data.
  • Scenario 2: You are creating an application that lets certain faculty follow and review problem tickets for the IT department. You already have a database from the IT department that contains the user information you need (for example, usernames), so you need only to identify the individuals to whom you want to grant access by pairing each user in the directory with a two-factor password.

Choose the use case that bears the closest resemblance to yours, and then refer to the CAS/Shibboleth Decision Tree to see the benefits and drawbacks of each solution.

This is document bdaf in the Knowledge Base.
Last modified on 2019-07-02 11:05:34.

Contact us

For help or to comment, email the UITS Support Center.