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
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
Re: [keycloak-dev] [keycloak-user] Keycloak 1.1.0.Final Released
by Stian Thorgersen
----- Original Message -----
> From: "Raghu Prabhala" <prabhalar(a)yahoo.com>
> To: "Stian Thorgersen" <stian(a)redhat.com>
> Cc: "keycloak dev" <keycloak-dev(a)lists.jboss.org>, "keycloak-user" <keycloak-user(a)lists.jboss.org>
> Sent: Friday, 30 January, 2015 2:44:14 PM
> Subject: Re: [keycloak-user] Keycloak 1.1.0.Final Released
>
> Great. Looking forward to the 1.2 Beta version.
> Regarding the system account support, from my perspective, it is very
> important because we have thousands of applications that interact with each
> other using system accounts (authentication with Kerberos with keytabs) and
> till we have that functionality, we will not be able to consider Keycloak as
> a SSO solution even though it is coming out to be a good product. The sooner
> we have it, the better. Hopefully, even other users will pitch in to request
> that functionality so that you can bump it up in your priority list.
> Thanks once again.Raghu
For your use-case would it have to be Kerberos? Only options we've been considering are certificates and jwt/jws.
> From: Stian Thorgersen <stian(a)redhat.com>
> To: Raghu Prabhala <prabhalar(a)yahoo.com>
> Cc: keycloak dev <keycloak-dev(a)lists.jboss.org>; keycloak-user
> <keycloak-user(a)lists.jboss.org>
> Sent: Friday, January 30, 2015 2:10 AM
> Subject: Re: [keycloak-user] Keycloak 1.1.0.Final Released
>
>
>
> ----- Original Message -----
> > From: "Raghu Prabhala" <prabhalar(a)yahoo.com>
> > To: "Stian Thorgersen" <stian(a)redhat.com>
> > Cc: "keycloak dev" <keycloak-dev(a)lists.jboss.org>, "keycloak-user"
> > <keycloak-user(a)lists.jboss.org>
> > Sent: Thursday, January 29, 2015 6:44:11 PM
> > Subject: Re: [keycloak-user] Keycloak 1.1.0.Final Released
> >
> > Congrats Keycloak team. A great deal of features in this release - really
> > like SAML and clustering.
> >
> > But what I am really looking for is the next release as we need all the
> > features you listed -any tentative dates for the beta version?
>
> We might do a beta soon, but that'll only include identity brokering. The
> other features will be at least a month away.
>
> >
> > The functionality provided so far seems to be targeted toward users
> > accounts.
> > When can we expect support for System accounts (with diff auth mechanisms
> > like certificates, Kerberos etc?
>
> Some time this year we aim to have system accounts with certificates, it'll
> depend on priorities. We don't have any plans to support Kerberos
> authentication with system accounts, but maybe that makes sense to add as
> well.
>
>
>
> >
> > Thanks,
> > Raghu
> >
> > Sent from my iPhone
> >
> > > On Jan 29, 2015, at 2:11 AM, Stian Thorgersen <stian(a)redhat.com> wrote:
> > >
> > > The Keycloak team is proud to announce the release of Keycloak
> > > 1.1.0.Final.
> > > Highlights in this release includes:
> > >
> > > * SAML 2.0
> > > * Clustering
> > > * Jetty, Tomcat and Fuse adapters
> > > * HTTP Security Proxy
> > > * Automatic migration of db schema
> > >
> > > We’re already started working on features for the next release. Some
> > > exiting features coming soon includes:
> > >
> > > * Identity brokering
> > > * Custom user profiles
> > > * Kerberos
> > > * OpenID Connect interop
> > >
> > > _______________________________________________
> > > keycloak-user mailing list
> > > keycloak-user(a)lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/keycloak-user
> >
>
>
10 years, 10 months
Re: [keycloak-dev] Rest password can cause cookie not found
by Michael Gerber
Am 27. Januar 2015 um 10:49 schrieb Stian Thorgersen <stian(a)redhat.com>:
----- Original Message -----
From: "Michael Gerber" <gerbermichi(a)me.com>
To: "Bill Burke" <bburke(a)redhat.com>
Cc: "Stian Thorgersen" <stian(a)redhat.com>, keycloak-dev(a)lists.jboss.org
Sent: Tuesday, January 27, 2015 10:33:09 AM
Subject: Re: [keycloak-dev] Rest password can cause cookie not found
Am 26. Januar 2015 um 20:49 schrieb Bill Burke <bburke(a)redhat.com>:
>
>
> On 1/26/2015 1:31 PM, Michael Gerber wrote:
>>> Am 26.01.2015 um 18:36 schrieb Bill Burke <bburke(a)redhat.com
>>>
>>> <mailto:bburke@redhat.com>>:
>>> On 1/26/2015 12:12 PM, Michael Gerber wrote:
>>>>> Am 26.01.2015 um 16:54 schrieb Bill Burke <bburke(a)redhat.com
>>>>>
>>>>> <mailto:bburke@redhat.com>>:
>>>>>> On 1/26/2015 8:45 AM, Stian Thorgersen wrote:
>>>>>> ----- Original Message -----
>>>>>>> From: "Bill Burke" <bburke(a)redhat.com <mailto:bburke@redhat.com>>
>>>>>>> To: keycloak-dev(a)lists.jboss.org
>>>>>>> <mailto:keycloak-dev@lists.jboss.org>
>>>>>>> Sent: Monday, January 26, 2015 2:27:30 PM
>>>>>>> Subject: Re: [keycloak-dev] Rest password can cause cookie not found
>>>>>>> Wouldn't this work?
>>>>>>> 1) store "state" of state cookie in user session.
>>>>>>> 2) embed user session and state of state cookie in URL
>>>>>>> Of course this screws up your "shorter URL" crusade.
>>>>>> I'm not following - the problem isn't remembering the state
>>>>>> variable in Keycloak, that's already sorted as we already store all
>>>>>> the query params passed by the client in the client session (state,
>>>>>> redirect_uri, etc). The problem is storing it on the adapter side.
>>>>> I think I get it...
>>>>> 1. Send email
>>>>> 2. Close browser
>>>>> 3. Open browser
>>>>> 4. Click email link
>>>>> 5. Reset password
>>>>> 6. Redirect back to app
>>>>> 7. App barfs because of state cookie
>>>>> Persistent state cookie sounds like cleanest and simplest solution. I
>>>>> just worry we'll introduce different bugs, or if we're opening up some
>>>>> kind of security hole. Maybe I'm just paranoid.
>>>> That doesn't work if the user uses two different browsers. This is
>>>> the case in a lot of companies (at least in Switzerland :)) where the
>>>> users are forced to use ie (default) but rather work with firefox.
>>> Unless we extend the protocol, or don’t redirect from the email, I
>>> don’t see a fix.
>> If the password reset process would redirect without the code and state
>> param, than the adapter would redirect back to the keycloak, and
>> keycloak can authenticate the user with its identity cookie…
>> But I don’t know if that is ok with the protocol.
>
> So maybe have a session cookie that is set by the auth server. If that
> cookie is set when clicking the email url, redirect with code, if not,
> redirect without it.
>
That sounds good, what do the other think about this fallback option?
I can update the JIRA issue if anybody is happy with that solution.
I'm happy with the idea of setting a session cookie so we can detect if a user is using the same browser to complete the flow. However, I don't think we should redirect back to the application.
In this case the user most likely wants to use a different browser for the application. For example a user uses Firefox to open the application, click on recover password, but then due to company policies IE is registered as the default OS browser so links in emails are opened in IE instead. In this case the user wants to close IE after resetting the password and go back to Firefox to use the application.
In the case the user is completing the password reset flow in a different browser it would be better to update the password, make sure no identity cookie or user session is created in the new browser, then just display a message "Your password has been updated".
Why do you want to make sure that no identity cookie is generated?
Wouldn't it be nice to generate the cookie and display a message to the user with a link to the desired redirect uri?
So, the user can still redirect to the uri without a login?
I read that you want to release 1.1.0 Final in the next view days. So I guess this bug/feature will be implemented in 1.2.0?
>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
10 years, 10 months
Direct links to pages
by Christian Beikov
Hello!
Quick question. Is there a way to directly link to the registration or
login page from a different page?
I tried the following but only get "Bad request" when submitting the form.
Registration:
/auth/realms/{realm-name}/tokens/registrations?redirect_uri=http%3A%2F%2Flocalhost%3A8080%2Fprotected&client_id=protected
Login:
/auth/realms/{realm-name}/tokens/login?redirect_uri=http%3A%2F%2Flocalhost%3A8080%2Fprotected&client_id=protected
--
Mit freundlichen Grüßen,
------------------------------------------------------------------------
*Christian Beikov*
10 years, 10 months
Re: [keycloak-dev] [keycloak-user] Keycloak 1.1.0.Final Released
by Stian Thorgersen
----- Original Message -----
> From: "Raghu Prabhala" <prabhalar(a)yahoo.com>
> To: "Stian Thorgersen" <stian(a)redhat.com>
> Cc: "keycloak dev" <keycloak-dev(a)lists.jboss.org>, "keycloak-user" <keycloak-user(a)lists.jboss.org>
> Sent: Thursday, January 29, 2015 6:44:11 PM
> Subject: Re: [keycloak-user] Keycloak 1.1.0.Final Released
>
> Congrats Keycloak team. A great deal of features in this release - really
> like SAML and clustering.
>
> But what I am really looking for is the next release as we need all the
> features you listed -any tentative dates for the beta version?
We might do a beta soon, but that'll only include identity brokering. The other features will be at least a month away.
>
> The functionality provided so far seems to be targeted toward users accounts.
> When can we expect support for System accounts (with diff auth mechanisms
> like certificates, Kerberos etc?
Some time this year we aim to have system accounts with certificates, it'll depend on priorities. We don't have any plans to support Kerberos authentication with system accounts, but maybe that makes sense to add as well.
>
> Thanks,
> Raghu
>
> Sent from my iPhone
>
> > On Jan 29, 2015, at 2:11 AM, Stian Thorgersen <stian(a)redhat.com> wrote:
> >
> > The Keycloak team is proud to announce the release of Keycloak 1.1.0.Final.
> > Highlights in this release includes:
> >
> > * SAML 2.0
> > * Clustering
> > * Jetty, Tomcat and Fuse adapters
> > * HTTP Security Proxy
> > * Automatic migration of db schema
> >
> > We’re already started working on features for the next release. Some
> > exiting features coming soon includes:
> >
> > * Identity brokering
> > * Custom user profiles
> > * Kerberos
> > * OpenID Connect interop
> >
> > _______________________________________________
> > keycloak-user mailing list
> > keycloak-user(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-user
>
10 years, 10 months
Follow-up blog posts for 1.1.0.Final release
by Stian Thorgersen
Over the next few weeks we should do follow-up blog posts on the major new features in 1.1, which would be:
* SAML 2.0
* Clustering (Stian)
* Adapter clustering (Marek)
* New adapters
* HTTP Security Proxy
* Automatic migration of db schema (Stian)
Any volunteers for those without a name already associated with them?
10 years, 10 months
