A clear division of tasks
Three parties, three tasks: the identity provider shows the sign-in page, checks password and second factor, holds the session and issues the sign-in credential. CIAS keeps users, tenants, roles and groups as business records and decides who may grant a right. The application enforces what a role permits on the data.
CIAS never sees a password. Even when CIAS sends the mail with the link for setting a password, the person types it in at the identity provider.
One direction for writing rights
Rights always flow in one direction: the application declares its roles and attributes to CIAS, CIAS writes roles, groups and attributes into the identity provider, and from there they come back at sign-in. Only CIAS writes rights. That keeps every grant traceable and lets the ceiling be checked reliably whenever rights are passed on.
Every object in CIAS has its own identifier; the identity provider’s identifier is stored alongside only as a reference. Your users, tenants and roles therefore survive a change of sign-in service.
Replaceable through adapters
None of the business modules – registration, users, roles, tenants – knows the identity provider. They only describe what is needed, such as “create an account” or “grant this role in this tenant”. The how lives in a single adapter. A different identity provider means a new adapter, not new business logic. Which sign-in services are supported in your setup is something we clarify in the technical fit conversation.
Access with precisely named rights
The Hub derives from your assembly which clients your identity provider must provide for the built system:
- one client per application that checks sign-in credentials and administers nothing itself,
- an administration client CIAS uses to create accounts, roles, groups and organisations – with precisely named rights,
- optionally a client for password links: the identity provider issues the link, CIAS writes the mail around it.
Reconciliation with restraint
At start-up and on request, CIAS brings roles, profile attributes and the names of the sign-in levels in the identity provider up to date. Reconciliation creates and retires, but never deletes and never grants. Groups that CIAS did not create itself are left alone; existing ones can be taken over deliberately. If the identity provider is unreachable at start-up, the application starts anyway and reports what is still open.