Enkel pålogging og kontrollhub

Engangspålogging (SSO) er en økt- eller brukerautentiseringsprosess som gir en bruker tilgang til ett eller flere programmer. Prosessen autentiserer brukere for alle programmene de har rettigheter til. Det eliminerer ytterligere anvisninger når brukere bytter program i løpet av en bestemt økt.

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

Profiler

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

  • SP-initiert POST -> POST-binding

  • SP-initiert OMDIRIGERING -> POST-binding

NameID-format

SAML 2.0-protokollen støtter flere Navn-ID-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-en, konfigureres den første oppføringen for bruk i Webex.

Engangsutlogging

Webex App støtter den enkle avloggingsprofilen. I Webex Appkan en bruker logge av programmet, som bruker SAML-protokollen for enkel avlogging til å avslutte økten og bekrefte at logger av med din IdP. Kontroller at IdP-en din er konfigurert for engangsutlogging.

Integrer kontrollhub med Shibboleth

Konfigureringsveiledningene viser et spesifikt eksempel for SSO-integrering, men gir ikke uttømmende konfigurering for alle muligheter. For eksempel er integreringstrinnene for nameid-format urn:oasis:names:tc:SAML:2.0:nameid-format:transient dokumentert. Andre formater, som urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified or urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress fungerer i SSO-integrering, men gjennomgås ikke i vår dokumentasjon.

Konfigurer denne integreringen for brukere i Webex-organisasjonen (inkludert Webex App, Webex Meetingsog andre tjenester som administreres i Control Hub). Hvis Webex-området er integrert i Kontrollhub, arver Webex-området brukeradministrasjonen. Hvis du ikke får tilgang til Webex-møter på denne måten, og det ikke administreres i Kontrollhub, må du gjøre en egen integrasjon for å aktivere SSO for Webex-møter. (Hvis du vil ha mer informasjon om SSO-integrering, kan du se Konfigurer engangspålogging for Webex i Nettstedsadministrasjon.)

Integreringstrinnene refererer til Shibboleth 2.4.5 i CentOS 7 med Tomcat 7 som nettserver.

Før du starter

For SSO og Control Hubmå IDPer være i samsvar med SAML 2.0-spesifikasjonen. IdP-er må også konfigureres på følgende måte:

Last ned Webex-metadataene til det lokale systemet

1

Gå til Innstillinger for https://admin.webex.com administrasjon > organisasjonfra kundevisningen i, og bla deretter til Godkjenning, og aktiver deretter innstillingen For enkel pålogging for å starte installasjonsveiviseren.
2

Velg sertifikattypen for organisasjonen:

  • 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 sertifiseringsinstans– sikrere, men du må ofte oppdatere metadataene (med mindre IdP-leverandøren støtter klareringsankere).

 

Klareringsankere er fellesnøkler som fungerer som en instans for å bekrefte sertifikatet til en digital signatur. Hvis du vil ha mer informasjon, kan du se idp-dokumentasjonen.
3

Last ned metadatafilen.

Filnavnet for Webex-metadata er idb-meta-<org-ID>-SP.xml.

Konfigurere autorisasjon i Shibboleth-filer

Når 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 som skal brukes, for eksempel LDAP-binding til Active Directory.
3

Rediger handler.xml-filen på følgende måte:

Fjern kommentar

    <!--  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 inn informasjon for Active Directory for å tillate godkjenning. Angi konfigurasjonen til login.config-filen.

Eksempel:

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";
};

Konfigurere Shibboleth-tjenesteleverandørkomponenter for SAML-deklarasjon

1

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

Rediger filen for beroende part.xml etter DefaultRelyingParty -koden legger du til detaljene for SAML-deklarasjonen 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 for eksemplet med EntityID for organisasjonen.
3

Legg til plasseringen til filen i metadata:MetadataProvider-taggen:

 <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 deklarasjonsattributtene

1

Angi hvor du skal hente attributter om brukerne dine i Datatilkobling-delen.

Eksempel:

Active Directory, med en MyLDAP-ID.

<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

Behold det som allerede finnes i konfigurasjonen for transientID i Attributtdefinisjon-delen.
3

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

Eksempel:

Tilordne attributtet mail (e-postadresseattributt i Active Directory) til uid (UserID 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 oppgis til hver SP-avtale i attributtfilteret.xml-filen.

Oppgi uid -attributtet til Webex som tilordnes brukerens e-postadresse.

Eksempel:

Frigi 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 å frigi attributtet mail-attr til EntityID som samsvarer med Webex.
5

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

Importere IdP-metadataene og aktivere enkel pålogging etter en test

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

Før du starter

Ikke test SSO-integrering fra IdP-grensesnittet (identitetsleverandør). Vi støtter kun tjenesteleverandørinitierte (SP-initierte) flyter, så du må bruke Control Hub SSO-testen for denne integreringen.

1

Velg én:

  • Gå tilbake til kontrollhuben – sertifikatvalgsiden i nettleseren, og klikk deretter Neste.
  • Hvis Kontrollhub ikke lenger er åpen i nettleserfanen, går du til Innstillinger for https://admin.webex.comadministrasjon > organisasjoni kundevisning i , blar til Godkjenningog velger Handlinger > Importer metadata.
2

Dra og slipp IdP-metadatafilen til siden Importer IdP-metadata, eller bruk filbehandleren til å finne og laste opp metadatafilen. Klikk på Neste.

Du bør bruke alternativet Sikrere hvis du kan. Dette er bare mulig hvis din IdP brukte en offentlig sertifiseringsinstans til å signere metadataene.

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

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


 

Hvis du får en autentiseringsfeil, kan det være et problem med legitimasjonen. Kontroller brukernavnet og passordet ditt, og prøv på nytt.

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

 

Hvis du vil se påloggingsopplevelsen for SSO direkte, kan du også klikke Kopier URL-adresse 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 tilgangstoken som kan være i en eksisterende økt fra deg som er logget på.
4

Gå tilbake til Control Hub-nettleserfanen.

  • Hvis testen var vellykket, velger du Vellykket test. Slå på SSO , og klikk Neste.
  • Hvis testen mislyktes, velger du Mislykket 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 nå?

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