Platform · Identity & Access
One application. Every kind of user.
Staff, partners, contractors, and the public each sign in through the identity they already use, and one role model governs what every one of them can see and do.
Connect
Bring the identity provider you already run.
Your people already have an identity. Plant an App uses it, through OpenID Connect, the standard every major identity provider speaks.
- Microsoft Entra ID
- Okta
- Google Workspace
- Auth0
- Ping Identity
- Keycloak
- Amazon Cognito
- AD FS
Several providers, side by side.
Staff through one, partners through another, each with its own sign-in button, on the same application.
Existing accounts, matched automatically.
Known users are recognized by email on their first sign-in, and new ones are created as they arrive.
Sign-out that follows through.
Signing out of the application can sign out of the provider too, and mobile apps sign in through the same provider.
Map
Claims and directory groups become application roles.
Identity doesn’t stop at sign-in. What the provider or directory knows about a person (their groups, their department, their country) shapes what the application does for them.
From your identity provider
- groups: FinanceRoleApprovers
- departmentProfileDepartment
- countrySettingRegion
From Active Directory
- Grants-StaffRoleGrants officers
- IT-Service-DeskRoleSupport agents
Claims drive roles and settings.
Every claim the provider sends is available the moment someone signs in. Map it to roles, profile fields, or any user setting with the same actions used everywhere else.
Groups keep access current.
Map a directory group to a role, and access changes as people join, move, or leave, with nothing to update by hand.
The directory stays the source of truth.
People sign in with the account they use every day, and their profile details come across each time.
Sign-in can be limited to specific organizational units, disabled accounts stay out, and OpenLDAP directories work too.
Authorize
Signing in is the start. Roles decide the rest.
However someone signs in, they land in the same role model. Define access once, and the application enforces it everywhere, from the page someone opens to the record they’re allowed to change.
Applications · Permissions
| Role | Can View | Can Add | Can Edit | Can Delete |
|---|---|---|---|---|
| Applicant | Own Entries | Own Entries | None | |
| Reviewer | All Entries | All Entries | None | |
| Program manager | All Entries | All Entries | All Entries |
Down to the page.
Each page and section opens only for the roles allowed to see it.
Down to the record.
For each role: view, add, edit, or delete all entries, only its own, or none.
Down to the button.
Actions on a listing appear only for the roles allowed to use them.
Down to the API.
Callers present tokens from your identity provider, restricted by scope and role.
Several identities.One access model.
Builder roles are tiered too, so no one can assign a role above their own.
Welcome
Not every user belongs in your directory.
Residents, applicants, vendors, and volunteers aren’t in anyone’s directory. They get accounts of their own, with the safeguards a public sign-in needs.
Register.
Residents, applicants, and vendors create their own accounts, approved automatically or by a person. Or they arrive through a time-limited invitation that signs them straight in.
Protect.
Password rules for length, character types, and lockout after failed attempts. Recovery through a secure email link. CAPTCHA against automated sign-ups.
Open to the public, without seats.
Licensing is never per end user, so opening an application to residents or customers adds no seat costs.
Strengthen
More than a password, where it matters.
Match the protection to the audience and the risk: passwordless for the public, a second factor where the stakes are higher, smart cards where regulation demands them, and your provider’s own rules when sign-in goes through it.
Passkeys.
Windows Hello, Touch ID, a phone, or a hardware security key. No password to steal or phish. Convenient enough for the public.
Two-factor sign-in.
A one-time code by email or SMS as a second step, wherever the risk calls for it.
Certificates and smart cards.
Sign in with a client certificate or smart card, for regulated environments that require them.
Your provider’s policies.
When sign-in goes through your identity provider, its multi-factor and conditional access rules apply as they do everywhere else.
Record
Every sign-in is recorded. Any sign-in can start work.
Identity events are events like any other: logged for the people who audit access, and ready to start the workflows that follow from them.
Sign-in can start work.
Welcome a first-time user, refresh a profile, provision what they need, or alert someone the moment a person signs in.
Every sign-in logged.
Successful and failed attempts alike, in the same audit log administrators already use.
Access on someone’s behalf stays traceable.
Sign-in links record who created them, so every entry has a name behind it.
Related capabilities
Start with the users you already have.
Staff in Entra ID or Active Directory, partners in their own provider, the public on accounts of their own. Talk to us, and see them all signing in to one application.