Integrate IU Login with a web application

On this page:


Overview

At Indiana University, you can integrate IU Login into your web application to provide single sign-on authentication. There are two primary options for applications to integrate: using the CAS protocol or the SAML protocol.

Important:

The CAS software, which has been synonymous with authentication at IU, is distinct from the CAS protocol. Most existing applications use the SAML protocol to integrate with the CAS software (via Shibboleth). If you have integrated with CAS in the past, do not assume that your application will need to connect with the CAS protocol.

Note:
To stay informed or provide feedback about IU Login, or to ask questions about developing with it, use the auth-discuss-l mailing list. To subscribe, send email to auth-discuss-l-subscribe@iu.edu.

Guidelines for choosing a protocol

To help you determine which authentication solution best suits the requirements of your service, UITS offers the following guidelines.

Your primary consideration should be 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.

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

This is document atfc in the Knowledge Base.
Last modified on 2020-06-08 11:07:07.

Contact us

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