Konfigurera: Användarfederation för autentisering
Lär dig hur du konfigurerar användarautentisering via federerad identitetshantering.
Konfigurera: Användarfederation för autentisering
Lär dig hur du konfigurerar användarautentisering via federerad identitetshantering.
Hur konfigurerar man användarfederation för autentisering?
I den här artikeln beskrivs instruktioner för att konfigurera användarfederation som autentiseringsprotokoll.
Användarfederation innebär att användare kan autentisera sig mot Efectes lösningar, byggda ovanpå Efectes servicehanteringsplattform, genom att använda samma inloggningsuppgifter (användarnamn och lösenord) som i kundkatalogen.
Varsel!
När en ny ESA version distribueras aktiveras synkroniseringen automatiskt igen, så de anpassade kopplingarna i ESA tas bort.
Synkronisering kan inaktiveras:
- # vim /opt/esa/epe_synch.configsynchronize_user_federations=false
- synkronisera_identitetsleverantörer=falskt
När ändringen ovan görs i filen "/opt/esa/epe_synch.config" kommer synkroniseringen alltid att vara inaktiverad.
Steg-för-steg-instruktioner
1. Pro för autentisering måste konfigureras i Efecte Service Management-plattformen innan Efecte Secure Access komponenten konfigureras.
2. Logga in på Efecte Secure Access administratörskonsol
3. Kontrollera att konfigurationen är korrekt lagrad i Efecte Secure Access komponenten
- Validering kan göras i: https://{TENANT_NAME.com}/auth/ och använd kontot main.admin (och lämpligt lösenord som läses från hyresgästkonfigurationen).
4. Genom att välja Användarfederation bör en lista med autentiseringsuppgifter visas (om listan är tom, vänta en minut för att överföra data från Efecte Service Management till Efecte Secure Access ; om listan fortfarande är tom).
5. Om du väljer Redigera i den specifika uppgiften visas detaljer om LDAPS-anslutningen. Det är värt att kontrollera om alla inställningar är på plats här, särskilt:
- Importera användare: PÅ
- Redigeringsläge: ENDAST AD
6. Efter att anslutningen har sparats visas en åtgärdsmeny i det övre högra hörnet, vilket gör det möjligt för administratören att synkronisera alla användare från LDAP till Efecte Secure Access
7. Kontrollera om AD _GroupMapper finns på plats. Välj Mappers från den översta fältet i användarfederationen. Bland standardtyperna bör en (eller flera) group-ldap-mapper-typer synas här.
- Om ingen AD _GroupMapper skapas automatiskt kan användaren skapa en egen med ett klick på den blå knappen Lägg till mapper.
Exempel på AD gruppmappare
8. Efter att konfigurationen har granskats kan administratören försöka synkronisera alla användare (nämns i en av de föregående skärmarna). Det borde ge ett meddelande som liknar
10. Konfigurationen bör vara klar nu och det är möjligt att testa autentiseringen Radera
Felsökning
1. Om Efecte Secure Access loggarna visar problem relaterade till SSL-anslutningen, till exempel:
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 find valid certification path to requested target] 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 find valid certification path to requested target 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 find valid certification path to requested target 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 find valid certification path to requested target 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. Om SSL används för att ansluta ESA till Active Directory måste ESA vara medveten om vilket certifikat AD presenterar. Det är ett manuellt steg och kräver:
- Logga in i ESA behållaren
- Gå in i /opt/esa (se till att det finns en truststore.jks-fil)
- I testmiljöer kan du utfärda följande kommando (om du inte har en certifikatfil):
- echo -n | openssl s_client -connect IP_OF_ AD _SERVER:636 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > NAME_OF_THE_FILE_FOR_EXAMPLE_IP_OF_ AD _SERVER.crt
- Men i produktionsmiljöer rekommenderas det att få rot- eller mellanliggande certifikat från kunden , dessa är vanligtvis längre giltiga än certifikat på servernivå.
- Ett exempel kan vara:
- echo -n | openssl s_client -connect 10.0.2.110:636 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > 10.0.2.110.crt
3. När du har certifikatfilen måste den importeras till truststore.jks-filen
- keytool -importcert -file NAMN_PÅ_CERT_FIL.crt -keystore truststore.jks -alias "ALIAS_FÖR_CERTIFIKATET"
- Till exempel: keytool -importcert -file AD _certificate.crt -keystore truststore.jks -alias AD _certificate