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.
In diesem Dokument wird die Konfiguration des OpenAM Identity Providers (IdP) zur Aktivierung von Single Sign On (SSO) beschrieben.
Cisco IDs-Bereitstellungsmodelle
Produkt | Bereitstellung |
UCCX | Mitansässig |
PCCE | Co-Resident mit CUIC (Cisco Unified Intelligence Center) und LD (Live-Daten) |
UCCE | Gleichzeitige Implementierung mit CUIC und LD für 2k-Bereitstellungen Standalone für Bereitstellungen der Serien 4000 und 12000. |
Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:
Anmerkung: Dieses Dokument bezieht sich auf die Konfiguration in Bezug auf den Cisco Identitätsdienst (IdS) und den Identitätsanbieter (IdP). Das Dokument verweist in den Screenshots und Beispielen auf UCCX. Die Konfiguration ist jedoch in Bezug auf den Cisco Identitätsdienst (UCCX/UCCE/PCCE) und den IdP ähnlich.
Dieses Dokument ist nicht auf bestimmte Software- und Hardware-Versionen beschränkt.
Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.
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. Es unterstützt Security Assertion Markup Language (SAML2). IdS ist ein SAML2-Client und soll Shibboleth mit minimalen oder keinen Änderungen an IdS unterstützen. In 11.6 ist IdS qualifiziert, mit Shibboleth IdP zu arbeiten.
Anmerkung: Dieses Dokument bezieht sich im Rahmen der Qualifizierung mit SSO auf Shibboleth Release 3.3.0
Komponente | Details |
Shibboleth-Version | v3.3.0 |
Speicherort herunterladen | http://shibboleth.net/downloads/identity-provider/ |
Plattform installieren | Ubuntu 14.0.4 Java-Version "1.8.0_121" |
Version des Lightweight Directory Access Protocol (LDAP) | Active Directory 2.0 |
Shibboleth Webserver | Apache Tomcat/8.5.12 |
Bitte lesen Sie das Wiki für die 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, wobei$shibboleth_home (Standard ist /opt/shibboleth-idp) auf das Installationsverzeichnis verweist, das bei der Installation von shibboleth verwendet wird.
Feld | Erwarteter Wert | Beschreibung |
idp.authn.LDAP.trustZertifikate | Eine Ressource zum Laden von Vertrauensankern, normalerweise eine lokale Datei in ${idp.home}/dentials wobei idp.home eine Umgebungsvariable ist, die als JAVA_OPTS in setenv.sh exportiert wird |
%{idp.home}/credentials/ldap-server.crt |
idp.authn.LDAP.trustStore | Eine Ressource zum Laden eines Java-Schlüsselspeichers, der Vertrauensanker enthält, in der Regel eine lokale Datei in %{idp.home}/dentials. | %{idp.home}/credentials/ldap-server.truststore |
idp.authn.LDAP.returnAttributes | Die kommagetrennte Liste der LDAPAttribute, die zurückgegeben werden müssen. Wenn Sie alle Attribute zurückgeben möchten, fügen Sie "*" hinzu. |
* |
idp.authn.LDAP.baseDN | Die Basis-DN, unter der die LDAP-Suche durchgeführt werden muss. | CN=users,DC=cisco,DC=com |
idp.authn.LDAP.subtreeSearch | Ob rekursiv gesucht 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 | Kennwort für die Bindung bei der Suche | |
idp.authn.LDAP.dnFormat | Eine Formatierungszeichenfolge zum Generieren der zu authentifizierenden Benutzer-DNs | %s@adfsserver.cisco.com (%s@domainname) |
idp.authn.LDAP.Authenticator | Steuert den Workflow für die Authentifizierung gegenüber dem 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 Sie certificateTrust oben verwenden, legen Sie den Pfad des vertrauenswürdigen Zertifikats fest.
idp.authn.LDAP.trustCertificates = %{idp.home}/credentials/ldap-server.crt
## Wenn Sie keyStoreTrust oben verwenden, legen Sie den Pfad für den Vertrauensspeicher fest.
idp.authn.LDAP.trustStore = %{idp.home}/credentials/ldap-server.truststore
## Attribute bei Authentifizierung zurückgeben
#idp.authn.LDAP.returnAttributes = userPrincipalName, sAMAccountName;
idp.authn.LDAP.returnAttributes = *
## Eigenschaften der DN-Auflösung ##
# Suche DN Auflösung, benutzt von anonSearchAuthenticator, bindSearchAuthenticator
Nr. 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 Bindungssuche
Nr. für AD: idp.authn.LDAP.bindDN=Administrator @domain .com
idp.authn.LDAP.bindDN = Administrator @cisco .com
idp.authn.LDAP.bindDNCredential = Cisco @123
# Format DN Auflösung, verwendet von directAuthenticator, adAuthenticator
Nr. für AD: idp.authn.LDAP.dnFormat=%s @domain .com
#idp.authn.LDAP.dnFormat = %s @adfsserver .cisco.com
# LDAP-Attributkonfiguration, siehe attribute-resolver.xml
# Hinweis, diese gilt wahrscheinlich nicht für die Verwendung älterer V2-Resolver-Konfigurationen
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.principale);
|
Um sicherzustellen, dass Anfragen von allen Clients eintreffen, müssen Änderungen in "$shibboleth_home/conf/access-control.xml" vorgenommen werden.
<entry key="AccessByIPAddress">
<bean 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 Anfragen aus jedem IP-Bereich.
Um IdS standardmäßig auf SHA1 zu konfigurieren, öffnen Sie "$shibboleth_home/conf/idp.properties", und legen Sie Folgendes fest:
idp.signing.config = shibboleth.SigningConfiguration.SHA1;
Diese Konfiguration kann auch geändert werden:
idp.encryption.optional = true
Wenn Sie den Wert auf true festlegen, führt das Nichtfinden eines zu verwendenden Verschlüsselungsschlüssels, wenn er aktiviert ist, nicht zu einem Anforderungsfehler. Diese hhilft bei der "opportunistischen" Verschlüsselung, d. h. Verschlüsselung wann immer möglich (ein kompatibler Schlüssel befindet sich in den Metadaten des Peers, mit dem verschlüsselt werden kann), aber andernfalls die Verschlüsselung zu überspringen.
Die AttributeDefinition wird in "$shibboleth_home/conf/attribute-resolver.xml" hinzugefügt, um sAMAccountName und userPrincipalName der uid und user_principal in der SAML-Antwort zuzuordnen.
Fügen Sie außerdem die LDAP-Connector-Einstellungen mit dem Tag <DataConnector> hinzu.
Hinweis: ReturnAttributes muss mit dem Wert "sAMAccountName userPrincipalName" angegeben werden.
Hinweis: LDAPProperty ist obligatorisch, wenn eine Integration mit einem Active Directory (AD) erfolgt.
%{idp.attribute.resolver.LDAP.searchFilter}
sAMAccountName userPrincipalName
Änderungen in "$shibboleth_home/conf/attribute-filter.xml" übernehmen
IdP-Metadaten sind im Ordner "$shibboleth_home/metadaten" verfügbar. Die Datei idp-metadaten.xml kann über die API (Application Programming Interface) in IdS hochgeladen werden.
PUT https://<idshost>:<idsport>/ids/v1/config/idpmetadaten
wobei "idsport" keine konfigurierbare Einheit ist und der Wert "8553" ist.
Warnung: Shibboleth-Metadaten können 2 Signaturzertifikate, das allgemeine Signaturzertifikat und den Rückkanal enthalten. Navigieren Sie zur Datei idp-backchannel.crt in "$shibboleth_home/dentials", um das Backchannel-Zertifikat zu identifizieren. Wenn das Backchannel-Zertifikat in den Metadaten verfügbar ist, sollten Sie das Backchannel-Zertifikat aus der Metadaten-XML entfernen, bevor Sie es in 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.
Wir müssen die Metadaten-Anbieter mit dem Eintrag in $shibboleth_home/metadata-providers.xml konfigurieren.
<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 mit der angegebenen ID registriert ist und die Metadaten in der angegebenen Datei /opt/shibboleth-idp/SP/sp.xml verfügbar sind.
Die Service Provider (SP)-Metadaten von IdS müssen in die im Eintrag angegebene metadatenFile kopiert werden.
Hinweis: SP-Metadaten von IdS können über GET https://<idshost>:<idsport>/ids/v1/config/spmetadaten abgerufen werden, wobei idsport keine konfigurierbare Entität ist und der Wert "8553" ist.
In diesem Dokument wird die IdP-Konfiguration für SSO zur Integration in den Cisco Identity Service beschrieben. Weitere Informationen finden Sie in den jeweiligen Produktkonfigurationsanleitungen:
Überarbeitung | Veröffentlichungsdatum | Kommentare |
---|---|---|
1.0 |
17-Aug-2017
|
Erstveröffentlichung |