Page Comparison

...

...

STEP 2: Schedule

...

kick-

...

off call with the Proxy Project Team 

At this point, before you can do some of the following steps, you need to contact the CCC the CCC Proxy Project team 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 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 Proxy Project Team will also ensure, as part of this step, that they have obtained a copy of the metadata for your college/your college or district IdP metadata.  Just Just as with CCCApply, the CCC SSO 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 Proxy 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 Proxy 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.  (NOTE: The information in this section is geared towards Shibboleth V3 IdP users. If you are using a different Identity Provider (IdP) solution, please follow the links below for instructions specific to your IdP.  Then return to this document to ensure you've completed the remaining integration and testing steps. 

...

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 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 , for 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 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

The "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 try to try and download that metadata until completing Step C 3 above.  Each  

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

...

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:

IdP's home directory/metadata/ccc-Idp-proxy-pilot-metadata.xml

...

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. 

Please forward a copy of your IdP metadata to:  Geneva Paliwodzinski, gpaliwodzinski@unicon.net; cc: Patty Donohue, pdonohue@ccctechcenter.org 

...

STEP 7: Test Your PILOT Implementation

...

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

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

Image Modified

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.