SAML 2.0
SAML is how one system tells another who you are without sharing your password. For an assistant it is the mechanism that makes "answer only what this person may see" possible at all.
SAML is how one system tells another who you are without sharing your password. For an assistant it is the mechanism that makes "answer only what this person may see" possible at all.
What SAML 2.0 holds, and why that matters here
SAML is a long-established standard for federated sign-in. An organisation runs an identity provider; applications trust it; a user signs in once and applications receive a signed assertion describing who they are and what groups they belong to.
For an assistant, that assertion is the foundation of safe personal answers. It arrives from a source the organisation controls, it is signed so it cannot be forged, and it carries the attributes that determine entitlement.
- Assertions — the signed statement of who the user is.
- Attributes — group membership, department, role.
- Single sign-on — one authentication across applications.
- Single logout — ending a session everywhere.
- Trust configuration — the relationship between provider and application.
Questions a SAML assertion lets Elbi answer
Who is this person?
Established from a signed assertion rather than from anything typed in a chat.
What groups are they in?
Attributes that determine what may be disclosed.
Are they still signed in?
Session state, so a stale session does not become an access path.
Which department?
Attributes used for routing and entitlement.
Should this be visible to them?
Entitlement decided before the conversation rather than during it.
Has their access changed?
Attributes reflect the current position at each sign-in.
How Elbi works with a SAML identity provider
- Elbi is added as a service providerYour identity team adds Elbi as a new service provider in the identity provider you already run, such as AD FS, Entra ID, Okta, PingFederate or Shibboleth. The two sides exchange metadata: Elbi's entity ID and assertion consumer address one way, your provider's sign-in address and signing certificate the other.
- Sign-in is best started from Elbi's sideThe person is sent to your provider with a request and comes back with a signed response to that request. Service-provider-initiated sign-in is generally preferred, because a response tied to a specific request is harder to replay than an unsolicited one.
- The assertion is checked before it is usedSAML requires the service provider to verify the signature against the certificate in your metadata and to check the assertion's audience and validity window. That window is short, so the clocks on both sides need to be accurate.
- Attributes carry entitlementThe assertion carries whatever your provider is configured to release — usually a stable identifier, a name, and group or department. Nothing is sent that the provider's release rules do not allow.
- Changes arrive at the next sign-inSAML delivers attributes when someone signs in, not continuously. A group change or a disabled account takes effect at the next sign-in, which is why the length of Elbi's sessions is worth agreeing with your identity team.
- No accounts to provisionSAML identifies people; it does not create accounts. Elbi keeps no user list of its own, so there is nothing to provision or deprovision, and the identity provider remains the only place access is granted or removed.
Scope and control in a SAML trust
| Direction of access | Assertions flow from your identity provider to Elbi and nowhere else. Elbi reads them; it does not create, change or manage accounts. |
|---|---|
| Who can see what | Entitlement follows the attributes in each assertion. Most identity providers can also restrict which users may sign in to a given service provider, so someone outside the pilot group is refused by your provider directly. |
| Credentials | The trust rests on certificates rather than a shared password. Your provider's signing certificate is yours to roll over, and disabling or removing Elbi's service provider entry ends every sign-in at once. |
| Where data goes | Attributes decide what may be answered in the conversation at hand. Message content is destroyed within 24 hours — typically when the conversation closes — and never reaches an external AI service. |
| Audit | Your provider logs each sign-in to Elbi. Elbi can record which asserted identity each lookup ran under, giving you both halves of the trail. |
| If the provider is down | New sign-ins fail, and Elbi limits itself to answers that need no identity. An expired assertion is not reused. |
What this replaces
The reason to care about SAML in an assistant context is that it moves the identity question out of the conversation. An assistant that establishes who someone is by asking them is trivially manipulated; one that receives a signed assertion from the organisation's own identity provider cannot be.
It also means the assistant participates in existing session and access policy rather than sitting outside it. When someone leaves, when their role changes, when access is revoked, the assistant follows automatically because it never held its own view of entitlement.
For organisations with an established federation, this is usually the least disruptive way to connect an assistant to anything personal — the trust relationship is a configuration exercise rather than a new system.
Where SAML federation is already the norm
Large enterprises
Existing federation extended to the assistant.
Government
Where federated identity is already mandated.
Multi-application estates
One sign-in across many systems, including this one.
Any personal-data use case
The prerequisite for safely answering anything about an individual.
Getting value from a SAML connection
Organisations with established federation usually have a long list of applications behind the same sign-in. Adding Elbi to that list is a configuration exercise, so the real question is not the connection but which personal question to unlock first. The best candidate is the one staff currently ask a person because a chatbot cannot know who they are.
Next, look at what your provider already releases to other applications. The same attribute set — often an identifier, name, email and groups — can frequently be reused, and reusing an approved set shortens the security review. New attributes are worth adding for Elbi only when a specific answer needs them.
Finally, keep group attributes meaningful. Releasing every group a person belongs to makes assertions large and rules hard to read. A filtered list, or a small set of groups created for the assistant, keeps both manageable.
What connecting SAML 2.0 involves
- Exchange metadataImport Elbi's service provider metadata into your identity provider and supply your provider's metadata in return. Working from metadata files rather than hand-typed values avoids the commonest configuration mistakes.
- Choose the name identifierPick a persistent, stable identifier rather than an email address that may change. It is how the same person is recognised from one session to the next.
- Define attribute releaseConfigure exactly which attributes your provider sends to Elbi — claim rules in AD FS, attribute mappings in most other products — and nothing beyond them.
- Restrict who can sign inLimit access to the pilot group inside your provider, so everyone else is refused before an assertion is ever issued.
- Plan certificate rolloverSigning certificates expire. Record the expiry date and agree how the new certificate will be published before the old one lapses, so sign-in does not break on the day.
- Test the failure casesA user outside the permitted group, a missing attribute, a clock out of step, a session that outlives a disabled account. Each should end with a clear message rather than a blank error page.
Attribute release and the PDPL
A SAML assertion is a small packet of personal data about the person signing in: at minimum an identifier, usually a name and email address, often department, job title and group memberships. Under the Personal Data Protection Law, releasing each attribute to another application is a processing decision that needs a purpose.
Identity providers are built for exactly this control. Attribute release is configured per service provider, so Elbi can receive a narrower set than, for instance, your HR portal. The review question is simple: for each attribute on the list, which answer needs it?
SAML also allows assertions to be encrypted as well as signed, so their contents are not readable as they pass through the browser. Whether to require that for Elbi is a sensible item for the same review.
What organisations typically see
SAML compared with other ways of identifying people
OpenID Connect does the same job with lighter machinery and suits mobile applications more naturally. Many identity providers offer both, and the choice usually comes down to what your team already runs and what your security reviewers already accept.
"Single sign-on" in a product description often refers to the administration console. When comparing assistants, it is worth asking specifically whether the person in the conversation — not only the administrator — is identified through your federation.
The alternative to both is a separate login for the assistant. It is quick to set up and recreates everything federation was introduced to remove: another password, another user list, and another account to remember when someone leaves.
Common questions
No — that is the point. They use the sign-in they already have.
SAML is a standard; the trust relationship is configured during deployment.
Access ends with their directory account. The assistant never held an independent view of entitlement.
A persistent identifier that stays with the person. Email addresses are convenient but can change, and a changed identifier looks like a new person.
Publish the new certificate in your metadata before the old one expires and confirm Elbi's side has taken it up. Planned that way, rollover passes without interruption.
No. Identity arrives with each assertion, so there are no accounts to provision, review or remove on Elbi's side.
Add Elbi to the federation you already trust
One more service provider behind your existing sign-in, answering in Arabic and English within the attributes you release.