Määritä: Käyttäjäliitto todennusta varten
Opi määrittämään käyttäjätodennus federoidun identiteetinhallinnan avulla.
Määritä: Käyttäjäliitto todennusta varten
Opi määrittämään käyttäjätodennus federoidun identiteetinhallinnan avulla.
Kuinka käyttäjäliitto määritetään todennusta varten?
Tässä artikkelissa kuvataan ohjeet käyttäjäliiton määrittämiseen todennusprotokollana.
Käyttäjäliitos tarkoittaa, että käyttäjät voivat todentaa itsensä Efecten ratkaisuihin, jotka on rakennettu Efecte Service Management -alustan päälle, käyttämällä samoja tunnuksia (käyttäjätunnus ja salasana) kuin asiakashakemistossa.
Huomio!
Kun uusi ESA versio otetaan käyttöön, synkronointi otetaan automaattisesti uudelleen käyttöön, joten ESA :n mukautetut liittimet poistetaan.
Synkronoinnin voi poistaa käytöstä:
- # vim /opt/esa/epe_synch.configsynchronize_user_federations=false
- synchronize_identity_providers=false
Kun yllä oleva muutos tehdään tiedostoon "/opt/esa/epe_synch.config", synkronointi poistetaan aina käytöstä.
Vaiheittaiset ohjeet
1. Todennuksen Pro on määritettävä Efecte Service Management -alustalla ennen Efecte Secure Access -komponentin määrittämistä.
2. Kirjaudu Efecte Secure Access hallintakonsoliin
3. Varmista, että kokoonpano on tallennettu oikein Efecte Secure Access -komponenttiin
- Vahvistus voidaan tehdä osoitteessa: https://{TENANT_NAME.com}/auth/ ja käyttää tiliä main.admin (ja asianmukaista salasanaa, joka on luettu vuokralaisen määrityksistä).
4. Valitsemalla Käyttäjäliitto pitäisi näkyviin tulla luettelo todennustehtävistä (jos luettelo on tyhjä, odota minuutti, jotta tiedot siirtyvät Efecte Service Managementista Efecte Secure Access ; jos luettelo on edelleen tyhjä).
5. Kun valitset Muokkaa kyseisestä tehtävästä, näkyviin tulevat LDAPS-yhteyden tiedot. Kannattaa tarkistaa, ovatko kaikki asetukset oikein, erityisesti:
- Tuo käyttäjiä: PÄÄLLÄ
- Muokkaustila: VAIN MAINOSTEN AD
6. Yhteyden tallentamisen jälkeen oikeaan yläkulmaan ilmestyy toimintovalikko, jonka avulla järjestelmänvalvoja voi synkronoida kaikki LDAP-käyttäjät Efecte Secure Access
7. Tarkista, onko AD _GroupMapper käytössä. Valitse käyttäjäliiton yläpalkista Mappers. Oletusarvoisten joukosta yhden (tai useamman) group-ldap-mapper-tyypin pitäisi näkyä tässä.
- Jos AD _GroupMapper -elementtiä ei ole luotu automaattisesti, käyttäjä voi luoda oman elementin napsauttamalla sinistä Lisää kartoittaja -painiketta.
Esimerkki AD -ryhmän kartoittimesta
8. Kun määritykset on tarkistettu, ylläpitäjä voi yrittää synkronoida kaikki käyttäjät (mainittu yhdessä edellisistä näytöistä). Tämän pitäisi tuoda esiin samankaltainen viesti kuin
10. Konfiguroinnin pitäisi nyt olla valmis ja todennusta voi testata Poistaa
Vianmääritys
1. Jos Efecte Secure Access lokit näyttävät SSL-yhteyteen liittyviä ongelmia, kuten esimerkiksi:
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] ei 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 ei 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 ei 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 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. Jos SSL-salausta käytetään ESA yhdistämiseen Active Directory , ESA on oltava tietoinen AD esittämästä varmenteesta. Tämä on manuaalinen vaihe, joka edellyttää:
- Kirjaudu ESA konttiin
- Mene hakemistoon /opt/esa (varmista, että siellä on truststore.jks-tiedosto)
- Testiympäristöissä voit antaa seuraavan komennon (jos sinulla ei ole varmennetiedostoa):
- echo -n | openssl s_client -connect IP_OF_ AD _SERVER:636 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > ESIMERKIN_TIEDOSTON_IP_OF_ AD _SERVER.crt
- Tuotantoympäristöissä on kuitenkin suositeltavaa hankkia pää- tai välitason varmenne asiakkaalta , sillä ne ovat yleensä voimassa pidempään kuin palvelintason varmenteet.
- Esimerkki voisi olla:
- echo -n | openssl s_client -connect 10.0.2.110:636 | sed -ne '/-VARMENNUKSEN ALOITUS-/,/-VARMENNUKSEN LOPPU-/p' > 10.0.2.110.crt
3. Kun sinulla on varmennetiedosto, se on tuotava truststore.jks-tiedostoon.
- keytool -importcert -file SERTIFIKAATIN_TIEDOSTON NIMI.crt -keystore truststore.jks -alias "VARMENNUKSEN_ALIAS"
- Esimerkiksi: keytool -importcert -file AD _certificate.crt -keystore truststore.jks -alias AD _certificate