Configureren en problemen oplossen met de WebApp SSO op CMS

Inleiding

In dit document wordt beschreven hoe u de Cisco Meeting Server (CMS) Web App-implementatie van Single Sign On (SSO) configureert en problemen oplost.

Voorwaarden

Vereisten

Cisco raadt u aan kennis te hebben van deze onderwerpen:

• CMS Callbridge versie 3.1 of hoger

• CMS Webbridge versie 3.1 of hoger

• Active Directory-server

• Identificeer provider (IDp)

Gebruikte componenten

De informatie in dit document is gebaseerd op de volgende software- en hardware-versies:

• CMS Callbridge versie 3.2

• CMS Webbridge versie 3.2

• Microsoft Active Directory Windows Server 2012 R2

• Microsoft ADFS 3.0 Windows Server 2012 R2

De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u zorgen dat u de potentiële impact van elke opdracht begrijpt.

Achtergrond

CMS 3.1 en hoger introduceerde de mogelijkheid voor gebruikers om zich aan te melden met behulp van een SSO zonder dat ze hun wachtwoord hoeven in te voeren telkens wanneer de gebruiker zich aanmeldt, omdat er één sessie wordt gemaakt met de Identity-provider.
Deze functie gebruikt de SAML-versie (Security Assertion Markup Language) 2.0 als het SSO-mechanisme.

Opmerking: CMS ondersteunt alleen HTTP-POST-bindingen in SAML 2.0 en wijst elke Identificeer Provider af zonder dat er HTTP-POST-bindingen beschikbaar zijn.

Opmerking: wanneer SSO is ingeschakeld, is elementaire LDAP-verificatie niet meer mogelijk.

Configureren

Netwerkdiagram

ADFS-installatie en initiële installatie

In dit implementatiescenario wordt Microsoft Active Directory Federation Services (ADFS) gebruikt als Identity Provider (IdP) en daarom wordt voorgesteld om een ADFS (of beoogde IdP) te installeren en uit te voeren voorafgaand aan deze configuratie.

CMS-gebruikers toewijzen aan Identity Provider (IdP)

Om gebruikers een geldige authenticatie te laten krijgen, moeten ze worden toegewezen in de Application Programming Interface (API) voor een correlerend veld dat door IdP wordt aangeboden. De hiervoor gebruikte optie is de authenticationIdMapping in de ldapMapping van de API.

1. Navigeer naar Configuratie > API op de CMS Web Admin GUI

Co

2. Zoek bestaande (of maak een nieuwe) LDAP-toewijzing onder api/v1/ldapMappings/<GUID-of-Ldap-Mapping>.

3. Werk in het geselecteerde ldapMapping-object de authenticationIdMapping bij naar het LDAP-kenmerk dat wordt doorgegeven vanaf de IdP. In het voorbeeld wordt de optie $sAMAaccountName gebruikt als het LDAP-kenmerk voor toewijzing.

Opmerking: De authenticatieIdMapping wordt gebruikt door de callbridge / database om de claim te valideren die is verzonden vanaf de IdP in de SAMLR-reactie en de gebruiker een JSON Web Token (JWT) te bieden.

4. Voer een LDAP-synchronisatie uit op de ldapSource die is gekoppeld aan de onlangs gewijzigde ldapMapping:

Voorbeeld:

5. Nadat de LDAP-synchronisatie is voltooid, navigeert u in de CMS API in Configuration > api/v1/users en selecteert u een geïmporteerde gebruiker en controleert u of de verificatie-ID correct is ingevuld.

Webbridge Metadata XML maken voor IdP

Met de Microsoft ADFS kan een metagegevens-XML-bestand worden geïmporteerd als een vertrouwenspersoon om de serviceprovider te identificeren die wordt gebruikt. Er zijn een paar manieren om het Metadata XML-bestand voor dit doel te maken, maar er zijn een paar kenmerken die in het bestand aanwezig moeten zijn:

Voorbeeld van Webbridge-metagegevens met vereiste waarden:

1. entityID - Dit is het Webbridge3-serveradres (FQDN/Hostname) en de bijbehorende poort die door browsers voor gebruikers kan worden bereikt.
   
   

   Opmerking: als er meerdere webbruggen zijn die één URL gebruiken, moet dit een taakverdelingsadres zijn.

   
   
   
2. Locatie - Dit is de locatie waar de HTTP-POST AssertionConsumerService voor het Webbridge-adres wordt gebruikt. Dit is wat de IdP vertelt waar een geverifieerde gebruiker na aanmelding moet worden omgeleid. Dit moet worden ingesteld op de URL idpResponse: https://<WebbridgeFQDN>:<port>/api/auth/sso/idpResponse.  Bijvoorbeeld https://join.example.com:443/api/auth/sso/idpResponse.
   
   
3. OPTIONEEL - Openbare sleutel voor ondertekening - dit is de openbare sleutel (certificaat) voor ondertekening, die door de IdP wordt gebruikt om AuthRequest van Webbridge te verifiëren. Dit MOET overeenkomen met de privésleutel 'sso_sign.key' op de SSO-bundel die op Webbridge is geüpload, zodat de IdP de openbare sleutel (certificaat) kan gebruiken om de handtekening te verifiëren. U kunt een bestaand certificaat uit uw implementatie gebruiken.  Open het certificaat in een tekstbestand en kopieer de inhoud naar het Webbridge Metadata-bestand.  Gebruik de overeenkomende sleutel voor het certificaat dat wordt gebruikt in het bestand sso_xxxx.zip als het bestand sso_sign.key.
   
   
4. OPTIONEEL - Openbare sleutel voor codering - dit is de openbare sleutel (certificaat) die de IdP gebruikt om SAML-informatie te coderen die naar Webbridge wordt teruggestuurd. Dit MOET overeenkomen met de privésleutel 'sso_encrypt.key' op de SSO-bundel die op Webbridge is geüpload, zodat Webbridge kan decoderen wat door IdP wordt teruggestuurd.  U kunt een bestaand certificaat uit uw implementatie gebruiken.  Open het certificaat in een tekstbestand en kopieer de inhoud naar het Webbridge Metadata-bestand.  Gebruik de overeenkomende sleutel voor het certificaat dat wordt gebruikt in het bestand sso_xxxx.zip als het bestand sso_encrypt.key. 

Voorbeeld van Webbridge-metagegevens die in IdP moeten worden geïmporteerd met optionele gegevens over publieke sleutels (certificaten):

Metagegevens voor Webbridge importeren in Identity Provider (IdP)

Nadat de XML-metagegevens met de juiste kenmerken zijn gemaakt, kan het bestand worden geïmporteerd in de Microsoft ADFS-server om een vertrouwenspersoon te maken.

1. Extern bureaublad naar de Windows Server waarop de ADFS-services worden gehost

2. Open de AD FS Management Console, die meestal toegankelijk is via Serverbeheer.

3. Navigeer in de ADFS-beheerconsole naar ADFS > Vertrouwensrelaties > Vertrouwen op een betrouwbare partij in het linkerdeelvenster.

4. Selecteer in het rechterdeelvenster van de ADFS Management Console de optie Add Relying Party Trust...

5. Nadat u deze optie hebt geselecteerd, wordt de wizard Vertrouwen van vertrouwenspersoon toevoegen geopend. Selecteer de optie Start.

6. Selecteer op de pagina Gegevensbron selecteren het keuzerondje Gegevens importeren over de vertrouwende partij uit een bestand en selecteer Bladeren en navigeer naar de locatie van het Webbridge MetaData-bestand.

7. Zet op de pagina Geef weergavenaam op om een naam voor de entiteit in ADFS weer te geven (de weergavenaam heeft geen serverdoel voor de ADFS-communicatie en is louter informatief).

8. Op de pagina Configure Multi-factor Authentication Now? (Meerfactorenverificatie nu configureren)? selecteert u Volgende.

9. Laat op de pagina Choose Issuance Authorization Rules alle gebruikers zoals geselecteerd voor Permit toegang tot deze vertrouwende partij.

10. Op de pagina Ready to Add Trust kunnen de geïmporteerde gegevens van de Relying Trust Party voor Webbridge worden bekeken via de tabbladen. Controleer de ID's en eindpunten voor de URL-gegevens voor de Webbridge-serviceprovider.

11. Selecteer op de pagina Voltooien de optie Sluiten om de wizard te sluiten en verder te gaan met het bewerken van claimregels.

Claim Rules maken voor de Webbridge Service op de IdP

Nu de Relying Party Trust voor de Webbridge is gemaakt, kunnen claimregels worden gemaakt om specifieke LDAP-kenmerken af te stemmen op uitgaande claimtypen die aan de Webbridge moeten worden verstrekt in de SAML-respons.

1. Markeer in de ADFS-beheerconsole het vertrouwen van de vertrouwende partij voor de Webbridge en selecteer Claimregels bewerken in het rechterdeelvenster.

2. Selecteer op de pagina Claim bewerken voor <DisplayName> de regel Toevoegen....

3. Selecteer op de pagina Wizard Regel voor claim toevoegen de optie LDAP-kenmerken als claim verzenden voor de sjabloon voor de regel voor claim en selecteer Volgende.

4. Configureer op de pagina Configure Claim Rule de claimregel voor de Trust van de vertrouwende partij met de volgende waarden:

1. Naam van regel voor claim = dit moet een naam zijn die aan de regel is gegeven in ADFS (alleen voor verwijzing naar regel)
2. Attribuutarchief = Active Directory
3. LDAP Attribuut = Dit moet overeenkomen met authenticationIdMapping in de Callbridge API. (Bijvoorbeeld $sAMAaccountName$.)
4. Type uitgaande claim = Dit moet overeenkomen met de verificatie-IDmapping in de Webbridge SSO config.json. (Bijvoorbeeld uid.)
   
   

ZIP-bestand voor SSO-archief maken voor Webbridge:

Deze configuratie is waar de Webbridge naar verwijst om de SSO-configuratie te valideren voor ondersteunde domeinen, authenticatietoewijzing, enzovoort. Voor dit deel van de configuratie moet rekening worden gehouden met de volgende regels:

• Het ZIP-bestand MOET beginnen met sso_ voorafgegaan door de bestandsnaam (bijvoorbeeld sso_cmstest.zip).
• Zodra dit bestand is geüpload, schakelt Webbridge basisverificatie uit en kan ALLEEN SSO worden gebruikt voor de Webbridge waarnaar dit is geüpload.
• Als er meerdere Identity Providers worden gebruikt, moet een apart ZIP-bestand worden geüpload met een ander naamgevingsschema (NOG steeds voorafgegaan door de sso_).
• Wanneer u het zip-bestand maakt, moet u de inhoud van het bestand markeren en zippen en de vereiste bestanden niet in een map zetten en die map zippen.

De inhoud van het zip-bestand bestaat uit 2 tot 4 bestanden, afhankelijk van of codering wordt gebruikt of niet.

De idp_config.xml verkrijgen en configureren

1. Open op de ADFS-server (of een locatie die toegang heeft tot de ADFS) een webbrowser.
   
   

2. Voer in de webbrowser de URL in: https://<ADFSFQDN>/FederationMetadata/2007-06/FederationMetadata.xml (U kunt ook localhost gebruiken in plaats van de FQDN als u zich lokaal op de ADFS-server bevindt).  Dit downloadt het bestand FederationMetadata.xml.

3. Kopieer het gedownloade bestand naar een locatie waar het zip-bestand wordt gemaakt en geef het de nieuwe naam idp_config.xml.

Het bestand config.json met inhoud maken

De config.json bevat deze 3 attributen en ze moeten tussen haakjes staan, { }:

1. supportedDomains - Dit is een lijst met domeinen die zijn gecontroleerd op SSO-verificatie ten opzichte van de IdP. Meerdere domeinen kunnen worden gescheiden door een komma.
2. authenticationIdMapping - Dit is de parameter die wordt doorgegeven als onderdeel van de regel voor uitgaande claims van de ADFS/IdP. Dit moet overeenkomen met de naamwaarde van het uitgaande claimtype op de IdP. Claim regel.
3. ssoServiceProviderAddress - Dit is de FQDN-URL waarnaar de Identificatieprovider de SAML-antwoorden verzendt. Dit moet de Webbridge FQDN zijn.
   
   

Stel de sso_sign.key in (OPTIONEEL) 

Dit bestand moet de privésleutel bevatten van het certificaat dat is gebruikt voor ondertekening in de Webbridge-metagegevens die zijn geïmporteerd in de IdP. Het certificaat dat voor ondertekening wordt gebruikt, kan tijdens het importeren van de Webbridge-metagegevens in de ADFS worden ingesteld door het X509Certificate in te vullen met de certificaatinformatie in de sectie <KeyDescriptor use=signing>. Het kan ook worden bekeken (en geïmporteerd) op ADFS in de Webbridge Relying Trust Party onder Eigenschappen > Handtekening. 

In het volgende voorbeeld ziet u het callbridge-certificaat (CN=cmscb3.brhuff.local), dat aan de Webbridge-metagegevens is toegevoegd voordat het in ADFS werd geïmporteerd. De privésleutel die in de sso_sign.key is ingevoegd, is de sleutel die overeenkomt met het cmscb3.brhuff.local-certificaat.

Dit is een optionele configuratie en is alleen nodig als u de SAML-antwoorden wilt coderen.

De sso_encrypt.key instellen (OPTIONEEL)

Dit bestand moet de privésleutel bevatten van het certificaat dat wordt gebruikt voor codering in de webbridge-metagegevens die zijn geïmporteerd naar de IdP. Het certificaat dat voor codering wordt gebruikt, kan tijdens het importeren van de Webbridge-metagegevens in de ADFS worden ingesteld door het X509Certificate te vullen met de certificaatinformatie in de sectie <KeyDescriptor use=encryption>. Het kan ook worden bekeken (en geïmporteerd) op ADFS in de Webbridge Relying Trust Party onder Eigenschappen > Codering. 

In het volgende voorbeeld ziet u het callbridge-certificaat (CN=cmscb3.brhuff.local), dat aan de Webbridge-metagegevens is toegevoegd voordat het in ADFS werd geïmporteerd. De private sleutel die in de 'sso_encrypt.key' is ingevoegd, is degene die overeenkomt met het cmscb3.brhuff.local certificaat.

Dit is een optionele configuratie en is alleen nodig als u van plan bent de SAML-antwoorden te coderen.

Het SSO ZIP-bestand maken

1. Markeer alle bestanden die voor het SSO-configuratiebestand moeten worden gebruikt.

Let op: niet de map met de bestanden zippen, omdat dit ertoe leidt dat de SSO niet werkt.

2. Klik met de rechtermuisknop op de bestanden markeren en selecteer Verzenden naar > Gecomprimeerde (gezipte) map.

3. Nadat de bestanden zijn gezipt, wijzigt u de naam in de gewenste naam met het voorvoegsel sso_:

Upload de SSO Zip-bestand(en) naar Webbridge

Open een SFTP/SCP-client, in dit voorbeeld wordt WinSCP gebruikt en maak verbinding met de server waarop Webbridge3 wordt gehost.

1. Navigeer in het linkerdeelvenster naar de locatie waar het SSO Zip-bestand zich bevindt en klik met de rechtermuisknop op upload of sleep het bestand.

2. Zodra het bestand volledig naar de Webbridge3-server is geüpload, opent u een SSH-sessie en voert u de opdracht webbridge3 opnieuw starten uit.

3. In de syslog geven deze berichten aan dat de SSO succesvol was:

Common Access Card (CAC)

Een Common Access Card (CAC) is een smartcard die dient als de standaard-identificatie voor actieve militairen, civiele medewerkers van het ministerie van Defensie en in aanmerking komend aannemerspersoneel. 

Hier is het volledige aanmeldingsproces voor gebruikers die CAC-kaarten gebruiken:

1. Pc inschakelen en in CAC-kaart blijven
2. Log in (kies soms cert) en voer pincode in
3. Browser openen
4. Navigeer naar de URL voor deelname en bekijk de opties Deelnemen aan een vergadering of Aanmelden
5. Inloggen: Voer de gebruikersnaam in die is geconfigureerd als jidMapping die Active Directory verwacht van een CAC-aanmelding
6. Inloggen raken
7. De ADFS-pagina komt kort naar voren en wordt automatisch ingevuld
8. Gebruikers zijn op dit punt ingelogd

Configureer jidMapping (dit is de aanmeldnaam van de gebruiker) in Ldapmapping op dezelfde manier als wat ADFS gebruikt voor de CAC-kaart.  $userPrincipalName$ bijvoorbeeld (hoofdlettergevoelig)

Stel hetzelfde LDAP-kenmerk voor de authenticationIdMapping ook in om overeen te komen met het kenmerk dat wordt gebruikt in de claimregel in ADFS. 

Hier laat de claimregel zien dat het $ userPrincipalName$ terugstuurt naar CMS als de UID.

SSO testen Inloggen via WebApp

Nu SSO is geconfigureerd, kunt u de server testen:

1. Navigeer naar Webbridge URL voor de Web App en selecteer de knop Inloggen.

2. De gebruiker krijgt de optie om zijn gebruikersnaam in te voeren (geen wachtwoordoptie op deze pagina).

3. De gebruiker wordt vervolgens doorgestuurd naar de ADFS-pagina (na het invoeren van gebruikersgegevens), waar de gebruiker zijn referenties moet invoeren om zich te authenticeren bij IdP.

4. De gebruiker wordt na het invoeren en valideren van referenties met de IdP omgeleid met de token om toegang te krijgen tot de startpagina van de Web App:

Probleemoplossing

Basisprobleemoplossing

Voor eenvoudige probleemoplossing van elk SSO-probleem:

1. Zorg ervoor dat de geconstrueerde metagegevens voor de Webbridge3 die wordt gebruikt om te importeren als een vertrouwensrelatie in IdP correct is geconfigureerd en dat de geconfigureerde URL exact overeenkomt met het ssoServiceProviderAddress in config.json.
2. Zorg ervoor dat de metagegevens die door de IdP worden verstrekt en in het configuratiebestand van de Webbridge3-sso zijn gezipt, de laatste zijn van de IdP, alsof er wijzigingen zijn in de hostnaam van de server, certificaten, enzovoort, het moet opnieuw worden geëxporteerd en in het configuratiebestand worden gezipt.
3. Als u privésleutels ondertekent en codeert om gegevens te coderen, moet u ervoor zorgen dat de juiste overeenkomende sleutels deel uitmaken van het sso_xxxx.zip-bestand dat u naar webbridge hebt geüpload. Probeer indien mogelijk te testen zonder de optionele privésleutels om te zien of SSO werkt zonder deze gecodeerde optie.
4. Zorg ervoor dat de config.json is geconfigureerd met de juiste details voor SSO-domeinen, Webbridge3 URL EN verwachte authenticatietoewijzing die overeenkomen met de SAMLR-respons.

Het zou ook ideaal zijn om de probleemoplossing vanuit het logboekperspectief te proberen:

1. Wanneer u naar de Webbridge-URL navigeert, plaatst u ?trace=true aan het einde van de URL om een uitgebreide logboekregistratie in te schakelen op de CMS-syslog. (bijv.: https://join.example.com/en-US/home?trace=true).
2. Voer de syslog-follow op de Webbridge3-server uit om live vast te leggen tijdens het testen of voer de test uit met de traceringsoptie die aan de URL is toegevoegd en verzamel de logbundle.tar.gz van de Webbridge3- en CMS-callbridge-servers.  Als webbridge en callbridge zich op dezelfde server bevinden, is alleen het bestand logbundle.tar.gz vereist.

Microsoft ADFS-foutcodes

Soms is er een storing voor het SSO-proces die kan leiden tot een storing voor de IdP-configuratie of de communicatie met de IdP. Als u de ADFS gebruikt, is het ideaal om de volgende link te bekijken om te bevestigen dat de fout wordt gezien en om herstelmaatregelen te nemen:

Microsoft-statuscodes

Een voorbeeld hiervan is:

client_backend: FOUT: SAMLmanager: SAML-verificatieverzoek _e135ca12-4b87-4443-abe1-30d396590d58 is mislukt met reden: urn:oasis:names:tc:SAML:2.0:status:Responder

Deze fout geeft aan dat volgens de vorige documentatie de fout is opgetreden als gevolg van de IdP of ADFS en dus moet worden afgehandeld door de beheerder van de ADFS om deze op te lossen. 

Verificatie-ID is niet opgehaald

Er kunnen gevallen zijn waarin de Webbridge tijdens het uitwisselen van SAMLRresponse terug van de IdP, deze foutmelding kan weergeven in de logs met een fout in het inloggen via SSO:

client_backend: INFO: SamlManager: [57dff9e3-862e-4002-b4fa-683e4aa6922c] Een verificatie-ID is niet verkregen

Wat dit aangeeft is dat bij het bekijken van de SAMLResponse-gegevens die tijdens de authenticatie-uitwisseling van de IdP zijn teruggestuurd, de Webbridge3 geen geldig overeenkomend attribuut in het antwoord heeft gevonden in vergelijking met zijn config.json voor de authenticatie-ID.

Als de communicatie niet is gecodeerd met behulp van het teken en de codering private keys, kan de SAML Response worden geëxtraheerd uit de Developer Tools Network Logging via een webbrowser en gedecodeerd met behulp van base64. Als het antwoord versleuteld is, kunt u de gedecodeerde SAML-reactie van de IdP-kant aanvragen. 

Zorg er bij het opnemen van netwerklogs voor dat het selectievakje "Logboek behouden" is ingeschakeld, zodat de logs niet worden overschreven wanneer de pagina wordt gewijzigd. 

Zoek in de netwerklogboekuitvoer van de ontwikkelaarstools, ook wel de HAR-gegevens genoemd, naar idpResponse onder de kolom Naam en selecteer Payload om de SAML-reactie te zien.  Zoals eerder vermeld, kan dit worden gedecodeerd met behulp van base64-decoder.

Wanneer u de SAMLResponse-gegevens ontvangt, controleert u het gedeelte <AttribuutStatement> om de attribuutnamen te vinden die zijn teruggestuurd en in dit gedeelte kunt u de claimtypen vinden die zijn geconfigureerd en verzonden vanuit de IdP. Voorbeeld:

<AttribuutStatement>
<Attribuutnaam="<URL for common name">
<AttributeValue>testuser1</AttributeValue>
</Attribuut>
<Attribuutnaam="<URL for NameID">
<AttributeValue>testuser1</AttributeValue>
</Attribuut>
<Attribuutnaam="uid">
<AttributeValue>testuser1</AttributeValue>
</Attribuut>
</AttribuutStatement>

Als u de vorige namen bekijkt, kunt u het gedeelte <AttribuutName> controleren onder Attribuut-instructie en elke waarde vergelijken met wat is ingesteld in de sectie authenticationImapping van de SSO config.json.

In het vorige voorbeeld kunt u zien dat de configuratie voor de authenticatieIdMapping NIET overeenkomt met precies wat is doorgegeven en dus resulteert in het niet vinden van een overeenkomende authenticatieId:

authenticatieIdMapping: http://example.com/claims/NameID

Om dit probleem op te lossen, zijn er twee mogelijke methoden om te proberen:

1. De IdP-regel voor uitgaande claims kan worden bijgewerkt om een overeenkomende claim te hebben die exact overeenkomt met wat is geconfigureerd in authenticationIdMapping van de config.json op de Webbridge3. (Claim regel toegevoegd op IdP voor http://example.com/claims/NameID)
   OF
2. De config.json kan worden bijgewerkt op de Webbridge3 om de 'authenticationIdMapping' exact te laten overeenkomen met wat is geconfigureerd als een van de uitgaande claimregels die zijn geconfigureerd op de IdP. (Dat is 'authenticationIdMapping' die moet worden bijgewerkt om overeen te komen met een van de attribuutnamen, die "uid", "<URL>/NameID" of "<URL>/CommonName" kunnen zijn. Zolang deze overeenkomt met (exact) de verwachte waarde die is geconfigureerd op de Callbridge API (wanneer deze wordt doorgegeven)

Geen bewering geslaagd/gematcht bij validatie

Soms, tijdens de uitwisseling van de SAMLRresponse van de IdP, geeft de Webbridge deze fout weer die aangeeft dat er een fout is opgetreden bij het matchen van de bewering en slaat alle beweringen over die niet overeenkomen met de serverconfiguratie:

client_backend: FOUT: SamlManager: Geen beweringen doorgegeven voor de validatie
client_backend: INFO: SamManager: assertie overslaan zonder ons in het toegestane publiek

Wat deze fout aangeeft, is dat bij het bekijken van de SAMLR-reactie van de IdP, de Webbridge geen overeenkomende beweringen heeft gevonden en dus niet-overeenkomende fouten heeft overgeslagen en uiteindelijk heeft geresulteerd in een mislukte SSO-aanmelding. 

Om dit probleem op te sporen, is het ideaal om de SAMLR-reactie van de IdP te bekijken. Als de communicatie niet is gecodeerd met behulp van de teken- en coderingsprivésleutels, kan de SAML-respons via een webbrowser worden geëxtraheerd uit de netwerklogboekregistratie voor ontwikkelaarstools en worden gedecodeerd met behulp van base64. Als het antwoord versleuteld is, kunt u de gedecodeerde SAML-reactie van de IdP-kant aanvragen. 

Bij het bekijken van de SAMLRresponse-gegevens, kijkend naar de <AudienceRestriction> sectie van de reactie, kunt u alle doelgroepen vinden waarvoor deze reactie is beperkt voor:

<Voorwaarden NotBefore=2021-03-30T19:35:37.071Z NotOnOrAfter=2021-03-30T19:36:37.071Z>
<AudienceRestriction>
<Audience>https://cisco.example.com</Audience>
</AudienceRestriction>
</Voorwaarden>

Met behulp van de waarde in de sectie <Audience> (https://cisco.example.com) kunt u deze vergelijken met het ssoServiceProviderAddress in de configuratie config.json van de Webbridge en valideren of deze exact overeenkomt. In dit voorbeeld kunt u zien dat de reden voor de fout is dat de Audience NIET overeenkomt met het adres van de Serviceprovider in de configuratie, omdat deze de toevoeging :443 heeft:

ssoServiceProviderAddress: https://cisco.example.com:443

Dit vereist een exacte match tussen deze om niet te resulteren in een mislukking als deze. In dit voorbeeld is de oplossing voor een van deze twee methoden:

1. De :443 kan worden verwijderd van het adres in het gedeelte ssoServiceProviderAddress van config.json, zodat deze overeenkomt met het veld Publiek in het SAMLR-antwoord van de IdP.
OF

2. De metagegevens OF vertrouwenspersoon voor Webbridge3 in de IdP kunnen worden bijgewerkt zodat de :443 aan de URL wordt toegevoegd. (Als de metagegevens worden bijgewerkt, moet deze opnieuw worden geïmporteerd als een vertrouwenspersoon op de ADFS. Als u de vertrouwenspersoon echter rechtstreeks vanuit de IdP-wizard wijzigt, hoeft deze niet opnieuw te worden geïmporteerd.)

Let ook op de voorwaarde NotBefore en NotONOrAfter: <Voorwaarden NotBefore=2021-03-30T19:35:37.071Z NotOnOrAfter=2021-03-30T19:36:37.071Z>

Als de servertijd onjuist is, kan dit ertoe leiden dat de tijd buiten de in de voorwaarden gedefinieerde geldigheidsperiode valt. U wilt de NTP-servers controleren via de CLI-opdrachten met behulp van de ntp-serverlijst om de geconfigureerde NTP-servers en de ntp-status te controleren om de status van de geconfigureerde NTP-servers te controleren. Gebruik de opdrachtregeldatum om de servertijd te controleren. 

Tip: Als u een lokale/interne NTP-server gebruikt, probeert u een openbare NTP-server zoals time.google.com te configureren (zorg ervoor dat u een openbare DNS-server configureert voordat u begint). 

Inloggen mislukt in Web App:

Inloggen mislukt

Scenario 1:

ADFS niet bereikbaar.  Wanneer de client probeert in te loggen (met behulp van https://<joinurl>?trace=true), controleert webbridge of het gebruikte domein overeenkomt met een domein in het bestand config.json en stuurt vervolgens de SAML-informatie naar de client, waarbij de client wordt verteld waar verbinding mee moet worden gemaakt voor verificatie.  De client probeert verbinding te maken met de IdP die zich in de SAML-token bevindt.  In het voorbeeld toont de browser deze pagina omdat deze de ADFS-server niet kan bereiken.

Fout in clientbrowser

CMS Webbridge traces (terwijl ?trace=true wordt gebruikt)

19 mrt 10:47:07.927 user.info cmscb3-1 client_backend: INFO: SamlManager: [63cdc9ed-ab52-455c-8bb2-9e925cb9e16b] Overeengekomen met SSO_2024.zip in SAML Token Request

19 mrt 10:47:07.927 user.info cmscb3-1 client_backend: INFO: SamlManager: [63cdc9ed-ab52-455c-8bb2-9e925cb9e16b] Op zoek naar SSO in SAML Token Request

19 mrt 10:47:07.930 user.info cmscb3-1 client_backend: INFO: SamlManager: [63cdc9ed-ab52-455c-8bb2-9e925cb9e16b] Succesvol gegenereerd SAML-token

Scenario 2:

Gebruiker heeft geprobeerd in te loggen met een domein dat niet in het SSO-zip-bestand op de webbridge-aanmeldingspagina staat.  Client verzendt een tokenRequest met een payload van de gebruikersnaam die de gebruiker heeft ingevoerd.  Webbridge stopt de inlogpoging onmiddellijk.

CMS Webbridge traces (terwijl ?trace=true wordt gebruikt)

18 mrt 14:54:52.698 user.err cmscb3-1 client_backend: FOUT: SamlManager: Ongeldige SSO-aanmeldingspoging

18 mrt 14:54:52.698 user.info cmscb3-1 client_backend: INFO: SamlManager: [3f93fd14-f4c9-4e5e-94d5-49bf6433319e] Er is geen SSO gevonden in SAML Token Request

18 mrt 14:54:52.698 user.info cmscb3-1 client_backend: INFO: SamlManager: [3f93fd14-f4c9-4e5e-94d5-49bf6433319e] SSO zoeken in SAML Token Request

Scenario 3:

De gebruiker heeft de juiste gebruikersnaam ingevoerd en wordt op de aanmeldingspagina voor eenmalige aanmelding weergegeven.  De gebruiker voert hier ook de juiste gebruikersnaam en het juiste wachtwoord in, maar krijgt nog steeds Log in Mislukt

CMS Webbridge traces (terwijl ?trace=true wordt gebruikt)

19 mrt 16:39:17.714 user.info cmscb3-1 client_backend: INFO: SamlManager: [ef8fe67f-685c-4a81-9240-f76239379806] Overeengekomen met SSO_2024.zip in SAML Token Request

19 mrt 16:39:17.714 user.info cmscb3-1 client_backend: INFO: SamlManager: [ef8fe67f-685c-4a81-9240-f76239379806] Zoektocht naar SSO in SAML IDP Response

19 maart 16:39:17.720 user.err cmscb3-1 client_backend: FOUT: SAMLmanager: Geen toegewezen element authenticatieId gevonden in ondertekende SAML-beweringen

19 mrt 16:39:17.720 user.info cmscb3-1 client_backend: INFO: SamlManager: [ef8fe67f-685c-4a81-9240-f76239379806] Geen verificatie-ID verkregen

De reden voor scenario 3 was dat de claimregel in de IdP een claimtype gebruikte dat niet overeenkwam met de authenticationIdMapping in het bestand config.json dat werd gebruikt in het SSO zip-bestand dat naar webbridge werd geüpload.  Webbridge kijkt naar de SAML-respons en verwacht dat de attribuutnaam overeenkomt met wat is geconfigureerd in de config.json.

Claimregel in ADFS

Config.json voorbeeld

Gebruikersnaam wordt niet herkend

Scenario 1:

Gebruiker ingelogd met verkeerde gebruikersnaam (domein komt overeen met wat er in het SSO-zip-bestand staat dat naar webbridge3 is geüpload, maar gebruiker bestaat niet)

Gebruikersnaam wordt niet herkend

CMS Webbridge traces (terwijl ?trace=true wordt gebruikt)

18 mrt 14:58:47.777 user.info cmscb3-1 client_backend: INFO: SamlManager: [79e9a87e-0fa4-44df-a914-bbcabb6c87c6] Overeengekomen met SSO_2024.zip in SAML Token Request

18 mrt 14:58:47.777 user.info cmscb3-1 client_backend: INFO: SamlManager: [79e9a87e-0fa4-44df-a914-bbcabb6c87c6] Op zoek naar SSO in SAML Token Request

18 mrt 14:58:47.780 user.info cmscb3-1 client_backend: INFO: SamlManager: [79e9a87e-0fa4-44df-a914-bbcabb6c87c6] Succesvol gegenereerd SAML-token

18 mrt 14:58:48.072 user.info cmscb3-1 client_backend: INFO: SamlManager: [79e9a87e-0fa4-44df-a914-bbcabb6c87c6] Overeengekomen met SSO_2024.zip in SAML Token Request

18 mrt 14:58:48.072 user.info cmscb3-1 client_backend: INFO: SamlManager: [79e9a87e-0fa4-44df-a914-bbcabb6c87c6] Op zoek naar SSO in SAML IDP Response

18 mrt 14:58:48.077 user.info cmscb3-1 client_backend: INFO: SamlManager: [79e9a87e-0fa4-44df-a914-bbcabb6c87c6] Succesvol verkregen verificatie-ID: darmckin@brhuff.com

18 mrt 14:58:48.078 user.info cmscb3-1 host: server: INFO: WB3CMgr: [79e9a87e-0fa4-44df-a914-bbcabb6c87c6] AuthRequestReceived for connection id=64004556-faea-479f-aabe-691e17783aa5 Registratie=40A4026C-0272-42A1-B125-136FDF5612A5 (Gebruiker=steve@brhuff.com)

18 mrt 14:58:48.092 user.info cmscb3-1 host: server: INFO: geen gebruiker gevonden voor autorisatie

18 mrt 14:58:48.092 user.info cmscb3-1 host: server: INFO: niet succesvol inlogverzoek van steve@brhuff.com

Scenario 2:

De gebruiker heeft de juiste aanmeldingsgegevens ingevoerd in de web-app en heeft ook de juiste referenties ingevoerd om zich te authenticeren bij LDAP op zijn SSO-pagina, maar kan zich niet aanmelden, omdat de gebruikersnaam niet wordt herkend. 

Gebruikersnaam wordt niet herkend

CMS Webbridge traces (terwijl ?trace=true wordt gebruikt)

18 mrt 15:08:52.114 user.info cmscb3-1 client_backend: INFO: SamlManager: [d626bbaf-80c3-4286-8284-fac6f71eb140] Overeengekomen SSO_2024.zip in SAML Token Request

18 mrt 15:08:52.114 user.info cmscb3-1 client_backend: INFO: SamlManager: [d626bbaf-80c3-4286-8284-fac6f71eb140] Zoektocht naar SSO in SAML Token Request

18 mrt 15:08:52.117 user.info cmscb3-1 client_backend: INFO: SamlManager: [d626bbaf-80c3-4286-8284-fac6f71eb140] Succesvol gegenereerd SAML-token

18 mrt 15:08:52.386 user.info cmscb3-1 client_backend: INFO: SamlManager: [d626bbaf-80c3-4286-8284-fac6f71eb140] Overeengekomen SSO_2024.zip in SAML Token Request

18 mrt 15:08:52.386 user.info cmscb3-1 client_backend: INFO: SamlManager: [d626bbaf-80c3-4286-8284-fac6f71eb140] Zoektocht naar SSO in SAML IDP Response

18 maart 15:08:52.391 user.info cmscb3-1 client_backend: INFO: SamlManager: [d626bbaf-80c3-4286-8284-fac6f71eb140] Authenticatie-ID: darmckin@brhuff.com is verkregen

18 mrt 15:08:52.391 user.info cmscb3-1 host: server: INFO: WB3CMgr: [d626bbaf-80c3-4286-8284-fac6f71eb140] AuthRequestReceived for connection id=64004556-faea-479f-aabe-691e17783aa5 Registratie=40A4026C-0272-42A1-B125-136FDF5612A5 (Gebruiker=darmckin@brhuff.com)

Mar 18 15:08:52.399 user.warning cmscb3-1 host: server: WAARSCHUWING: afwijzen van inlogpoging van gebruiker 'darmckin@brhuff.com' -- authenticatieId incorrect

18 mrt 15:08:52.412 user.info cmscb3-1 host: server: INFO: niet succesvol inlogverzoek van darmckin@brhuff.com

AuthenticationIdMapping in CMS-toewijzing komt niet overeen met het geconfigureerde LDAP-kenmerk dat wordt gebruikt voor de claimregel in ADFS. De regel "Succesvol verkregen authenticatie-ID:darmckin@brhuff.com" zegt dat ADFS claimregel heeft geconfigureerd met attribuut dat darmckin@brhuff.com uit de actieve directory haalt, maar de AuthenticationID in CMS API > Gebruikers laat zien dat het darckin verwacht.  In de CMS ldapMappings is de AuthenticationID geconfigureerd als $sAMAaccountName$, maar de claimregel in ADFS is geconfigureerd om de E-mailadressen te verzenden, dus dit komt niet overeen. 

Hoe dit op te lossen:

Doe een van beide opties om het volgende te beperken:

1. Wijzig de verificatie-ID in de CMS-toewijzing zodat deze overeenkomt met wat wordt gebruikt in de regel Claim op ADFS en voer een nieuwe synchronisatie uit
2. Wijzig het LDAP-kenmerk dat wordt gebruikt in de regel ADFS Claim om overeen te komen met wat is geconfigureerd in CMS-toewijzing

API LDAPMapping

Voorbeeld van API-gebruiker

Claimregel van ADFS

Webbridge-log met werklog in voorbeeld.  Voorbeeld gegenereerd met ?trace=true in de join-URL:

18 mrt 14:24:01.096 user.info cmscb3-1 client_backend: INFO: SamlManager: [7979f13c-d490-4f8b-899c-0c82853369ba] Overeengekomen met SSO_2024.zip in SAML Token Request

18 mrt 14:24:01.096 user.info cmscb3-1 client_backend: INFO: SamlManager: [7979f13c-d490-4f8b-899c-0c82853369ba] Op zoek naar SSO in SAML IDP Response

18 maart 14:24:01.101 user.info cmscb3-1 client_backend: INFO: SamlManager: [7979f13c-d490-4f8b-899c-0c82853369ba] Authenticatie-ID: darmckin@brhuff.com is verkregen

18 mrt 14:24:01.102 user.info cmscb3-1 host: server: INFO: WB3CMgr: [7979f13c-d490-4f8b-899c-0c82853369ba] AuthRequestReceived for connection id=64004556-faea-479f-aabe-691e17783aa5 Registratie=40A4026C-0272-42A1-B125-136FDF5612A5 (Gebruiker=darmckin@brhuff.com)

18 mrt 14:24:01.130 user.info cmscb3-1 host: server: INFO: succesvol aanmeldingsverzoek van darmckin@brhuff.com

18 mrt 14:24:01.130 user.info cmscb3-1 host: server: INFO: WB3CMgr: [7979f13c-d490-4f8b-899c-0c82853369ba] issuing JWT ID e2a860ef-f4ef-4391-b5d5-9abdfa89ba0f

18 mrt 14:24:01.132 user.info cmscb3-1 host: server: INFO: WB3CMgr: [7979f13c-d490-4f8b-899c-0c82853369ba] verzenden van auth response (jwt length=1064, Verbinding=64004556-FAEA-479F-AABE-691E17783AA5)

18 mrt 14:24:01.133 local7.info cmscb3-1 56496041063b wb3_frontend: [Auth:darmckin@brhuff.com, Tracing:7979f13c-d490-4f8b-899c-0c82853369ba] 10.10.10.8 - [18/Mar/2024:18:24:01 +0000] status 200 "POST /api/auth/sso/idpResponse HTTP/1.1" bytes_sent 0 http_referer "https://adfs.brhuff.com/" http_user_agent "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (HTML, zoals Gecko) Chrome/122.0.0. Safari/537.36" naar upstream 192.0.2.2:9000: upstream_response_time 0.038 request_time 0.039 msec 1710786241.133 upstream_response_length 24 200

Veelgestelde vragen (FAQ)

In deze sectie worden veelgestelde vragen of onderwerpen met betrekking tot WebApp SSO op de Cisco Meeting Server gemarkeerd.

Kan de Webapp SSO JWT worden uitgebreid?

De JSON Web Token (JWT) is het token dat door de Callbridge wordt verstrekt aan een met succes geverifieerde Webapp-client (met succes geverifieerd aan de IdP), waardoor ze toegang krijgen tot de WebApp-services. Binnen de JWT is een vervaltijd waarde die aangeeft hoe lang de JWT geldig is, die zodra de JWT vervaltijd is bereikt - de WebApp gebruiker wordt omgeleid terug naar de Webbridge login in pagina, die opnieuw moet worden geverifieerd om toegang terug te krijgen. 

De JWT-vervaldatum is configureerbaar met behulp van de 'callbridge wc3jwt expiry <1-24>' (Toegevoegd in 3.8 en hoger - meer details zijn te vinden in de CMS 3.8 Release notes of CMS MMP Guide) waarin de numerieke waarde is voor het aantal uren dat u de vervaltijd voor de JWT wilt instellen die aan WebApp-clients wordt geleverd. Zoals te zien is in de opdracht, kan de maximale waarde echter worden ingesteld op 24 uur, wat betekent dat de langste tijd dat de JWT geldig kan blijven en WebApp-gebruiker kan worden ingelogd 24 uur is. Wanneer de JWT verloopt, wordt de tijd gehaald - de browser dumpt de verlopen token en de WebApp-gebruiker wordt gedwongen terug te keren naar de WebApp-aanmeldingspagina. 

In sommige omgevingen kan, afhankelijk van de IdP- en omgevingsinstellingen, een Persistent SSO / Keep me-ingelogde functies worden geïmplementeerd op de IdP - die de browser een persistent gekookt product van de IdP zou bieden, waarbij zelfs het sluiten van de browser de cookie zou worden bewaard (tenzij gewist op andere manieren). Ongeacht de SSO / IdP-configuratie - wanneer de JWT verloopt (max 24 uur), wordt de WebApp-gebruiker gedwongen terug te gaan naar de WebApp-aanmeldingspagina - maar in dit scenario waarbij Persistente SSO is ingeschakeld op de IdP - zou de gebruiker gewoon zijn <user@domain> op de WebApp-aanmeldingspagina moeten invoeren en niet opnieuw hoeven te verifiëren om hun IdP.

Een uitbreiding staat open voor het implementeren van een Refresh-tokenmechanisme om uitgebreide autorisatie mogelijk te maken voor WebApp - Cisco bug ID CSCwm28758.

Moet ik me opnieuw verifiëren bij WebApp als ik mijn browser sluit?

De flow voor dit scenario zou zijn:

1. Een gebruiker meldt zich aan bij de WebApp (met behulp van de SSO-verificatiemethode).
2. De gebruiker sluit de browser op een gegeven moment.
3. De gebruiker opent de browser opnieuw en navigeert naar de WebApp-site. (onmiddellijk of op een later tijdstip).

Wat zou er in dit scenario gebeuren?

Voor dit antwoord hangt het af! Het hangt volledig af van de vraag of de JWT die door Callbridge is verstrekt, is verlopen op het moment van toegang tot de WebApp-pagina. Zolang de JWT nog steeds geldig en aanwezig is in de opslag, kunt u navigeren naar de WebApp-pagina (zelfs als u de browser hebt gesloten). Houd er rekening mee dat de maximale tijdsduur dat de JWT geldig kan zijn 24 uur is. 

• Als de JWT nog steeds GELDIG (NIET VERLOPEN) en AANWEZIG is, kan de gebruiker naar de WebApp-pagina navigeren met hun spaties enzovoort zonder opnieuw te hoeven verifiëren.
• Als de JWT ONGELDIG is (VERLOPEN), wordt de gebruiker doorgestuurd naar de WebApp-aanmeldingspagina en moet hij zich opnieuw aanmelden bij de WebApp. De gebruiker kan ook opnieuw moeten verifiëren aan zijn IdP, afhankelijk van zijn IdP-verificatiemethode (bijvoorbeeld als de IdP SSO of Persistent SSO gebruikt).

Hoe worden meerdere domeinen ondersteund in WebApp SSO?

WebApp SSO kan omgevingen ondersteunen die meerdere domeinen hebben en zelfs omgevingen waar die verschillende domeinen wijzen op verschillende Identity Providers (IdP's).  Raadpleeg de implementatiehandleidingen voor de Cisco Meeting Server of neem contact op met Cisco TAC voor ondersteuning bij het gebruik van meerdere domeinen.

Gerelateerde informatie

• Cisco Technical Support en downloads