Contents:

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. 

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.

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

Minimum Required Attributes

These are REQUIRED attributes that must be sent by the college. 

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.

STEP 2: Schedule kick-off call with the SSO Integration Team 

At this point, before you can do some of the following steps, you need to contact the SSO Integration Team to tell them that you are ready to add your college/district IdP to the SSO Proxy. There are several steps that the team needs to take to configure the SSO Proxy to be "ready" for the college/district IdP, and those need to happen before you download the metadata in the next step. Integration will start with the Pilot Proxy, and once that integration is successfully verified, then integration will move on to the Production Proxy.

The SSO Integration Team will also ensure, as part of this step, that they have obtained a copy of your college or district IdP metadata. Just as with CCCApply, the Proxy will need that metadata to be able to interact with your IdP.  If you have registered your college/district IdP with InCommon, the metadata can be obtained by the SSO Integration Team through InCommon. If not, and you are running the Shibboleth IdP, the right metadata may be available in the IdP's file metadata/idp-metadata.xml. Otherwise, you will need to work with the SSO Integration Team to get your metadata to them.

STEP 3: Configure your Identity Provider (IdP) to release the above attributes to the CCC SSO Proxy

Based on the IdP solution you are running, a few configuration changes need to be made to your IdP.  

• Portal Guard IdP - instructions can be found at Attributes for the SSO GW: Portal Guard

• Ellucian IdP -  instructions can be found at Attributes for the SSO GW: Ellucian

• Shibboleth IdP - (See instructions below.)
  

For Shibboleth IdP

The new IdP v3 config that has been put in place includes consuming a CCC system-wide, centrally managed "attribute release file" (a central attribute-filter.xml file) from a HTTPS URL (with checking that the certificate matches for security.) The IdP automatically checks for updates for that file and if changes have been found will reload the file.  That "CCC-wide central attribute-filter.xml file" already contains the following attribute release rules for the proxy. You can tell if your IdP has that file by checking in the IdP's conf/ directory for the file 'conf/attribute-filter.ccccentral.xml'. Otherwise, add the following to the IdP's conf/attribute-filter.xml file, or however you configure attribute release in whatever SAML IdP software that you are using.
 

<!-- 
     Release all required and optional attributes, for any service, 
     to the CCC IdP Proxy, so it in turn can release only the
     needed attributes to the services on the other side
     of the IdP Proxy. All attributes will not be sent to all services,
     just the needed ones for a given service. The attributes here should
     constitute a "union" of all possible attributes for any service.
-->
<AttributeFilterPolicy id="CCCWideReleaseForIdPProxy">
	<PolicyRequirementRule xsi:type="OR">
		<Rule xsi:type="Requester" value="https://sso.pilot.cccmypath.org/simplesaml/module.php/saml/sp/metadata.php"/>
		<Rule xsi:type="Requester" value="https://sso.cccmypath.org/simplesaml/module.php/saml/sp/metadata.php"/>
	</PolicyRequirementRule>
	<AttributeRule attributeID="eduPersonPrincipalName">
		<PermitValueRule xsi:type="ANY"/>
	</AttributeRule>
	<AttributeRule attributeID="uid">
		<PermitValueRule xsi:type="ANY"/>
	</AttributeRule>
	<AttributeRule attributeID="email">
		<PermitValueRule xsi:type="ANY"/>
	</AttributeRule>
	<AttributeRule attributeID="givenName">
		<PermitValueRule xsi:type="ANY"/>
	</AttributeRule>
	<AttributeRule attributeID="surname">
		<PermitValueRule xsi:type="ANY"/>
	</AttributeRule>
	<AttributeRule attributeID="displayName">
		<PermitValueRule xsi:type="ANY"/>
	</AttributeRule>
	<AttributeRule attributeID="eduPersonAffiliation">
		<PermitValueRule xsi:type="OR">
			<Rule xsi:type="Value" value="faculty" ignoreCase="true"/>
			<Rule xsi:type="Value" value="student" ignoreCase="true"/>
			<Rule xsi:type="Value" value="staff" ignoreCase="true"/>
			<Rule xsi:type="Value" value="alum" ignoreCase="true"/>
			<Rule xsi:type="Value" value="member" ignoreCase="true"/>
			<Rule xsi:type="Value" value="affiliate" ignoreCase="true"/>
			<Rule xsi:type="Value" value="employee" ignoreCase="true"/>
			<Rule xsi:type="Value" value="library-walk-in" ignoreCase="true"/>
		</PermitValueRule>
	</AttributeRule>
	<AttributeRule attributeID="eduPersonPrimaryAffiliation">
		<PermitValueRule xsi:type="ANY"/>
	</AttributeRule>

	<!-- CCC specific attributes -->
	<AttributeRule attributeID="cccId">
		<PermitValueRule xsi:type="ANY"/>
	</AttributeRule>
	<AttributeRule attributeID="cccMisCode">
		<PermitValueRule xsi:type="ANY"/>
	</AttributeRule>

	<!-- Less likely attributes to be populated, but release if available -->
	<AttributeRule attributeID="mobileNumber">
		<PermitValueRule xsi:type="ANY"/>
	</AttributeRule>
	<AttributeRule attributeID="homePhone">
		<PermitValueRule xsi:type="ANY"/>
	</AttributeRule>
	<AttributeRule attributeID="telephoneNumber">
		<PermitValueRule xsi:type="ANY"/>
	</AttributeRule>
	<AttributeRule attributeID="postalAddress">
		<PermitValueRule xsi:type="ANY"/>
	</AttributeRule>
	<AttributeRule attributeID="street">
		<PermitValueRule xsi:type="ANY"/>
	</AttributeRule>
	<AttributeRule attributeID="locality">
		<PermitValueRule xsi:type="ANY"/>
	</AttributeRule>
	<AttributeRule attributeID="stateProvince">
		<PermitValueRule xsi:type="ANY"/>
	</AttributeRule>
	<AttributeRule attributeID="postalCode">
		<PermitValueRule xsi:type="ANY"/>
	</AttributeRule>
</AttributeFilterPolicy>

STEP 4: Configure your Identity Provider to consume the metadata for the CCC SSO Proxy

The new IdP v3 config that has been put in place includes consuming a CCC system-wide, centrally managed digitally-signed metadata file from a URL (with verification of the signature for security.) The IdP automatically checks for updates for that file, and reloads it if such have been made.

The "CCC-wide central metadata file"  contains the metadata for a number of CCC system-wide services, including the Proxy. You can tell if your IdP has that file by checking for the file in the IdP's metadata/ directory, the file 'metadata/ccc-central-metadata.xml'. Otherwise, you need to download the metadata for the SSO Proxy from the following URLs (one for Pilot, one for Production). But do not try to download that metadata until completing Step 3 above.  

Each college/district IdP will have its own Proxy endpoint for metadata, and to which to send its response to, and those endpoints get created and added to the Proxy metadata distribution only once your IdP has itself been "added to" the Proxy's own configuration.

Just as with the CCCApply service, you will start with Pilot, and once that is working and you are given the "go-ahead", then download the metadata for Production. Note: you need to replace the 'nnn' at the end of each URL with the MIS code that applies to your district (if a district-wide IdP) or to the college (if a single college IdP). The SSO Integration Team will confirm with you what that code will be for your IdP.

STEP 5: Add the Proxy metadata to your college/district IdP

Otherwise, if you are running Shibboleth IdP v3 without assistance from Unicon, follow the below instructions:

Metadata for the Proxy is contained within the the CCC Central Metadata feed that contains metadata for many CCC system-wide services. You should add the following configuration to your college/district IdP's conf/metadata-providers.xml file, which will automatically keep checking (every few hours) whether there is an updated file to download, and if so, download it and keep a local "backing file" on your IdP.

<!-- Central CCC distribution of metadata -->
<MetadataProvider id="CCC_Central_Metadata"
                      xsi:type="FileBackedHTTPMetadataProvider"
                      backingFile="%{idp.home}/metadata/ccc-central-metadata.xml"
                      metadataURL=" http://saml.cccmypath.org/metadata/ccc-metadata.xml">
        <MetadataFilter xsi:type="RequiredValidUntil" maxValidityInterval="PT0S"/>
        <MetadataFilter xsi:type="SignatureValidation"
            requireSignedRoot="true" certificateFile="${idp.home}/credentials/ccctc-md-cert.pem"/>
        <MetadataFilter xsi:type="EntityRoleWhiteList">
            <RetainedRole>md:SPSSODescriptor</RetainedRole>
        </MetadataFilter>
</MetadataProvider>

STEP 6: Coordinate with Unicon to add your IdP metadata to the SSO Proxy
 

A.  Add metadata to SSO Proxy (Pilot and Production)

Just as you are adding the CCC SSO Proxy metadata to your IdP, the metadata for your college's IdP will need to be added to the Proxy. Unicon will add your college's metadata to the Proxy in the Pilot environment and will confirm with you once this process has been completed. You will not be able to successfully move forward with testing until this step has been completed. 

NOTE: In addition to the SSO Proxy, we also need to coordinate the replacement of your existing CCCApply metadata used to authenticate your college staff to your CCCApply Administrator and Report Center in the Pilot and Production environments. This step can happen concurrently with the SSO Proxy metadata upload, but testing the CCCApply URLs is a separate process that needs to be communicated with the Team. See "CCCApply Proxy Integration" section below for details.

STEP 7: Test Your Proxy Integration in the PILOT Environment

Once all the above steps have been completed in Pilot, you can test by using the following URLs.  Once the college/district and the SSO Integration Team agree that everything is working as it should with the Pilot integration, then the process is repeated in the Production environment (proxy). 

Step A - Navigate to the Proxy Testing Web Application

To start the test, click on the following link:

https://sso.pilot.cccmypath.org/simplesaml/module.php/core/authenticate.php?as=MISnnn
 

If you receive an error page, either there is an issue with the IDP configuration, the MISnnn value is incorrect, or the district/college code for your Identity Provider has not yet been configured in the SSO Proxy.  

Step B - IDP Login

The SSO Proxy will redirect you to your IDP.  Log in with a known userid/password.

Step C - Proxy Verification Page

If an error page is displayed, check your IDP configuration to ensure you are configured correctly.

If your IDP is configured correctly, you will see the following page displaying the SAML attributes that were release by your Identity Provider
 

Step D - Report Testing Feedback to SSO Integration Team

After testing the Pilot Proxy URL, please forward feedback to the SSO Integration team

If testing the Pilot Proxy is successful, testing the Production Proxy URL is the final step in the initial integration.

STEP 8: Make appropriate metadata changes in Proxy Production environment and test

Once all the above steps have been completed in Pilot and testing is successful, you will need to make any metadata or configuration changes to the Production IdP environment in order to enable the changes. You will need to download the metadata for the CCC SSO Proxy, similar to the steps taken in Step 4 for Pilot, from the following URL:

The Team will confirm with you what the code will be for your IdP.  Additional confirmation testing should occur once the changes have been made in Production to verify that the integration is still working as expected. Once this has been done, the initial integration with the SSO Proxy is complete.
 

CCCApply Proxy Integration
 

STEP 9:  Coordinate with Unicon to update your metadata for CCCApply Administrator in Pilot & Production

In addition to the proxy, we will coordinate the replacement of your existing CCCApply metadata used to authenticate your college staff to your CCCApply Administrator and Report Center applications in the Pilot and Production environments.  This step will happen concurrently with the proxy metadata upload and testing.

Please be aware: If you are doing a straight up Shibboleth V2 to V3 upgrade - whether you do it yourself or Unicon does it for you - we will simply replace your existing CCCApply metadata (in both environments) and there will be no change to the URLs you are using to access the CCCApply staff tools. However, if you change the name of your IdP, or if you switch to an alternative SAML-compliant IdP solution, such as Portal Guard, Ellucian, or ADFS, your current staff tools URLs will no longer work and you will be provided with new Administrator and Report Center URLs. This information will be reviewed with you during the SSO Kick-Off meeting at the onset of this process, but it's important to note this here as a reminder.

Once your metadata is replaced for CCCApply in the Pilot environment, please test by having an authorized user login to either the CCCApply Administrator or Report Center. If successful, please let the SSO Integration team know that you are ready to test in Production.

CANVAS Proxy Integration

STEP 10:  Configure your IdP to Integrate with Canvas

After you've completed and tested the SSO Proxy integration, you must configure your Canvas instance to work with the SSO Proxy.  

Integrate Canvas InCommon Metadata with the SSO Proxy

Hobson's Starfish Proxy Integration

STEP 11:  Configure your IdP to Integrate with Hobson's Starfish

If your college is implementing Hobson's Starfish application, we will work with your college to integrate with the SSO Proxy. Contact the SSO Integration team for information. 

CCC Applications Through Proxy Testing

STEP 12:  Pilot Colleges & Early Adopters Test Proxy Integration (Assess, Course Exchange, and MyPath)