Authentication Options (in order of preference)Our authentication and authorization services are designed to meet different goals. How do you know which one it right for your project? The information below is intended to help you determine which one is right for your application or service.
SAMLPurdue runs a Shibboleth SAML Identity Provider (IdP). Deployment details and how to request access can be found here. Our IdP uses CAS for its authentication, so the user experience is equivalent to CAS, there's just a few extra browser redirects going on under the covers.
Here are some advantages of SAML over CAS for integrations:
- SAML attribute release is customized for your application's needs. With CAS it's currently one size fits all, we send puid/login/name/I2A2 characteristics. With SAML, we can support a wide array of attribute release.
- An application with SAML integration is already prepared to run in the cloud. CAS is generally not an option for applications hosted off campus (and LDAP is not an option for off campus).
- There is no need to authorize CAS ticket checks, either via the current ip address method (or later when we roll out CAS authorization via application url).
- There is two factor support. By default CAS allows two factor to be used, but the IdP can be optionally configured to deny authentication to a particular application if the user is not authenticated via two factor.
- There is additional authorization support. We can assert custom authorization attributes to your particular application to represent its roles. We can calculate custom attributes based on any combination of I2A2 characteristics as well as other data loaded into our system.
- Real long term, *everything* should be SAML, and nothing would be CAS except the Shibboleth IdP itself.
CASCAS is our recommended authentication and authorization service for all web-based applications that are not compatible with SAML. It provides a Single Sign-On (SSO) experience for Purdue users along with all applications configured for SAML or CAS.
To learn more about Purdue's Centralized Authentication Service (CAS) - including a link to the required Service Level Agreement (SLA) needed to add your server to use CAS, please click the Centralized Authentication Service (CAS) page.
LDAPIf your application cannot support CAS or SAML, and the application is hosted on a Purdue network, we can offer LDAP.
To learn more about IAMO LDAP authentication service, click here.
To request access to the IAMO LDAP authentication service, you will first need to fill out a Service Level Agreement (SLA) between your group and the IAMO. Please fill out section VII Client Definitions: section A, VIII Signatures: section A and IX Appendix A: sections A, B, C D and E. In section C, make sure you check LDAP authentication. Please allow 3-5 business days for processing.
I2A2I2A2 stands for Infrastructure for Identification, Authentication and Authorization (I2A2). To read more about Purdue's implementation by reading Infrastructure for Identification, Authentication and Authorization (I2A2). The most common use of I2A2 is the I2A2 LDAP interface.
We will continue to offer I2A2 access, although at some point we will need to begin phasing out its use. We strongly recommend configuring new applications using one of the above non-I2A2 options, and reserve future I2A2 use for applications already built to use it. To request access to Purdue's I2A2 implementation, you will first need to fill out a Service Level Agreement (SLA) between your group and the IAMO. Please fill out section VII Client Definitions: section A, VIII Signatures: section A and IX Appendix A: sections A, B, C D and E. In section C, make sure you check I2A2. Once you have this filled out, forward the hard copy to: IAMO Director / ITAP / ROSS. Please allow 3-5 business days for processing.
If you have any questions, please contact firstname.lastname@example.org.