Integration / Identity
Okta, routed by jurisdiction.
Sign in to the YTT Secunet console with Okta over SAML 2.0 and provision users and groups with SCIM 2.0, so access to policy packs, receipts and audit exports follows your identity lifecycle. Available on Enterprise Sovereign and Sovereign Dedicated.
Okta is a widely used workforce identity provider. Administrators add applications to Okta as app integrations: for single sign-on, Okta acts as a SAML 2.0 identity provider that signs assertions for the application, and for lifecycle management it acts as a SCIM client, calling the application's SCIM 2.0 endpoints to create, update and deactivate users and to push groups. Both are configured in the Okta Admin Console, where a custom SAML app integration takes the application's single sign-on URL and audience URI, and its Provisioning tab takes a SCIM connector base URL and an authentication method.
In YTT Secunet the console is the SAML service provider and exposes a SCIM 2.0 endpoint for each organisation. Okta groups map to console roles: organisation administrators, policy authors who draft Rego and visual policies, policy approvers who publish them, and read-only auditors who can view receipts and download evidence packages. A policy author cannot approve their own change, so separation of duties on the policy plane follows group membership in Okta. When Okta deactivates a user, YTT Secunet ends their sessions and revokes their personal access tokens at once, and flags any service API keys they created for reassignment, so production traffic does not stop because one person left.
Two residency points belong in your records. Okta stores your directory in the cell your org was provisioned on; Okta runs cells in the US, EMEA and other regions, and Okta, Inc. is a US-headquartered company. YTT Secunet receives only what the assertions and SCIM calls carry (name, work email, group membership and the Okta user identifier) and stores it in the EU control plane in Frankfurt am Main, with a standby in Paris. On Sovereign Dedicated the console and its SCIM endpoint run inside your environment; if Okta cannot reach that endpoint, use SAML just-in-time provisioning and remove leavers through scheduled access reviews instead.
| Region or deployment | Location | Jurisdiction |
|---|---|---|
| EU control plane, primary (console and SCIM endpoint) | Frankfurt am Main, Germany | EU / European Union |
| EU control plane, standby | Paris, France | EU / European Union |
| Sovereign Dedicated in-country control plane | Customer VPC, Zurich | CH / Switzerland |
- 01
In the Okta Admin Console, create a SAML 2.0 app integration for YTT Secunet and enter the single sign-on URL and audience URI shown on the SSO page of the YTT Secunet console.
- 02
Add attribute statements for email, first name and last name, and a group attribute statement that sends only groups whose names start with jr-.
- 03
Paste the app's identity provider metadata URL into the YTT Secunet console and map each jr- group to a console role.
- 04
Test sign-in with one user from each group, then switch on Require SSO in YTT Secunet and keep a single hardware-key break-glass account outside Okta.
- 05
In the app's General settings, enable SCIM provisioning. On the Provisioning tab, enter the YTT Secunet SCIM connector base URL, userName as the unique identifier field, and HTTP Header authentication with a token generated in the YTT Secunet console.
- 06
Under provisioning to the app, enable creating users, updating user attributes and deactivating users, then push the jr- groups.
# YTT Secunet console: SSO and SCIM for organisation acme-gmbh
sso:
protocol: saml2
sp_entity_id: https://yttsecunet.com/sso/acme-gmbh
acs_url: https://yttsecunet.com/sso/acme-gmbh/acs
idp_metadata_url: https://acme.okta.com/app/<app-id>/sso/saml/metadata
name_id_format: emailAddress
require_sso: true
attributes:
email: user.email
given_name: user.firstName
family_name: user.lastName
groups: groups # Okta group attribute statement, filter: starts with jr-
role_mapping:
jr-org-admins: org_admin
jr-policy-authors: policy_author
jr-policy-approvers: policy_approver
jr-auditors: auditor_read_only
scim:
base_url: https://yttsecunet.com/scim/v2/acme-gmbh
auth: bearer_token # Okta authentication mode: HTTP Header
token: vault://okta/scim
on_deactivate: [end_sessions, revoke_personal_tokens, flag_service_keys]- Publishing a policy change needs a member of the approver group other than its author, so separation of duties follows Okta group membership rather than a separate list.
- Every console sign-in, role change and SCIM operation is written to the audit log with the Okta user identifier, next to the policy change history.
- Removing a user from a jr- group in Okta removes the matching role at the next SCIM update; deactivation ends sessions immediately.
- SSO governs the console only. Applications authenticate to the gateway with API keys scoped to tenants and policy packs, not with user sessions.
Which plans include Okta SSO and SCIM?
SAML SSO and SCIM are included in Enterprise Sovereign and Sovereign Dedicated. They are not available on Growth.
Does Okta see our prompts or policy content?
No. Okta handles authentication and provisioning for the console. Prompts flow through the data plane and policy content stays in the YTT Secunet control plane; Okta sees which users sign in to the console and when.
What happens to API keys when someone leaves?
Personal access tokens are revoked on deactivation. Service API keys the person created keep working and are flagged for reassignment to a new owner, so production traffic does not fail because of an HR event.
Sovereign route ready
Stop risking 4% global turnover GDPR fines on AI inference.
Deploy sovereign, cryptographically proven AI routing in 15 minutes.