June 2017 - keycloak-dev - Jboss List Archives

Review Chinese translations

by Stian Thorgersen

Can someone please review PR for Chinese translations: https://github.com/keycloak/keycloak/pull/4251

8 years, 3 months

1
0
0 / 0

Re: [keycloak-dev] Proposal of using existing authentication server on behalf of keycloak browser-based authentication

by 乗松隆志 / NORIMATSU，TAKASHI

I need to use the authentication server without OIDC/OAuth2/SAMLv2 implementation as an external IdP, in order to integrate existing authentication system. (some commercial products supports such the case) I consulted identity broker's section in keycloak's manual below and found that if I use this feature the external IdP must support OIDC or SAMLv2. https://keycloak.gitbooks.io/documentation/server_admin/topics/identity-b... Therefore, I realized it by using redirect based authentication flows. Can identity Brokering can support such the case? Aside from this, I'd like to contribute it to Community extensions and examples. Best Regards Takashi Norimatsu Hitachi, Ltd. --- From: Stian Thorgersen [mailto:sthorger@redhat.com] Sent: Tuesday, June 27, 2017 5:52 PM To: 乗松隆志 / NORIMATSU，TAKASHI Cc: keycloak-dev(a)lists.jboss.org Subject: [!]Re: [keycloak-dev] Proposal of using existing authentication server on behalf of keycloak browser-based authentication I'm not in favour of adding this. If it's using redirect based authentication flows it should be done through identity brokering, not authentication flows. It's also a very complex example that we don't want to maintain. We've also in the process of moving all examples away from the main Keycloak repository into a separate quickstart repository. On 27 June 2017 at 08:54, 乗松隆志 / NORIMATSU，TAKASHI <takashi.norimatsu.ws(a)hitachi.com> wrote: Hello. Previously, I had proposed the feature of delegating authentication to an external authentication server on behalf of keycloak's browser-based authentication mechanism. I've integrated this feature to keycloak's "examples" packages and send PR (https://github.com/keycloak/keycloak/pull/4260). Hope this PR is reviewed and merged as an example for combining some providers to customize keycloak. Detailed description of this feature is mentioned below. https://github.com/Hitachi/PoV-keycloak-authentication-delegation I am now engaging in integrating this feature to keycloak as product-base default providers, but encounter technical problems about writing arquillian. Would someone tell me how to resolve this problem? [Problem] - I could not find how to run an external authentication server(application running on wildfly 10) during each arquillian test cases. After resolving this problem and writing and running arquillian test cases, I'll send PR for this feature as product-base default providers. Best Regards Takashi Norimatsu Hitachi, Ltd. _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

8 years, 3 months

2
1
0 / 0

Adding a validate password endpoint in the Admin API

by Wim Vandenhaute

Hello list, Via an admin portal of a customer I am working for, they provide a feature where an admin can edit the user's data, including setting a new password. For the sake of atomicity, all update steps first go through a series of validations for all modified data before actually committing the changes and (if needed) updating the keycloak password At the moment, there is no way to pre-update do a validity check of the updated password against keycloak's configured password policy(ies) Therefor I would propose to have a validate-password endpoint in the Admin API. I've made a pull request already here: * https://github.com/keycloak/keycloak/pull/4229 Any thoughts on this? Kind regards, Wim

8 years, 3 months

3
7
0 / 0

Review Japanese PR

by Stian Thorgersen

There's a PR for fixes to the Japanese translations. Could someone review it please? https://github.com/keycloak/keycloak/pull/4245

8 years, 3 months

2
2
0 / 0

Re: [keycloak-dev] Proposal of using existing authentication server on behalf of keycloak browser-based authentication

by 乗松隆志 / NORIMATSU，TAKASHI

Hello. Previously, I had proposed the feature of delegating authentication to an external authentication server on behalf of keycloak's browser-based authentication mechanism. I've integrated this feature to keycloak's "examples" packages and send PR (https://github.com/keycloak/keycloak/pull/4260). Hope this PR is reviewed and merged as an example for combining some providers to customize keycloak. Detailed description of this feature is mentioned below. https://github.com/Hitachi/PoV-keycloak-authentication-delegation I am now engaging in integrating this feature to keycloak as product-base default providers, but encounter technical problems about writing arquillian. Would someone tell me how to resolve this problem? [Problem] - I could not find how to run an external authentication server(application running on wildfly 10) during each arquillian test cases. After resolving this problem and writing and running arquillian test cases, I'll send PR for this feature as product-base default providers. Best Regards Takashi Norimatsu Hitachi, Ltd.

8 years, 3 months

2
1
0 / 0

Review German PR

by Stian Thorgersen

Can someone please review fixes to the German translations in PR https://github.com/keycloak/keycloak/pull/4234?

8 years, 3 months

1
0
0 / 0

fine grain permissions merged

by Bill Burke

See https://issues.jboss.org/browse/KEYCLOAK-3444 It its currently limited to single realm administration. Can't define master realm fine grain permissions. It was too much of a pain. Also fixed the long standing issue of when admin with manage-users role could upgrade their management permissions. I'll be working on documentation in the next week or so and will get something in by 3.2 Final. Regards, Bill

8 years, 3 months

2
4
0 / 0

Usage of "aud" claim in access tokens

by Schuster Sebastian (INST/ESY1)

Hi everybody, While playing around with the authorization api and the photoz example I noticed the aud claim in the access token contained the client_id of the RP similar to the ID token. This was not quite what I expected. The client is the intended consumer of the ID token as per spec: “Audience(s) that this ID Token is intended for. It MUST contain the OAuth 2.0 client_id of the Relying Party as an audience value.” So everything is fine here. The consumer of the access token is in my opinion the resource server granting access based on content of the access token (in the case of opaque tokens, the client can’t even read the access token). Per JWT spec: “The "aud" (audience) claim identifies the recipients that the JWT is intended for. Each principal intended to process the JWT MUST identify itself with a value in the audience claim. If the principal processing the claim does not identify itself with a value in the "aud" claim then this claim is present, then the JWT MUST be rejected.” Therefore, for my access token of the photos example having the client id in the “aud” claim: { "jti": "ad02bc48-ee9c-4480-b8d2-ca57547c8026", "exp": 1498475985, "nbf": 0, "iat": 1498475685, "iss": "http://localhost:8180/auth/realms/photoz", "aud": "photoz-html5-client", "sub": "73c303f1-7088-4f09-85c3-bd39a736c833", "typ": "Bearer", "azp": "photoz-html5-client", "nonce": "02df304b-199b-4dd8-923d-9cf470d1129a", "auth_time": 1498475685, "session_state": "e202b205-15bd-43c8-9fbd-cd602d0708f0", "acr": "1", "allowed-origins": [ "*" ], "realm_access": { "roles": [ "uma_authorization", "user" ] }, "resource_access": { "photoz-restful-api": { "roles": [ "manage-albums" ] }, "account": { "roles": [ "manage-account", "manage-account-links", "view-profile" ] } }, "name": "Alice In Chains", "preferred_username": "alice", "given_name": "Alice", "family_name": "In Chains", "email": "alice(a)keycloak.org" } I would have expected an audience claim like “aud”:[“photoz-restful-api”, “account”, “http://localhost:8180/auth/realms/photoz”] (the first two for the resource servers defining the roles, the last one for the entire realm and the realm roles). What do you think? Best regards, Sebastian Mit freundlichen Grüßen / Best regards Sebastian Schuster Engineering and Support (INST/ESY1) Bosch Software Innovations GmbH | Schöneberger Ufer 89-91 | 10785 Berlin | GERMANY | www.bosch-si.com<http://www.bosch-si.com> Tel. +49 30 726112-485 | Fax +49 30 726112-100 | Sebastian.Schuster(a)bosch-si.com<mailto:Sebastian.Schuster@bosch-si.com> Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B Geschäftsführung: Dr.-Ing. Rainer Kallenbach, Michael Hahn

8 years, 3 months

3
3
0 / 0

Rehash password after each login

by Hynek Mlnarik

The o.k.credential.PasswordCredentialProvider.isValid() method in its end [1] rehashes and stores the credentials upon successful authentication. This has benefits in that whenever hashing algorithm or policy changes (e.g. number of iterations), after a login the user password would be stored again. If nothing changes, the password is at least rehashed with another salt. Actually, as the password policy/algorithm usually does not change too often, it also induces unnecessary network traffic: because a user invalidation sent to other nodes in cluster (and other DCs) after each successful login. One way to mitigate the issue is to invalidate the current encoded password only if the variant encoded using the same salt as original password and current password policy is different to the stored one. If occasional rehashing would be a must, it would be possible to update credentials after login with new hash only once in a given period of time (e.g. at most weekly, this can be determined from the password created date). WDYT? --Hynek [1] https://github.com/keycloak/keycloak/blob/master/services/src/main/java/o...

8 years, 3 months

2
2
0 / 0

Moving ClientInitialAccessModel from infinispan to db

by Marek Posolda

I've sent PR https://github.com/keycloak/keycloak/pull/4248 for move ClientInitialAccessModel from userSessionProvider (infinispan) to realm model (db). This has advantages like: - Client initial access tokens will remain persistent among server restarts - There won't be issues in cross-dc environment Regarding functionality, nothing is changed. Admin console and admin REST endpoints are still the same behaviour. There is still decrease of remainingCount during each client registration like was before. Only change is, that server restarts will just work :) I didn't add support for export/import of client initial access token models. Was thinking about possible issues like: - admin creates the initial token with 3 counters - Export is done - Then token is used to register 3 clients, which defacto make the token expired - After realm re-import, the token will be back again with 3 attempts, which is likely not what admin wants. Also I didn't add support for caching. Reason is, that there is just small amount of tokens. Also there is almost same amount of writes and reads to ClientInitialAccessModel as every client registration needs to decrease counter and update DB. With caching enabled, there will be lots of additional overhead needed to send invalidation message to all cluster nodes in all DCs during every write, which likely won't help with performance, but rather the opposite. WDYT? Marek

8 years, 3 months

2
1
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

keycloak-dev June 2017