Eenmalig inloggen (SSO)
Enterprise voegt eenmalig inloggen toe voor elk teamlid. Je kiest het zelf onder Instellingen → Abonnement & facturen, net als de andere abonnementen. Daarvoor verifieer je eerst een bedrijfsdomein onder Instellingen → Toegangsbeheer. Zonder geverifieerd domein krijg je de melding “Verifieer een bedrijfsdomein voordat je Enterprise kiest”.
Tot er een koppeling aanstaat, blijft iedereen inloggen met de e-maillink, een passkey, of Google, Apple en Microsoft.
Wijzigingen op Instellingen → Toegangsbeheer kunnen alleen binnen 2 uur na het inloggen, en alleen met je eigen login: niet terwijl een reseller of onze support in je account werkt. Zie Wijzigingen waarvoor je opnieuw inlogt.
Een domein verifiëren
- Open Instellingen → Toegangsbeheer. Dit tabblad is er voor beheerders, ook zonder Enterprise: een domein claim je vóór je Enterprise kiest.
- Vul het bedrijfsdomein in, bijvoorbeeld
voorbeeld.nl, en kies Domein toevoegen. Het domein krijgt de status Wacht op DNS. - Maak een DNS TXT-record op dat domein, of op
_yarla.voorbeeld.nl, met de waardeyarla-verify=en het token op de pagina. - Kies DNS controleren. Vindt de controle het record nog niet, wacht dan een paar minuten en probeer het opnieuw. Lukt het, dan staat er Geverifieerd.
- Kies onder Instellingen → Abonnement & facturen het abonnement Enterprise.
Publieke inboxen zoals gmail.com kun je niet claimen. Een domein hoort pas bij een bedrijf als de DNS-controle slaagt: een claim die bij een ander bedrijf nog op DNS wacht, houdt de jouwe niet tegen, en wie de controle het eerst haalt, krijgt het domein. Daarna kan geen ander bedrijf het nog verifiëren. Een claim die 30 dagen op DNS wacht, vervalt; voeg het domein dan opnieuw toe.
De identiteitsprovider koppelen
Een bedrijf kan meerdere koppelingen bewaren, tot tien. Kies Nieuwe koppeling en kies de dienst bij Provider. De lijst bevat Microsoft Entra, Okta, OneLogin, Ping Identity, Auth0, JumpCloud en Keycloak, elk met SAML of OpenID Connect, en Google Workspace, AD FS, Duo en AWS IAM Identity Center met SAML. Al het andere is Aangepaste SAML of Aangepaste OpenID Connect. De naam komt uit die keuze.
SAML. Plak de Metadata-URL (die moet met https:// beginnen). Onder het veld staat de gebruikelijke URL van de gekozen provider. Zet in de identiteitsprovider het antwoordadres op het adres dat op deze pagina staat zolang het formulier open is. Het eindigt op /saml2/idpresponse.
OpenID Connect. Plak de Issuer (die moet met https:// beginnen), de Client-id en het Clientgeheim. Het geheim wordt na het opslaan niet meer getoond. Laat je het veld bij Bewerken leeg, dan blijft het bewaarde geheim staan. Zet in de identiteitsprovider de redirect-URI op hetzelfde adres als het antwoordadres, maar eindigend op /oauth2/idpresponse.
De provider moet het e-mailadres sturen in het attribuut email en de naam in name. Bij Groepsattribuut vul je het attribuut of de claim met de groepsnamen in. Standaard is dat groups.
Deze koppeling gebruiken voor eenmalig inloggen staat bij een nieuwe koppeling al aan. Haal het vinkje weg zolang de provider nog niet klaar is. Kies daarna Opslaan: dit formulier slaat niet automatisch op.
Staat een koppeling aan, dan stuurt de inlogpagina een adres op een geverifieerd domein na het invullen van het e-mailadres direct naar de provider, ook als eenmalig inloggen niet verplicht is. Staat er meer dan één aan, dan kiest het teamlid er daar een. De koppeling met Standaard is alleen een markering in de lijst in het dashboard. Met Als standaard verplaats je die.
Teamleden starten op de inlogpagina. Een start vanuit het portaal van de provider rondt de aanmelding niet af. Heeft iemand al een account met hetzelfde adres, gemaakt met de e-maillink of een uitnodiging, dan eindigt de eerste aanmelding via de provider met “Inloggen is geannuleerd of geweigerd. Probeer het opnieuw.” Het account is dan gekoppeld en de volgende poging lukt. Een account dat met Google, Apple of Microsoft is begonnen, wordt niet gekoppeld; het teamlid wordt wel aan het adres herkend. Een adres dat al bij het account van een ander bedrijf hoort, wordt nooit gekoppeld of verplaatst: die aanmelding eindigt met “Dit adres hoort bij een ander account”. Diegene verlaat eerst dat account (of de beheerder daar verwijdert diegene) en meldt zich daarna opnieuw aan.
Onder Aanmeldregels, op dezelfde pagina, worden wijzigingen automatisch opgeslagen. Je kiest wat er gebeurt als een bedrijfsdomeinadres dat nog niet in het team zit voor het eerst via de provider inlogt: Maak automatisch een account aan (de standaard) of Alleen op uitnodiging. Bij de tweede ziet die persoon dezelfde melding, tot je diegene hebt uitgenodigd, en ook een eerste aanmelding met Google, Apple of Microsoft op het domein maakt dan geen account aan. Nieuwe accounts krijgen de Rol voor nieuwe accounts, standaard Kijker.
Eis eenmalig inloggen voor geverifieerde domeinen kan pas nadat een domein geverifieerd is en een koppeling aanstaat. Die adressen kunnen de e-maillink en een passkey dan niet gebruiken, en een aanmelding met Google, Apple of Microsoft wordt geweigerd, ook van een login die al bestond maar nog niet in het team zit. Uitgenodigde teamleden met een ander adres kunnen de e-maillink wel gebruiken. Nodig je een adres op een geverifieerd domein uit terwijl dit aanstaat, dan zie je “Meld je aan via de identiteitsprovider van je bedrijf”. Het teamlid is wel toegevoegd en staat in de lijst nadat je de pagina herlaadt, maar er gaat geen uitnodiging uit: diegene logt in via de provider. Bij Nood-e-mailadressen zet je maximaal drie adressen, gescheiden door komma's, die de e-maillink of een passkey mogen blijven gebruiken. Bij een adres op een geverifieerd domein staat elk gebruik in het auditlog. Een adres op een ander domein valt sowieso niet onder deze regel, en de aanmeldingen daarvan worden niet gelogd.
Onder Groepen aan rollen koppelen koppel je maximaal twintig groepsnamen aan Beheerder, Bewerker of Kijker, met één regel per groep. De eerste regel die past, geldt. Hoofdletters tellen niet. Voor een account dat is ontstaan bij een eerste aanmelding via de provider wordt de rol bij elke aanmelding via de provider zo opnieuw bepaald: stuurt de provider groepen zonder passende regel, dan krijgt het teamlid de Rol voor nieuwe accounts. Stuurt de provider geen groepen, dan blijft de rol staan. Een bestaand account dat is gekoppeld (uitgenodigd, via SCIM aangemaakt of al op een andere manier ingelogd) valt hier niet onder: de rol blijft zoals die onder Instellingen → Team staat, of volgt de SCIM-groepen hieronder. Vraag de provider om alleen die groepsnamen te sturen, niet elke groep in de directory. De laatste beheerder wordt nooit gedegradeerd.
SCIM
Onder SCIM op Instellingen → Toegangsbeheer maak je een token met Token maken. Het token wordt één keer getoond, dus kopieer het meteen. De identiteitsprovider roept /scim/v2/Users en /scim/v2/Groups op het adres van je dashboard aan met Authorization: Bearer scim_….
Een gebruiker aanmaken voegt een teamlid toe met de Rol voor nieuwe accounts. userName moet het e-mailadres zijn, op een van je geverifieerde domeinen (een ander adres wordt geweigerd), en er gaat geen uitnodiging uit. active op false zet het teamlid uit. Een uitgezet teamlid kan het dashboard niet openen en staat onder Instellingen → Team als Gedeactiveerd. Verwijderen in SCIM zet het teamlid ook uit. Zelf doe je dat onder Instellingen → Team met Deactiveren. Weghalen uit het team kan alleen daar, met Verwijderen. De enige actieve beheerder kan via SCIM niet worden uitgezet of verwijderd: de provider krijgt antwoord 409. Maak eerst een ander teamlid beheerder. Gebruikers die via SCIM zijn aangemaakt, uitgezet of weer aangezet, en rolwijzigingen uit SCIM-groepen, komen in het auditlog.
Groepsleden krijgen de rol uit Groepen aan rollen koppelen. Ze komen alleen mee als de provider ze met POST of PUT op /scim/v2/Groups stuurt. Een PATCH met Operations wijzigt de leden van een groep niet.
Beveiligingsregels
Elke regel onder Beveiligingsregels begint uit. Wijzigingen worden automatisch opgeslagen.
- Sessies na zoveel uren beëindigen is een aantal uren vanaf het inloggen, van 1 tot 720. Leeg betekent geen limiet.
- Een tweede factor verplichten in het dashboard stuurt een teamlid naar Mijn account → Beveiliging tot een authenticator-app, passkey of hardwaresleutel aanstaat. Een sms-code telt niet.
- MFA van de bedrijfsprovider accepteren slaat die tweede factor over voor wie een account heeft dat is ontstaan bij een eerste aanmelding via de bedrijfsprovider. Vink dit aan als de identiteitsprovider al MFA eist. Wie een gekoppeld account heeft (uitgenodigd, via SCIM aangemaakt of al op een andere manier ingelogd) moet de tweede factor nog steeds instellen, net als iedereen die met de e-maillink inlogt, bijvoorbeeld met een noodadres.
- Toegestane IP-reeksen voor het dashboard beperkt het dashboard tot die reeksen: één CIDR per regel, maximaal 50. Leeg betekent elk adres. Een IPv6-adres past alleen als het los op de lijst staat, niet via een reeks. Zet je eigen adres erbij, want buiten de lijst kun je ook als beheerder het dashboard niet openen. Webhooks, de chatwidget en telefoongesprekken blijven open.
- API-sleutels ook tot deze IP-reeksen beperken past dezelfde lijst toe op verzoeken met een API-sleutel. Zonder dit vinkje vallen die er niet onder.
Het Auditlog onderaan de pagina toont de laatste 20 aanmeldingen en beheerwijzigingen, inclusief het IP-adres wanneer dat bekend is. CSV downloaden geeft er maximaal 500. Beide gaan terug tot het aantal dagen bij Gesprekken bewaren (dagen) onder Instellingen → Bedrijf. Een aanmelding via de provider met een gekoppeld account staat er niet in. Een geweigerde aanmelding (een adres dat bij het account van een ander bedrijf hoort), een rolwijziging uit providergroepen of SCIM-groepen, en een wijziging van de beveiligingsregels, met de regels die veranderd zijn, staan er wel in.
Vul je onder Beveiligingsregels een Audit-webhook-URL in, dan moet dat een https://-adres zijn; een ander adres wordt niet opgeslagen. Elke gebeurtenis gaat dan als POST met JSON (id, businessId, at, action, actor, summary, ip) naar dat adres. Dat verzoek is ondertekend met X-Yarla-Signature, met hetzelfde webhookgeheim als andere webhooks (Instellingen → Koppelingen bij Webhookgeheim). Hoe je dat controleert, staat in Webhooks. Een verzoek dat langer dan 3 seconden duurt, wordt afgebroken, en een mislukt verzoek wordt niet opnieuw geprobeerd; de regel blijft in het auditlog staan.
Voorwaardelijke toegang, apparaatcontrole en risicocontroles blijven bij de identiteitsprovider. Uitloggen hier beëindigt de sessie in deze app. Het beëindigt de sessie bij de identiteitsprovider niet.
Als je Enterprise verlaat of er een betaling openstaat
Stap je over naar een goedkoper abonnement, dan zie je eerst wat er stopt en bevestig je dat. Op de verlengdatum (of als een opgezegd abonnement afloopt) gaan Eis eenmalig inloggen voor geverifieerde domeinen en de beveiligingsregels uit en worden de SCIM-tokens ingetrokken. Iedereen logt weer in met de e-maillink, een passkey, of Google, Apple en Microsoft, en houdt het eigen account. Inloggen via de provider stopt voor iedereen, ook voor teamleden die dat al eerder deden: zij gebruiken de e-maillink met hetzelfde adres. De koppelingen blijven bewaard, inactief, onder Instellingen → Toegangsbeheer: ze werken weer als je opnieuw Enterprise kiest en die pagina opent, en je kunt ze verwijderen. Het auditlog blijft leesbaar. Beheerders en de factuurcontactpersoon krijgen een e-mail met wat er veranderd is. Zie Abonnement en facturen.
Staat er een betaling open (achterstallig of gepauzeerd), dan wordt niets minder streng: eenmalig inloggen, de beveiligingsregels, SCIM en gedeactiveerde teamleden blijven gelden. Je kunt ze weer aanpassen zodra de factuur betaald is.