Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 34 Next »

This document is being worked on as we speak.

Overview

The purpose of the California Community Colleges Single Sign-on Federation (CCC SSO) is to provide secure, scalable, and integrated technology solutions for the California Community Colleges 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 CCC 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.


Federated Identity Management

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

What is Single Sign On (SSO)?

Single Sign On (SSO) is a session and user authentication process that permits a user to enter one username and password - one time - in order to access multiple applications without having to sign-in to each application separately. 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 separately to each of the applications. 

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. 

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.

 

How SSO Works

When a user logs in at the College/District Identity Provider, the Identity Provider will release 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 most contain the following information (also known as attributes).

SAML Attribute Values

Simple Name and the SAMLv2 name when sent in the SAMLv2 responseShort descriptionSample value(s)Description

eduPersonPrincipalName (EPPN)

 

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

 

Role within the college/district
  • staff
  • student
  • member

All of the roles a given person has within the college.

eduPersonPrimaryAffiliation

 

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).

uid

UsernamejsmithThis is usually the value that the user fills in as their username when they login.

givenName

First NameJane 

sn (surname)

Last NameSmith 

displayName

Full name to display

Jane Smith 

mail (email)

 

Email Addressjane.smith@college.edu 

cccId 

Unique id for a student within the CCC system AXC9876The 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.

 

 

CCC SSO Federation

The CCC SSO Federation is a shared federation of CCC colleges. College applicants, students, staff and faculty will be using the Student Portal, Report Center, Hobsons and Canvas as well as other CCC managed and external services.

Each participating college will be required to provide a SAML compliant Identity Provider to authenticate their user population to these services. Currently, the CCC Technology Center supports Shibboleth IdP software and Portal Guard IdP.  For more information, see "Support SSO Solutions".

At this time, all California Community Colleges already have an Identity Provider (IdP), such as Shibboleth or Portal Guard, in place to authenticate college staff to the CCCApply Administrator and the CCC Report Center.  However, to allow students to access the rich portfolio of student services web applications - existing or under-development  by the CCC Technology Center - colleges must either install a supported SSO solution that includes student attributes or upgrade their existing IdP to allow students to access the resources within the CCC SSO Federation.

Requirements for SSO Federation

To participate in the CCC SSO Federation, colleges will be 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 facilitate the full benefits of system-wide single sign-on connectivity for students, staff and faculty across all secure CCC applications. In addition, any vendor applications, such as Canvas and Hobsons, will also need to 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.

 

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 following diagram illustrated the relationship between Identity Providers (IDP), the SSO Proxy, and the Services Providers (SP).

CCC Federation Overview Diagram

 

What is the CCCID?

A CCCID is a unique student-identifier generated when an individual 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 admissions application process known as CCCApply, however, any existing student can (and should) be encouraged to create an OpenCCC account and thus create their own CCCID, explained Lou Delzompo, Chief Technology Officer of the CCC Technology Center.

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.



Supported IdP Solutions

To participate in the CCC SSO Federation, colleges must implement a SAML2-compliant Identity Provider (IdP) solution that meets the minimum requirements of the Federation. The CCC Tech Center currently supports Shibboleth and Portal Guard IdP solutions for student, staff, and faculty SSO. Colleges using an alternate solution should review the SSO Proxy IdP Requirements to ensure your solution is meeting the requirements necessary to integrate with CCC system-wide applications. 


What is Shibboleth IdP?


Shibboleth Identity Provider is the most widely used SAML2 compliant identity provider in higher education and is a supported SSO solution of the CCC SSO Federation. It allows sign in using just one identity (username and password), connecting users to applications both within and between federations of organizations and institutions.


The Shibboleth Internet2 middleware initiative created an architecture and open-source implementation for identity management and federated identity based authentication and authorization (or access control) infrastructure based on Security Assertion Markup Language (SAML).



What is Portal Guard IdP?

Portal Guard Identity Provider Software is a single sign-on (SSO) login system, similiar to Shibboleth, however...


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. 

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.

SSO Proxy

The SSO 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 on your proxy implementation, 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 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 to either recover or create a new OpenCCC account.  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.


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 SSO Proxy Technical Implementation Guide

What is 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

 

Coming soon...

College Adaptor Installation

Mini-Grant Funding

  


  • No labels