This information was last reviewed in May, 2019, by Scott Cantor.
5/2019: Updates from latest round of testing of encryption and logout.
7/2019: Incomplete information regarding their encryption support.
7/2019: This was created by copying an original page supplied by Lafeyette College, reformatting to fit the template, and correcting some mistakes as well as updating to reflect changes in their GUI.
This is not a replacement for the actual documentation and you cannot cut and paste your way to a working system. The examples are not usable without taking into consideration your local needs and requirements.
This is a page for documenting Shibboleth integration with ArcGIS Online, which is a typical cloud service providing direct self-managed configuration of SAML settings rather than relying on federation-mediated metadata exchange.
The official documentation, which includes at least some definite inaccuracies, is at https://doc.arcgis.com/en/arcgis-online/reference/configure-shibboleth.htm
Identity Provider Metadata
The relevant section of the ArcGIS Online admin interface is Organization > Settings > Security. In the Enterprise Logins section, there are options for both single and multiple Identity Provider scenarios. I have only tried the single IdP case, which used to be the only one supported.
They support file and URL-based metadata for one-time extraction of the settings, or you can manually establish the IdP settings, including a name for the IdP used in their login form, the Redirect and POST binding SSO endpoints, and the IdP's signing certificate:
- Login URL (Redirect):
- Login URL (POST):
Service Provider Metadata
ArcGIS will produce mostly correct metadata based on the options you set in the Identity Provider dialog (counter-intuitively). In particular you must set a unique entityID for your instance, which you get to pick, so use something stable and reasonable you won't need to change later. With the signing and encryption options unchecked, the metadata it generates is very limited and doesn't include a key.
The signing and encryption options apparently result in the metadata being generated with a key, but see below for my encryption results.
Once you determine what kind of
Format you intend to use down below, you'll need to add a
<NameIDFormat> element to the SP's metadata before you load it into the IdP to trigger the right format to be selected at runtime. The element appears immediately ahead of the
<AssertionConsumerService> element(s) in an SP's metadata.
ArcGIS supports vanilla SAML behavior without any special workarounds, excepting that it hasn't been successfully made to work with encryption enabled and their documentation claims that logout is not supported, even though their UI exposes those options. With logout enabled, I observed it attempting to send a request, but inside a hidden frame (which the IdP won't handle well), and it was unsigned and also broken because they had removed the
Format attribute, which would cause the IdP to reject it as non-matching.
With encryption on, I got a validation error of some kind on their side. It's possible a different set of signing options or some other changes might have made it work.
Example Shibboleth Configuration
Other than possibly disabling encryption (see SecurityConfiguration), you should not need any special RelyingParty behavior configured.
Required Profile Configurations
ArcGIS can do just in time provisioning or can be limited to invited users, based on a radio button chosen on the Identity Provider setup dialog. It also has an option for updating user profiles with SAML Attributes, but with a quirk noted below in that section.
ArcGIS inaccurately documents itself as requiring a particular, and ill-advised
urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified. In fact the documentation is so broken that it inaccurately references that constant with a "2.0" string inside it, which is technically wrong on top of not even being true.
Do not use that format or any of their broken documentation!
The application requires that you pass it a unique ID for the accounts in the
<NameID> element, but it does not care what the actual
Format string is. While this is broken in its own right, it's not uncommon. You should pick a
Format that reflects the data you choose to pass, one that would be valid regardless of which service you may decide to pass it to in different cases. Ideally this should be a stable identifier you can rely on of course.
On the application side, it actually concatenates whatever you give it with an underscore and then an organization ID string that is specific to each silo to make the value internally unique, so you'll notice that once you see people actually using the system.
Example Shibboleth Configuration
Refer to the NameIDGenerationConfiguration topic for a full treatment of NameID features.
For the sake of argument, if you have an attribute definition named "employeeNumber" produced by your AttributeResolverConfiguration, release it to ArcGIS in your AttributeFilterConfiguration (example below).
You will also need to add the appropriate
<NameIDFormat> element to the SP's metadata that you load into the IdP, containing the format value you're going to use.
Finally, to actually produce the necessary
<NameID>, modify saml-nameid.xml as shown:
ArcGIS supports a couple of optional SAML Attributes if you provision on the fly or if you check a box telling it to update the user's profile information. It apparently supports the standard SAML and Shibboleth OID nomenclature for the "mail" and "givenName" attributes, but it inaccurately populates what is essentially a "display name" of both first and last name using the givenName value, so this isn't going to work at scale. People can also update their profiles after the fact, but then it just updates again, etc.