Fwd: keycloak 1.8.1 to 1.9.0 upgrade failed
by Michael Mok
Hi Bruno
I will try to provide the steps in another email. Here are more info.
Thanks.
Database is MySQL 5.7 , default char set is utf8
Database migration log table attached. Not sure why it decides to redo
1.6.1 again hmmm...
On 24 February 2016 at 08:40, Bruno Oliveira <bruno(a)abstractj.org> wrote:
> Could you please provide the steps to reproduce?
>
> On Tue, Feb 23, 2016, 8:44 PM Michael Mok <teatimej(a)gmail.com> wrote:
>
>> Hi there.
>>
>> Keycloak 1.9.0 is working but this error keeps appearing in the log every
>> time I restart keycloak. :<
>>
>>
>> 23:41:51,546 INFO [org.jboss.as.clustering.infinispan] (ServerService
>> Thread Pool -- 51) WFLYCLINF0002: Started users cache from keycloak
>> container
>> 23:41:51,551 INFO [org.jboss.as.clustering.infinispan] (ServerService
>> Thread Pool -- 47) WFLYCLINF0002: Started realms cache from keycloak
>> container
>> 23:41:51,684 INFO [org.jboss.as.clustering.infinispan] (ServerService
>> Thread Pool -- 46) WFLYCLINF0002: Started realmVersions cache from keycloak
>> container
>> 23:41:52,827 INFO [org.keycloak.services] (ServerService Thread Pool --
>> 50) KC-SERVICES0001: Loading config from
>> /opt/keycloak/standalone/configuration/keycloak-server.json
>> 23:41:56,771 INFO [org.hibernate.jpa.internal.util.LogHelper]
>> (ServerService Thread Pool -- 50) HHH000204: Processing PersistenceUnitInfo
>> [
>> name: keycloak-default
>> ...]
>> 23:41:56,844 INFO [org.hibernate.Version] (ServerService Thread Pool --
>> 50) HHH000412: Hibernate Core {5.0.7.Final}
>> 23:41:56,846 INFO [org.hibernate.cfg.Environment] (ServerService Thread
>> Pool -- 50) HHH000206: hibernate.properties not found
>> 23:41:56,848 INFO [org.hibernate.cfg.Environment] (ServerService Thread
>> Pool -- 50) HHH000021: Bytecode provider name : javassist
>> 23:41:56,894 INFO [org.hibernate.annotations.common.Version]
>> (ServerService Thread Pool -- 50) HCANN000001: Hibernate Commons
>> Annotations {5.0.1.Final}
>> 23:41:57,063 INFO [org.hibernate.dialect.Dialect] (ServerService Thread
>> Pool -- 50) HHH000400: Using dialect: org.hibernate.dialect.MySQL5Dialect
>> 23:41:57,114 INFO [org.hibernate.envers.boot.internal.EnversServiceImpl]
>> (ServerService Thread Pool -- 50) Envers integration enabled? : true
>> 23:41:57,965 INFO [org.hibernate.validator.internal.util.Version]
>> (ServerService Thread Pool -- 50) HV000001: Hibernate Validator 5.2.3.Final
>> 23:41:58,990 INFO
>> [org.hibernate.hql.internal.QueryTranslatorFactoryInitiator]
>> (ServerService Thread Pool -- 50) HHH000397: Using ASTQueryTranslatorFactory
>> 23:42:00,007 ERROR [org.keycloak.services] (ServerService Thread Pool --
>> 50) KC-SERVICES0002: Failed to migrate datamodel:
>> java.lang.NullPointerException
>> at
>> org.keycloak.migration.migrators.MigrateTo1_9_0.migrate(MigrateTo1_9_0.java:42)
>> at
>> org.keycloak.migration.MigrationModelManager.migrate(MigrationModelManager.java:93)
>> at
>> org.keycloak.services.resources.KeycloakApplication.migrateModel(KeycloakApplication.java:152)
>> at
>> org.keycloak.services.resources.KeycloakApplication.<init>(KeycloakApplication.java:94)
>> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>> at
>> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>> at
>> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
>> at
>> org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:150)
>> at
>> org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2209)
>> at
>> org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:299)
>> at
>> org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:240)
>> at
>> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:113)
>> 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:78)
>> at
>> io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103)
>> at
>> io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:231)
>> at
>> io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:132)
>> at
>> io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:526)
>> at
>> org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:101)
>> at
>> org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82)
>> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
>> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>> at
>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>> at
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>> at java.lang.Thread.run(Thread.java:745)
>> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
>>
>> 23:42:00,214 INFO [org.jboss.resteasy.resteasy_jaxrs.i18n]
>> (ServerService Thread Pool -- 50) RESTEASY002225: Deploying
>> javax.ws.rs.core.Application: class
>> org.keycloak.services.resources.KeycloakApp
>> lication
>> 23:42:00,216 INFO [org.jboss.resteasy.resteasy_jaxrs.i18n]
>> (ServerService Thread Pool -- 50) RESTEASY002200: Adding class resource
>> org.keycloak.services.resources.JsResource from Application class o
>> rg.keycloak.services.resources.KeycloakApplication
>> 23:42:00,217 INFO [org.jboss.resteasy.resteasy_jaxrs.i18n]
>> (ServerService Thread Pool -- 50) RESTEASY002205: Adding provider class
>> org.keycloak.services.filters.KeycloakTransactionCommitter from App
>> lication class org.keycloak.services.resources.KeycloakApplication
>> 23:42:00,217 INFO [org.jboss.resteasy.resteasy_jaxrs.i18n]
>> (ServerService Thread Pool -- 50) RESTEASY002200: Adding class resource
>> org.keycloak.services.resources.ThemeResource from Application clas
>> s org.keycloak.services.resources.KeycloakApplication
>> 23:42:00,217 INFO [org.jboss.resteasy.resteasy_jaxrs.i18n]
>> (ServerService Thread Pool -- 50) RESTEASY002200: Adding class resource
>> org.keycloak.services.resources.QRCodeResource from Application cla
>> ss org.keycloak.services.resources.KeycloakApplication
>> 23:42:00,217 INFO [org.jboss.resteasy.resteasy_jaxrs.i18n]
>> (ServerService Thread Pool -- 50) RESTEASY002220: Adding singleton resource
>> org.keycloak.services.resources.WelcomeResource from Applicatio
>> n class org.keycloak.services.resources.KeycloakApplication
>>
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
8 years, 9 months
Re: [keycloak-user] Securely setting admin passwords
by Aikeaguinea
I'd be happy with KEYCLOAK-2501 (accepting the password on the command
line). Then the docker exec approach wouldn't expose the password; this
is essentially the approach I started with before I ran into the issue
with the -p switch. (It would be equally desirable to have the same
change for add-user --container for the Wildfly password; should I open
a JIRA with Wildfly about this, or would the implementation of
KEYCLOAK-2501 require the corresponding modification in Wildfly anyway?)
Mounting the file via volume was something we looked into. We're setting
things up in Amazon's Elastic Container Service, which uses autoscaling
groups to bring up new instances automatically (though we don't think
we'll really need that aspect of it all that much). My recollection is
that the setup involved didn't seem worth the trouble because our Docker
image is in a secure repository anyway. If we have to store the file
someplace, might as well just copy it into the container and keep it in
the image; at least that was the thinking. For people who put their
images on a public registry this wouldn't be a good solution.
From: <keycloak-user-bounces(a)lists.jboss.org> on behalf of Marek Posolda
<mposolda(a)redhat.com>
Date: Tuesday, February 23, 2016 at 4:37 AM
To: "stian(a)redhat.com" <stian(a)redhat.com>, Aikeaguinea
<aikeaguinea(a)xsmail.com>
Cc: keycloak-user <keycloak-user(a)lists.jboss.org>
Subject: Re: [keycloak-user] Securely setting admin passwords
Another possibility is to share the file keycloak-user.json with docker
via volume. Then it's not hardcoded into the Docker image. The
entrypoint script can check if the file shared through volume exists and
copy it to standalone/configuration in that case.
Marek
On 23/02/16 10:10, Stian Thorgersen wrote:
On 22 February 2016 at 16:10, Aikeaguinea <aikeaguinea(a)xsmail.com>
wrote:
With regard to Docker, things get more complicated. I believe it's not
just the bash history but the Docker history itself that stores the
commands.
What about "docker exec" approach? We've fixed it in 1.9.0.Final so that
it'll now prompt for a password if one isn't specified.
Also, per one of the messages earlier on this chain, it is not advised
to put secrets into Docker environment variables. These are accessible
in many different ways.
From: <keycloak-user-bounces(a)lists.jboss.org> on behalf of Stan Silvert
<ssilvert(a)redhat.com>
Date: Thursday, February 18, 2016 at 12:26 PM
To: "stian(a)redhat.com" <stian(a)redhat.com>
Cc: Stian Thorgersen <sthorger(a)redhat.com>, keycloak-user
<keycloak-user(a)lists.jboss.org>
Subject: Re: [keycloak-user] Securely setting admin passwords
On 2/18/2016 12:14 PM, Stian Thorgersen wrote:
It's security vs usability as usual. Allowing passing the password
directly is convenient for developers, for Docker image, for
provisioning tools, etc.. So we're not going to remove that it's
required, but I do appreciate that if not used correctly it's a
potential security risk. The worst case scenario here is really that
someone gets an admins favorite password, as someone that has access to
getting the bash history of that particular user will also be able to
run the add-user script themselves. So if the admin wants to print his
favorite password in clear text in the bash history we should not stop
him.
It's not our responsibility to clear the bash history, so we should not
do that either.
If there is a way to stop that one command from being saved in the bash
history then we should do it.
At the very least, we should print a warning message to let the
administrator know he has done something that is potentially insecure.
On 18 February 2016 at 16:53, Bruno Oliveira <bruno(a)abstractj.org>
wrote:
It's about balance. I'm not arguing here against it, I just don't see
how it could strengthen security. Nothing will stop people to get their
own gun and automate it with stdin :)
On Thu, Feb 18, 2016 at 12:45 PM Stan Silvert <ssilvert(a)redhat.com>
wrote:
On 2/18/2016 9:29 AM, Bruno Oliveira wrote:
I can be wrong, but this is not only our responsibility. For example, on
Linux you are prompted for the password with passwd, but at the same
time you could circumvent this using: echo 12345678 | sudo passwd admin
--stdin.
In this scenario security auditors won't blame the OS for this, but
pretty much sysadmins and bad security practices. Anyways, whatever
people think is the best, I'm fine.
I agree with you there. In that case you are doing something extra to
shoot yourself in the foot. We can't guard against that.
We just shouldn't put the gun in your hand.
On Thu, Feb 18, 2016 at 12:18 PM Stan Silvert <ssilvert(a)redhat.com>
wrote:
On 2/18/2016 9:10 AM, Bruno Oliveira wrote:
I think the Jira created by Stian pretty much fixes the problem. Nope?
Stian's JIRA says that if it is not specified on the command line then
do the prompt. But if we still allow setting it from the command line
then the password can still be saved to the log in plain text. Security
auditors will always frown on that.
So I'm saying we should either disallow setting on the command line or
somehow disable saving to the log. We shouldn't rely on an
administrator to do the right thing.
Something like:
./add-user-keycloak.sh -u user
Password: ******
Or
./add-user-keycloak-sh
Username: joe
Password: ******
If this can't fix the issue, is also possible to disable bash_history
temporarily. But I wouldn't take this route, because this is pretty much
system administration responsibility.
On Thu, Feb 18, 2016 at 11:47 AM Stan Silvert <ssilvert(a)redhat.com>
wrote:
On 2/18/2016 2:15 AM, Stian Thorgersen wrote:
On 17 February 2016 at 17:09, Aikeaguinea <aikeaguinea(a)xsmail.com>
wrote:
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.
That's a mistake we'll fix that. If not specified it should prompt for
it. Added https://issues.jboss.org/browse/KEYCLOAK-2501
After attending several security talks the last couple of days, I've
become rather sensitized to this kind of issue. I feel quite strongly
that we should never allow the password to be written to history in
plain text. I'm also afraid it could cause us to flunk government
certifications.
On Windows, this really isn't a problem because command history is not
saved. After a CMD session ends, the history is lost (unless you
install some third-party tool).
Perhaps there is a way to temporarily disable logging of command history
in the add-user-keycloak.sh?
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.
You need to set the password once for your database. This can be done
prior to accessing the admin console the first time. Take a look at
https://github.com/jboss-dockerfiles/keycloak/blob/master/server/README.md,
you can use docker exec to do this.
--
http://www.fastmail.com - Faster than the air-speed velocity of an
unladen european swallow
8 years, 9 months
Re: [keycloak-user] Proxying SAML Login
by Sarp Kaya
Hi,
Identity Providers tab only have the SAML provider that I was talking
about (which redirects you to SAML provider). If I go to User Federation
there is no SAML there either, so mapping IDP to a User Federation does
not seem possible. I could not find anywhere to set ³IDP Federation²,
could you explain a little further?
Kind Regards,
Sarp Kaya
>Date: Mon, 22 Feb 2016 09:04:18 -0500
>From: Bill Burke <bburke(a)redhat.com>
>Subject: Re: [keycloak-user] Proxying SAML Login
>To: keycloak-user(a)lists.jboss.org
>Message-ID: <56CB1562.2090106(a)redhat.com>
>Content-Type: text/plain; charset="windows-1252"
>
>Check the identity providers tab. You can set u "IDP Federation".
>Social login is under there too.
>
>On 2/22/2016 6:33 AM, Sarp Kaya wrote:
>> Hi,
>>
>> I have looked around but couldn?t find what I was looking for.
>> What I want to do is when user wants to login with IDP I still want
>> the user to login via Keycloak UI and I want Keycloak to proxy the
>> IDP. What makes sense to me is to have something like a new client
>> which will use OpenID and then this client would proxy it to the IDP
>> itself. Is this possible? If so then how can I do it?
>>
>>
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>--
>Bill Burke
>JBoss, a division of Red Hat
>http://bill.burkecentral.com
>
8 years, 9 months
Spring Security - URL schema in "redirect_uri" generation
by Andy Yar
Howdy,
I use 1.8.0-Final integrated with Spring Security (which itself is
integrated into Grails) using OpenID Connect method. The Keycloak and all
integrated apps run behind a nginx SSL reverse proxy. Realm's SSL is set
to: "ssl-required": "external".
My issue is related to initial "redirect_uri" generation.
When I'm logged out and try to access a protected resource via a HTTPS
request, I receive 302 response with Location URL starting with plain HTTP
scheme. Apparently the Location goes to the "redirect_uri" attribute and
therefore it tries to redirect me back here after a successful login.
Of course, it is possible to add both HTTP and HTTPS schemas as allowed
redirect URI patterns. However, application's security gets lowered by that
plain HTTP redirect...
Is there any easy solution for non-SSL Keycloak/apps running behind SSL
reverse proxy? I haven't looked into the source code but it seems as a
plain redirect which wouldn't be schema-aware.
Thanks in advance!
Andy
8 years, 9 months
Re: [keycloak-user] Securely setting admin passwords
by Aikeaguinea
With regard to Docker, things get more complicated. I believe it's
not just the bash history but the Docker history itself that stores
the commands.
Also, per one of the messages earlier on this chain, it is not advised
to put secrets into Docker environment variables. These are accessible
in many different ways.
*From: *<keycloak-user-bounces(a)lists.jboss.org> on behalf of Stan
Silvert <ssilvert(a)redhat.com> *Date: *Thursday, February 18, 2016 at
12:26 PM *To: *"stian(a)redhat.com" <stian(a)redhat.com> *Cc: *Stian
Thorgersen <sthorger(a)redhat.com>, keycloak-user <keycloak-
user(a)lists.jboss.org> *Subject: *Re: [keycloak-user] Securely setting
admin passwords
On 2/18/2016 12:14 PM, Stian Thorgersen wrote:
> It's security vs usability as usual. Allowing passing the password
> directly is convenient for developers, for Docker image, for
> provisioning tools, etc.. So we're not going to remove that it's
> required, but I do appreciate that if not used correctly it's a
> potential security risk. The worst case scenario here is really that
> someone gets an admins favorite password, as someone that has access
> to getting the bash history of that particular user will also be able
> to run the add-user script themselves. So if the admin wants to print
> his favorite password in clear text in the bash history we should not
> stop him.
>
> It's not our responsibility to clear the bash history, so we should
> not do that either.
If there is a way to stop that one command from being saved in the bash
history then we should do it.
At the very least, we should print a warning message to let the
administrator know he has done something that is potentially insecure.
>
> On 18 February 2016 at 16:53, Bruno Oliveira
> <bruno(a)abstractj.org> wrote:
>> It's about balance. I'm not arguing here against it, I just don't see
>> how it could strengthen security. Nothing will stop people to get
>> their own gun and automate it with stdin :)
>>
>> On Thu, Feb 18, 2016 at 12:45 PM Stan Silvert
>> <ssilvert(a)redhat.com> wrote:
>>> On 2/18/2016 9:29 AM, Bruno Oliveira wrote:
>>>> I can be wrong, but this is not only our responsibility. For
>>>> example, on Linux you are prompted for the password with passwd,
>>>> but at the same time you could circumvent this using: echo 12345678
>>>> | sudo passwd admin --stdin.
>>>>
>>>> In this scenario security auditors won't blame the OS for this, but
>>>> pretty much sysadmins and bad security practices. Anyways, whatever
>>>> people think is the best, I'm fine.
>>> I agree with you there. In that case you are doing something extra
>>> to shoot yourself in the foot. We can't guard against that.
>>>
>>> We just shouldn't put the gun in your hand.
>>>
>>>>
>>>> On Thu, Feb 18, 2016 at 12:18 PM Stan Silvert <ssilvert(a)redhat.com>
>>>> wrote:
>>>>> On 2/18/2016 9:10 AM, Bruno Oliveira wrote:
>>>>>> I think the Jira created by Stian pretty much fixes the problem.
>>>>>> Nope?
>>>>> Stian's JIRA says that if it is not specified on the command line
>>>>> then do the prompt. But if we still allow setting it from the
>>>>> command line then the password can still be saved to the log in
>>>>> plain text. Security auditors will always frown on that.
>>>>>
>>>>> So I'm saying we should either disallow setting on the command
>>>>> line or somehow disable saving to the log. We shouldn't rely on
>>>>> an administrator to do the right thing.
>>>>>
>>>>>
>>>>>>
>>>>>> Something like:
>>>>>>
>>>>>> ./add-user-keycloak.sh -u user Password: ******
>>>>>>
>>>>>> Or
>>>>>>
>>>>>> ./add-user-keycloak-sh Username: joe Password: ******
>>>>>>
>>>>>> If this can't fix the issue, is also possible to disable
>>>>>> bash_history temporarily. But I wouldn't take this route, because
>>>>>> this is pretty much system administration responsibility.
>>>>>>
>>>>>>
>>>>>> On Thu, Feb 18, 2016 at 11:47 AM Stan Silvert
>>>>>> <ssilvert(a)redhat.com> wrote:
>>>>>>> On 2/18/2016 2:15 AM, Stian Thorgersen wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> On 17 February 2016 at 17:09, Aikeaguinea
>>>>>>>> <aikeaguinea(a)xsmail.com> wrote:
>>>>>>>>> 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.
>>>>>>>>
>>>>>>>> That's a mistake we'll fix that. If not specified it should
>>>>>>>> prompt for it. Added
>>>>>>>> https://issues.jboss.org/browse/KEYCLOAK-2501
>>>>>>> After attending several security talks the last couple of days,
>>>>>>> I've become rather sensitized to this kind of issue. I feel
>>>>>>> quite strongly that we should never allow the password to be
>>>>>>> written to history in plain text. I'm also afraid it could
>>>>>>> cause us to flunk government certifications.
>>>>>>>
>>>>>>> On Windows, this really isn't a problem because command history
>>>>>>> is not saved. After a CMD session ends, the history is lost
>>>>>>> (unless you install some third-party tool).
>>>>>>>
>>>>>>> Perhaps there is a way to temporarily disable logging of command
>>>>>>> history in the add-user-keycloak.sh?
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> 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.
>>>>>>>>
>>>>>>>> You need to set the password once for your database. This can
>>>>>>>> be done prior to accessing the admin console the first time.
>>>>>>>> Take a look at
>>>>>>>> https://github.com/jboss-dockerfiles/keycloak/blob/master/server/README.md,
>>>>>>>> you can use docker exec to do this.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> http://www.fastmail.com[1] - Access your email from home and
>>>>>>>>> the web
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> keycloak-user mailing list keycloak-user(a)lists.jboss.org
>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
keycloak-user mailing list
>>>>>>>> keycloak-user(a)lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> keycloak-user mailing list keycloak-user(a)lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>
>>>
>>
>> _______________________________________________
>> keycloak-user mailing list keycloak-user(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
Links:
1. http://www.fastmail.com/
--
http://www.fastmail.com - Choose from over 50 domains or use your own
8 years, 9 months
Re: [keycloak-user] Securely setting admin passwords
by Aikeaguinea
We're essentially doing this. Since we need to secure the Wildfly admin
password as well, we are basically running the add-user.sh scripts to
generate the keycloak-user.json and mgmt-users.properties before running
the Docker script, and then adding them to the image. This has the
disadvantage of baking the passwords into the image, but at least
they're encrypted and the image is stored in a secure repository, which
is probably as good as we're going to get.
From: <keycloak-user-bounces(a)lists.jboss.org> on behalf of Bill Burke
<bburke(a)redhat.com>
Date: Monday, February 22, 2016 at 10:21 AM
To: "keycloak-user(a)lists.jboss.org" <keycloak-user(a)lists.jboss.org>
Subject: Re: [keycloak-user] Securely setting admin passwords
I'm too lazy to read this entire thread, sorry if somebody already
suggested this, but can't you
1) Create a minimal realm in your local environment and export the realm
to json.
2) Import this json in your Docker script?
On 2/22/2016 10:10 AM, Aikeaguinea wrote:
With regard to Docker, things get more complicated. I believe it's not
just the bash history but the Docker history itself that stores the
commands.
Also, per one of the messages earlier on this chain, it is not advised
to put secrets into Docker environment variables. These are accessible
in many different ways.
From: <keycloak-user-bounces(a)lists.jboss.org> on behalf of Stan Silvert
<ssilvert(a)redhat.com>
Date: Thursday, February 18, 2016 at 12:26 PM
To: "stian(a)redhat.com" <stian(a)redhat.com>
Cc: Stian Thorgersen <sthorger(a)redhat.com>, keycloak-user
<keycloak-user(a)lists.jboss.org>
Subject: Re: [keycloak-user] Securely setting admin passwords
On 2/18/2016 12:14 PM, Stian Thorgersen wrote:
It's security vs usability as usual. Allowing passing the password
directly is convenient for developers, for Docker image, for
provisioning tools, etc.. So we're not going to remove that it's
required, but I do appreciate that if not used correctly it's a
potential security risk. The worst case scenario here is really that
someone gets an admins favorite password, as someone that has access to
getting the bash history of that particular user will also be able to
run the add-user script themselves. So if the admin wants to print his
favorite password in clear text in the bash history we should not stop
him.
It's not our responsibility to clear the bash history, so we should not
do that either.
If there is a way to stop that one command from being saved in the bash
history then we should do it.
At the very least, we should print a warning message to let the
administrator know he has done something that is potentially insecure.
On 18 February 2016 at 16:53, Bruno Oliveira <bruno(a)abstractj.org>
wrote:
It's about balance. I'm not arguing here against it, I just don't see
how it could strengthen security. Nothing will stop people to get their
own gun and automate it with stdin :)
On Thu, Feb 18, 2016 at 12:45 PM Stan Silvert <ssilvert(a)redhat.com>
wrote:
On 2/18/2016 9:29 AM, Bruno Oliveira wrote:
I can be wrong, but this is not only our responsibility. For example, on
Linux you are prompted for the password with passwd, but at the same
time you could circumvent this using: echo 12345678 | sudo passwd admin
--stdin.
In this scenario security auditors won't blame the OS for this, but
pretty much sysadmins and bad security practices. Anyways, whatever
people think is the best, I'm fine.
I agree with you there. In that case you are doing something extra to
shoot yourself in the foot. We can't guard against that.
We just shouldn't put the gun in your hand.
On Thu, Feb 18, 2016 at 12:18 PM Stan Silvert <ssilvert(a)redhat.com>
wrote:
On 2/18/2016 9:10 AM, Bruno Oliveira wrote:
I think the Jira created by Stian pretty much fixes the problem. Nope?
Stian's JIRA says that if it is not specified on the command line then
do the prompt. But if we still allow setting it from the command line
then the password can still be saved to the log in plain text. Security
auditors will always frown on that.
So I'm saying we should either disallow setting on the command line or
somehow disable saving to the log. We shouldn't rely on an
administrator to do the right thing.
Something like:
./add-user-keycloak.sh -u user
Password: ******
Or
./add-user-keycloak-sh
Username: joe
Password: ******
If this can't fix the issue, is also possible to disable bash_history
temporarily. But I wouldn't take this route, because this is pretty much
system administration responsibility.
On Thu, Feb 18, 2016 at 11:47 AM Stan Silvert <ssilvert(a)redhat.com>
wrote:
On 2/18/2016 2:15 AM, Stian Thorgersen wrote:
On 17 February 2016 at 17:09, Aikeaguinea <aikeaguinea(a)xsmail.com>
wrote:
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.
That's a mistake we'll fix that. If not specified it should prompt for
it. Added https://issues.jboss.org/browse/KEYCLOAK-2501
After attending several security talks the last couple of days, I've
become rather sensitized to this kind of issue. I feel quite strongly
that we should never allow the password to be written to history in
plain text. I'm also afraid it could cause us to flunk government
certifications.
On Windows, this really isn't a problem because command history is not
saved. After a CMD session ends, the history is lost (unless you
install some third-party tool).
Perhaps there is a way to temporarily disable logging of command history
in the add-user-keycloak.sh?
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.
You need to set the password once for your database. This can be done
prior to accessing the admin console the first time. Take a look at
https://github.com/jboss-dockerfiles/keycloak/blob/master/server/README.md,
you can use docker exec to do this.
--
http://www.fastmail.com - Access your email from home and the web
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
_______________________________________________
keycloak-user mailing list
keycloak-user@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
--
http://www.fastmail.com - Choose from over 50 domains or use your own
_______________________________________________
keycloak-user mailing list
keycloak-user@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
--
http://www.fastmail.com - Or how I learned to stop worrying and
love email again
8 years, 9 months
