github.com/argoproj/argo-cd/v3@v3.2.1/docs/operator-manual/user-management/okta.md (about) 1 # Okta 2 3 !!! note "Are you using this? Please contribute!" 4 If you're using this IdP please consider [contributing](../../developer-guide/docs-site.md) to this document. 5 6 A working Single Sign-On configuration using Okta via at least two methods was achieved using: 7 8 * [SAML (with Dex)](#saml-with-dex) 9 * [OIDC (without Dex)](#oidc-without-dex) 10 11 ## SAML (with Dex) 12 13 !!! note "Okta app group assignment" 14 The Okta app's **Group Attribute Statements** regex will be used later to map Okta groups to Argo CD RBAC roles. 15 16 1. Create a new SAML application in Okta UI. 17 *  18 I've disabled `App Visibility` because Dex doesn't support Provider-initiated login flows. 19 *  20 1. Click `View setup instructions` after creating the application in Okta. 21 *  22 1. Copy the Argo CD URL to the `argocd-cm` in the data.url 23 24 <!-- markdownlint-disable MD046 --> 25 ```yaml 26 data: 27 url: https://argocd.example.com 28 ``` 29 <!-- markdownlint-disable MD046 --> 30 31 1. Download the CA certificate to use in the `argocd-cm` configuration. 32 * If you are using this in the caData field, you will need to pass the entire certificate (including `-----BEGIN CERTIFICATE-----` and `-----END CERTIFICATE-----` stanzas) through base64 encoding, for example, `base64 my_cert.pem`. 33 * If you are using the ca field and storing the CA certificate separately as a secret, you will need to mount the secret to the `dex` container in the `argocd-dex-server` Deployment. 34 *  35 1. Edit the `argocd-cm` and configure the `data.dex.config` section: 36 37 <!-- markdownlint-disable MD046 --> 38 ```yaml 39 dex.config: | 40 logger: 41 level: debug 42 format: json 43 connectors: 44 - type: saml 45 id: okta 46 name: Okta 47 config: 48 ssoURL: https://yourorganization.oktapreview.com/app/yourorganizationsandbox_appnamesaml_2/rghdr9s6hg98s9dse/sso/saml 49 # You need `caData` _OR_ `ca`, but not both. 50 caData: | 51 <CA cert passed through base64 encoding> 52 # You need `caData` _OR_ `ca`, but not both. 53 # Path to mount the secret to the dex container 54 ca: /path/to/ca.pem 55 redirectURI: https://ui.argocd.yourorganization.net/api/dex/callback 56 usernameAttr: email 57 emailAttr: email 58 groupsAttr: group 59 ``` 60 <!-- markdownlint-enable MD046 --> 61 62 ---- 63 64 ### Private deployment 65 It is possible to setup Okta SSO with a private Argo CD installation, where the Okta callback URL is the only publicly exposed endpoint. 66 The settings are largely the same with a few changes in the Okta app configuration and the `data.dex.config` section of the `argocd-cm` ConfigMap. 67 68 Using this deployment model, the user connects to the private Argo CD UI and the Okta authentication flow seamlessly redirects back to the private UI URL. 69 70 Often this public endpoint is exposed through an [Ingress object](../../ingress/#private-argo-cd-ui-with-multiple-ingress-objects-and-byo-certificate). 71 72 73 1. Update the URLs in the Okta app's General settings 74 *  75 The `Single sign on URL` field points to the public exposed endpoint, and all other URL fields point to the internal endpoint. 76 1. Update the `data.dex.config` section of the `argocd-cm` ConfigMap with the external endpoint reference. 77 78 <!-- markdownlint-disable MD046 --> 79 ```yaml 80 dex.config: | 81 logger: 82 level: debug 83 connectors: 84 - type: saml 85 id: okta 86 name: Okta 87 config: 88 ssoURL: https://yourorganization.oktapreview.com/app/yourorganizationsandbox_appnamesaml_2/rghdr9s6hg98s9dse/sso/saml 89 # You need `caData` _OR_ `ca`, but not both. 90 caData: | 91 <CA cert passed through base64 encoding> 92 # You need `caData` _OR_ `ca`, but not both. 93 # Path to mount the secret to the dex container 94 ca: /path/to/ca.pem 95 redirectURI: https://external.path.to.argocd.io/api/dex/callback 96 usernameAttr: email 97 emailAttr: email 98 groupsAttr: group 99 ``` 100 <!-- markdownlint-enable MD046 --> 101 102 ### Connect Okta Groups to Argo CD Roles 103 Argo CD is aware of user memberships of Okta groups that match the *Group Attribute Statements* regex. 104 The example above uses the `argocd-*` regex, so Argo CD would be aware of a group named `argocd-admins`. 105 106 Modify the `argocd-rbac-cm` ConfigMap to connect the `argocd-admins` Okta group to the builtin Argo CD `admin` role. 107 <!-- markdownlint-disable MD046 --> 108 ```yaml 109 apiVersion: v1 110 kind: ConfigMap 111 metadata: 112 name: argocd-rbac-cm 113 data: 114 policy.csv: | 115 g, argocd-admins, role:admin 116 scopes: '[email,groups]' 117 ``` 118 119 ## OIDC (without Dex) 120 121 !!! warning "Okta groups for RBAC" 122 If you want `groups` scope returned from Okta, you will need to enable [API Access Management with Okta](https://developer.okta.com/docs/concepts/api-access-management/). This addon is free, and automatically enabled, on Okta developer edition. However, it's an optional add-on for production environments, with an additional associated cost. 123 124 You may alternately add a "groups" scope and claim to the default authorization server, and then filter the claim in the Okta application configuration. It's not clear if this requires the Authorization Server add-on. 125 126 If this is not an option for you, use the [SAML (with Dex)](#saml-with-dex) option above instead. 127 128 !!! note 129 These instructions and screenshots are of Okta version 2023.05.2 E. You can find the current version in the Okta website footer. 130 131 First, create the OIDC integration: 132 133 1. On the `Okta Admin` page, navigate to the Okta Applications at `Applications > Applications.` 134 1. Choose `Create App Integration`, and choose `OIDC`, and then `Web Application` in the resulting dialogues. 135  136 1. Update the following: 137 1. `App Integration name` and `Logo` - set these to suit your needs; they'll be displayed in the Okta catalogue. 138 1. `Sign-in redirect URLs`: Add `https://argocd.example.com/auth/callback`; replacing `argocd.example.com` with your ArgoCD web interface URL. 139 1. `Sign-out redirect URIs`: Add `https://argocd.example.com`; substituting the correct domain name as above. 140 1. Either assign groups, or choose to skip this step for now. 141 1. Leave the rest of the options as-is, and save the integration. 142  143 1. Copy the `Client ID` and the `Client Secret` from the newly created app; you will need these later. 144 145 Next, create a custom Authorization server: 146 147 1. On the `Okta Admin` page, navigate to the Okta API Management at `Security > API`. 148 1. Click `Add Authorization Server`, and assign it a name and a description. The `Audience` should match your ArgoCD URL - `https://argocd.example.com` 149 1. Click `Scopes > Add Scope`: 150 1. Add a scope called `groups`. Leave the rest of the options as default. 151  152 1. Click `Claims > Add Claim`: 153 1. Add a claim called `groups`. 154 1. Adjust the `Include in token type` to `ID Token`, `Always`. 155 1. Adjust the `Value type` to `Groups`. 156 1. Add a filter that will match the Okta groups you want passed on to ArgoCD; for example `Regex: argocd-.*`. 157 1. Set `Include in` to `groups` (the scope you created above). 158  159 1. Click on `Access Policies` > `Add Policy.` This policy will restrict how this authorization server is used. 160 1. Add a name and description. 161 1. Assign the policy to the client (application integration) you created above. The field should auto-complete as you type. 162 1. Create the policy. 163  164 1. Add a rule to the policy: 165 1. Add a name; `default` is a reasonable name for this rule. 166 1. Fine-tune the settings to suit your organization's security posture. Some ideas: 167 1. uncheck all the grant types except the Authorization Code. 168 1. Adjust the token lifetime to govern how long a session can last. 169 1. Restrict refresh token lifetime, or completely disable it. 170  171 1. Finally, click `Back to Authorization Servers`, and copy the `Issuer URI`. You will need this later. 172 173 ### CLI login 174 175 In order to login with the CLI `argocd login https://argocd.example.com --sso`, Okta requires a separate dedicated App Integration: 176 177 1. Create a new `Create App Integration`, and choose `OIDC`, and then `Single-Page Application`. 178 1. Update the following: 179 1. `App Integration name` and `Logo` - set these to suit your needs; they'll be displayed in the Okta catalogue. 180 1. `Sign-in redirect URLs`: Add `http://localhost:8085/auth/callback`. 181 1. `Sign-out redirect URIs`: Add `http://localhost:8085`. 182 1. Either assign groups, or choose to skip this step for now. 183 1. Leave the rest of the options as-is, and save the integration. 184 1. Copy the `Client ID` from the newly created app; `cliClientID: <Client ID>` will be used in your `argocd-cm` ConfigMap. 185 1. Edit your Authorization Server `Access Policies`: 186 1. Navigate to the Okta API Management at `Security > API`. 187 1. Choose your existing `Authorization Server` that was created previously. 188 1. Click `Access Policies` > `Edit Policy`. 189 1. Assign your newly created `App Integration` by filling in the text box and clicking `Update Policy`. 190  191 192 If you haven't yet created Okta groups, and assigned them to the application integration, you should do that now: 193 194 1. Go to `Directory > Groups` 195 1. For each group you wish to add: 196 1. Click `Add Group`, and choose a meaningful name. It should match the regex or pattern you added to your custom `group` claim. 197 1. Click on the group (refresh the page if the new group didn't show up in the list). 198 1. Assign Okta users to the group. 199 1. Click on `Applications` and assign the OIDC application integration you created to this group. 200 1. Repeat as needed. 201 202 Finally, configure ArgoCD itself. Edit the `argocd-cm` configmap: 203 204 <!-- markdownlint-disable MD046 --> 205 ```yaml 206 url: https://argocd.example.com 207 oidc.config: | 208 name: Okta 209 # this is the authorization server URI 210 issuer: https://example.okta.com/oauth2/aus9abcdefgABCDEFGd7 211 clientID: 0oa9abcdefgh123AB5d7 212 cliClientID: gfedcba0987654321GEFDCBA # Optional if using the CLI for SSO 213 clientSecret: ABCDEFG1234567890abcdefg 214 requestedScopes: ["openid", "profile", "email", "groups"] 215 requestedIDTokenClaims: {"groups": {"essential": true}} 216 ``` 217 218 You may want to store the `clientSecret` in a Kubernetes secret; see [how to deal with SSO secrets](./index.md/#sensitive-data-and-sso-client-secrets ) for more details.