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, serviceId: https://federation.campuslabs.com/shibboleth|https://cms.omniupdate.com/shibboleth|htt... and so on. metadataCriteriaPattern: https://federation.campuslabs.com/shibboleth|https://cms.omniupdate.com/shibboleth|htt... and so on. 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: serviceId: https://cm.maxient.com/simplesaml/module.php/saml/sp/metadata.php/maxient-sp metadataCriteriaPattern: https://cm.maxient.com/simplesaml/module.php/saml/sp/metadata.php/maxient-sp 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: serviceId: https://shib.lynda.com/shibboleth-sp requiredNameIdFormat: https://shib.lynda.com/shibboleth-sp 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 On Tue, May 15, 2018 at 1:07 PM, Scott Green <[email protected]> wrote: > Has anyone here had success in getting the InCommon Federation setup to > use the Shibboleth side of CAS 5.2.X? If so are you having to add each > entity individually, or were you able to use a single entry to get the > entire scope? We are looking at migrating our instance out of ADFS, and > into CAS, but if that's not possible we may abandon both in favor of > Shibboleth. I'm just looking for any help on that, as I feel like CAS is > our best option for IDP. > > Thanks, > > Scott > > -- > - Website: https://apereo.github.io/cas > - Gitter Chatroom: https://gitter.im/apereo/cas > - List Guidelines: https://goo.gl/1VRrw7 > - Contributions: https://goo.gl/mh7qDG > --- > You received this message because you are subscribed to the Google Groups > "CAS Community" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit https://groups.google.com/a/ > apereo.org/d/msgid/cas-user/f2b829fe-993a-47f8-9815- > aa079933e207%40apereo.org > <https://groups.google.com/a/apereo.org/d/msgid/cas-user/f2b829fe-993a-47f8-9815-aa079933e207%40apereo.org?utm_medium=email&utm_source=footer> > . > -- Gregory Booth Senior Systems Administrator & Technical Team Lead IT Operations Information Technology Michigan Technological University (906) 487-1797 <9064871797> www.mtu.edu www.it.mtu.edu -- - Website: https://apereo.github.io/cas - Gitter Chatroom: https://gitter.im/apereo/cas - List Guidelines: https://goo.gl/1VRrw7 - Contributions: https://goo.gl/mh7qDG --- You received this message because you are subscribed to the Google Groups "CAS Community" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/CAH%2BQwmih4o%3DpjaZ9PKUFvmzrtZBy8PdnB%2BksCvbkcdZymP%3DvPg%40mail.gmail.com.
