Steps to Integrate with the CCC SSO Proxy
This guide provides step-by-step instructions for integrating with the CCC SSO Proxy service and should be used in conjunction with the /wiki/spaces/CSF/pages/137363670 to ensure all technical and operational requirements have been met. The process can also be visualized on the Proxy Integration Workflow diagram.
Contents:
- 1 Configuring Your College/District IdP to Release Attributes to the Proxy
- 1.1 STEP 1: Understand and make sure you have the following attributes available
- 1.2 Minimum Required Attributes
- 1.3 STEP 2: Schedule kick-off call with the SSO Integration Team
- 1.4 STEP 3: Configure your Identity Provider (IdP) to release the above attributes to the CCC SSO Proxy
- 1.5 STEP 4: Configure your Identity Provider to consume the metadata for the CCC SSO Proxy
- 1.6 Optional Step
- 1.7 STEP 5: Add the Proxy metadata to your college/district IdP
- 1.8 STEP 6: Coordinate with Unicon to add your IdP metadata to the SSO Proxy
- 1.9 STEP 7: Test Your Proxy Integration in the PILOT Environment
- 1.10 STEP 8: Make appropriate metadata changes in Proxy Production environment and test
- 2 CCCApply Proxy Integration
- 3 CANVAS Proxy Integration
- 4 Hobson's Starfish Proxy Integration
- 5 CCC Applications Through Proxy Testing
Overview
The CCC SSO Proxy service was created to accomplish several things:
Provide a way to add the user's CCCID attribute to the SAML response to a service, even if the college was not able to provide one
Provide a central management point where new services could be integrated without each college needing to make any changes to its local college IdP in order to access that new service
Instead of the SAML response from the college/district IdP going directly to the service (e.g. Canvas, Assess), it goes first to the SSO Proxy (which has it own "internal" SP). The Proxy can add attribute(s) to it if needed (e.g. CCCID), filter the attributes received down to the specific attributes needed by the particular service, and send a SAML response back to the service.
This simple diagram illustrates what this looks like:
Once your college/district IdP is configured to release a "master bundle of attributes" to the CCC SSO Proxy, that IdP won't need to be changed to be used with a new service, because all the needed changes will be made within the proxy itself. The only exception would be if an entirely new attribute was needed for a service beyond the set documented below, in which case the college/district IdP would need to be updated to release that attribute to the proxy.
The CCC SSO Proxy is under the management of the CCC Technology Center. No attribute values will be stored, saved, or logged by the proxy, and only the needed attributes will be forwarded in the response to the service.
Configuring Your College/District IdP to Release Attributes to the Proxy
Integrating your college/district IdP with the proxy is essentially the same steps you would follow to integrate with CCCApply, only there is a wider set of attributes that are required and/or potentially useful (optional). Basically, the idea is that the set of attributes released to the proxy is the full set of any attributes that any federated service needs. The proxy will take care of filtering that set down to what is needed for any given service. And just like with CCCApply, there is both a Pilot and Production environment for the proxy. You will integrate first with the Pilot environment, and then with Production.
Note: if you are running Shibboleth IdP v3 software with the standard configuration that Unicon has been putting into the IdPv3 installs, you only need to perform Steps 3 and 6 below in order to integrate with the SSO Proxy. Your IdP has already been configured to consume both the metadata for the proxy – contained within the CCC central metadata file distribution (ccc-metdata.xml) – and the attribute release rules needed for the proxy, contained within the CCC central attribute filter file (attribute-filter.ccccentral.xml). Otherwise, you need to perform all of the following steps.
STEP 1: Understand and make sure you have the following attributes available
These attributes are described in more detail in the accompanying wiki page entitled "Attributes for CCC SSO Federated Access". In particular, the critically important eduPersonPrincipalName (EPPN) attribute is described more fully in that wiki page. A few sample definitions of creating, or "resolving", these attributes in a Shibboleth IdP v3 server can be found on the wiki page "Shibboleth IdP v3 Attribute Resolver Configuration".
The eduPerson schema ( http://software.internet2.edu/eduperson/internet2-mace-dir-eduperson-201602.html ) has a more detailed description of many of these attributes and their intended meaning and purpose.
Minimum Required Attributes
These are REQUIRED attributes that must be sent by the college.
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. | 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 person. | |
eduPersonAffiliation urn:oid:1.3.6.1.4.1.5923.1.1.1.1 | Role within the institution |
| All of the roles a given person has within the college. This is the only attribute listed here that is intended to have multiple values. All the rest are expected to have a single value. |
cccId | Unique id for a student within the CCC system | The CCCID is a critical attribute for students. If not specified, but required for a portal or service action, the CCCID will be looked up via the EPPN. If no match is found, the action cannot be performed until the user creates a CCCID via the OpenCCC portlet. | |
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. If you are using AD, the usual attribute you want to use to populate uid is the sAMAccountName attribute. |
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 | Required for display |
mail (email) urn:oid:0.9.2342.19200300.100.1.3 | Email Address | jane.smith@college.edu |
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 |
|---|---|---|---|
eduPersonPrimaryAffiliation urn:oid:1.3.6.1.4.1.5923.1.1.1.5 | Primary role at the institution |
| Must be one of the values specified in eduPersonAffilliation. If the eduPersonAffiliation attribute has many values, the primary affiliation should reflect primary the users primary affiliation. i.e. a teacher aid may be a student and staff, but their primary role is a student. |
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 |