...
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.
...
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 C and F below in order to integrate with the 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.
...
A. Understand and make sure you have the following attributes available
These attributes are described in more detail in the accompanying wiki page entitled "CCC Attributes for 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".
...
| 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. |
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 the role to be associated with services that differentiate based on this value (such as the CCC Portal). |
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 | |
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 | 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. |
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 |
|---|---|---|
cccMisCode | The MIS code assigned to a college by the CCC. If a IdP is for the district, and represents multiple colleges, each with their own MIS code, the IdP could send the district MIS code as a default. | 123 |
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 |
...
B: Configure your Identity Provider (IdP) to Release the Above Attributes to the CCC SSO Proxy
| Note |
|---|
| If you are running a Shibboleth IdP v3 server, with the configuration changes made by Unicon, you won't need to add the following. |
...
| Code Block |
|---|
<!-- Pilot CCC IdP Proxy Metadata, locally maintained -->
<MetadataProvider id="CCCIdPProxyPilot" xsi:type="FilesystemMetadataProvider"
metadataFile="%{idp.home}/metadata/ccc-idp-proxy-pilot-metadata.xml"/>
<!-- Production CCC IdP Proxy Metadata, locally maintained -->
<MetadataProvider id="CCCIdPProxyProduction" xsi:type="FilesystemMetadataProvider"
metadataFile="%{idp.home}/metadata/ccc-idp-proxy-production-metadata.xml"/> |
...
F: Test Your PILOT Implementation
Once all the above steps have been completed in Pilot, you can test by using the following URLs. Once the college/district and the CCC IdP Proxy Service Team agree that all is working as it should with the Pilot integration, then the college/district and the CCC IdP Proxy Service Team can move on to Production.
...