Keycloak 1.1.0.Final Released
by Stian Thorgersen
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
11 years
Keycloak 1.1.0.Final Admin Console Refresh every 5sec
by Nicholas Padilla
Hello All,
I have just downloaded the 1.1.0.Final release and found that every 5
seconds the admin console browser page refreshes. This is, I think,
preventing me from adding my realm.json export file. I am
using keycloak-appliance-dist-all-1.1.0.Final. Please advise.
As a side note, I was trying to see if the 1.1.0.Final release correctly
handled the KEYCLOAK_RESOURCE role added to the Oauth Client for one of my
realms. Since the usage of this client is trusted, so want to not have to
grant access to the resources every time for the client. There is nothing
in the documentation on how to set that up, only in the Login Algorithm
page on the github wiki. Please advise as how to use this feature.
Thanks!
Nicholas Padilla
www.monstersoftwarellc.com
“Problems cannot be solved by the same level of thinking that created them.”
“Learn from yesterday, live for today, hope for tomorrow. The important
thing is not to stop questioning.
<http://thinkexist.com/quotation/learn_from_yesterday-live_for_today-hope_...>
”
Albert Einstein <http://thinkexist.com/quotes/albert_einstein/>
11 years
aggregate modules
by Bill Burke
Hey,
I was thinking of having a few aggregate modules instead of having one
jboss-deployment-structure.xml that includes everything (50+ modules).
keycloak-server - includes base SPIs and keycloak-providers module
keycloak-adapter
keycloak-providers - includes JPA and infinispan providers by default
keycloak-mongo-providers - all stuff that uses mongo
keycloak-jpa-providers - all stuff that uses jpa
keycloak-infinispan-providers - all stuff that uses infinispan
keycloak-social-plugins - all social provider plugins
This way, if dependencies need to be added/removed/modified, you don't
have to edit the WAR.
Sorry I've taken so long... A lot of distractions this week.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
11 years
Automatic tests on push and PRs to Keycloak
by Stian Thorgersen
All,
Travis CI is now running tests automatically when there's a new push or PR to Keycloak. The results can be seen here https://travis-ci.org/keycloak/keycloak, but Travis also adds the status of the tests to each PRs comment section.
This only tests JDK7 and H2 in-mem, so we still need Jenkins for that. I've changed Jenkins to not run any tests on pushes, but instead it runs all tests every 24h.
11 years
Re: [keycloak-dev] Rest password can cause cookie not found
by Michael Gerber
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.
>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
11 years
Intermittent test failures in SyncProvidersTest.testLDAPSync and CookieTokenStoreAdapterTest.testTokenInCookieRefresh
by Stian Thorgersen
SyncProvidersTest.testLDAPSync and CookieTokenStoreAdapterTest.testTokenInCookieRefresh are failing for me once in a while. Also fails on Jenkins.
Failed tests:
SyncProvidersTest.testLDAPSync:142->assertUserImported:191 expected:<User5FN[Updated]> but was:<User5FN[]>
CookieTokenStoreAdapterTest.testTokenInCookieRefresh:110 Values should be different. Actual: eyJhbGciOiJSUzI1NiJ9.eyJzdWIiOiJiMTBlMjVlNS1mYTIyLTQwMjgtODg0Ny1mYTU4OWMxNzI1NjUiLCJuYW1lIjoiQmlsbCBCdXJrZSIsImVtYWlsIjoiYmJ1cmtlQHJlZGhhdC5jb20iLCJzdWJqZWN0IjoiYjEwZTI1ZTUtZmEyMi00MDI4LTg4NDctZmE1ODljMTcyNTY1IiwiZ2l2ZW5fbmFtZSI6IkJpbGwiLCJmYW1pbHlfbmFtZSI6IkJ1cmtlIiwicHJlZmVycmVkX3VzZXJuYW1lIjoiYmJ1cmtlQHJlZGhhdC5jb20iLCJlbWFpbF92ZXJpZmllZCI6ZmFsc2UsImp0aSI6IjBlMWI0Mzc4LWVjMGQtNDIzMS04NmU4LWI1YjNkYjA0NWNkNiIsImV4cCI6MTQyMjI2MzY0NCwibmJmIjowLCJpYXQiOjE0MjIyNjM2NDEsImlzcyI6ImRlbW8iLCJhdWQiOiJjdXN0b21lci1jb29raWUtcG9ydGFsIiwic3ViIjoiYjEwZTI1ZTUtZmEyMi00MDI4LTg4NDctZmE1ODljMTcyNTY1IiwiYXpwIjoiY3VzdG9tZXItY29va2llLXBvcnRhbCIsInNlc3Npb25fc3RhdGUiOiIwNjBmM2FjYy1jZDkxLTQwZTUtOTEzOS1lODRlMTNiMmY3MDkiLCJhbGxvd2VkLW9yaWdpbnMiOlsiaHR0cDovL2xvY2FsaG9zdDo4MDgxIl0sInJlYWxtX2FjY2VzcyI6eyJyb2xlcyI6WyJ1c2VyIl19LCJyZXNvdXJjZV9hY2Nlc3MiOnsiYWNjb3VudCI6eyJyb2xlcyI6WyJtYW5hZ2UtYWNjb3VudCJdfX19.Zzdkcx-LbBPtX_xCGjxBT2d8VOzwSP8i8XdiSsfpOotPGN0D7aiehb3QrvXjYcFOMgkutWNMfZxeNcJ9iN3kxcV7IA6AYchVPLo-WX1fUmRiUbpghophQA5pjbxB3Riqn5W0G6A_zFvkPRPQohXeiO_Wq0Ao_mBQGvhZg1RN0u0@eyJhbGciOiJSUzI1NiJ9.eyJuYW1lIjoiQmlsbCBCdXJrZSIsImVtYWlsIjoiYmJ1cmtlQHJlZGhhdC5jb20iLCJnaXZlbl9uYW1lIjoiQmlsbCIsImZhbWlseV9uYW1lIjoiQnVya2UiLCJwcmVmZXJyZWRfdXNlcm5hbWUiOiJiYnVya2VAcmVkaGF0LmNvbSIsImVtYWlsX3ZlcmlmaWVkIjpmYWxzZSwianRpIjoiNDk0OGYzNjktMGJmOS00MTA0LTg3ZjUtZGIzYWExZGE0Nzg0IiwiZXhwIjoxNDIyMjYzNjQ0LCJuYmYiOjAsImlhdCI6MTQyMjI2MzY0MSwiaXNzIjoiZGVtbyIsImF1ZCI6ImN1c3RvbWVyLWNvb2tpZS1wb3J0YWwiLCJzdWIiOiJiMTBlMjVlNS1mYTIyLTQwMjgtODg0Ny1mYTU4OWMxNzI1NjUiLCJhenAiOiJjdXN0b21lci1jb29raWUtcG9ydGFsIn0.m6n2f2uJUPapm3L73PgtB0Lqyqi7dZgzI0G_9-X7G9DUq0dB-h5GJVezfLmVlESjuw2K7Jn3urEwjD_gTShecEDGnJeSfi-EYRbBQvolcATapT8wN7-LabP95MdIH3ustnjQExhXNYxGG0QlA1c4oA9OebLzG-SX314U5Ha6-OQ@eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiJlN2FkMzEyNC1lNzk0LTRiMDEtYTAxOS1mN2NjODQzNmZiYTIiLCJleHAiOjE0MjIyNjU0NDEsIm5iZiI6MCwiaWF0IjoxNDIyMjYzNjQxLCJpc3MiOiJkZW1vIiwic3ViIjoiYjEwZTI1ZTUtZmEyMi00MDI4LTg4NDctZmE1ODljMTcyNTY1IiwidHlwIjoiUkVGUkVTSCIsImF6cCI6ImN1c3RvbWVyLWNvb2tpZS1wb3J0YWwiLCJzZXNzaW9uX3N0YXRlIjoiMDYwZjNhY2MtY2Q5MS00MGU1LTkxMzktZTg0ZTEzYjJmNzA5IiwicmVhbG1fYWNjZXNzIjp7InJvbGVzIjpbInVzZXIiXX0sInJlc291cmNlX2FjY2VzcyI6eyJhY2NvdW50Ijp7InJvbGVzIjpbIm1hbmFnZS1hY2NvdW50Il19fX0.prz4dbCq66DqnpAudzfcghuYje30D96MSuVWqk9pIVVmx5-4qMIDCfoS3hbeJpV98OYlRHSpKBQI-FTTWEm-mWKBY30SAzutbwbf7nXG3TuF5-lId3tNsc_tA72XW9HoEAW9_AVA8_w4L51D7D_x7RnFiRa7k2WDaRjlrF9nBQk
Anyone know why these are failing?
11 years
Rest password can cause cookie not found
by Stian Thorgersen
Someone reported https://issues.jboss.org/browse/KEYCLOAK-1014. In summary if you click on reset password, close the browser, then click the link in the email to recover password the state cookie won't be set.
Some suggestions on how to solve this:
* Store state variable in non-session cookie (with some sensible expiration 24h?)
* Generate/verify state using HMAC on the server-side instead of using uuid
* Improve error message on client side if state is not correct, basically asking user to re-login - can this be easily implemented in the app itself with the adapter today?
11 years
[KEYCLOAK-996] - Allow application to select provider
by Pedro Igor Silva
Hi,
KEYCLOAK-996 is about allowing clients to select an existing identity provider when sending an authentication request to the server. Initially, this is all about passing the IdP id and automatically redirect the user to its login page. Without even show KC's login page.
IMO instead of using an "idp_hint", like proposed in that JIRA, we may start using the "acr_values" parameter as defined by OIDC specs. I think this parameter better fits the purpose and will allow us to support LoAs in the future as well.
The acr value in this case would be something like "idp-X", where X is the id of the identity provider.
What do you think ?
Regards.
Pedro Igor
11 years
