Run Keycloak side by side
by Davey Chu
Hello,
We have a use case where we initially want to run Keycloak side by side
with our own authentication system. Our current way of handling it is by
effectively overriding KeycloakOIDCFilter::shouldSkip method to only
execute the filter if the user is on a special Keycloak login url or if the
attribute KeycloakAccount.class.getName() is on the session (naive way to
deduce that the user has logged in with Keycloak).
As this feels like a fragile way of doing things, we were wondering if
others have had the same use case and could point us in a better direction.
Additionally, we deploy our single war in DTAP. We would therefore like to
suggest to add a possibility to set the keycloak.config.file path via a
system environment variable.
Looking forward to any response or advice,
Davey Chu
9 years, 3 months
Travis issues again
by Stian Thorgersen
Travis has an upper limit on 50 min for a single "script". Seems like our
tests are now regularly taking more than 50 min to execute so that's the
reason so many PRs are failing on Travis at the moment.
I'll try to sort this out asap.
9 years, 3 months
Keycloak 2.4.0 Status
by Stian Thorgersen
Due to meetings and public holidays 2.4.0.CR1 will be delayed and will be
released on Monday 21st. Then 2.4.0.Final is on Wednesday 23rd.
We will follow-up with 2.4.1.Final on 7th December.
All changes for 2.4.0 needs to be in by end of Friday 18th December. Marek
will drive testing of the release on Monday 21st. The release will be done
in the evening (EU time) on Monday 21st.
Remaining work for 2.4.0.CR1 includes:
* LDAP porting to User Storage SPI including migration. If not ready it'll
get postponed to 2.4.1.
* Infinispan cache issues - Marek is working on this and the aim is to
include. If not ready it'll get postponed to 2.4.1.
* Remove native libraries included in SSSD jar - Bruno is working on this.
* Fuse issues - Marek is on these
* A few more minor issues, see JIRA for list
Postponed to 2.4.1:
* Kerberos and SSSD porting to User Storage SPI
* LDAP without syncing users to Keycloak db
* Removal of old User Federation SPI
9 years, 3 months
Splitting server-spi into server-spi and server-spi-private
by Stian Thorgersen
I've sent a PR for splitting server-spi into server-spi and
sever-spi-private.
server-spi should now aim to include only what is needed to create a user
storage provider. There are more in there than I'd like, but it would be to
much work to refactor things at this point.
The PR is:
https://github.com/keycloak/keycloak/pull/3489
I'll give everyone a chance to take a look and object to this before
merging. So please review it asap as I'll be merging it tomorrow.
9 years, 3 months
evict on update/remove, make providers cache aware
by Bill Burke
I was thinking that we change all Mongo and JPA adapters, and
RealmProvider and UserProvider methods that can update or remove models
from the database and have them evict the cache of that type. This will
make sure that if somebody gets a non-cached model or provider and
performs an update, the cache is still invalidated. Sound ok?
Thanks,
Bill
9 years, 3 months
Microservice to Microservice calls, authorization from a queue message
by Ignacio Ocampo
Hello Team,
*Context:* I'm creating a cloud platform to support multiple applications
with SSO. I'm using *Keycloak for authentication* and *Netflix Zuul for
authorization* (API Gateway) thru *Keycloak Spring Security Adapter*.
Each microservice expect an Authorization header, which contains a valid
JWT, from which it will take the username (sub) to process the request.
Each microservice-to-microservice call should go thru Netflix Zuul first,
passing the Authorization header to maintain a stateless validation. That
strategy allow to every microservice to know who is the user (sub) who is
invoking the microservice indirectly.
*Problem/Question 1:* What happens if a microservice is invoked from a
queue message? One idea that I had is to storage in the queue the
information related to the message + userInfo, and, create a dedicated
microservice to process that kind of messages, with that approach this
special microservice should read the userInfo from the queue and process
the message.
*Problem/Question 2:* But, what happens if the previous special
microservice wants to call another normal microservice which expect to
receive a JWT in a header? Should this special microservice create by
himself a JWT to impersonate the user and be able to call the regular
microservices?
Another solution that I thought was to storage the original JWT in the
queue, but, what happens if the queue calls to the special microservice
later? Just after the JWT is not valid anymore (it expired) and the
microservice called will reject the request?
I will appreciate very much your help. Thanks.
--
Ignacio Ocampo Millán
9 years, 4 months
Custom UserStorageProvider and TOTP Credentials
by Thomas Darimont
Hello,
I have a custom UserStorageProvider as a replacement for the deprecated
UserFederationProvider mechanism which connects users from a legacy user
store with Keycloak.
Since the legacy user store will remain the leading system for a while.
I want to prohibit users from changing passwords and OTP secrets via the
account page.
For password changes this can be easily done by throwing an
UnsupportedOperationException
in the implementation of the org.keycloak.credential.CredentialInputUpdater.
updateCredential(RealmModel, UserModel, CredentialInput) method for the
UserCredentialModel.PASSWORD.
If a user tries to change a password he/she sees an error message that this
is not supported for their accounts.
However prohibiting users from configuring a TOTP token cannot be done this
way, since thowing an exception results in a stacktrace presented to the
user. (stacktrace below)
I think the reason for this is that the AccountService.processTotpUpdate
method:
org.keycloak.services.resources.AccountService.processTotpUpdate(
MultivaluedMap<String, String>)
is missing some error handling:
See: https://github.com/keycloak/keycloak
/blob/ccaac408630d83b6d66b041a2ef4c23102f0ed60/services/src/main/java/org/
keycloak/services/resources/AccountService.java#L563
In AccountService.processPasswordUpdate the error handling seems to be fine.
org.keycloak.services.resources.AccountService.processPasswordUpdate(
MultivaluedMap<String, String>)
see: https://github.com/keycloak/keycloak
/blob/ccaac408630d83b6d66b041a2ef4c23102f0ed60/services/src/main/java/org/
keycloak/services/resources/AccountService.java#L641
Could the error handling (try / catch) of AccountService.
processPasswordUpdate also be applied to AccountService.processTotpUpdate?
This would ease the control of what credentials a "federated" user can
change.
Bottom line it should be possible for a UserStorageProvider to only
validate credentials (Password, OTP, etc.) ( org.keycloak.credential.
CredentialInputUpdater) but prohibit updating them.
Currently the login in org.keycloak.credential.UserCredentialStoreManager.
updateCredential(RealmModel, UserModel, CredentialInput)
falls back to updating the credentials anyway if the CredentialInputUpdater.
updateCredential(..) Method implemented by the custom UserStorageProvider does
NOT handle the credential update by returning false in
CredentialInputUpdater.updateCredential(..)
Cheers,
Thomas
Error processing request
Context Path:/auth
Servlet Path:
Path Info:/realms/user-storage-provider-dev/account/totp
Query String:null
Stack Trace
org.jboss.resteasy.spi.UnhandledException: java.lang.IllegalStateException:
updateCredential(realm,user,credentialInput) not supported
org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(
ExceptionHandler.java:76)
org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler
.java:212)
org.jboss.resteasy.core.SynchronousDispatcher.writeException(
SynchronousDispatcher.java:168)
org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher
.java:411)
org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher
.java:202)
org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher
.service(ServletContainerDispatcher.java:221)
org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(
HttpServletDispatcher.java:56)
org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(
HttpServletDispatcher.java:51)
javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler
.java:85)
io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(
FilterHandler.java:129)
org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(
KeycloakSessionServletFilter.java:90)
io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(
FilterHandler.java:131)
io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler
.java:84)
io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.
handleRequest(ServletSecurityRoleHandler.java:62)
io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(
ServletDispatchingHandler.java:36)
io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.
handleRequest(SSLInformationAssociationHandler.java:131)
io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.
handleRequest(ServletAuthenticationCallHandler.java:57)
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler
.java:43)
io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(
AbstractConfidentialityHandler.java:46)
io.undertow.servlet.handlers.security.
ServletConfidentialityConstraintHandler.handleRequest(
ServletConfidentialityConstraintHandler.java:64)
io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(
AuthenticationMechanismsHandler.java:60)
io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.
handleRequest(CachedAuthenticatedSessionHandler.java:77)
io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.
handleRequest(AbstractSecurityContextAssociationHandler.java:43)
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler
.java:43)
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler
.java:43)
io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(
ServletInitialHandler.java:284)
io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(
ServletInitialHandler.java:263)
io.undertow.servlet.handlers.ServletInitialHandler.access$000(
ServletInitialHandler.java:81)
io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(
ServletInitialHandler.java:174)
io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor
.java:1142)
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor
.java:617)
java.lang.Thread.run(Thread.java:745)
9 years, 4 months
Making ServerInfoAdminResource::ENUMS mutable
by Dmitry Telegin
Hi,
After KEYCLOAK-3618 is (hopefully) resolved, providers will have an
ability to log admin events with custom ResourceType. However, custom
values won't show in the Events - Admin Events - Filter - Resource
Types dropdown (fortunately, the values can still be typed in
directly).
The values in the dropdown reflect
org.keycloak.services.resources.admin.info.ServerInfoAdminResource::ENU
MS content. How about making it mutable, so that providers could
register provider-specific values? These could be some two methods: one
taking (String, String[]) to add values to existing enum maps, another
one taking (Class... enums) to register completely different enums for
provider's private needs.
What do you think?
Dmitry
9 years, 4 months
User SPI cache policies
by Bill Burke
You can now define cache policies per UserStorageProvider.
* NO_CACHE - don't cache users loaded from this provider
* MAX_LIFESPAN - max lifespan of user in cache
* EVICT_DAILY - specify a time of day when the cache will be expired
every day.
* EVICT_WEEKLY - specify a day of the week and time of day when the
cache will be expired.
Bill
9 years, 4 months
