I denne artikkelen
dropdown icon
Enkel pålogging og kontrollhub
    Profiler
    NavnID-format
    EnkeltLogg ut
Integrer Control Hub med Shibboleth
Last ned Webex-metadataene til ditt lokale system
Konfigurer autorisasjon i Shibboleth-filer
Konfigurer Shibboleth-tjenesteleverandørkomponenter for SAML-påstand
Konfigurere påstandsattributtene
Importer IdP-metadataene og aktiver enkel pålogging etter en test
Konfigurer enkel pålogging i Control Hub med Shibboleth
list-menuI denne artikkelen
list-menuTilbakemelding?

Du kan konfigurere en SSO (Single Sign-On) -integrasjon mellom Control Hub og en distribusjon som bruker Shibboleth som identitetsleverandør (IdP).

Enkel pålogging og kontrollhub

Enkel pålogging (SSO) er en økt- eller brukerautentiseringsprosess som tillater en bruker å oppgi legitimasjon for å få tilgang til ett eller flere applikasjoner. Prosessen autentiserer brukere for alle applikasjonene de får rettigheter til. Det eliminerer ytterligere meldinger når brukere bytter applikasjoner under en bestemt økt.

Security Assertion Markup Language (SAML 2.0) Federation Protocol brukes til å gi SSO-godkjenning mellom Webex-skyen og identitetsleverandøren (IdP).

Profiler

Webex-appen støtter bare nettleserens SSO-profil. I nettleserens SSO-profil støtter Webex App følgende bindinger:

  • SP initierte POST -> POST-binding

  • SP initierte REDIRECT -> POST-binding

NavnID-format

SAML 2.0-protokollen støtter flere NameID-formater for kommunikasjon om en bestemt bruker. Webex App støtter følgende NameID-formater.

  • urn:oasis:names:tc:SAML:2.0:nameid-format:transient

  • urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified

  • urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress

I metadataene du laster inn fra IdP, er den første oppføringen konfigurert for bruk i Webex.

EnkeltLogg ut

Webex-appen støtter enkelt utloggingsprofil. I Webex-appen kan en bruker logge av applikasjonen, som bruker SAML-protokollen for enkel utlogging for å avslutte økten og bekrefte at du logger ut med din IdP. Forsikre deg om at din IdP er konfigurert for SingleLogout.

Integrer Control Hub med Shibboleth

Konfigurasjonsveiledningene viser et spesifikt eksempel på SSO-integrasjon, men gir ikke uttømmende konfigurasjon for alle muligheter. For eksempel, integrasjonstrinnene for nameid-format urn:oasis:names:tc:SAML:2.0:nameid-format:transienter dokumentert. Andre formater som urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified or urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddressvil fungere for SSO-integrasjon, men er utenfor omfanget av dokumentasjonen vår.

Konfigurer denne integrasjonen for brukere i Webex-organisasjonen (inkludert Webex-appen og andre tjenester som administreres i Control Hub). Webex Meetings Hvis Webex-området ditt er integrert i Control Hub, arver Webex-området brukeradministrasjonen. Hvis du ikke får tilgang Webex Meetings på denne måten, og den ikke administreres i Control Hub, må du gjøre en egen integrasjon for å aktivere SSO forWebex Meetings.

Integrasjonstrinnene refererer til Shibboleth 2.4.5 i CentOS 7 med Tomcat 7 som webserver.

Før du begynner

For SSO og Control Hub må IDP-er være i samsvar med SAML 2.0-spesifikasjonen. I tillegg må IDP-er konfigureres på følgende måte:

Last ned Webex-metadataene til ditt lokale system

1

Logg på Control Hub.

2

Gå til Administrasjon > Sikkerhet > God kjenning.

3

Gå til fanen Identitetsleverand ør og klikk Aktiver SSO.

4

Velg en IdP.

5

Velg sertifikattype for organisasjonen din:

  • Selvsignert av Cisco —Vi anbefaler dette valget. La oss signere sertifikatet slik at du bare trenger å fornye det en gang hvert femte år.
  • Signert av en offentlig sertifikat myndighet — Sikrere, men du må oppdatere metadata ene ofte (med mindre IdP- leverandøren støtter klareringsankere).

Tillitsankere er offentlige nøkler som fungerer som en autoritet for å verifisere sertifikatet til en digital signatur. Hvis du vil ha mer informasjon, kan du se IdP-dokumentasjonen.

6

Last ned metadatafilen.

<org-ID>Webex-metadatafilnavnet er idb-meta- -SP.xml.

Konfigurer autorisasjon i Shibboleth-filer

Etter at du har installert Shibboleth, får du konfigurasjonsfiler med eksempler.

1

Gå til katalogen /opt/shibboleth- idp/conf for å få tilgang til eksempelfilene.

2

Bestem hvilken autorisasjonsmetode du vil bruke — for eksempel LDAP binde til. Active Directory

3

Rediger filen handler.xml som følger:

Avkommentere

    <!--  Username/password login handler -->
    <ph:LoginHandler xsi:type="ph:UsernamePassword"
                  jaasConfigurationLocation="file:///opt/shibboleth-idp/conf/login.config">  
  <ph:AuthenticationMethod>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
</ph:AuthenticationMethod>
    </ph:LoginHandler>

Kommentar

<ph:LoginHandler xsi:type="ph:RemoteUser"> 
<ph:AuthenticationMethod>urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified</ph:AuthenticationMethod>
    </ph:LoginHandler>
4

Fyll ut detaljene Active Directory til din for å tillate autentisering. Gi konfigurasjonen til filen login.config.

ShibUserPassAuth {
   edu.vt.middleware.ldap.jaas.LdapLoginModule required
      ldapUrl="ldap://ad0a.cisco.net:389"
      ssl="false"
      tls="false"
      baseDn="cn=Users,dc=cisco,dc=net"
      subtreeSearch="true"
      userFilter="sAMAccountName={0}"
      bindDn="cn=Administrator,cn=Users,dc=cisco,dc=net"
      bindCredential="ThePassword";
};

Konfigurer Shibboleth-tjenesteleverandørkomponenter for SAML-påstand

1

Legg til filen du lastet ned fra Webex SP i katalogen /opt/shibboleth-idp/metadata.

2

Rediger filen relying-party.xml; etter DefaultRelyingParty-taggen legger du til detaljene for SAML-påstanden for Webex.

 <rp:RelyingParty id="https://idbroker.webex.com/ea7c1420-711d-4916-95f8-
22de53230d1e"
              provider="https://shib9a.cisco.net/idp/shibboleth"
              defaultSigningCredentialRef="IdPCredential">
            <rp:ProfileConfiguration xsi:type="saml:SAML2SSOProfile"
                includeAttributeStatement="true"
                assertionLifetime="PT5M" assertionProxyCount="0"
                signResponses="never" signAssertions="always"
                encryptAssertions="conditional" encryptNameIds="never"
                includeConditionsNotBefore="true"/>
        </rp:RelyingParty>

For id må du bruke EntityID-verdien fra Webex-metadatafilen. Erstatt ID-en til eksemplet med EntityId for organisasjonen din.

3

Inne i metadata:metadataProvider-taggen legger du til plasseringen av filen:

 <metadata:MetadataProvider id="ShibbolethMetadata" xsi:type="metadata:Chaini
ngMetadataProvider">
        <metadata:MetadataProvider id="IdPMD" xsi:type="metadata:FilesystemMetad
ataProvider" metadataFile="/opt/shibboleth-idp/metadata/idp-metadata.xml" maxRefreshDelay="P1D" />
    <!--     Cisco UCXN Configuration               -->
   <metadata:MetadataProvider xsi:type="FilesystemMetadataProvider" xmlns="urn:m
ace:shibboleth:2.0:metadata" id="ucxn9a" metadataFile="/opt/shibboleth-idp/metad
ata/ucxn9a-single-agreement.xml" />
    <!--     Cisco CUCM Configuration               -->
   <metadata:MetadataProvider xsi:type="FilesystemMetadataProvider" xmlns="urn:m
ace:shibboleth:2.0:metadata" id="cucm9a" metadataFile="/opt/shibboleth-idp/metad
ata/cucm9a.cisco.net-single-agreement.xml" />
    <!--     Cisco CI Configuration               
   <metadata:MetadataProvider xsi:type="FilesystemMetadataProvider" xmlns="urn:m
ace:shibboleth:2.0:metadata" id="CI" metadataFile="/opt/shibboleth-idp/metadata/
idb-meta-ea7c1420-711d-4916-95f8-22de53230d1e-SP.xml" />
    </metadata:MetadataProvider>

SP-metadataene kommer fra en fil i Shibboleth-filsystemet, på stedet der du lastet opp metadataene for Webex-organisasjonen.

Konfigurere påstandsattributtene

1

I Data Connector-delen angir du hvor du skal hente attributter om brukerne dine.

Active Directory, med en id av myLDAP.

<resolver:DataConnector id="MyLDAP" xsi:type="dc:LDAPDirectory"
      ldapURL="ldap://ad0a.cisco.net:389"
      baseDN="cn=Users,dc=cisco,dc=net"
      principal="Administrator@cisco.net"
      principalCredential="ThePassword">
        <dc:FilterTemplate>
            <![CDATA[
                (sAMAccountName=$requestContext.principalName)
            ]]>
        </dc:FilterTemplate>
    </resolver:DataConnector>

2

I delen Attributtdefinisjon beholder du det som allerede er i konfigurasjonen for TransientID.

3

Legg til det ekstra attributtet som SP forventer, og definer hva det tilordnes i attributtkilden.

Tilordne attributtet mail (e-postadresseattributt iActive Directory) til uid (brukerID i Webex).

<resolver:AttributeDefinition id="mail-attr" xsi:type="ad:Simple" 
sourceAttributeID="mail">
        <resolver:Dependency ref="MyLDAP" />
        <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="uid" />
     </resolver:AttributeDefinition>

4

Definer hvilket attributt som skal gis til hver SP-avtale i filen attribute-filter.xml.

Oppgi uid-attributtet til Webex som tilordnes e-postadressen til brukeren.

Slipp attributtet uid til SP-avtalen med Webex.

<!--  Release the attributes to cisco CI Cloud  -->
    <afp:AttributeFilterPolicy id="ReleaseToCI">
        <afp:PolicyRequirementRule xsi:type="basic:AttributeRequesterString" 
value="https://idbroker.webex.com/ea7c1420-711d-4916-95f8-22de53230d1e" />
        <afp:AttributeRule attributeID="transientId">
            <afp:PermitValueRule xsi:type="basic:ANY"/>
        </afp:AttributeRule>
        <afp:AttributeRule attributeID="mail-attr">
            <afp:PermitValueRule xsi:type="basic:ANY" />
        </afp:AttributeRule>
    </afp:AttributeFilterPolicy>

Regelen du opprettet i attribute-resolver.xml, bør ha en policy for å frigjøre mail-attr-attributtet til EntityId som samsvarer med Webex.

5

Last ned metadatafilen fra Shibboleth-serveren i /opt/shibboleth-idp/metadata. Filnavnet er idp-metadata.xml.

Importer IdP-metadataene og aktiver enkel pålogging etter en test

Etter at du har eksportert Webex-metadataene, konfigurert IdP-en og lastet ned IdP-metadataene til det lokale systemet, er du klar til å importere det til Webex-organisasjonen din fra Control Hub.

Før du begynner

Ikke test SSO-integrasjon fra IdP-grensesnittet (Identity Provider). Vi støtter bare tjenesteleverandørinitierte (SP-initierte) flyter, så du må bruke Control Hub SSO-testen for denne integrasjonen.

1

Velg en:

  • Gå tilbake til Control Hub — sertifikatvalgsiden i nettleseren din, og klikk deretter Neste.
  • Åpne Control Hub på nytt hvis den ikke lenger er åpen i nettleserfanen. Gå til Administ rasjon > Sikker het > God kjen ning fra kundevisningen i Control Hub, velg IdP og velg deretter Hand linger > Importer metadata.
2

På siden Importer IdP-metadata kan du enten dra og slippe IdP-metadatafilen til siden eller bruke alternativet for filnettleser til å finne og laste opp metadat afilen. Klikk på Neste.

Du bør bruke alternativet Mer sikker, hvis du kan. Dette er bare mulig hvis din IdP brukte en offentlig CA til å signere metadataene sine.

I alle andre tilfeller må du bruke alternativet Mindre sikkert. Dette inkluderer hvis metadataene ikke er signert, selvsignert eller signert av en privat CA.

Okta signerer ikke metadataene, så du må velge Mindre sikker for en Okta SSO-integrasjon.

3

Velg Test SSO-oppsett, og når en ny nettleserfane åpnes, godkjenn med IdP ved å logge på.

Hvis du får en godkjenningsfeil, kan det være et problem med legitimasjonen. Sjekk brukernavnet og passordet, og prøv igjen.

En Webex App-feil betyr vanligvis et problem med SSO-oppsettet. I dette tilfellet går du gjennom trinnene igjen, spesielt trinnene der du kopierer og li mer inn Control Hub-metadataene i IdP-oppsettet.

For å se SSO-påloggingsopplevelsen direkte, kan du også klikke Kopier URL til utklippstavlen fra dette skjermbildet og lime den inn i et privat nettleservindu. Derfra kan du gå gjennom på logging med SSO. Dette trinnet stopper falske positiver på grunn av et til gangstoken som kan være i en eksisterende økt etter at du er logget på.

4

Gå tilbake til kontrollhub-nettleserfanen.

  • Hvis testen var vellykket, velger du Vell ykket test. Slå på SSO og klikk Neste.
  • Hvis testen mislyktes, velger du Mis lykket test. Slå av SSO og klikk Neste.

SSO-konfigurasjonen trer ikke i kraft i organisasjonen med mindre du velger første alternativknapp og aktiverer SSO.

Hva du skal gjøre videre

Bruk prosedyrene i Synkroniser Okta-brukere til Cisco Webex Control Hub hvis du vil gjøre brukerklargjøring ut av Okta til Webex-skyen.

Bruk prosedyrene i Synkroniser Microsoft Entra ID-brukere til Cisco Webex Control Hub hvis du vil gjøre brukerklargjøring ut av Entra ID til Webex-skyen.

Du kan følge fremgangsmåten i Undertrykk automatiserte e-post meldinger for å deaktivere e-postmeldinger som sendes til nye Webex App-brukere i organisasjonen. Dokumentet inneholder også beste fremgangsmåter for å sende ut kommunikasjon til brukere i organisasjonen.

Var denne artikkelen nyttig?
Var denne artikkelen nyttig?