ArcGIS Online

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): https://idp.example.edu/idp/profile/SAML2/Redirect/SSO
• Login URL (POST): https://idp.example.edu/idp/profile/SAML2/POST/SSO

This dialog also includes a range of options related to the SP's own behavior, including its entityID, see below.

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

Profile Requirements

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 <NameID>  element's 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

SAML2.SSO

Account Provisioning

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.

NameID Requirements

ArcGIS inaccurately documents itself as requiring a particular, and ill-advised <NameID> Format of 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

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:

	<!-- SAML 2 NameID Generation -->
	<util:list id="shibboleth.SAML2NameIDGenerators">

		<ref bean="shibboleth.SAML2TransientGenerator" />

		<!--
		<ref bean="shibboleth.SAML2PersistentGenerator" />
		-->

		<!--
		Add custom support for employeeNumber-based NameID, assumes you've released
		the source attribute (employeeNumber) to any SPs expecting to get it.
		-->
		<bean parent="shibboleth.SAML2AttributeSourcedGenerator"
			p:format="urn:oid:2.16.840.1.113730.3.1.3"
			p:attributeSourceIds="#{ {'employeeNumber'} }" />

	</util:list>

	<AttributeFilterPolicy id="ArcGIS">
		<PolicyRequirementRule xsi:type="Requester" value="https://example.maps.arcgis.com/sp" />

		<AttributeRule attributeID="employeeNumber" permitAny="true" />
	</AttributeFilterPolicy>

Attribute Requirements

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.