> ## Documentation Index > Fetch the complete documentation index at: https://docs.assetinfinity.ai/llms.txt > Use this file to discover all available pages before exploring further. # Identity providers > Connecting your own SAML, OpenID Connect or LDAP directory, and keeping accounts in step with it. Connecting your own identity provider or directory, so your people sign in with the credentials your organisation already manages rather than a password held here. This is the administration screen behind [ways to sign in](/setup/sign-in-methods): what you configure here decides which buttons and forms your people see on the sign-in screen, and what happens when they use them. ## Adding a connection Three kinds, each suited to a different arrangement: | Kind | For | How somebody signs in | | - | - | - | | **SAML 2.0** | An identity provider your organisation runs (ADFS, Okta, and similar) | Redirected to it, and back with a signed assertion | | **OpenID Connect** | An identity provider speaking OIDC, including Entra ID | Redirected to it, and back with a token | | **LDAP / Active Directory** | A directory behind your own firewall, with nowhere to redirect to | Types their directory password into this product's own form; the broker binds against your directory to check it | A connection is saved with **In use** switched off by default. Configuring SAML or OpenID Connect is a two-way exchange — values from your identity provider into this form, and values from this form back into theirs — so nothing is offered to your people until you have finished both halves and tested it. ### What your identity provider needs from you For SAML and OpenID Connect, the entity ID (or issuer), the reply URL, and — for OpenID Connect — the redirect URI, sit at the top of the panel with a copy button on each, because registering this application at the identity provider's end is the half of the job people most often forget. ### Testing an LDAP connection An LDAP connection has no console of its own to test from, so **Save and test** does it here: it saves the connection and reports how far it got — reached the directory, encryption negotiated, the service account accepted, a person found — rather than a bare pass or fail. Without this, the first sign of trouble is a technician failing to sign in. Prefer `ldaps://` or StartTLS. Sending passwords to your directory unencrypted is possible, for a directory that can do neither, but every password crosses your network in the clear when you turn it on — including from handsets on site wifi. ## Who gets an account Two independent questions for anybody arriving through a connection: * **Create accounts on first sign-in** — on, somebody your identity provider vouches for who has no account here gets one automatically. Off, they are refused until an administrator invites them. * **Which role they arrive with** — mapped from their directory group, or a default role for anyone whose group matches nothing. Group mapping is applied on every sign-in, not only the first, so moving somebody out of a mapped group in your directory removes that role here too. Anything granted by hand on the [Access](/setup/access) screen is left alone. **Allowed email domains** narrows who this connection will accept at all — useful once account creation is on and your identity provider could otherwise assert an address from outside your organisation. ## Whether a password still works Switch off local passwords once a connection is tested and working, and the only way in for this organisation is through it. Before you do, name a **break-glass role** — the one role that may still sign in with a password if the connection is ever unreachable. Every such sign-in is recorded and notified. Give it to two or three people, not to a group. ## Certificates and authorities SAML connections need a signing certificate to verify anything — without one, every sign-in through it is refused. Several may be active at once, which is what makes rotation survivable: add the new one before the old one expires. An LDAP connection uses the same list the other way round: only if your directory's own certificate authority is private rather than public do you need to pin it here. ## Directory provisioning Two independent ways to keep accounts in step with a directory, for the half that group mapping does not cover: knowing when somebody has left. **SCIM 2.0** — your identity provider pushes changes to this product as they happen. Issue a token, paste the SCIM base URL into your provider's connector, and it tells this product the moment somebody is disabled: their sessions end, and their next request is refused. Recorded here: every token's request count and last use, and the last refusal if one occurred. **Reading accounts from a directory** — for a directory that has no SCIM licence, or will not push. This product binds with the connection's own service account and reads everybody your search matches on a schedule, creating and updating accounts to match. Because your directory has no way of telling this product that somebody has left, anyone the read no longer finds is treated as gone — a deactivation limit caps how many can be removed in one pass, so a broken search filter cannot empty the organisation by mistake. Every run is logged with what it created, updated, deactivated and refused, and every refusal names why — a missing email address, a domain not on the allowed list, an address already claimed by somebody else here. Use one or the other, not both. SCIM tells you about departures the moment they happen; reading the directory on a schedule is the fallback for a directory that cannot tell you at all. ## Who can use this Configuring a connection needs the authentication permission — the same one that governs [authentication policy](/setup/authentication). Provisioning tokens and directory reads sit behind the same permission, because issuing a token that can create and disable accounts is the same decision as connecting the directory in the first place.