Page Comparison

...

STEP 2:

...

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.

...

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.

The CCC IdP Proxy Service Team will also ensure, as part of this step, that they have a copy of the metadata for your college/district IdP.  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 CCC 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 that you are running, a few configuration changes will need to be made:

Portal Guard IdP - instructions can be found at Attributes for the Proxy: Portal Guard

Ellucian IdP -  instructions can be found at Attributes for the Proxy: Ellucian

Shibboleth IdP - instructions can be found below:

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="ValueRequester" value="library-walk-in" ignoreCase="true"/>
		</PermitValueRule>
	</AttributeRule>
	<AttributeRule attributeID="eduPersonPrimaryAffiliation"https://sso.test.cccmypath.org/simplesaml/module.php/saml/sp/metadata.php"/>
		<PermitValueRule<Rule xsi:type="ANYRequester"/>
	</AttributeRule>

	<!-- CCC specific attributes -->
	<AttributeRule attributeID="cccId" value="https://sso.pilot.cccmypath.org/simplesaml/module.php/saml/sp/metadata.php"/>
		<PermitValueRule<Rule xsi:type="ANY="Requester" value="https://sso.cccmypath.org/simplesaml/module.php/saml/sp/metadata.php"/>
	</AttributeRule>PolicyRequirementRule>
	<AttributeRule attributeID="cccMisCodeeduPersonPrincipalName">
		<PermitValueRule xsi:type="ANY"/>
	</AttributeRule>

	<!-- Less likely attributes to be populated, but release if available -->
	<AttributeRule 	<AttributeRule attributeID="mobileNumberuid">
		<PermitValueRule xsi:type="ANY"/>
	</AttributeRule>
	<AttributeRule attributeID="homePhoneemail">
		<PermitValueRule xsi:type="ANY"/>
	</AttributeRule>
	<AttributeRule attributeID="telephoneNumbergivenName">
		<PermitValueRule xsi:type="ANY"/>
	</AttributeRule>
	<AttributeRule attributeID="postalAddresssurname">
		<PermitValueRule xsi:type="ANY"/>
	</AttributeRule>
	<AttributeRule attributeID="streetdisplayName">
		<PermitValueRule xsi:type="ANY"/>
	</AttributeRule>
	<AttributeRule attributeID="localityeduPersonAffiliation">
		<PermitValueRule xsi:type="ANYOR"/>
	</AttributeRule>
	<AttributeRule attributeID="stateProvince">
		<PermitValueRule<Rule xsi:type="ANY"Value" value="faculty" ignoreCase="true"/>
	</AttributeRule>
	<AttributeRule attributeID="postalCode"			<Rule xsi:type="Value" value="student" ignoreCase="true"/>
		<PermitValueRule	<Rule xsi:type="ANYValue" value="staff" ignoreCase="true"/>
			</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.

The CCC IdP Proxy Service Team will also ensure, as part of this step, that they have a copy of the metadata for your college/district IdP.  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 CCC Proxy Team to get your metadata to them.

<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

...

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

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

and then add the file:

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

...

following configuration into the IdP's conf/metadata-providers.xml file:
 

	<!-- Pilot CCC IdP Proxy Metadata, locally maintained -->
	<MetadataProvider id="CCCIdPProxyPilot"  xsi:type="FilesystemMetadataProvider"
		metadataFile="%{idp.home}/metadata/ccc-

...

idp-proxy-

...

pilot-metadata.xml

...

and then add the following configuration into the IdP's conf/metadata-providers.xml file:
 

"/>
 
	<!-- PilotProduction CCC IdP Proxy Metadata, locally maintained -->
	<MetadataProvider id="CCCIdPProxyPilotCCCIdPProxyProduction"  xsi:type="FilesystemMetadataProvider"
		metadataFile="%{idp.home}/metadata/ccc-idp-proxy-pilotproduction-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: Unicon will add your IdP metadata to the CCC SSO Proxy

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. 

STEP 7: 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. 

...