Okta Workforce Entreprise SSO Groups Clarification

[davidhouseknechtdev]

Question

Following up on Okta Workforce Entreprise SSO Groups – is this still the case?

Reasoning

I ask because I setup an Okta Workforce connection and I select the User Mapping > Okta Default setting I see that groups are sent in the scopes and federated_groups shows up in the mapping be default:

However, even after the user authenticates through the Okta connection, we don’t see the federated_groups on the user in Auth0 (but we do see federated_locale and federated_zoneinfo).

I thought maybe the article meant that Okta isn’t sending the groups claim. I opened this question on their forum. Their response seems to indicate that Auth0 is dropping the groups on the floor not that Okta isn’t sending. I was hoping to confirm this.

[davidhouseknechtdev]

Also, I noticed Auth0’s documentation around setting up groups seems like this should be supported.

[nik.baleca]

Hi @davidhouseknechtdev

Welcome back to the Auth0 Community!

Have you tried using the bind_all for the mapping_mode attribute?

Kind Regards,
Nik

[davidhouseknechtdev]

Hey @nik.baleca,

Yeah, I have tried that. I get this error:

[nik.baleca]

I see, that is quite weird.

For your Okta Workforce connection, are you using a front_channel connection or a back_channel channel?

And just to confirm, you have configured an OIDC connection or an Okta Workforce Enterprise connection?

If it is an Okta Workforce Enterprise Connection, could you please try the following user mapping?

{
  "attribute_map": {
       "mapping_mode": "bind_all",
       "userinfo_scope": "openid email profile groups",
       "attributes": {
            "name": "${context.tokenset.name}",
            "email": "${context.tokenset.email}",
            "username": "${context.tokenset.preferred_username}",
            "federated_groups": "${context.userinfo.groups}",
            "federated_locale": "${context.userinfo.locale}",
            "federated_zoneinfo": "${context.userinfo.zoneinfo}"
     }
   }
}

Kind Regards,
Nik

[davidhouseknechtdev]

Thanks @nik.baleca, I was able to save that configuration you listed. I am waiting to hear back from our partner to try the login connection again. I will let you know what comes of that.

As far as your other questions:

• We have an Okta Workforce Enterprise connection setup
• I don’t know how to tell if we are using a front_channel or a back_channel login

[nik.baleca]

Great!

Since you are using Okta Workforce Enterprise connection and not an OIDC one, you do not have the option for front_channel or back_channel communication so you can disregard that.

Looking forward to your reply!

Kind Regards,
Nik

[davidhouseknechtdev]

Hey @nik.baleca!

Our partner was able to try this out last night. Unfortunately, it looks like it didn’t work and even regressed a little bit. We still don’t have the groups showing up on the user’s object after authenticating, but now we don’t have the federated_locale or federated_zoneinfo either.

Are there any other steps I could try?

[nik.baleca]

Hi there,

Thanks for the update!

I will look further into the issue regarding possible solutions, usually, the groups should be returned as long as the user has assigned groups.

You can also try the following mapping:

{
"attributes": {
"name": "${context.tokenset.name}",
"email": "${context.tokenset.email}",
"username": "${context.tokenset.preferred_username}",
"groups": "${context.userinfo.groups}",
"federated_locale": "${context.userinfo.locale}",
"federated_groups": "${context.userinfo.groups}",
"federated_zoneinfo": "${context.userinfo.zoneinfo}"
},
"mapping_mode": "use_map",
"userinfo_scope": "openid email profile groups"
}

Also, under the connection’s settings, do you have the following scopes set?

openid profile email groups

In the meantime, you can implement an OIDC enterprise connection instead of an Okta Workforce one and use the following settings:

• Front channel communication with bind_all mapping method: this should map the groups as a string
• Front channel communication with use_map mapping method: this should map the groups as an array

When setting up the connection metadata, for the issuer attributed you can try using /oauth2/default/.well-known/openid-configuration endpoint instead of the /oauth2/default/ if you are having issues with retrieving the groups.

I will come back with an update as soon as possible!

Kind Regards,
Nik

[davidhouseknechtdev]

Thanks @nik.baleca. Yes, we have that mapping already set and the groups sent in the scopes.

I was hoping to avoid using a standard OIDC or SAML enterprise connection since the Okta Workforce connection doesn’t count against our quota for enterprise connections. I may still give this a shot, though, just to verify.

Keep me posted on anything else you all may find and/or other things I can try.

[nik.baleca]

Alright!

However, have you tried the proposed mapping above?

You can also try the following mapping:

{
"attributes": {
"name": "${context.tokenset.name}",
"email": "${context.tokenset.email}",
"username": "${context.tokenset.preferred_username}",
"groups": "${context.userinfo.groups}",
"federated_locale": "${context.userinfo.locale}",
"federated_groups": "${context.userinfo.groups}",
"federated_zoneinfo": "${context.userinfo.zoneinfo}"
},
"mapping_mode": "use_map",
"userinfo_scope": "openid email profile groups"
}

I will be looking forward to an update.

Kind Regrds,
Nik

[davidhouseknechtdev]

Sorry, I should have clarified – we have tried that mapping. It is very similar to the mapping we began with and caused us to report the issue. The only difference between the one you sent and the one we used was this extra line:

"groups": "${context.userinfo.groups}"

However, that appears to be just a duplicate of what we had:

"federated_groups": "${context.userinfo.groups}"

[nik.baleca]

Hi @davidhouseknechtdev

Regarding the issue at hand, are the group claims being sent from your Okta application in the token?

You can review this documentation from Okta about sending the groups in the token:

• Customize tokens returned from Okta with a groups claim | Okta Developer

Basically, you would need to go to the Okta application → Sign on tab → OIDC ID Token → Edit → Group Claims Filter → Use the name groups → Select Matches Regex → Type .*

This will return the groups in a string not in an array.

Let me know if this works.

Kind Regards,
Nik