Page Comparison

...

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 C3 and F below 6 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.

...

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

...

...

STEP 2: Configure your Identity Provider (IdP) to Release the Above Attributes to the CCC SSO Proxy

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 system-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 for the file in the IdP's conf/ directory, the file 'conf/attribute-filter.ccccentral.xml'. Otherwise, add the following to the IdP's conf/attribute-filter.xml file, or however you corresponding 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.ci.cccmypath.org/simplesaml/module.php/saml/sp/metadata.php"/>
		<Rule xsi:type="Requester" value="https://sso.test.cccmypath.org/simplesaml/module.php/saml/sp/metadata.php"/>
		<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 3: Schedule Kick-Off Meeting with Proxy Project Team 

At this point, before you can do some of the following steps, you need to contact the CCC Proxy Project 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 need to take to configure the IdP 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 CCC IdP Proxy, and once that integration is successfully verified, then integration will move on to the Production CCC IdP Proxy.

...

...

STEP 4: Configure your Identity Provider to Consume the Metadata for the CCC SSO Proxy

If you are running a Shibboleth IdP v3 server, with the configuration changes made by Unicon, you won't need to perform the following. 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. That "CCC system-wide central metadata file"  contains the metadata for a number of CCC system-wide services, including for 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 CCC SSO Proxy from the following URLs (one for Pilot, one for Production). But you do not want to try and download that metadata until completing Step C 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.

...

...

STEP 5: Add the CCC IdP Proxy Metadata to your College/District IdP

Otherwise, if you are running Shibboleth IdP v3 without assistance from Unicon, you need to save the metadata file you obtained from the above URL, and save it as the file:

...

	<!-- 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"/>

...

STEP 6: 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 Proxy Project Team agree that all is working as it should with the Pilot integration, then the college/district and the Proxy Project Team can move on to Production. 

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

Note: you need to replace IMPORTANT: 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 CCC IdP SSO Proxy Service Team will confirm with you what that code will be for your IdP.

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 CCC SSO Proxy Team

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

If testing the Pilot Proxy was successful, testing the Production Proxy URL is the final step.