^{Last Update: June 19, 2021}

Overview

The purpose of the California Community Colleges Single Sign-on Federation (OpenCCC SSO) is to provide secure, scalable, and integrated technology solutions for the California Community Colleges and its students that take advantage of economies of scale and facilitated by governance from the colleges themselves. The CCC SSO Federation offers a common framework for shared management of access to OpenCCC resources and secure web applications. .

Through partnership with the InCommon Federation, college Identity Providers can give their users single sign-on convenience and privacy protection, while online Service Providers control access to their protected resources.

Contents:

1 Overview
2 Federated Identity Management
3 CCC SSO Federation
4 SSO Proxy

Federated Identity Management

Federated Identity allows the sharing of information about users (students and college faculty/staff) from one secure domain to the other organizations in a federation. This allows for cross-domain single sign-on capability and removes the need for content providers to maintain user names and passwords. Identity providers (IdP) supply user information, while service providers (SP) consume the information and give access to secure content.

Single Sign On (SSO)

Single Sign On (SSO) is a session and user authentication process that permits an end-user to log in to a single portal and access multiple applications seamlessly using only one set of credentials (one username and password) without having to sign-in to each application separately. Single sign-on increases security, reduces multiple login prompts and provides end users with a convenient, usable method of accessing all of their accounts.

For example, when CCC students are configured for SSO, they can login to one application, such as MyPath, the Student Services Portal, and then access multiple different web applications, such as Canvas Course Management System (CMS), CCCAssess, and CCCApply, without having to login to each of the applications individually.

The SSO process involves authentication and authorization. Authentication is a confirmation that the person logging in is the person they claim to be. Authorization is a confirmation that the logged-in person is authorized to access a particular "resource" (i.e. MyPath Portal, etc.). The Tech Center has implemented a SSO proxy process to facilitate streamline integration for current and future applications.

How SSO Works

When a user logs in at their College/District Identity Provider system, the Identity Provider releases basic information about the user to the service providers in the federation so they know "who is logging in". This identity information is sent as a SAML2 assertion. The information in SAML2 assertion is encrypted and only service providers with the CCC Federation are allowed access to the information in the assertion.

At a bare minimum, the SAML assertion must contain the following information (also known as attributes).

What is SAML Protocol?

The Security Assertion Markup Language (SAML) allows for secure authentication between an identity provider and a service provider. SAML facilitates access to the rest of your pre-registered web-based accounts. For example: CCCAssess, MyPath Student Services Portal, CCC Course Exchange, CCCApply, Canvas, Hobson's Starfish, and various cloud-based applications are all easily integrated into SSO by using the SAML protocol.

SAML Attribute Values

The table below displays the "minimum required" SAML attributes that must be configured for your college/district IdP to integrate with the CCC SSO Proxy.

For more information on the SSO Proxy integration requirements, including the SAML attribute configurations for the different IdP solutions, see the The SSO Gateway (aka Proxy) page and view links in the left sidebar.

Minimum Required Attributes for OpenCCC SSO

Simple Name and the SAMLv2 name when sent in the SAMLv2 response	Short description	Sample value(s)	Description

Simple Name and the SAMLv2 name when sent in the SAMLv2 response	Short description	Sample value(s)	Description
eduPersonPrincipalName (EPPN) ^{urn:oid:1.3.6.1.4.1.5923.1.1.1.6}	The primary federated identifier of a given user from a college/district IdP.	jsmith@idp.college.edu	EPPN has the syntax of an email address, but it should be considered a "globally unique federated identifier" rather than an email address. It is generally the most important attribute to be shared with federated services. This value is usually automatically generated by the identity provider. Most typically it made up using the userid the user logged in with combined with the @ sign then the domain name associated with the IDP.
eduPersonAffiliation ^{urn:oid:1.3.6.1.4.1.5923.1.1.1.1}	Role within the college/district	staff student member	All of the roles a given person has within the college.
uid ^{urn:oid:0.9.2342.19200300.100.1.1}	Username	jsmith	This is usually the value that the user fills in as their username when they login.
givenName ^{urn:oid:2.5.4.42}	First Name	Jane
sn (surname) ^{urn:oid:2.5.4.4}	Last Name	Smith
displayName ^{urn:oid:2.16.840.1.113730.3.1.241}	Full name to display	Jane Smith
mail (email) ^{urn:oid:0.9.2342.19200300.100.1.3}	Email Address	jane.smith@college.edu
cccId	Unique id for a student within the CCC system	AXC9876	The CCCID is a critical attribute for students. If the Identity provider cannot provide a CCCID, the SSO Proxy will lookup the users CCCID or prompt the user to recover or create the CCCID if it cannot be found.

Configure Optional Attributes

These are optional attributes that can be sent by the college. One example use is that these can be used to pre-populate values when the user is required to create a central CCCID account.

Simple Name and the SAMLv2 name when sent in the SAMLv2 response	Short description	Example	Notes

Simple Name and the SAMLv2 name when sent in the SAMLv2 response	Short description	Example	Notes
eduPersonPrimaryAffiliation ^{urn:oid:1.3.6.1.4.1.5923.1.1.1.5}	Primary role at the institution	staff student faculty	Must be one of the values specified in eduPersonAffilliation. If the eduPersonAffiliation attribute has many values, the primary affiliation should reflect the role to be associated with services that differentiate based on this value (such as the CCC Portal).
street urn:oid:2.5.4.9	Street address	303 Mulberry St.
locality .... urn:oid:2.5.4.7	City	Metropolis
st .... urn:oid:2.5.4.8	State or Province name	CA
postalCode .... urn:oid:2.5.4.17	Postal or zip code	12345
homePhone .... urn:oid:0.9.2342.19200300.100.1.20	Home Phone Number	+1 212 555 1234
mobile .... urn:oid:0.9.2342.19200300.100.1.41	Mobile Phone Number	+1 775 555 6789

Why implement SSO?

Implementing a SSO solution is a requirement of the CCC SSO Federation and allows participating California Community Colleges to take full advantage of the products and services offered by the CCC Technology Center (CCCTC). SSO allows students, faculty and staff to access these service using the login credentials they already use at the college or district.

CCC SSO Federation

The CCC SSO Federation is a shared federation of California Community Colleges based on a secure single sign-on. Each participating college will be required to stand up a SAML compliant Identity Provider to authenticate their user population to secure CCC web applications services in the SSO Federation. Currently, the CCC Technology Center supports Shibboleth IdP software and Portal Guard IdP; however colleges may choose to use another IdP solution with built-in support services, such as Ellucian. For more information on the IdP solutions supported by the Tech Center, see Supported IdP Solutions below.

Requirements

To participate in the CCC SSO Federation, colleges are required to implement a SAML2-compliant Identity Provider (IdP), become a member of the InCommon Federation; and integrate with the SSO Proxy service, in order to access the full benefits of system-wide single sign-on connectivity for students, staff and faculty across all secure CCC applications. In addition, all CCC-approved vendor applications, such as Canvas and Starfish, will also integrate with the Proxy in order to facilitate single sign-on to those applications, while passing the required attributes for access and reporting (i.e.,, CCCID, EPPN, etc).

Required:

SAML2-compliant Identity Provider (IDP)
Membership with InCommon Federation
Proxy Integration to CCC Applications
Proxy integration to Canvas, Hobsons/Starfish, Others

Optional implementations, but highly recommended:

Integration with the CCC College Adapter (under-development)
MyPath Student Services Portal
CCCAssess
EMSI Career Coach
Canvas CMS
Hobsons/Starfish Degree Audit Systems

Integrating with CCC Applications

Because a student will usually initiate access to central services from their home college web site, and to avoid being presented with a IDP discovery page where the student has to choose from 110+ college/district identity providers, the college will place a specially formatted link on their website to the the targeted service provider. This link will be provided to the college by the CCC Tech Center.

CCC Federation Overview Diagram

The following diagram illustrated the relationship between Identity Providers (IDP), the SSO Proxy, and the Services Providers (SP).

The EPPN

The EduPersonPrincipalName (EPPN) is the unique identifier for a user (applicant, student, faculty, staff) across all college IdPs.

For the the Student population, a Central OpenCCC Id (CCCID) is a unique correlation ID for a single student across the entire CCC system and is a key SAML attribute requirement across all service providers.

Many colleges will be able to lookup the CCCID from their directory servers, but for the colleges that dont store CCCID, the central IdP proxy will be used to lookup the CCCID for a given EPPN and included it in the list of SAML attributes sent to the final Service Provider.

The EPPN has the syntax of an email address, but it should be considered a "globally unique federated identifier" rather than an email address. It is generally the most important attribute to be shared with federated services. Note that the value of EPPN does not have to match what the user fills in as their username when they login, and the user does not need to know what their EPPN is, as it is shared between the IdP and the service. It should be unique, rarely change, and not be reassigned to another user.

The significance of the EPPN to the CCC SSO Federation

The EduPersonPrincipalName (EPPN) is the unique identifier for a user for across all college IDPs.

For the the Student population, an OpenCCC Account Id (CCCID) is a unique correlation ID for a single student across then entire CCC system and is a key SAML attribute requirement across all service providers. Many colleges will be able to lookup the CCCID from their directory servers, but for the colleges that dont store CCCID, the SSO Proxy will be used to lookup the CCCID for a given EPPN and included it in the list of SAML attributes sent to the final Service Provider.

The CCCID

The CCCID is a unique student-identifier generated when an individual (student) creates an OpenCCC account, enabling secure, single sign-on access to admissions applications and other systemwide web-based services. The CCCID is commonly created during the CCCApply admissions application process, however, any existing student can (and should) be encouraged to create an OpenCCC account and thus create their own CCCID.

Some key functions of the CCCID:

The CCCID is generated when a student sets up an OpenCCC account and commonly passed to the college in the CCCApply data download.
The CCCID is then stored in the college’s SIS or college LDAP/Active Directory
The CCCID is passed as an attribute from the college’s IdP to the systemwide applications SP (i.e. Canvas, CCCAssess, MyPath, etc.)
The CCCID is used by the systemwide application to identify the student.

The main linking mechanism between user accounts in the Identity Center and applications and services running in the cloud is the CCCID, a seven character ID composed of three alphabetic characters (A-Z, excluding O and I) and 4 numbers (0-9). This results in an account identifier with more than 130 million combinations that is easy for a person to remember if it was ever necessary. Example: SWD3986

The significance of CCCID for the CCC SSO Federation

The CCCID is used for multiple purposes across the California Community Colleges system. The CCC Chancellor's Office and other systemwide organizations rely on the CCCID to track progress and the educational choices made by student across the course of their academic journey. Students that attend multiple colleges across the system are tracked in one central location (OpenCCC Student Account System) and their CCCID will be used for research (locally and systemwide) to better align support and services across the system.

In order to track students through their CCCID, the objective of the SSO Proxy is to ensure that every CCC student has a CCCID. Therefore, as part of the SSO Proxy integration, it is strongly recommended that colleges store the CCCID in their Active Directory or LDAP directory in order to pass this attribute with the EPPN with the student user session when authenticating to a CCC web application, such as CCCAssess, Canvas and MyPath.

Shibboleth V3 Upgrade

Version 3 of Shibboleth Identity Provider software was released in early 2016, replacing the popular V2 version, completing an end-of-life process on July 31, 2016. No further security updates or bug-fixes will be provided for Shibboleth Version 2.X. Please see this page for more information: End of Life for Shibboleth V2.

The CCC Technology Center (CCCTC) upgraded the OpenCCC student gateway IdP (Shibboleth v.2.4.1, to version 3.1), and the CCCApply staff tools IdP - which authenticates administrator and staff users to the CCCApply Administrator and CCC Report Center, on September 30, 2016.

CCCTC Supports College Upgrades to Shibboleth V3

Colleges using Shibboleth now (to access CCCApply Administrator and/or Report Center) should verify which version they are using and if using version 2.X, should consider upgrading to the latest version. Shibboleth V2 is an unsupported version, and while upgrading to V3 is not required, it is strongly recommended. See below for more information on the benefits and requirements of upgrading the Shibboleth version 3 today!

Assistance is available for colleges that need help upgrading to V3. For more information, please contact Patricia Donohue, Product Manager, pdonohue@ccctechcenter.org.

Upgrade to Shibboleth Version 3

Colleges participating in one or more of the statewide technology initiatives will soon need to go through a readiness process to ensure that their campus system is compatible with the statewide IdP. This includes aligning the IdP and associated applications to support integration with statewide authentication services (SSO) for students and staff.

Colleges that have only one IdP configured for staff (i.e. Shibboleth 2.X for the CCCApply Administrator & Report Center) will be required to upgrade to Shibboleth version 3 in order to facilitate authentication capability for students, as well as admins and staff .

Failure to upgrade to the latest version 3.X of the Shibboleth IdP could result in students losing access to secure CCC web applications within the CCC SSO Initiative, including the new student services portal, MyPath; the common assessment system, CCCAssess; the Hobson's suite of Ed Planning tools; and Canvas, the statewide course management system (CMS).

Benefits of Upgrading

The CCCTC recommends that all colleges using Shibboleth Identity Provider software upgrade to the latest version 3.X in order to take advantage of the many benefits and enhancements it provides:

Improved security
Ease of use and configuration
Decrease in Help Desk calls - fewer passwords to remember
Increased student productivity
Inter-operability and integration with CCC applications

Get Started on Shibboleth Upgrade

Colleges can choose to upgrade Shibboleth on their own (DIY), or work with an approved vendor on this implementation.

Working with an approved vendor may affect your project timeline. Vendors are working with colleges on a first-come, first-served basis; however project pilot colleges may be prioritized depending on the project timeline. Find out more about working with an approved vendor to facilitate your Shibboleth Upgrade. Contact Patricia Donohue, Product Manager, pdonohue@ccctechcenter.org.

Using Different Identity Provider Software?

If your college is not using Shibboleth Identity Provider software, there are other steps you may need to take to ensure your system is compatible with the statewide IdP. Colleges using PortalGuard and other IdP solutions will need to go through a readiness checklist process to ensure they meet the requirements for student authentication per the CCC SSO Initiative.

General Support for Shibboleth

In-house technical support is available for colleges implementing Shibboleth as part of the their implementation of CCC SSO Initiative. Questions regarding other SAML-compliant IdP solutions as they relate to CCC SSO, the proxy, or vendor implementations will be fielded b (IdP) solutions; however, wCCC SSO and the SSO Proxy. See the Support page for contact information and support links.

SSO Proxy

The The SSO Gateway (aka Proxy) is a centralized proxy service through which secure CCC web applications can centralize authentication requests for students and staff across all CCC colleges. The SSO Proxy helps colleges assert consistent SAML attributes to the various Service Providers within the CCC SSO Federation.

The SSO Proxy is also responsible for establishing a link between the students EPPN at the college and the students CCCID when colleges are unable to retrieve the CCCID from their own directory service or student information system.

One of the implementation requirements for the CCC SSO Federation is to connect all college/district IdPs to the proxy to simplify and accelerate system-wide technology adoption and provide uniform experiences for key users. Colleges that have already upgraded their Shibboleth IdP to V3 can be integrated with the proxy at any time.

To get started with the SSO Proxy, see "SSO Proxy Technical Integration Guide" and contact the CCC Proxy Project Team to schedule a kick-off meeting.

Proxy Use Cases

The main proxy use case is when a college is not able to send the CCCID attribute for students when they attempt to authenticate to a CCC web application. If the proxy discovers that the CCCID attribute is not present, it will first attempt to locate the CCCID associated with the IdPs unique identifier (EPPN) for the user.

If a CCCID is not found, the student will be redirected to OpenCCC Account System to either recover (Account Recovery) or create a new OpenCCC account (Account Creation). Once the account is recovered or created, the CCCID will be cross referenced to the student's EPPN so that the next time a student attempts to login to a CCC web application from their college IdP, the proxy will be find the student's CCCID and add it to the SAML attributes presented to other federation service providers.

If the college is able to send the CCCID with the EPPN for that unique student, they proxy will silently send that user forward to their intended destination without presenting the sign-in page. This is a significant benefit for the college (and student) to store the CCCIDs in their Active Directory or LDAP directory. It will minimize need for the proxy and reduce confusion for the student when accessing CCC web applications.

NOTE: The student will only be presented with the OpenCCC sign-in page once, the first time that user attempts to login to a secure CCC application (include Canvas).

SSO Proxy Flow Diagram

This simple diagram illustrates the flow between the college IDP, the SSO Proxy and the final Service Provider.

For more information on SSO Proxy, please refer to CCC Single Sign-On Technical Implementation Guide.

What is the InCommon Federation?

InCommon, operated by Internet2, provides a trust fabric for higher education, their vendors, and partners to facilitate single sign on from local campus accounts. InCommon also operates a related assurance program, and offers security certificate and multi-factor authentication services.

The InCommon Federation enables Identity Providers (IdPs), such as colleges/districts, and Service Providers (SP), such as CCC and vendor applications, to work together to manage access to protected resources, such as student user data. InCommon participant sites use federation-enabled software products, such as the Shibboleth suite or other products supporting the Security Assertion Markup Language (SAML) to accomplish this.

InCommon Overview Video

https://www.incommon.org/

Is it a requirement to join InCommon?

To facilitate our federated identity initiative to allow single sign-on access to all systemwide technology offerings, it is highly recommended that colleges/districts join InCommon Federation in order to secure your protected resources and CCCCO and the CCC Technology Center have put together an agreement for InCommon Membership for all California Community Colleges to be paid centrally moving forward. Ongoing funding for this effort is a part of the Technology Initiatives for Student Success funded by the legislature.

What are the benefits of joining InCommon?

Through InCommon, Identity Providers can give their users single sign-on convenience and privacy protection, while online Service Providers control access to their protected resources. In addition, college/district members can also take advantage of:

Immediate savings on security certificates
Single Sign-On for Higher Education vendors
Single Sign-On for CCC system-wide technology offerings

What is the agreement made between CCC and InCommon?

CCCCO and the CCC Technology Center have put together an agreement for InCommon Membership for all California Community Colleges to be paid centrally moving forward. Ongoing funding for this effort is a part of the Technology Initiatives for Student Success funded by the legislature. Colleges/districts that have already joined InCommon may be eligible for a reimbursement of this year's membership fees.

What does your college/district have to do to join InCommon?

Joining InCommon Federation requires your college/district to identify one or more Site Admins who will be responsible for registering your college/district IdP metadata with the InCommon repository. The process to join InCommon and register your metadata can take place at any time. For all details, please see Joining InCommon Federation.

CCC SSO Federation - Resource Guide