Problem with Github Identity Provider
by Peter Braun
Hey everyone,
i'm having trouble with the Github Identity Provider in Keycloak 4 (using
RH-SSO 7.3) where it was working fine with Keycloak 3 (RH-SSO 7.2). Realm,
Client and Provider are configured in the same way but login fails and I
get this error in the logs:
*09:14:19,823 ERROR
[org.keycloak.broker.oidc.AbstractOAuth2IdentityProvider] (default task-71)
Failed to make identity provider oauth callback:
org.keycloak.broker.provider.IdentityBrokerException: No access token
available in OAuth server response:
{"error":"unauthorized_client","error_description":"The client is not
authorized to request a token using this method."}*
I've already checked that the credentials are correct and that the realm,
client and idp settings are similar to the Keycloak 3 instance. Any Idea
where to best start looking?
Regards,
Peter
5 years
Option to disable SPNEGO
by Ryan Slominski
With the "LDAP" User Storage Provider you can configure authentication with a Kerberos password, but disable SPENGO. The admin web interface labels this "Allow Kerberos Authentication" (seems like a bad label). However, with the "Kerberos" User Storage Provider there is no such option. Is there a reason, or can this be added?
Going a step further, the option to request SPENGO be disabled via url parameter (regardless of LDAP vs Kerberos User Storage Provider) was discussed years ago (http://lists.jboss.org/pipermail/keycloak-dev/2015-October/005399.html) with no resolution. Where are we with this? Either the parameter approach or some sort of support for "Switch User" would be appreciated because it is very tricky to accommodate with the current API. Currently I'm using a brokered identity provider which is a duplicate of the primary realm minus SPNEGO support. Then client applications are coded with a "switch user" link that uses the idp_hint parameter to indicate the special su brokered realm be used. Seems unnecessarily complex. Maybe I'm missing something easier?
5 years
keycloak database
by Andrew Meyer
So I've created the keycloak database, but when I login to the admin side and set it all up should there be any other databases/tables that get added to MariaDB/MySQL/ or PostGreSQL?
I see a blank database. Did I miss something?
5 years
LDAP null uuid Regression?
by Ryan Slominski
I'm attempting to setup Keycloak 5.0.0 with Java 11 with a LDAP User Storage Provider, and I am unable to load users into Keycloak. I'm using Red Hat Identity Manager as the LDAP server (which, I believe uses Red Hat Directory Server under the hood). The error in the log file when I navigate to the "Users" menu to try to search for a user is:
2019-03-27 11:38:54,095 ERROR [org.keycloak.services.error.KeycloakErrorHandler] (default task-15) Uncaught server error: org.keycloak.models.ModelException: User returned from LDAP has null uuid! Check configuration of your LDAP settings. UUID Attribute must be unique among your LDAP records and available on all the LDAP user records. If your LDAP server really doesn't support the notion of UUID, you can use any other attribute, which is supposed to be unique among LDAP users in tree. For example 'uid' or 'entryDN' . Mapped UUID LDAP attribute: nsuniqueid, user DN: uid=ryans,cn=users,cn=accounts,dc=acc,dc=jlab,dc=org
at org.keycloak.keycloak-ldap-federation@5.0.0//org.keycloak.storage.ldap.LDAPUtils.checkUuid(LDAPUtils.java:123)
at org.keycloak.keycloak-ldap-federation@5.0.0//org.keycloak.storage.ldap.LDAPStorageProvider.importUserFromLDAP(LDAPStorageProvider.java:498)
at org.keycloak.keycloak-ldap-federation@5.0.0//org.keycloak.storage.ldap.LDAPStorageProvider.searchForUser(LDAPStorageProvider.java:372)
at org.keycloak.keycloak-ldap-federation@5.0.0//org.keycloak.storage.ldap.LDAPStorageProvider.searchForUser(LDAPStorageProvider.java:354)
at org.keycloak.keycloak-services@5.0.0//org.keycloak.storage.UserStorageManager.lambda$searchForUser$1(UserStorageManager.java:537)
at org.keycloak.keycloak-services@5.0.0//org.keycloak.storage.UserStorageManager.query(UserStorageManager.java:505)
at org.keycloak.keycloak-services@5.0.0//org.keycloak.storage.UserStorageManager.searchForUser(UserStorageManager.java:535)
at org.keycloak.keycloak-model-infinispan@5.0.0//org.keycloak.models.cache.infinispan.UserCacheSession.searchForUser(UserCacheSession.java:573)
at org.keycloak.keycloak-services@5.0.0//org.keycloak.services.resources.admin.UsersResource.getUsers(UsersResource.java:202)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at org.jboss.resteasy.resteasy-jaxrs@3.6.2.Final//org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139)
at org.jboss.resteasy.resteasy-jaxrs@3.6.2.Final//org.jboss.resteasy.core.ResourceMethodInvoker.internalInvokeOnTarget(ResourceMethodInvoker.java:509)
at org.jboss.resteasy.resteasy-jaxrs@3.6.2.Final//org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTargetAfterFilter(ResourceMethodInvoker.java:399)
at org.jboss.resteasy.resteasy-jaxrs@3.6.2.Final//org.jboss.resteasy.core.ResourceMethodInvoker.lambda$invokeOnTarget$0(ResourceMethodInvoker.java:363)
at org.jboss.resteasy.resteasy-jaxrs@3.6.2.Final//org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:355)
at org.jboss.resteasy.resteasy-jaxrs@3.6.2.Final//org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:365)
at org.jboss.resteasy.resteasy-jaxrs@3.6.2.Final//org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:337)
at org.jboss.resteasy.resteasy-jaxrs@3.6.2.Final//org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:137)
at org.jboss.resteasy.resteasy-jaxrs@3.6.2.Final//org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:106)
at org.jboss.resteasy.resteasy-jaxrs@3.6.2.Final//org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:132)
at org.jboss.resteasy.resteasy-jaxrs@3.6.2.Final//org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:106)
at org.jboss.resteasy.resteasy-jaxrs@3.6.2.Final//org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:132)
at org.jboss.resteasy.resteasy-jaxrs@3.6.2.Final//org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:100)
at org.jboss.resteasy.resteasy-jaxrs@3.6.2.Final//org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:439)
at org.jboss.resteasy.resteasy-jaxrs@3.6.2.Final//org.jboss.resteasy.core.SynchronousDispatcher.lambda$invoke$4(SynchronousDispatcher.java:229)
at org.jboss.resteasy.resteasy-jaxrs@3.6.2.Final//org.jboss.resteasy.core.SynchronousDispatcher.lambda$preprocess$0(SynchronousDispatcher.java:135)
at org.jboss.resteasy.resteasy-jaxrs@3.6.2.Final//org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:355)
at org.jboss.resteasy.resteasy-jaxrs@3.6.2.Final//org.jboss.resteasy.core.SynchronousDispatcher.preprocess(SynchronousDispatcher.java:138)
at org.jboss.resteasy.resteasy-jaxrs@3.6.2.Final//org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:215)
at org.jboss.resteasy.resteasy-jaxrs@3.6.2.Final//org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:227)
at org.jboss.resteasy.resteasy-jaxrs@3.6.2.Final//org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
at org.jboss.resteasy.resteasy-jaxrs@3.6.2.Final//org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
at javax.servlet.api@1.0.0.Final//javax.servlet.http.HttpServlet.service(HttpServlet.java:791)
at io.undertow.servlet@2.0.15.Final//io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:74)
at io.undertow.servlet@2.0.15.Final//io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
at org.keycloak.keycloak-services@5.0.0//org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:90)
at io.undertow.servlet@2.0.15.Final//io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
at io.undertow.servlet@2.0.15.Final//io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
at io.undertow.servlet@2.0.15.Final//io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
at io.undertow.servlet@2.0.15.Final//io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
at io.undertow.servlet@2.0.15.Final//io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:68)
at io.undertow.servlet@2.0.15.Final//io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
at org.wildfly.extension.undertow@15.0.1.Final//org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
at io.undertow.core@2.0.15.Final//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet@2.0.15.Final//io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:132)
at io.undertow.servlet@2.0.15.Final//io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
at io.undertow.core@2.0.15.Final//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.core@2.0.15.Final//io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
at io.undertow.servlet@2.0.15.Final//io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
at io.undertow.core@2.0.15.Final//io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
at io.undertow.servlet@2.0.15.Final//io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
at io.undertow.core@2.0.15.Final//io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
at io.undertow.core@2.0.15.Final//io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
at io.undertow.core@2.0.15.Final//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at org.wildfly.extension.undertow@15.0.1.Final//org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
at io.undertow.core@2.0.15.Final//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at org.wildfly.extension.undertow@15.0.1.Final//org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
at io.undertow.core@2.0.15.Final//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet@2.0.15.Final//io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
at io.undertow.servlet@2.0.15.Final//io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
at io.undertow.servlet@2.0.15.Final//io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
at io.undertow.servlet@2.0.15.Final//io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
at io.undertow.servlet@2.0.15.Final//io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
at io.undertow.servlet@2.0.15.Final//io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
at org.wildfly.extension.undertow@15.0.1.Final//org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
at org.wildfly.extension.undertow@15.0.1.Final//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
at org.wildfly.extension.undertow@15.0.1.Final//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
at org.wildfly.extension.undertow@15.0.1.Final//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
at org.wildfly.extension.undertow@15.0.1.Final//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
at io.undertow.servlet@2.0.15.Final//io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
at io.undertow.servlet@2.0.15.Final//io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
at io.undertow.servlet@2.0.15.Final//io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
at io.undertow.core@2.0.15.Final//io.undertow.server.Connectors.executeRootHandler(Connectors.java:360)
at io.undertow.core@2.0.15.Final//io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
at org.jboss.threads@2.3.2.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads@2.3.2.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
at org.jboss.threads@2.3.2.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
at org.jboss.threads@2.3.2.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
at java.base/java.lang.Thread.run(Thread.java:834)
I believe this is a regression since I have this currently working on another server using Keycloak 4.1.0 and Java 8. As a workaround I can update the "UUID LDAP attribute" from "nsuniqueid" to "uid" and then it works again (I can search for and find users on the Users page). However, I know the "nsuniqueid" field exists in LDAP and I'm using that field with Keycloak 4.1.0. Should I create an issue ticket for this?
5 years
Re: [keycloak-user] Load testing and performance
by Tim Swift
Hi Thelo,
I was wondering if you ever got Keycloak to the performance login level
that you needed it. I have a similar setup using Docker/Kubernetes/Azure
- 4 pod instances of Keycloak (2 CPUs, 1.2 GB memory each)
- 1 Postgres DB in Azure with 4 vCores, 500 connections max
Ran a 400 thread JMeter load test to measure response time of POST login to
/auth/realms/(domain)/login-actions
Results were around 35 logins per second (14098 logins in 400 seconds)
Thanks,
Tim
5 years
Purpose of proxy_address_forwardinf variable?
by Mike W.
Does anyone know what exactly is the purpose of the
proxy_address_forwarding variable and what are its expected effects once is
it enabled and added to the http and https listeners in the standalone /
standalone-ha xml files?
Thanks,
Mike
5 years
Why duplicate records found for user?
by Ryan Slominski
I've noticed this behavior with both Keycloak 4.1.0 and Keycloak 5.0.0: when using admin web interface "Users" search duplicate records are found for some users. What could possibly be causing this?
I've tried clearing all caches from (Realm Settings > Cache) and I've tried removing imported users (User Federation > ldap storage provider > "Remove Imported" button). Still seeing duplicates for some users. Weird. I've got UUID LDAP attribute set to nsuinqueid with keycloak 4.1.0 and to uid with keycloak 5.0.0 (both pointing to same Red Hat Identity Manager instance). Duplicate users don't seem to be duplicated in LDAP. Maybe group-ldap-mapper is doing something weird? Is this due to Brokered Identities? Or is this just a bug?
5 years
Keycloak performance on Kubernetes
by Tim Swift
Hi,
For my portal config I have a Keycloak cluster running in a Docker
container deployed with Kubernetes/Azure. Database is postgres (4 cores).
I am performance testing by using JMeter to get response times for a POST
to /auth/realms/(domain)/login-actions. Overall I'm not seeing very good
results:
Threads/Response (ms)
200/5009
400/7283
600/10065
I need to support up to 2500 concurrent logins (threads) and realistically
response time should be less than 5 seconds. When I run the tests the DB
utilization is low. I have tried the following but response times are still
fairly slow.
1. Add 3 additional keycloak pods to Kubernetes (result: small improvement
in response times)
2. Bump up CPU on keycloak pods (CPU was spiking during tests, but memory
usage fairly low)
3. Investigate Azure App Gateway usage (not an issue)
I'm running out of ideas now, how can I get Keycloak to handle more logins
with better response times? Thanks for any help.
Tim
5 years
Password hash migration: what authority says "rehash the hash" is a good strategy?
by Aaron Harnly
We are migrating an older system with a deprecated password hashing
strategy that we want to bring up to modern standard.
There are a range of options for the migration, including:
1. Reset all user passwords (not ideal!)
2. Rehash after successful login (works, but leaves older hashes in
storage until the long tail of users have all logged in)
3. "Rehash the hashes", ie bulk replace the 'oldhash' values with
newhash(oldhash), with a custom verifier that does the double hash;
then do #2 on login.
I'd like input on strategy #3 – ie is there advice from authoritative
sources confirming that this is a secure strategy? It seems fine to my
layperson's eyeballs, and is surely better than leaving old hash
values in storage for a long time. But I'd like reassurance on it, and
can't find anything other than stray Stack Overflow responses[1, 2] or
blog posts[3] discussing it.
[1]: https://crypto.stackexchange.com/q/2945
[2]: https://security.stackexchange.com/a/17294
[3]: https://www.michalspacek.com/upgrading-existing-password-hashes
Any suggestions for an authoritative source on this?
cheers
-Aaron
5 years
Mappers with token exchange
by Kemal Hadımlı
Hello,
We're using token exchange to enable logins for social media provider
users, using their respective native apps. So the tokens are obtained via
official SDKs/apps, then sent our backend to be exchanged for a keycloak
token, which is then used throughout.
The problem is, attribute importers don't seem to be running for tokens
that are exchanged with this method. We have a mapper to export the user's
facebook id ("Social Profile JSON Field Path" set to "id") to custom user
attribute, but it doesn't seem to be working. (except of course when I
login "properly" and not use the token exchange process at all)
Are there any settings that I'm missing? Recommendations?
(Keycloak 5.0. Same with 4.1)
Thanks
Kemal
5 years
