Skip to content
FluxGate

Enterprise · FluxGate with Okta

People sign in

People sign in with Okta and land in the account Okta created, with the role and team their group gives them, and nothing more.

3:56 videoBuilds on:Groups, roles and teams

Before you start

  • The provider okta is enabled with role sync mode SCIM, and the three people exist in FluxGate with their roles (Groups, roles and teams).
  • The team Routing has a flag (smart-dispatch in the example) on a pipeline with an approval policy that requires the Approver role. See Approvals and policies.
  • Use a private browser window for each person, so one person's Okta session does not sign in the next one.

What happens at sign-in

  1. The person clicks Sign in with Okta on the FluxGate login page.
  2. Okta checks the password and any second factor your Okta policy requires. FluxGate never sees the password.
  3. Okta sends the person back to FluxGate, which shows Signing you in and opens the overview.
  4. On the first sign-in, FluxGate links the sign-in to the account Okta created, through the link pair sub to externalId. It does not create a second account. The audit log records sso_identity_linked with "via": "scim".

The Account menu (the avatar at the top right) shows who is signed in and the roles of that person, for example Admin, Approver or Requester.

Sign in as each person

  1. Open /login in a private window and click Sign in with Okta. Sign in at Okta as maya@brightwater.example. The Account menu shows Admin, and the sidebar shows Settings.
  2. Click Log out in the Account menu. Close the private window.
  3. In a new private window, sign in as lena@brightwater.example Requester. The Account menu shows Requester, there is no Settings group, and Select team shows Routing.
  4. Open Features, then smart-dispatch, and edit it. Select the stage Development, open Actions and click Request Deployment. The toast "Stage change requested" appears.
  5. Open Approvals. The request is Pending, and Approve is disabled for lena.
  6. Log out, close the window, and sign in in a new private window as ravi@brightwater.example Approver. The Account menu shows Approver.
  7. Open Approvals, open the request, and click Approve. The toast "Approval recorded" appears. On smart-dispatch, Actions now offers Deploy.

As admin System admin, open Audit Log (/dashboard/audit-log). Each first sign-in has an entry of type sso_identity_linked. Open one: its data shows "via": "scim".

Good to know

  • A person without the Approver role sees Approve disabled, not hidden. A requester can never approve their own request.
  • Signing out of FluxGate does not sign the person out of Okta. On a shared computer, sign out of Okta too.
  • Role changes made in Okta apply to an open session when its access token renews. A new sign-in applies them at once.

Troubleshooting

"No FluxGate account exists for you. Ask an administrator."

Okta has not provisioned the person, or the link pair does not match. Check that the person is in a group assigned to the provisioning app, and that the link pair is sub to externalId.

The next person is signed in as the previous one

Okta still has the previous session in that browser. Use a new private window, or sign out of Okta.

Next

Joiner, profile change, mover, leaver and rehire, all from Okta: Lifecycle.