External identify provdier (idP) - Initiate authentication and roles

Hi Ryan,

Thanks for the input. Under “Perspective / Permissions”, “Roles” and “match all” has been selected.

I can still login from auth0.

Did you select some roles? If Public is selected, anyone can Login…

Security in Perspective - Ignition User Manual 8.1 - Ignition Documentation (inductiveautomation.com)

If we set Security levels none is allowed in, even when the auth0 user has role “admin” assigned.

Did you test your IdP from the GW to make sure its retuning as expected?


We are on to something here.

The test login idP Response data from Auth0 is not including roles. Will look into it. :slight_smile:


Looking at the Raw JSON that Auth0 sends and the Ignition idP test data there is a big difference. Name and user name is mapped to attribut “sub”, that is nowhere to be found in the Auth0 output.

Is Ignition doing its own filtering and altering the input?

Sounds like you need to play with your User Attribute Mapping to get the fields aligned to your IdP…


Custom namespace-prefixed attribute is now being passed successfully into the Test IdP area:

  "tokenEndpointResponse": { /* snipped */ },
  "idTokenClaims": {
    "https://custom.url.here/roles": [
    "sub": "etc",
    // snipped

However inside the user attribute mapping, a direct mapping for “https://custom.url.here/roles” doesn’t seem to map anything. The rest of the attributes (given_name, family_name, email, etc) are mapping correctly.

Check out this thread: Ignition 8.0.2, May 7th Identity Provider - User Mapping Attributes - Roles property does not get mapped to IdP Response value

Confirmed - direct mapping http://custom.url.here/roles does not work, but ["https://custom.url.here/roles"] does work. The JsonPath library used under the hood needs this syntax when matching against something that looks like a URL. This effectively tells the mapper to “just match the text” and not try to find a subpath.



#3 answered. Anyone have any ideas for #1 and #2?

No, though this idea has been submitted and looks pretty popular. If that idea captures what you are asking, consider upvoting the idea.

Not at this time. We are currently exploring how best to enable this capability.

I see I already have given my vote. :slight_smile:

eric3 sent me this by email, I would like to share it:
“Regarding the authentication… The ALB (Amazon load balancer) does a great job at authentication and making the session available to the application. I considered this when we were discussing this early on, however I ruled it out because you don’t have any control over the Ignition server. You would need to get Ignition to “trust” the ALB session information, and Ignition doesn’t have any kind of option for that. You need more granular control over who has access to what (RBAC == Role Based Access Control) and Ignition has no support for externally-enforced RBAC.”

This seems unrelated to your original questions, but it seems like the email you shared expresses a goal of getting Ignition to establish an authenticated session based on trust in a load balancer in front of it (perhaps through some magic headers or something of the sort). While I do not believe this is possible, Ignition can trust an external IdP. Can the ALB act as a SAML or OIDC IdP for Ignition? Or might there be an IdP service / software out there which can trust ALB session information? If either of these two options are possible, you could indirectly accomplish your goal (or eric3’s goal, if I understand it correctly).

Hi, did you (or anyone) figure out how to get roles from auth0?


1 Like

Thank you! really appreciate it.

Within Okta I create a “group” for each of the “roles” I need. For the user logging in, I collect the groups that they are a member of and then map that value to “roles”.

For posterity - a new auto login feature was added to Perspective in 8.1.8 which addresses some of the questions earlier in this thread. See: