LockAcquisitionException against SQL Server
by Geadah, Nicolas (VEC)
We have started a load testing effort against RedHat SSO 7.1.2, using a SQL Server data source. Our datasource pool is set to min/max of 10/30.
With a load of only about 5 concurrent users, we start experiencing LockAcquisitionException errors on user creation or access token building. This results in the load test failing for a large percentage of users.
Any recommendations on where to look for resolving this issue? Perhaps something with the data source configuration?
Thanks!
8 years, 4 months
Searching user based on firstName, lastName, etc.
by Sajid Chauhan
Dear All,
On the admin console we can search for a user using their firstName or
lastName or a combination of the tow. (GET /admin/realms/{realm}/users)
However, when I try using the below code snippet the search does not work
as expected.
Keycloak kc = Keycloak.getInstance(serverUrl, masterRealm,
masterUsername, masterPassword, masterClientId);
List<UserRepresentation> userRepresentations =
kc.realms().realm(realmName).users().search(username, firstName,
lastName, email, firstResult, maxResults);
Can anyone please help out how can I search for a user firstName or
lastName programmatically in keycloak?
--
Thanks and regards,
Sajid
8 years, 4 months
Programatic username/password access with KeyCloak using external IDP brokering
by Yuriy Yunikov
Hello,
We're using Identity Brokering feature and we use external IDP. So, user
logs in into external IDP UI, then KeyCloak broker client receives JWT
token from external IDP and KeyCloak provides JWT with which we access our
resources. We've set up "Default Identitiy Provider" feature, so external
IDP login screen is displayed to the user on login. That means that users
and their passwords are stored on external IDP.
The problem occurs when we need to log in using "Direct Access Grant"
(Resource Owner Password grant) programatically in our tests. As password
is not stored on KeyCloak, we always get 401 Unauthorized error from
KeyCloak on login. When I tried to change user password it started to work,
so the problem is that user password is not provisioned on KeyCloak and
using "Direct Access Grant" KeyCloak doesn't invoke external IDP.
Is there any way it can be fixed? For example to call identity broker on
"Direct Access Grant", so that KeyCloak provides us it's valid token?
Regards,
Yuriy
8 years, 4 months
Keycloak options
by trmadhu＠tafe.com
Dear Team
We are evaluating the keycloak SSO, we require some of the features to be deployed.
1. We are planning to deploy Primary Server in our Data center and replica in the AWS data center - does keycloak supports replication between primary and secondary
2. How to address Non SAML / Open ID - we have in house application which does not support SAML, how to address those applications
3. We are integrated Keycloak with Active directory and LDAP, but change password is not supported for AD / LDAP.
Regards
[All]
Above email is subject to 'Disclaimer' as per <a href="http://tafe.co.in/email-disclaimer.htm">http://tafe.co.in/email-disclaimer.htm</a>
8 years, 4 months
sessions are lost after restart - 3.3.0.CR2
by shop24＠wolke7.net
Hi,
as we plan to update to 3.3.0.Final, I already started to play with the current CR2 and check the features we use.
We save our sessions in the file based infinispan cache
<local-cache name="sessions" xmlns="urn:jboss:domain:infinispan:4.0">
<file-store passivation="false" fetch-state="true" purge="false" relative-to="jboss.home.dir" path="/infinistate/session" />
</local-cache>
I can see the session.dat file there growing on the amount of sessions, and as long as the server stays alive, the sessions can be counted.
But when I restart the server, no sessions are visible on the admin console neither by the REST API.
Those things worked at least until 3.1.0.Final.
Is this a bug or can I configure this some how different now? Are you working on it and it is one of the point, that are not final?
Regards,
Marie
8 years, 4 months
session timeout behavior when using the Spring Security adapter
by Sud Ramasamy
It looks like when using Keycloak and Spring Security with the OIDC Client protocol there is a way to hose the application session unintentionally when the Keycloak SSO session timeout setting is lower than the application (ie. Client) session timeout value.
If the user accesses any parts of the application which are protected by the Keycloak adapter after the access token has expired (configured for 5 minutes) without first ending the application session, Spring Security still has the authentication object. But as part of the authentication flow in the application, the Keycloak adapter checks to see if the Access token is active which it won't be at this point. So the Keycloak adapter (RefreshableKeycloakSecurityContext.java) attempts to get a new Access token using the refresh token it has. Since the refresh token has been invalidated in Keycloak the adapter receives a "Stale refresh token" error response from Keycloak. The "no access token" is propagated to the Keycloak adapter's OAuthRequestAuthenticator.java which proceeds to trigger a login redirect to Keycloak. Once the user is successfully authenticated in Keycloak and control is returned to the KeycloakAuthenticationProcessingFilter.java as a final step it attempts to store the KeycloakAuthenticationToken in the Spring SecurityContextHolder (see SpringSecurityTokenStore.saveAccountInfo). Here the code throws an exception because there is already an existing KeycloakAuthenticationToken in the SecurityContextHolder from the earlier login that wasn't cleared.
At this point SSO login into the application is hosed. A potential fix is to trigger a call to the application’s logout endpoint which will clear the Spring SecurityContextHolder object prior to fetching a new access token.
I was wondering if anyone has run into this behavior. It seems like when using the OIDC Client protocol by it’s very nature of using short lived Access tokens and Refresh tokens that are tied to the Keycloak session we will have to set the Keycloak Session timeout to be the same or higher than the Client session timeout. But we do not necessarily have control over the clients. So we will have to set the Keycloak session timeout to the highest session timeout across all Clients since this is realm level setting and not a per Client setting. But this breaks another use case since we are using Identity Brokering. We want the user to be bounced to the external Identity Provider when their application session timeouts. If the Keycloak session timeout is higher than their application session timeout then they wouldn’t be bounced to the external Identity Provider for authentication. Looks like we might need to force Keycloak to initiate the authentication when we detect an application timeout.
-sud
8 years, 4 months
Poor performance on /admin/realms/platform/users
by David Hartfield
After upgrading from keycloak 1.9.8 to 3.3.0.Final I started noticing a substantial performance issue on the /admin/realms/platform/users endpoint. I use this with an empty search and typically grab 1000 users at a time. I am able to reproduce the issue as follows:
1. Downloaded fresh copy of 3.3.0
2. Connect to empty postgres database (by following the documentation for adding the postgres jar as a module and setting up datasource connection in standalone.xml)
3. Run in standalone mode
4. Create a new realm and add 1000 users
* I did this by using the admin-cli client and an admin user I created with manage-users & manage-realms. Used bearer tokens to hit POST to endpoint to create user.
5. Now I hit the /admin/realms/platform/users endpoint with a bearer token from the admin-cli client
The call takes 30 seconds to return!! And this is with everything on my local machine.
I can verify that if I do the same process with with keycloak 1.9.8 the same call takes just about 1 second
What has caused the difference between 30 seconds and 1 second for the same call? Is there something I need to set up differently in version 3.3.0?
As a side note, I tried paging the calls 100 at a time on keycloak 3.3.0 as well. Going this route on my local machine takes a sum total of about 13 seconds to get all 1000 users of ten calls. 13 seconds is a pretty long time for just 1000 users.
--
David Hartfield
Software Architect | EdLogics
david.hartfield(a)edlogics.com<mailto:chris.savory@edlogics.com>
www.edlogics.com<http://www.edlogics.com/>
[cid:image001.png@01D36CF2.2757B060]<http://www.edlogics.com/>
[cid:image002.png@01D36CF2.2757B060]<https://www.linkedin.com/company/edlogics>[cid:image003.png@01D36CF2.2757B060]<https://twitter.com/EdLogics>
8 years, 4 months
CORS header on /auth endpoint
by LAGIER Aymeric
Hi,
I have an angular 4 app protected by the mod_auth_openidc apache module<https://github.com/zmartzone/mod_auth_openidc>. My API is also protected by the same apache module.
Configuration (mod_auth_openidc configuration is omitted) :
# API
<Location "/api">
ProxyPass http://monapi.com
ProxyPassReverse http://monapi.com
AuthType openid-connect
Require valid-user
</Location>
# Angular
<Location "/">
AuthType openid-connect
Require valid-user
</Location>
My angular app calls /api via an AJAX call through the angular http client :
this.http.get('/api', { withCredentials: true } ).subscribe(function (data) {
console.log(data);
});
Everything is configured to work with the authorization code flow and CORS is configured to "*" in my keycloak client.
Everything works fine when the apache session is valid.
If my angular app is started and my apache session is expired, when I try to call /api, the apache module returns a HTTP 302 response :
HTTP/1.1 302 Found
Date: Mon, 04 Dec 2017 15:43:49 GMT
Server: Apache/2.4.25 (Unix)
Set-Cookie: mod_auth_openidc_state_OceqhOzOyuDZCbg7G0dZJh-JCbM=(....); Path=/; HttpOnly
Location: http://keycloak/auth/realms/<REALM-NAME>/protocol/openid-connect/auth?response_type=code&scope=openid&client_id=<CLIENT_ID>&state=OceqhOzOyuDZCbg7G0dZJh-JCbM&redirect_uri=http%3A%2F%2Fapp%3A8070%2Fredirect_uri&nonce=l-vH7oI71dUuOpT0BRixiJZgME2lY29AMrEIlLZjQAI
Content-Length: 460
Keep-Alive: timeout=5, max=99
Connection: Keep-Alive
Content-Type: text/html; charset=iso-8859-1
The HTTP 302 is followed and the following request is sent:
GET http://keycloak/auth/realms/<REALM-NAME>/protocol/openid-connect/auth?response_type=code&scope=openid&client_id=<CLIENT_ID>&state=<STATE>&redirect_uri=http%3A%2F%2Fapp%3A8070%2Fredirect_uri&nonce=<NONCE> HTTP/1.1
Host: keycloak:8080
Connection: keep-alive
Accept: application/json, text/plain, */*
Origin: http://app:8070
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.94 Safari/537.36
Referer: http://app:8070/dashboard
Accept-Encoding: gzip, deflate
Accept-Language: fr-FR,fr;q=0.9,en-US;q=0.8,en;q=0.7
Cookie: AUTH_SESSION_ID=6cb9e14d-3a85-484d-b40b-2b447affe8be; KEYCLOAK_IDENTITY=<VALUE>; KEYCLOAK_SESSION=<VALUE>
Keycloak validates my cookies and returns another HTTP 302 to go back to the application domain :
HTTP/1.1 302 Found
Connection: keep-alive
Cache-Control: no-store, must-revalidate, max-age=0
Set-Cookie: KC_RESTART=<VALUE>; Version=1; Path=/auth/realms/ALA; HttpOnly
Set-Cookie: KC_RESTART=; Version=1; Expires=Thu, 01-Jan-1970 00:00:10 GMT; Max-Age=0; Path=/auth/realms/<REALM-NAME>; HttpOnly
Set-Cookie: KEYCLOAK_IDENTITY=<VALUE>; Version=1; Path=/auth/realms/ALA; HttpOnly
Set-Cookie: KEYCLOAK_SESSION=<VALUE>; Version=1; Expires=Tue, 05-Dec-2017 01:43:49 GMT; Max-Age=36000; Path=/auth/realms/<REALM-NAME>
Set-Cookie: KEYCLOAK_REMEMBER_ME=; Version=1; Comment=Expiring cookie; Expires=Thu, 01-Jan-1970 00:00:10 GMT; Max-Age=0; Path=/auth/realms/<REALM-NAME>; HttpOnly
P3P: CP="This is not a P3P policy!"
Location: http://app:8070/redirect_uri?state=<STATE>&code=<CODE>
Content-Length: 0
Date: Mon, 04 Dec 2017 15:43:49 GMT
The problem is that CORS headers are not returned by the keycloak server so the browser doesn't accept the response :
Failed to load http://keycloak/auth/realms/<REALM-NAME>/protocol/openid-connect/auth?response_type=code&scope=openid&client_id=<CLIENT_ID>&state=<STATE>&redirect_uri=http%3A%2F%2Fapp%3A8070%2Fredirect_uri&nonce=<NONCE>: Redirect from 'http://keycloak/auth/realms/<REALM-NAME>/protocol/openid-connect/auth?response_type=code&scope=openid&client_id=<CLIENT_ID>&state=<STATE>&redirect_uri=http%3A%2F%2Fapp%3A8070%2Fredirect_uri&nonce=<NONCE>' to 'http://app:8070/redirect_uri?state=<STATE>&code=<CODE>' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://app:8070' is therefore not allowed access.
By manually injecting the 2 missing CORS headers "Access-Control-Allow-Origin" and "Access-Control-Allow-Credentials", the redirect is done but there's a problem on the next redirect :
GET http://app:8070/redirect_uri?state=<STATE> HTTP/1.1
Host: app:8070
Proxy-Connection: keep-alive
Accept: application/json, text/plain, */*
Origin: null
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.94 Safari/537.36
Referer: http://app:8070/dashboard
Accept-Encoding: gzip, deflate
Accept-Language: fr-FR,fr;q=0.9,en-US;q=0.8,en;q=0.7
Cookie: mod_auth_openidc_state_9v609458FxkBuhIFpPyQDd0UNr0=<STATE>
Because the Origin is null, the browser also refuse the response :
Failed to load http://app:8070/redirect_uri?state=<STATE>&code=<CODE>: Redirect from 'http://app:8070/redirect_uri?state=<STATE>&code=<CODE>' to 'http://app:8070/api' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'null' is therefore not allowed access.
The origin = null seems to respect the specification : https://www.w3.org/TR/cors/#generic-cross-origin-request-algorithms (See section 7.1.7 step 6).
Do you know how to solve these problems ?
Thanks in advance,
Regards
Aymeric
8 years, 4 months
JWT 'sub' claim in client credentials flow
by Balazs Kovacs
Hi,
I'm experimenting with Keycloak 3.4.1 CR1.
I'm executing a client_credentials flow with a client to get authorized at
a resource server. When authorizing at the resource server,
I'm using the JWT 'sub' claim to identify the subject accessing the
resource server.
Apparently, in this flow the 'sub' claim is getting an ID that I'm not able
to relate to any metadata of the client. I would have expected
the client_id be used as 'sub' but it is not.
Here is a partial access token content I got for client credentials
(client id is used in aud and azp fields below, and not 'sub'):
{
"jti": "417742bc-b374-4457-955b-3a5c5cea1d02",
"exp": 1512377520,
"nbf": 0,
"iat": 1512377220,
"iss": "http://localhost:8081/auth/realms/myrealm",
"aud": "5d8448f9-d7d8-41f9-b0cc-3f8772fca62f",
"sub": "a82751a5-3635-4cd3-941e-e0f38367ea73",
"typ": "Bearer",
"azp": "5d8448f9-d7d8-41f9-b0cc-3f8772fca62f",
...
}
So I have these questions:
- Is there a reason why 'sub' is not 'client_id' in client credentials
flow? Note, that in authorization_code flow the 'sub' claim gets the ID of
the user that I
also see in the Admin Console, as expected.
- If they have to be different, how could I query what 'sub' value will
belong to a client_id without requesting a token on behalf of the client?
For example, can it be somehow retrieved from Admin REST API? (I didn't
find it in the client schema either)
Best Regards,
Balazs Kovacs
8 years, 4 months
Services behind a Proxy that offloads SSL
by Malte Finsterwalder
Hi there,
I have a service running in a JBoss server, that I want to secure via the
keycloak adapter.
The server is behind a proxy, that offloads SSL, so the server itself gets
traffic as http.
When the server redirects to keycloak for authentication, the redirect URL
supplied to keycloak is http, not https. How can I ensure, that a redirect
URL is an https URL?
Greetings,
Malte
8 years, 4 months
