In dem Dokumentationssatz für dieses Produkt wird die Verwendung inklusiver Sprache angestrebt. Für die Zwecke dieses Dokumentationssatzes wird Sprache als „inklusiv“ verstanden, wenn sie keine Diskriminierung aufgrund von Alter, körperlicher und/oder geistiger Behinderung, Geschlechtszugehörigkeit und -identität, ethnischer Identität, sexueller Orientierung, sozioökonomischem Status und Intersektionalität impliziert. Dennoch können in der Dokumentation stilistische Abweichungen von diesem Bemühen auftreten, wenn Text verwendet wird, der in Benutzeroberflächen der Produktsoftware fest codiert ist, auf RFP-Dokumentation basiert oder von einem genannten Drittanbieterprodukt verwendet wird. Hier erfahren Sie mehr darüber, wie Cisco inklusive Sprache verwendet.
Cisco hat dieses Dokument maschinell übersetzen und von einem menschlichen Übersetzer editieren und korrigieren lassen, um unseren Benutzern auf der ganzen Welt Support-Inhalte in ihrer eigenen Sprache zu bieten. Bitte beachten Sie, dass selbst die beste maschinelle Übersetzung nicht so genau ist wie eine von einem professionellen Übersetzer angefertigte. Cisco Systems, Inc. übernimmt keine Haftung für die Richtigkeit dieser Übersetzungen und empfiehlt, immer das englische Originaldokument (siehe bereitgestellter Link) heranzuziehen.
Dieses Dokument beschreibt die Konfiguration des OpenAM Identity Providers (IDP) zur Aktivierung der Single Sign On (SSO).
Cisco IDS-Bereitstellungsmodelle
Produkt | Bereitstellung |
UCCX | Co-Resident |
PCCE | Co-Resident mit CUIC (Cisco Unified Intelligence Center) und LD (Live-Daten) |
UCCE | Resident gemeinsam mit CUIC und LD für 2.000 Bereitstellungen. Standalone für 4.000- und 12.000-Bereitstellungen. |
Cisco empfiehlt, über Kenntnisse in folgenden Bereichen zu verfügen:
Hinweis: Dieses Dokument bezieht sich auf die Konfiguration des Cisco Identify Service (IDs) und des Identitätsanbieters (IdP). Das Dokument verweist in den Screenshots und Beispielen auf UCCX, die Konfiguration ähnelt jedoch dem Cisco Identitify Service (UCCX/UCCE/PCCE) und der IdP.
Dieses Dokument ist nicht auf bestimmte Software- und Hardwareversionen beschränkt.
Die Informationen in diesem Dokument wurden von den Geräten in einer bestimmten Laborumgebung erstellt. Alle in diesem Dokument verwendeten Geräte haben mit einer leeren (Standard-)Konfiguration begonnen. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die potenziellen Auswirkungen eines Befehls verstehen.
Shibboleth ist ein Open-Source-Projekt, das Single Sign-On-Funktionen bietet und es Websites ermöglicht, fundierte Autorisierungsentscheidungen für den individuellen Zugriff auf geschützte Online-Ressourcen unter Wahrung der Privatsphäre zu treffen. Sie unterstützt Security Assertion Markup Language (SAML2). IdS ist ein SAML2-Client und soll Shibboleth mit minimalen oder gar keinen Änderungen an IDs unterstützen. In 11.6 ist IdS für die Arbeit mit Shibboleth IdP qualifiziert.
Hinweis: Dieses Dokument bezieht sich auf Shibboleth Release 3.3.0 als Teil der Qualifizierung mit SSO
Komponente | Details |
Shibboleth-Version | Version 3.3.0 |
Download-Speicherort | http://shibboleth.net/downloads/identity-provider/ |
Installationsplattform | Ubuntu 14.0.4 Java-Version "1.8.0_121" |
LDAP-Version (Lightweight Directory Access Protocol) | Active Directory 2.0 |
Shibboleth-Webserver | Apache Tomcat/8.5.12 |
Im Wiki finden Sie Informationen zur Installation von Shibboleth.
https://wiki.shibboleth.net/confluence/display/IDP30/Installation
Um einen LDAP-Server mit Shibboleth zu integrieren, müssen die Felder in $shibboleth_home /conf/ldap.properties aktualisiert werden, wo$shibboleth_home (Standardwert: /opt/shibboleth-idp) auf das Installationsverzeichnis verweist, das bei der Installation von Shibboleth verwendet wird.
Feld | Erwarteter Wert | Beschreibung |
idp.authn.LDAP.trustCertificates | Eine Ressource zum Laden von vertrauenswürdigen Ankern aus einer lokalen Datei in ${idp.home}/Anmeldeinformationen. wobei idp.home eine Umgebungsvariable ist, die in setenv.sh als JAVA_OPTS exportiert wird. |
%{idp.home}/credentials/ldap-server.crt |
idp.authn.LDAP.trustStore | Eine Ressource zum Laden eines Java-Keystres mit Vertrauenshinweisen, in der Regel eine lokale Datei in %{idp.home}/Anmeldeinformationen. | %{idp.home}/credentials/ldap-server.truststore |
idp.authn.LDAP.returnAttributes | Die kommagetrennte Liste von LDAPAttributen, die zurückgegeben werden müssen. Wenn Sie alle Attribute zurückgeben möchten, fügen Sie "*" hinzu. |
* |
idp.authn.LDAP.baseDN | Der baseDN, bei dem die LDAP-Suche ausgeführt werden muss | CN=Benutzer, DC=cisco,DC=com |
idp.authn.LDAP.subtreeSuche | Gibt an, ob eine rekursive Suche durchgeführt werden soll. | wahr |
idp.authn.LDAP.userFilter | LDAP-Suchfilter | (sAMAccountName={user})* |
idp.authn.LDAP.bindDN | DN für die Anbindung bei der Suche | administrator@cisco.com |
idp.authn.LDAP.bindDNCredential | Passwort, mit dem bei der Suche verknüpft werden soll | |
idp.authn.LDAP.dnFormat | Eine Formatierungszeichenfolge zum Generieren der Benutzer-DNs zum Authentifizieren | %s@adfsserver.cisco.com (%s@domainname) |
idp.authn.LDAP.authentifier | Steuert den Workflow für die Art der Authentifizierung mit LDAP | bindSearchAuthenticator |
idp.authn.LDAP.ldapURL | Verbindungs-URI für LDAP-Verzeichnis |
Weitere Informationen finden Sie unter:
https://wiki.shibboleth.net/confluence/display/IDP30/LDAPAuthnConfiguration
# Wartezeit in Millisekunden für Antworten
#idp.authn.LDAP.responseTimeout = PT3S
## SSL-Konfiguration, entweder jvmTrust, certificateTrust oder keyStoreTrust
#idp.authn.LDAP.sslConfig = certificateTrust
## Wenn certificateTrust oben verwendet wird, legen Sie den Pfad des vertrauenswürdigen Zertifikats fest
idp.authn.LDAP.trustCertificates = %{idp.home}/credentials/ldap-server.crt
## Wenn keyStoreTrust oben verwendet wird, legen Sie den Pfad für den Truststore fest
idp.authn.LDAP.trustStore = %{idp.home}/credentials/ldap-server.truststore
## Rückgabeattribute für Authentifizierung
#idp.authn.LDAP.returnAttributes = userPrincipalName, sAMAccountName
idp.authn.LDAP.returnAttributes = *
## DN-Auflösungseigenschaften ##
# DN-Auflösung durchsuchen, verwendet von anonSearchAuthenticator, bindSearchAuthenticator
# für AD: CN=Benutzer,DC=Beispiel,DC=org
idp.authn.LDAP.baseDN = CN=Users,DC=cisco,DC=com
idp.authn.LDAP.subtreeSearch = < wahr
*idp.authn.LDAP.userFilter = (sAMAccountName={user})*
# Konfiguration der binden-Suche
# für AD: idp.authn.LDAP.bindDN=adminuser @domäne .com
idp.authn.LDAP.bindDN = administrator @cisco .com
idp.authn.LDAP.bindDNCredential = Cisco @123
# Format-DN-Auflösung, verwendet von directAuthenticator, adAuthenticator
# für AD verwenden idp.authn.LDAP.dnFormat=%s @domäne .com
#idp.authn.LDAP.dnFormat = %s @adfsserver .cisco.com
# LDAP-Attributkonfiguration, siehe attribute resolver.xml
# Hinweis, diese wird wahrscheinlich nicht auf die Verwendung von älteren V2-Resolver-Konfigurationen angewendet
idp.attribute.resolver.LDAP.ldapURL = %{idp.authn.LDAP.ldapURL}
idp.attribute.resolver.LDAP.connectTimeout = %{idp.authn.LDAP.connectTimeout:PT3S}
idp.attribute.resolver.LDAP.responseTimeout = %{idp.authn.LDAP.responseTimeout:PT3S}
idp.attribute.resolver.LDAP.baseDN = %{idp.authn.LDAP.baseDN:undefined}
idp.attribute.resolver.LDAP.bindDN = %{idp.authn.LDAP.bindDN:undefined}
idp.attribute.resolver.LDAP.bindDNCredential = %{idp.authn.LDAP.bindDNCredential:undefined}
idp.attribute.resolver.LDAP.useStartTLS = %{idp.authn.LDAP.useStartTLS: wahr }
idp.attribute.resolver.LDAP.trustCertificates = %{idp.authn.LDAP.trustCertificates:undefined}
idp.attribute.resolver.LDAP.searchFilter = (sAMAccountName=$resolutionContext.Principal)
|
Um sicherzustellen, dass Anfragen aller Kunden eingehen, sind Änderungen in "$shibboleth_home/conf/access-control.xml" erforderlich.
<entry key="AccessByIPAddress">
<bohne id="AccessByIPAddress" parent="shibboleth.IPRangeAccessControl"
p:allowedRanges="#{'127.0.0.1/32','0.0.0.0/0', '::1/128', '10.78.93.103/32'} }" />
</entry>
Fügen Sie '0.0.0.0/0' zu den zulässigen Bereichen hinzu. Dies ermöglicht Anforderungen aus einem beliebigen IP-Bereich.
Um die Standardeinstellung für IDs auf SHA1 festzulegen, öffnen Sie "$shibboleth_home/conf/idp.properties" und legen Sie Folgendes fest:
idp.sign.config = shibboleth.SigningConfiguration.SHA1;
Diese Konfiguration kann auch geändert werden:
idp.encryption.optional = true
Wenn Sie den Wert auf true festlegen, wird bei aktiviertem Fehler bei der Suche nach einem zu verwendenden Verschlüsselungsschlüssel keine Anforderung ausfallen. Dies hunterstützt die Verschlüsselung "opportunistisch", d. h., wenn möglich zu verschlüsseln (ein kompatibler Schlüssel ist in den Metadaten des Peers zu verschlüsseln mit), aber die Verschlüsselung andernfalls zu überspringen.
Die AttributeDefinition wird in "$shibboleth_home/conf/attribute-resolver.xml" hinzugefügt, um in der SAML-Antwort sAMAccountName und userPrincipalName der Datei zu uid und user_principal zuzuordnen.
Fügen Sie darüber hinaus die LDAP-Connector-Einstellungen mit dem Tag <DataConnector> hinzu.
Hinweis: ReturnAttributes muss mit dem Wert "sAMAccountName userPrincipalName" angegeben werden.
Hinweis: Bei Integration in ein Active Directory (AD) ist LDAPProperty zwingend erforderlich.
%{idp.attribute.resolver.LDAP.searchFilter}
sAMAccountName userPrincipalName
Nehmen Sie die Änderungen in "$shibboleth_home/conf/attribute-filter.xml" auf.
IDP-Metadaten sind im Ordner "$shibboleth_home/metadaten" verfügbar. Die Datei "idp-metadaten.xml" kann über die API (Application Programming Interface) auf IdS hochgeladen werden.
PUT https://<idshost>:<idsport>/ids/v1/config/idpmetadaten
wobei idsport keine konfigurierbare Entität ist und der Wert "8553" ist.
Warnung: Shibboleth-Metadaten können zwei Signaturzertifikate, das allgemeine Signaturzertifikat und den Backchannel enthalten. Navigieren Sie zur Datei idp-backchannel.crt in "$shibboleth_home/dentials", um das Backchannel-Zertifikat zu identifizieren. Wenn das Back-Channel-Zertifikat in den Metadaten verfügbar ist, sollten Sie das Back-Channel-Zertifikat aus den Metadaten xml entfernen, bevor Sie es an IdS hochladen. Dies liegt daran, dass die von IdS verwendete Fedlet 12.0-Bibliothek nur ein Zertifikat in den Metadaten unterstützt. Wenn mehr als ein Signaturzertifikat verfügbar ist, verwendet Fedlet das erste verfügbare Zertifikat.
Der Eintrag in $shibboleth_home/metadata-providers.xml muss für die Metadatenanbieter konfiguriert werden.
<MetadataProvider id="smart-86" xsi:type="FilesystemMetadataProvider" metadataFile="/opt/shibboleth-idp/SP/sp.xml"/>
wobei"id"-Attribut ein beliebiger eindeutiger Name sein kann.
Dieser Eintrag gibt an, dass ein Metadatenanbieter bei der angegebenen ID registriert ist und die Metadaten in der angegebenen Datei /opt/shibboleth-idp/SP/sp.xml verfügbar sind.
Service Provider (SP)-Metadaten von IdS müssen in die im Eintrag angegebene Metadatendatei kopiert werden.
Hinweis: SP-Metadaten von IdS können über GET https://<idshost>:<idsport>/ids/v1/config/spmetadaten abgerufen werden, wobei idsport keine konfigurierbare Einheit ist und der Wert "8553" lautet.
Dieses Dokument beschreibt die Konfiguration aus dem IdP-Aspekt für SSO zur Integration in den Cisco Identity Service. Weitere Informationen finden Sie in den einzelnen Produktkonfigurationsleitfäden: