|
| 1 | +# Configuring Custom Claims/Scopes with Okta for group/role |
| 2 | + |
| 3 | +<div style="pad: 0px; margin: 0px;"> |
| 4 | + <span style="vertical-align:middle;">Author: </span> |
| 5 | + <a href="https://github.com/Emyrk" style="text-decoration: none; color: inherit; margin-bottom: 0px;"> |
| 6 | + <span style="vertical-align:middle;">Steven Masley</span> |
| 7 | + <img src="https://avatars.githubusercontent.com/u/5446298?v=4" width="24px" height="24px" style="vertical-align:middle; margin: 0px;"/> |
| 8 | + </a> |
| 9 | +</div> |
| 10 | +December 13, 2023 |
| 11 | + |
| 12 | +--- |
| 13 | + |
| 14 | +> Okta is an identity provider that can be used for OpenID Connect (OIDC) Single |
| 15 | +> Sign On (SSO) on Coder. |
| 16 | +
|
| 17 | +To configure custom claims in Okta to support syncing roles and groups with |
| 18 | +Coder, you must first have setup an Okta application with |
| 19 | +[OIDC working with Coder](https://coder.com/docs/v2/latest/admin/auth#openid-connect). |
| 20 | +From here, we will add additional claims for Coder to use for syncing groups and |
| 21 | +roles. |
| 22 | + |
| 23 | +You may use a hybrid of the following approaches. |
| 24 | + |
| 25 | +# (Easiest) Sync using Okta Groups |
| 26 | + |
| 27 | +If the Coder roles & Coder groups can be inferred from |
| 28 | +[Okta groups](https://help.okta.com/en-us/content/topics/users-groups-profiles/usgp-about-groups.htm), |
| 29 | +Okta has a simple way to send over the groups as a `claim` in the `id_token` |
| 30 | +payload. |
| 31 | + |
| 32 | +In Okta, go to the application “Sign On” settings page. |
| 33 | + |
| 34 | +Applications > Select Application > General > Sign On |
| 35 | + |
| 36 | +In the “OpenID Connect ID Token” section, turn on “Groups Claim Type” and set |
| 37 | +the “Claim name” to `groups`. Optionally configure a filter for which groups to |
| 38 | +be sent. |
| 39 | + |
| 40 | +> !! If the user does not belong to any groups, the claim will not be sent. Make |
| 41 | +> sure the user authenticating for testing is in at least 1 group. Defer to |
| 42 | +> [troubleshooting](https://coder.com/docs/v2/latest/admin/auth#troubleshooting) |
| 43 | +> with issues |
| 44 | +
|
| 45 | + |
| 46 | + |
| 47 | +Configure Coder to use these claims for group sync. These claims are present in |
| 48 | +the `id_token`. See all configuration options for group sync in the |
| 49 | +[docs](https://coder.com/docs/v2/latest/admin/auth#group-sync-enterprise). |
| 50 | + |
| 51 | +```bash |
| 52 | +# Add the 'groups' scope. |
| 53 | +CODER_OIDC_SCOPES=openid,profile,email,groups |
| 54 | +# This name needs to match the "Claim name" in the configuration above. |
| 55 | +CODER_OIDC_GROUP_FIELD=groups |
| 56 | +``` |
| 57 | + |
| 58 | +These groups can also be used to configure role syncing based on group |
| 59 | +membership. |
| 60 | + |
| 61 | +```bash |
| 62 | +# Requires the "groups" scope |
| 63 | +CODER_OIDC_SCOPES=openid,profile,email,groups |
| 64 | +# This name needs to match the "Claim name" in the configuration above. |
| 65 | +CODER_OIDC_USER_ROLE_FIELD=groups |
| 66 | +# Example configuration to map a group to some roles |
| 67 | +CODER_OIDC_USER_ROLE_MAPPING='{"admin-group":["template-admin","user-admin"]}' |
| 68 | +``` |
| 69 | + |
| 70 | +# (Easy) Mapping Okta profile attributes |
| 71 | + |
| 72 | +If roles or groups cannot be completely inferred from Okta group memberships, |
| 73 | +another option is to source them from a user’s attributes. The user attribute |
| 74 | +list can be found in “Directory > Profile Editor > User (default)”. |
| 75 | + |
| 76 | +Coder can query an Okta profile for the application from the `/userinfo` OIDC |
| 77 | +endpoint. To pass attributes to Coder, create the attribute in your application, |
| 78 | +then add a mapping from the Okta profile to the application. |
| 79 | + |
| 80 | +“Directory > Profile Editor > {Your Application} > Add Attribute” |
| 81 | + |
| 82 | +Create the attribute for the roles, groups, or both. **Make sure the attribute |
| 83 | +is of type `string array`.** |
| 84 | + |
| 85 | + |
| 86 | + |
| 87 | +On the “Okta User to {Your Application}” tab, map a `roles` or `groups` |
| 88 | +attribute you have configured to the application. |
| 89 | + |
| 90 | + |
| 91 | + |
| 92 | +Configure using these new attributes in Coder. |
| 93 | + |
| 94 | +```bash |
| 95 | +# This must be set to false. Coder uses this endpoint to grab the attributes. |
| 96 | +CODER_OIDC_IGNORE_USERINFO=false |
| 97 | +# No custom scopes are required. |
| 98 | +CODER_OIDC_SCOPES=openid,profile,email |
| 99 | +# Configure the group/role field using the attribute name in the application. |
| 100 | +CODER_OIDC_USER_ROLE_FIELD=approles |
| 101 | +# See our docs for mapping okta roles to coder roles. |
| 102 | +CODER_OIDC_USER_ROLE_MAPPING='{"admin-group":["template-admin","user-admin"]}' |
| 103 | + |
| 104 | +# If you added an attribute for groups, set that here. |
| 105 | +# CODER_OIDC_GROUP_FIELD=... |
| 106 | +``` |
| 107 | + |
| 108 | +# (Advanced) Custom scopes to retrieve custom claims |
| 109 | + |
| 110 | +Okta does not support setting custom scopes and claims in the default |
| 111 | +authorization server used by your application. If you require this |
| 112 | +functionality, you must create (or modify) an authorization server. |
| 113 | + |
| 114 | +To see your custom authorization servers go to “Security > API”. Note the |
| 115 | +`default` authorization server **is not the authorization server your app is |
| 116 | +using.** You can configure this default authorization server, or create a new |
| 117 | +one specifically for your application. |
| 118 | + |
| 119 | +Authorization servers also give more refined controls over things such as |
| 120 | +token/session lifetimes. |
| 121 | + |
| 122 | + |
| 123 | + |
| 124 | +To get custom claims working, we should map them to a custom scope. Click the |
| 125 | +authorization server you wish to use (likely just using the default). |
| 126 | + |
| 127 | +Go to “Scopes”, and “Add Scope”. Feel free to create one for roles, groups, or |
| 128 | +both. |
| 129 | + |
| 130 | + |
| 131 | + |
| 132 | +Now create the claim to go with the said scope. Go to “Claims”, then “Add |
| 133 | +Claim”. Make sure to select **ID Token** for the token type. The **Value** |
| 134 | +expression is up to you based on where you are sourcing the role information. |
| 135 | +Lastly, configure it to only be a claim with the requested scope. This is so if |
| 136 | +other applications exist, we do not send them information they do not care |
| 137 | +about. |
| 138 | + |
| 139 | + |
| 140 | + |
| 141 | +Now we have a custom scope + claim configured under an authorization server, we |
| 142 | +need to configure coder to use this. |
| 143 | + |
| 144 | +```bash |
| 145 | +# Grab this value from the Authorization Server > Settings > Issuer |
| 146 | +# DO NOT USE the application issuer URL. Make sure to use the newly configured |
| 147 | +# authorization server. |
| 148 | +CODER_OIDC_ISSUER_URL=https://dev-12222860.okta.com/oauth2/default |
| 149 | +# Add the new scope you just configured |
| 150 | +CODER_OIDC_SCOPES=openid,profile,email,roles |
| 151 | +# Use the claim you just configured |
| 152 | +CODER_OIDC_USER_ROLE_FIELD=roles |
| 153 | +# See our docs for mapping okta roles to coder roles. |
| 154 | +CODER_OIDC_USER_ROLE_MAPPING='{"admin-group":["template-admin","user-admin"]}' |
| 155 | +``` |
| 156 | + |
| 157 | +You can use the “Token Preview” page to verify it has been correctly configured |
| 158 | +and verify the `roles` is in the payload. |
| 159 | + |
| 160 | + |
0 commit comments