4 ms·

Here's a tip for anyone planning on working with customers who are US research or education institutions: Have one of your Higher Ed customers sponsor you as an

Here's a tip for anyone planning on working with customers who are US research or education institutions: Have one of your Higher Ed customers sponsor you as an InCommon sponsored partner, and use that to join the InCommon Federation (https://www.incommon.org/ https://www.incommon.org/) InCommon is, among other things, a US federation of SAML SPs and IdPs. And this is one of the interesting things about SAML. Let's say that you are a Service Provider. Normally, for each customer, you have do at least one exchange of metadata (as u/victorNicollet mentioned elsewhere in the comments). If you have multiple SPs (say, a dev and a prod), or the customer has multiple IdPs (again, a dev and a prod), then you have to do this exchange multiple times. An alternative is to join a federation. With a federation, the federation receives all of the metadata (all of the information about SPs and IdPs), and you trust the combined metadata the federation provides. And for Service Providers, there is a separate metadata feed of just IdPs. What does this get you? It means, if your customer is already part of the federation, you don't have to exchange metadata with them. At most, they (the customer) might have to release additional attributes to you, that are not released by default (phone number, for example). For InCommon, you can see all of the federation participants here: https://www.incommon.org/federation/incommon-federation-participants/ https://www.incommon.org/federation/incommon-federation-part... Details on the technical side of the process are available here: https://spaces.at.internet2.edu/display/InCFederation/How+to+Get+Started+in+the+InCommon+Federation https://spaces.at.internet2.edu/display/InCFederation/How+to...

rb12345 7y ago
To expand on this from a non-US perspective, the advice to join a federation also applies to working with universities elsewhere. Having joined one federation (e.g. InCommon or the UK Access Management Federation (https://www.ukfederation.org.uk/) https://www.ukfederation.org.uk/)), you can then get your metadata published in eduGAIN (https://edugain.org/ https://edugain.org/) for institutions elsewhere in the world to use. Other things to note from a HE perspective: - Most potential users will likely be using Shibboleth as an IdP, as opposed to ADFS, Ping Federate, Okta and the like. This means that using federation-supplied metadata is far easer to work with than setting up per-SP metadata manually. (In ADFS at least, all the relying party setup is fairly manual, although Powershell can make this slightly less painful.) - The admins running the IdP will most likely not not be the people buying or using the services provided by an SP. This can complicate setting up SAML integrations. - SPs should try to support standard LDAP attribute schemas like the eduPerson (https://wiki.refeds.org/display/STAN/eduPerson https://wiki.refeds.org/display/STAN/eduPerson) schema. These are likely to appear as "urn:oid:..." attributes in the SAML assertion. My personal suggestion for mixed HE/enterprise SPs would be to map both the eduPerson URNs and the equivalent ADFS claim identifiers to one internal identifier. - As noted elsewhere, email addresses as identifiers are problematic in the general case: people change names, people change departments, and people may have multiple email addresses. The eduPersonPrincipalName attribute is generally more stable and is still non-opaque.
tingletech 7y ago
I literally have nightmares about shibboleth and InCommon. My university system has at least 11 IdPs (I think some of the medical centers have their own, but my apps aren't used by medical centers generally). Even with InCommon, I had to negotiate attribute release with every IdP to get email and eppn. Even after filling out the forms that went through a systemwide identity committee, I had to cold call half the campus identity management groups to get the attributes. To even get my metadata into InCommon, I had practically camp out in front of some dudes office because I could not get email or phone calls returned. But, I was getting it set up before the Research and Scholarship category came out. If you can get your app/SP approved, and your target IdPs support it, the attributes are pre-negotiated. Plus the software was a PITA too. I'm trying to get a "bridge" set up so I can have one SP in R&S that supports OIDC, that way when I do a new app I can just have the app use open id connect and not have to deal with shibboleth. Research and Scholarship Category https://spaces.at.internet2.edu/display/InCFederation/Research+and+Scholarship+Category https://spaces.at.internet2.edu/display/InCFederation/Resear...

rb12345 7y ago

To expand on this from a non-US perspective, the advice to join a federation also applies to working with universities elsewhere. Having joined one federation (e.g. InCommon or the UK Access Management Federation (https://www.ukfederation.org.uk/) https://www.ukfederation.org.uk/)), you can then get your metadata published in eduGAIN (https://edugain.org/ https://edugain.org/) for institutions elsewhere in the world to use. Other things to note from a HE perspective: - Most potential users will likely be using Shibboleth as an IdP, as opposed to ADFS, Ping Federate, Okta and the like. This means that using federation-supplied metadata is far easer to work with than setting up per-SP metadata manually. (In ADFS at least, all the relying party setup is fairly manual, although Powershell can make this slightly less painful.) - The admins running the IdP will most likely not not be the people buying or using the services provided by an SP. This can complicate setting up SAML integrations. - SPs should try to support standard LDAP attribute schemas like the eduPerson (https://wiki.refeds.org/display/STAN/eduPerson https://wiki.refeds.org/display/STAN/eduPerson) schema. These are likely to appear as "urn:oid:..." attributes in the SAML assertion. My personal suggestion for mixed HE/enterprise SPs would be to map both the eduPerson URNs and the equivalent ADFS claim identifiers to one internal identifier. - As noted elsewhere, email addresses as identifiers are problematic in the general case: people change names, people change departments, and people may have multiple email addresses. The eduPersonPrincipalName attribute is generally more stable and is still non-opaque.

tingletech 7y ago

I literally have nightmares about shibboleth and InCommon. My university system has at least 11 IdPs (I think some of the medical centers have their own, but my apps aren't used by medical centers generally). Even with InCommon, I had to negotiate attribute release with every IdP to get email and eppn. Even after filling out the forms that went through a systemwide identity committee, I had to cold call half the campus identity management groups to get the attributes. To even get my metadata into InCommon, I had practically camp out in front of some dudes office because I could not get email or phone calls returned. But, I was getting it set up before the Research and Scholarship category came out. If you can get your app/SP approved, and your target IdPs support it, the attributes are pre-negotiated. Plus the software was a PITA too. I'm trying to get a "bridge" set up so I can have one SP in R&S that supports OIDC, that way when I do a new app I can just have the app use open id connect and not have to deal with shibboleth. Research and Scholarship Category https://spaces.at.internet2.edu/display/InCFederation/Research+and+Scholarship+Category https://spaces.at.internet2.edu/display/InCFederation/Resear...