Slow Direct Grants API endpoint
by Daniel Baxter
Hi,
I am attempting to integrate Keycloak into an existing application to replace the homegrown user management system in place. We have a new project built from the ground up on Keycloak 1.0.4.Final which is exhibiting good performance. However this app that I am porting has a remoting component that connects to the server with bare username/password credentials over the EJB Remoting framework. I was hoping to use 1.1.0 (currently Beta2) which provides a DirectAccessGrantsLoginModule which does exactly what I want (turns username and password into a KeycloakPrincipal). However, the turn around time from Keycloak is on the order of several seconds.
I have used a bare REST client to execute the POSTs to both our 1.0.4 Keycloak and 1.1.0 Keycloak instances and have noted an order of magnitude difference in getting a response. Is this a known issue (I cannot find anything in the public bugs/tasks list)? Or is this due to the Beta status leaving additional performance affecting logging or instrumentation in place?
Thanks,
Daniel
10 years, 10 months
Facing Issue with Resource Server in Clustered Environment
by Bappaditya Gorai (bgorai)
Hi Team,
Please find the details on setup and observation below. Please provide your suggestion on how to overcome this issue. We are using Keycloak 1.0.4.Final (Adapter & Server).
Setup:
1. We have brought up Jboss cluster ( Using mod_cluster, httpd ) with 2 nodes in domain mode and enabled session replication between these nodes.
2. Our Recourse server is deployed in this clustered environment with distributable and Sticky session Off.
Behavior observed :
During the Authorization/Authentication process ,when Initial call(Resource Access) lands on master and next redirection (post Code To token) falls on slave Adapter is treating it as a new session and redirecting to login URL again. So we ended up with circular redirection error. After further investigation seems like session replication delay is causing adapter to behave this way. As the redirection call happens very quickly and this results in circular redirection error.
NOTE: Sticky Session in mod_cluster environment solves the issue but it does not provide true load balancing. Therefore we are not considering Stick session option.
Thanks
Bappaditya Gorai
10 years, 10 months
Improve browser caching?
by Marek Posolda
We seem to have many questions each release related to non-working
things due to stale browser cache. Usually it's due to changes in admin
console, but it may be even worse if we ever change something in CSS/JS
of login or account mgmt, as those are available for end users.
I wonder if we can somehow improve this? One possible solution is to
attach the redundant parameter with version to the cached resources.
Something like: "/auth/theme/.../stylesheet.css?v=1.1.0.Final", so
upgrade to next version will force browser to reload the resource.
The problem is longer (and not so nice) URLs and also some refactoring
needed. For freemarker templates, we can add version parameter at
runtime. However for admin console HTML pages, we would need to add
version somehow at compile time though.
There is also possibility to attach hash instead of version (Juca
mentioned this to me some time ago), but not sure if it's big difference.
Any better ideas? Or should we rather just keep it as it is?
Marek
10 years, 10 months
Automatic logout from KC admin console for non-authorized users
by Marek Posolda
Right now, when user goes to keycloak admin console and he doesn't have
access (any admin roles assigned), he is logged out automatically. It's
done by "whoami" endpoint, which returns 401 in this case.
Shouldn't we instead just display some notification like "Forbidden, you
don't have access" instead of automatically logout user?
My point is links between various admin consoles. For example when user
is logged in hawtio admin console and he click on link to Keycloak admin
console. But when he don't have access, he is logged out automatically,
which does SSO logout and logout him also from hawtio. To me it looks
like bit confusing behaviour tbh.
Also do we have plan to add support for referrer in KC admin console
similarly like account mgmt has?
Marek
10 years, 10 months
Do we have Login SPI with Keycloak_1.1.0_Final?
by Lakshmi Narayana VADALI (lvadali)
Congrats Team for Keycloak 1.1.0.Final Release loaded with features.
We are planning to integrate our code with Latest Keycloak. So Can you please confirm do we have full support for Below features in Keycloak_1.1.0_Final Release.
1. Login SPI
2. HA Support
3. Clustering Support
Thanks,
Lakshmi Narayana V
10 years, 10 months
Re: [keycloak-dev] Looking for a workaround...
by Michael Gerber
Am 02. Februar 2015 um 09:07 schrieb Stian Thorgersen <stian(a)redhat.com>:
----- Original Message -----
From: "Michael Gerber" <gerbermichi(a)me.com>
To: "Stian Thorgersen" <stian(a)redhat.com>
Cc: "keycloak dev" <keycloak-dev(a)lists.jboss.org>
Sent: Sunday, 1 February, 2015 4:09:35 PM
Subject: Re: [keycloak-dev] Looking for a workaround...
I would look at the following scenario:
A user starts with the login process and then takes a long break (15 mins or
more) without locking his computer.
Is this not a relatively uncommon use-case? Would a error message with a link back to the application be a good enough solution?
Unfortunately, it isn't. We have got customers which use one computer for multiple users. And this users are used to logout from the application without closing the browser.
The new user then uses the same browser to login. And this action would lead to an error, which is for the user not understandable.
There are critical processes like password changes, which should definitely
expires after a view minutes and others like authentication which does not
matter if they don’t expire during this break.
As above we need to improve the error page in this case. With a way back to the application as well.
critical actions:
- OAUTH_GRANT
- CODE_TO_TOKEN (already seperate)
- VERIFY_EMAIL
- RECOVER_PASSWORD
- UPDATE_PROFILE
- CONFIGURE_TOTP
- UPDATE_PASSWORD
non-critical actions:
- AUTHENTICATE
- SOCIAL_CALLBACK
> Am 30.01.2015 um 14:25 schrieb Stian Thorgersen <stian(a)redhat.com>:
>
> What groups would you propose?
>
> ----- Original Message -----
>> From: "Michael Gerber" <gerbermichi(a)me.com>
>> To: "Stian Thorgersen" <stian(a)redhat.com>
>> Cc: "keycloak dev" <keycloak-dev(a)lists.jboss.org>
>> Sent: Monday, 26 January, 2015 4:23:49 PM
>> Subject: Re: [keycloak-dev] Looking for a workaround...
>>
>>> ----- Original Message -----
>>>> From: "Michael Gerber" <gerbermichi(a)me.com>
>>>> To: "Stian Thorgersen" <stian(a)redhat.com>
>>>> Sent: Monday, January 26, 2015 2:10:59 PM
>>>> Subject: Re: [keycloak-dev] Looking for a workaround...
>>>> ----- Original Message -----
>>>> From: "Michael Gerber" <gerbermichi(a)me.com>
>>>> To: keycloak-dev(a)lists.jboss.org
>>>>
>>>> Sent: Monday, January 26, 2015 1:37:53 PM
>>>> Subject: [keycloak-dev] Looking for a workaround...
>>>> Hi all,
>>>> I receive a lot of bug reports from our test team because of the
>>>> following
>>>> two issues:
>>>> - Reset password leads to 400 Bad Request (
>>>> https://issues.jboss.org/browse/KEYCLOAK-1014 )
>>>> This is a tricky one - we can't ignore the state variable as that would
>>>> make
>>>> it vulnerable.
>>>> We could probably come up with an alternative way to generate and verify
>>>> state variable though. Could be a HMAC for example.
>>>> So you would remove the state cookie?
>>>
>>> It could potentially be a solution - I started a separate thread on
>>> keycloak-dev to discuss this.
>>>
>>>> - Login attempt after "Login user action lifespan" leads to "Invalid
>>>> username
>>>> or password." ( https://issues.jboss.org/browse/KEYCLOAK-1015 )
>>>> I agree that the error message is not very good, but I disagree with
>>>> removing
>>>> the expiration. Why not increase it to say 30 min? That's probably a
>>>> more
>>>> sensible timeout for reset password as well.
>>>> I prefer an expiration of 5 min for the password update process, but
>>>> thats
>>>> a
>>>> bit short for the authentication or password reset process.
>>>> I think the best solution would be different expiration times for the
>>>> different processes, wouldn't it?
>>>
>>> Maybe - we do try to keep configuration options to a minimum as these
>>> introduce complexity as well as potentials for bug/security issues.
>>
>> I totaly understand that.
>> You have currently the following actions:
>> OAUTH_GRANT,
>> CODE_TO_TOKEN,
>> VERIFY_EMAIL,
>> UPDATE_PROFILE,
>> CONFIGURE_TOTP,
>> UPDATE_PASSWORD,
>> RECOVER_PASSWORD,
>> AUTHENTICATE,
>> SOCIAL_CALLBACK
>>
>> And it doesn't make sense to have a different conffiguration for every
>> one...
>> But maybe we can group it into different groups?
>>
>>>
>>>
>>>> Do you have any good ideas for a workaround?
>>>> Best
>>>> Michael
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev(a)lists.jboss.org
>>>>
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
10 years, 10 months
Building Keycloak from master
by Guy Davis
Good day,
I've been able to get the 1.1.0.Beta2 distribution running inside my JBoss
EAP 6.1alpha with the JBoss 7 adapter. However, I would like to try the
latest work related to identity brokering by building the master branch. I
couldn't find build instructions in the master checkout from Git, so tried
the following generic steps:
1. mvn compile --> Succeeded
2. mvn package --> Failed with test errors.
It would be great if you could point me to the steps to build master into a
distribution that I could then deploy into my local JBoss. I'm very much
looking forward to trying out the latest work.
Thanks much,
Guy
10 years, 10 months
Re: [keycloak-dev] Looking for a workaround...
by Michael Gerber
> ----- Original Message -----
>> From: "Michael Gerber" <gerbermichi(a)me.com>
>> To: "Stian Thorgersen" <stian(a)redhat.com>
>> Sent: Monday, January 26, 2015 2:10:59 PM
>> Subject: Re: [keycloak-dev] Looking for a workaround...
>> ----- Original Message -----
>> From: "Michael Gerber" <gerbermichi(a)me.com>
>> To: keycloak-dev(a)lists.jboss.org
>>
>> Sent: Monday, January 26, 2015 1:37:53 PM
>> Subject: [keycloak-dev] Looking for a workaround...
>> Hi all,
>> I receive a lot of bug reports from our test team because of the following
>> two issues:
>> - Reset password leads to 400 Bad Request (
>> https://issues.jboss.org/browse/KEYCLOAK-1014 )
>> This is a tricky one - we can't ignore the state variable as that would make
>> it vulnerable.
>> We could probably come up with an alternative way to generate and verify
>> state variable though. Could be a HMAC for example.
>> So you would remove the state cookie?
>
> It could potentially be a solution - I started a separate thread on keycloak-dev to discuss this.
>
>> - Login attempt after "Login user action lifespan" leads to "Invalid username
>> or password." ( https://issues.jboss.org/browse/KEYCLOAK-1015 )
>> I agree that the error message is not very good, but I disagree with removing
>> the expiration. Why not increase it to say 30 min? That's probably a more
>> sensible timeout for reset password as well.
>> I prefer an expiration of 5 min for the password update process, but thats a
>> bit short for the authentication or password reset process.
>> I think the best solution would be different expiration times for the
>> different processes, wouldn't it?
>
> Maybe - we do try to keep configuration options to a minimum as these introduce complexity as well as potentials for bug/security issues.
I totaly understand that.
You have currently the following actions:
OAUTH_GRANT,
CODE_TO_TOKEN,
VERIFY_EMAIL,
UPDATE_PROFILE,
CONFIGURE_TOTP,
UPDATE_PASSWORD,
RECOVER_PASSWORD,
AUTHENTICATE,
SOCIAL_CALLBACK
And it doesn't make sense to have a different conffiguration for every one...
But maybe we can group it into different groups?
>
>
>> Do you have any good ideas for a workaround?
>> Best
>> Michael
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev(a)lists.jboss.org
>>
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
10 years, 10 months
