Platform › Access & Security
Access
Who may sign in, which directory vouches for them, what they may reach once they are in, who is signed in at this moment, the duties that must not be combined, administrator authority borrowed for a fixed window, and one person’s identity borrowed for another to debug with.
In Platform → Access & Security · 9 screens
WorkspaceUsersWho may sign in, which roles they hold, and where they are allowed to work.AdminOpenWorkspaceService AccountsIdentities for software. They hold roles like a person but cannot sign in to the console and are never asked for a second step: a secret, shown once, is exchanged for a short-lived token.OpenWorkspaceRolesWhat a role may reach: modules, locations and warehouses.AdminOpenWorkspaceSingle Sign-OnOne connection per directory — SAML 2.0 and OpenID Connect sign people in; OAuth 2.0, WS-Federation, CAS, LDAP and the rest are described — and the email domains each of them answers for, the directory’s MFA and the roles its groups give.OpenWorkspaceProvisioning (SCIM)Your directory creates, changes and deactivates people here through SCIM 2.0, with a token made on this screen and shown once. Groups it pushes give the roles you choose.OpenWorkspaceWeb & User SessionsEvery web session and every signed-in person, with what each is doing now. Sign out one, several, a person, or everybody else.OpenWorkspaceSegregation of DutiesPairs of duties that should not sit with one person, and who currently holds both. Administrators are exempt — they hold every grant by definition.AdminOpenWorkspaceElevated AccessAdministrator authority borrowed for a fixed window, against a written reason, a ticket and two approvals. It ends on its own.OpenWorkspaceAssumed IdentitySigning in as another person to reproduce their transaction, for a fixed window, against a written reason, a ticket and two approvals. Read-only unless it was approved otherwise, an administrator can never be the subject, and every call made with it is recorded and readable afterwards.Open
Columns, fields and actions
| Screen | Kind | What it is | Columns | Fields | Actions |
|---|---|---|---|---|---|
| Users | Workspace | Who may sign in, which roles they hold, and where they are allowed to work. | 0 | 0 | 0 |
| Service Accounts | Workspace | Identities for software. They hold roles like a person but cannot sign in to the console and are never asked for a second step: a secret, shown once, is exchanged for a short-lived token. | 0 | 0 | 0 |
| Roles | Workspace | What a role may reach: modules, locations and warehouses. | 0 | 0 | 0 |
| Single Sign-On | Workspace | One connection per directory — SAML 2.0 and OpenID Connect sign people in; OAuth 2.0, WS-Federation, CAS, LDAP and the rest are described — and the email domains each of them answers for, the directory’s MFA and the roles its groups give. | 0 | 0 | 0 |
| Provisioning (SCIM) | Workspace | Your directory creates, changes and deactivates people here through SCIM 2.0, with a token made on this screen and shown once. Groups it pushes give the roles you choose. | 0 | 0 | 0 |
| Web & User Sessions | Workspace | Every web session and every signed-in person, with what each is doing now. Sign out one, several, a person, or everybody else. | 0 | 0 | 0 |
| Segregation of Duties | Workspace | Pairs of duties that should not sit with one person, and who currently holds both. Administrators are exempt — they hold every grant by definition. | 0 | 0 | 0 |
| Elevated Access | Workspace | Administrator authority borrowed for a fixed window, against a written reason, a ticket and two approvals. It ends on its own. | 0 | 0 | 0 |
| Assumed Identity | Workspace | Signing in as another person to reproduce their transaction, for a fixed window, against a written reason, a ticket and two approvals. Read-only unless it was approved otherwise, an administrator can never be the subject, and every call made with it is recorded and readable afterwards. | 0 | 0 | 0 |