November 2017 - keycloak-dev - Jboss List Archives

by Stan Silvert

Right now, the admin console tests are not being run as part of CI. As a result, they have become neglected and broken. The console bugs I am fixing right now are minor and for now we can get away with merging fixes that don't include unit tests, but the longer we wait, the worse this will get. Can we come up with a plan to get these tests running again? FYI, when I try to run a console test, I get: Caused by: java.lang.IllegalStateException: Password blacklists location does not exist: c:\GitHub\keycloak\testsuite\integration-arquillian\tests\other\console\target\test-classes\password-blacklists I can manually create the password-blacklists directory, but then I get: 08:51:31,786 ERROR [io.undertow.request] UT005023: Exception handling request to /auth/realms/master/protocol/openid-connect/token org.jboss.resteasy.spi.UnhandledException: java.lang.RuntimeException: Uncompilable source code - Erroneous sym type: org.keycloak.authentication.AuthenticationFlowContext.getAuthenticationSession.setAuthNote ... ... Caused by: java.lang.RuntimeException: Uncompilable source code - Erroneous sym type: org.keycloak.authentication.AuthenticationFlowContext.getAuthenticationSession.setAuthNote

6 years, 5 months

3
3
0 / 0

access token valid for more than expiry time by milli seconds

by Rahul R

> > Hi, > We have a keycloak set up where the Access Token Lifespan is set to 5 > minutes. We get the access token using the following command : > curl -d "client_id=admin-cli" -d "username=admin_user" -d > "password=admin_user" -d "grant_type=password" " > http://192.168.56.101:8080/auth/realms/REALM/protocol/openid-connect/token > " > > Now we use the following command to get the user details > curl -H "Authorization: bearer "access token value got earlier" " > http://192.168.56.101:8080/auth/realms/REALM/protocol/openi > d-connect/userinfo" > > The expectation is that the second command works till the token expiry > time which is 5 minutes and after 5 minutes the token not valid error > should be seen. But while running the tests multiple times, we are seeing > that sometimes the token is valid for more than 5 minutes by almost 500 > milliseconds. > > From the RFC for JWT https://tools.ietf.org/html/rfc7519 > > 4.1.4. "exp" (Expiration Time) Claim > > The "exp" (expiration time) claim identifies the expiration time on or > after which the JWT MUST NOT be accepted for processing. The processing of > the "exp" claim requires that the current date/time MUST be before the > expiration date/time listed in the "exp" claim. Implementers MAY provide > for some small leeway, usually no more than a few minutes, to account for > clock skew. Its value MUST be a number containing a NumericDate value. > Use of this claim is OPTIONAL. > > So is this delay intentional from the keycloak implementors ? > > Thanks > Rahul >

6 years, 5 months

1
0
0 / 0

Can't login with email as username if another user has same email

by Stian Thorgersen

If user#1 has the username 'user(a)host.com' with no email, and user#2 has the email 'user(a)host.com', user#1 would not be able to login. In this case user#1 would have to contact the admin who would have to change the username or add an email. This issue was reported a while back by our QE [1], but AFAIK no actual users have run into this problem and it seems unlikely that it'll be a real problem. I'm leaning towards just closing this issue as won't fix. Best ideas I have for solving is: 1. Make sure username can't match email of another user. Not sure how we could do this as I'm pretty sure that couldn't be done with SQL. 2. Add a code check for for the above. It won't be guaranteed, but maybe good enough? 3. Add option to set if realm should allow login by "Username and email", "Username only" or "Email only". For the "Username and email" option we should document the fact that this issue can happen and that email always wins. [1] https://issues.jboss.org/browse/KEYCLOAK-4466

6 years, 5 months

2
2
0 / 0

Client and Service Account Session

by Pedro Igor Silva

Hi, Currently, every time a confidential client tries to get a new access token from the token endpoint a new session is created on the server. This can lead to multiple active sessions for a single client/service account when doing multiple requests to token endpoint. To avoid that the client should store the access token/refresh token and use a refresh token when appropriate in case the access token has expired. That is fine. Now, suppose a confidential client is deployed and wants an access token. A new session will be created on the server. In case the application goes down for some reason (e.g.: container moved to a different node in kubernetes and without a persistent volume) and tries to get a new access token, we may end-up with two active sessions when asking for a new token after a re-deploy. What are your thoughts about re-using existing sessions when doing client credentials ? What could be the impact on clustering if we need (and we'll probably need) to update the session ? Another question would be ... Does make sense to also enable clients to obtain tokens without necessarily creating a session on the server ? I think that in most cases, you don't really want to keep track of sessions when doing client credentials. Regards. Pedro Igor

6 years, 5 months

1
0
0 / 0

Build broken on Windows

by Stan Silvert

This commit broke the build on Windows. It is using symlinks. While there are workarounds, I don't think we want to complicate things by merging symlinks into our code base. https://github.com/keycloak/keycloak/commit/f88b3cddb6630aae4e058f7173c7f... Please fix!!!

6 years, 5 months

2
2
0 / 0

FYI keycloak-3.4.0.Final artifact does not contain jpa-changelog-3.4.0.xml

by Thomas Darimont

Hi Keycloak Team, I just stumbled upon the fact that the latest downloadable Keycloak release 3.4.0.Final which was announced today does not contain the jpa-changelog-3.4.0.xml migration. Was this intended? FYI The current master branch contains a jpa-changelog-master.xml which references jpa-changelog-3.4.0.xml which was added 17days ago. https://github.com/keycloak/keycloak/blob/master/model/jpa/src/main/resou... Cheers, Thomas

6 years, 5 months

2
1
0 / 0

Spring boot integration test

by Thomas Recloux

Hi All, I'd like to create integration tests for spring boot and spring security adapters. I noticed that the JUnit Rule "AbstractKeycloakRule" is now located in "keycloak-testsuite-integration-deprecated" module, so it loks like it's not a great idea to use this ;-) I also noticed that there is the "testsuite/integration-arquillian/test-apps/spring-boot-adapter" module but not used and almost empty. What is the status of this module ? Is there any work in progress in this area ? Is there any documentation about testsuite/integration-arquillian structure ? Thanks, Thomas

6 years, 5 months

3
2
0 / 0

5111x SQL Executions

by John D. Ament

Hi, So we've nailed down most of our performance issues (figured out why caching was off as well). We're seeing that the last call that's struggling is the whoami call. We see 5k SQL executions for the following query: 5,111 × select userrolema0_.ROLE_ID as col_0_0_ from USER_ROLE_MAPPING userrolema0_ where userrolema0_.USER_ID=? I've put together a gist of the request/response to better highlight what I believe the issue is. Basically, for every realm and every role the user has, one query is executed. This data isn't loaded from the cache for some reason. I'm wondering if for role mapping does it make sense to simply load all of them for a given user? Gist: https://gist.github.com/johnament/e2be3ba7bda695b014caa695ebffdd61 John

6 years, 5 months

1
0
0 / 0

Keycloak 3.4.0.Final released

by Stian Thorgersen

We've just released Keycloak 3.4.0.Final. To download the release go to the Keycloak homepage <http://www.keycloak.org/downloads>. The full list of resolved issues is available in JIRA <https://issues.jboss.org/issues/?jql=project%20%3D%20keycloak%20and%20fix...> . Upgrading Before you upgrade remember to backup your database and check the upgrade guide <http://www.keycloak.org/docs/latest/upgrading/index.html> for anything that may have changed.

6 years, 5 months

2
3
0 / 0

Custom attributes for roles

by Schuster Sebastian (INST/ESY1)

Hi everybody, For compliance reasons, I have to store for each role, who is responsible for managing this role. Keycloak has the nice feature of supporting custom attributes for users and groups. I think supporting my requirement would be best done by also having custom attributes per role (that could for example also be mapped from an LDAP). Do you think custom role attributes would be a valuable addition and could make it upstream? Best regards, Sebastian Mit freundlichen Grüßen / Best regards Dr.-Ing. Sebastian Schuster Engineering and Support (INST/ESY1) Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin | GERMANY | www.bosch-si.com Tel. +49 30 726112-485 | Fax +49 30 726112-100 | Sebastian.Schuster(a)bosch-si.com Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr.-Ing. Rainer Kallenbach, Michael Hahn -----Original Message----- From: keycloak-dev-bounces(a)lists.jboss.org [mailto:keycloak-dev-bounces@lists.jboss.org] On Behalf Of Stian Thorgersen Sent: Freitag, 10. November 2017 07:14 To: keycloak-dev <keycloak-dev(a)lists.jboss.org> Subject: [keycloak-dev] Can't login with email as username if another user has same email If user#1 has the username 'user(a)host.com' with no email, and user#2 has the email 'user(a)host.com', user#1 would not be able to login. In this case user#1 would have to contact the admin who would have to change the username or add an email. This issue was reported a while back by our QE [1], but AFAIK no actual users have run into this problem and it seems unlikely that it'll be a real problem. I'm leaning towards just closing this issue as won't fix. Best ideas I have for solving is: 1. Make sure username can't match email of another user. Not sure how we could do this as I'm pretty sure that couldn't be done with SQL. 2. Add a code check for for the above. It won't be guaranteed, but maybe good enough? 3. Add option to set if realm should allow login by "Username and email", "Username only" or "Email only". For the "Username and email" option we should document the fact that this issue can happen and that email always wins. [1] https://issues.jboss.org/browse/KEYCLOAK-4466 _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

6 years, 5 months

2
1
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

keycloak-dev November 2017