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.
Purdue 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 are 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.
CAS 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 visit the Centralized Authentication Service (CAS) page
If your application cannot support CAS or SAML, and the application is hosted on a Purdue network, we can offer LDAP.
Click to learn more about IAMO LDAP Authentication Service.
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.
The I2A2 legacy services have been deprecated. As of March 1, 2019, new connections to I2A2 services will not be created. We are working with current customers of I2A2 services to transition them to one of the services above. Information about the legacy I2A2 services is available here:
If you have any questions, please contact firstname.lastname@example.org.
- Identity and Access
- Purdue OID
- Purdue University Identification
- Guest Access Application
- Account Setup Reset Application
- Security Policy/Procedures Exceptions
- InCommon Service
- InCommon Certificate Service
- Alertus Desktop Client Information
- Purdue Shibboleth Service Information
- Authentication Options
- Student Organization Accounts