Substrate documentation
2023.05
Source & Binary
Search
⌃K
Links

Integrating your Okta identity provider

substrate create-admin-account -quality <quality> will ask for several inputs, which this page will help you provide from your Okta identity provider.

Create a custom profile attribute

  1. 1.
    Visit your Okta admin panel in a browser
  2. 2.
    Click the hamburger menu
  3. 3.
    Click Profile Editor in the Directory section
  4. 4.
    Click User (default) (with type “Okta”)
  5. 5.
    Click + Add Attribute
  6. 6.
    Enter “AWS_RoleName” for both Display name and Variable name
  7. 7.
    Click Save

Create and configure an OAuth OIDC client

  1. 1.
    Visit your Okta admin panel in a browser
  2. 2.
    Click the hamburger menu
  3. 3.
    Click Applications in the Applications section
  4. 4.
    Click Create App Integration
  5. 5.
    Select “OAuth - OpenID Connect”
  6. 6.
    Select “Web Application”
  7. 7.
    Click Next
  8. 8.
    Customize App integration name
  9. 9.
    Change the first/only item in Sign-in redirect URIs to “https://intranet-dns-domain-name/login” (substituting your just-purchased or just-transferred Intranet DNS domain name)
  10. 10.
    Remove all Sign-out redirect URIs
  11. 11.
    Select “Limit access to selected groups” and select the groups that are authorized to use AWS (or choose another option; this can always be reconfigured)
  12. 12.
    Click Save
  13. 13.
    Paste the Client ID, Client secret, and Okta domain in response to substrate create-admin-account's prompts
  14. 14.
    Click Okta API Scopes
  15. 15.
    Click Grant at the end of the “okta.users.read.self” line

Authorize users to use AWS

  1. 1.
    Visit your Okta admin panel in a browser
  2. 2.
    Click the hamburger menu
  3. 3.
    Click People in the Directory section
  4. 4.
    For every user authorized to use AWS:
    1. 1.
      Click the user's name
    2. 2.
      Click Profile
    3. 3.
      Click Edit
    4. 4.
      In the AWS_RoleName input, enter the name (not the ARN) of the IAM role they should assume in your admin account (“Administrator” for yourself as you're getting started; if for others it's not “Administrator” or “Auditor”, ensure you've followed adding non-Administrator roles for humans first)
    5. 5.
      Click Save
With your identity provider integrated, jump to deleting unnecessary root access keys.
Previous
Integrating your Google identity provider
Next - Bootstrapping your Substrate-managed AWS organization
Deleting unnecessary root access keys
Last modified 25d ago