Reset admin password
by Stan Silvert
We need a way to reset the admin password in case it is lost or
hijacked. The proposal is to do that through an operation on the
keycloak-server-subsystem that only runs in "offline CLI" mode.
First, we currently allow you to delete the admin user. Should we
disallow that and make the master admin user permanent?
Should the new operation only work on the master admin password or can
it be applied to any user in any realm?
11 years
Failed building latest master - as7-subsystem
by Marek Posolda
I have some issues building latest master. Namely when building
"integration/as7-subsystem" I had:
[ERROR] Failed to execute goal on project keycloak-as7-subsystem: Could
not resolve dependencies for project
org.keycloak:keycloak-as7-subsystem:jar:1.3.0.Final-SNAPSHOT: The
following artifacts could not be resolved:
org.jboss.as:jboss-as-naming:jar:7.5.0.Final-redhat-15,
org.jboss.as:jboss-as-server:jar:7.5.0.Final-redhat-15,
org.jboss.as:jboss-as-ee:jar:7.5.0.Final-redhat-15,
org.jboss.as:jboss-as-web:jar:7.5.0.Final-redhat-15: Could not find
artifact org.jboss.as:jboss-as-naming:jar:7.5.0.Final-redhat-15 in
jboss-public-repository-group
(https://repository.jboss.org/nexus/content/groups/public-jboss)
To workaround this, I downloaded jboss-eap-6.4.0.Alpha.zip and unzip it
to my local maven repo. I guess we don't want this step to be required
for build Keycloak? Is there any public repository, which contains those
artifacts and which should be put into pom.xml ? Or am I just missing
something?
Marek
11 years
User apps and HttpClient
by Marko Strukelj
We package examples with jboss-deployment-structure.xml that looks like this:
<jboss-deployment-structure>
<deployment>
<dependencies>
<module name="org.apache.httpcomponents"/>
</dependencies>
</deployment>
</jboss-deployment-structure>
If we drop a .war containing this into Wildfly 9 (distribution/server-dist - ATM distribution/demo-dist, and distribution/adapters/wildfly-adapter-zip look buggy as they still use slot=4.3), things are fine.
However, if we dropped this into Wildfly 8 with keycloak adapter modules using org.apache.httpcomponents slot=4.3, we get a java.lang.LinkageError as soon as some Keycloak logic is triggered by user app.
The question: how come jboss modules isolation doesn’t kick in and allow keycloak adapter modules to use slot=4.3 while at the same time user app (our examples) uses slot=main?
The answer is that org.keycloak.adapters.HttpClientBuilder which seems to be our helper class for org.apache.httpcomponents inevitably leaks the version of HttpClient its module refers to - can’t be any other way (unless we change the code to use client app’s classloader - opening a can of worms). Any user app using HttpClientBuilder.build() method receives an instance of HttpClient loaded through org.keycloak.keycloak-adapter-core module, and transitively through org.apache.httpcomponents referred to therein.
Any attempt of an application (.war) to package its own httpcomponents jars, or to refer to a different jboss module than the exact one referred to by org.keycloak.keycloak-adapter-core will result in ‘catastrophic failure’. Example:
HttpClient client = new HttpClientBuilder().disableTrustManager().build();
HttpClient on the left is loaded by app’s classloader. The one returned by build() on the right is loaded by org.keycloak.keycloak-adapter-core module’s version of httpcomponents. If it’s not the same classloader (jboss module) on both sides loading HttpClient you get a LinkageError.
In light of this I wonder if it wasn’t the best solution to reexport org.apache.httpcomponents to .wars by default, thereby removing the necessity to package jboss-deployment-structure.xml at all, and ensuring that user application always uses the proper module.
Currently jboss-deployment-structure.xml is required for wildfly / as7, and is a nuisance, especially as it has to be different (refer to slot=4.3) for Wildfly 8.
If using HttpClientBuilder is supposed to be completely optional, we could maybe add configuration to keycloak subsystem to control exposing it to all or specific secure deployments.
We could simply add another common attribute that can be used in <realm> and <secure-deployment>. We could expose it by default and have something like:
<expose-httpcomponents>false</expose-httpcomponents>
to inhibit exposing it if a situation calls for it.
WDYT?
11 years
ErrorResponse and ErrorResponseException
by Benjamin Hansmann [alphaApps]
In case of failures org.keycloak.services.admin.UsersResource returns an
ErrorResponse or throws an exception (e.g. BadRequestException,
NotFoundException...) depending if the return type of the corresponding
method is Response or void. This leads to inconsistent error
representations on the client side.
org.keycloak.services.ErrorResponse wraps an ErrorRepresentation.
org.keycloak.services.ErrorResponseExceptions defines another
representation for errors
org.jboss.resteasy.spi.{BadRequestException|NotFoundException|Inte...}
just wraps a string
Would anyone mind if I define a new Exception wraps an
ErrorRepresentation for those methods that don't return a response? Or
does an exception of this kind already exist. It should ideally be named
ErrorResponseException but that one already exists...
Benjamin
11 years
Re: [keycloak-dev] [keycloak-user] Securing one .war with two .json
by Leonardo Loch Zanivan
Look at multi-tenant example
https://github.com/keycloak/keycloak/tree/master/examples/multi-tenant
On Thu, May 21, 2015 at 12:31 PM Carlos Feria <carlosthe19916(a)gmail.com>
wrote:
> Good morning. How can i configure one .war with two .json?
>
> I have two realms, these access the same .war (restfull bearer only), but
> my problem is that a .war can just one realm dependencie.
>
> I see that *keycloak* have a application with *realm-management* name and
> this application is registered in more than one realms but all realms can
> access to *realm-management* without problems.
>
> How can i do the same with my .war like *realm-management.*
>
> I need registrer my .war in two realms. Please help me.
>
> --
> Carlos E. Feria Vila
> _______________________________________________
> keycloak-user mailing list
> keycloak-user(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
11 years, 1 month
Why does WildFly CLI suck?
by Stan Silvert
I've probably been too involved with it to be objective. What are the
usability issues?
11 years, 1 month
Problem upgrading from 1.2.0.Beta1 to CR1
by Matthew Casperson
I received this error after copying the h2 database from my existing
1.2.0.Beta1 deployment into a fresh copy of CR1.
Maybe a bug with the upgrade process?
jboss.undertow.deployment.default-server.default-host./auth: Failed to
start service
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
[jboss-msc-1.2.2.Final.jar:1.2.2.Final]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
[rt.jar:1.7.0_65]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
[rt.jar:1.7.0_65]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_65]
Caused by: java.lang.RuntimeException: Failed to construct public
org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher)
at org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:160)
at org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2211)
at org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:295)
at org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:236)
at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:112)
at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36)
at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117)
at org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:79)
at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103)
at io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:220)
at io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:125)
at io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:508)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:88)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.start(UndertowDeploymentService.java:72)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
[jboss-msc-1.2.2.Final.jar:1.2.2.Final]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
[jboss-msc-1.2.2.Final.jar:1.2.2.Final]
... 3 more
Caused by: org.keycloak.models.ModelException:
javax.persistence.PersistenceException:
org.hibernate.PropertyAccessException: Null value was assigned to a
property of primitive type setter of
org.keycloak.models.jpa.entities.ClientEntity.directGrantsOnly
at org.keycloak.connections.jpa.PersistenceExceptionConverter.convert(PersistenceExceptionConverter.java:44)
at org.keycloak.connections.jpa.PersistenceExceptionConverter.invoke(PersistenceExceptionConverter.java:34)
at com.sun.proxy.$Proxy57.find(Unknown Source)
at org.keycloak.models.jpa.JpaRealmProvider.getRealm(JpaRealmProvider.java:63)
at org.keycloak.models.cache.DefaultCacheRealmProvider.getRealm(DefaultCacheRealmProvider.java:163)
at org.keycloak.services.managers.ApplianceBootstrap.bootstrap(ApplianceBootstrap.java:40)
at org.keycloak.services.managers.ApplianceBootstrap.bootstrap(ApplianceBootstrap.java:31)
at org.keycloak.services.resources.KeycloakApplication.setupDefaultRealm(KeycloakApplication.java:160)
at org.keycloak.services.resources.KeycloakApplication.<init>(KeycloakApplication.java:85)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method) [rt.jar:1.7.0_65]
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
[rt.jar:1.7.0_65]
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
[rt.jar:1.7.0_65]
at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
[rt.jar:1.7.0_65]
at org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:148)
... 18 more
Caused by: javax.persistence.PersistenceException:
org.hibernate.PropertyAccessException: Null value was assigned to a
property of primitive type setter of
org.keycloak.models.jpa.entities.ClientEntity.directGrantsOnly
at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1763)
at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1694)
at org.hibernate.jpa.spi.AbstractEntityManagerImpl.find(AbstractEntityManagerImpl.java:1141)
at org.hibernate.jpa.spi.AbstractEntityManagerImpl.find(AbstractEntityManagerImpl.java:1068)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[rt.jar:1.7.0_65]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
[rt.jar:1.7.0_65]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[rt.jar:1.7.0_65]
at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_65]
at org.keycloak.connections.jpa.PersistenceExceptionConverter.invoke(PersistenceExceptionConverter.java:32)
... 30 more
Caused by: org.hibernate.PropertyAccessException: Null value was
assigned to a property of primitive type setter of
org.keycloak.models.jpa.entities.ClientEntity.directGrantsOnly
at org.hibernate.property.DirectPropertyAccessor$DirectSetter.set(DirectPropertyAccessor.java:126)
at org.hibernate.tuple.entity.AbstractEntityTuplizer.setPropertyValues(AbstractEntityTuplizer.java:713)
at org.hibernate.tuple.entity.PojoEntityTuplizer.setPropertyValues(PojoEntityTuplizer.java:362)
at org.hibernate.persister.entity.AbstractEntityPersister.setPropertyValues(AbstractEntityPersister.java:4718)
at org.hibernate.engine.internal.TwoPhaseLoad.doInitializeEntity(TwoPhaseLoad.java:188)
at org.hibernate.engine.internal.TwoPhaseLoad.initializeEntity(TwoPhaseLoad.java:144)
at org.hibernate.loader.plan.exec.process.internal.AbstractRowReader.performTwoPhaseLoad(AbstractRowReader.java:244)
at org.hibernate.loader.plan.exec.process.internal.AbstractRowReader.finishUp(AbstractRowReader.java:215)
at org.hibernate.loader.plan.exec.process.internal.ResultSetProcessorImpl.extractResults(ResultSetProcessorImpl.java:140)
at org.hibernate.loader.plan.exec.internal.AbstractLoadPlanBasedLoader.executeLoad(AbstractLoadPlanBasedLoader.java:138)
at org.hibernate.loader.plan.exec.internal.AbstractLoadPlanBasedLoader.executeLoad(AbstractLoadPlanBasedLoader.java:102)
at org.hibernate.loader.entity.plan.AbstractLoadPlanBasedEntityLoader.load(AbstractLoadPlanBasedEntityLoader.java:186)
at org.hibernate.persister.entity.AbstractEntityPersister.load(AbstractEntityPersister.java:4126)
at org.hibernate.event.internal.DefaultLoadEventListener.loadFromDatasource(DefaultLoadEventListener.java:503)
at org.hibernate.event.internal.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:468)
at org.hibernate.event.internal.DefaultLoadEventListener.load(DefaultLoadEventListener.java:213)
at org.hibernate.event.internal.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:275)
at org.hibernate.event.internal.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:151)
at org.hibernate.internal.SessionImpl.fireLoad(SessionImpl.java:1070)
at org.hibernate.internal.SessionImpl.access$2000(SessionImpl.java:176)
at org.hibernate.internal.SessionImpl$IdentifierLoadAccessImpl.load(SessionImpl.java:2551)
at org.hibernate.internal.SessionImpl.get(SessionImpl.java:955)
at org.hibernate.jpa.spi.AbstractEntityManagerImpl.find(AbstractEntityManagerImpl.java:1110)
... 36 more
Caused by: java.lang.IllegalArgumentException: Can not set boolean
field org.keycloak.models.jpa.entities.ClientEntity.directGrantsOnly
to null value
at sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:164)
[rt.jar:1.7.0_65]
at sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:168)
[rt.jar:1.7.0_65]
at sun.reflect.UnsafeBooleanFieldAccessorImpl.set(UnsafeBooleanFieldAccessorImpl.java:80)
[rt.jar:1.7.0_65]
at java.lang.reflect.Field.set(Field.java:741) [rt.jar:1.7.0_65]
at org.hibernate.property.DirectPropertyAccessor$DirectSetter.set(DirectPropertyAccessor.java:122)
... 58 more
--
*Matthew Casperson*
*Senior Front End Developer*
Technology, Space & Distribution
Auto & General Holdings Pty Ltd
P: 07) 3377 8751 (Direct: 3377 8751)
F: 07) 3377 8833
--
This email is sent by Auto & General Insurance Company Ltd, Auto & General Services Pty Ltd, Auto & General Holdings Pty Ltd or a related body corporate (Auto & General) and is for the intended addressee.
The views expressed in this email and attachments (email) reflect the views of the stated author but may not reflect views of Auto & General. This email is confidential and subject to copyright.
It may be privileged. If you are not the intended addressee, confidentiality and privilege have not been waived and any use, interference with, or disclosure of this email is unauthorised.
If you are not the intended addressee please immediately notify the sender and then delete the email. Auto & General does not warrant that this email is error or virus free.
11 years, 1 month
Thoughts on Keycloak CLI
by Stan Silvert
I've been giving some thought to the Keycloak integration with WildFly
CLI. There are two designs. Both involve a subsystem called "kcrest"
with a resource called "server". You can define a server to talk to
using these three attributes:
base-url ( value is something like http://localhost:8080/auth/admin/realms)
username
password
username and password are optional. If you don't mind having these
values stored in standalone.xml/domain.xml you can specify them. That
way, you don't have to include them with each request.
*Design #1: Implement all of the Keycloak REST API in CLI
*We build out resources for each REST path and put them in the
management model. Then build out operations for everything. So a CLI
session to create a client called "myclient" might look like this:
cd /subsystem=kcrest/server=foo
cd realm=myrealm
clients=myclient:add(enabled=true)
*Design #2: Create a single generic operation that closely mimics the
REST API*
cd /subsystem=kcrest/server=foo
:submit(method=POST,
path=/myrealm/clients,params={"clientId"=>"myclient","enabled"=>"true"})
*
**Advantages of Design #1*
* Looks and behaves just like other CLI resources
* Uses standard CLI operations
* Each resource and operation can contain help text
* Everything can be navigated from CLI command line or CLI GUI tree,
making it easy to browse the model
*Disadvantages of Design #1**
*
* It might take a very long time to implement (2-3 months?)
* Ongoing maintenance. Every time REST API changes, you have to
update subsystem code
*Advantages of Design #2
*
* Quick to implement (2-3 weeks)
* Always works despite REST API changes
*Disadvantages of Design #2
*
* :submit operations get long and ugly
* Can't specify help text for each resource
* Hard to browse the model. Need to submit "list" style REST invocations.
Note that it might be possible to auto-generate Design #1. If so, it
would be the best of both worlds.
Whoever implements this should probably start with Design #2 and then
spend some time researching auto-generation of Design #1.
Other thoughts?
11 years, 1 month
