SSO en provisioning

Single sign-on (SSO) laat leden inloggen bij Bird via je identiteitsprovider in plaats van met een apart Bird-wachtwoord. Bird ondersteunt SAML 2.0- en OpenID Connect (OIDC)-verbindingen.

Het opzetten is een taak voor een organisatie-Owner, en de instellingen staan op de Single sign-on-pagina van je organisatie. Een lid met de SSO-machtiging kan verbindingen beheren zonder Owner te zijn.

Persoonlijke Google- of GitHub-aanmelding staat los van organisatie-SSO. Zie Login, wachtwoord & MFA.

Hoe SSO werkt

Een SSO-verbinding dekt een of meer geverifieerde e-maildomeinen, zoals yourcompany.com. Leden op die domeinen authenticeren bij je identiteitsprovider. Hun Bird-machtigingen komen nog steeds van hun organisatie- en werkruimterollen.

Wat de setup inhoudt

Een organisatie-Owner en een identiteitsprovider-beheerder voltooien de setup:

1. Bewijs dat het domein van jou is. Bird geeft je een DNS-record om te publiceren voor elk e-maildomein dat de verbinding dekt. Afdwinging kan pas worden ingeschakeld als het domein is geverifieerd.
2. Configureer de verbinding. Geef voor SAML de metadata van de identiteitsprovider op, of de inlog-URL en ondertekeningscertificaten. Geef voor OIDC de issuer en clientgegevens op. Kopieer de serviceprovider- of redirectgegevens van Bird naar je identiteitsprovider.
3. Test de verbinding. Voltooi een testlogin voordat je de verbinding activeert. Welk protocol je ook hebt gekozen, een concept waarvan de test slaagt wordt voor je geactiveerd, mits je organisatie een geverifieerd domein heeft en onder de limiet voor actieve verbindingen zit.
4. Kies of je SSO verplicht stelt. Als SSO optioneel is, kunnen leden SSO of een andere beschikbare inlogmethode gebruiken. Als het verplicht is, moeten leden SSO doorlopen om toegang te krijgen tot de organisatie. SSO verplicht stellen vereist een actieve verbinding en ten minste één geverifieerd domein.

SSO verplicht stellen gaat onmiddellijk in, bij elk verzoek, en niet pas bij de volgende login. Een lid wiens huidige sessie niet via je identiteitsprovider tot stand is gekomen, verliest de toegang tot de organisatie totdat diegene opnieuw inlogt via de identiteitsprovider. Plan de wijziging dus rond de werkdag van je team in plaats van het achteraf aan te kondigen. Organisatie-Owners zijn de uitzondering: een Owner behoudt toegang met het Bird-wachtwoord, en dat voorkomt dat een verkeerd geconfigureerde verbinding iedereen buitensluit.

Je identiteitsprovider instellen

Stap 2 is het deel dat per provider verschilt: dezelfde waarde heeft in elke provider een andere naam, en elke provider heeft een instelling die alle logins weigert als die fout staat. De eigen veldnamen van Bird staan op de verbindingspagina, onder Register these with your identity provider.

• SSO instellen met Okta
• SSO instellen met Google Workspace
• SSO instellen met Microsoft Entra ID

Voor elke andere SAML 2.0- of OpenID Connect-provider zijn de vier bovenstaande stappen het volledige contract.

SAML instellen zonder tijdelijke waarden

De Entity ID en Assertion Consumer Service URL van een SAML-verbinding worden afgeleid van de verbinding zelf en bestaan dus pas als je die aanmaakt. Dat levert een cirkel op: je identiteitsprovider heeft die waarden nodig, en die waarden hebben de verbinding nodig.

Maak eerst de verbinding aan. Kies in Add connection SAML en vervolgens I have not set up my provider yet. De verbinding wordt aangemaakt als concept zonder gegevens van de identiteitsprovider, en als je die opent zie je de waarden die je moet registreren onder Register these with your identity provider. Configureer je provider met die waarden, kom dan terug en gebruik Supply the details op dezelfde verbinding, in welke vorm je ze ook hebt:

• een metadata-URL, die we ophalen en uitlezen
• het metadatadocument zelf, voor een provider die een bestand uitreikt in plaats van er een te hosten
• de entity ID, inlog-URL en ondertekeningscertificaten, rechtstreeks ingevoerd

Een geüpload document wordt uitgelezen voor die drie waarden en niet opgeslagen.

Totdat de gegevens binnenkomen, blijft de verbinding een concept: ze verwerkt geen logins en kan niet worden geactiveerd.

Hoe leden worden geïdentificeerd

Een SAML-verbinding identificeert elk lid aan de hand van de NameID die je provider stuurt, en die identifier is permanent voor iedereen die inlogt. Bij het opzetten van een verbinding wordt niet gevraagd welk formaat je wilt gebruiken. Als je een metadata-URL of -document hebt opgegeven, lezen we wat je provider daar adverteert en koppelen de verbinding daaraan. Als je de gegevens handmatig hebt ingevoerd is er geen metadata om te lezen, dus wordt de verbinding gekoppeld aan een permanent ID.

Wat je wél bepaalt is de waarde erachter. Stel de applicatiegebruikersnaam bij je provider in op iets opaaks dat nooit opnieuw wordt toegewezen, en stuur het adres apart mee als email-attribuut. Een e-mailadres als identifier is voorgoed zwakker: als het adres ooit opnieuw wordt toegewezen, erft de volgende persoon die het krijgt het Bird-account.

Metadata beschrijft wat je provider kan sturen; de applicatieconfiguratie bepaalt wat die daadwerkelijk stuurt, en die twee kunnen verschillen. Daarom rapporteert de testlogin in stap 3 de identifier en het formaat die de assertion daadwerkelijk bevatte, en aan dat rapport zie je of de twee overeenkomen voordat iemand op de verbinding vertrouwt. We weigeren ook een identifier met het label persistent die eigenlijk een e-mailadres is.

Als de test een formaat rapporteert dat je niet verwachtte, heb je twee manieren om het te corrigeren, en welke juist is hangt af van wat er mis is:

• De provider stuurt het verkeerde. Wijzig de applicatiegebruikersnaam bij je provider en test opnieuw. Dit is meestal de juiste oplossing, omdat de opaque identifier degene is die je wilt behouden.
• De verbinding is gekoppeld aan het verkeerde. Open Edit op de verbinding en wijzig het NameID-formaat naar het formaat dat je provider stuurt.

Doe een van beide voordat leden beginnen in te loggen. Zodra ze dat hebben gedaan, zijn hun accounts gekoppeld aan de dan geldende identifier, dus het formaat ligt vast en de wijziging wordt geweigerd. Maak in plaats daarvan een verbinding aan voor het nieuwe formaat.

Een provider vervangen

De identiteitsprovidergegevens van een SAML-verbinding kunnen worden vervangen zolang er niemand mee heeft ingelogd. Zodra leden de verbinding hebben gebruikt, zijn hun accounts gekoppeld aan de identifiers die je huidige provider stuurt, dus vervanging wordt geweigerd. Maak in plaats daarvan een verbinding aan voor de nieuwe provider. Bij een OIDC-verbinding kun je het clientgeheim op elk moment roteren, wat niet verandert waarmee leden worden geïdentificeerd, maar de provider zelf kan niet worden vervangen.

De testlogin in stap 3 telt niet mee. Een test koppelt geen account en verleent geen toegang, dus een verbinding die je hebt opgezet en getest maar nog niet aan je team hebt gegeven, kan nog worden omgeleid.

Wat er verandert voor je team

Een verbinding kan een lid bij de eerste geslaagde SSO-login standaardtoegang geven tot de organisatie en werkruimte. Configureer die standaardtoegang expliciet; nodig anders leden uit en wijs rollen toe voordat ze inloggen. Zie Gebruikers, teams & rollen.

Het opschorten van een verbinding voorkomt nieuwe logins via die verbinding. Controleer Bird-lidmaatschappen en actieve sessies apart wanneer iemand je bedrijf verlaat.

Volgende stappen

• Login, wachtwoord & MFA: individuele accountbeveiliging, inclusief persoonlijke Google-/GitHub-aanmelding
• Gebruikers, teams & rollen: hoe rollen en machtigingen werken zodra leden binnen zijn
• Authenticatie & API-sleutels: de authenticatiereferentie voor ontwikkelaars