Okta
Create the Sentisec application in Okta over SAML 2.0 or OIDC, and map the attributes Sentisec needs.
This is the Okta half of the hosted SSO setup. Start at Single Sign-On — you need our service-provider details before the values below have anything to go in them.
SAML 2.0
Okta Admin → Applications → Create App Integration → SAML 2.0. Name it Sentisec.
Single sign-on URL — the ACS URL we sent you. Audience URI (SP Entity ID) — the entity id we sent you. Leave the name-id format as EmailAddress.
Attribute statements. Map three, using exactly these names:
| Name | Value |
|---|---|
email | user.email |
firstName | user.firstName |
lastName | user.lastName |
Add a group attribute statement named groups only if you plan to
drive roles from Okta groups.
Assign the app to the users or groups who should have access. Okta will not send an assertion for anyone unassigned.
Copy the metadata URL from the Sign On tab and send it to us. That one URL carries the certificate and endpoints, and it lets certificate rotation happen without a second round trip.
OIDC
Create App Integration → OIDC → Web Application.
Sign-in redirect URI — the redirect URI we sent you. Grant type: authorization code.
Scopes — openid, profile, email.
Send us the client id, the client secret, and your Okta issuer
URL (https://<your-org>.okta.com/oauth2/default, or your custom
authorization server).
Roles
Sentisec has two roles, admin and member. If you want Okta to decide which one a person gets, tell us which group should map to admin when you send the metadata; everyone else resolves to member.
Verify
Sign in as a test user from the Okta dashboard tile. They should land in the Sentisec dashboard with the workspaces their membership grants. If sign-in fails, the usual causes are an unassigned user, an attribute name that does not match the table above, or a stale metadata URL after a certificate rotation.
Related
- Single Sign-On — the end-to-end flow
- SCIM provisioning — automate account lifecycle
- Roles and permissions