Hi, Scott,
We were able to set up InCommon Federation on CAS 5.1.x (we're in the process up updating to 5.2.x, but are not there yet). We ended up having 3 service files in /etc/cas/services - one file covers nearly all our InCommon SPs, but two of the vendors had special requirements that necessitated breaking each of them out into a separate file (more on that later). The basic process we followed was:
1) Set up InCommon initially, by adding the InCommon config lines (as noted here -
https://apereo.github.io/cas/5.1.x/installation/Configuration-Properties.html#incommon ) to cas.properties and restarting CAS. This auto-generated a service definition file, /etc/cas/services/InCommonAggregate-10000.json, and set up the InCommon metadata, including making it refresh periodically.
2) Delete the InCommon lines from cas.properties so we can manage the service definition file ourselves rather than auto-generate it.
3) Edit the InCommonAggregate-10000.json file. Mostly, we changed the following things:
3a) Replaced the serviceId and metadataCriteriaPattern attribute with a list of our vendor's entityIDs, separated by pipes. For example,
I believe this is what is meant by "EntityIds can be regular expression patterns and are mapped to CAS’ serviceId field in the registry." from the docs.
3b) Set up our attributes to be released, including mapping them by OID. For example,
allowedAttributes:
{
@class: java.util.TreeMap
eduPersonPrincipalName: urn:oid:1.3.6.1.4.1.5923.1.1.1.6
givenName: urn:oid:2.5.4.42
mail: urn:oid:0.9.2342.19200300.100.1.3
sn: urn:oid:2.5.4.4
uid: urn:oid:0.9.2342.19200300.100.1.1
}
3c) Put in semi-generic name, description, and logo lines. These are generally specified by the vendor in the InCommon metadata, but if the vendor did not include these, the valuse you put in here will be displayed on the login page.
4) Tested out all our vendors' logins. Two of these vendors each required an extra thing, so we copied InCommonAggregate-10000.json for each of them, replaced the list of serviceId and metadataCriteriaPattern entityIDs with just that vendors' (and removed that vendor's entityID from InCommonAggregate-10000.json), and added the thing they required. For example,
InCommonAggregate-10001.json has the following lines:
requiredNameIdFormat: urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified
...this is because Maxient requires nameid-format to be 'unspecified'.
InCommonAggregate-10002.json has the following lines:
attributeNameFormats:
{
@class: java.util.HashMap
"urn:oid:1.3.6.1.4.1.5923.1.1.1.6" :uri
"urn:oid:2.5.4.42" :uri
"urn:oid:0.9.2342.19200300.100.1.3" :uri
"urn:oid:2.5.4.4" :uri
"urn:oid:0.9.2342.19200300.100.1.1" :uri
}
...this is because
lynda.com requires an attributeNameFormat of 'uri'.
You could also break out separate files if you want to release different sets of attributes to different vendors.
I'm not sure this is the 'correct' or 'best' way to set this up, but it works for us and allowed us to go to one SSO system instead of having separate CAS and Shib systems.
Greg