Konfigurieren: Benutzerverbund für die Authentifizierung
Erfahren Sie, wie Sie die Benutzerauthentifizierung über föderiertes Identitätsmanagement einrichten.
Konfigurieren: Benutzerverbund für die Authentifizierung
Erfahren Sie, wie Sie die Benutzerauthentifizierung über föderiertes Identitätsmanagement einrichten.
Wie konfiguriere ich die Benutzerföderation für die Authentifizierung?
In diesem Artikel werden Anweisungen zum Konfigurieren der Benutzerföderation zur Verwendung als Authentifizierungsprotokoll beschrieben.
Benutzerföderation bedeutet, dass sich Benutzer bei Efecte-Lösungen, die auf der Efecte Service Management-Plattform aufbauen, authentifizieren können, indem sie dieselben Anmeldeinformationen (Benutzername und Kennwort) wie im Kundenverzeichnis verwenden.
Schritt-für-Schritt-Anleitung
1. Die Pro für die Authentifizierung muss in der Efecte Service Management-Plattform konfiguriert werden, bevor Efecte Secure Access Komponente konfiguriert wird
2. Melden Sie sich bei Efecte Secure Access Admin-Konsole an
3. Überprüfen Sie, ob die Konfiguration korrekt in Efecte Secure Access Komponente gespeichert ist
- Die Validierung kann unter https://{TENANT_NAME.com}/auth/ erfolgen und das Konto main.admin (und das entsprechende Kennwort, das aus der Mandantenkonfiguration gelesen wurde) verwenden.
4. Wenn Sie „Benutzerföderation“ auswählen, sollte eine Liste mit Authentifizierungsaufgaben angezeigt werden (wenn die Liste leer ist, warten Sie eine Minute, um die Daten von Efecte Service Management an Efecte Secure Access zu übertragen; wenn die Liste immer noch leer ist).

5. Wenn Sie in der jeweiligen Aufgabe „Bearbeiten“ auswählen, werden Details zur LDAPS-Verbindung angezeigt. Es lohnt sich zu überprüfen, ob alle Einstellungen hier korrekt sind, insbesondere:
- Benutzer importieren: EIN
- Bearbeitungsmodus: NUR AD
6. Nach dem Speichern der Verbindung wird in der rechten oberen Ecke ein Aktionsmenü angezeigt, mit dem der Administrator alle Benutzer von LDAP mit Efecte Secure Access synchronisieren kann

7. Überprüfen Sie, ob der AD vorhanden ist. Wählen Sie in der oberen Leiste der Benutzerföderation „Mapper“ aus. Unter den Standardtypen sollte hier ein (oder mehrere) Gruppen-LDAP-Mapper-Typen sichtbar sein.
- Wenn kein AD _GroupMapper automatisch erstellt wird, kann der Benutzer durch Klicken auf die blaue Schaltfläche „Mapper hinzufügen“ einen eigenen erstellen.

Beispiel für AD Gruppen-Mapper


8. Nachdem die Konfiguration überprüft wurde, kann der Administrator versuchen, alle Benutzer zu synchronisieren (siehe vorherige Bildschirme). Dies sollte eine ähnliche Meldung wie folgt anzeigen:


10. Die Konfiguration sollte nun abgeschlossen sein und es ist möglich, die Authentifizierung zu testen Löschen
Fehlerbehebung
1. Wenn die Protokolle Efecte Secure Access Probleme im Zusammenhang mit der SSL-Verbindung anzeigen, wie zum Beispiel:
Caused by: org. keycloak .models.ModelException: Querying of LDAP failed org. keycloak .storage.ldap.idm.query.internal.LDAPQuery@292d8e81 at org. keycloak .storage.ldap.idm.store.ldap.LD API dentityStore.fetchQueryResults(LD API dentityStore.java:289) at org. keycloak .storage.ldap.idm.query.internal.LDAPQuery.getResultList(LDAPQuery.java:174) ... 80 more Caused by: javax.naming.CommunicationException: simple bind failed: 10.0.2.110:636 [Root exception is javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to valid certification path to requested target] konnte nicht find ] at com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:219) at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2897) at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:347) at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxFromUrl(LdapCtxFactory.java:225) at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:189) at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:243)
at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:154)
at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:84)
at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:116)
at org.jboss.as.naming.InitialContext.init(InitialContext.java:101)
at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:91)
at org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:43)
at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:695)
at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
at javax.naming.InitialContext.init(InitialContext.java:244)
at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
at org.keycloak.storage.ldap.idm.store.ldap.LDAPContextManager.createLdapContext(LDAPContextManager.java:80)
at org.keycloak.storage.ldap.idm.store.ldap.LDAPContextManager.getLdapContext(LDAPContextManager.java:100)
at org.keycloak.storage.ldap.idm.query.internal.LDAPQuery.initPagination(LDAPQuery.java:213)
at org.keycloak.storage.ldap.idm.store.ldap.LDAPOperationManager.searchPaginated(LDAPOperationManager.java:293)
at org. keycloak .storage.ldap.idm.store.ldap.LD API dentityStore.fetchQueryResults(LD API dentityStore.java:277) ... 81 more Caused by: javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to valid certification path to requested target konnte nicht find at sun.security.ssl.Alert.createSSLException(Alert.java:131) at sun.security.ssl.TransportContext.fatal(TransportContext.java:324) at sun.security.ssl.TransportContext.fatal(TransportContext.java:267) at sun.security.ssl.TransportContext.fatal(TransportContext.java:262) at sun.security.ssl.CertificateMessage$T12CertificateConsumer.checkServerCerts(CertificateMessage.java:654) at sun.security.ssl.CertificateMessage$T12CertificateConsumer.onCertificate(CertificateMessage.java:473) at sun.security.ssl.CertificateMessage$T12CertificateConsumer.consume(CertificateMessage.java:369) at sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:377) at sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:444) at sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:422) at sun.security.ssl.TransportContext.dispatch(TransportContext.java:182) at sun.security.ssl.SSLTransport.decode(SSLTransport.java:152)
at sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1383) at sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1291) at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:435) at sun.security.ssl.SSLSocketImpl.ensureNegotiated(SSLSocketImpl.java:804) at sun.security.ssl.SSLSocketImpl.access$200(SSLSocketImpl.java:73) at sun.security.ssl.SSLSocketImpl$AppOutputStream.write(SSLSocketImpl.java:1166) at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82) at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140) at com.sun.jndi.ldap.Connection.writeRequest(Connection.java:448) at com.sun.jndi.ldap.Connection.writeRequest(Connection.java:421) at com.sun.jndi.ldap.LdapClient.ldapBind(LdapClient.java:359) at com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:214) ... 102 more Caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to valid certification path to requested target konnte nicht find at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:456)
at sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:323) at sun.security.validator.Validator.validate(Validator.java:271) at sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:315) at sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:223) at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:129) at sun.security.ssl.CertificateMessage$T12CertificateConsumer.checkServerCerts(CertificateMessage.java:638) ... 121 more Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to valid certification path to requested target find at sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:141) at sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:126) at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:280) at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:451) ... 127 more
|
2. Wenn SSL verwendet wird, um ESA mit Active Directory zu verbinden, muss ESA das von AD bereitgestellte Zertifikat kennen. Dies ist ein manueller Schritt und erfordert:
- Melden Sie sich beim ESA Container an
- Gehen Sie in /opt/esa (stellen Sie sicher, dass dort eine Datei truststore.jks vorhanden ist)
- In Testumgebungen können Sie den folgenden Befehl ausführen (wenn Sie keine Zertifikatsdatei haben):
- echo -n | openssl s_client -connect IP_OF_ AD _SERVER:636 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > NAME_DER_DATEI_FÜR_BEISPIEL_IP_OF_ AD _SERVER.crt
- In Produktionsumgebungen wird jedoch empfohlen, Stamm- oder Zwischenzertifikate vom Kunden zu erhalten , da diese normalerweise länger gültig sind als Zertifikate auf Serverebene.
- Ein Beispiel könnte sein:
- echo -n | openssl s_client -connect 10.0.2.110:636 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > 10.0.2.110.crt
3. Nachdem Sie die Zertifikatsdatei haben, muss sie in die Datei truststore.jks importiert werden
- keytool -importcert -file NAME_DER_ZERTIFIKAT-DATEI.crt -keystore truststore.jks -alias "ALIAS_DAS_ZERTIFIKATS"
- Beispiel: keytool -importcert -file AD _certificate.crt -keystore truststore.jks -alias AD _certificate