Keycloak 1.5.1 Released
by Stian Thorgersen
We've just released Keycloak 1.5.1. This release contains a moderate impact
security fix and we recommend everyone that are currently using 1.5.0 to
upgrade as soon as possible. The security issue does not affect older
releases.
10 years
1.7 release
by Stian Thorgersen
I'm hoping to tag 1.7 on Friday and release on Monday.
Are there any outstanding issues not already in JIRA? We have quite a lot
of outstanding issues (~33) most of these are minor bugs.
10 years
i18n/l10n: English text in java code
by Stan Silvert
Marko brought this to my attention yesterday. For some things, we
dynamically create UI. In this case, the java code contains the English
text and it needs to be localized. Luckily, the solution was pretty
straightforward. We just replace the English text with a key into the
message bundle. The html template that displays this text already pulls
from an Angular scope so we just leave that alone and pass it through
the |translate filter. You do need to also add the double-colon.
One nice side effect is that if the key is not found in the bundle then
the output of the translate filter is the unchanged text. This means
that any code which has not converted to using bundle keys will still
work as expected. And, any third-party providers can just pass in
plain text if they don't care about l10n. If they ever do care about
l10n we will just need to provide a means for them to add key/value
pairs to the resource bundles.
Here is an example for anyone who needs to localize English text
embedded in java:
https://github.com/ssilvert/keycloak/commit/c9437595b70810c4472325373dd88...
Stan
10 years
Support for SSO bridge with shared user base
by Vlastimil Elias
Hi,
I'd like to implement SSO bridge between Keycloak used for our website,
and other SAML 2 based SSO server used by another website.
Both SSO servers share common user base (user federation provider in
keycloak against same user store as the SAML SSO server).
What I want to achieve is that once user is logged in on other SAML SSO
server and then comes to Keycloak site I'd like to login him there
automatically.
What I can do is to configure SAML Identity Provider in Keycloak and
enable "Authenticate By Default" for it. But I think this will always
lead to user creation conflict in Keycloak as we share user base. I have
to somehow force this "SAML Identity Provider" in keycloak to directly
use existing Keycloak users instead of creating new one and linking to them.
Is this somehow achievable in Keycloak 1.5, eg. by development of some
extension? From what I know I think it s not achievable and feature must
be coded into keycloak core.
And one other question ;-)
When "Authenticate By Default" is used for some Identity Provider then I
believe that Keycloak redirects user's browser to this provider in
passive mode before showing own login page to get identity from it if
any. But what happen if the provider is unreachable? In this case user
finishes with erro page and is not able to login into Keycloak at all.
Is Keycloak able to detect provider failure and stop redirecting user
there?
Thanks in advance
Vlastimil
--
Vlastimil Elias
Principal Software Engineer
jboss.org Development Team
10 years
Realm setting for email editable?
by Joakim Löfgren
Hey guys,
I want to duplicate the "Edit username" setting under the "Login" tab but
for email.
What do you think? Is it a reasonable feature to implement?
Sincerely,
Joakim
10 years
Re: [keycloak-dev] id_token_hint
by Michael Gerber
Ok, so I probably misunderstood it.
I thought it's the reverse of the logout, where you can use any id token of a logged in user to log him out.
Am 12. Oktober 2015 um 08:21 schrieb Stian Thorgersen <sthorger(a)redhat.com>:
I need some time to look into the use of id_token_hint as I'm not sure I fully understand it. From what I've read so far I don't think the user should be authenticated from the id_token_hint so no authenticator should be required. It's only about checking the current logged-in user and seeing if it's the same user has the application expects.
On 11 October 2015 at 17:34, Michael Gerber <gerbermichi(a)me.com> wrote:
I’ve created a jira task for that:
https://issues.jboss.org/browse/KEYCLOAK-1949
I already did an implementation proposal of that task, what do you think of it?
https://github.com/gerbermichi/keycloak/commit/0ef36f0ac446fcf70272f2aed0...
On 09.10.2015, at 07:46, Michael Gerber <gerbermichi(a)me.com> wrote:
As far as I understand it, we just have to create a new authenticator, check for the id_token_hint, if it is valid than we set the authenticated user, otherwise we send attempted.
I can create a PR for that if it is that simple ;)
Am 09. Oktober 2015 um 07:41 schrieb Stian Thorgersen <sthorger(a)redhat.com>:
It wasn't on our road map, but it looks easy to add
On 9 October 2015 at 07:16, Michael Gerber <gerbermichi(a)me.com> wrote:
Hi,
Do you have any plans to include the id_token_hint in the near future?
id_token_hintOPTIONAL. ID Token previously issued by the Authorization Server being passed as a hint about the End-User's current or past authenticated session with the Client. If the End-User identified by the ID Token is logged in or is logged in by the request, then the Authorization Server returns a positive response; otherwise, it SHOULD return an error, such as login_required. When possible, an id_token_hint SHOULD be present when prompt=none is used and an invalid_request error MAY be returned if it is not; however, the server SHOULD respond successfully when possible, even if it is not present. The Authorization Server need not be listed as an audience of the ID Token when it is used as an id_token_hint value.If the ID Token received by the RP from the OP is encrypted, to use it as an id_token_hint, the Client MUST decrypt the signed ID Token contained within the encrypted ID Token. The Client MAY re-encrypt the signed ID token to the Authentication Server using a key that enables the server to decrypt the ID Token, and use the re-encrypted ID token as the id_token_hint value.
Best
Michael
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
10 years
Re: [keycloak-dev] id_token_hint
by Michael Gerber
As far as I understand it, we just have to create a new authenticator, check for the id_token_hint, if it is valid than we set the authenticated user, otherwise we send attempted.
I can create a PR for that if it is that simple ;)
Am 09. Oktober 2015 um 07:41 schrieb Stian Thorgersen <sthorger(a)redhat.com>:
It wasn't on our road map, but it looks easy to add
On 9 October 2015 at 07:16, Michael Gerber <gerbermichi(a)me.com> wrote:
Hi,
Do you have any plans to include the id_token_hint in the near future?
id_token_hintOPTIONAL. ID Token previously issued by the Authorization Server being passed as a hint about the End-User's current or past authenticated session with the Client. If the End-User identified by the ID Token is logged in or is logged in by the request, then the Authorization Server returns a positive response; otherwise, it SHOULD return an error, such as login_required. When possible, an id_token_hint SHOULD be present when prompt=none is used and an invalid_request error MAY be returned if it is not; however, the server SHOULD respond successfully when possible, even if it is not present. The Authorization Server need not be listed as an audience of the ID Token when it is used as an id_token_hint value.If the ID Token received by the RP from the OP is encrypted, to use it as an id_token_hint, the Client MUST decrypt the signed ID Token contained within the encrypted ID Token. The Client MAY re-encrypt the signed ID token to the Authentication Server using a key that enables the server to decrypt the ID Token, and use the re-encrypted ID token as the id_token_hint value.
Best
Michael
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
10 years
Adding descriptive names for realms and roles
by Thomas Raehalme
Hi!
The name of a realm or a role is also its identifier. I would like to be
able to use a bit more descriptive names, but at the same time I don't want
them to be used in URLs or when testing for a presence of a role.
What do you think would it be possible for realms and roles to have both id
and a name?
Best regards,
Thomas
10 years, 1 month
Mongo Replica Sets
by Carsten Saathoff
Hi all,
we are currently setting up a production system that uses keycloak as the
Identity Provider. We use mongodb as the database for keycloak (since this
is our main database), but require keycloak to also handle mongodb replica
sets appropriately. Currently, when the primary changes in a mongo replica
set, keycloak stops working, since it only connects to a single instance.
I have a version of keycloak that uses a mongodb:// uri[1] to specify the
mongo connection parameters in the keycloak configuration file. Since
mongodb:// uris are a standard way of obtaining a mongo client, this
naturally supports replica sets. The patch is only a couple of lines and
seems to work. The only issue I have is that the MongoDB update seems to
be broken in master currently. But this is also the case when I build
keycloak without my patch, so I assume this to be an unrelated issue.
The commit is available in my keycloak fork:
https://github.com/kodemaniak/keycloak/commit/6741dffe38c9c8d9fd8ca1e92cb...
Only the setup of the operational attributes is still missing for the
configuration via uri, but it can easily be added.
I would like to get this somehow into an official release, since I think
that supporting replica sets is crucial in order to use keycloak with
mongo in a production setup. Personally I think that specifying mongo
connection parameters via mongodb:// uris is the most convenient way and
it's standardized. So it could even be the only way of specifying the
connection details IMHO.
Since in the contribution section it's encouraged to first discuss such
ideas on this mailing list prior to sending a pull request, I am sending
this mail to receive any feedback.
best
Carsten
[1] http://docs.mongodb.org/manual/reference/connection-string/
--------------------------------------------------------------------------------------------------------------------------------------------
Carsten Saathoff - KISTERS AG - Stau 75 - 26122 Oldenburg - Germany
Handelsregister Aachen, HRB-Nr. 7838 | Vorstand: Klaus Kisters, Hanns Kisters | Aufsichtsratsvorsitzender: Dr. Thomas Klevers
Phone: +49 441 93602 -257 | Fax: +49 441 93602 -222 | E-Mail: Carsten.Saathoff(a)kisters.de | WWW: http://www.kisters.de
--------------------------------------------------------------------------------------------------------------------------------------------
Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet.
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
10 years, 1 month
