UniversalTemplate/logo.png UniversalTemplate/UTS.png

Authentication Standards for Single Sign On (SSO) Applications

Topic: Using the Single Sign On (SSO) service for your web application

Overview

What is Single Sign On?

Single Sign On (SSO) allows applications at Oakland to utilize users current NetID and password for authentication. This is more efficient and secure for departments, because administrators and super users do not have to create and maintain separate usernames and passwords for various applications, and users cannot access systems after they have left the University. SSO also offers the ability to protect with DUO two factor authentication for Banner administrative applications. Once SSO is configured for an application, administrators and super users do not have to reset end user passwords.

Benefits of using SSO:

  • Standardized Login page that is OU branded.
  • User accounts are automatically deactivated in the application when a NetID is disabled.
  • Improves customer satisfaction.
  • Boosts productivity.
  • Improves compliance and security capabilities.
  • Improved user auditing.
  • Strengthen IT security and control.
  • Enhances user adaptation to applications that OU promotes.

Preferred Technical Integration

The University requires that the proposed solution meet University identity access management standards. Login processes can authenticate using Single Sign On for:

  • InCommon Federation

  • SP(Vendor) can integrate with Shibboleth IDP Version 5.1.2 or higher
    • Standard Attributes being released:
      • givenName urn:oid:2.5.4.42
      • uid (NetID): urn:oid:0.9.2342.19200300.100.1.1
      • eduPersonPrincipalName urn:oid:1.3.6.1.4.1.5923.1.1.1.6
      • cn urn:oid:2.5.4.3 friendlyName="cn"
      • Surname urn:oid:2.5.4.4
      • Mail (email address) urn:oid:0.9.2342.19200300.100.1.3
      • Extra Attributes that can be release upon request
      • eduPersonAffiliation urn:oid:1.3.6.1.4.1.5923.1.1.1.1
      • eduPersonPrimaryAffiliation urn:oid:1.3.6.1.4.1.5923.1.1.1.5
      • eduPersonUniqueId urn:oid:1.3.6.1.4.1.5923.1.1.1.13
      • GrizzlyID friendlyName=”GrizzlyID”
      • "schoolName" Oakland University friendlyName=”schooName”

      • "schoolNumber" 244 friendlyName=”schoolNumber”

  • SAML 2.0 (Must use encryption and signed assertions)
  • CAS protocol 2.0 or higher
  • open LDAP/RedHat Directory Server 11.7 or higher
  • Active Directory

    * ADFS is not an option at this time*

Design Standards

The design standard elements required by Communications and Marketing must follow OU templates.

General rules:

1. Official Oakland University Colors are Pantone 872 Metallic Gold, Black and White.

2. Official Oakland University fonts are ITC Garamond and Helvetica.

3. Any text that says Oakland University, OU, or Golden Grizzlies must be followed by a “TM”.

4. Marks cannot be cropped, skewed, or altered in any fashion.

5. Any item produced using official Oakland University marks or verbiage must be submitted through the Learfield licensing portal.

6. Several marks have specific rules to them. For specific rules, please click on mark below.

You can also visit the Oakland University Style Guide for more direction regarding the guidelines for formulating content.

Compliance with Accessibility Standards

The page must be scanned with ADA tools and corrected if not using Oakland’s main SSO. Websites and web site content must be developed and maintained with attention to accessibility standards and in compliance with Section 504 and 508 of the Rehabilitation Act, the Americans with Disabilities Act, and university non-discrimination policies. All websites to the extent feasible, must be made accessible to people with disabilities. If it is not feasible, alternative methods must be made available to complete the same tasks. Compliance with the WCAG Standard 2.0 Level AA (including Level A) standard is required.

For more information on Accessibility Guidelines visit:

https://kb.oakland.edu/uts/Accessibility_Efforts_and_Toolkits

Application Administrator or Super Users responsibilities for new applications

The application administrator or super users will be responsible to verify or add users, and assign the appropriate roles or security to each application that utilizes SSO. The only ongoing maintenance is that you may need to continue to add any new users and roles if the application does not auto provision the accounts and remove users when applicable.

UTS will coordinate a test with the vendor and department to test authentication after initial installation and configuration of SSO.

How do I migrate my existing application to authenticate to SSO?

Create a UTS project ticket by emailing [email protected] with the answers from the questions below:

  • Does the vendor application support Shibboleth (SAML 2.0) or CAS Protocol?
  • If you require the CAS protocol, which version do you require?
  • Work with your vendor to determine if they will charge you any fees to migrate.
  • Obtain the vendor contact information for technical support.

UTS will work with the vendor to share technical requirements to establish the SSO authentication process.

UTS will coordinate a test with the vendor and department to test authentication.

References