Versions Compared

Old Version 63

changes.mady.by.user Patricia Donohue

Saved on

compared with

New Version Current

changes.mady.by.user Patricia Donohue

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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


Info

The eduPerson schema ( http://software.internet2.edu/eduperson/internet2-mace-dir-eduperson-201602.html ) has a more detailed description of many of these attributes and their intended meaning and purpose.

...

Simple Name and the SAMLv2 name when sent in the SAMLv2 response

Short description

Example

Notes

eduPersonPrimaryAffiliation

urn:oid:1.3.6.1.4.1.5923.1.1.1.5

Primary role at the institution

  • staff

  • student

  • faculty

Must be one of the values specified in eduPersonAffilliation. If the eduPersonAffiliation attribute has many values, the primary affiliation should reflect primary the users primary affiliation. i.e. a teacher aid may be a student and staff, but their primary role is a student.

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

...


...

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.


Info

Contact

Team

Us: The CCC SSO Integration Team can be reached here: CCC SSO Support Engineer = Matt Schroeder, mschroeder@ccctechcenter.org, Proxy Service & Technical Implementation Manager = Rodney Hing, rhing@unicon.net; CCC SSO Product Manager = Patricia Donohue, pdonohue@ccctechcenter.org;

...

through CCCTC Enabling Services.

...

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

...

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

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

Note

If you are running a Shibboleth IdP v3 server with the configuration changes made by Unicon, you will not need to make the following configuration changes because it has already been done for you. If you are not sure if these changes have been made already by Unicon, please contact the SSO Integration Team for confirmation.


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.
 

Code Block
<!-- 
     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>

...

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

...

Anchor
hobsons-proxy
hobsons-proxy
Hobson's Starfish Proxy Integration

...