ArcGIS AGOL Unable to Login Using IDP Error Parsing 'NAME_ID' from SAML Reponse

[AlexStevenson]

This issue started today where on occasion just signing into AGOL via web browser or through the Navigator for ArcGIS app, we will get this error.  Then it mysteriously goes away.  I contacted our guy that works with ADFS and he said that he doesn't see any issues or errors on our end.  But there seems to be an issue going on between our enterprise identity provider and AGOL's Portal for ArcGIS.

Is anyone else experiencing this issue recently where it was working normally beforehand?

[DanielUrbach]

Alex,

That error generally indicates that the Portal (or AGOL) did not receive a nameID attribute in the SAML response sent from your ADFS.

If you happen to have Firefox, you can install a handy SAML troubleshooting tool called SAML Tracer, which will let you view the SAML response that is sent back upon authentication with ADFS (the SAML response and request are denoted in SAML Tracer with an orange "SAML" tag on the right side of the window.  Looking at that SAML response after getting this error, do you see the NameID attribute?  If not, it indicates that ADFS is not sending that attribute and in that case it might be worth having your ADFS admin take a look at the Windows Event logs for that ADFS machine.  It's probably also a good idea to confirm if this is happening to other users as well, or just your user, as that might help your ADFS administrators to narrow down the issue.

Do you have multiple ADFS instances behind a load-balancer?  Because of the intermittent nature of the issue, it could indicate that one of the instances may not be handling requests properly.

-Danny

[AlexStevenson]

Hi Daniel,

Thank you for the response.

I don't have Firefox but I did see that there's a SAML Tracer for Google Chrome.  I installed that extension, logged out of AGOL and logged back in.  No issues this time around with logging in.  I looked at the SAML extension logs but did not find any attribute with "Nameid" or "Name_ID" in the response data tab.  I also exported the SAML logs (it exports as a .json file) and did a search in there for NameID but it didn't return anything.

I have confirmed that this is happening to other users as will and with the mobile app Navigator for ArcGIS.

Thanks,

Alex

[DanielUrbach]

Alex,

I only mentioned Firefox because up until a few minutes ago, every Chrome extension I tested wouldn't actually capture the SAML traffic from AGOL (this is due to the fact that we open a second tab for the SAML interactions).  It looks like the "SAML Message Decoder" extension does work and it's what I will be using moving forward!

Either way, can you confirm if your organization is indeed using encrypted assertions?  You could check the "Edit Identity Provider" settings in your organization's security settings page to confirm this.  If so, this would explain why you didn't see "nameid" in the SAML response, as it would be encrypted.  If this is the case, as a test you might turn off encrypted assertions there and have your ADFS admin temporarily disable them on the ADFS side, then capture the SAML response from a failed login attempt.

An easier first step may be to simply re-establish the relying-party trust between AGOL and ADFS.  It's generally pretty painless and won't affect the SAML-based users you have already created in AGOL, so long as the attributes currently mapped in ADFS remain the same.  See Configure Active Directory Federation Services—ArcGIS Online Help | ArcGIS  for details on how to do this.

-Danny

[AlexStevenson]

Hi Danny,

I'll also be using the SAML Message Decoder.  Thanks for mentioning it!

I checked the Edit Identity Provider settings and it appears we do not have Encrypt Assertion enabled.  

I'm checking with our ADFS admin to make sure we are including the 4 User Attributes for outgoing claim types as mentioned in the article you mentioned. A couple of questions on this - if we make a change to the ADFS mapped attributes, say that attributes are added, will that affect the existing SAML-based users in AGOL?  And, will that require an update with our IDP?

Thanks,

Alex

[DanielUrbach]

Alex,

Regarding the claims types, changing any of these WILL affect your existing SAML-based users, but only one will be a detrimental change.  Changing the attributes mapped for email, givenname or group attributes will only affect the profile of the user and potentially what enterprise-based groups they are a part of in AGOL.

Changing the attribute that is mapped to nameID will actually cause AGOL to assume you are a different user!  I definitely do NOT recommend changing this unless you have a only a few users or the SAML-based users don't own content/groups.  We use the nameID to properly map your user to the AGOL named user account.

To answer your last question, making changes to the claims attributes in ADFS will not require you to reconfigure the trust between AGOL and ADFS.

If you are not seeing the nameID attribute in the SAML Message Decoder but you ARE able to sign in, I'm sort of at a loss to explain that.  If you are comfortable doing so you can send me the SAML response for both the successful and unsuccessful login attempt in a private message, I'd be interested to see the difference between these.

-Danny

[AlexStevenson]

Danny,

We have a case open with premium support and it was determined that we needed to add the other LDAP attributes to the outgoing claim types.  So, I worked with our ADFS admin to add these.  We did not change the mapping of the User-Principal-Name to Name ID.  We also re-established the trust between AGOL and our network (imported the federation metadata xml).  Also, that SAML Message Decoder extension has been working great.  I can now see the attributes in the SAML response header.

After making these changes, we have not seen the IDP error come back just yet.  However, a new issue came up. Now, when trying to hit the Save button in the Organization Settings, it throws an Error saying that it is unable to save our settings at this time.  Premium support is thinking that it has to do with the newly added LDAP attributes affecting the way AGOL is trying to save or a corrupt metadata file.  The next test is to Remove Enterprise Login and test if we can Save.  

Regards,

Alex

[DanielUrbach]

Alex,

Glad to hear you got past that error!

Because only nameID is required to send in the outgoing claims attributes, my guess is what really fixed this was simply recreating the trust between AGOL and ADFS.

When did you see this issue with saving the changes?  I ask because a new release of AGOL was just rolled out in the last few days, I'm wondering if you are seeing an issue with this new release.  I don't believe the claims attributes you configured would have any bearing on AGOL being able to save the changes on that page.

Can you check the network traffic in the browser developer tools when you click Save?  I'm interested to see what calls are going out and what the response to that call is.

-Danny

[AlexStevenson]

Danny,

We saw the issue happen Wednesday morning.  I believe that the new release for AGOL did not happen until Wednesday evening but the timing of these issues is peculiar. 

I did capture the network traffic in the browser developer tools and saw the following, which was interesting:

I also tried saving under a non-Enterprise account and received the same response error.

Side note - I tried sending you a direct message with some more information but I'm not allowed to it seems.

-Alex

[DanielUrbach]

For anyone following this thread that runs into a similar error when trying to save changes in the organizational settings, please note that any users listed in the Administrative Contacts under the General tab in Settings MUST have an email address associated with the account.  If you were not sending the email attribute in the SAML response for SAML-based users and those users were previously listed as administrator contacts for your organization you will want to do one of the following:

1) Ensure that "Update profile at sign in" is checked in the "Edit Identity Provider" settings under Settings > Security, then have any users listed in Administrative Contacts sign in and confirm their profile populates the Email address value.

2) Contact Esri Support Services if option 1 does not work or you cannot change the above setting.

-Danny