Configure OpenID Connect logins

9343
20
Jump to solution
06-07-2021 02:20 AM
RomanBoros
New Contributor III

Hi,

We are trying to setup an OpenID Connection to our ArcGIS Online.

All the necessary configurations were done on our Identity Provider and in the ArcGIS Online admin panel.

The button appeared on the login screen and after pressing we are redirected to the Identity Provider. After successful authentication the server redirects back to the portal and an error message is displayed.

Did not receive 'user profile' parameter from the provider.

RomanBoros_0-1623056922667.png

Can you provide more details what might be the problem?

This is the response format that the identity provider returns from the user info endpoint

RomanBoros_1-1623057291228.png

As Identity Provider we are using Identity Server 4.

The grant type for this client is authorization_code

We tried looking into documentation, but there is nothing about this error.

Thanks for your help.

Tags (3)
20 Replies
HaraldLund
New Contributor II

Hi @JoshuaAbbott,

Unfortunately we weren't able to get this to work with ArcGIS Portal 10.9.1. But using the exact same IdentityServer application with ArcGIS Online that also supports PKCE flow, it works. So I suspect that there is a problem with 10.9.1. It would be nice if Esri would be able to support the latest security demands also with ArcGIS Portal 10.9.x and that there were possibilities to manage some mapping and handling of custom scopes and claims. With more and more demands to be able to support the latest secure architecture using OpenID Connect I think it is essential that Portal would support this. I also missing how samples and documentation of how the mapping is done now. 

One other thing I'm unsure of is if we would be able to authenticate an user with the federated IDP, and use the token to access the items the user is authorised to use. Or do we always have to trigger the authentication by accessing Portal first and to be redirected to the IDP?

 

0 Kudos
JoshuaAbbott
New Contributor II

Many thanks for the response. I agree that they should include support in 10.9.1 since PKCE is now the industry standard. I am using a version of ArcGIS that supports PKCE and I am still seeing that error, that I hope you might be able to shed some light on. Below is my client setup with sensitive info redacted. Also, when configuring the Login on ArcGIS, it asks for a "Provider Issuer ID" is this just the domain of the identity provider? For example I just have "https://localhost:44360". Again, thanks for your collaboration.  

{
   ClientId = "arcgis-client",
   ClientName = "API Client",
   AllowedGrantTypes = GrantTypes.Code,
   RequirePkce = true,
   RequireClientSecret = false, // obsolete with PKCE
   AllowOfflineAccess = true,
   AlwaysIncludeUserClaimsInIdToken = false,
   RedirectUris = new string[] { "REDACTED" },
   PostLogoutRedirectUris = new string[] { "REDACTED" },
   ClientSecrets = new Secret[] { new Secret("REDACTED".Sha256()) }, // Not used, but ArcGIS asks for it
   AllowedScopes = new string[]
   {
      IdentityServerConstants.StandardScopes.OpenId,
      IdentityServerConstants.StandardScopes.Profile,
      IdentityServerConstants.StandardScopes.Email
   }
}

 

0 Kudos
HaraldLund
New Contributor II

As issuer I also have used the same as you. Have you tried to set this to true? 

AlwaysIncludeUserClaimsInIdToken = true

If you're using a version supporting PKCE, isn't that ArcGIS Online?

I see you also use a local host for testing. Just wondering if there is an issue if your server isn't reachable for the ArcGIS installation,  but the communication should be with in the browser session, if I have understood this correctly. 

 

0 Kudos
JoshuaAbbott
New Contributor II

Yes, I'm using ArcGIS Online with PKCE support. I have "Include Token in Header" enabled and I have tried 

 

AlwaysIncludeUserClaimsInIdToken = true

 

still without success. I do not think the issue is the communication to localhost, since it does redirect to the sign in page of my Identity Provider, the user is authenticated and then returned to ArcGIS with the access token. It is then that ArcGIS shows that error about "no user profile parameter". 

Update: @HaraldLund I did have to have it running at a publicly accessible URL, so after hosting it on IIS everything worked out fine. 

HaraldLund
New Contributor II

Great you managed to solve it, that was my next step for my testing as well. Was also looking into Keycloak but ended up with same error. I will go back to testing with a accessible URL with IdentityServer, even though using KeyCloak may reduce the development time.

0 Kudos
MarkCederholm
Occasional Contributor III

I'm playing around with IdentityServer4 as an OpenID Connect source, and I am getting the same "user profile" error, although it works fine for a MVC client that uses the same parameters as ArcGIS Online.  Next I created a custom IProfileService implementation to see if it's actually being called, and again it works fine for the MVC client, but with AGOL only IsActiveAsync is being called (and returning true); GetProfileDataAsync is never called. 

0 Kudos
pocalipse
New Contributor III

Hi Mark

Did you find a solution for the OpenID problem - I have the exact same issue using KeyCloak!

0 Kudos
HaraldLund
New Contributor II

This will probably not help you directly, but I have a customer who were able to setup KeyCloak with ArcGIS Portal 10.9, but I do not have any details on the configuration. But when I was setting up the Okta setup, I also struggled with this error. I ended up with not checking the "Send access token in header", setting the  UserInfo URL to empty but filling out the JWKS url. With the Okta configuration I uses Client Credential and Authorization Code. I also had to make sure the Claims where mapping correctly. I also have a sub claim added. 

pocalipse
New Contributor III

I think my problem is exactly the mapping - did you manage to figure out what claims ArcGIS is expecting?

 

0 Kudos
HaraldLund
New Contributor II

Hi, 

These are the claims you need:

name
nickname
given_name
middle_name
family_name
email

0 Kudos