LDAPS configuration fails "Test authentication"
by Jason Axley
I followed some documentation like https://developer.jboss.org/wiki/LDAPSecurityRealmExamples for configuring JBOSS to use LDAP over SSL to Active Directory but can’t seem to get Keycloak to honor the trust settings in the configured keystore.
2016-02-17 21:33:49,670 ERROR [org.keycloak.services.managers.LDAPConnectionTestManager] (default task-2) Error when authenticating to LDAP: simple bind failed: server.example.com:636: javax.naming.CommunicationException: simple bind failed: server.example.com:636 [Root exception is javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: 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)
This is the configuration I’m using for the standalone server:
<security-realm name="LdapSSLRealm">
<authentication>
<truststore path="keycloak.jks" relative-to="jboss.server.config.dir" keystore-password=“password" />
</authentication>
</security-realm>
</security-realms>
<outbound-connections>
<ldap name=“AD" url="ldaps://server.example.com:636" security-realm="LdapSSLRealm" />
</outbound-connections>
I have all of the certs in the chain imported into the keystore:
keytool -list -keystore ../configuration/keycloak.jks
Enter keystore password:
Keystore type: JKS
Keystore provider: SUN
Your keystore contains 5 entries
cert1, Feb 17, 2016, trustedCertEntry,
Certificate fingerprint (SHA1): D5:BA:F5:07:21:7D:71:AA:F6:9B:53:41:C1:05:0C:48:A9:3F:57:CE
rootcert2, Feb 17, 2016, trustedCertEntry,
Certificate fingerprint (SHA1): 86:70:AB:0A:96:58:4D:73:C0:D5:13:A8:4D:B3:1D:EC:08:D7:7B:1A
mykey, Feb 12, 2016, trustedCertEntry,
Certificate fingerprint (SHA1): 20:8C:D9:BD:B7:75:12:53:F8:68:04:82:48:5C:D7:70:F5:6C:28:15
rootcert, Feb 17, 2016, trustedCertEntry,
Certificate fingerprint (SHA1): 36:28:1E:74:E0:A9:6E:0F:53:99:75:DA:62:20:24:D4:F6:34:CD:BD
intermediateu, Feb 17, 2016, trustedCertEntry,
Certificate fingerprint (SHA1): E9:66:EE:CF:79:6A:C1:D0:13:18:59:9C:B4:29:08:54:DF:91:27:2D
Is there a way to find out if Keycloak/jboss is picking up this truststore config? Seems that it’s not. Any other ideas?
-Jason
8 years, 3 months
authenticator.principal is null after successful authentication
by Gregor Jarisch
Hi there,
we are currently setting up keycloak (1.8.1.Final) with an application containing an embedded jetty (9.2.10.v20150310).
Following the guidelines in the documentation, we have managed to make the authentication redirect process work.
However when the request is redirected back to our jetty (with an successful authentication), the variable "principal" of org.keycloak.adapters.jetty.core.JettyRequestAuthenticator in line 274 of org.keycloak.adapters.jetty.core.AbstractKeycloakJettyAuthenticator is null.
We are not fully understanding the mechanism behind it, thus have difficulties understanding what we are doing wrong here. Following is our jetty embedded code. We assume that the problem must be within those lines.
Any help, insight or tip is highly appreciated!
Thank you,
Gregor
...
final HandlerList handlers = new HandlerList();
KeycloakJettyAuthenticator keycloakAuthenticator = new KeycloakJettyAuthenticator();
AdapterConfig keycloakAdapterConfig = new AdapterConfig();
keycloakAdapterConfig.setRealm("realm");
keycloakAdapterConfig.setRealmKey("realmKEY");
keycloakAdapterConfig.setAuthServerUrl("http://localhost:8080/auth");
keycloakAdapterConfig.setSslRequired("none");
keycloakAdapterConfig.setResource("client");
keycloakAdapterConfig.setPublicClient(true);
keycloakAdapterConfig.setTokenStore("cookie");
keycloakAuthenticator.setAdapterConfig(keycloakAdapterConfig);
ConstraintSecurityHandler security = new ConstraintSecurityHandler();
server.setHandler(security);
Constraint constraint = new Constraint();
constraint.setName("auth");
constraint.setAuthenticate(true);
constraint.setRoles(new String[] { "user", "admin" });
ConstraintMapping mapping = new ConstraintMapping();
mapping.setPathSpec("/*");
mapping.setConstraint(constraint);
security.setConstraintMappings(Collections.singletonList(mapping));
security.setAuthenticator(keycloakAuthenticator);
handlers.addHandler(security);
ServletContextHandler servletHandler = new ServletContextHandler(security, "/*", ServletContextHandler.NO_SESSIONS);
handlers.addHandler(servletHandler);
server.setHandler(handlers);
...
8 years, 3 months
custom protocol mappers
by Jeremy Simon
Hi All,
What is the best way to go about writing a custom protocol mapper? I
hadn't seen any documentation for it.
Basically I was thinking about grabbing some multivalued attribute on
the userdetails object and mushing it into a CSV string for a SAML
attribute.
jeremy
jeremy(a)jeremysimon.com
www.JeremySimon.com
8 years, 3 months
SAML attribute mapping debugging
by Jason Axley
I’ve set up incoming SAML authentication using Microsoft ADFS as the IdP. However, the attribute mappings I’ve configured are not picking up the data. A couple things are not clear:
1. How can one debug the mappings to find out why they did not find the data?
2. Where is the “user model” documented to know which fields are available to map to? I pulled out some things from existing LDAP mappings but would be nice to know what else is there to map (e.g. AD or other LDAP Groups)
For example, I’ve set up an email mapper that is configured:
Mapper Type: Attribute Importer
Attribute Name: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress
Friendly Name: emailaddress
User Attribute Name: email
Doesn’t work…
-Jason
8 years, 3 months
ZipException: Unsupported compression method
by Juraci Paixão Kröhling
We are seeing this exception "from time to time" on the logs.
Unfortunately, I don't have much information about it, as I couldn't
reproduce it consistently (yet), but perhaps someone has also seen this
before? We are using KC 1.8.0.CR1.
http://fpaste.org/314926/45382345/
ERROR [stderr] (default task-62) java.util.zip.ZipException: Unsupported
compression method
ERROR [stderr] (default task-62) at
java.util.zip.GZIPInputStream.readHeader(GZIPInputStream.java:169)
ERROR [stderr] (default task-62) at
java.util.zip.GZIPInputStream.<init>(GZIPInputStream.java:79)
ERROR [stderr] (default task-62) at
java.util.zip.GZIPInputStream.<init>(GZIPInputStream.java:91)
ERROR [stderr] (default task-62) at
org.keycloak.common.util.Base64.decode(Base64.java:1274)
ERROR [stderr] (default task-62) at
org.keycloak.common.util.Base64.decode(Base64.java:1224)
ERROR [stderr] (default task-62) at
org.keycloak.common.util.Base64Url.decode(Base64Url.java:35)
ERROR [stderr] (default task-62) at
org.keycloak.jose.jws.JWSInput.<init>(JWSInput.java:35)
ERROR [stderr] (default task-62) at
org.keycloak.RSATokenVerifier.toAccessToken(RSATokenVerifier.java:52)
ERROR [stderr] (default task-62) at
org.keycloak.RSATokenVerifier.verifyToken(RSATokenVerifier.java:22)
ERROR [stderr] (default task-62) at
org.keycloak.RSATokenVerifier.verifyToken(RSATokenVerifier.java:18)
- Juca.
8 years, 3 months
Securely setting admin passwords
by Aikeaguinea
It seems the add-user.sh script for changing the admin password only
accepts the password as a -p command-line parameter. This would expose
the password in the command history, so I'd prefer not to use the
command in its current form.
Is there another way to do this?
The situation is even more complicated with Docker, since running the
script to change the Wildfly admin password requires restarting the
server, which shuts down the container. If you have an autoscaling
group, the container that gets brought up is not the container where you
changed the password, but instead the original container. This seems to
mean that the only way to have Keycloak run in Dockers in an autoscaling
group is to bake the admin passwords into the Docker image beforehand.
This isn't ideal; less so if the only way to add those passwords during
build time is to run the shell script that exposes the password on the
command line.
--
http://www.fastmail.com - Access your email from home and the web
8 years, 3 months
Re: [keycloak-user] Using Keycloak in AWS EC2. What are people using? / Infinispan not working on HA environment withdockers.
by Aikeaguinea
I just got JGroups/Infinispan with JDBC_PING working from inside a
Docker cluster in ECS on EC2. I use JDBC_PING rather than S3_PING, since
I need a database anyway and didn't want to have to set up an S3 bucket
just for this one purpose. Nicolás, if you're on AWS the default UDP
transport for JGroups doesn't work because multicast isn't supported
inside EC2, which may be your problem.
Here are the configurations you'd need:
1. The JGroups module has to reference to the db module. So in jgroups-
module.xml I have:
<dependencies> <module name="javax.api"/> <module
name="org.postgresql.jdbc"/> </dependencies>
2.The standalone-ha.xml has a JGroups subsystem (with TCP and JDBC_PING)
that looks like the configuration below; I read certain variables from
the environment, but may use the Wildfly vault tool for some of them.
The external_addr property configurations are only needed if you're
inside a Docker container, since Wildfly has to read the address of
the EC2 instance hosting the container to register itself with
JGroups. For the initialize_sql you can generally use the default, but
for Postgres I needed a custom DDL because I needed the BYTEA data
type which isn't in the default DDL.
<subsystem xmlns="urn:jboss:domain:jgroups:4.0"> <channels
default="ee"> <channel name="ee" stack="tcp"/>
</channels>
<stacks default="tcp"> <stack name="tcp">
<transport type="TCP" socket-binding="jgroups-tcp">
<property name="external_addr">${env.EXTERNAL_HOST_IP}</property>
</transport>
<protocol type="JDBC_PING"> <property
name="connection_driver">org.postgresql.Driver</property>
<property name="connection_url">jdbc:postgresql://${env.POSTGRES_TCP_AD-
DR}:${env.POSTGRES_TCP_PORT}/${env.POSTGRES_DATABASE}</property>
<property name="connection_username">${env.POSTGRES_USER}</property>
<property name="connection_password">${env.POSTGRES_PASSWORD}</property>
<property name="initialize_sql"> CREATE TABLE
IF NOT EXISTS jgroupsping ( own_addr
VARCHAR(200) NOT NULL, cluster_name
VARCHAR(200) NOT NULL, ping_data BYTEA
DEFAULT NULL, PRIMARY KEY (own_addr,
cluster_name) )
</property> </protocol>
<protocol type="MERGE3"/> <protocol type="FD_SOCK"
socket-binding="jgroups-tcp-fd"> <property
name="external_addr">${env.EXTERNAL_HOST_IP}</property>
</protocol>
<protocol type="FD"/> <protocol
type="VERIFY_SUSPECT"/> <protocol
type="pbcast.NAKACK2"/> <protocol type="UNICAST3"/>
<protocol type="pbcast.STABLE"/> <protocol
type="pbcast.GMS"/> <protocol type="MFC"/>
<protocol type="FRAG2"/> </stack> </stacks>
</subsystem>
3. If you're in a Docker container, you have to expose the JGroups ports
so they are visible from outside the container, so in standalone-
ha.xml in the socket bindings I have changed to the public interface:
<socket-binding name="jgroups-tcp" interface="public" port="7600"/>
<socket-binding name="jgroups-tcp-fd" interface="public" port="57600"/>
4. For Docker, the startup script needs to pass the EXTERNAL_HOST_IP
variable. I have a wrapper start script that first queries the AWS
instance metadata service for the host's private IP address:
export EXTERNAL_HOST_IP=$(curl -s 169.254.169.254/latest/meta-data/local-
ipv4) exec $WILDFLY_HOME/bin/standalone.sh -c standalone-keycloak-
ha.xml -Djboss.node.name=$HOSTNAME -Djgroups.bind_addr=global -b
$HOSTNAME
------------------------------------------------------------------------
--------------------------------------------------------------------
From: <keycloak-user-bounces(a)lists.jboss.org> Date: Wednesday, February
17, 2016 at 9:03 AM To: "keycloak-user(a)lists.jboss.org" <keycloak-
user(a)lists.jboss.org> Subject: [keycloak-user] Infinispan not working on
HA environment with dockers.
Hello all, I'm trying to set a Keycloak HA environment up with dockers.
I tried with jboss/keycloak-ha-postgres:1.8.0.Final image.
I can't make infinispan work when I run 2 instances of my docker images.
I get the following log in every node:
Received new cluster view for channel ejb: [f9032dc82244|0] (1)
[f9032dc82244] Received new cluster view for channel hibernate:
[f9032dc82244|0] (1) [f9032dc82244] Received new cluster view for
channel keycloak: [f9032dc82244|0] (1) [f9032dc82244] Received new
cluster view for channel web: [f9032dc82244|0] (1) [f9032dc82244]
Channel hibernate local address is f9032dc82244, physical addresses are
[127.0.0.1:55200] Channel keycloak local address is f9032dc82244,
physical addresses are [127.0.0.1:55200] Channel ejb local address is
f9032dc82244, physical addresses are [127.0.0.1:55200] Channel web local
address is f9032dc82244, physical addresses are [127.0.0.1:55200]
Received new cluster view for channel server: [f9032dc82244|0] (1)
[f9032dc82244] Channel server local address is f9032dc82244, physical
addresses are [127.0.0.1:55200]
This is causing my user sessions are not shared between instances and
it's not working properly.
When I run 2 instances of keycloak without dockers, they work properly.
Am I missing something? Is there any extra configuration that I need
to change?
Thanks, Nicolas.-
--
http://www.fastmail.com - A fast, anti-spam email service.
8 years, 3 months
Update The Client: Inconsistent behaviour by deleting of attributes via REST admin command in 1.9.0.RC1
by Juraj Janosik
Hi,
I created a JIRA issue for this problem..
For detailed description please check
https://issues.jboss.org/browse/KEYCLOAK-2503
*Basic description:*
I want to delete 2 (custom) attributes defined via client representation in
body parameter "attributes" via REST admin command "Update the client" (PUT
method).
1.) customAttr_1 via not defining in JSON's request body
2.) customAttr_2 via setting with value empty string ""
Execution of Update The Client REST request performs successfully with
status code 204 No Content.
Next I want to check the client representation via GET method.
The response returns customAttr_1 and does not return customAttr_2.
But If I want to re-create the deleted customAttr_2 (via UPDATE the
client), I receive HTTP status code 409 Conflict.
Conclusion:
1.) customAttr_1 not deleted
2.) customAttr_2 not present in GET response, but still present in DB in
table CLIENT_ATTRIBUTES with value Null.
Best Regards,
Juraj
8 years, 3 months
Frequent LDAP bind failed socket connection reset exceptions in Keycloak LDAP user federation
by Edgar Vonk - Info.nl
hi,
We are getting frequent LDAP simple bind failed, socket exceptions, when communicating with our Active Directory server using the Keycloak user federation provider. The might very well be a problem on the AD side of things or perhaps in our network, but I was wondering if it might be something in Keycloak? We have not been able to narrow it down so far.
It happens quite often for example when manually synching users from AD to Keycloak but also for example when creating a new user from Keycloak to AD. When you try any such action again it always succeeds. It seems some sort of hiccup.
09:08:23,080 ERROR [org.keycloak.services] LDAP Query failed
org.keycloak.models.ModelException: LDAP Query failed
at org.keycloak.federation.ldap.idm.query.internal.LDAPQuery.getResultList(LDAPQuery.java:168)
at org.keycloak.federation.ldap.idm.query.internal.LDAPQuery.getFirstResult(LDAPQuery.java:175)
at org.keycloak.federation.ldap.LDAPFederationProvider.loadLDAPUserByUsername(LDAPFederationProvider.java:504)
[..]
Caused by: org.keycloak.models.ModelException: Querying of LDAP failed org.keycloak.federation.ldap.idm.query.internal.LDAPQuery@12228106
at org.keycloak.federation.ldap.idm.store.ldap.LDAPIdentityStore.fetchQueryResults(LDAPIdentityStore.java:169)
at org.keycloak.federation.ldap.idm.query.internal.LDAPQuery.getResultList(LDAPQuery.java:164)
... 54 more
Caused by: javax.naming.CommunicationException: simple bind failed: ldap.hf.info.nl:636 [Root exception is java.net.SocketException: Connection reset]
at com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:219)
at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2788)
at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:319)
at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:192)
at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:210)
at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:153)
at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:83)
at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
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.federation.ldap.idm.store.ldap.LDAPOperationManager.createLdapContext(LDAPOperationManager.java:473)
at org.keycloak.federation.ldap.idm.store.ldap.LDAPOperationManager.execute(LDAPOperationManager.java:541)
at org.keycloak.federation.ldap.idm.store.ldap.LDAPOperationManager.search(LDAPOperationManager.java:166)
at org.keycloak.federation.ldap.idm.store.ldap.LDAPIdentityStore.fetchQueryResults(LDAPIdentityStore.java:160)
... 55 more
Caused by: java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(SocketInputStream.java:209)
at java.net.SocketInputStream.read(SocketInputStream.java:141)
at sun.security.ssl.InputRecord.readFully(InputRecord.java:465)
at sun.security.ssl.InputRecord.read(InputRecord.java:503)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:973)
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1375)
at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:747)
at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:123)
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:426)
at com.sun.jndi.ldap.Connection.writeRequest(Connection.java:399)
at com.sun.jndi.ldap.LdapClient.ldapBind(LdapClient.java:359)
at com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:214)
... 69 more
8 years, 3 months
