Feature: support for group management with okta

[shiv-tyagi]

Is there an existing request for this feature?

• I have searched the existing issues and found none that matched mine

Describe the feature

I’m looking into adding support for retrieving groups from the Okta provider and wanted to clarify a few design questions before moving forward.

In Okta, there are two authorization server options:

• The Org Authorization Server (the built-in server for the org).
  (e.g. https://{yourOktaDomain}/oauth2/v1/authorize)
• Custom Authorization Servers, which are more flexible and configurable.
  (e.g. https://{yourOktaDomain}/oauth2/{authorizationServerId}/v1/authorize)

With the Org Authorization Server, we can configure the groups claim under the application to return groups matching a regex with the id_token when groups scope is requested.

With the above configuration, the id_token contains the group names matching the regex and the list looks like,

With a Custom Authorization Server also, we can define a groups scope and a corresponding groups claim matching groups via regex.

The id_token similar to org auth server case also contains the group names matching the regex,

In both cases, it’s also possible to customise the groups claim to return a value such as <group-id>:<group-name>, instead of just the group name.

For org auth server,

For custom auth server,

Before proceeding with implementation, I’d like feedback on the following:

1. Should we introduce a dedicated authd broker for Okta to handle this properly, or should we extend the existing generic broker to support this?
2. Do we want to support only group names, or should we allow a custom expression that can include group IDs as well (for example <group-id>:<group-name>)?

Here is a doc from okta which I followed while trying this out.
https://developer.okta.com/docs/guides/customize-tokens-groups-claim/main/

Describe the ideal solution

1. I feel adding a dedicated broker for okta is the right thing as the implementation of the feature would be okta specific and not generic mostly.
2. I feel that allowing a custom expression that returns both the group ID and the group name could be useful in the long run. It would give us more stability if group names are renamed in Okta. And I already verified that it is possible with both org and custom authorisation servers.

Alternatives and current workarounds

No response

[shiv-tyagi]

Hey @adombeck @denisonbarbosa @3v1n0,

Please give your views on this whenever you get time. I have spent good enough time on experimenting with the okta provider. I can start working on it once I get some direction from your side. I am really excited about the okta broker honestly.

Thanks in advance!

[adombeck]

Thanks a lot for the research @shiv-tyagi , this is very useful!

Before proceeding with implementation, I’d like feedback on the following:

1. Should we introduce a dedicated authd broker for Okta to handle this properly, or should we extend the existing generic broker to support this?

In my opinion, that depends on whether it's feasible to implement the group support in a way that is compatible with different IdPs. So before implementing this, I'm afraid we need more research into how other IdPs support groups. Other IdPs I think we should check are Google (they do have some sort of support for groups if I remember correctly, but we didn't spend much time looking into it yet), Keycloak and Authentik.

2. Do we want to support only group names, or should we allow a custom expression that can include group IDs as well (for example <group-id>:<group-name>)?

It's great if we can get a unique identifier of the group that remains the same when the group is renamed. We can use that as the "UGID" of the group. If an IdP can't give us such a UGID then we can't detect renames of the group. That means the authd user will be removed from the old group and added to a new group with a new GID, and files owned by the old group might become inaccessible.

[3v1n0]

On 1. I think it would be best to have an Okta-specific broker whenever we can provide a good support for it so that we can publicly and "officially" support it.

2. is indeed good, unless the mo<de is not changed, that would rely to groups not matching (e.g. if you switch from ID:GROUP mode to GROUP and vice versa).

[shiv-tyagi]

Thanks for replying @adombeck @3v1n0.

I tried exploring more for the support of custom group claims in google, keycloak and authentic.

i. For google, I could not find an easy way to return a user's group info in access_token, id_token or /userinfo endpoint.
ii. Authentik seems to have a similar way to map groups claim to a custom expression like that in okta.
https://docs.goauthentik.io/add-secure-apps/providers/property-mappings/#scope-mappings-with-oauth2
https://docs.goauthentik.io/add-secure-apps/providers/property-mappings/expression/
iii. Keycloak also seems to support returning group information using similar mappers. https://www.keycloak.org/docs/latest/server_admin/index.html#_mappers

I am yet to try out authentik and keycloak for the above functionality. I will try to make some time and see how they work. I will post here if we can get the group names and ids in access token claims in a similar way we can get in Okta.