De inhoud op deze pagina is automatisch vertaald. Zoom garandeert de nauwkeurigheid niet.
For the complete documentation index, see llms.txt. This page is also available as Markdown.

SSO-handleiding

Inleiding

Het integreren van Single Sign-On (SSO) met Zoom biedt beheerders opties voor Gebruikersbeheer en beveiliging die accountbeheer kunnen vereenvoudigen. Zodra dit is geconfigureerd, authenticeren gebruikers zich met hun bedrijfsreferenties bij de identiteitsprovider van hun bedrijf in plaats van alternatieve methoden voor authenticatie te gebruiken, zoals OAuth via een app van een externe partij of rechtstreeks met een Gebruikersnaam en wachtwoord in Zoom.

Dit document biedt een uitgebreid overzicht van SSO-configuraties en Instellingen binnen Zoom, naast informatie over probleemoplossing en beveiliging.

SSO configureren

SSO vereist een vanity-URL om aan de slag te gaan

Een account moet een goedgekeurde vanity-URL hebben voordat SSO wordt geconfigureerd. Zodra de vanity-URL is goedgekeurd, kunnen Zoom-beheerders toegang krijgen tot de SSO-configuratie pagina via het submenu Geavanceerde opties op het webportaal. Raadpleeg ons artikel over ondersteuning bij vanity-URL's voor meer informatie. vanity-URL's voor meer informatie.

Zoom SSO werkt met elke SAML 2.0- of OIDC-identiteitsprovider

Zoom kan integreren met elke identiteitsprovider die Security Assertion Markup Language (SAML) 2.0 of OpenID Connect (OIDC) authenticatie ondersteunt.

Zoom-beheerders kunnen gebruikersprofielinformatie en licenties beheren via responsmapping of SCIM-integraties

Beheerders kunnen gebruikersprofielinformatie en licentiëring beheren via responsmapping of via verzoeken aan de System for Cross-Domain Identity Management (SCIM) applicatieprogrammeerinterface (API), afhankelijk van welke functies Beschikbaar zijn bij de identiteitsprovider. Beide methoden voor Gebruikersbeheer bieden vrijwel dezelfde functionaliteit voor het mappen van profielinformatie en licentiebeheer, maar voor sommige SCIM-mappings is handmatige configuratie vereist.

Voor een uitgebreide lijst van SCIM-mogelijkheden, raadpleeg onze SCIM API-documentatie.

Zoom-beheerders kunnen de status van het account van de gebruiker beheren via SCIM, maar niet via SAML of OIDC

Omdat SCIM identiteitsproviders in staat stelt om op elk moment rechtstreeks met Zoom te communiceren, kunnen gebruikersaccounts worden geactiveerd, gedeactiveerd, gemaakt, of verwijderd via SCIM-integraties automatisch. Bijvoorbeeld: als een gebruiker zijn of haar account in Active Directory is uitgeschakeld, of als zij de applicatie niet toegewezen hebben gekregen, kan SCIM een automatisch deactivatieverzoek sturen voor het account van de gebruiker binnen Zoom. Deze Functie(s) is afhankelijk van de mogelijkheden van de SCIM-applicatie van de identiteitsprovider en de functionaliteit kan per provider verschillen.

Een beperkt aantal identiteitsproviders biedt SCIM voor Zoom

Veel identiteitsproviders hebben geen SCIM Integratie(s) die voor Zoom is ingebouwd als onderdeel van hun diensten. Accounts die een identiteitsprovider gebruiken die SCIM met Zoom niet ondersteunt, moeten response mapping gebruiken voor geautomatiseerd Gebruikersbeheer.

SCIM vereist een gekoppeld domein om gebruikers automatisch in te richten

Accounts die SCIM gebruiken om gebruikers voor SSO te beheren en te provisioneren moet koppel het E-maildomein aan Zoom. Als u het domein niet koppelt, leidt dit tot fouten bij het provisioneren van gebruikers. Raadpleeg ons ondersteuningsartikel over Gekoppelde domeinen voor meer informatie over het proces.

SAML-configuratiegids

De volgende links bevatten gidsen voor het configureren van SSO met SAML.

Providerdocumentatie
Zoom-documentatie
Ondersteunt SCIM

auth0

ADFS

AD Sync-tool

Clever

CyberArk

Duo

Entra ID (voorheen Azure)

Google

JumpCloud

miniOrange

Okta

OneLogin

Ping Identity

Als de identiteitsprovider die uw bedrijf gebruikt hierboven niet wordt vermeld, raden we aan om in de kennisbank van de provider te zoeken naar een Zoom-specifieke Integratie(s)-gids. Als die niet Beschikbaar is, kan SSO nog steeds worden geconfigureerd door sleutelidentificaties uit uw IdP te koppelen binnen het Scherm voor Zoom's SSO-configuratie. Raadpleeg Zoom's Ondersteuningscentrum voor meer informatie over een snelstartgids voor SSO en welke informatie nodig is om dit proces te voltooien.

OIDC-configuratiegids

Zoom ondersteunt OIDC-discovery, waarmee algemene gegevens van de identiteitsprovider automatisch kunnen worden ingevuld, zoals de issuer, autorisatie Eindpunt, token Eindpunt en ondertekeningssleutels. Omdat OIDC afhankelijk is van gestandaardiseerde configuratiewaarden, is providerspecifieke Zoom-documentatie doorgaans niet vereist; wanneer discovery niet beschikbaar is, kunnen de benodigde waarden handmatig worden ingevoerd.

Als gevolg hiervan kunnen OIDC-identiteitsproviders die aan de standaarden voldoen, doorgaans met Zoom worden geconfigureerd, zelfs wanneer een providerspecifieke Integratiegids niet beschikbaar is. Raadpleeg Zoom's Ondersteuningscentrum voor meer informatie over het configureren van OIDC-SSO.

Aanvullende configuratieopties

Zoom kan meerdere vanity-URL's en/of meerdere applicaties van identiteitsproviders ondersteunen

Zoom-accounts kunnen meerdere vanity-URL's, meerdere configuraties van identiteitsproviders (IdP), of een combinatie van beide ondersteunen. Ondersteunde configuraties zijn onder meer:

  • Meerdere vanity-URL's die een gemeenschappelijke IdP-configuratie delen.

  • Meerdere vanity-URL's, elk met een zelfstandige IdP-configuratie.

  • Eén vanity-URL gekoppeld aan meerdere IdP-configuraties.

Deze configuraties worden ingeschakeld via Zoom-ondersteuning en worden niet geconfigureerd via de Standaard SSO-beheerinterface. Dien een verzoek om ondersteuning om deze Functie(s) te Inschakelen, samen met de gewenste vanity-URL- en IdP-configuratie en de beoogde authenticatie-uitkomst.

Opmerking

OIDC-authenticatie ondersteunt momenteel geen meerdere Vanity-URL's of IdP's. Als u niet zeker weet of deze situatie op u van toepassing is, neem dan voor meer informatie contact op met uw Zoom-accountteam.

On-premises Active Directory kan in plaats van SCIM de AD Sync-tool gebruiken

Accounts die willen automatiseren voor het inrichten van gebruikers via SCIM, maar geen op Cloud gebaseerde identiteitsprovider hebben, kunnen de Active Directory (AD) Sync Tool applicatie gebruiken die door Zoom is ontwikkeld voor het beheren van hun gebruikers. Deze applicatie draait op Oracle JDK 8 en simuleert SCIM-provisioning door gebruikers te beheren via API-opdrachten. Bekijk ons ondersteuningsartikel op de AD Sync-tool voor meer informatie.

Identiteitsproviders kunnen zelfs deelnemers aan de vergadering authenticeren die geen Zoom-account hebben

Accounts die van gebruikers willen vereisen dat zij hun identiteit authenticeren, maar geen Zoom-accounts willen verstrekken, kunnen een extern authenticatieprofiel configureren met hun identiteitsprovider. Wanneer dit is ingeschakeld voor een vergadering, moeten gebruikers die proberen deel te nemen hun inloggegevens authenticeren bij uw identiteitsprovider om toegang te krijgen. Dit is een veelvoorkomende configuratie voor scholen die niet alle leerlingen accounts verstrekken, maar authenticatie vereisen om deel te nemen aan lessen. Raadpleeg ons ondersteuningsartikel over het configureren van externe authenticatie voor meer informatie.

Het wijzigen van de identiteitsprovider vereist het opnieuw configureren van SSO binnen Zoom

Accounts die van identiteitsprovider veranderen, moeten hun SSO-configuratie binnen Zoom opnieuw uitvoeren. Dit omvat het bijwerken van alle velden op de configuratiepagina zodat deze overeenkomen met hun nieuwe identiteitsprovider. Accounts worden aangemoedigd te bevestigen dat antwoordtoewijzingen niet zullen veranderen met de nieuwe identiteitsprovider.

Er zouden geen aanvullende configuraties of wijzigingen nodig moeten zijn, ervan uitgaande dat er geen verdere wijzigingen zijn.

Klanten met subaccounts kunnen SSO Configureer vanuit het hoofdaccount of subaccount

Klanten met subaccounts hebben twee opties voor het configureren van SSO:

  1. Alle gebruikers authenticeren met de vanity-URL van het hoofdaccount en worden automatisch aangemeld bij het subaccount via geavanceerde antwoordtoewijzing (er gelden enkele beperkingen voor toewijzingen)

  2. Elk subaccount heeft een unieke vanity-URL en onafhankelijke SSO-configuratie, die uitsluitend wordt gebruikt door leden van dat subaccount

Elke configuratie biedt unieke voordelen, waarbij de tweede optie de meeste flexibiliteit biedt. Klanten die overwegen een van beide configuraties te implementeren, moeten met hun accountteam bespreken welke configuratie het beste aansluit bij hun behoeften.

Provisioneringsmethoden

Provisioneringsmodi en SCIM zijn twee verschillende mechanismen en ze kunnen samen worden gebruikt

Provisionering Bij aanmelden en Voor aanmelden zijn de twee Beschikbaar zijnde waarden van één SSO-instelling. Ze bepalen of Zoom een account voor een gebruiker aanmaakt op het moment dat zij authenticeren, of vereist dat het account al bestaat. SCIM is geen derde waarde van die instelling — het is een afzonderlijk, via API aangestuurd mechanisme dat gebruikers onafhankelijk van authenticatie provisioneert en het werkt naast welke provisioneringsmodus ook is geselecteerd.

Provisioneringsmethode
Hoe het werkt
Voorvereisten
Maakt account aan
Deactiveert account

Bij aanmelden (Just-in-time)

Maakt het account aan wanneer de gebruiker zich voor het eerst authentiseert

Geen

Ja

Nee

Voor aanmelden (Vooraf provisioning)

Controleert of een gebruiker gemachtigd is om zich aan te melden via SSO

Een account met het SSO-inlogtype. Vaak gebruikt met SCIM-provisioning.

Nee, maar wordt vaak gebruikt met SCIM

Nee, maar wordt vaak gebruikt met SCIM

SCIM

Synchroniseert gebruikersgegevens vanuit de identiteitsprovider volgens zijn eigen Planning via API's

IdP-ondersteuning voor SCIM en een bijbehorend domein

Ja

Ja, als dit wordt ondersteund door de IdP

Bij aanmelden

Provisioning bij aanmelding maakt in één stap het account en het SSO-inlogtype aan

Met de Bij aanmelden instelling (ook wel just-in-time provisioning genoemd) krijgt een gebruiker die binnen de identiteitsprovider is toegewezen aan de Zoom-applicatie en die een ondersteunde Zoom-licentie ontvangt, de eerste keer dat hij authenticeren een account aangemaakt. Er hoeft vooraf niets in Zoom te bestaan. Dit maakt het de eenvoudigste optie om op te zetten, en daarom wordt het aanbevolen wanneer u SSO voor het eerst op een account configureert.

Provisioning bij aanmelding is ook compatibel met SCIM — de twee kunnen tegelijk worden uitgevoerd. In de praktijk maakt SCIM er echter meestal overbodig, omdat accounts al bestaan tegen de tijd dat een gebruiker voor het eerst authenticeren.

Voor aanmelden

Provisioning voorafgaand aan het inloggen is afhankelijk van iets anders dat eerst het account of het inlogtype heeft aangemaakt

De Voor aanmelden instelling (ook bekend als pre-provisioning) voorziet niets automatisch. In plaats daarvan dwingt deze een voorwaarde af: een gebruiker mag alleen authenticeren als zijn Zoom-account al bestaat en het SSO-inlogtype heeft. Iets anders moet dus verantwoordelijk zijn voor het aanmaken van die accounts, en er zijn twee praktische opties.

  • SCIM-provisioning, waarmee accounts automatisch worden aangemaakt vanuit de identiteitsprovider zodra gebruikers de applicatie toegewezen krijgen.

  • Bulk CSV-upload met de SSO-gebruiker optie geselecteerd, waarmee accounts worden aangemaakt en het SSO-inlogtype in één import wordt toegepast.

Daarom worden pre-provisioning en SCIM zo vaak gecombineerd. Pre-provisioning stelt een vereiste; SCIM is het mechanisme dat daaraan op grote schaal voldoet.

Zoom-beheerders kunnen bevestigen of een account een SSO-aanmeldtype heeft door het gebruikersaccount te bekijken op de Gebruikersbeheer pagina binnen het webportaal en te zoeken naar het pictogram “SSO” onder de E-mail van de gebruiker.

A user profile showing an SSO login type
Locatie van het SSO-pictogram onder de E-mail van een gebruiker.

Als het pictogram aanwezig is, is de gebruiker geprovisioneerd voor SSO; als het pictogram ontbreekt, is Aanmelden via SSO niet mogelijk terwijl pre-provisioning is ingeschakeld totdat het is toegevoegd. Een Zoom-beheerder kan dit aanmeldtype Toevoegen door gebruikers in bulk toe te voegen via een CSV-bestand en de optie “SSO-gebruiker” te selecteren of de gebruiker te authenticeren terwijl Provision at Sign-in is ingeschakeld.

Voorbeeld om de optie “SSO-gebruiker” voor bulk uploaden te presenteren.

SCIM

SCIM voorziet gebruikers via API's en bevestigt nooit identiteitswaarden zoals SAML of OIDC

SCIM verschilt van response mapping op een manier die het waard is om duidelijk te vermelden. Response mapping — of dit nu via SAML-asserties of OIDC-claims gebeurt — draagt gebruikersinformatie als onderdeel van een authenticatie-Evenement. Er wordt niets toegepast totdat de gebruiker Aanmelden heeft voltooid, en de informatie reist binnen de assertie.

SCIM bevat helemaal geen verklaringen of claims. De identiteitsprovider roept Zoom's API rechtstreeks aan volgens zijn eigen Planning en stuurt gebruikersinformatie, ongeacht of de gebruiker ooit heeft ingelogd. Dit maakt het mogelijk dat SCIM accounts kan maken, bijwerken, deactiveren en verwijderen zonder betrokkenheid van de gebruiker, en daarom kan SCIM de accountstatus beheren terwijl response mapping dat niet kan.

SCIM is compatibel met beide provisioningmodi en wordt meestal samen met pre-provisioning geïmplementeerd.

Raadpleeg de SCIM voor Entra ID en Okta veldgids voor meer informatie over het configureren van SCIM voor uw account met zowel Entra ID als Okta.

Beveiligings Instellingen

Zoom-beheerders kunnen automatisch uitloggen afdwingen na een bepaalde tijdsduur

Zoom-beheerders kunnen Zoom zodanig Configureer dat gebruikers automatisch uit actieve sessies worden afgemeld na vastgestelde tijdsduur, aanpasbaar van 15 minuten tot 180 dagen. Dit proces stelt het Zoom-toegangstoken zo in dat het verloopt na de vooraf bepaalde duur zodra het token is gegenereerd. Dit token heeft geen relatie met een identiteitsprovider en is uniek voor Zoom.

Een domein moet worden gekoppeld en beheerd om SSO-authenticatie af te dwingen

Zoom-beheerders kunnen SSO-authenticatie afdwingen alleen als het E-maildomein is gekoppeld en beheerd binnen Zoom. Wanneer dit is ingeschakeld, worden alle gebruikers die zich authenticeren met uw bedrijfsdomein(en) automatisch omgeleid naar de authenticatiepagina van uw identiteitsprovider, ongeacht Platform.

Zodra het domein is goedgekeurd en beheerd, kan een Zoom-beheerder SSO-authenticatie afdwingen via uw account beveiligingspagina onder Aanmeldingsmethoden. Raadpleeg ons ondersteuningsartikel over Gekoppelde domeinen voor meer informatie over het koppelen en beheren van een domein.

Opgegeven gebruikers kunnen worden vrijgesteld van verplichte SSO-authenticatie

Zoom-beheerders kunnen specifieke gebruikers uitsluiten van verplichte SSO-authenticatie. Het uitsluiten van specifieke gebruikers (zoals een beheerderaccount) kan nuttig zijn als een SSO-configuratie defect raakt en een accountbeheerder niet-SSO-toegang tot het Zoom-account nodig heeft. Beheerders die zijn vrijgesteld, kunnen zich te allen tijde aanmelden bij beheerder.zoom.us in het Evenement van een accountvergrendeling of defecte SSO-configuratie (gebruiker moet de standaard beheerder Rol). Als een Zoom-beheerder geen toegang heeft tot het account, moeten zij een contactpersoon bij Zoom-ondersteuning benaderen voor hulp.

Om een uitzondering voor een gebruiker Inschakelen, navigeer naar het account beveiligingspagina op het webportaal, onder geavanceerde opties, zoekt u de lijst met afgedwongen domeinen en Toevoegen een uitzondering via de bewerkingslijst.

Voorbeeld van domeinlijst voor SSO.

Mobiele en desktopclients kunnen worden geconfigureerd om van gebruikers te vereisen dat ze SSO-authenticatie gebruiken

Zoom-clients kunnen vooraf worden geconfigureerd om SSO-functionaliteit te automatiseren, waaronder automatisch inloggen, automatisch uitloggen, uitsluitend SSO-authenticatie op het Apparaat en meer via Groep Policy, services voor beheer van mobiele Apparaten (MDM) en clients voor massale implementatie.

Raadpleeg voor een volledige lijst van configuratiemogelijkheden onze configuratieopties voor Groepsbeleid, iOS, Android, Mac en Windows.

Office 365-gebruikers kunnen zich automatisch aanmelden bij de Zoom voor Outlook-invoegtoepassing met SSO-referenties

Klanten die Office 365 gebruiken, kunnen hun gebruikers automatisch aanmelden bij de Zoom voor Outlook-invoegtoepassing met SSO-referenties. Dit kan worden gecombineerd met een aangepast invoegtoepassingsmanifest dat de vanity-URL van het account vooraf invult, waardoor gebruikers een naadloze authenticatie-ervaring krijgen. Deze functie gebruikt het SSO-sessie-token van de gebruiker als deze actief is, of vraagt om een nieuwe authenticatie met uw identiteitsprovider als er geen actieve sessie wordt gevonden.

Een Zoom-beheerder kan deze instelling inschakelen op het account beveiligingspagina onder de geavanceerde menu.

Voorbeeld van beheerderinstelling voor SSO met Outlook-invoegtoepassing.

Responsmapping

Bij responsmapping, attributen zijn categorieën gegevens gedefinieerd door waardenen worden gebruikt om informatie door te geven van de identiteitsprovider naar een serviceprovider zoals Zoom. Het mappen van attributen en waarden is essentieel voor het automatiseren van gebruikersprofielinformatie en het beheren van gebruikerslicenties.

Zoom-responsmapping is opgesplitst in twee delen: Basis en geavanceerdemapping wordt gebruikt om basisprofielinformatie toe te passen, waaronder naam, telefoonnummer, afdeling, enz., terwijl geavanceerde mapping wordt gebruikt om dynamische licentietoewijzingen te beheren, gebruikersgroepen toe te wijzen, gebruikersrollen toe te wijzen en meer.

Dit gedeelte behandelt de basisprincipes van basis- en geavanceerde responsmapping en belicht unieke voorwaarden die vereist zijn voor sommige Functie(s).

Zoom ondersteunt responsmapping via zowel SAML als OIDC

Zoom kan responsmapping configureren via zowel SAML als OIDC. SAML-identiteitsinformatie wordt uitgewisseld in XML-geformatteerde assertions, terwijl OIDC-identiteitsinformatie wordt geleverd via JSON Web Key-sets (JWK's). In beide gevallen kan Zoom de attributen of claims die van de identiteitsprovider worden ontvangen gebruiken om gebruikersprofielinformatie, licenties, groepen en andere ondersteunde account-Instellingen toe te wijzen.

Basisprincipes: Attributen en Waarden

De meeste identiteitsproviders geven basisprofielinformatie door met eenvoudige attribuutnamen en waarden. Bijvoorbeeld kan de afdeling van een werknemer binnenkomen met een attribuut department en een waarde Human Resources. De volgende tabel toont de relatie tussen attributen en waarden bij het doorgeven van informatie over een gebruiker.

Attribuut
Waarde

firstName

John

lastName

Smith

E-mail

john.smith@companydomain.com

department

Personeelszaken

Door een attribuut correct toe te wijzen aan een responsmapping, kan gebruikersinformatie automatisch worden toegepast op een gebruikersprofiel om het proces voor het aanmaken en beheren van een account te vereenvoudigen.

Basis mapping: Profielinformatie

Basis mapping wordt gebruikt om profielinformatie zoals voornaam, achternaam, afdeling, telefoonnummer, kostenplaats en Locatie uit een directory toe te passen op het profiel van een gebruiker. Veel van deze categorieën spreken voor zich en kunnen eenvoudig worden geconfigureerd; sommige categorieën vereisen echter uitleg voor een juiste configuratie om onvoorziene gevolgen of fouten in de applicatie te voorkomen. Het volgende gedeelte belicht unieke mappingopties en configuratie-Instellingen voor Basis mapping. Raadpleeg ons artikel over Basis mapping voor een volledige lijst met ondersteunde attributen.

Het Standaard licentietype is alleen van toepassing op gloednieuwe gebruikers

De optie voor het Standaard licentietype zal de toegewezen licentie toepassen op alle gloednieuwe gebruikers die binnen het account worden ingericht via eerste authenticatie. Dit is niet van toepassing op gebruikers die zich voor een tweede keer authenticeren, gebruikers die in het account zijn samengevoegd vanuit een eerder account, gebruikers die via SCIM worden ingericht, of gebruikers die handmatig zijn uitgenodigd.

Voor informatie over bijwerken voor gebruikerslicenties met authenticatie, raadpleeg de licentieconfiguratie onder Geavanceerde toewijzing.

Een standaard licentietype van Geen staat nieuwe gebruikers niet toe om zich te authenticeren, tenzij geavanceerde toewijzing is geconfigureerd om een licentie toe te wijzen

Zoom-gebruikers moeten een toegewezen licentietype hebben (Niet toegewezen zonder Zoom Meetings Basis, Zoom Workplace, enz.) om zich aan te melden bij de Zoom-service. Als een standaard licentietype van Geen is geselecteerd, kunnen nieuwe gebruikers zich niet aanmelden of een nieuw account aanmaken, tenzij zij een licentie ontvangen via Geavanceerde toewijzing.

De meeste basis-toewijzingen worden bij aanmelden opnieuw toegepast, tenzij anders vermeld

De meeste basis-toewijzingen worden standaard elke keer dat een gebruiker zich aanmeldt bijgewerkt, behalve voor voornaam, achternaam, weergavenaam en telefoonnummer. Standaard worden deze vier toewijzingen alleen toegepast de eerste keer dat een gebruiker zich moet authenticeren en worden ze daarna niet opnieuw toegepast, zelfs niet als ze zijn bijgewerkt door een gebruiker of beheerder. Zoom-beheerders kunnen dit gedrag wijzigen door de optie voor Bijwerken bij elke SSO-aanmelding op de pagina voor respons-toewijzing.

Voorbeeld van de optie Bijwerken bij elke SSO-aanmelding.

Telefoonnummers moeten een landcode en netnummer bevatten als ze buiten de Verenigde Staten zijn

Telefoonnummers die via beweringen worden toegewezen, moeten waar mogelijk de landcode en het netnummer van de gebruiker bevatten. Zoom gaat standaard uit van landcode +1 als deze niet is gedefinieerd.

Accounts die in hun directory geen landcodes behouden, kunnen hun beweringen binnen hun identiteitsprovider bewerken om deze indien nodig automatisch toe te voegen.

Elke gebruiker kan maximaal drie telefoonnummers en één faxnummer aan zijn accountprofiel toegewezen krijgen

Zoom-beheerders kunnen voor elke gebruiker maximaal drie afzonderlijke telefoonnummers en één faxnummertoewijzing configureren. Elk telefoonnummer moet uniek zijn en mag niet dezelfde waarde hebben als een ander veld.

Voorbeeld van telefoonnummeropties voor elke gebruiker.

Profielfoto's moeten worden toegewezen vanuit een openbaar toegankelijke URL of gecodeerd met Base64

Accounts die profielfoto's uit hun directory willen toewijzen, moeten de afbeeldingen gebruiken via een openbaar toegankelijke URL of de afbeelding coderen in Base64 bij het afgeven van de bewering.

Unieke werknemer-ID

De Unieke werknemer-ID wijzigt de primaire Identificatie die Zoom gebruikt om gebruikers te identificeren en helpt dubbele gebruikersaccounts na een wijziging van E-mailadres te voorkomen

De Unieke werknemer-ID is een functie die Zoom biedt ter ondersteuning van identiteitsbeheer. Standaard is de primaire Identificatie voor een Zoom-gebruiker hun E-mail E-mailadres. Dit betekent dat als het aanmeldtype E-mail werk is john.smith@company.com, dan zal Zoom deze gebruiker altijd identificeren aan de hand van dat E-mailadres. Deze Identificatie zorgt ervoor dat integraties zoals SSO of Facebook- en Google OAuth-accounts de gebruiker aan hetzelfde Zoom-account kunnen koppelen.

Deze identificatieprocedure kan echter problematisch zijn als de naam of E-mailadres van een gebruiker verandert. Bijvoorbeeld, als john.smith@company.com een wijziging van E-mailadres heeft naar jonathan.smith@company.com, dan kan Zoom niet veilig vaststellen dat dit dezelfde persoon is (omdat de fundamentele Identificatie anders is), dus zal Zoom een nieuw account aanmaken de eerste keer dat jonathan.smith@company.com inlogt.

Om dit probleem te vereenvoudigen biedt Zoom de functie Unieke werknemer-ID, die de primaire Identificatie van een gebruiker verandert van hun E-mailadres naar een vastgestelde unieke ID. Dit wijzigt niet de Gebruikersnaam van een gebruiker binnen Zoom, maar biedt in plaats daarvan een alternatief identificerend attribuut. Deze wijziging stelt Zoom in staat om het E-mailadres van een gebruiker dynamisch bij te werken binnen Zoom als:

  • een nieuw E-mailadres wordt vergezeld door een bekende Unieke werknemer-ID; en

  • het domein van de getroffen gebruiker is gekoppeld binnen Zoom

Bijvoorbeeld, als john.smith@company.com zich authenticeert en een waarde van 12345 (hun werknemersnummer) doorgeeft voor het kenmerk Unieke werknemer-ID, zal Zoom de gebruiker nu binnen het account identificeren aan de hand van de opgegeven waarde. Als John opnieuw probeert te authenticeren met het E-mailadres jonathan.smith@company.com terwijl hij nog steeds de Unieke werknemer-ID van 12345 doorgeeft, zal Zoom herkennen dat john.smith@company.com nu jonathan.smith@company.com is en zal het E-mailadres van de gebruiker binnen het account dynamisch bijwerken als het domein gekoppeld is.

Identiteitsbeheerders dienen er zeker van te zijn dat geen twee gebruikers elkaar zullen overlappen met dezelfde waarde voor Unieke werknemer-ID voordat voor deze categorie een toewijzing wordt ingesteld. Als een andere gebruiker probeert te authenticeren en dezelfde waarde doorgeeft, wordt het E-mailadres opnieuw bijgewerkt naar de nieuwe gebruiker en kan dit aanzienlijke verstoring veroorzaken voor gebruikersservices en -ervaring.

De functie Unieke werknemer-ID vereist Gekoppelde domeinen om het E-mailadres van een gebruiker te wijzigen

De functie Unieke werknemer-ID kan het E-mailadres van een gebruiker niet bijwerken tenzij het E-maildomein officieel is gekoppeld aan uw accountprofiel. Raadpleeg ons ondersteuningsartikel over Gekoppelde domeinen voor meer informatie.

Beheerders en eigenaars kunnen hun E-mailadres niet bijwerken via de Unieke werknemer-ID

De E-mailadressen van beheerder en Eigenaar binnen Zoom kunnen niet worden bijgewerkt via de werknemer Unieke-ID Functie(s). Dit is bedoeld als beveiligingsmaatregel om ongeautoriseerde Access te Voorkomen. Beheerders en Eigenaren moeten hun E-mail Wijzigen via hun profielpagina.

E-mails van de gebruiker kunnen slechts eenmaal per dag worden bijgewerkt via de unieke ID van de werknemer

Gebruikers-E-mailadressen kunnen alleen eens per 24 uur worden bijgewerkt via de Functie(s) voor unieke werknemer-ID. Een gebruiker moet een volledige agendadag wachten sinds de vorige update voordat hij of zij zijn of haar E-mail opnieuw via SSO kan bijwerken.

Diagram van een voorbeeldstroom voor het bijwerken van e-mails van de gebruiker.

Het instellen van het attribuut op <NameID> zal de geclaimde NameID van de gebruiker gebruiken

Het kenmerk Unique ID van de werknemer toewijzen aan <NameID> zal automatisch de geclaimde NameID-waarde van de gebruiker gebruiken als hun unieke identificatie. Dit kan een nuttig hulpmiddel zijn als uw identiteitsprovider een NameID claimt die niet overeenkomt met het e-mailadres van een gebruiker, zoals een User Principal Name (UPN) of een vergelijkbare waarde die niet wijzigt. Gebruik deze waarde niet als de NameIDs van gebruikers overeenkomen met hun e-mail.

Voorbeeld van de <NameID> beheerderinstelling.

Geavanceerde mapping: Licenties en Toevoegen-ons

In het gedeelte Geavanceerde informatietoewijzing kunnen dynamisch licenties (inclusief Zoom Phone), invoegtoepassingen en Access-groepen voor gebruikers worden toegepast wanneer zij zich authenticeren. In tegenstelling tot Basis-toewijzing bevat geavanceerde toewijzing veel nuances die, afhankelijk van de complexiteit van uw omgeving, zorgvuldige aandacht kunnen vereisen bij de configuratie. In dit gedeelte worden de nuances voor het configureren van geavanceerde responstoewijzing toegelicht. Raadpleeg ons artikel over geavanceerde toewijzing voor een volledige lijst met ondersteunde attributen.

Geavanceerde toewijzing wordt telkens toegepast wanneer een gebruiker zich authenticeert

In tegenstelling tot Basis-toewijzing, die voor sommige categorieën Optioneel toe te passen updates heeft, worden configuraties voor geavanceerde toewijzing telkens toegepast wanneer een gebruiker zich authenticeert, volgens de top-downvolgorde van applicatie.

Als een gebruiker bijvoorbeeld een Basis-licentie heeft en zich vervolgens via SSO authenticeert met een kenmerk en waarde die zijn toegewezen aan het verlenen van een volledige licentie, krijgt de gebruiker onmiddellijk de volledige licentie. Als het profiel van de gebruiker vervolgens binnen de identiteitsprovider wordt gewijzigd om deze terug te zetten naar een Basis-licentie, krijgt de gebruiker opnieuw de Basis-licentie toegewezen zodra deze zich opnieuw authenticeert binnen Zoom.

Geavanceerde toewijzing staat meerdere kenmerken en waarden per categorie toe

In tegenstelling tot Basis-toewijzing, die slechts één kenmerk per categorie toestaat, kan geavanceerde toewijzing meerdere kenmerken en waarden voor elke categorie ondersteunen. Dit biedt aanzienlijke flexibiliteit bij het beheren van licenties en Access voor gebruikers via beveiligingsgroepen binnen uw identiteitsprovider, zoals te zien is in de volgende configuratie.

Voorbeeld van geavanceerde kenmerktoewijzing.

Geavanceerde toewijzing past licenties van boven naar beneden toe wanneer meerdere attributen worden opgegeven

Als een gebruiker meerdere attributen of waarden doorgeeft die zijn geconfigureerd voor geavanceerde toewijzing, zal Zoom de licenties van boven naar beneden toewijzen. Zie het volgende voorbeeld:

Voorbeeld van selectie van licentietype in beheerderinstellingen.

Volgens de bovenstaande configuratie, als een gebruiker een attribuut voor beide zou doorgeven global_users en marketing, omdat marketing de hoogste is in de configuratie, wordt dit attribuut toegepast op de gebruiker en worden de overige toepasselijke attributen genegeerd.

Als alternatief, als de configuratie was ingesteld met global_users als de hoogste, zoals te zien in de volgende schermafbeelding, als de bewering van een gebruiker bevatte global_users, marketing, mens bronnen, en IT, omdat global_users is de hoogste prioriteit, wordt alleen een Basis-licentie toegewezen.

Voorbeeld van het aanpassen van de prioriteitsvolgorde

Zoom-beheerders kunnen de volgorde van applicatie aanpassen bij het bewerken van de toewijzingswaarden met de ↑↓-pijlen in de editor.

webinar- en Grote vergaderingen-koppelingen kunnen een gemeenschappelijke waarde delen om beide Toevoegen toe te passen

Om het applicatieproces te vereenvoudigen kunnen Zoom-beheerders hetzelfde kenmerk en dezelfde waarde twee keer configureren (Configureer) om zowel webinar- als Grote vergaderingen-toevoegingen (Toevoegen) toe te passen op de gebruikers (gebruiker), zoals te zien is in de volgende afbeelding met de global_users waarde. Deze toevoegingen (Toevoegen) kunnen desgewenst ook afzonderlijk worden geconfigureerd (Configureer), zoals wordt getoond met de webinar en Grote vergaderingen alleen waarden.

Voorbeeld van kenmerken voor Grote vergaderingen alleen en webinar alleen.

Aangewezen gebruikers (gebruiker) en gebruikersgroepen kunnen worden vrijgesteld van specifieke toewijzingen

Elke optie onder Geavanceerde toewijzing kan worden geconfigureerd (Configureer) om specifieke gebruikers (gebruiker) en gebruikersgroepen vrij te stellen van toewijzingsgedrag. Dit kan nuttig zijn om te voorkomen dat VIP-gebruikers (gebruiker) worden verstoord in hun dienstverlening door een mogelijke wijziging (Wijzigen) in licenties.

Voorbeeld van vrijstellingen voor gebruikers (gebruiker).

Zoom ondersteunt tot vijf aangepaste kenmerken

Zoom-beheerders kunnen maximaal Configureer vijf aangepaste kenmerken voor het toevoegen van gebruikersgegevens aan hun Zoom-profiel onder het geavanceerd Gebruikersbeheer pagina. Na het toevoegen van de aangepaste velden kunnen Zoom-beheerders de toewijzing Configureer op de Responsmapping pagina.

Voorbeeld van aangepaste kenmerken

Het toewijzen van gebruikers aan een sub-account zal alleen een vergaderinglicentie en Toevoegen-ons toepassen

Het toewijzen van een gebruiker aan een sub-account past alleen de vergaderinglicentie en Toevoegen-ons van een gebruiker, zoals webinar en Grote vergaderingen, toe op het sub-account. Gebruikersgroepen, IM-groepen, Gebruikersrollen enzovoort worden niet toegepast en moeten binnen het sub-account worden geconfigureerd.

Klanten die meer flexibiliteit vereisen voor response-mapping met subaccounts hebben een unieke vanity-URL en een nieuwe SSO-configuratie binnen het sub-account nodig.

Geavanceerde mapping: toewijzing van gebruiker-Groep en contactpersoon-Groep

De toewijzing van gebruiker-Groep en contactpersoon-Groep is het ene onderdeel van geavanceerde mapping dat in twee verschillende modi werkt: standaard mapping en multi-mapping.

  • Standaard mapping past één enkele match toe. Een beheerder kan veel attribuut- en waardeparen configureren, maar wanneer een gebruiker authenticatie uitvoert, is alleen de eerste overeenkomende vermelding van kracht en worden de rest genegeerd. Het bereiken van een specifiek resultaat hangt daarom af van een nauwkeurige, exacte configuratie. Dit is het Standaard gedrag voor alle accounts.

  • Multi-mapping is een optionele modus die elke match toepast. Eén authenticatie kan meerdere attributen en waarden tegelijk matchen, waardoor de gebruiker in één keer aan meerdere groepen wordt toegewezen. Dit maakt het zeer geschikt voor accounts met complexe groepsstructuren die gebruikers over een breed scala aan Gebruiker-Groepen en Contactpersoon-Groepen plaatsen. Multi-mapping moet via Zoom-ondersteuning worden ingeschakeld.

Standaard mapping wijst een gebruiker toe aan de eerste overeenkomende Gebruiker-Groep of Contactpersoon-Groep

Bij standaardtoewijzing past Zoom, wanneer de verklaring van een gebruiker overeenkomt met meerdere geconfigureerde waarden binnen de categorie Gebruikersgroep of Contactgroep, alleen de bovenste overeenkomende invoer in de configuratie toe. De invoeren worden van boven naar beneden geëvalueerd en de eerste die overeenkomt, wordt toegepast. Alle overige overeenkomsten binnen die categorie worden genegeerd.

Bijvoorbeeld, in een configuratie met twintig attribuut- en waardepares die aan verschillende Gebruikersgroepen zijn toegewezen, wordt een gebruiker van wie de verklaring overeenkomt met meerdere van die paren, alleen in de Groep geplaatst die bij de hoogste overeenkomende invoer hoort.

Met één waarde kan een gebruiker aan meerdere groepen worden Toevoegen, en de eerste toegevoegde Groep wordt de Primaire Groep.

Zoom-beheerders kunnen de toewijzing van Gebruikersgroepen Configureer om met één waarde een gebruiker aan meerdere groepen te Toevoegen. Dit gedrag geldt voor zowel standaardtoewijzing als multitoewijzing.

De eerste gebruiker Groep die wordt toegevoegd, wordt ingesteld als de Primaire Groep van de gebruiker en bepaalt de Standaard Instellingen van de gebruiker. tenzij een onderliggende Groep een instelling heeft vergrendeld. Raadpleeg voor meer informatie over Gebruikersgroepen onze ondersteuningsartikel.

In de volgende afbeelding, als een gebruiker de waarden heeft doorgegeven voor Leiderschap, Personeelszaken, en Gereguleerd, zouden ze alleen in de groepen voor worden geplaatst Leiderschap, omdat het de eerste overeenkomst is en geen verdere overeenkomsten van toepassing zijn.

Voorbeeld van standaard gebruiker Groep-mapping.

Multi-mapping wijst een gebruiker toe aan elke overeenkomende gebruiker Groep en contactpersoon Groep, voor maximaal 50 regelovereenkomsten

Wanneer multi-mapping is ingeschakeld, past Zoom elke overeenkomende invoer binnen de categorieën gebruiker Groep en contactpersoon Groep in plaats van alleen de bovenste overeenkomst. Hetzelfde attribuut kan tot vijftig keer worden geconfigureerd, en elke geconfigureerde waarde die overeenkomt met een assertion plaatst de gebruiker in de bijbehorende Groep.

Dit betekent dat een enkel attribuut dat met vijftig verschillende waarden wordt doorgegeven, elk toegewezen aan een andere groep, een gebruiker in alle vijftig groepen kan plaatsen in een enkele authenticatie. Dit maakt een één-op-éénrelatie mogelijk tussen beveiligingsgroepen van de identiteitsprovider en Zoom-groepen, zodat het toevoegen van een gebruiker aan een beveiligingsgroep binnen de identiteitsprovider hen bij hun volgende authenticatie toewijst aan de bijbehorende Zoom-groep.

In de volgende afbeelding, als een gebruiker de waarden heeft doorgegeven voor leiderschap, testen, AI, en personeelszaken met multi-mapping ingeschakeld, zou de gebruiker in alle gebruiker Groepen worden geplaatst, omdat Zoom de eerste 50 regelovereenkomsten toepast wanneer multi-mapping is ingeschakeld.

Voorbeeld van multi-mapping van gebruiker Groepen

De aanduiding van de Primaire Groep wordt niet beïnvloed door de mappingmodus. Bij zowel Standaard mapping als multi-mapping wordt de eerst overeenkomende Groep die wordt toegevoegd de Primaire Groep van de gebruiker, tenzij een onderliggende Groep een vergrendelde instelling heeft.

Multi-mapping vereenvoudigt Groeptoewijzing in grote Onderneming-omgevingen

Multi-mapping vermindert de configuratieprecisie die nodig is om gebruikers toe te wijzen aan meerdere gebruiker Groepen of contactpersoon Groepen. Onder Standaard mapping hangt het plaatsen van een gebruiker in meerdere Groepen af van een exacte configuratie van boven naar beneden die in één evaluatie correct wordt opgelost. Multi-mapping verwijdert deze beperking door alle overeenkomende vermeldingen tegelijk toe te passen, wat omgevingen ondersteunt waarin gebruikers tot veel Groepen behoren en waarin configuraties per attribuut, per waarde anders moeilijk uit te voeren zouden zijn in één doorgang.

Multi-mapping vereist activering via Zoom-ondersteuning

Multi-mapping is niet ingeschakeld via de Standaard SSO-beheerinterface. Het inschakelen van de Functie(s) vereist het indienen van een verzoek om ondersteuning naar Zoom met het verzoek dat multi-mapping wordt geactiveerd voor het account. Totdat het verzoek is verwerkt, werkt Toewijzen van gebruiker Groep en contactpersoon Groep onder Standaard first-match-gedrag.

Geavanceerde toewijzing: Automatische toewijzing

Automatische toewijzing fungeert als terugvaloptie die gebruikers Toewijzen aan een gebruiker, kanaal of IM-Groep met de naam van hun opgegeven waarde wanneer geen expliciete regel overeenkomt

Automatische toewijzing kan worden gebruikt om gebruikers automatisch Toewijzen aan een gebruiker Groep, kanaal en IM-Groep met de naam van hun opgegeven waarde. In tegenstelling tot andere geavanceerde toewijzingsonderdelen, die kunnen worden geconfigureerd om een gebruiker aan elke Groep toe te wijzen op basis van de waarde, wijst Automatische toewijzing een gebruiker altijd toe aan een Groep op basis van de exacte waarde. Als de Groep eerder niet bestond, wordt deze automatisch aangemaakt.

Automatische toewijzing fungeert als terugvaloptie en is alleen van toepassing wanneer de bevestiging van een gebruiker niet overeenkomt met een van de expliciete regels die zijn geconfigureerd in de geavanceerde toewijzingssecties hierboven. Als aan een gebruiker al via een expliciete regel een Groep is toegewezen—bijvoorbeeld geplaatst in een gebruiker Groep op basis van lidmaatschap van de beveiligingsgroep van de identiteitsprovider—heeft die expliciete Toewijzen voorrang en wordt de overeenkomstige Automatische toewijzing-regel genegeerd. In hetzelfde voorbeeld zou een gebruiker Groep die automatisch is toegewezen op basis van de afdelingswaarde van de gebruiker niet van toepassing zijn, omdat de expliciete gebruiker Groep-regel al overeenkwam.

Voorbeeld van een Automatische toewijzing-configuratie.

Bijvoorbeeld, als Automatische toewijzing is ingesteld om een gebruiker toe te wijzen aan de Groepen op basis van hun afdeling, en de gebruiker geen overeenkomende expliciete regel heeft voor die categorie, dan, als hun afdelingswaarde nog niet is gedefinieerd voor de gebruiker Groep, kanaal of IM-Groep, zullen gebruikers automatisch worden toegewezen aan een Groep die overeenkomt met hun afdelingsnaam, zoals getoond in de volgende tabel:

Attribuut
Waarde
Bestaat Zoom Groep al?
Resultaat

Afdeling

Personeelszaken

Ja

gebruiker toegevoegd aan de Human Resources Groep

Afdeling

Marketing

Ja

gebruiker toegevoegd aan de Marketing Groep

Afdeling

Verkoop

Nee

Verkoop Groep is gemaakt, gebruiker toegevoegd aan de Verkoop Groep

Problemen oplossen met SSO

Responslogboeken kunnen worden opgeslagen voor probleemoplossing

Zoom kan responslogboeken van authenticatiepogingen zeven dagen na een authenticatie opslaan. Deze responslogboeken kunnen een onschatbaar hulpmiddel zijn voor het oplossen van configuratie- en gebruikerfouten, naast configuraties voor responsmapping. Lees het gedeelte over problemen oplossen met fouten met responslogboeken voor meer informatie.

Response-logboeken gebruiken om problemen op te lossen

Opgeslagen response-logboeken kunnen een onschatbaar hulpmiddel zijn voor het oplossen van configuratie- en gebruikerfouten, naast configuraties voor response-toewijzing. Als uw Zoom SSO-configuratie is ingesteld om response-logboeken op te slaan, kunnen deze worden geopend via het Responselog Het tabblad is Beschikbaar op de SSO-configuratiepagina in Geavanceerde Instellingen. Klik om response-logboeken te bekijken op Details weergeven naast een authenticatiepoging.

De meeste authenticaties worden weergegeven in de response-logboeken

De meeste mislukte of onsuccesvolle authenticatiepogingen worden weergegeven op de pagina met response-logboeken. Als een authenticatiepoging niet wordt weergegeven, heeft Zoom hoogstwaarschijnlijk geen assertion ontvangen van uw identiteitsprovider, of is het opslaan van response-logboeken uitgeschakeld.

Response-logboeken kunnen u vertellen of uw configuratie onjuist is of uw certificaat verouderd is

Wanneer het opslaan van response-logboeken is ingeschakeld, wordt de informatie van de identiteitsprovider aan Zoom doorgegeven om de identiteiten van elke partij te authenticeren. Als een doorgegeven instelling of een reeks informatie, zoals het X509-certificaat of de uitgever-ID, anders is dan de huidige Zoom-configuratie, verschijnt er een foutmelding met de melding dat de informatie “niet overeenkomt met de huidige SSO-Instellingen.” Een Zoom-beheerder kan de SSO-configuratie bijwerken zodat deze overeenkomt met deze doorgegeven waarden als ze correct zijn om de fout op te lossen.

Voorbeeld van onjuiste configuratiewaarschuwingen.

Responslogboeken laten u zien welke waarden en attributen worden geclaimd

Het bekijken van responslogboeken kan helpen bij het oplossen van configuraties voor responskoppeling door te verifiëren welke attributen en waarden door gebruikers worden geclaimd terwijl ze authenticeren. Deze kunnen worden vergeleken met de configuratie om ervoor te zorgen dat de attributen en waarden overeenkomen.

Voorbeeld van informatie die wordt geclaimd door de identiteitsproviderdienst.

Als attributen of waarden ontbreken, wordt de informatie niet geclaimd door de identiteitsproviderdienst. Gebruikers die dit probleem ondervinden, worden aangemoedigd contact op te nemen met hun ondersteuningsdiensten van de identiteitsprovider voor meer hulp.

Responslogboeken bevatten een foutcode en een korte uitleg, als het niet is gelukt

Als een gebruiker niet kan authenticeren of een fout ontvangt, bevatten de responslogboeken een foutcode en een korte uitleg van de fout.

Voorbeeld van foutcode en uitleg.

De meeste problemen kunnen worden geïdentificeerd en opgelost met behulp van deze foutmeldingen. Als u de fout niet kunt oplossen, neem dan contact op met Zoom-ondersteuning voor extra hulp.

Fouten met webtracking-id's

Als een gebruiker niet slaagt voor SSO-authenticatie, ontvangt deze een WEB Tracking ID-foutcode. Deze codes zijn geen foutmelding die verband houdt met een specifieke fout, maar zijn in plaats daarvan een unieke log-ID die kan worden beoordeeld in Response Mapping om authenticatieproblemen te identificeren.

Voorbeeld van een fout voor de gebruiker met een WEB Tracking ID-foutcode.

Om de fout te identificeren, als responslogging is ingeschakeld, navigeert u naar het Responselog Tabblad Beschikbaar binnen de SSO-configuratiepagina in Geavanceerde Instellingen. Vanaf daar kunt u de WEB tracking-ID Invoeren in het veld Tracking ID en zoeken om het responslogboek te vullen

Voorbeeld van het doorzoeken van het Responslogboek met de bovengenoemde WEB Tracking ID-foutcode.

De responslogboeken moeten de ontvangen assertion en een foutcode en bericht onderaan de respons weergeven die kunnen worden gebruikt voor aanvullende probleemoplossing.

SCIM-probleemoplossing

Fouten

Gebruiker bestaat niet of behoort niet tot dit account

Deze fout treedt op wanneer het E-mailadres van een beoogde gebruiker niet kan worden geprovisioned vanwege een al bestaand account. Zoom-beheerders worden aangemoedigd om rechtstreeks contact op te nemen met de gebruiker en de gebruiker handmatig uit te nodigen voor het account.

Voorbeeld van een provisioningfout.

Toevoegen van betaalde gebruikers is niet mogelijk

Deze fout treedt op wanneer SCIM probeert een gebruiker te provisionen terwijl er onvoldoende licenties op het account zijn. Om de fout op te lossen, moet de gebruiker als Basisgebruiker worden geprovisioned, of moet er een licentie Beschikbaar worden gemaakt voor provisioning.

Voorbeeld van een provisioningfout.

SCIM-logboeken gebruiken om problemen met gebruikersprovisioning op te lossen

Zoom biedt de meest recente 100 API-verzoeklogboeken in de Zoom Marketplace. Een Zoom-beheerder kan deze logs gebruiken om te bevestigen welke informatie wordt verzonden en ontvangen via provisioning-API's. Meld u aan bij Zoom Marketplace als Zoom-beheerder en klik op om toegang te krijgen tot de logs Beheren. Op de volgende pagina, Selecteer Bellenlogboeken onder Persoonlijk app-beheer. Vanaf daar klikt u op een item om de API-logboeken uit te vouwen en de inhoud te bekijken.

De volgende afbeelding toont een voorbeeld van een SCIM-aanvraag voor gebruikersprovisioning, met de identiteit en licentieattributen van de gebruiker gemarkeerd ter referentie.

Voorbeeld van een SCIM-gebruikerprovisioningverzoek.

Net als bij responsmapping kan Zoom alleen informatie toepassen die in het inrichtingsverzoek vanuit de identiteitsprovider wordt ingediend. Gebruik deze logboeken om te bevestigen dat gebruikersidentiteit- en licentieattributen vanuit de identiteitsprovider worden ingediend. Als verwachte informatie ontbreekt in deze verklaringen, neem contactpersoon op met uw identiteitsprovider voor ondersteuning.

Gegevensstromen en authenticatie

SAML-authenticatie

Het volgende diagram beschrijft de SAML-authenticatiestroom van een gebruiker bij het starten van een Single Sign-On-sessie met Zoom.

Diagram van een voorbeeld van een SAML-authenticatieflow.

OIDC-authenticatie

Het volgende diagram beschrijft de OIDC-authenticatieflow van een gebruiker wanneer deze een Single Sign-On-sessie met Zoom start.

Diagram of an example SAML authentication flow.
Diagram van een voorbeeld van een SAML-authenticatieflow.

SSO-webinlogtoken

Nadat een gebruiker zich heeft geauthenticeerd, wordt de sessie van de gebruiker in hun Browser opgebouwd en heeft deze Standaard een levensduur van twee uur. Als de gebruiker zijn Zoom-webpagina actief blijft gebruiken, wordt de sessie vernieuwd; als de gebruiker zijn webpagina echter twee uur lang niet gebruikt, verloopt het token en moet de gebruiker zich opnieuw authenticeren. Zoom-beheerders kunnen deze Actief sessielengte Configureer op de Beveiliging pagina onder Gebruikers moeten zich na een periode van inactiviteit opnieuw Aanmelden en Stel de periode voor inactiviteit op het web in (minuten).

Client-inlogtoken

Wanneer een gebruiker probeert te authenticeren via SSO binnen een client, opent de machine van de gebruiker een Browser en wordt deze omgeleid naar de inlogpagina van de identiteitsprovider. Nadat een gebruiker zich heeft geauthenticeerd, ontvangt de Browser van de gebruiker een Zoom-clientstarttoken. Zodra een gebruiker op de knop 'openen' of 'starten' klikt, gebruikt de Browser het URL-schema in combinatie met het starttoken om de Zoom-client te openen.

De Zoom-client gebruikt het starttoken om de Access token en de vernieuwtoken van de Zoom-server op te halen. De client gebruikt de Access token telkens gedurende twee uur en gebruikt bij het verlopen de vernieuwtoken om een nieuwe set tokens te krijgen, die worden opgeslagen in de lokale database van de client. Dit vernieuwproces is Standaard onbeperkt en kan tokens voortdurend blijven doorlopen totdat een gebruiker zich afmeldt of de tokens verlopen. Zoom-beheerders kunnen de sessielengte aanpassen op de SSO Instellingen pagina onder automatisch afmelden afdwingen.

Laatst bijgewerkt

Was dit nuttig?