ARCHIVED: CAS or SAML authentication for web applications

This content has been archived, and is no longer maintained by Indiana University. Information here may no longer be accurate, and links may no longer be available or reliable.

On this page:


Overview

At Indiana University, you can integrate CAS or SAML 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 Systems (IMS) offers these guidelines.

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:

  • SAML can return more user attributes and may already be supported by your application.
  • 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).
    Note:
    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:

Protocol User attributes returned Configuration required Accounts supported Protocols supported
CAS
Username only; however, you can use the username to return more information by querying ADS using LDAP
Requires no extra software
Works for all university and email-based guest accounts
Supports CAS 2
SAML
ePPN (eduPersonPrincipalName) is returned by default (for example, username@iu.edu); other attributes are available by request
Configuration is more involved; service provider needs to be configured on the client side
Works for all accounts (university, email, and social-based guests)
Supports SAML 1 and SAML 2, and features up to Shibboleth 3.4

Use case scenarios

These two common use case scenarios 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.

This is document bdaf in the Knowledge Base.
Last modified on 2019-12-13 08:04:31.