From bburke at redhat.com  Mon Apr  2 18:16:19 2018
From: bburke at redhat.com (Bill Burke)
Date: Mon, 2 Apr 2018 18:16:19 -0400
Subject: [keycloak-dev] offline access permission incorrect?
Message-ID: <CABRXCmz9QQTC8TZYvcjnhskOiU=z0Vw8cfdm-DSkqKnvJn3v1Q@mail.gmail.com>

To enable offline access the user must have the offline access role
and the client must have that role in its scope...

This just doesn't seem right to me.  IMO, this shouldn't be something
you assign permission to a user.  Its solely a client permission and
should not be something role-based.  Instead the client should be
marked as allowing to ask for offline access and whether or not the
client must ask consent for this.

-- 
Bill Burke
Red Hat

From sebastien.vandamme at telemis.com  Tue Apr  3 03:31:23 2018
From: sebastien.vandamme at telemis.com (=?UTF-8?Q?S=C3=A9bastien_Vandamme?=)
Date: Tue, 3 Apr 2018 09:31:23 +0200
Subject: [keycloak-dev] keycloak-cli.bat failed to connect to the controller
 with SaslException DIGEST-MD5: Server rejected authentication
Message-ID: <CAM5Pytzdv7U96OhoMktgop1zfApAmien0tYZN9sPP+s9BB_x4g@mail.gmail.com>

 Hello,

I am in the process of installing Keycloak 3.4.3.Final and customize it
using scripts. I reuse scripts that I used on Keycloak 2.5.1 with success
but, on the new version, I run into strange problems.
All the command that I run that start with

keycloak-cli.bat --connect --controller=localhost:9990 --user=root
--password=somePwd

doesn't work anymore and displays the following error

Failed to connect to the controller:
Unable to authenticate against controller at localhost:9990:
Authentication failed: all available authentication mechanisms failed:
DIGEST-MD5: javax.security.sasl.SaslException: DIGEST-MD5: Server
rejected authentication

When I run the same command without the credentials

keycloak-cli.bat --connect --controller=localhost:9990

the connection work and I see

[standalone at localhost:9990 /]

When I connect directly via the browser on the url localhost:9990, it ask
me for a login and a password, I enter the ones given in the first command
and I can connect without any problem.

I read a lot of stuff on similar problems on the web but nothing solved my
problem. For example, my remoting configuration, that was a problem in some
case, seems right

<subsystem xmlns="urn:jboss:domain:remoting:4.0">
    <endpoint/>
    <http-connector name="http-remoting-connector"
connector-ref="default" security-realm="ApplicationRealm"/>
</subsystem>

In short, I'm stuck.
Does someone has any idea to help me ?

Thank you in advance for your help,

Seb

From sthorger at redhat.com  Tue Apr  3 05:20:03 2018
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 3 Apr 2018 11:20:03 +0200
Subject: [keycloak-dev] offline access tokens part 2
In-Reply-To: <CABRXCmzZ=B-FRpJcMT2QH3Ge=Wy3+MH=CeXo6_+0P0fdLy2o2g@mail.gmail.com>
References: <CABRXCmxVzbGs27X2Pg8mYW=o0q3BV9z8UoG39eJnbmh-n4Q5aQ@mail.gmail.com>
	<6833362f-c904-519d-4642-61a79087270d@redhat.com>
	<CABRXCmwRMO235OsvPKuAMKytU-3oOuoskupJbtE1sED7AL53zw@mail.gmail.com>
	<d1bc6868-2312-e4f1-2451-670d118add20@redhat.com>
	<CABRXCmx3hd_WR6Z5xWK89Qb6pswwAdnonWMMyjkQwN7c6mz41g@mail.gmail.com>
	<CAJgngAfH-zjhvWQd48k4NusdKpZDh2Rr3XmSp8oer5YGn4_DOQ@mail.gmail.com>
	<CABRXCmzZ=B-FRpJcMT2QH3Ge=Wy3+MH=CeXo6_+0P0fdLy2o2g@mail.gmail.com>
Message-ID: <CAJgngAdaORg6qyQZVXAUr6qU_0XTbFhqdDqQofT_J4pryaCh6Q@mail.gmail.com>

On 28 March 2018 at 16:24, Bill Burke <bburke at redhat.com> wrote:

> On Wed, Mar 28, 2018 at 12:58 AM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
> > Since my reply was ignored I'm going to repeat myself.
> >
> > I would rather have the option to override the expiration of access
> tokens
> > expiration on a per-client basis. We could allow clients to use the
> global
> > expiration, a client specific expiration or no expiration at all. When a
> JWT
> > has no expiration set the client should always use the token
> introspection
> > endpoint to validate the tokens.
> >
> > Perhaps also combine that with client scopes to make it possible for a
> > client to request one token with longer expiration for a specific
> use-case.
> > For instance if a client needs to invoke some background process that
> takes
> > longer than the regular access token.
> >
> > I think that approach will be simpler to implement and also cover more
> > use-cases.
> >
> > I don't see the need to have a different scope than what we have today.
> This
> > should be a config option on the client for the current offline scope.
> > There's no need to introduce a new non-common scope for this stuff.
> >
>
> FYI, didn't ignore you.  I replied to Marek's email first, got
> distracted before I could read and reply to yours.
>
> I think this is a reference token vs. non-reference token debate.
> Let's first talk about offline access tokens.  In thinking further on
> your suggestion, what about instead of per client expiration,
> shouldn't we instead have an "offline access token timeout"?  Access
> tokens created for  offline access should have this timeout, maybe
> default to "offline idle" timeout?  One thing we have to be sure of is
> that these offline access tokens are valid across server restarts.
>

It would definitively make sense to add an offline access token timeout. I
still think it would be useful to be able to override expirations for
specific clients.


>
> In retrospect, I mixed up offline access and the idea of a reference
> token.  I think whether an access token is a reference token or not is
> orthogonal to whether it is offline or not.  Reference tokens must
> always be validated.  Non-reference tokens can be used as bearer
> tokens without validation.  I think we should have a global switch on
> what the access token type should be by default, then allow clients to
> override.   You should also be able to separately configure whether a
> reference token should be used or not for offline and non-offline
> access.  In the future we might even want to offer one-time reference
> tokens that can only be validated once.  FYI:  all tokens in
> Kubernetes and Openshift are reference tokens (and offline).


> Reference tokens require validation and shouldn't be excepted ever for
> bearer token requests unless validated.  Using expiration time to
> determine the token type is not a good solution. Other than just being
> a hack, you remove the ability to have any expiration on the token.  I
> really prefer that reference tokens be completely opaque to the
> client.  A JWE IMO.
>

Yes, this all makes sense to me. So to summary to make sure we are on the
same page:

1. Add offline access token timeout that allows setting different
expiration for tokens for an offline session
2. Add support for an option on realm with override on clients to issue
JWTs or opaque tokens JWE. The latter requiring calling the token
introspection endpoint rather than simply inspecting the token directly

A few extensions we could consider:

3. Add ability to override token expiration for specific clients
4. A support for a reference tokens where the token is a short UUID and not
a long JWE. I believe when folks refer to reference tokens this is what
they refer to. This would probably require storing the token details in the
session or something




>
> --
> Bill Burke
> Red Hat
>

From sthorger at redhat.com  Tue Apr  3 05:21:05 2018
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 3 Apr 2018 11:21:05 +0200
Subject: [keycloak-dev] offline access permission incorrect?
In-Reply-To: <CABRXCmz9QQTC8TZYvcjnhskOiU=z0Vw8cfdm-DSkqKnvJn3v1Q@mail.gmail.com>
References: <CABRXCmz9QQTC8TZYvcjnhskOiU=z0Vw8cfdm-DSkqKnvJn3v1Q@mail.gmail.com>
Message-ID: <CAJgngAc_OM6G3deyGVbfAxkRC0zx6xCcnEdn4_ywBq61_vXtVA@mail.gmail.com>

+1

On 3 April 2018 at 00:16, Bill Burke <bburke at redhat.com> wrote:

> To enable offline access the user must have the offline access role
> and the client must have that role in its scope...
>
> This just doesn't seem right to me.  IMO, this shouldn't be something
> you assign permission to a user.  Its solely a client permission and
> should not be something role-based.  Instead the client should be
> marked as allowing to ask for offline access and whether or not the
> client must ask consent for this.
>
> --
> Bill Burke
> Red Hat
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sthorger at redhat.com  Tue Apr  3 05:21:54 2018
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 3 Apr 2018 11:21:54 +0200
Subject: [keycloak-dev] keycloak-cli.bat failed to connect to the
 controller with SaslException DIGEST-MD5: Server rejected authentication
In-Reply-To: <CAM5Pytzdv7U96OhoMktgop1zfApAmien0tYZN9sPP+s9BB_x4g@mail.gmail.com>
References: <CAM5Pytzdv7U96OhoMktgop1zfApAmien0tYZN9sPP+s9BB_x4g@mail.gmail.com>
Message-ID: <CAJgngAc5fXBDmvH33RqB-0edFZrtCBiNC1W479V2zz19mHpipA@mail.gmail.com>

Wrong list. Please use user mailing list for help. This mailing list is to
discuss development of Keycloak itself.

On 3 April 2018 at 09:31, S?bastien Vandamme <sebastien.vandamme at telemis.com
> wrote:

>  Hello,
>
> I am in the process of installing Keycloak 3.4.3.Final and customize it
> using scripts. I reuse scripts that I used on Keycloak 2.5.1 with success
> but, on the new version, I run into strange problems.
> All the command that I run that start with
>
> keycloak-cli.bat --connect --controller=localhost:9990 --user=root
> --password=somePwd
>
> doesn't work anymore and displays the following error
>
> Failed to connect to the controller:
> Unable to authenticate against controller at localhost:9990:
> Authentication failed: all available authentication mechanisms failed:
> DIGEST-MD5: javax.security.sasl.SaslException: DIGEST-MD5: Server
> rejected authentication
>
> When I run the same command without the credentials
>
> keycloak-cli.bat --connect --controller=localhost:9990
>
> the connection work and I see
>
> [standalone at localhost:9990 /]
>
> When I connect directly via the browser on the url localhost:9990, it ask
> me for a login and a password, I enter the ones given in the first command
> and I can connect without any problem.
>
> I read a lot of stuff on similar problems on the web but nothing solved my
> problem. For example, my remoting configuration, that was a problem in some
> case, seems right
>
> <subsystem xmlns="urn:jboss:domain:remoting:4.0">
>     <endpoint/>
>     <http-connector name="http-remoting-connector"
> connector-ref="default" security-realm="ApplicationRealm"/>
> </subsystem>
>
> In short, I'm stuck.
> Does someone has any idea to help me ?
>
> Thank you in advance for your help,
>
> Seb
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From Sebastian.Schuster at bosch-si.com  Tue Apr  3 10:20:58 2018
From: Sebastian.Schuster at bosch-si.com (Schuster Sebastian (INST/ESY1))
Date: Tue, 3 Apr 2018 14:20:58 +0000
Subject: [keycloak-dev] offline access tokens part 2
In-Reply-To: <CAJgngAdaORg6qyQZVXAUr6qU_0XTbFhqdDqQofT_J4pryaCh6Q@mail.gmail.com>
References: <CABRXCmxVzbGs27X2Pg8mYW=o0q3BV9z8UoG39eJnbmh-n4Q5aQ@mail.gmail.com>
	<6833362f-c904-519d-4642-61a79087270d@redhat.com>
	<CABRXCmwRMO235OsvPKuAMKytU-3oOuoskupJbtE1sED7AL53zw@mail.gmail.com>
	<d1bc6868-2312-e4f1-2451-670d118add20@redhat.com>
	<CABRXCmx3hd_WR6Z5xWK89Qb6pswwAdnonWMMyjkQwN7c6mz41g@mail.gmail.com>
	<CAJgngAfH-zjhvWQd48k4NusdKpZDh2Rr3XmSp8oer5YGn4_DOQ@mail.gmail.com>
	<CABRXCmzZ=B-FRpJcMT2QH3Ge=Wy3+MH=CeXo6_+0P0fdLy2o2g@mail.gmail.com>
	<CAJgngAdaORg6qyQZVXAUr6qU_0XTbFhqdDqQofT_J4pryaCh6Q@mail.gmail.com>
Message-ID: <00ecca46da2446fb96495c98f4cf7328@bosch-si.com>

I really like 3) because this might be a way of getting around having to do token signing externally in an HSM, depending on company regulations.

Btw. how about allowing to override token lifetimes also based on the involved roles/scopes? Lifetimes are essentially a security/efficiency tradeoff and for critical roles, I would really like to tune that tradeoff towards security.
That would probably be something in the line of creating a token with the minimum lifetime configured by realm/client/role....

Best regards,
Sebastian

Mit freundlichen Gr??en / Best regards

Dr.-Ing.  Sebastian Schuster

Engineering and Support (INST/ESY1) 
Bosch?Software Innovations?GmbH | Ullsteinstr. 128 | 12109 Berlin | GERMANY | www.bosch-si.com
Tel. +49 30 726112-485 | Fax +49 30 726112-100 | Sebastian.Schuster at bosch-si.com

Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B 
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten L?cke; Gesch?ftsf?hrung: Dr. Stefan Ferber, Michael Hahn 



-----Original Message-----
From: keycloak-dev-bounces at lists.jboss.org [mailto:keycloak-dev-bounces at lists.jboss.org] On Behalf Of Stian Thorgersen
Sent: Dienstag, 3. April 2018 11:20
To: Bill Burke <bburke at redhat.com>
Cc: keycloak-dev <keycloak-dev at lists.jboss.org>
Subject: Re: [keycloak-dev] offline access tokens part 2

On 28 March 2018 at 16:24, Bill Burke <bburke at redhat.com> wrote:

> On Wed, Mar 28, 2018 at 12:58 AM, Stian Thorgersen 
> <sthorger at redhat.com>
> wrote:
> > Since my reply was ignored I'm going to repeat myself.
> >
> > I would rather have the option to override the expiration of access
> tokens
> > expiration on a per-client basis. We could allow clients to use the
> global
> > expiration, a client specific expiration or no expiration at all. 
> > When a
> JWT
> > has no expiration set the client should always use the token
> introspection
> > endpoint to validate the tokens.
> >
> > Perhaps also combine that with client scopes to make it possible for 
> > a client to request one token with longer expiration for a specific
> use-case.
> > For instance if a client needs to invoke some background process 
> > that
> takes
> > longer than the regular access token.
> >
> > I think that approach will be simpler to implement and also cover 
> > more use-cases.
> >
> > I don't see the need to have a different scope than what we have today.
> This
> > should be a config option on the client for the current offline scope.
> > There's no need to introduce a new non-common scope for this stuff.
> >
>
> FYI, didn't ignore you.  I replied to Marek's email first, got 
> distracted before I could read and reply to yours.
>
> I think this is a reference token vs. non-reference token debate.
> Let's first talk about offline access tokens.  In thinking further on 
> your suggestion, what about instead of per client expiration, 
> shouldn't we instead have an "offline access token timeout"?  Access 
> tokens created for  offline access should have this timeout, maybe 
> default to "offline idle" timeout?  One thing we have to be sure of is 
> that these offline access tokens are valid across server restarts.
>

It would definitively make sense to add an offline access token timeout. I still think it would be useful to be able to override expirations for specific clients.


>
> In retrospect, I mixed up offline access and the idea of a reference 
> token.  I think whether an access token is a reference token or not is 
> orthogonal to whether it is offline or not.  Reference tokens must 
> always be validated.  Non-reference tokens can be used as bearer 
> tokens without validation.  I think we should have a global switch on 
> what the access token type should be by default, then allow clients to
> override.   You should also be able to separately configure whether a
> reference token should be used or not for offline and non-offline 
> access.  In the future we might even want to offer one-time reference 
> tokens that can only be validated once.  FYI:  all tokens in 
> Kubernetes and Openshift are reference tokens (and offline).


> Reference tokens require validation and shouldn't be excepted ever for 
> bearer token requests unless validated.  Using expiration time to 
> determine the token type is not a good solution. Other than just being 
> a hack, you remove the ability to have any expiration on the token.  I 
> really prefer that reference tokens be completely opaque to the 
> client.  A JWE IMO.
>

Yes, this all makes sense to me. So to summary to make sure we are on the same page:

1. Add offline access token timeout that allows setting different expiration for tokens for an offline session 2. Add support for an option on realm with override on clients to issue JWTs or opaque tokens JWE. The latter requiring calling the token introspection endpoint rather than simply inspecting the token directly

A few extensions we could consider:

3. Add ability to override token expiration for specific clients 4. A support for a reference tokens where the token is a short UUID and not a long JWE. I believe when folks refer to reference tokens this is what they refer to. This would probably require storing the token details in the session or something




>
> --
> Bill Burke
> Red Hat
>
_______________________________________________
keycloak-dev mailing list
keycloak-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev


From bburke at redhat.com  Tue Apr  3 11:02:50 2018
From: bburke at redhat.com (Bill Burke)
Date: Tue, 3 Apr 2018 11:02:50 -0400
Subject: [keycloak-dev] offline access tokens part 2
In-Reply-To: <00ecca46da2446fb96495c98f4cf7328@bosch-si.com>
References: <CABRXCmxVzbGs27X2Pg8mYW=o0q3BV9z8UoG39eJnbmh-n4Q5aQ@mail.gmail.com>
	<6833362f-c904-519d-4642-61a79087270d@redhat.com>
	<CABRXCmwRMO235OsvPKuAMKytU-3oOuoskupJbtE1sED7AL53zw@mail.gmail.com>
	<d1bc6868-2312-e4f1-2451-670d118add20@redhat.com>
	<CABRXCmx3hd_WR6Z5xWK89Qb6pswwAdnonWMMyjkQwN7c6mz41g@mail.gmail.com>
	<CAJgngAfH-zjhvWQd48k4NusdKpZDh2Rr3XmSp8oer5YGn4_DOQ@mail.gmail.com>
	<CABRXCmzZ=B-FRpJcMT2QH3Ge=Wy3+MH=CeXo6_+0P0fdLy2o2g@mail.gmail.com>
	<CAJgngAdaORg6qyQZVXAUr6qU_0XTbFhqdDqQofT_J4pryaCh6Q@mail.gmail.com>
	<00ecca46da2446fb96495c98f4cf7328@bosch-si.com>
Message-ID: <CABRXCmytNFH_3AevOgVSOULVzanF-VKyXBaE-=eLp8du_JdM1A@mail.gmail.com>

On Tue, Apr 3, 2018 at 10:20 AM, Schuster Sebastian (INST/ESY1)
<Sebastian.Schuster at bosch-si.com> wrote:
> I really like 3) because this might be a way of getting around having to do token signing externally in an HSM, depending on company regulations.
>
> Btw. how about allowing to override token lifetimes also based on the involved roles/scopes? Lifetimes are essentially a security/efficiency tradeoff and for critical roles, I would really like to tune that tradeoff towards security.
> That would probably be something in the line of creating a token with the minimum lifetime configured by realm/client/role....
>

So, each role, scope, protocol mapper could specify a token timeout?
The token issuer logic would just pick the smallest timeout based on
the roles, scopes, protocol mappers used to build the token?
All this would be a compeltely separate feature/PR/Jira.

Work should be broken up into:
* offline access token timeout for realm
* reference tokens
* per client timeouts
* per role, scope, protocol mapper timeouts.




-- 
Bill Burke
Red Hat

From thomas.darimont at googlemail.com  Wed Apr  4 05:07:50 2018
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Wed, 4 Apr 2018 11:07:50 +0200
Subject: [keycloak-dev] Client Scope naming
In-Reply-To: <0a29664822124858923a515a1e6c8847@bosch-si.com>
References: <a07feaadfdcd4aaeb82163c784041781@bosch-si.com>
	<6109ae10-65be-5c45-8a9e-bd4f79c034bc@redhat.com>
	<CAJrcDBd+ri5afu7BzSqz2jKQLiPimfsHuFtEYrOo7JNdD5hagA@mail.gmail.com>
	<b3ccbf66-4b32-7bdd-2f48-2b507f71810e@redhat.com>
	<CAJrcDBdjdP_9_0JeW8OTNHgXgLDB0QXagLeUPdZYnd4GqcN4FA@mail.gmail.com>
	<976022cb-b0ed-51e0-6754-955efee6675a@redhat.com>
	<CAJrcDBc-sfoBTWcHRY2sPGgUC8Too8wb3qNjuzcaHkvLY4B_BQ@mail.gmail.com>
	<56ee4c0a-2661-c4db-5844-8aef0afba7c9@redhat.com>
	<CAJrcDBdQMRtEuRJH3UOV1i0Qrn-H+XPJe84wNWAgALmuwZQyOg@mail.gmail.com>
	<f5629ef6ec93488b9b45562a81074f18@bosch-si.com>
	<CAJrcDBffBSDyjsMqHvm7F=jHgV4x5B_m0y94i8c8TRUQoEmcBw@mail.gmail.com>
	<58fc88ad-acab-e580-25f4-7849798173cd@redhat.com>
	<0a29664822124858923a515a1e6c8847@bosch-si.com>
Message-ID: <CAK-7U1jATq79gKbPTjXD0esLF5tPvd62t=eJ2VshQJkiT1kgwQ@mail.gmail.com>

Great discussion, I think many folks are looking forward to enhanced scope
support in Keycloak.

I also think that having scopes in the RefreshToken as well as the
AccessToken
structure is useful.

Some additional remarks:
* backwards compatibility
Changing the representation of the token structures might cause problems
for clients using an older version of a Keycloak adapter when trying to
unmarshall
the JSON due to the unknown "client-scopes" field.
This incompatibility should be mentioned in the migration guides for 4.x.

* Scopes in general
As far as the current discussion goes the current understanding of custom
scopes (apart from role based scopes) seems to be "scoped" to client-level
since there is no mentioning of something like global scopes on realm level.
I wonder whether it would make sense to have support for broader global
scopes
on realm level, this could help to implement cross-cutting scopes across
all clients.

* Scope translation / rendering on consent page
When requesting consent for a scope from the user in a consent screen it
would be handy to have a way to use parameters for the translation of a
particular scope.
This would allow to render consent requests like
"Access to email: foo at bar.com" , "Access to User attribute: Date of Birth"

Cheers,
Thomas

2018-03-20 10:56 GMT+01:00 Schuster Sebastian (INST/ESY1) <
Sebastian.Schuster at bosch-si.com>:

> +1
>
> Mit freundlichen Gr??en / Best regards
>
> Dr.-Ing. Sebastian Schuster
>
> Engineering and Support (INST/ESY1)
> Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin |
> GERMANY | www.bosch-si.com<http://www.bosch-si.com>
> Tel. +49 30 726112-485 | Fax +49 30 726112-100 |
> Sebastian.Schuster at bosch-si.com<mailto:Sebastian.Schuster at bosch-si.com>
>
> Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
> Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten L?cke; Gesch?ftsf?hrung: Dr.
> Stefan Ferber, Michael Hahn
>
>
>
> From: Marek Posolda [mailto:mposolda at redhat.com]
> Sent: Montag, 19. M?rz 2018 18:31
> To: Pedro Igor Silva <psilva at redhat.com>; Schuster Sebastian (INST/ESY1) <
> Sebastian.Schuster at bosch-si.com>
> Cc: keycloak-dev <keycloak-dev at lists.jboss.org>
> Subject: Re: [keycloak-dev] Client Scope naming
>
> I see. I think you guys have very good points. I've created JIRA
> https://issues.jboss.org/browse/KEYCLOAK-6883 to make sure that we return
> "scope" in the access token.
>
> With my PR, the "scope" is already returned in the TokenResponse as
> defined in the OAuth2 [1] . But Introspection endpoint doesn't return
> "scope" because access token doesn't yet have scope in my PR.
>
> I've just added scope information to the refresh token, but I didn't add
> scope claim directly. I've added "client-scopes" claim to the refresh token
> with the list of UUIDs referencing used client scopes. I did this just
> because:
> a) refreshToken is opaque to the application and just Keycloak needs to be
> able to read it and decode used client scopes from it.
> b) referencing by UUID is in theory bit safer instead of referencing by
> scope names. I was just thinking about corner case when admin deletes scope
> "foo" and then re-create scope "foo" again, it would be something different
> then what user granted, even if it's same name. Hence I used reference by
> UUID. But this is probably just corner case, which won't happen in practice.
>
> When thinking more about it, it seems that none of the points (a) and (b)
> justifies this unecessary complication with using "client-scopes" rather
> then just "scope". It will be just easier if both access token and
> refreshToken contains "scope" claim in the OAuth2 format. WDYT?
>
> [1] https://tools.ietf.org/html/rfc6749#section-5.1
>
> Marek
>
> On 19/03/18 13:59, Pedro Igor Silva wrote:
>
>
> On Mon, Mar 19, 2018 at 9:33 AM, Schuster Sebastian (INST/ESY1) <
> Sebastian.Schuster at bosch-si.com<mailto:Sebastian.Schuster at bosch-si.com>>
> wrote:
> If you support scopes you definitely need some claims in the token that
> represent the granted scopes. Otherwise as a resource server you could only
> do token introspection to retrieve the scopes and having to do this always
> defeats the purpose of self-contained tokens. The fact that Keycloak
> supports defining custom mappings of scopes to roles (and now arbitrary
> claims with token mappers) is just fine, I think.
>
> Btw. access tokens and scopes is not always user consent, see client
> credentials grant?
>
> Yeah, that is why I said usually. My initial idea was discuss cases where
> scopes are *not* limited to the protected resources under the control of
> the client.
>
>
> Best regards,
> Sebastian
>
> Mit freundlichen Gr??en / Best regards
>
> Dr.-Ing. Sebastian Schuster
>
> Engineering and Support (INST/ESY1)
> Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin | <
> https://maps.google.com/?q=Ullsteinstr.+128+%7C+12109+
> Berlin+%7C++%0D%0AGERMANY&entry=gmail&source=g> GERMANY | www.bosch-si.com
> <http://www.bosch-si.com>
> Tel. +49 30 726112-485<tel:+49%2030%20726112485> | Fax +49 30
> 726112-100<tel:+49%2030%20726112100> | Sebastian.Schuster at bosch-si.com
> <mailto:Sebastian.Schuster at bosch-si.com>
>
> Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
> Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten L?cke; Gesch?ftsf?hrung: Dr.
> Stefan Ferber, Michael Hahn
>
>
> From: Pedro Igor Silva [mailto:psilva at redhat.com<mailto:psilva at redhat.com
> >]
> Sent: Montag, 19. M?rz 2018 13:19
> To: Marek Posolda <mposolda at redhat.com<mailto:mposolda at redhat.com>>
> Cc: Schuster Sebastian (INST/ESY1) <Sebastian.Schuster at bosch-si.com
> <mailto:Sebastian.Schuster at bosch-si.com>>; keycloak-dev <
> keycloak-dev at lists.jboss.org<mailto:keycloak-dev at lists.jboss.org>>
> Subject: Re: [keycloak-dev] Client Scope naming
>
> OAuth2 does not define any format for access tokens - as you know they are
> opaque - so you can push whatever you want into it, use it as a reference,
> etc. But if you look https://tools.ietf.org/html/rfc7662 you'll see that
> token introspection response includes a "scope" claim.
>
> The main point I'm trying to make here is that access tokens usually
> represent user consent. Consent is not the same thing as a role granted to
> an user. So I may want to build my REST API without any role mapping but
> based on user consent to specific scopes. Where these scopes grant access
> to different parts of my API.
>
> But I think that should also be possible with your changes. We would just
> need to have a mapper that adds to an access token the scopes granted by
> the user to a client. Or maybe make this information also available via
> introspection endpoint (which I think we are missing).
>
> On Mon, Mar 19, 2018 at 5:22 AM, Marek Posolda <mposolda at redhat.com
> <mailto:mposolda at redhat.com>> wrote:
> Yes, and this (almost) all should be possible now with new client scopes
> stuff I did. It won't be a problem to have "device.localization" client
> scope, which doesn't have any roles or protocolMappers. And require this
> client scope to be present on consent screen.
>
> Only thing, which is not directly available OOTB from what you mentioned,
> is the: Check if scope "device.localization" is granted by introspecting
> the token. For instance, checking a scope claim within a token.
>
> For now, I've just added client scopes to refresh token, but that one is
> opaque to the adapter. I did not add anything to access token or ID token.
> The "scope" claim is not defined on OIDC or OAuth2, so we don't have it in
> our tokens. Do you know if it's defined in some other specification? We can
> do our extension and add some stuff into access token similarly like we did
> for roles, but not sure we want that?
>
> Marek
>
>
> On 16/03/18 14:27, Pedro Igor Silva wrote:
> We already had discussions a long time ago about it. I do think that
> scopes are a first class citizen when doing OIDC and OAuth2, not RBAC. We
> are too role-based ...
>
> Thinking it simple, as an admin user I may want to:
>
> * Create a scope "device.localization" with consent required for a client
>
> As a client:
>
> * Ask for "device.localization" scope when obtaining tokens from AS
>
> As a resource server:
>
> * Check if scope "device.localization" is granted by introspecting the
> token. For instance, checking a scope claim within a token.
>
> See, no role mapping, no scope -> role mapping, etc. User just consented
> to grant "device.localization" scope.
>
> On Fri, Mar 16, 2018 at 10:12 AM, Marek Posolda <mposolda at redhat.com
> <mailto:mposolda at redhat.com>> wrote:
> On 16/03/18 13:24, Pedro Igor Silva wrote:
> That is what I was thinking. In authz services, scopes are not related
> with roles or protocol mappers. They are just a string representing
> something you can perform/access in a protected resource. Use client scopes
> to represent such concept and remove "authz scopes" tab is a bit overkill,
> I think.
>
> Currently, if I have a Localization API and a scope that grants access
> based on a "device.localization"  scope, I would need to create a
> role/mapper and associate it with a client scope, right ?
> You mean that you have support for "device.localization" value of OAuth
> scope parameter? Yes, you would need to create clientScope and associate
> role "device.localization" with it. With client scopes support, the scope
> parameter doesn't reference single role, but single client scope.
>
> Marek
>
>
> On Fri, Mar 16, 2018 at 4:46 AM, Marek Posolda <mposolda at redhat.com
> <mailto:mposolda at redhat.com>> wrote:
> Scope parameter would reference client scopes. For example scope parameter
> "openid email profile offline_access" will reference client scopes "email",
> "profile" and "offline_access" (openid is jsut generic OpenID Connect
> marker).  And each client scope is set of protocolMappers and/or Role scope
> mappings.
>
> Marek
>
>
> On 15/03/18 12:39, Pedro Igor Silva wrote:
> How a scope looks like now after your changes ? Are they just strings
> referencing a set of one or more roles ? Or they are still roles ?
>
> On Wed, Mar 14, 2018 at 5:03 PM, Marek Posolda <mposolda at redhat.com
> <mailto:mposolda at redhat.com>> wrote:
> That's good question. As you know, we also have "Scope" tab (used to
> specify scope role mappings of client) and "Authorization scope", which
> is used when Authorization is enabled :)
>
> Marek
>
> On 14/03/18 14:37, Schuster Sebastian (INST/ESY1) wrote:
> > Hi,
> >
> > I saw there are activities to replace client templates with client
> scopes. UMA 2.0 uses the term ?client scope? to determine what the OAuth
> client wants to do with the granted access (e.g. this could be used to
> determine the purpose of processing some data for GDPR compliance). Since
> Keycloak will also support UMA 2.0, I am a little concerned this might lead
> to some confusion. As you know, there are only two hard problems in
> computer science: cache invalidation, naming things, and off-by-one errors.
> ? WDYT?
> >
> > Best regards,
> > Sebastian
> >
> > Mit freundlichen Gr??en / Best regards
> >
> > Dr.-Ing. Sebastian Schuster
> >
> > Engineering and Support (INST/ESY1)
> > Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin |
> GERMANY<https://maps.google.com/?q=Ullsteinstr.+128+%7C+
> 12109+Berlin+%7C+GERMANY&entry=gmail&source=g> | www.bosch-si.com<
> http://www.bosch-si.com><http://www.bosch-si.com>
> > Tel. +49 30 726112-485<tel:%2B49%2030%20726112-485> | Fax +49 30
> 726112-100<tel:%2B49%2030%20726112-100> | Sebastian.Schuster at bosch-si.com
> <mailto:Sebastian.Schuster at bosch-si.com><mailto:Sebastian
> .Schuster at bosch-si.com<mailto:Sebastian.Schuster at bosch-si.com>>
> >
> > Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
> > Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten L?cke; Gesch?ftsf?hrung:
> Dr. Stefan Ferber, Michael Hahn
> >
> >
> >
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org<mailto:keycloak-dev at lists.jboss.org>
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org<mailto:keycloak-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From thomas.darimont at googlemail.com  Wed Apr  4 06:18:57 2018
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Wed, 4 Apr 2018 12:18:57 +0200
Subject: [keycloak-dev] Automatic Security Advisory for Keycloak Settings
Message-ID: <CAK-7U1j+Gc1bmXZRz-T6H-pjMmKC0rkH1KxCkG+sLtXrQPsgFA@mail.gmail.com>

Hello,

After upgrading Keycloak some settings are not updated and
left as is, either because the they were changed by the admin
or contain the previous default value.
This settings might not match the current recommendations.

Since there is currently no automatic configuration check
Keycloak admins potentially need to revisit every
setting after an upgrade / migration.

As an example for settings that need to be upgraded regularly after
a Keycloak upgrade are the Header configurations in the Security Settings.

It would be great if Keycloak would be aware of the current
best practice recommendations for configuration settings and
would list / highlight deviations.

One way to show this to admins would be a list in a dedicated
"Security Advisory" section or as a hint on a particular setting
in the admin console.

Do you have any plans for implementing something like this?

Cheers,
Thomas

From mposolda at redhat.com  Wed Apr  4 07:48:45 2018
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 4 Apr 2018 13:48:45 +0200
Subject: [keycloak-dev] offline access permission incorrect?
In-Reply-To: <CAJgngAc_OM6G3deyGVbfAxkRC0zx6xCcnEdn4_ywBq61_vXtVA@mail.gmail.com>
References: <CABRXCmz9QQTC8TZYvcjnhskOiU=z0Vw8cfdm-DSkqKnvJn3v1Q@mail.gmail.com>
	<CAJgngAc_OM6G3deyGVbfAxkRC0zx6xCcnEdn4_ywBq61_vXtVA@mail.gmail.com>
Message-ID: <eae48ea9-6163-568e-b61c-13fe7ed7b832@redhat.com>

I was thinking that people may have usecase, when they don't want all 
users to allow automatically ask for offline tokens? Currently 
offline_access is realm default role, so all users are automatically 
allowed to "request" offline tokens. But was thinking that someone may 
want also the opposite use-case. For example allow just admin user to 
request offline tokens, but ensure that other users are not allowed to 
request it.

If you think, we can remove this capability. We can see if people claims 
that they want to add it back :) Nobody specifically requested that 
capability as it's there since the beginning of the offline tokens support.

In clientScope PR, there is "offline_access" client scope, but 
"offline_access" realm role is also still there and it's assigned as 
"role scope mapping" to the offline_access clientScope. So clientScope 
PR still requires users to be in "offline_access" role. If you want to 
change the behaviour, it will be nice to do that after clientScope PR is 
merged, however if it blocks you, it's likely fine to do it now. The 
clientScope PR will then need to be updated later as there would be some 
conflicts...

Marek


Dne 3.4.2018 v 11:21 Stian Thorgersen napsal(a):
> +1
>
> On 3 April 2018 at 00:16, Bill Burke <bburke at redhat.com> wrote:
>
>> To enable offline access the user must have the offline access role
>> and the client must have that role in its scope...
>>
>> This just doesn't seem right to me.  IMO, this shouldn't be something
>> you assign permission to a user.  Its solely a client permission and
>> should not be something role-based.  Instead the client should be
>> marked as allowing to ask for offline access and whether or not the
>> client must ask consent for this.
>>
>> --
>> Bill Burke
>> Red Hat
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



From bburke at redhat.com  Wed Apr  4 08:00:44 2018
From: bburke at redhat.com (Bill Burke)
Date: Wed, 4 Apr 2018 08:00:44 -0400
Subject: [keycloak-dev] offline access permission incorrect?
In-Reply-To: <eae48ea9-6163-568e-b61c-13fe7ed7b832@redhat.com>
References: <CABRXCmz9QQTC8TZYvcjnhskOiU=z0Vw8cfdm-DSkqKnvJn3v1Q@mail.gmail.com>
	<CAJgngAc_OM6G3deyGVbfAxkRC0zx6xCcnEdn4_ywBq61_vXtVA@mail.gmail.com>
	<eae48ea9-6163-568e-b61c-13fe7ed7b832@redhat.com>
Message-ID: <CABRXCmzy=TtdoWrK3-QU2XdmCm-RbanO9_iiGGPA_Lg2t_Bnxw@mail.gmail.com>

Users don't request offline access.  Applications do.  Users will not
even know about OIDC, Oauth, offline access etc...

On Wed, Apr 4, 2018 at 7:48 AM, Marek Posolda <mposolda at redhat.com> wrote:
> I was thinking that people may have usecase, when they don't want all users
> to allow automatically ask for offline tokens? Currently offline_access is
> realm default role, so all users are automatically allowed to "request"
> offline tokens. But was thinking that someone may want also the opposite
> use-case. For example allow just admin user to request offline tokens, but
> ensure that other users are not allowed to request it.
>
> If you think, we can remove this capability. We can see if people claims
> that they want to add it back :) Nobody specifically requested that
> capability as it's there since the beginning of the offline tokens support.
>
> In clientScope PR, there is "offline_access" client scope, but
> "offline_access" realm role is also still there and it's assigned as "role
> scope mapping" to the offline_access clientScope. So clientScope PR still
> requires users to be in "offline_access" role. If you want to change the
> behaviour, it will be nice to do that after clientScope PR is merged,
> however if it blocks you, it's likely fine to do it now. The clientScope PR
> will then need to be updated later as there would be some conflicts...
>
> Marek
>
>
> Dne 3.4.2018 v 11:21 Stian Thorgersen napsal(a):
>
>> +1
>>
>> On 3 April 2018 at 00:16, Bill Burke <bburke at redhat.com> wrote:
>>
>>> To enable offline access the user must have the offline access role
>>> and the client must have that role in its scope...
>>>
>>> This just doesn't seem right to me.  IMO, this shouldn't be something
>>> you assign permission to a user.  Its solely a client permission and
>>> should not be something role-based.  Instead the client should be
>>> marked as allowing to ask for offline access and whether or not the
>>> client must ask consent for this.
>>>
>>> --
>>> Bill Burke
>>> Red Hat
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>



-- 
Bill Burke
Red Hat

From mposolda at redhat.com  Wed Apr  4 08:01:46 2018
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 4 Apr 2018 14:01:46 +0200
Subject: [keycloak-dev] Client Scope naming
In-Reply-To: <CAK-7U1jATq79gKbPTjXD0esLF5tPvd62t=eJ2VshQJkiT1kgwQ@mail.gmail.com>
References: <a07feaadfdcd4aaeb82163c784041781@bosch-si.com>
	<6109ae10-65be-5c45-8a9e-bd4f79c034bc@redhat.com>
	<CAJrcDBd+ri5afu7BzSqz2jKQLiPimfsHuFtEYrOo7JNdD5hagA@mail.gmail.com>
	<b3ccbf66-4b32-7bdd-2f48-2b507f71810e@redhat.com>
	<CAJrcDBdjdP_9_0JeW8OTNHgXgLDB0QXagLeUPdZYnd4GqcN4FA@mail.gmail.com>
	<976022cb-b0ed-51e0-6754-955efee6675a@redhat.com>
	<CAJrcDBc-sfoBTWcHRY2sPGgUC8Too8wb3qNjuzcaHkvLY4B_BQ@mail.gmail.com>
	<56ee4c0a-2661-c4db-5844-8aef0afba7c9@redhat.com>
	<CAJrcDBdQMRtEuRJH3UOV1i0Qrn-H+XPJe84wNWAgALmuwZQyOg@mail.gmail.com>
	<f5629ef6ec93488b9b45562a81074f18@bosch-si.com>
	<CAJrcDBffBSDyjsMqHvm7F=jHgV4x5B_m0y94i8c8TRUQoEmcBw@mail.gmail.com>
	<58fc88ad-acab-e580-25f4-7849798173cd@redhat.com>
	<0a29664822124858923a515a1e6c8847@bosch-si.com>
	<CAK-7U1jATq79gKbPTjXD0esLF5tPvd62t=eJ2VshQJkiT1kgwQ@mail.gmail.com>
Message-ID: <6020827a-cf64-2bc8-f855-d540a50e221d@redhat.com>

Dne 4.4.2018 v 11:07 Thomas Darimont napsal(a):
> Great discussion, I think many folks are looking forward to enhanced 
> scope support in Keycloak.
>
> I also think that having scopes in the RefreshToken as well as the 
> AccessToken
> structure is useful.
>
> Some additional remarks:
> * backwards compatibility
> Changing the representation of the token structures might cause problems
> for clients using an older version of a Keycloak adapter when trying 
> to unmarshall
> the JSON due to the unknown "client-scopes" field.
> This incompatibility should be mentioned in the migration guides for 4.x.
Good point. I think it won't be an issue for our java adapters. The 
JsonWebToken class contains field "otherClaims", which contains all the 
claims without getter/setter. So if our older adapter reads new 
accessToken, the "scope" will be just put as attribute to "otherClaims" 
. But it might be an issue for our Node.js adapter (maybe?) and for 3rd 
party adapters, which parse our accessToken and rely on it's format. 
Agree will be good to put to the migration guide.
>
> * Scopes in general
> As far as the current discussion goes the current understanding of custom
> scopes (apart from role based scopes) seems to be "scoped" to client-level
> since there is no mentioning of something like global scopes on realm 
> level.
> I wonder whether it would make sense to have support for broader 
> global scopes
> on realm level, this could help to implement cross-cutting scopes 
> across all clients.
The clientScopes will be defined at realm level similarly like currently 
clientTemplates. So the definition of clientScope itself (EG. which 
protocolMappers and role scope mappings it contains) is at realm level. 
At client level, you can just assign clientScope to client. There will 
also be "Default client scopes" - those are automatically added to new 
clients, but can be then manually removed from clients.
>
> * Scope translation / rendering on consent page
> When requesting consent for a scope from the user in a consent screen it
> would be handy to have a way to use parameters for the translation of 
> a particular scope.
> This would allow to render consent requests like
> "Access to email: foo at bar.com <mailto:foo at bar.com>" , "Access to User 
> attribute: Date of Birth"
In the clientScope PR, it supports localization, but not parameters. 
Feel free to create JIRA for parameters.

Marek
>
> Cheers,
> Thomas
>
> 2018-03-20 10:56 GMT+01:00 Schuster Sebastian (INST/ESY1) 
> <Sebastian.Schuster at bosch-si.com 
> <mailto:Sebastian.Schuster at bosch-si.com>>:
>
>     +1
>
>     Mit freundlichen Gr??en / Best regards
>
>     Dr.-Ing. Sebastian Schuster
>
>     Engineering and Support (INST/ESY1)
>     Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin
>     | GERMANY | www.bosch-si.com
>     <http://www.bosch-si.com><http://www.bosch-si.com
>     <http://www.bosch-si.com>>
>     Tel. +49 30 726112-485 | Fax +49 30 726112-100 |
>     Sebastian.Schuster at bosch-si.com
>     <mailto:Sebastian.Schuster at bosch-si.com><mailto:Sebastian.Schuster at bosch-si.com
>     <mailto:Sebastian.Schuster at bosch-si.com>>
>
>     Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB
>     148411 B
>     Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten L?cke;
>     Gesch?ftsf?hrung: Dr. Stefan Ferber, Michael Hahn
>
>
>
>     From: Marek Posolda [mailto:mposolda at redhat.com
>     <mailto:mposolda at redhat.com>]
>     Sent: Montag, 19. M?rz 2018 18:31
>     To: Pedro Igor Silva <psilva at redhat.com
>     <mailto:psilva at redhat.com>>; Schuster Sebastian (INST/ESY1)
>     <Sebastian.Schuster at bosch-si.com
>     <mailto:Sebastian.Schuster at bosch-si.com>>
>     Cc: keycloak-dev <keycloak-dev at lists.jboss.org
>     <mailto:keycloak-dev at lists.jboss.org>>
>     Subject: Re: [keycloak-dev] Client Scope naming
>
>     I see. I think you guys have very good points. I've created JIRA
>     https://issues.jboss.org/browse/KEYCLOAK-6883
>     <https://issues.jboss.org/browse/KEYCLOAK-6883> to make sure that
>     we return "scope" in the access token.
>
>     With my PR, the "scope" is already returned in the TokenResponse
>     as defined in the OAuth2 [1] . But Introspection endpoint doesn't
>     return "scope" because access token doesn't yet have scope in my PR.
>
>     I've just added scope information to the refresh token, but I
>     didn't add scope claim directly. I've added "client-scopes" claim
>     to the refresh token with the list of UUIDs referencing used
>     client scopes. I did this just because:
>     a) refreshToken is opaque to the application and just Keycloak
>     needs to be able to read it and decode used client scopes from it.
>     b) referencing by UUID is in theory bit safer instead of
>     referencing by scope names. I was just thinking about corner case
>     when admin deletes scope "foo" and then re-create scope "foo"
>     again, it would be something different then what user granted,
>     even if it's same name. Hence I used reference by UUID. But this
>     is probably just corner case, which won't happen in practice.
>
>     When thinking more about it, it seems that none of the points (a)
>     and (b) justifies this unecessary complication with using
>     "client-scopes" rather then just "scope". It will be just easier
>     if both access token and refreshToken contains "scope" claim in
>     the OAuth2 format. WDYT?
>
>     [1] https://tools.ietf.org/html/rfc6749#section-5.1
>     <https://tools.ietf.org/html/rfc6749#section-5.1>
>
>     Marek
>
>     On 19/03/18 13:59, Pedro Igor Silva wrote:
>
>
>     On Mon, Mar 19, 2018 at 9:33 AM, Schuster Sebastian (INST/ESY1)
>     <Sebastian.Schuster at bosch-si.com
>     <mailto:Sebastian.Schuster at bosch-si.com><mailto:Sebastian.Schuster at bosch-si.com
>     <mailto:Sebastian.Schuster at bosch-si.com>>> wrote:
>     If you support scopes you definitely need some claims in the token
>     that represent the granted scopes. Otherwise as a resource server
>     you could only do token introspection to retrieve the scopes and
>     having to do this always defeats the purpose of self-contained
>     tokens. The fact that Keycloak supports defining custom mappings
>     of scopes to roles (and now arbitrary claims with token mappers)
>     is just fine, I think.
>
>     Btw. access tokens and scopes is not always user consent, see
>     client credentials grant?
>
>     Yeah, that is why I said usually. My initial idea was discuss
>     cases where scopes are *not* limited to the protected resources
>     under the control of the client.
>
>
>     Best regards,
>     Sebastian
>
>     Mit freundlichen Gr??en / Best regards
>
>     Dr.-Ing. Sebastian Schuster
>
>     Engineering and Support (INST/ESY1)
>     Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin
>     |
>     <https://maps.google.com/?q=Ullsteinstr.+128+%7C+12109+Berlin+%7C++%0D%0AGERMANY&entry=gmail&source=g
>     <https://maps.google.com/?q=Ullsteinstr.+128+%7C+12109+Berlin+%7C++%0D%0AGERMANY&entry=gmail&source=g>>
>     GERMANY | www.bosch-si.com
>     <http://www.bosch-si.com><http://www.bosch-si.com
>     <http://www.bosch-si.com>>
>     Tel. +49 30 726112-485<tel:+49%2030%20726112485> | Fax +49 30
>     726112-100<tel:+49%2030%20726112100> |
>     Sebastian.Schuster at bosch-si.com
>     <mailto:Sebastian.Schuster at bosch-si.com><mailto:Sebastian.Schuster at bosch-si.com
>     <mailto:Sebastian.Schuster at bosch-si.com>>
>
>     Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB
>     148411 B
>     Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten L?cke;
>     Gesch?ftsf?hrung: Dr. Stefan Ferber, Michael Hahn
>
>
>     From: Pedro Igor Silva [mailto:psilva at redhat.com
>     <mailto:psilva at redhat.com><mailto:psilva at redhat.com
>     <mailto:psilva at redhat.com>>]
>     Sent: Montag, 19. M?rz 2018 13:19
>     To: Marek Posolda <mposolda at redhat.com
>     <mailto:mposolda at redhat.com><mailto:mposolda at redhat.com
>     <mailto:mposolda at redhat.com>>>
>     Cc: Schuster Sebastian (INST/ESY1)
>     <Sebastian.Schuster at bosch-si.com
>     <mailto:Sebastian.Schuster at bosch-si.com><mailto:Sebastian.Schuster at bosch-si.com
>     <mailto:Sebastian.Schuster at bosch-si.com>>>; keycloak-dev
>     <keycloak-dev at lists.jboss.org
>     <mailto:keycloak-dev at lists.jboss.org><mailto:keycloak-dev at lists.jboss.org
>     <mailto:keycloak-dev at lists.jboss.org>>>
>     Subject: Re: [keycloak-dev] Client Scope naming
>
>     OAuth2 does not define any format for access tokens - as you know
>     they are opaque - so you can push whatever you want into it, use
>     it as a reference, etc. But if you look
>     https://tools.ietf.org/html/rfc7662
>     <https://tools.ietf.org/html/rfc7662> you'll see that token
>     introspection response includes a "scope" claim.
>
>     The main point I'm trying to make here is that access tokens
>     usually represent user consent. Consent is not the same thing as a
>     role granted to an user. So I may want to build my REST API
>     without any role mapping but based on user consent to specific
>     scopes. Where these scopes grant access to different parts of my API.
>
>     But I think that should also be possible with your changes. We
>     would just need to have a mapper that adds to an access token the
>     scopes granted by the user to a client. Or maybe make this
>     information also available via introspection endpoint (which I
>     think we are missing).
>
>     On Mon, Mar 19, 2018 at 5:22 AM, Marek Posolda
>     <mposolda at redhat.com
>     <mailto:mposolda at redhat.com><mailto:mposolda at redhat.com
>     <mailto:mposolda at redhat.com>>> wrote:
>     Yes, and this (almost) all should be possible now with new client
>     scopes stuff I did. It won't be a problem to have
>     "device.localization" client scope, which doesn't have any roles
>     or protocolMappers. And require this client scope to be present on
>     consent screen.
>
>     Only thing, which is not directly available OOTB from what you
>     mentioned, is the: Check if scope "device.localization" is granted
>     by introspecting the token. For instance, checking a scope claim
>     within a token.
>
>     For now, I've just added client scopes to refresh token, but that
>     one is opaque to the adapter. I did not add anything to access
>     token or ID token. The "scope" claim is not defined on OIDC or
>     OAuth2, so we don't have it in our tokens. Do you know if it's
>     defined in some other specification? We can do our extension and
>     add some stuff into access token similarly like we did for roles,
>     but not sure we want that?
>
>     Marek
>
>
>     On 16/03/18 14:27, Pedro Igor Silva wrote:
>     We already had discussions a long time ago about it. I do think
>     that scopes are a first class citizen when doing OIDC and OAuth2,
>     not RBAC. We are too role-based ...
>
>     Thinking it simple, as an admin user I may want to:
>
>     * Create a scope "device.localization" with consent required for a
>     client
>
>     As a client:
>
>     * Ask for "device.localization" scope when obtaining tokens from AS
>
>     As a resource server:
>
>     * Check if scope "device.localization" is granted by introspecting
>     the token. For instance, checking a scope claim within a token.
>
>     See, no role mapping, no scope -> role mapping, etc. User just
>     consented to grant "device.localization" scope.
>
>     On Fri, Mar 16, 2018 at 10:12 AM, Marek Posolda
>     <mposolda at redhat.com
>     <mailto:mposolda at redhat.com><mailto:mposolda at redhat.com
>     <mailto:mposolda at redhat.com>>> wrote:
>     On 16/03/18 13:24, Pedro Igor Silva wrote:
>     That is what I was thinking. In authz services, scopes are not
>     related with roles or protocol mappers. They are just a string
>     representing something you can perform/access in a protected
>     resource. Use client scopes to represent such concept and remove
>     "authz scopes" tab is a bit overkill, I think.
>
>     Currently, if I have a Localization API and a scope that grants
>     access based on a "device.localization"? scope, I would need to
>     create a role/mapper and associate it with a client scope, right ?
>     You mean that you have support for "device.localization" value of
>     OAuth scope parameter? Yes, you would need to create clientScope
>     and associate role "device.localization" with it. With client
>     scopes support, the scope parameter doesn't reference single role,
>     but single client scope.
>
>     Marek
>
>
>     On Fri, Mar 16, 2018 at 4:46 AM, Marek Posolda
>     <mposolda at redhat.com
>     <mailto:mposolda at redhat.com><mailto:mposolda at redhat.com
>     <mailto:mposolda at redhat.com>>> wrote:
>     Scope parameter would reference client scopes. For example scope
>     parameter "openid email profile offline_access" will reference
>     client scopes "email", "profile" and "offline_access" (openid is
>     jsut generic OpenID Connect marker).? And each client scope is set
>     of protocolMappers and/or Role scope mappings.
>
>     Marek
>
>
>     On 15/03/18 12:39, Pedro Igor Silva wrote:
>     How a scope looks like now after your changes ? Are they just
>     strings referencing a set of one or more roles ? Or they are still
>     roles ?
>
>     On Wed, Mar 14, 2018 at 5:03 PM, Marek Posolda
>     <mposolda at redhat.com
>     <mailto:mposolda at redhat.com><mailto:mposolda at redhat.com
>     <mailto:mposolda at redhat.com>>> wrote:
>     That's good question. As you know, we also have "Scope" tab (used to
>     specify scope role mappings of client) and "Authorization scope",
>     which
>     is used when Authorization is enabled :)
>
>     Marek
>
>     On 14/03/18 14:37, Schuster Sebastian (INST/ESY1) wrote:
>     > Hi,
>     >
>     > I saw there are activities to replace client templates with
>     client scopes. UMA 2.0 uses the term ?client scope? to determine
>     what the OAuth client wants to do with the granted access (e.g.
>     this could be used to determine the purpose of processing some
>     data for GDPR compliance). Since Keycloak will also support UMA
>     2.0, I am a little concerned this might lead to some confusion. As
>     you know, there are only two hard problems in computer science:
>     cache invalidation, naming things, and off-by-one errors. ? WDYT?
>     >
>     > Best regards,
>     > Sebastian
>     >
>     > Mit freundlichen Gr??en / Best regards
>     >
>     > Dr.-Ing. Sebastian Schuster
>     >
>     > Engineering and Support (INST/ESY1)
>     > Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109
>     Berlin |
>     GERMANY<https://maps.google.com/?q=Ullsteinstr.+128+%7C+12109+Berlin+%7C+GERMANY&entry=gmail&source=g
>     <https://maps.google.com/?q=Ullsteinstr.+128+%7C+12109+Berlin+%7C+GERMANY&entry=gmail&source=g>>
>     | www.bosch-si.com
>     <http://www.bosch-si.com><http://www.bosch-si.com
>     <http://www.bosch-si.com>><http://www.bosch-si.com
>     <http://www.bosch-si.com>>
>     > Tel. +49 30 726112-485<tel:%2B49%2030%20726112-485> | Fax +49 30
>     726112-100<tel:%2B49%2030%20726112-100> |
>     Sebastian.Schuster at bosch-si.com
>     <mailto:Sebastian.Schuster at bosch-si.com><mailto:Sebastian.Schuster at bosch-si.com
>     <mailto:Sebastian.Schuster at bosch-si.com>><mailto:Sebastian.Schuster at bosch-si.com
>     <mailto:Sebastian.Schuster at bosch-si.com><mailto:Sebastian.Schuster at bosch-si.com
>     <mailto:Sebastian.Schuster at bosch-si.com>>>
>     >
>     > Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB
>     148411 B
>     > Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten L?cke;
>     Gesch?ftsf?hrung: Dr. Stefan Ferber, Michael Hahn
>     >
>     >
>     >
>     > _______________________________________________
>     > keycloak-dev mailing list
>     > keycloak-dev at lists.jboss.org
>     <mailto:keycloak-dev at lists.jboss.org><mailto:keycloak-dev at lists.jboss.org
>     <mailto:keycloak-dev at lists.jboss.org>>
>     > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>     <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>
>
>     _______________________________________________
>     keycloak-dev mailing list
>     keycloak-dev at lists.jboss.org
>     <mailto:keycloak-dev at lists.jboss.org><mailto:keycloak-dev at lists.jboss.org
>     <mailto:keycloak-dev at lists.jboss.org>>
>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>     <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>
>
>
>
>
>
>
>
>
>
>
>
>
>     _______________________________________________
>     keycloak-dev mailing list
>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>     <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>
>


From mposolda at redhat.com  Wed Apr  4 08:12:12 2018
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 4 Apr 2018 14:12:12 +0200
Subject: [keycloak-dev] offline access permission incorrect?
In-Reply-To: <CABRXCmzy=TtdoWrK3-QU2XdmCm-RbanO9_iiGGPA_Lg2t_Bnxw@mail.gmail.com>
References: <CABRXCmz9QQTC8TZYvcjnhskOiU=z0Vw8cfdm-DSkqKnvJn3v1Q@mail.gmail.com>
	<CAJgngAc_OM6G3deyGVbfAxkRC0zx6xCcnEdn4_ywBq61_vXtVA@mail.gmail.com>
	<eae48ea9-6163-568e-b61c-13fe7ed7b832@redhat.com>
	<CABRXCmzy=TtdoWrK3-QU2XdmCm-RbanO9_iiGGPA_Lg2t_Bnxw@mail.gmail.com>
Message-ID: <e1e6057c-8fd1-2377-6f7a-64c6634709f2@redhat.com>

Yes, but users can be theoretically aware of it and manually add 
"scope=offline_access" to the URL and have the offline token 
successfully issued. Our public clients are allowed to request offline 
tokens, so user will have offline token as well and use it anytime later 
without require other re-authentication. But I am not sure if it's real 
concern or not...

I agree we can remove this. We can see if people claim that they want to add it back...


Marek

Dne 4.4.2018 v 14:00 Bill Burke napsal(a):
> Users don't request offline access.  Applications do.  Users will not
> even know about OIDC, Oauth, offline access etc...
>
> On Wed, Apr 4, 2018 at 7:48 AM, Marek Posolda <mposolda at redhat.com> wrote:
>> I was thinking that people may have usecase, when they don't want all users
>> to allow automatically ask for offline tokens? Currently offline_access is
>> realm default role, so all users are automatically allowed to "request"
>> offline tokens. But was thinking that someone may want also the opposite
>> use-case. For example allow just admin user to request offline tokens, but
>> ensure that other users are not allowed to request it.
>>
>> If you think, we can remove this capability. We can see if people claims
>> that they want to add it back :) Nobody specifically requested that
>> capability as it's there since the beginning of the offline tokens support.
>>
>> In clientScope PR, there is "offline_access" client scope, but
>> "offline_access" realm role is also still there and it's assigned as "role
>> scope mapping" to the offline_access clientScope. So clientScope PR still
>> requires users to be in "offline_access" role. If you want to change the
>> behaviour, it will be nice to do that after clientScope PR is merged,
>> however if it blocks you, it's likely fine to do it now. The clientScope PR
>> will then need to be updated later as there would be some conflicts...
>>
>> Marek
>>
>>
>> Dne 3.4.2018 v 11:21 Stian Thorgersen napsal(a):
>>
>>> +1
>>>
>>> On 3 April 2018 at 00:16, Bill Burke <bburke at redhat.com> wrote:
>>>
>>>> To enable offline access the user must have the offline access role
>>>> and the client must have that role in its scope...
>>>>
>>>> This just doesn't seem right to me.  IMO, this shouldn't be something
>>>> you assign permission to a user.  Its solely a client permission and
>>>> should not be something role-based.  Instead the client should be
>>>> marked as allowing to ask for offline access and whether or not the
>>>> client must ask consent for this.
>>>>
>>>> --
>>>> Bill Burke
>>>> Red Hat
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>
>


From vsafin at kdsconsulting.com  Wed Apr  4 09:02:17 2018
From: vsafin at kdsconsulting.com (Vladimir Safin)
Date: Wed, 04 Apr 2018 09:02:17 -0400
Subject: [keycloak-dev] Keycloak usage scenario
Message-ID: <e38db35c-f051-486b-85e3-21839fd9d4d3@kdsconsulting.com>

I have Angular application that calls Spring Boot based rest API.
Angular application can authenticate with KeyCloack, in fact I was thinking 
about using Keycloak ability to register user as well.
In my application I have a need to provision logged this user in my 
database or update their information after they login. Since Spring Boot 
API app is stateless and we use JWT token to authenticate saving user into 
the database on every request would not be efficient.
Anybody run into the scenario like this ? How did you solve it?

From thomas.darimont at googlemail.com  Wed Apr  4 11:42:45 2018
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Wed, 4 Apr 2018 17:42:45 +0200
Subject: [keycloak-dev] offline access permission incorrect?
In-Reply-To: <e1e6057c-8fd1-2377-6f7a-64c6634709f2@redhat.com>
References: <CABRXCmz9QQTC8TZYvcjnhskOiU=z0Vw8cfdm-DSkqKnvJn3v1Q@mail.gmail.com>
	<CAJgngAc_OM6G3deyGVbfAxkRC0zx6xCcnEdn4_ywBq61_vXtVA@mail.gmail.com>
	<eae48ea9-6163-568e-b61c-13fe7ed7b832@redhat.com>
	<CABRXCmzy=TtdoWrK3-QU2XdmCm-RbanO9_iiGGPA_Lg2t_Bnxw@mail.gmail.com>
	<e1e6057c-8fd1-2377-6f7a-64c6634709f2@redhat.com>
Message-ID: <CAK-7U1hrvbTYmTYC85RnoLKOa2kVAjjznPQo1-0YKLyiBhcmug@mail.gmail.com>

I think one scenario where a user needs to grant offline-access
to client-a for another client-b is integrating with third-party apps.

A third-party app could be represented as a client in Keycloak in order
to define client specific roles and assign them to a user.
This third-party app might periodically request data from a
bearer-only backend-service client on behalf of the user,
without requiring the user to be logged in all the time.
Also the third-party may not necessarily be (fully) integrated with
Keycloak.

A user grants offline-access to the third-party client via a initial
"connect step".
In the connect step the user is asked for consent to grant offline-access
(including other scopes)
to the third-party client whose roles include an access/reader/user role
for backend-service.

The third-party client now receives a new refresh-token (offline-token)
which enables
the third-party client to retrieve new access-tokens for requesting data
from the backend-service.

The user can now see the granted offline-access consent for the third-party
application
in the applications section of the account page.
If the user wants to deactivate access for the third-party app, he just
removes the
granted offline-access scope in the account page. Once the access-token
currently used by
the third-party client has timed-out it cannot request new access-tokens
anymore.

Currently granting offline-access to a client is quite an extensive
permission
since it might enable a third-party service to access other clients as well
thus clients need apply some additional checks for tokens retrieved for
offline-access.

With the support for more flexible custom scopes this can be mitigated a
bit by defining
custom scopes like "timesheet.read" that encompasses or are combined with
offline-access.

I demonstrated such an integration scenario to S?bastien Blanc at the
JavaLand conference.

Cheers,
Thomas

2018-04-04 14:12 GMT+02:00 Marek Posolda <mposolda at redhat.com>:

> Yes, but users can be theoretically aware of it and manually add
> "scope=offline_access" to the URL and have the offline token
> successfully issued. Our public clients are allowed to request offline
> tokens, so user will have offline token as well and use it anytime later
> without require other re-authentication. But I am not sure if it's real
> concern or not...
>
> I agree we can remove this. We can see if people claim that they want to
> add it back...
>
>
> Marek
>
> Dne 4.4.2018 v 14:00 Bill Burke napsal(a):
> > Users don't request offline access.  Applications do.  Users will not
> > even know about OIDC, Oauth, offline access etc...
> >
> > On Wed, Apr 4, 2018 at 7:48 AM, Marek Posolda <mposolda at redhat.com>
> wrote:
> >> I was thinking that people may have usecase, when they don't want all
> users
> >> to allow automatically ask for offline tokens? Currently offline_access
> is
> >> realm default role, so all users are automatically allowed to "request"
> >> offline tokens. But was thinking that someone may want also the opposite
> >> use-case. For example allow just admin user to request offline tokens,
> but
> >> ensure that other users are not allowed to request it.
> >>
> >> If you think, we can remove this capability. We can see if people claims
> >> that they want to add it back :) Nobody specifically requested that
> >> capability as it's there since the beginning of the offline tokens
> support.
> >>
> >> In clientScope PR, there is "offline_access" client scope, but
> >> "offline_access" realm role is also still there and it's assigned as
> "role
> >> scope mapping" to the offline_access clientScope. So clientScope PR
> still
> >> requires users to be in "offline_access" role. If you want to change the
> >> behaviour, it will be nice to do that after clientScope PR is merged,
> >> however if it blocks you, it's likely fine to do it now. The
> clientScope PR
> >> will then need to be updated later as there would be some conflicts...
> >>
> >> Marek
> >>
> >>
> >> Dne 3.4.2018 v 11:21 Stian Thorgersen napsal(a):
> >>
> >>> +1
> >>>
> >>> On 3 April 2018 at 00:16, Bill Burke <bburke at redhat.com> wrote:
> >>>
> >>>> To enable offline access the user must have the offline access role
> >>>> and the client must have that role in its scope...
> >>>>
> >>>> This just doesn't seem right to me.  IMO, this shouldn't be something
> >>>> you assign permission to a user.  Its solely a client permission and
> >>>> should not be something role-based.  Instead the client should be
> >>>> marked as allowing to ask for offline access and whether or not the
> >>>> client must ask consent for this.
> >>>>
> >>>> --
> >>>> Bill Burke
> >>>> Red Hat
> >>>> _______________________________________________
> >>>> keycloak-dev mailing list
> >>>> keycloak-dev at lists.jboss.org
> >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>>
> >>> _______________________________________________
> >>> keycloak-dev mailing list
> >>> keycloak-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> >>
> >
> >
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From bburke at redhat.com  Wed Apr  4 11:46:56 2018
From: bburke at redhat.com (Bill Burke)
Date: Wed, 4 Apr 2018 11:46:56 -0400
Subject: [keycloak-dev] offline access permission incorrect?
In-Reply-To: <CAK-7U1hrvbTYmTYC85RnoLKOa2kVAjjznPQo1-0YKLyiBhcmug@mail.gmail.com>
References: <CABRXCmz9QQTC8TZYvcjnhskOiU=z0Vw8cfdm-DSkqKnvJn3v1Q@mail.gmail.com>
	<CAJgngAc_OM6G3deyGVbfAxkRC0zx6xCcnEdn4_ywBq61_vXtVA@mail.gmail.com>
	<eae48ea9-6163-568e-b61c-13fe7ed7b832@redhat.com>
	<CABRXCmzy=TtdoWrK3-QU2XdmCm-RbanO9_iiGGPA_Lg2t_Bnxw@mail.gmail.com>
	<e1e6057c-8fd1-2377-6f7a-64c6634709f2@redhat.com>
	<CAK-7U1hrvbTYmTYC85RnoLKOa2kVAjjznPQo1-0YKLyiBhcmug@mail.gmail.com>
Message-ID: <CABRXCmwM9PLzPoHNMxnisPc-Et_fs_tX89v6nRV9_y3LMHyH1w@mail.gmail.com>

Thomas, so you're agreeing with me?    I think Marek's client scope
work should be the basis of allowing offline access.  Client is can
ask for "offline-access" scope and its configured if consent is
required or not.  Since we have never had proper scope support (as
Pedro kept telling me over and over), the role-based way was the only
way to do this sort of thing.

On Wed, Apr 4, 2018 at 11:42 AM, Thomas Darimont
<thomas.darimont at googlemail.com> wrote:
> I think one scenario where a user needs to grant offline-access
> to client-a for another client-b is integrating with third-party apps.
>
> A third-party app could be represented as a client in Keycloak in order
> to define client specific roles and assign them to a user.
> This third-party app might periodically request data from a
> bearer-only backend-service client on behalf of the user,
> without requiring the user to be logged in all the time.
> Also the third-party may not necessarily be (fully) integrated with
> Keycloak.
>
> A user grants offline-access to the third-party client via a initial
> "connect step".
> In the connect step the user is asked for consent to grant offline-access
> (including other scopes)
> to the third-party client whose roles include an access/reader/user role for
> backend-service.
>
> The third-party client now receives a new refresh-token (offline-token)
> which enables
> the third-party client to retrieve new access-tokens for requesting data
> from the backend-service.
>
> The user can now see the granted offline-access consent for the third-party
> application
> in the applications section of the account page.
> If the user wants to deactivate access for the third-party app, he just
> removes the
> granted offline-access scope in the account page. Once the access-token
> currently used by
> the third-party client has timed-out it cannot request new access-tokens
> anymore.
>
> Currently granting offline-access to a client is quite an extensive
> permission
> since it might enable a third-party service to access other clients as well
> thus clients need apply some additional checks for tokens retrieved for
> offline-access.
>
> With the support for more flexible custom scopes this can be mitigated a bit
> by defining
> custom scopes like "timesheet.read" that encompasses or are combined with
> offline-access.
>
> I demonstrated such an integration scenario to S?bastien Blanc at the
> JavaLand conference.
>
> Cheers,
> Thomas
>
> 2018-04-04 14:12 GMT+02:00 Marek Posolda <mposolda at redhat.com>:
>>
>> Yes, but users can be theoretically aware of it and manually add
>> "scope=offline_access" to the URL and have the offline token
>> successfully issued. Our public clients are allowed to request offline
>> tokens, so user will have offline token as well and use it anytime later
>> without require other re-authentication. But I am not sure if it's real
>> concern or not...
>>
>> I agree we can remove this. We can see if people claim that they want to
>> add it back...
>>
>>
>> Marek
>>
>> Dne 4.4.2018 v 14:00 Bill Burke napsal(a):
>> > Users don't request offline access.  Applications do.  Users will not
>> > even know about OIDC, Oauth, offline access etc...
>> >
>> > On Wed, Apr 4, 2018 at 7:48 AM, Marek Posolda <mposolda at redhat.com>
>> > wrote:
>> >> I was thinking that people may have usecase, when they don't want all
>> >> users
>> >> to allow automatically ask for offline tokens? Currently offline_access
>> >> is
>> >> realm default role, so all users are automatically allowed to "request"
>> >> offline tokens. But was thinking that someone may want also the
>> >> opposite
>> >> use-case. For example allow just admin user to request offline tokens,
>> >> but
>> >> ensure that other users are not allowed to request it.
>> >>
>> >> If you think, we can remove this capability. We can see if people
>> >> claims
>> >> that they want to add it back :) Nobody specifically requested that
>> >> capability as it's there since the beginning of the offline tokens
>> >> support.
>> >>
>> >> In clientScope PR, there is "offline_access" client scope, but
>> >> "offline_access" realm role is also still there and it's assigned as
>> >> "role
>> >> scope mapping" to the offline_access clientScope. So clientScope PR
>> >> still
>> >> requires users to be in "offline_access" role. If you want to change
>> >> the
>> >> behaviour, it will be nice to do that after clientScope PR is merged,
>> >> however if it blocks you, it's likely fine to do it now. The
>> >> clientScope PR
>> >> will then need to be updated later as there would be some conflicts...
>> >>
>> >> Marek
>> >>
>> >>
>> >> Dne 3.4.2018 v 11:21 Stian Thorgersen napsal(a):
>> >>
>> >>> +1
>> >>>
>> >>> On 3 April 2018 at 00:16, Bill Burke <bburke at redhat.com> wrote:
>> >>>
>> >>>> To enable offline access the user must have the offline access role
>> >>>> and the client must have that role in its scope...
>> >>>>
>> >>>> This just doesn't seem right to me.  IMO, this shouldn't be something
>> >>>> you assign permission to a user.  Its solely a client permission and
>> >>>> should not be something role-based.  Instead the client should be
>> >>>> marked as allowing to ask for offline access and whether or not the
>> >>>> client must ask consent for this.
>> >>>>
>> >>>> --
>> >>>> Bill Burke
>> >>>> Red Hat
>> >>>> _______________________________________________
>> >>>> keycloak-dev mailing list
>> >>>> keycloak-dev at lists.jboss.org
>> >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> >>>>
>> >>> _______________________________________________
>> >>> keycloak-dev mailing list
>> >>> keycloak-dev at lists.jboss.org
>> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> >>
>> >>
>> >
>> >
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>



-- 
Bill Burke
Red Hat


From thomas.darimont at googlemail.com  Wed Apr  4 12:23:32 2018
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Wed, 4 Apr 2018 18:23:32 +0200
Subject: [keycloak-dev] offline access permission incorrect?
In-Reply-To: <CABRXCmwM9PLzPoHNMxnisPc-Et_fs_tX89v6nRV9_y3LMHyH1w@mail.gmail.com>
References: <CABRXCmz9QQTC8TZYvcjnhskOiU=z0Vw8cfdm-DSkqKnvJn3v1Q@mail.gmail.com>
	<CAJgngAc_OM6G3deyGVbfAxkRC0zx6xCcnEdn4_ywBq61_vXtVA@mail.gmail.com>
	<eae48ea9-6163-568e-b61c-13fe7ed7b832@redhat.com>
	<CABRXCmzy=TtdoWrK3-QU2XdmCm-RbanO9_iiGGPA_Lg2t_Bnxw@mail.gmail.com>
	<e1e6057c-8fd1-2377-6f7a-64c6634709f2@redhat.com>
	<CAK-7U1hrvbTYmTYC85RnoLKOa2kVAjjznPQo1-0YKLyiBhcmug@mail.gmail.com>
	<CABRXCmwM9PLzPoHNMxnisPc-Et_fs_tX89v6nRV9_y3LMHyH1w@mail.gmail.com>
Message-ID: <CAK-7U1hzHLBp0MaYm=P+eSd0szaKiNF1WJDQ1-NfdSyn5hkCQw@mail.gmail.com>

I'd say I agree with you but I haven't fully digested Marek's client scope
proposal yet, need to give it a spin first.

To summarize what we currently have:
A client X (with consent required enabled) may require offline-access to
request data from another backend-service.
When a user accesses an application part of X that requires data from a
backend-service then X may redirect the user
to a consent page asking the user to give consent to enable X to use
offline-access.
If the user grants this consent X will retrieve the offline-token (special
refresh-token) which enables X to retrieve
access-tokens for accessing the backend-service on the users behalf but
without requiring user interaction.

That's how it currently works.

It works great, but as said the client X can access the backend-service as
long as it's current access-token is valid
even though the user might have just removed the offline-access capability
for client X.
It would be great if removal of consent would trigger a request to the
configured admin-url to inform
a client that consent was removed which could then instruct the client X to
destroy the current access-token.

Further more it might also be handy to be able to have hierarchical scopes
like we currently have for roles
(don't know whether this is already in Marek's proposal). So one could say
offline-support for client X
includes/requires consent for scope S1 and S2 or event better: scope
"thirdparty-access" includes/requires consent
for offline_access and scope S1 and S2.
This would enable to configure different access scenarios without requiring
clients to know all scopes in detail.

Regarding the limited scope support:
Yes, I also think that the scope support is currently a bit inflexible due
to the tight coupling to roles.
Other systems like the UAA OAuth Server of Cloud Foundry use a more
flexible scope model:
https://github.com/cloudfoundry/uaa/blob/master/docs/UAA-Security.md#token-scope-rules
which is also a bit too generic IMHO since they even treat roles /
authorities as scope.


2018-04-04 17:46 GMT+02:00 Bill Burke <bburke at redhat.com>:

> Thomas, so you're agreeing with me?    I think Marek's client scope
> work should be the basis of allowing offline access.  Client is can
> ask for "offline-access" scope and its configured if consent is
> required or not.  Since we have never had proper scope support (as
> Pedro kept telling me over and over), the role-based way was the only
> way to do this sort of thing.
>
> On Wed, Apr 4, 2018 at 11:42 AM, Thomas Darimont
> <thomas.darimont at googlemail.com> wrote:
> > I think one scenario where a user needs to grant offline-access
> > to client-a for another client-b is integrating with third-party apps.
> >
> > A third-party app could be represented as a client in Keycloak in order
> > to define client specific roles and assign them to a user.
> > This third-party app might periodically request data from a
> > bearer-only backend-service client on behalf of the user,
> > without requiring the user to be logged in all the time.
> > Also the third-party may not necessarily be (fully) integrated with
> > Keycloak.
> >
> > A user grants offline-access to the third-party client via a initial
> > "connect step".
> > In the connect step the user is asked for consent to grant offline-access
> > (including other scopes)
> > to the third-party client whose roles include an access/reader/user role
> for
> > backend-service.
> >
> > The third-party client now receives a new refresh-token (offline-token)
> > which enables
> > the third-party client to retrieve new access-tokens for requesting data
> > from the backend-service.
> >
> > The user can now see the granted offline-access consent for the
> third-party
> > application
> > in the applications section of the account page.
> > If the user wants to deactivate access for the third-party app, he just
> > removes the
> > granted offline-access scope in the account page. Once the access-token
> > currently used by
> > the third-party client has timed-out it cannot request new access-tokens
> > anymore.
> >
> > Currently granting offline-access to a client is quite an extensive
> > permission
> > since it might enable a third-party service to access other clients as
> well
> > thus clients need apply some additional checks for tokens retrieved for
> > offline-access.
> >
> > With the support for more flexible custom scopes this can be mitigated a
> bit
> > by defining
> > custom scopes like "timesheet.read" that encompasses or are combined with
> > offline-access.
> >
> > I demonstrated such an integration scenario to S?bastien Blanc at the
> > JavaLand conference.
> >
> > Cheers,
> > Thomas
> >
> > 2018-04-04 14:12 GMT+02:00 Marek Posolda <mposolda at redhat.com>:
> >>
> >> Yes, but users can be theoretically aware of it and manually add
> >> "scope=offline_access" to the URL and have the offline token
> >> successfully issued. Our public clients are allowed to request offline
> >> tokens, so user will have offline token as well and use it anytime later
> >> without require other re-authentication. But I am not sure if it's real
> >> concern or not...
> >>
> >> I agree we can remove this. We can see if people claim that they want to
> >> add it back...
> >>
> >>
> >> Marek
> >>
> >> Dne 4.4.2018 v 14:00 Bill Burke napsal(a):
> >> > Users don't request offline access.  Applications do.  Users will not
> >> > even know about OIDC, Oauth, offline access etc...
> >> >
> >> > On Wed, Apr 4, 2018 at 7:48 AM, Marek Posolda <mposolda at redhat.com>
> >> > wrote:
> >> >> I was thinking that people may have usecase, when they don't want all
> >> >> users
> >> >> to allow automatically ask for offline tokens? Currently
> offline_access
> >> >> is
> >> >> realm default role, so all users are automatically allowed to
> "request"
> >> >> offline tokens. But was thinking that someone may want also the
> >> >> opposite
> >> >> use-case. For example allow just admin user to request offline
> tokens,
> >> >> but
> >> >> ensure that other users are not allowed to request it.
> >> >>
> >> >> If you think, we can remove this capability. We can see if people
> >> >> claims
> >> >> that they want to add it back :) Nobody specifically requested that
> >> >> capability as it's there since the beginning of the offline tokens
> >> >> support.
> >> >>
> >> >> In clientScope PR, there is "offline_access" client scope, but
> >> >> "offline_access" realm role is also still there and it's assigned as
> >> >> "role
> >> >> scope mapping" to the offline_access clientScope. So clientScope PR
> >> >> still
> >> >> requires users to be in "offline_access" role. If you want to change
> >> >> the
> >> >> behaviour, it will be nice to do that after clientScope PR is merged,
> >> >> however if it blocks you, it's likely fine to do it now. The
> >> >> clientScope PR
> >> >> will then need to be updated later as there would be some
> conflicts...
> >> >>
> >> >> Marek
> >> >>
> >> >>
> >> >> Dne 3.4.2018 v 11:21 Stian Thorgersen napsal(a):
> >> >>
> >> >>> +1
> >> >>>
> >> >>> On 3 April 2018 at 00:16, Bill Burke <bburke at redhat.com> wrote:
> >> >>>
> >> >>>> To enable offline access the user must have the offline access role
> >> >>>> and the client must have that role in its scope...
> >> >>>>
> >> >>>> This just doesn't seem right to me.  IMO, this shouldn't be
> something
> >> >>>> you assign permission to a user.  Its solely a client permission
> and
> >> >>>> should not be something role-based.  Instead the client should be
> >> >>>> marked as allowing to ask for offline access and whether or not the
> >> >>>> client must ask consent for this.
> >> >>>>
> >> >>>> --
> >> >>>> Bill Burke
> >> >>>> Red Hat
> >> >>>> _______________________________________________
> >> >>>> keycloak-dev mailing list
> >> >>>> keycloak-dev at lists.jboss.org
> >> >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >> >>>>
> >> >>> _______________________________________________
> >> >>> keycloak-dev mailing list
> >> >>> keycloak-dev at lists.jboss.org
> >> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >> >>
> >> >>
> >> >
> >> >
> >>
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> >
>
>
>
> --
> Bill Burke
> Red Hat
>

From bburke at redhat.com  Wed Apr  4 17:53:50 2018
From: bburke at redhat.com (Bill Burke)
Date: Wed, 4 Apr 2018 17:53:50 -0400
Subject: [keycloak-dev] wildfly pkg manager changes everything
Message-ID: <CABRXCmzTL89zT7tPUXDLoEViq6Bjf6exQUiOEqqcGF-SGFNEgQ@mail.gmail.com>

Had a long talk with Jason Greene today and one of the things that
came up was the Wildfly Package Manager that is being developed.

You'll be able to pull in the exact subsystems, modules, you want,
even  as fine grain as saying "I don't want EJB remoting".  You'll be
able to update,  at will,  all or parts of the install.  This
completely changes patch management for all of us.  You'll be able to
easily create and extend distros and service packs.  Service packs
that depend on service packs.  A lot of interesting combinations. They
are also looking into various ways to organize an image hierarchy so
even how we build images for keycloak may change.  It is all maven
artifact based, which means that a service pack definitions,
distributions, images, installations are measured in kilobytes rather
than hundreds of megabytes as these definitions point into maven
repos.  Its not limited to Java either and will be able to really
package manage anything...cross platform as its written in Java.

This brings a smile to my face as we can ditch this whole monolithic
distribution approach we currently have with bare metal and
docker/openshift.  Keycloak, IMO, has always been more of an
integration platform than a black box appliance and this will be a big
boon to developers that want to optimize their distribution, memory
consumption, image size, etc.
-- 
Bill Burke
Red Hat

From sthorger at redhat.com  Thu Apr  5 02:28:03 2018
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 5 Apr 2018 08:28:03 +0200
Subject: [keycloak-dev] wildfly pkg manager changes everything
In-Reply-To: <CABRXCmzTL89zT7tPUXDLoEViq6Bjf6exQUiOEqqcGF-SGFNEgQ@mail.gmail.com>
References: <CABRXCmzTL89zT7tPUXDLoEViq6Bjf6exQUiOEqqcGF-SGFNEgQ@mail.gmail.com>
Message-ID: <CAJgngAexdXw-x9xnoKkeEJMRJHJD7o-LMfJLN-8T3rNai2PrFQ@mail.gmail.com>

I don't have the full picture yet on how this will all work, but it sounds
really promising.

There are at least 3 categories of users for Keycloak:

* Black box users - built-in features and config options are sufficient
* Middle ground - customized themes and a few custom providers, but still
happy with a default setup with regards to subsystems (and limited use of
JEE features)
* Integration - more heavily customized and have a need to add additional
subsystems on top of what we bring

I would believe most users land in the first two and would be happy with a
single distro download rather than having to install a package manager to
then install. For the latter the approach to combine your own would be
great.

Same applies to Docker and OpenShift distributions. We still need a ready
out of the box option as well as the "install your own" option.

On 4 April 2018 at 23:53, Bill Burke <bburke at redhat.com> wrote:

> Had a long talk with Jason Greene today and one of the things that
> came up was the Wildfly Package Manager that is being developed.
>
> You'll be able to pull in the exact subsystems, modules, you want,
> even  as fine grain as saying "I don't want EJB remoting".  You'll be
> able to update,  at will,  all or parts of the install.  This
> completely changes patch management for all of us.  You'll be able to
> easily create and extend distros and service packs.  Service packs
> that depend on service packs.  A lot of interesting combinations. They
> are also looking into various ways to organize an image hierarchy so
> even how we build images for keycloak may change.  It is all maven
> artifact based, which means that a service pack definitions,
> distributions, images, installations are measured in kilobytes rather
> than hundreds of megabytes as these definitions point into maven
> repos.  Its not limited to Java either and will be able to really
> package manage anything...cross platform as its written in Java.
>
> This brings a smile to my face as we can ditch this whole monolithic
> distribution approach we currently have with bare metal and
> docker/openshift.  Keycloak, IMO, has always been more of an
> integration platform than a black box appliance and this will be a big
> boon to developers that want to optimize their distribution, memory
> consumption, image size, etc.
> --
> Bill Burke
> Red Hat
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sthorger at redhat.com  Thu Apr  5 08:04:14 2018
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 5 Apr 2018 14:04:14 +0200
Subject: [keycloak-dev] Token validator endpoint (for humans)
Message-ID: <CAJgngAf7fEw6o5sMdHNLMJkCkAFcANE5rfBe4e_Lv+6=MUttww@mail.gmail.com>

I added an example token validator endpoint that I needed for some
demonstration purposes. Question would this be useful to add directly to
Keycloak?

It provides a simple form where you can paste in the base64 token. It will
then output the header, claims and whether or not the token is valid. It
uses realm keys to verify the signature so you don't have to paste that in
manually (like you do on jwt.io).

For those to lazy to try it out I've attached a screenshot.

From bruno at abstractj.org  Thu Apr  5 09:17:25 2018
From: bruno at abstractj.org (Bruno Oliveira)
Date: Thu, 5 Apr 2018 10:17:25 -0300
Subject: [keycloak-dev] Token validator endpoint (for humans)
In-Reply-To: <CAJgngAf7fEw6o5sMdHNLMJkCkAFcANE5rfBe4e_Lv+6=MUttww@mail.gmail.com>
References: <CAJgngAf7fEw6o5sMdHNLMJkCkAFcANE5rfBe4e_Lv+6=MUttww@mail.gmail.com>
Message-ID: <20180405131725.GB18020@abstractj.org>



On 2018-04-05, Stian Thorgersen wrote:
> I added an example token validator endpoint that I needed for some
> demonstration purposes. Question would this be useful to add directly to
> Keycloak?
> 
> It provides a simple form where you can paste in the base64 token. It will
> then output the header, claims and whether or not the token is valid. It
> uses realm keys to verify the signature so you don't have to paste that in
> manually (like you do on jwt.io).

Where is the link to give it a try?


> 
> For those to lazy to try it out I've attached a screenshot.

It seems like your screenshot was blocked by the mailing list.

> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


-- 

abstractj

From sthorger at redhat.com  Thu Apr  5 09:22:24 2018
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 5 Apr 2018 15:22:24 +0200
Subject: [keycloak-dev] Token validator endpoint (for humans)
In-Reply-To: <20180405131725.GB18020@abstractj.org>
References: <CAJgngAf7fEw6o5sMdHNLMJkCkAFcANE5rfBe4e_Lv+6=MUttww@mail.gmail.com>
	<20180405131725.GB18020@abstractj.org>
Message-ID: <CAJgngAeTvqCEGcE6pSLuNdaYkravM+EZEfha9G5Gsp41h8CKhg@mail.gmail.com>

Forgot the link:

https://github.com/stianst/keycloak-experimental/tree/master/token-validation

Hm... need to tune the mailing list so it's possible to include images. I
thought it already was.

On 5 April 2018 at 15:17, Bruno Oliveira <bruno at abstractj.org> wrote:

>
>
> On 2018-04-05, Stian Thorgersen wrote:
> > I added an example token validator endpoint that I needed for some
> > demonstration purposes. Question would this be useful to add directly to
> > Keycloak?
> >
> > It provides a simple form where you can paste in the base64 token. It
> will
> > then output the header, claims and whether or not the token is valid. It
> > uses realm keys to verify the signature so you don't have to paste that
> in
> > manually (like you do on jwt.io).
>
> Where is the link to give it a try?
>
>
> >
> > For those to lazy to try it out I've attached a screenshot.
>
> It seems like your screenshot was blocked by the mailing list.
>
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
> --
>
> abstractj
>

From sthorger at redhat.com  Thu Apr  5 09:24:36 2018
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 5 Apr 2018 15:24:36 +0200
Subject: [keycloak-dev] Token validator endpoint (for humans)
In-Reply-To: <CAJgngAeTvqCEGcE6pSLuNdaYkravM+EZEfha9G5Gsp41h8CKhg@mail.gmail.com>
References: <CAJgngAf7fEw6o5sMdHNLMJkCkAFcANE5rfBe4e_Lv+6=MUttww@mail.gmail.com>
	<20180405131725.GB18020@abstractj.org>
	<CAJgngAeTvqCEGcE6pSLuNdaYkravM+EZEfha9G5Gsp41h8CKhg@mail.gmail.com>
Message-ID: <CAJgngAcvks3yOzg=W18HZaUjC8XYg8-HJK0-QzYnD6804ZcJMA@mail.gmail.com>

Trying to attach again

On 5 April 2018 at 15:22, Stian Thorgersen <sthorger at redhat.com> wrote:

> Forgot the link:
>
> https://github.com/stianst/keycloak-experimental/tree/
> master/token-validation
>
> Hm... need to tune the mailing list so it's possible to include images. I
> thought it already was.
>
> On 5 April 2018 at 15:17, Bruno Oliveira <bruno at abstractj.org> wrote:
>
>>
>>
>> On 2018-04-05, Stian Thorgersen wrote:
>> > I added an example token validator endpoint that I needed for some
>> > demonstration purposes. Question would this be useful to add directly to
>> > Keycloak?
>> >
>> > It provides a simple form where you can paste in the base64 token. It
>> will
>> > then output the header, claims and whether or not the token is valid. It
>> > uses realm keys to verify the signature so you don't have to paste that
>> in
>> > manually (like you do on jwt.io).
>>
>> Where is the link to give it a try?
>>
>>
>> >
>> > For those to lazy to try it out I've attached a screenshot.
>>
>> It seems like your screenshot was blocked by the mailing list.
>>
>> > _______________________________________________
>> > keycloak-dev mailing list
>> > keycloak-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>> --
>>
>> abstractj
>>
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: token-validator.png
Type: image/png
Size: 178357 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20180405/f9768bb9/attachment-0001.png 

From sthorger at redhat.com  Thu Apr  5 09:33:59 2018
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 5 Apr 2018 15:33:59 +0200
Subject: [keycloak-dev] OAuth 2.0 Security Best Current Practice
Message-ID: <CAJgngAcdm3UCiJxqYLzN3Mvn1zsjWv=prrJk5hLfps=DrE=7yg@mail.gmail.com>

https://tools.ietf.org/html/draft-ietf-oauth-security-topics-05

From bburke at redhat.com  Thu Apr  5 09:41:45 2018
From: bburke at redhat.com (Bill Burke)
Date: Thu, 5 Apr 2018 09:41:45 -0400
Subject: [keycloak-dev] Token validator endpoint (for humans)
In-Reply-To: <CAJgngAf7fEw6o5sMdHNLMJkCkAFcANE5rfBe4e_Lv+6=MUttww@mail.gmail.com>
References: <CAJgngAf7fEw6o5sMdHNLMJkCkAFcANE5rfBe4e_Lv+6=MUttww@mail.gmail.com>
Message-ID: <CABRXCmyQ8=CcgNV=3m1m0B9cRTOanxw_jyFPJqFfwHp=AHuZ=Q@mail.gmail.com>

+1

Question, how are you adding this endpoint?  Under ../protocol/oidc?

The kubernetes integration needs a similar validation endpoint that
outputs a document that kubernetes consumes.  What I did is create an
entirely new protocol.  Maybe a protocol extension endpoint would be
better?

Object createExtensionEndpoint(String providerId)

The returned Object would be a JAX-RS sub resource.

Then the base endpoint would be .../protocol/oidc/extensions/{provider-id}



On Thu, Apr 5, 2018 at 8:04 AM, Stian Thorgersen <sthorger at redhat.com> wrote:
> I added an example token validator endpoint that I needed for some
> demonstration purposes. Question would this be useful to add directly to
> Keycloak?
>
> It provides a simple form where you can paste in the base64 token. It will
> then output the header, claims and whether or not the token is valid. It
> uses realm keys to verify the signature so you don't have to paste that in
> manually (like you do on jwt.io).
>
> For those to lazy to try it out I've attached a screenshot.
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



-- 
Bill Burke
Red Hat

From sthorger at redhat.com  Thu Apr  5 09:48:27 2018
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 5 Apr 2018 15:48:27 +0200
Subject: [keycloak-dev] Token validator endpoint (for humans)
In-Reply-To: <CABRXCmyQ8=CcgNV=3m1m0B9cRTOanxw_jyFPJqFfwHp=AHuZ=Q@mail.gmail.com>
References: <CAJgngAf7fEw6o5sMdHNLMJkCkAFcANE5rfBe4e_Lv+6=MUttww@mail.gmail.com>
	<CABRXCmyQ8=CcgNV=3m1m0B9cRTOanxw_jyFPJqFfwHp=AHuZ=Q@mail.gmail.com>
Message-ID: <CAJgngAcwhwZq_MWMhvD7WR+rGZTMwzWBTJGe+qDM=GOzh49Xfw@mail.gmail.com>

We already have a realm resource provider which adds directly under realm
(/auth/realms/<realm name>/<resource provider id>). See
https://github.com/stianst/keycloak-experimental/blob/master/token-validation/src/main/java/org/keycloak/experimental/token/TokenValidatorFactory.java#L31
.

The URL for this thing is: /auth/realms/master/token-validator

Perhaps we could extend the realm resource provider to allow not just
adding directly under realms, but under any arbitrary path? Not sure if
RestEasy allows that though.

On 5 April 2018 at 15:41, Bill Burke <bburke at redhat.com> wrote:

> +1
>
> Question, how are you adding this endpoint?  Under ../protocol/oidc?
>
> The kubernetes integration needs a similar validation endpoint that
> outputs a document that kubernetes consumes.  What I did is create an
> entirely new protocol.  Maybe a protocol extension endpoint would be
> better?
>
> Object createExtensionEndpoint(String providerId)
>
> The returned Object would be a JAX-RS sub resource.
>
> Then the base endpoint would be .../protocol/oidc/extensions/{provider-id}
>
>
>
> On Thu, Apr 5, 2018 at 8:04 AM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
> > I added an example token validator endpoint that I needed for some
> > demonstration purposes. Question would this be useful to add directly to
> > Keycloak?
> >
> > It provides a simple form where you can paste in the base64 token. It
> will
> > then output the header, claims and whether or not the token is valid. It
> > uses realm keys to verify the signature so you don't have to paste that
> in
> > manually (like you do on jwt.io).
> >
> > For those to lazy to try it out I've attached a screenshot.
> >
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
> --
> Bill Burke
> Red Hat
>

From bburke at redhat.com  Thu Apr  5 09:56:43 2018
From: bburke at redhat.com (Bill Burke)
Date: Thu, 5 Apr 2018 09:56:43 -0400
Subject: [keycloak-dev] Token validator endpoint (for humans)
In-Reply-To: <CAJgngAcwhwZq_MWMhvD7WR+rGZTMwzWBTJGe+qDM=GOzh49Xfw@mail.gmail.com>
References: <CAJgngAf7fEw6o5sMdHNLMJkCkAFcANE5rfBe4e_Lv+6=MUttww@mail.gmail.com>
	<CABRXCmyQ8=CcgNV=3m1m0B9cRTOanxw_jyFPJqFfwHp=AHuZ=Q@mail.gmail.com>
	<CAJgngAcwhwZq_MWMhvD7WR+rGZTMwzWBTJGe+qDM=GOzh49Xfw@mail.gmail.com>
Message-ID: <CABRXCmx-MgHAOoyDYoYWfzX-7Qo_vv=e4_rbV1bv3fa8qx6--A@mail.gmail.com>

I'll just switch to using that probably.

On Thu, Apr 5, 2018 at 9:48 AM, Stian Thorgersen <sthorger at redhat.com> wrote:
> We already have a realm resource provider which adds directly under realm
> (/auth/realms/<realm name>/<resource provider id>). See
> https://github.com/stianst/keycloak-experimental/blob/master/token-validation/src/main/java/org/keycloak/experimental/token/TokenValidatorFactory.java#L31.
>
> The URL for this thing is: /auth/realms/master/token-validator
>
> Perhaps we could extend the realm resource provider to allow not just adding
> directly under realms, but under any arbitrary path? Not sure if RestEasy
> allows that though.
>
> On 5 April 2018 at 15:41, Bill Burke <bburke at redhat.com> wrote:
>>
>> +1
>>
>> Question, how are you adding this endpoint?  Under ../protocol/oidc?
>>
>> The kubernetes integration needs a similar validation endpoint that
>> outputs a document that kubernetes consumes.  What I did is create an
>> entirely new protocol.  Maybe a protocol extension endpoint would be
>> better?
>>
>> Object createExtensionEndpoint(String providerId)
>>
>> The returned Object would be a JAX-RS sub resource.
>>
>> Then the base endpoint would be .../protocol/oidc/extensions/{provider-id}
>>
>>
>>
>> On Thu, Apr 5, 2018 at 8:04 AM, Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>> > I added an example token validator endpoint that I needed for some
>> > demonstration purposes. Question would this be useful to add directly to
>> > Keycloak?
>> >
>> > It provides a simple form where you can paste in the base64 token. It
>> > will
>> > then output the header, claims and whether or not the token is valid. It
>> > uses realm keys to verify the signature so you don't have to paste that
>> > in
>> > manually (like you do on jwt.io).
>> >
>> > For those to lazy to try it out I've attached a screenshot.
>> >
>> > _______________________________________________
>> > keycloak-dev mailing list
>> > keycloak-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>>
>> --
>> Bill Burke
>> Red Hat
>
>



-- 
Bill Burke
Red Hat

From sthorger at redhat.com  Thu Apr  5 09:58:47 2018
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 5 Apr 2018 15:58:47 +0200
Subject: [keycloak-dev] Token validator endpoint (for humans)
In-Reply-To: <CABRXCmx-MgHAOoyDYoYWfzX-7Qo_vv=e4_rbV1bv3fa8qx6--A@mail.gmail.com>
References: <CAJgngAf7fEw6o5sMdHNLMJkCkAFcANE5rfBe4e_Lv+6=MUttww@mail.gmail.com>
	<CABRXCmyQ8=CcgNV=3m1m0B9cRTOanxw_jyFPJqFfwHp=AHuZ=Q@mail.gmail.com>
	<CAJgngAcwhwZq_MWMhvD7WR+rGZTMwzWBTJGe+qDM=GOzh49Xfw@mail.gmail.com>
	<CABRXCmx-MgHAOoyDYoYWfzX-7Qo_vv=e4_rbV1bv3fa8qx6--A@mail.gmail.com>
Message-ID: <CAJgngAfAFnFi1wydGPNWdM7qPRKRfVC5Zfd-sp_TpA5FULWtRA@mail.gmail.com>

Is there a way we could let it register on any path with RestEasy?

On 5 April 2018 at 15:56, Bill Burke <bburke at redhat.com> wrote:

> I'll just switch to using that probably.
>
> On Thu, Apr 5, 2018 at 9:48 AM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
> > We already have a realm resource provider which adds directly under realm
> > (/auth/realms/<realm name>/<resource provider id>). See
> > https://github.com/stianst/keycloak-experimental/blob/
> master/token-validation/src/main/java/org/keycloak/experimental/token/
> TokenValidatorFactory.java#L31.
> >
> > The URL for this thing is: /auth/realms/master/token-validator
> >
> > Perhaps we could extend the realm resource provider to allow not just
> adding
> > directly under realms, but under any arbitrary path? Not sure if RestEasy
> > allows that though.
> >
> > On 5 April 2018 at 15:41, Bill Burke <bburke at redhat.com> wrote:
> >>
> >> +1
> >>
> >> Question, how are you adding this endpoint?  Under ../protocol/oidc?
> >>
> >> The kubernetes integration needs a similar validation endpoint that
> >> outputs a document that kubernetes consumes.  What I did is create an
> >> entirely new protocol.  Maybe a protocol extension endpoint would be
> >> better?
> >>
> >> Object createExtensionEndpoint(String providerId)
> >>
> >> The returned Object would be a JAX-RS sub resource.
> >>
> >> Then the base endpoint would be .../protocol/oidc/extensions/{
> provider-id}
> >>
> >>
> >>
> >> On Thu, Apr 5, 2018 at 8:04 AM, Stian Thorgersen <sthorger at redhat.com>
> >> wrote:
> >> > I added an example token validator endpoint that I needed for some
> >> > demonstration purposes. Question would this be useful to add directly
> to
> >> > Keycloak?
> >> >
> >> > It provides a simple form where you can paste in the base64 token. It
> >> > will
> >> > then output the header, claims and whether or not the token is valid.
> It
> >> > uses realm keys to verify the signature so you don't have to paste
> that
> >> > in
> >> > manually (like you do on jwt.io).
> >> >
> >> > For those to lazy to try it out I've attached a screenshot.
> >> >
> >> > _______________________________________________
> >> > keycloak-dev mailing list
> >> > keycloak-dev at lists.jboss.org
> >> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> >>
> >>
> >> --
> >> Bill Burke
> >> Red Hat
> >
> >
>
>
>
> --
> Bill Burke
> Red Hat
>

From bburke at redhat.com  Thu Apr  5 10:08:01 2018
From: bburke at redhat.com (Bill Burke)
Date: Thu, 5 Apr 2018 10:08:01 -0400
Subject: [keycloak-dev] Token validator endpoint (for humans)
In-Reply-To: <CAJgngAfAFnFi1wydGPNWdM7qPRKRfVC5Zfd-sp_TpA5FULWtRA@mail.gmail.com>
References: <CAJgngAf7fEw6o5sMdHNLMJkCkAFcANE5rfBe4e_Lv+6=MUttww@mail.gmail.com>
	<CABRXCmyQ8=CcgNV=3m1m0B9cRTOanxw_jyFPJqFfwHp=AHuZ=Q@mail.gmail.com>
	<CAJgngAcwhwZq_MWMhvD7WR+rGZTMwzWBTJGe+qDM=GOzh49Xfw@mail.gmail.com>
	<CABRXCmx-MgHAOoyDYoYWfzX-7Qo_vv=e4_rbV1bv3fa8qx6--A@mail.gmail.com>
	<CAJgngAfAFnFi1wydGPNWdM7qPRKRfVC5Zfd-sp_TpA5FULWtRA@mail.gmail.com>
Message-ID: <CABRXCmzv-p5Up8h5-=oBVTGLQPVt9wRy+a5sQ6xxD8T9=gjoYA@mail.gmail.com>

Its possible and easy if you don't allow hot deployment.   Just add
the provider to the list of classes or objects that define the root of
the JAX-RS tree.

IMO, though I don't see the value.  We'll only want extensions under
/realms/{realm} and under the admin REST API (for token validation).
There's a lot of initialization and work that's done by each layer of
the url scheme.  Especially for admin endpoints.


On Thu, Apr 5, 2018 at 9:58 AM, Stian Thorgersen <sthorger at redhat.com> wrote:
> Is there a way we could let it register on any path with RestEasy?
>
> On 5 April 2018 at 15:56, Bill Burke <bburke at redhat.com> wrote:
>>
>> I'll just switch to using that probably.
>>
>> On Thu, Apr 5, 2018 at 9:48 AM, Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>> > We already have a realm resource provider which adds directly under
>> > realm
>> > (/auth/realms/<realm name>/<resource provider id>). See
>> >
>> > https://github.com/stianst/keycloak-experimental/blob/master/token-validation/src/main/java/org/keycloak/experimental/token/TokenValidatorFactory.java#L31.
>> >
>> > The URL for this thing is: /auth/realms/master/token-validator
>> >
>> > Perhaps we could extend the realm resource provider to allow not just
>> > adding
>> > directly under realms, but under any arbitrary path? Not sure if
>> > RestEasy
>> > allows that though.
>> >
>> > On 5 April 2018 at 15:41, Bill Burke <bburke at redhat.com> wrote:
>> >>
>> >> +1
>> >>
>> >> Question, how are you adding this endpoint?  Under ../protocol/oidc?
>> >>
>> >> The kubernetes integration needs a similar validation endpoint that
>> >> outputs a document that kubernetes consumes.  What I did is create an
>> >> entirely new protocol.  Maybe a protocol extension endpoint would be
>> >> better?
>> >>
>> >> Object createExtensionEndpoint(String providerId)
>> >>
>> >> The returned Object would be a JAX-RS sub resource.
>> >>
>> >> Then the base endpoint would be
>> >> .../protocol/oidc/extensions/{provider-id}
>> >>
>> >>
>> >>
>> >> On Thu, Apr 5, 2018 at 8:04 AM, Stian Thorgersen <sthorger at redhat.com>
>> >> wrote:
>> >> > I added an example token validator endpoint that I needed for some
>> >> > demonstration purposes. Question would this be useful to add directly
>> >> > to
>> >> > Keycloak?
>> >> >
>> >> > It provides a simple form where you can paste in the base64 token. It
>> >> > will
>> >> > then output the header, claims and whether or not the token is valid.
>> >> > It
>> >> > uses realm keys to verify the signature so you don't have to paste
>> >> > that
>> >> > in
>> >> > manually (like you do on jwt.io).
>> >> >
>> >> > For those to lazy to try it out I've attached a screenshot.
>> >> >
>> >> > _______________________________________________
>> >> > keycloak-dev mailing list
>> >> > keycloak-dev at lists.jboss.org
>> >> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> >>
>> >>
>> >>
>> >> --
>> >> Bill Burke
>> >> Red Hat
>> >
>> >
>>
>>
>>
>> --
>> Bill Burke
>> Red Hat
>
>



-- 
Bill Burke
Red Hat

From psilva at redhat.com  Thu Apr  5 10:23:44 2018
From: psilva at redhat.com (Pedro Igor Silva)
Date: Thu, 5 Apr 2018 11:23:44 -0300
Subject: [keycloak-dev] Token validator endpoint (for humans)
In-Reply-To: <CAJgngAf7fEw6o5sMdHNLMJkCkAFcANE5rfBe4e_Lv+6=MUttww@mail.gmail.com>
References: <CAJgngAf7fEw6o5sMdHNLMJkCkAFcANE5rfBe4e_Lv+6=MUttww@mail.gmail.com>
Message-ID: <CAJrcDBfBROrqPCyF6et15EFx=ZZ=FGKuZu_1EEpsMG0OwjuFfA@mail.gmail.com>

Although very helpful, people may want to disable this when in production.

On Thu, Apr 5, 2018 at 9:04 AM, Stian Thorgersen <sthorger at redhat.com>
wrote:

> I added an example token validator endpoint that I needed for some
> demonstration purposes. Question would this be useful to add directly to
> Keycloak?
>
> It provides a simple form where you can paste in the base64 token. It will
> then output the header, claims and whether or not the token is valid. It
> uses realm keys to verify the signature so you don't have to paste that in
> manually (like you do on jwt.io).
>
> For those to lazy to try it out I've attached a screenshot.
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sblanc at redhat.com  Thu Apr  5 10:30:16 2018
From: sblanc at redhat.com (Sebastien Blanc)
Date: Thu, 5 Apr 2018 16:30:16 +0200
Subject: [keycloak-dev] Token validator endpoint (for humans)
In-Reply-To: <CAJgngAf7fEw6o5sMdHNLMJkCkAFcANE5rfBe4e_Lv+6=MUttww@mail.gmail.com>
References: <CAJgngAf7fEw6o5sMdHNLMJkCkAFcANE5rfBe4e_Lv+6=MUttww@mail.gmail.com>
Message-ID: <CAMZCGg80Hmt6CXNHrmxsnH9m_Lc2XQjdozUvqLtg6tctqxuwUw@mail.gmail.com>

Really nice !

I just gave it a try and it works perfectly.

I was thinking that we could maybe add an extra @POST endpoint that returns
a json object so that third parties could integrate with this service, wdyt
?




On Thu, Apr 5, 2018 at 2:04 PM, Stian Thorgersen <sthorger at redhat.com>
wrote:

> I added an example token validator endpoint that I needed for some
> demonstration purposes. Question would this be useful to add directly to
> Keycloak?
>
> It provides a simple form where you can paste in the base64 token. It will
> then output the header, claims and whether or not the token is valid. It
> uses realm keys to verify the signature so you don't have to paste that in
> manually (like you do on jwt.io).
>
> For those to lazy to try it out I've attached a screenshot.
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From psilva at redhat.com  Thu Apr  5 10:41:50 2018
From: psilva at redhat.com (Pedro Igor Silva)
Date: Thu, 5 Apr 2018 11:41:50 -0300
Subject: [keycloak-dev] Pushing Claims from Policy Enforcer
Message-ID: <CAJrcDBd32CLhW5=P8SCKMv0FrNwB7GxhKtRWhh8qxaNjRj+4Fw@mail.gmail.com>

Hi,

I'm currently working on https://issues.jboss.org/browse/KEYCLOAK-4903.

This is all about allowing applications to push arbitrary claims to
Keycloak prior to evaluating permissions on the server. A simple example to
illustrate the idea: a request arrives you extract what you want from there
(parameters, headers, etc) and "push" the information from the request as
claims in order to evaluate your permissions.

There are endless possibilities on what you can push and how.

>From a design perspective, I was thinking about providing a SPI on the
adapter side (as simple as using ServiceLoader) to load built-in and
user-defined "claim information points". Examples of built-in
implementations would be:

* Extract parameters
* Extract headers
* Extract path parameters
* Extract cookies
* Invoke an external "policy information point"

What do you think ?

Regards.
Pedro Igor

From sthorger at redhat.com  Thu Apr  5 10:45:23 2018
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 5 Apr 2018 16:45:23 +0200
Subject: [keycloak-dev] Token validator endpoint (for humans)
In-Reply-To: <CAJrcDBfBROrqPCyF6et15EFx=ZZ=FGKuZu_1EEpsMG0OwjuFfA@mail.gmail.com>
References: <CAJgngAf7fEw6o5sMdHNLMJkCkAFcANE5rfBe4e_Lv+6=MUttww@mail.gmail.com>
	<CAJrcDBfBROrqPCyF6et15EFx=ZZ=FGKuZu_1EEpsMG0OwjuFfA@mail.gmail.com>
Message-ID: <CAJgngAdGBi2GD9J8UjC8zEKLorTxRqaBqgOMM+SUBOYiVSYkQA@mail.gmail.com>

Why?

On 5 April 2018 at 16:23, Pedro Igor Silva <psilva at redhat.com> wrote:

> Although very helpful, people may want to disable this when in production.
>
> On Thu, Apr 5, 2018 at 9:04 AM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> I added an example token validator endpoint that I needed for some
>> demonstration purposes. Question would this be useful to add directly to
>> Keycloak?
>>
>> It provides a simple form where you can paste in the base64 token. It will
>> then output the header, claims and whether or not the token is valid. It
>> uses realm keys to verify the signature so you don't have to paste that in
>> manually (like you do on jwt.io).
>>
>> For those to lazy to try it out I've attached a screenshot.
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>

From sthorger at redhat.com  Thu Apr  5 10:46:04 2018
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 5 Apr 2018 16:46:04 +0200
Subject: [keycloak-dev] Token validator endpoint (for humans)
In-Reply-To: <CAMZCGg80Hmt6CXNHrmxsnH9m_Lc2XQjdozUvqLtg6tctqxuwUw@mail.gmail.com>
References: <CAJgngAf7fEw6o5sMdHNLMJkCkAFcANE5rfBe4e_Lv+6=MUttww@mail.gmail.com>
	<CAMZCGg80Hmt6CXNHrmxsnH9m_Lc2XQjdozUvqLtg6tctqxuwUw@mail.gmail.com>
Message-ID: <CAJgngAdZOFoky1ZSiPqTmcXvic7LserzjSkGipAcJeTiwzk_bw@mail.gmail.com>

This is not a third party rest service. Just a tool for humans. There's
already a rest service that lets you check tokens it's the token
introspection endpoint.

On 5 April 2018 at 16:30, Sebastien Blanc <sblanc at redhat.com> wrote:

> Really nice !
>
> I just gave it a try and it works perfectly.
>
> I was thinking that we could maybe add an extra @POST endpoint that
> returns a json object so that third parties could integrate with this
> service, wdyt ?
>
>
>
>
> On Thu, Apr 5, 2018 at 2:04 PM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> I added an example token validator endpoint that I needed for some
>> demonstration purposes. Question would this be useful to add directly to
>> Keycloak?
>>
>> It provides a simple form where you can paste in the base64 token. It will
>> then output the header, claims and whether or not the token is valid. It
>> uses realm keys to verify the signature so you don't have to paste that in
>> manually (like you do on jwt.io).
>>
>> For those to lazy to try it out I've attached a screenshot.
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>

From sthorger at redhat.com  Thu Apr  5 10:47:47 2018
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 5 Apr 2018 16:47:47 +0200
Subject: [keycloak-dev] Token validator endpoint (for humans)
In-Reply-To: <CAJgngAdGBi2GD9J8UjC8zEKLorTxRqaBqgOMM+SUBOYiVSYkQA@mail.gmail.com>
References: <CAJgngAf7fEw6o5sMdHNLMJkCkAFcANE5rfBe4e_Lv+6=MUttww@mail.gmail.com>
	<CAJrcDBfBROrqPCyF6et15EFx=ZZ=FGKuZu_1EEpsMG0OwjuFfA@mail.gmail.com>
	<CAJgngAdGBi2GD9J8UjC8zEKLorTxRqaBqgOMM+SUBOYiVSYkQA@mail.gmail.com>
Message-ID: <CAJgngAcrHeRUXfzOMQFuFqjNHfo5jK27JQrB0V0iK16GEHiuNQ@mail.gmail.com>

Just to add - we can easily make it a feature that can be enabled/disabled
through the profile stuff, but was just curious to why you thought it would
be needed to disable it.

On 5 April 2018 at 16:45, Stian Thorgersen <sthorger at redhat.com> wrote:

> Why?
>
> On 5 April 2018 at 16:23, Pedro Igor Silva <psilva at redhat.com> wrote:
>
>> Although very helpful, people may want to disable this when in production.
>>
>> On Thu, Apr 5, 2018 at 9:04 AM, Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>>
>>> I added an example token validator endpoint that I needed for some
>>> demonstration purposes. Question would this be useful to add directly to
>>> Keycloak?
>>>
>>> It provides a simple form where you can paste in the base64 token. It
>>> will
>>> then output the header, claims and whether or not the token is valid. It
>>> uses realm keys to verify the signature so you don't have to paste that
>>> in
>>> manually (like you do on jwt.io).
>>>
>>> For those to lazy to try it out I've attached a screenshot.
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>>
>

From psilva at redhat.com  Thu Apr  5 10:58:05 2018
From: psilva at redhat.com (Pedro Igor Silva)
Date: Thu, 5 Apr 2018 11:58:05 -0300
Subject: [keycloak-dev] Token validator endpoint (for humans)
In-Reply-To: <CAJgngAcrHeRUXfzOMQFuFqjNHfo5jK27JQrB0V0iK16GEHiuNQ@mail.gmail.com>
References: <CAJgngAf7fEw6o5sMdHNLMJkCkAFcANE5rfBe4e_Lv+6=MUttww@mail.gmail.com>
	<CAJrcDBfBROrqPCyF6et15EFx=ZZ=FGKuZu_1EEpsMG0OwjuFfA@mail.gmail.com>
	<CAJgngAdGBi2GD9J8UjC8zEKLorTxRqaBqgOMM+SUBOYiVSYkQA@mail.gmail.com>
	<CAJgngAcrHeRUXfzOMQFuFqjNHfo5jK27JQrB0V0iK16GEHiuNQ@mail.gmail.com>
Message-ID: <CAJrcDBdzyO022j8PVT6Yr5-7OPLbELYiV8a4S85hFMY3fNrqjw@mail.gmail.com>

To avoid additional endpoints that are not really part of the core
functionality. For demo and testing this is very helpful but in production
you don't want the server serving such requests and consuming resources.

Treat as a "feature" seems more reasonable for me instead of always have it
available.

On Thu, Apr 5, 2018 at 11:47 AM, Stian Thorgersen <sthorger at redhat.com>
wrote:

> Just to add - we can easily make it a feature that can be enabled/disabled
> through the profile stuff, but was just curious to why you thought it would
> be needed to disable it.
>
> On 5 April 2018 at 16:45, Stian Thorgersen <sthorger at redhat.com> wrote:
>
>> Why?
>>
>> On 5 April 2018 at 16:23, Pedro Igor Silva <psilva at redhat.com> wrote:
>>
>>> Although very helpful, people may want to disable this when in
>>> production.
>>>
>>> On Thu, Apr 5, 2018 at 9:04 AM, Stian Thorgersen <sthorger at redhat.com>
>>> wrote:
>>>
>>>> I added an example token validator endpoint that I needed for some
>>>> demonstration purposes. Question would this be useful to add directly to
>>>> Keycloak?
>>>>
>>>> It provides a simple form where you can paste in the base64 token. It
>>>> will
>>>> then output the header, claims and whether or not the token is valid. It
>>>> uses realm keys to verify the signature so you don't have to paste that
>>>> in
>>>> manually (like you do on jwt.io).
>>>>
>>>> For those to lazy to try it out I've attached a screenshot.
>>>>
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>>
>>>
>>
>

From sthorger at redhat.com  Thu Apr  5 11:03:45 2018
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 5 Apr 2018 17:03:45 +0200
Subject: [keycloak-dev] Token validator endpoint (for humans)
In-Reply-To: <CAJrcDBdzyO022j8PVT6Yr5-7OPLbELYiV8a4S85hFMY3fNrqjw@mail.gmail.com>
References: <CAJgngAf7fEw6o5sMdHNLMJkCkAFcANE5rfBe4e_Lv+6=MUttww@mail.gmail.com>
	<CAJrcDBfBROrqPCyF6et15EFx=ZZ=FGKuZu_1EEpsMG0OwjuFfA@mail.gmail.com>
	<CAJgngAdGBi2GD9J8UjC8zEKLorTxRqaBqgOMM+SUBOYiVSYkQA@mail.gmail.com>
	<CAJgngAcrHeRUXfzOMQFuFqjNHfo5jK27JQrB0V0iK16GEHiuNQ@mail.gmail.com>
	<CAJrcDBdzyO022j8PVT6Yr5-7OPLbELYiV8a4S85hFMY3fNrqjw@mail.gmail.com>
Message-ID: <CAJgngAf7nWuNexAOk6kfHgU2XUCkYN_YhCGw45nXLZcOZN=DVw@mail.gmail.com>

I can see it being helpful in production for debugging purposes. It may
also be helpful for application developers that are trying to figure out
what's going on in their apps.

Do you have any actual concerns about it being exposed rather than just
because it's more stuff to expose ;)

On 5 April 2018 at 16:58, Pedro Igor Silva <psilva at redhat.com> wrote:

> To avoid additional endpoints that are not really part of the core
> functionality. For demo and testing this is very helpful but in production
> you don't want the server serving such requests and consuming resources.
>
> Treat as a "feature" seems more reasonable for me instead of always have
> it available.
>
> On Thu, Apr 5, 2018 at 11:47 AM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> Just to add - we can easily make it a feature that can be
>> enabled/disabled through the profile stuff, but was just curious to why you
>> thought it would be needed to disable it.
>>
>> On 5 April 2018 at 16:45, Stian Thorgersen <sthorger at redhat.com> wrote:
>>
>>> Why?
>>>
>>> On 5 April 2018 at 16:23, Pedro Igor Silva <psilva at redhat.com> wrote:
>>>
>>>> Although very helpful, people may want to disable this when in
>>>> production.
>>>>
>>>> On Thu, Apr 5, 2018 at 9:04 AM, Stian Thorgersen <sthorger at redhat.com>
>>>> wrote:
>>>>
>>>>> I added an example token validator endpoint that I needed for some
>>>>> demonstration purposes. Question would this be useful to add directly
>>>>> to
>>>>> Keycloak?
>>>>>
>>>>> It provides a simple form where you can paste in the base64 token. It
>>>>> will
>>>>> then output the header, claims and whether or not the token is valid.
>>>>> It
>>>>> uses realm keys to verify the signature so you don't have to paste
>>>>> that in
>>>>> manually (like you do on jwt.io).
>>>>>
>>>>> For those to lazy to try it out I've attached a screenshot.
>>>>>
>>>>> _______________________________________________
>>>>> keycloak-dev mailing list
>>>>> keycloak-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>
>>>>
>>>>
>>>
>>
>

From psilva at redhat.com  Thu Apr  5 11:09:20 2018
From: psilva at redhat.com (Pedro Igor Silva)
Date: Thu, 5 Apr 2018 12:09:20 -0300
Subject: [keycloak-dev] Token validator endpoint (for humans)
In-Reply-To: <CAJgngAf7nWuNexAOk6kfHgU2XUCkYN_YhCGw45nXLZcOZN=DVw@mail.gmail.com>
References: <CAJgngAf7fEw6o5sMdHNLMJkCkAFcANE5rfBe4e_Lv+6=MUttww@mail.gmail.com>
	<CAJrcDBfBROrqPCyF6et15EFx=ZZ=FGKuZu_1EEpsMG0OwjuFfA@mail.gmail.com>
	<CAJgngAdGBi2GD9J8UjC8zEKLorTxRqaBqgOMM+SUBOYiVSYkQA@mail.gmail.com>
	<CAJgngAcrHeRUXfzOMQFuFqjNHfo5jK27JQrB0V0iK16GEHiuNQ@mail.gmail.com>
	<CAJrcDBdzyO022j8PVT6Yr5-7OPLbELYiV8a4S85hFMY3fNrqjw@mail.gmail.com>
	<CAJgngAf7nWuNexAOk6kfHgU2XUCkYN_YhCGw45nXLZcOZN=DVw@mail.gmail.com>
Message-ID: <CAJrcDBdseshnc7tUWQHL=VU-TGgCS5YgRTSUgeEQVD1Zzt3MYg@mail.gmail.com>

Nope :)

On Thu, Apr 5, 2018 at 12:03 PM, Stian Thorgersen <sthorger at redhat.com>
wrote:

> I can see it being helpful in production for debugging purposes. It may
> also be helpful for application developers that are trying to figure out
> what's going on in their apps.
>
> Do you have any actual concerns about it being exposed rather than just
> because it's more stuff to expose ;)
>
> On 5 April 2018 at 16:58, Pedro Igor Silva <psilva at redhat.com> wrote:
>
>> To avoid additional endpoints that are not really part of the core
>> functionality. For demo and testing this is very helpful but in production
>> you don't want the server serving such requests and consuming resources.
>>
>> Treat as a "feature" seems more reasonable for me instead of always have
>> it available.
>>
>> On Thu, Apr 5, 2018 at 11:47 AM, Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>>
>>> Just to add - we can easily make it a feature that can be
>>> enabled/disabled through the profile stuff, but was just curious to why you
>>> thought it would be needed to disable it.
>>>
>>> On 5 April 2018 at 16:45, Stian Thorgersen <sthorger at redhat.com> wrote:
>>>
>>>> Why?
>>>>
>>>> On 5 April 2018 at 16:23, Pedro Igor Silva <psilva at redhat.com> wrote:
>>>>
>>>>> Although very helpful, people may want to disable this when in
>>>>> production.
>>>>>
>>>>> On Thu, Apr 5, 2018 at 9:04 AM, Stian Thorgersen <sthorger at redhat.com>
>>>>> wrote:
>>>>>
>>>>>> I added an example token validator endpoint that I needed for some
>>>>>> demonstration purposes. Question would this be useful to add directly
>>>>>> to
>>>>>> Keycloak?
>>>>>>
>>>>>> It provides a simple form where you can paste in the base64 token. It
>>>>>> will
>>>>>> then output the header, claims and whether or not the token is valid.
>>>>>> It
>>>>>> uses realm keys to verify the signature so you don't have to paste
>>>>>> that in
>>>>>> manually (like you do on jwt.io).
>>>>>>
>>>>>> For those to lazy to try it out I've attached a screenshot.
>>>>>>
>>>>>> _______________________________________________
>>>>>> keycloak-dev mailing list
>>>>>> keycloak-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>

From sthorger at redhat.com  Thu Apr  5 12:31:00 2018
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 05 Apr 2018 16:31:00 +0000
Subject: [keycloak-dev] Token validator endpoint (for humans)
In-Reply-To: <CAJrcDBdseshnc7tUWQHL=VU-TGgCS5YgRTSUgeEQVD1Zzt3MYg@mail.gmail.com>
References: <CAJgngAf7fEw6o5sMdHNLMJkCkAFcANE5rfBe4e_Lv+6=MUttww@mail.gmail.com>
	<CAJrcDBfBROrqPCyF6et15EFx=ZZ=FGKuZu_1EEpsMG0OwjuFfA@mail.gmail.com>
	<CAJgngAdGBi2GD9J8UjC8zEKLorTxRqaBqgOMM+SUBOYiVSYkQA@mail.gmail.com>
	<CAJgngAcrHeRUXfzOMQFuFqjNHfo5jK27JQrB0V0iK16GEHiuNQ@mail.gmail.com>
	<CAJrcDBdzyO022j8PVT6Yr5-7OPLbELYiV8a4S85hFMY3fNrqjw@mail.gmail.com>
	<CAJgngAf7nWuNexAOk6kfHgU2XUCkYN_YhCGw45nXLZcOZN=DVw@mail.gmail.com>
	<CAJrcDBdseshnc7tUWQHL=VU-TGgCS5YgRTSUgeEQVD1Zzt3MYg@mail.gmail.com>
Message-ID: <CAJgngAf_mM49m5u+mq6n2e_A_QgK3_DFpnjWbysjeSR4t2oXnA@mail.gmail.com>

One important thing I can think of is if we add support for JWEs we need to
make sure this thing doesn't return token details.

On Thu, 5 Apr 2018, 17:09 Pedro Igor Silva, <psilva at redhat.com> wrote:

> Nope :)
>
> On Thu, Apr 5, 2018 at 12:03 PM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> I can see it being helpful in production for debugging purposes. It may
>> also be helpful for application developers that are trying to figure out
>> what's going on in their apps.
>>
>> Do you have any actual concerns about it being exposed rather than just
>> because it's more stuff to expose ;)
>>
>> On 5 April 2018 at 16:58, Pedro Igor Silva <psilva at redhat.com> wrote:
>>
>>> To avoid additional endpoints that are not really part of the core
>>> functionality. For demo and testing this is very helpful but in production
>>> you don't want the server serving such requests and consuming resources.
>>>
>>> Treat as a "feature" seems more reasonable for me instead of always have
>>> it available.
>>>
>>> On Thu, Apr 5, 2018 at 11:47 AM, Stian Thorgersen <sthorger at redhat.com>
>>> wrote:
>>>
>>>> Just to add - we can easily make it a feature that can be
>>>> enabled/disabled through the profile stuff, but was just curious to why you
>>>> thought it would be needed to disable it.
>>>>
>>>> On 5 April 2018 at 16:45, Stian Thorgersen <sthorger at redhat.com> wrote:
>>>>
>>>>> Why?
>>>>>
>>>>> On 5 April 2018 at 16:23, Pedro Igor Silva <psilva at redhat.com> wrote:
>>>>>
>>>>>> Although very helpful, people may want to disable this when in
>>>>>> production.
>>>>>>
>>>>>> On Thu, Apr 5, 2018 at 9:04 AM, Stian Thorgersen <sthorger at redhat.com
>>>>>> > wrote:
>>>>>>
>>>>>>> I added an example token validator endpoint that I needed for some
>>>>>>> demonstration purposes. Question would this be useful to add
>>>>>>> directly to
>>>>>>> Keycloak?
>>>>>>>
>>>>>>> It provides a simple form where you can paste in the base64 token.
>>>>>>> It will
>>>>>>> then output the header, claims and whether or not the token is
>>>>>>> valid. It
>>>>>>> uses realm keys to verify the signature so you don't have to paste
>>>>>>> that in
>>>>>>> manually (like you do on jwt.io).
>>>>>>>
>>>>>>> For those to lazy to try it out I've attached a screenshot.
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> keycloak-dev mailing list
>>>>>>> keycloak-dev at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

From bburke at redhat.com  Thu Apr  5 12:55:50 2018
From: bburke at redhat.com (Bill Burke)
Date: Thu, 5 Apr 2018 12:55:50 -0400
Subject: [keycloak-dev] wildfly pkg manager changes everything
In-Reply-To: <CAJgngAexdXw-x9xnoKkeEJMRJHJD7o-LMfJLN-8T3rNai2PrFQ@mail.gmail.com>
References: <CABRXCmzTL89zT7tPUXDLoEViq6Bjf6exQUiOEqqcGF-SGFNEgQ@mail.gmail.com>
	<CAJgngAexdXw-x9xnoKkeEJMRJHJD7o-LMfJLN-8T3rNai2PrFQ@mail.gmail.com>
Message-ID: <CABRXCmzbm8d0xRAQa2cWdcqNhudLubE_-1dRFD-xAiMe0xz8_w@mail.gmail.com>

On Thu, Apr 5, 2018 at 2:28 AM, Stian Thorgersen <sthorger at redhat.com> wrote:
> I don't have the full picture yet on how this will all work, but it sounds
> really promising.
>
> There are at least 3 categories of users for Keycloak:
>
> * Black box users - built-in features and config options are sufficient

What the new WPM will allow us to do is define a bare bones distros.
People that want to write extensions using other components (i.e. EJB,
JMS, etc...) can use WPM to bring in those dependencies.

> * Middle ground - customized themes and a few custom providers, but still
> happy with a default setup with regards to subsystems (and limited use of
> JEE features)
> * Integration - more heavily customized and have a need to add additional
> subsystems on top of what we bring
>
> I would believe most users land in the first two and would be happy with a
> single distro download rather than having to install a package manager to
> then install. For the latter the approach to combine your own would be
> great.
>

Jason envisions a base Wildfly image that is just a maven repo.
Layered products like keycloak just ship a thin extension image that
points into the repo of the base image.  This extension image is just
config files.  Very tiny and compact.  This gives a lot of room for
optimization in the cloud layer as other non-keycloak apps built on
wildfly and eap and rhoar can also point into this base image.

For us, I think the steps should be:
1. download keycloak which will come included with WPM
2. add your db driver

$ wpm install my-db-driver

3. Modify Wildfly config by hand or with jboss cli as needed
4. Modify add themes as needed
5. Develop extensions as needed
if writing an extension that uses EJB and JMS

$ wpm install EJB JMS

You have something working, now its time to put shit into your cloud environment

1. Your development distro (just a set of config files) is packaged
and pushed to your company maven repo.  (Yes, WPM will allow you to do
this).  What's interesting about this development distro is that it is
just a set of config files and is very very tiny.
2. Extend the development distro to add production parameters.  yes,
you can have one distro depend on another!

$ wpm install kube-ping

3. Add a stock Dockerfile to your extended "production" distro.
This stock Dockerfile extends base Wildfly or EAP image (which is just
a maven repo).
4. Build and push your new production image.  This new image is really
tiny...measured in kilobytes as it points into the maven repo that
comes with the base Wildfly/EAP image.

Oh...we need to move our distro to Amazon AWS.  We need a different DB
and a different JGroups stack

1. Extend the production distro and make changes:
$ wpm remove my-db-driver
$ wpm remove keycloak-jpa
$ wpm install keylcloak-s3
$ wpm remove kube-ping
$ wpm install s3-ping
$ jboss-cli ...

Repeat steps 3 and 4 above to build a new image.  What's cool is that
WPM creates a history file that can be replayed.  So all the steps
above are ready to copy and throw in a Dockerfile

Let's pretend that we would have to have a different keycloak
deployment per cloud provider (AWS vs. GCE vs. on premise Openshift
vs. Openshift Online).  We could prepackage this stuff with additional
service packs.  Then you could extend the custom development service
pack we defined earlier and do this instead:

$ wpm install keycloak-aws

There's just so much flexibility for our users, for Wildfly, and for
the cloud provider. So much potential for re-use and optimization.

All and all, I think your viewpoint doesn't match the actual reality
of how people are going to consume Keycloak.  I'm not alone.  In my
talks with Jason, he also thought the ENV VAR approach is just crazy.
 He has the exact same concerns with the Wildfly XPaaS image that I do
with Keycloak's.   There's a reason that their are a million settings
in the application server.  This tech has been around for 15 years and
people do a lot of crazy shit.  I would say 100% of "actual" users
will extend the themes.  I think close to 100% will need to modify
configuration, install their own database driver, tweek undertow
config,  turn on/turn off wildfly management layer etc. etc. etc..
I'm not even 100% sure that we can ship with a stock JGroups stack for
Openshift and this might have to change depending on the cloud
provider.  I think a majority of developers will have to write an
extension at some point.  Finally, I would also say that there will be
a large chunk of developers that will want as slim a Keycloak as
possible.  I think Spring proves how prevalent this "deploy only what
you need" ideology is.  I think developers will outgrow "hello world"
and the base image very very quickly.

IMO, almost everybody will want to work locally on their laptop,
develop and test their deployment there rather than the crazy model
being pushed right now around S2I and constantly recycling and
redeploying your image.  Think about it....Would you restart your
laptop every time you made a codechange while developing?  IMO, the
best approach is to bridge the divide between local development and
cloud deployment.  Let people define and test their deployment locally
as well.  This isn''t solely a Keycloak problem.  Every app of every
language and framework will have it.

Anyways, that's my rant, viewpoint, and prediction.

From bburke at redhat.com  Thu Apr  5 13:08:44 2018
From: bburke at redhat.com (Bill Burke)
Date: Thu, 5 Apr 2018 13:08:44 -0400
Subject: [keycloak-dev] Token validator endpoint (for humans)
In-Reply-To: <CAJgngAf_mM49m5u+mq6n2e_A_QgK3_DFpnjWbysjeSR4t2oXnA@mail.gmail.com>
References: <CAJgngAf7fEw6o5sMdHNLMJkCkAFcANE5rfBe4e_Lv+6=MUttww@mail.gmail.com>
	<CAJrcDBfBROrqPCyF6et15EFx=ZZ=FGKuZu_1EEpsMG0OwjuFfA@mail.gmail.com>
	<CAJgngAdGBi2GD9J8UjC8zEKLorTxRqaBqgOMM+SUBOYiVSYkQA@mail.gmail.com>
	<CAJgngAcrHeRUXfzOMQFuFqjNHfo5jK27JQrB0V0iK16GEHiuNQ@mail.gmail.com>
	<CAJrcDBdzyO022j8PVT6Yr5-7OPLbELYiV8a4S85hFMY3fNrqjw@mail.gmail.com>
	<CAJgngAf7nWuNexAOk6kfHgU2XUCkYN_YhCGw45nXLZcOZN=DVw@mail.gmail.com>
	<CAJrcDBdseshnc7tUWQHL=VU-TGgCS5YgRTSUgeEQVD1Zzt3MYg@mail.gmail.com>
	<CAJgngAf_mM49m5u+mq6n2e_A_QgK3_DFpnjWbysjeSR4t2oXnA@mail.gmail.com>
Message-ID: <CABRXCmyH3i8QSHWf4sUMiVTAf6dhB5v9d+XcNid6RVE0gQpHcw@mail.gmail.com>

If your service is receiving a valid active token, why does it matter
if it is a valid JWE or not?   Related to this is that protocol
mappers allow you to define how an access token, id token, AND the
user info service looks like.  Couldn't your endpoint just use the
user info output?  Then you are sure that you are not leaking
anything.

BTW, we'll need such an "open endpoint" when reference tokens come in.

On Thu, Apr 5, 2018 at 12:31 PM, Stian Thorgersen <sthorger at redhat.com> wrote:
> One important thing I can think of is if we add support for JWEs we need to
> make sure this thing doesn't return token details.
>
> On Thu, 5 Apr 2018, 17:09 Pedro Igor Silva, <psilva at redhat.com> wrote:
>
>> Nope :)
>>
>> On Thu, Apr 5, 2018 at 12:03 PM, Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>>
>>> I can see it being helpful in production for debugging purposes. It may
>>> also be helpful for application developers that are trying to figure out
>>> what's going on in their apps.
>>>
>>> Do you have any actual concerns about it being exposed rather than just
>>> because it's more stuff to expose ;)
>>>
>>> On 5 April 2018 at 16:58, Pedro Igor Silva <psilva at redhat.com> wrote:
>>>
>>>> To avoid additional endpoints that are not really part of the core
>>>> functionality. For demo and testing this is very helpful but in production
>>>> you don't want the server serving such requests and consuming resources.
>>>>
>>>> Treat as a "feature" seems more reasonable for me instead of always have
>>>> it available.
>>>>
>>>> On Thu, Apr 5, 2018 at 11:47 AM, Stian Thorgersen <sthorger at redhat.com>
>>>> wrote:
>>>>
>>>>> Just to add - we can easily make it a feature that can be
>>>>> enabled/disabled through the profile stuff, but was just curious to why you
>>>>> thought it would be needed to disable it.
>>>>>
>>>>> On 5 April 2018 at 16:45, Stian Thorgersen <sthorger at redhat.com> wrote:
>>>>>
>>>>>> Why?
>>>>>>
>>>>>> On 5 April 2018 at 16:23, Pedro Igor Silva <psilva at redhat.com> wrote:
>>>>>>
>>>>>>> Although very helpful, people may want to disable this when in
>>>>>>> production.
>>>>>>>
>>>>>>> On Thu, Apr 5, 2018 at 9:04 AM, Stian Thorgersen <sthorger at redhat.com
>>>>>>> > wrote:
>>>>>>>
>>>>>>>> I added an example token validator endpoint that I needed for some
>>>>>>>> demonstration purposes. Question would this be useful to add
>>>>>>>> directly to
>>>>>>>> Keycloak?
>>>>>>>>
>>>>>>>> It provides a simple form where you can paste in the base64 token.
>>>>>>>> It will
>>>>>>>> then output the header, claims and whether or not the token is
>>>>>>>> valid. It
>>>>>>>> uses realm keys to verify the signature so you don't have to paste
>>>>>>>> that in
>>>>>>>> manually (like you do on jwt.io).
>>>>>>>>
>>>>>>>> For those to lazy to try it out I've attached a screenshot.
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> keycloak-dev mailing list
>>>>>>>> keycloak-dev at lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



-- 
Bill Burke
Red Hat

From psilva at redhat.com  Thu Apr  5 14:06:00 2018
From: psilva at redhat.com (Pedro Igor Silva)
Date: Thu, 5 Apr 2018 15:06:00 -0300
Subject: [keycloak-dev] Token validator endpoint (for humans)
In-Reply-To: <CAJgngAf_mM49m5u+mq6n2e_A_QgK3_DFpnjWbysjeSR4t2oXnA@mail.gmail.com>
References: <CAJgngAf7fEw6o5sMdHNLMJkCkAFcANE5rfBe4e_Lv+6=MUttww@mail.gmail.com>
	<CAJrcDBfBROrqPCyF6et15EFx=ZZ=FGKuZu_1EEpsMG0OwjuFfA@mail.gmail.com>
	<CAJgngAdGBi2GD9J8UjC8zEKLorTxRqaBqgOMM+SUBOYiVSYkQA@mail.gmail.com>
	<CAJgngAcrHeRUXfzOMQFuFqjNHfo5jK27JQrB0V0iK16GEHiuNQ@mail.gmail.com>
	<CAJrcDBdzyO022j8PVT6Yr5-7OPLbELYiV8a4S85hFMY3fNrqjw@mail.gmail.com>
	<CAJgngAf7nWuNexAOk6kfHgU2XUCkYN_YhCGw45nXLZcOZN=DVw@mail.gmail.com>
	<CAJrcDBdseshnc7tUWQHL=VU-TGgCS5YgRTSUgeEQVD1Zzt3MYg@mail.gmail.com>
	<CAJgngAf_mM49m5u+mq6n2e_A_QgK3_DFpnjWbysjeSR4t2oXnA@mail.gmail.com>
Message-ID: <CAJrcDBef3QkmtzcmYCcKLRSnog1G8xov=qyHfn7s4_CzYTCzAg@mail.gmail.com>

I'm wondering now ... I think Marek did some kind of "Evaluator" for
showing how scopes looks like in a token. In Authorization Services we have
the "Policy Evaluation Tool" which shows how an access token looks like
(including claims added by mappers, etc). Why not have something in admin
console itself from where admins can "evaluate" how an access/id token
looks like after selecting an user/service account ?

On Thu, Apr 5, 2018 at 1:31 PM, Stian Thorgersen <sthorger at redhat.com>
wrote:

> One important thing I can think of is if we add support for JWEs we need
> to make sure this thing doesn't return token details.
>
> On Thu, 5 Apr 2018, 17:09 Pedro Igor Silva, <psilva at redhat.com> wrote:
>
>> Nope :)
>>
>> On Thu, Apr 5, 2018 at 12:03 PM, Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>>
>>> I can see it being helpful in production for debugging purposes. It may
>>> also be helpful for application developers that are trying to figure out
>>> what's going on in their apps.
>>>
>>> Do you have any actual concerns about it being exposed rather than just
>>> because it's more stuff to expose ;)
>>>
>>> On 5 April 2018 at 16:58, Pedro Igor Silva <psilva at redhat.com> wrote:
>>>
>>>> To avoid additional endpoints that are not really part of the core
>>>> functionality. For demo and testing this is very helpful but in production
>>>> you don't want the server serving such requests and consuming resources.
>>>>
>>>> Treat as a "feature" seems more reasonable for me instead of always
>>>> have it available.
>>>>
>>>> On Thu, Apr 5, 2018 at 11:47 AM, Stian Thorgersen <sthorger at redhat.com>
>>>> wrote:
>>>>
>>>>> Just to add - we can easily make it a feature that can be
>>>>> enabled/disabled through the profile stuff, but was just curious to why you
>>>>> thought it would be needed to disable it.
>>>>>
>>>>> On 5 April 2018 at 16:45, Stian Thorgersen <sthorger at redhat.com>
>>>>> wrote:
>>>>>
>>>>>> Why?
>>>>>>
>>>>>> On 5 April 2018 at 16:23, Pedro Igor Silva <psilva at redhat.com> wrote:
>>>>>>
>>>>>>> Although very helpful, people may want to disable this when in
>>>>>>> production.
>>>>>>>
>>>>>>> On Thu, Apr 5, 2018 at 9:04 AM, Stian Thorgersen <
>>>>>>> sthorger at redhat.com> wrote:
>>>>>>>
>>>>>>>> I added an example token validator endpoint that I needed for some
>>>>>>>> demonstration purposes. Question would this be useful to add
>>>>>>>> directly to
>>>>>>>> Keycloak?
>>>>>>>>
>>>>>>>> It provides a simple form where you can paste in the base64 token.
>>>>>>>> It will
>>>>>>>> then output the header, claims and whether or not the token is
>>>>>>>> valid. It
>>>>>>>> uses realm keys to verify the signature so you don't have to paste
>>>>>>>> that in
>>>>>>>> manually (like you do on jwt.io).
>>>>>>>>
>>>>>>>> For those to lazy to try it out I've attached a screenshot.
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> keycloak-dev mailing list
>>>>>>>> keycloak-dev at lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>

From psilva at redhat.com  Thu Apr  5 14:11:57 2018
From: psilva at redhat.com (Pedro Igor Silva)
Date: Thu, 5 Apr 2018 15:11:57 -0300
Subject: [keycloak-dev] wildfly pkg manager changes everything
In-Reply-To: <CABRXCmzbm8d0xRAQa2cWdcqNhudLubE_-1dRFD-xAiMe0xz8_w@mail.gmail.com>
References: <CABRXCmzTL89zT7tPUXDLoEViq6Bjf6exQUiOEqqcGF-SGFNEgQ@mail.gmail.com>
	<CAJgngAexdXw-x9xnoKkeEJMRJHJD7o-LMfJLN-8T3rNai2PrFQ@mail.gmail.com>
	<CABRXCmzbm8d0xRAQa2cWdcqNhudLubE_-1dRFD-xAiMe0xz8_w@mail.gmail.com>
Message-ID: <CAJrcDBfNktc=mee8azHvnW8GGzVN3iTiLE8+EyoPENuwqo2hQw@mail.gmail.com>

All that seems awesome ....

So, WPM would basically use maven artifacts to represent layers in your
distro (like we have in docker for any additional stuff you want into an
image) ?

On Thu, Apr 5, 2018 at 1:55 PM, Bill Burke <bburke at redhat.com> wrote:

> On Thu, Apr 5, 2018 at 2:28 AM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
> > I don't have the full picture yet on how this will all work, but it
> sounds
> > really promising.
> >
> > There are at least 3 categories of users for Keycloak:
> >
> > * Black box users - built-in features and config options are sufficient
>
> What the new WPM will allow us to do is define a bare bones distros.
> People that want to write extensions using other components (i.e. EJB,
> JMS, etc...) can use WPM to bring in those dependencies.
>
> > * Middle ground - customized themes and a few custom providers, but still
> > happy with a default setup with regards to subsystems (and limited use of
> > JEE features)
> > * Integration - more heavily customized and have a need to add additional
> > subsystems on top of what we bring
> >
> > I would believe most users land in the first two and would be happy with
> a
> > single distro download rather than having to install a package manager to
> > then install. For the latter the approach to combine your own would be
> > great.
> >
>
> Jason envisions a base Wildfly image that is just a maven repo.
> Layered products like keycloak just ship a thin extension image that
> points into the repo of the base image.  This extension image is just
> config files.  Very tiny and compact.  This gives a lot of room for
> optimization in the cloud layer as other non-keycloak apps built on
> wildfly and eap and rhoar can also point into this base image.
>
> For us, I think the steps should be:
> 1. download keycloak which will come included with WPM
> 2. add your db driver
>
> $ wpm install my-db-driver
>
> 3. Modify Wildfly config by hand or with jboss cli as needed
> 4. Modify add themes as needed
> 5. Develop extensions as needed
> if writing an extension that uses EJB and JMS
>
> $ wpm install EJB JMS
>
> You have something working, now its time to put shit into your cloud
> environment
>
> 1. Your development distro (just a set of config files) is packaged
> and pushed to your company maven repo.  (Yes, WPM will allow you to do
> this).  What's interesting about this development distro is that it is
> just a set of config files and is very very tiny.
> 2. Extend the development distro to add production parameters.  yes,
> you can have one distro depend on another!
>
> $ wpm install kube-ping
>
> 3. Add a stock Dockerfile to your extended "production" distro.
> This stock Dockerfile extends base Wildfly or EAP image (which is just
> a maven repo).
> 4. Build and push your new production image.  This new image is really
> tiny...measured in kilobytes as it points into the maven repo that
> comes with the base Wildfly/EAP image.
>
> Oh...we need to move our distro to Amazon AWS.  We need a different DB
> and a different JGroups stack
>
> 1. Extend the production distro and make changes:
> $ wpm remove my-db-driver
> $ wpm remove keycloak-jpa
> $ wpm install keylcloak-s3
> $ wpm remove kube-ping
> $ wpm install s3-ping
> $ jboss-cli ...
>
> Repeat steps 3 and 4 above to build a new image.  What's cool is that
> WPM creates a history file that can be replayed.  So all the steps
> above are ready to copy and throw in a Dockerfile
>
> Let's pretend that we would have to have a different keycloak
> deployment per cloud provider (AWS vs. GCE vs. on premise Openshift
> vs. Openshift Online).  We could prepackage this stuff with additional
> service packs.  Then you could extend the custom development service
> pack we defined earlier and do this instead:
>
> $ wpm install keycloak-aws
>
> There's just so much flexibility for our users, for Wildfly, and for
> the cloud provider. So much potential for re-use and optimization.
>
> All and all, I think your viewpoint doesn't match the actual reality
> of how people are going to consume Keycloak.  I'm not alone.  In my
> talks with Jason, he also thought the ENV VAR approach is just crazy.
>  He has the exact same concerns with the Wildfly XPaaS image that I do
> with Keycloak's.   There's a reason that their are a million settings
> in the application server.  This tech has been around for 15 years and
> people do a lot of crazy shit.  I would say 100% of "actual" users
> will extend the themes.  I think close to 100% will need to modify
> configuration, install their own database driver, tweek undertow
> config,  turn on/turn off wildfly management layer etc. etc. etc..
> I'm not even 100% sure that we can ship with a stock JGroups stack for
> Openshift and this might have to change depending on the cloud
> provider.  I think a majority of developers will have to write an
> extension at some point.  Finally, I would also say that there will be
> a large chunk of developers that will want as slim a Keycloak as
> possible.  I think Spring proves how prevalent this "deploy only what
> you need" ideology is.  I think developers will outgrow "hello world"
> and the base image very very quickly.
>
> IMO, almost everybody will want to work locally on their laptop,
> develop and test their deployment there rather than the crazy model
> being pushed right now around S2I and constantly recycling and
> redeploying your image.  Think about it....Would you restart your
> laptop every time you made a codechange while developing?  IMO, the
> best approach is to bridge the divide between local development and
> cloud deployment.  Let people define and test their deployment locally
> as well.  This isn''t solely a Keycloak problem.  Every app of every
> language and framework will have it.
>
> Anyways, that's my rant, viewpoint, and prediction.
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sthorger at redhat.com  Thu Apr  5 15:46:17 2018
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 5 Apr 2018 21:46:17 +0200
Subject: [keycloak-dev] Token validator endpoint (for humans)
In-Reply-To: <CABRXCmyH3i8QSHWf4sUMiVTAf6dhB5v9d+XcNid6RVE0gQpHcw@mail.gmail.com>
References: <CAJgngAf7fEw6o5sMdHNLMJkCkAFcANE5rfBe4e_Lv+6=MUttww@mail.gmail.com>
	<CAJrcDBfBROrqPCyF6et15EFx=ZZ=FGKuZu_1EEpsMG0OwjuFfA@mail.gmail.com>
	<CAJgngAdGBi2GD9J8UjC8zEKLorTxRqaBqgOMM+SUBOYiVSYkQA@mail.gmail.com>
	<CAJgngAcrHeRUXfzOMQFuFqjNHfo5jK27JQrB0V0iK16GEHiuNQ@mail.gmail.com>
	<CAJrcDBdzyO022j8PVT6Yr5-7OPLbELYiV8a4S85hFMY3fNrqjw@mail.gmail.com>
	<CAJgngAf7nWuNexAOk6kfHgU2XUCkYN_YhCGw45nXLZcOZN=DVw@mail.gmail.com>
	<CAJrcDBdseshnc7tUWQHL=VU-TGgCS5YgRTSUgeEQVD1Zzt3MYg@mail.gmail.com>
	<CAJgngAf_mM49m5u+mq6n2e_A_QgK3_DFpnjWbysjeSR4t2oXnA@mail.gmail.com>
	<CABRXCmyH3i8QSHWf4sUMiVTAf6dhB5v9d+XcNid6RVE0gQpHcw@mail.gmail.com>
Message-ID: <CAJgngAdPRKrqCXNdECFc9ism9HHhd934DM1UwMA8CdkXutMf9Q@mail.gmail.com>

This endpoint is meant to just return exactly what is in the token so a
human can quickly copy/paste it to see what's in the base64 token. However,
if it's JWE encrypted and should be opaque, then it obviously shouldn't
decrypt the details and return it.

As long as the token isn't JWE and just a JWT then the human could just as
well have decoded the token himself, but this is just a tool to help doing
that ;)

On 5 April 2018 at 19:08, Bill Burke <bburke at redhat.com> wrote:

> If your service is receiving a valid active token, why does it matter
> if it is a valid JWE or not?   Related to this is that protocol
> mappers allow you to define how an access token, id token, AND the
> user info service looks like.  Couldn't your endpoint just use the
> user info output?  Then you are sure that you are not leaking
> anything.
>
> BTW, we'll need such an "open endpoint" when reference tokens come in.
>

Can you elaborate on that?


>
> On Thu, Apr 5, 2018 at 12:31 PM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
> > One important thing I can think of is if we add support for JWEs we need
> to
> > make sure this thing doesn't return token details.
> >
> > On Thu, 5 Apr 2018, 17:09 Pedro Igor Silva, <psilva at redhat.com> wrote:
> >
> >> Nope :)
> >>
> >> On Thu, Apr 5, 2018 at 12:03 PM, Stian Thorgersen <sthorger at redhat.com>
> >> wrote:
> >>
> >>> I can see it being helpful in production for debugging purposes. It may
> >>> also be helpful for application developers that are trying to figure
> out
> >>> what's going on in their apps.
> >>>
> >>> Do you have any actual concerns about it being exposed rather than just
> >>> because it's more stuff to expose ;)
> >>>
> >>> On 5 April 2018 at 16:58, Pedro Igor Silva <psilva at redhat.com> wrote:
> >>>
> >>>> To avoid additional endpoints that are not really part of the core
> >>>> functionality. For demo and testing this is very helpful but in
> production
> >>>> you don't want the server serving such requests and consuming
> resources.
> >>>>
> >>>> Treat as a "feature" seems more reasonable for me instead of always
> have
> >>>> it available.
> >>>>
> >>>> On Thu, Apr 5, 2018 at 11:47 AM, Stian Thorgersen <
> sthorger at redhat.com>
> >>>> wrote:
> >>>>
> >>>>> Just to add - we can easily make it a feature that can be
> >>>>> enabled/disabled through the profile stuff, but was just curious to
> why you
> >>>>> thought it would be needed to disable it.
> >>>>>
> >>>>> On 5 April 2018 at 16:45, Stian Thorgersen <sthorger at redhat.com>
> wrote:
> >>>>>
> >>>>>> Why?
> >>>>>>
> >>>>>> On 5 April 2018 at 16:23, Pedro Igor Silva <psilva at redhat.com>
> wrote:
> >>>>>>
> >>>>>>> Although very helpful, people may want to disable this when in
> >>>>>>> production.
> >>>>>>>
> >>>>>>> On Thu, Apr 5, 2018 at 9:04 AM, Stian Thorgersen <
> sthorger at redhat.com
> >>>>>>> > wrote:
> >>>>>>>
> >>>>>>>> I added an example token validator endpoint that I needed for some
> >>>>>>>> demonstration purposes. Question would this be useful to add
> >>>>>>>> directly to
> >>>>>>>> Keycloak?
> >>>>>>>>
> >>>>>>>> It provides a simple form where you can paste in the base64 token.
> >>>>>>>> It will
> >>>>>>>> then output the header, claims and whether or not the token is
> >>>>>>>> valid. It
> >>>>>>>> uses realm keys to verify the signature so you don't have to paste
> >>>>>>>> that in
> >>>>>>>> manually (like you do on jwt.io).
> >>>>>>>>
> >>>>>>>> For those to lazy to try it out I've attached a screenshot.
> >>>>>>>>
> >>>>>>>> _______________________________________________
> >>>>>>>> keycloak-dev mailing list
> >>>>>>>> keycloak-dev at lists.jboss.org
> >>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
> --
> Bill Burke
> Red Hat
>

From bburke at redhat.com  Thu Apr  5 22:35:24 2018
From: bburke at redhat.com (Bill Burke)
Date: Thu, 5 Apr 2018 22:35:24 -0400
Subject: [keycloak-dev] wildfly pkg manager changes everything
In-Reply-To: <CAJrcDBfNktc=mee8azHvnW8GGzVN3iTiLE8+EyoPENuwqo2hQw@mail.gmail.com>
References: <CABRXCmzTL89zT7tPUXDLoEViq6Bjf6exQUiOEqqcGF-SGFNEgQ@mail.gmail.com>
	<CAJgngAexdXw-x9xnoKkeEJMRJHJD7o-LMfJLN-8T3rNai2PrFQ@mail.gmail.com>
	<CABRXCmzbm8d0xRAQa2cWdcqNhudLubE_-1dRFD-xAiMe0xz8_w@mail.gmail.com>
	<CAJrcDBfNktc=mee8azHvnW8GGzVN3iTiLE8+EyoPENuwqo2hQw@mail.gmail.com>
Message-ID: <CABRXCmwA2PeNwvqY-NL3CaBjFg0tb-=+4RV52vKcjzE27eK=7w@mail.gmail.com>

That is my understanding.  I think the timeline is that it will just
be used internally to build releases for various product service packs
this summer.  Then the next release of Wildfly after that will make
WPM public.  My biggest hope is, with this, why would you need to
build RPMs anymore when you have something that does exactly the same
things as yum, except cross platform.

On Thu, Apr 5, 2018 at 2:11 PM, Pedro Igor Silva <psilva at redhat.com> wrote:
> All that seems awesome ....
>
> So, WPM would basically use maven artifacts to represent layers in your
> distro (like we have in docker for any additional stuff you want into an
> image) ?
>
> On Thu, Apr 5, 2018 at 1:55 PM, Bill Burke <bburke at redhat.com> wrote:
>>
>> On Thu, Apr 5, 2018 at 2:28 AM, Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>> > I don't have the full picture yet on how this will all work, but it
>> > sounds
>> > really promising.
>> >
>> > There are at least 3 categories of users for Keycloak:
>> >
>> > * Black box users - built-in features and config options are sufficient
>>
>> What the new WPM will allow us to do is define a bare bones distros.
>> People that want to write extensions using other components (i.e. EJB,
>> JMS, etc...) can use WPM to bring in those dependencies.
>>
>> > * Middle ground - customized themes and a few custom providers, but
>> > still
>> > happy with a default setup with regards to subsystems (and limited use
>> > of
>> > JEE features)
>> > * Integration - more heavily customized and have a need to add
>> > additional
>> > subsystems on top of what we bring
>> >
>> > I would believe most users land in the first two and would be happy with
>> > a
>> > single distro download rather than having to install a package manager
>> > to
>> > then install. For the latter the approach to combine your own would be
>> > great.
>> >
>>
>> Jason envisions a base Wildfly image that is just a maven repo.
>> Layered products like keycloak just ship a thin extension image that
>> points into the repo of the base image.  This extension image is just
>> config files.  Very tiny and compact.  This gives a lot of room for
>> optimization in the cloud layer as other non-keycloak apps built on
>> wildfly and eap and rhoar can also point into this base image.
>>
>> For us, I think the steps should be:
>> 1. download keycloak which will come included with WPM
>> 2. add your db driver
>>
>> $ wpm install my-db-driver
>>
>> 3. Modify Wildfly config by hand or with jboss cli as needed
>> 4. Modify add themes as needed
>> 5. Develop extensions as needed
>> if writing an extension that uses EJB and JMS
>>
>> $ wpm install EJB JMS
>>
>> You have something working, now its time to put shit into your cloud
>> environment
>>
>> 1. Your development distro (just a set of config files) is packaged
>> and pushed to your company maven repo.  (Yes, WPM will allow you to do
>> this).  What's interesting about this development distro is that it is
>> just a set of config files and is very very tiny.
>> 2. Extend the development distro to add production parameters.  yes,
>> you can have one distro depend on another!
>>
>> $ wpm install kube-ping
>>
>> 3. Add a stock Dockerfile to your extended "production" distro.
>> This stock Dockerfile extends base Wildfly or EAP image (which is just
>> a maven repo).
>> 4. Build and push your new production image.  This new image is really
>> tiny...measured in kilobytes as it points into the maven repo that
>> comes with the base Wildfly/EAP image.
>>
>> Oh...we need to move our distro to Amazon AWS.  We need a different DB
>> and a different JGroups stack
>>
>> 1. Extend the production distro and make changes:
>> $ wpm remove my-db-driver
>> $ wpm remove keycloak-jpa
>> $ wpm install keylcloak-s3
>> $ wpm remove kube-ping
>> $ wpm install s3-ping
>> $ jboss-cli ...
>>
>> Repeat steps 3 and 4 above to build a new image.  What's cool is that
>> WPM creates a history file that can be replayed.  So all the steps
>> above are ready to copy and throw in a Dockerfile
>>
>> Let's pretend that we would have to have a different keycloak
>> deployment per cloud provider (AWS vs. GCE vs. on premise Openshift
>> vs. Openshift Online).  We could prepackage this stuff with additional
>> service packs.  Then you could extend the custom development service
>> pack we defined earlier and do this instead:
>>
>> $ wpm install keycloak-aws
>>
>> There's just so much flexibility for our users, for Wildfly, and for
>> the cloud provider. So much potential for re-use and optimization.
>>
>> All and all, I think your viewpoint doesn't match the actual reality
>> of how people are going to consume Keycloak.  I'm not alone.  In my
>> talks with Jason, he also thought the ENV VAR approach is just crazy.
>>  He has the exact same concerns with the Wildfly XPaaS image that I do
>> with Keycloak's.   There's a reason that their are a million settings
>> in the application server.  This tech has been around for 15 years and
>> people do a lot of crazy shit.  I would say 100% of "actual" users
>> will extend the themes.  I think close to 100% will need to modify
>> configuration, install their own database driver, tweek undertow
>> config,  turn on/turn off wildfly management layer etc. etc. etc..
>> I'm not even 100% sure that we can ship with a stock JGroups stack for
>> Openshift and this might have to change depending on the cloud
>> provider.  I think a majority of developers will have to write an
>> extension at some point.  Finally, I would also say that there will be
>> a large chunk of developers that will want as slim a Keycloak as
>> possible.  I think Spring proves how prevalent this "deploy only what
>> you need" ideology is.  I think developers will outgrow "hello world"
>> and the base image very very quickly.
>>
>> IMO, almost everybody will want to work locally on their laptop,
>> develop and test their deployment there rather than the crazy model
>> being pushed right now around S2I and constantly recycling and
>> redeploying your image.  Think about it....Would you restart your
>> laptop every time you made a codechange while developing?  IMO, the
>> best approach is to bridge the divide between local development and
>> cloud deployment.  Let people define and test their deployment locally
>> as well.  This isn''t solely a Keycloak problem.  Every app of every
>> language and framework will have it.
>>
>> Anyways, that's my rant, viewpoint, and prediction.
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>



-- 
Bill Burke
Red Hat

From bburke at redhat.com  Thu Apr  5 22:39:04 2018
From: bburke at redhat.com (Bill Burke)
Date: Thu, 5 Apr 2018 22:39:04 -0400
Subject: [keycloak-dev] Token validator endpoint (for humans)
In-Reply-To: <CAJgngAdPRKrqCXNdECFc9ism9HHhd934DM1UwMA8CdkXutMf9Q@mail.gmail.com>
References: <CAJgngAf7fEw6o5sMdHNLMJkCkAFcANE5rfBe4e_Lv+6=MUttww@mail.gmail.com>
	<CAJrcDBfBROrqPCyF6et15EFx=ZZ=FGKuZu_1EEpsMG0OwjuFfA@mail.gmail.com>
	<CAJgngAdGBi2GD9J8UjC8zEKLorTxRqaBqgOMM+SUBOYiVSYkQA@mail.gmail.com>
	<CAJgngAcrHeRUXfzOMQFuFqjNHfo5jK27JQrB0V0iK16GEHiuNQ@mail.gmail.com>
	<CAJrcDBdzyO022j8PVT6Yr5-7OPLbELYiV8a4S85hFMY3fNrqjw@mail.gmail.com>
	<CAJgngAf7nWuNexAOk6kfHgU2XUCkYN_YhCGw45nXLZcOZN=DVw@mail.gmail.com>
	<CAJrcDBdseshnc7tUWQHL=VU-TGgCS5YgRTSUgeEQVD1Zzt3MYg@mail.gmail.com>
	<CAJgngAf_mM49m5u+mq6n2e_A_QgK3_DFpnjWbysjeSR4t2oXnA@mail.gmail.com>
	<CABRXCmyH3i8QSHWf4sUMiVTAf6dhB5v9d+XcNid6RVE0gQpHcw@mail.gmail.com>
	<CAJgngAdPRKrqCXNdECFc9ism9HHhd934DM1UwMA8CdkXutMf9Q@mail.gmail.com>
Message-ID: <CABRXCmy71YnF2=wtOrVdFNVe=pQ4UnkP484GzFVbjCTJr5WiuA@mail.gmail.com>

On Thu, Apr 5, 2018 at 3:46 PM, Stian Thorgersen <sthorger at redhat.com> wrote:
> This endpoint is meant to just return exactly what is in the token so a
> human can quickly copy/paste it to see what's in the base64 token. However,
> if it's JWE encrypted and should be opaque, then it obviously shouldn't
> decrypt the details and return it.
>
> As long as the token isn't JWE and just a JWT then the human could just as
> well have decoded the token himself, but this is just a tool to help doing
> that ;)
>
> On 5 April 2018 at 19:08, Bill Burke <bburke at redhat.com> wrote:
>>
>> If your service is receiving a valid active token, why does it matter
>> if it is a valid JWE or not?   Related to this is that protocol
>> mappers allow you to define how an access token, id token, AND the
>> user info service looks like.  Couldn't your endpoint just use the
>> user info output?  Then you are sure that you are not leaking
>> anything.
>>
>> BTW, we'll need such an "open endpoint" when reference tokens come in.
>
>
> Can you elaborate on that?
>

public clients that have reference tokens need to validate them and
get user information from them.  Maybe that's just the user info
service though.

Bill

From bburke at redhat.com  Thu Apr  5 23:49:01 2018
From: bburke at redhat.com (Bill Burke)
Date: Thu, 5 Apr 2018 23:49:01 -0400
Subject: [keycloak-dev] Pushing Claims from Policy Enforcer
In-Reply-To: <CAJrcDBd32CLhW5=P8SCKMv0FrNwB7GxhKtRWhh8qxaNjRj+4Fw@mail.gmail.com>
References: <CAJrcDBd32CLhW5=P8SCKMv0FrNwB7GxhKtRWhh8qxaNjRj+4Fw@mail.gmail.com>
Message-ID: <CABRXCmydON+5e8WPv+iRk_RvLfSuTSRBty9CZcEJP2Q2Wht7uw@mail.gmail.com>

I dont' understand...Why do you need an plugin SPI for this?  Wouldn't
the developer just call into your api to create the invocation to the
permission endpoint?

On Thu, Apr 5, 2018 at 10:41 AM, Pedro Igor Silva <psilva at redhat.com> wrote:
> Hi,
>
> I'm currently working on https://issues.jboss.org/browse/KEYCLOAK-4903.
>
> This is all about allowing applications to push arbitrary claims to
> Keycloak prior to evaluating permissions on the server. A simple example to
> illustrate the idea: a request arrives you extract what you want from there
> (parameters, headers, etc) and "push" the information from the request as
> claims in order to evaluate your permissions.
>
> There are endless possibilities on what you can push and how.
>
> >From a design perspective, I was thinking about providing a SPI on the
> adapter side (as simple as using ServiceLoader) to load built-in and
> user-defined "claim information points". Examples of built-in
> implementations would be:
>
> * Extract parameters
> * Extract headers
> * Extract path parameters
> * Extract cookies
> * Invoke an external "policy information point"
>
> What do you think ?
>
> Regards.
> Pedro Igor
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



-- 
Bill Burke
Red Hat

From sthorger at redhat.com  Fri Apr  6 00:17:03 2018
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 6 Apr 2018 06:17:03 +0200
Subject: [keycloak-dev] Token validator endpoint (for humans)
In-Reply-To: <CABRXCmy71YnF2=wtOrVdFNVe=pQ4UnkP484GzFVbjCTJr5WiuA@mail.gmail.com>
References: <CAJgngAf7fEw6o5sMdHNLMJkCkAFcANE5rfBe4e_Lv+6=MUttww@mail.gmail.com>
	<CAJrcDBfBROrqPCyF6et15EFx=ZZ=FGKuZu_1EEpsMG0OwjuFfA@mail.gmail.com>
	<CAJgngAdGBi2GD9J8UjC8zEKLorTxRqaBqgOMM+SUBOYiVSYkQA@mail.gmail.com>
	<CAJgngAcrHeRUXfzOMQFuFqjNHfo5jK27JQrB0V0iK16GEHiuNQ@mail.gmail.com>
	<CAJrcDBdzyO022j8PVT6Yr5-7OPLbELYiV8a4S85hFMY3fNrqjw@mail.gmail.com>
	<CAJgngAf7nWuNexAOk6kfHgU2XUCkYN_YhCGw45nXLZcOZN=DVw@mail.gmail.com>
	<CAJrcDBdseshnc7tUWQHL=VU-TGgCS5YgRTSUgeEQVD1Zzt3MYg@mail.gmail.com>
	<CAJgngAf_mM49m5u+mq6n2e_A_QgK3_DFpnjWbysjeSR4t2oXnA@mail.gmail.com>
	<CABRXCmyH3i8QSHWf4sUMiVTAf6dhB5v9d+XcNid6RVE0gQpHcw@mail.gmail.com>
	<CAJgngAdPRKrqCXNdECFc9ism9HHhd934DM1UwMA8CdkXutMf9Q@mail.gmail.com>
	<CABRXCmy71YnF2=wtOrVdFNVe=pQ4UnkP484GzFVbjCTJr5WiuA@mail.gmail.com>
Message-ID: <CAJgngAfJwwrhW5Gm6r20O3JHxujV5_a_=r5EZqgQN2Hk9+25RA@mail.gmail.com>

On 6 April 2018 at 04:39, Bill Burke <bburke at redhat.com> wrote:

> On Thu, Apr 5, 2018 at 3:46 PM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
> > This endpoint is meant to just return exactly what is in the token so a
> > human can quickly copy/paste it to see what's in the base64 token.
> However,
> > if it's JWE encrypted and should be opaque, then it obviously shouldn't
> > decrypt the details and return it.
> >
> > As long as the token isn't JWE and just a JWT then the human could just
> as
> > well have decoded the token himself, but this is just a tool to help
> doing
> > that ;)
> >
> > On 5 April 2018 at 19:08, Bill Burke <bburke at redhat.com> wrote:
> >>
> >> If your service is receiving a valid active token, why does it matter
> >> if it is a valid JWE or not?   Related to this is that protocol
> >> mappers allow you to define how an access token, id token, AND the
> >> user info service looks like.  Couldn't your endpoint just use the
> >> user info output?  Then you are sure that you are not leaking
> >> anything.
> >>
> >> BTW, we'll need such an "open endpoint" when reference tokens come in.
> >
> >
> > Can you elaborate on that?
> >
>
> public clients that have reference tokens need to validate them and
> get user information from them.  Maybe that's just the user info
> service though.
>

That's actually a rather interesting problem just there. One reason folks
want to have access tokens is that they don't want sensitive information to
leave the organization boundary. As such we'd have to be really careful
about what information is exposed and probably also somehow make it
configurable.


>
> Bill
>

From sthorger at redhat.com  Fri Apr  6 00:41:14 2018
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 6 Apr 2018 06:41:14 +0200
Subject: [keycloak-dev] Pushing Claims from Policy Enforcer
In-Reply-To: <CAJrcDBd32CLhW5=P8SCKMv0FrNwB7GxhKtRWhh8qxaNjRj+4Fw@mail.gmail.com>
References: <CAJrcDBd32CLhW5=P8SCKMv0FrNwB7GxhKtRWhh8qxaNjRj+4Fw@mail.gmail.com>
Message-ID: <CAJgngAfX+LaAzSLVpb72DNobYzj4nEmyeMoeDGdPHgUaL_vS7Q@mail.gmail.com>

Sounds like a nice addition to me. I pressume the RPT endpoint already has
support for the server-side part?

On 5 April 2018 at 16:41, Pedro Igor Silva <psilva at redhat.com> wrote:

> Hi,
>
> I'm currently working on https://issues.jboss.org/browse/KEYCLOAK-4903.
>
> This is all about allowing applications to push arbitrary claims to
> Keycloak prior to evaluating permissions on the server. A simple example to
> illustrate the idea: a request arrives you extract what you want from there
> (parameters, headers, etc) and "push" the information from the request as
> claims in order to evaluate your permissions.
>
> There are endless possibilities on what you can push and how.
>
> >From a design perspective, I was thinking about providing a SPI on the
> adapter side (as simple as using ServiceLoader) to load built-in and
> user-defined "claim information points". Examples of built-in
> implementations would be:
>
> * Extract parameters
> * Extract headers
> * Extract path parameters
> * Extract cookies
> * Invoke an external "policy information point"
>
> What do you think ?
>
> Regards.
> Pedro Igor
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From psilva at redhat.com  Fri Apr  6 07:26:56 2018
From: psilva at redhat.com (Pedro Igor Silva)
Date: Fri, 6 Apr 2018 08:26:56 -0300
Subject: [keycloak-dev] Pushing Claims from Policy Enforcer
In-Reply-To: <CABRXCmydON+5e8WPv+iRk_RvLfSuTSRBty9CZcEJP2Q2Wht7uw@mail.gmail.com>
References: <CAJrcDBd32CLhW5=P8SCKMv0FrNwB7GxhKtRWhh8qxaNjRj+4Fw@mail.gmail.com>
	<CABRXCmydON+5e8WPv+iRk_RvLfSuTSRBty9CZcEJP2Q2Wht7uw@mail.gmail.com>
Message-ID: <CAJrcDBf1wX451PwUtpz8_71DCtbnBvi2tTTVeOQtAkp8-ZCXRA@mail.gmail.com>

If you are using the API directly, yes, you don't need this SPI ...

But when using our policy enforcer (embedded within our adapters)
developers don't actually use our API to call the permission endpoint. This
is done by the policy enforcer itself, internally. The SPI is mainly
targeted for applications using our adapters.

The SPI serves for two purposes:

1) Allow developers to customize permission requests and push arbitrary
claims to the permission endpoint (extension point)
2) Serve as the backbone for built-in "Claim Information Points", provided
by us OOTB.

As an example, here is how a configuration should looks like:

"claim-information-point": [

????"claims": {

????????"claim-a": "{request.parameter['abc']}"

???? },

    "http-service": {

        "url": "abc"

    }

]

"Claim Information Point" is pretty much the same thing as a Policy
Information Point. Each CIP Provider provides its own way to define claims
to a permission request. In the example above, you are "pushing" a
"claim-a" to your policies where the value would be a request parameter
"abc".

Makes more sense now ?


On Fri, Apr 6, 2018 at 12:49 AM, Bill Burke <bburke at redhat.com> wrote:

> I dont' understand...Why do you need an plugin SPI for this?  Wouldn't
> the developer just call into your api to create the invocation to the
> permission endpoint?
>
> On Thu, Apr 5, 2018 at 10:41 AM, Pedro Igor Silva <psilva at redhat.com>
> wrote:
> > Hi,
> >
> > I'm currently working on https://issues.jboss.org/browse/KEYCLOAK-4903.
> >
> > This is all about allowing applications to push arbitrary claims to
> > Keycloak prior to evaluating permissions on the server. A simple example
> to
> > illustrate the idea: a request arrives you extract what you want from
> there
> > (parameters, headers, etc) and "push" the information from the request as
> > claims in order to evaluate your permissions.
> >
> > There are endless possibilities on what you can push and how.
> >
> > >From a design perspective, I was thinking about providing a SPI on the
> > adapter side (as simple as using ServiceLoader) to load built-in and
> > user-defined "claim information points". Examples of built-in
> > implementations would be:
> >
> > * Extract parameters
> > * Extract headers
> > * Extract path parameters
> > * Extract cookies
> > * Invoke an external "policy information point"
> >
> > What do you think ?
> >
> > Regards.
> > Pedro Igor
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
> --
> Bill Burke
> Red Hat
>

From psilva at redhat.com  Fri Apr  6 07:29:39 2018
From: psilva at redhat.com (Pedro Igor Silva)
Date: Fri, 6 Apr 2018 08:29:39 -0300
Subject: [keycloak-dev] Pushing Claims from Policy Enforcer
In-Reply-To: <CAJgngAfX+LaAzSLVpb72DNobYzj4nEmyeMoeDGdPHgUaL_vS7Q@mail.gmail.com>
References: <CAJrcDBd32CLhW5=P8SCKMv0FrNwB7GxhKtRWhh8qxaNjRj+4Fw@mail.gmail.com>
	<CAJgngAfX+LaAzSLVpb72DNobYzj4nEmyeMoeDGdPHgUaL_vS7Q@mail.gmail.com>
Message-ID: <CAJrcDBeouj3AqEbUnS9qK7NWR2A4RY2JMaySCuVG3r6nH9dd-w@mail.gmail.com>

Actually, that is being added as part of the work I'm doing. In fact, I
have this part done already. Now I'm trying to find the best approach to
enable this on the resource server side. Thus the reason for this thread as
well gather feedback from you.

On Fri, Apr 6, 2018 at 1:41 AM, Stian Thorgersen <sthorger at redhat.com>
wrote:

> Sounds like a nice addition to me. I pressume the RPT endpoint already has
> support for the server-side part?
>
> On 5 April 2018 at 16:41, Pedro Igor Silva <psilva at redhat.com> wrote:
>
>> Hi,
>>
>> I'm currently working on https://issues.jboss.org/browse/KEYCLOAK-4903.
>>
>> This is all about allowing applications to push arbitrary claims to
>> Keycloak prior to evaluating permissions on the server. A simple example
>> to
>> illustrate the idea: a request arrives you extract what you want from
>> there
>> (parameters, headers, etc) and "push" the information from the request as
>> claims in order to evaluate your permissions.
>>
>> There are endless possibilities on what you can push and how.
>>
>> >From a design perspective, I was thinking about providing a SPI on the
>> adapter side (as simple as using ServiceLoader) to load built-in and
>> user-defined "claim information points". Examples of built-in
>> implementations would be:
>>
>> * Extract parameters
>> * Extract headers
>> * Extract path parameters
>> * Extract cookies
>> * Invoke an external "policy information point"
>>
>> What do you think ?
>>
>> Regards.
>> Pedro Igor
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>

From bburke at redhat.com  Fri Apr  6 10:46:41 2018
From: bburke at redhat.com (Bill Burke)
Date: Fri, 6 Apr 2018 10:46:41 -0400
Subject: [keycloak-dev] Token validator endpoint (for humans)
In-Reply-To: <CAJgngAfJwwrhW5Gm6r20O3JHxujV5_a_=r5EZqgQN2Hk9+25RA@mail.gmail.com>
References: <CAJgngAf7fEw6o5sMdHNLMJkCkAFcANE5rfBe4e_Lv+6=MUttww@mail.gmail.com>
	<CAJrcDBfBROrqPCyF6et15EFx=ZZ=FGKuZu_1EEpsMG0OwjuFfA@mail.gmail.com>
	<CAJgngAdGBi2GD9J8UjC8zEKLorTxRqaBqgOMM+SUBOYiVSYkQA@mail.gmail.com>
	<CAJgngAcrHeRUXfzOMQFuFqjNHfo5jK27JQrB0V0iK16GEHiuNQ@mail.gmail.com>
	<CAJrcDBdzyO022j8PVT6Yr5-7OPLbELYiV8a4S85hFMY3fNrqjw@mail.gmail.com>
	<CAJgngAf7nWuNexAOk6kfHgU2XUCkYN_YhCGw45nXLZcOZN=DVw@mail.gmail.com>
	<CAJrcDBdseshnc7tUWQHL=VU-TGgCS5YgRTSUgeEQVD1Zzt3MYg@mail.gmail.com>
	<CAJgngAf_mM49m5u+mq6n2e_A_QgK3_DFpnjWbysjeSR4t2oXnA@mail.gmail.com>
	<CABRXCmyH3i8QSHWf4sUMiVTAf6dhB5v9d+XcNid6RVE0gQpHcw@mail.gmail.com>
	<CAJgngAdPRKrqCXNdECFc9ism9HHhd934DM1UwMA8CdkXutMf9Q@mail.gmail.com>
	<CABRXCmy71YnF2=wtOrVdFNVe=pQ4UnkP484GzFVbjCTJr5WiuA@mail.gmail.com>
	<CAJgngAfJwwrhW5Gm6r20O3JHxujV5_a_=r5EZqgQN2Hk9+25RA@mail.gmail.com>
Message-ID: <CABRXCmwcMbA27zTEAL+rQNAHNGcpKASCoUHffSJi3dTAUaPWmQ@mail.gmail.com>

On Fri, Apr 6, 2018 at 12:17 AM, Stian Thorgersen <sthorger at redhat.com> wrote:
>
>
> On 6 April 2018 at 04:39, Bill Burke <bburke at redhat.com> wrote:
>>
>> On Thu, Apr 5, 2018 at 3:46 PM, Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>> > This endpoint is meant to just return exactly what is in the token so a
>> > human can quickly copy/paste it to see what's in the base64 token.
>> > However,
>> > if it's JWE encrypted and should be opaque, then it obviously shouldn't
>> > decrypt the details and return it.
>> >
>> > As long as the token isn't JWE and just a JWT then the human could just
>> > as
>> > well have decoded the token himself, but this is just a tool to help
>> > doing
>> > that ;)
>> >
>> > On 5 April 2018 at 19:08, Bill Burke <bburke at redhat.com> wrote:
>> >>
>> >> If your service is receiving a valid active token, why does it matter
>> >> if it is a valid JWE or not?   Related to this is that protocol
>> >> mappers allow you to define how an access token, id token, AND the
>> >> user info service looks like.  Couldn't your endpoint just use the
>> >> user info output?  Then you are sure that you are not leaking
>> >> anything.
>> >>
>> >> BTW, we'll need such an "open endpoint" when reference tokens come in.
>> >
>> >
>> > Can you elaborate on that?
>> >
>>
>> public clients that have reference tokens need to validate them and
>> get user information from them.  Maybe that's just the user info
>> service though.
>
>
> That's actually a rather interesting problem just there. One reason folks
> want to have access tokens is that they don't want sensitive information to
> leave the organization boundary. As such we'd have to be really careful
> about what information is exposed and probably also somehow make it
> configurable.
>

My thought was that developers would just use the user info endpoint
to validate reference tokens.  We already have control, per client, of
what the user info service spits out.

FYI, kubernetes/openshift need a different endpoint like this, but
only username and group membership is outputted.  This is why I need
to add "groups" to client scope.



-- 
Bill Burke
Red Hat

From bburke at redhat.com  Fri Apr  6 10:51:58 2018
From: bburke at redhat.com (Bill Burke)
Date: Fri, 6 Apr 2018 10:51:58 -0400
Subject: [keycloak-dev] Pushing Claims from Policy Enforcer
In-Reply-To: <CAJrcDBf1wX451PwUtpz8_71DCtbnBvi2tTTVeOQtAkp8-ZCXRA@mail.gmail.com>
References: <CAJrcDBd32CLhW5=P8SCKMv0FrNwB7GxhKtRWhh8qxaNjRj+4Fw@mail.gmail.com>
	<CABRXCmydON+5e8WPv+iRk_RvLfSuTSRBty9CZcEJP2Q2Wht7uw@mail.gmail.com>
	<CAJrcDBf1wX451PwUtpz8_71DCtbnBvi2tTTVeOQtAkp8-ZCXRA@mail.gmail.com>
Message-ID: <CABRXCmwCteS+VQM=OPqEX47q_0jbez74V0c4XJ3nh0+_LtQt3g@mail.gmail.com>

Wouldn't a more generic hook be better.  One that allowed people to add
whatever they wanted to the attributes being pushed?  Rather than having
all this composition login within json?  Not saying I'm right and you are
wrong, just wondering if it would be better?

On Fri, Apr 6, 2018 at 7:26 AM, Pedro Igor Silva <psilva at redhat.com> wrote:

> If you are using the API directly, yes, you don't need this SPI ...
>
> But when using our policy enforcer (embedded within our adapters)
> developers don't actually use our API to call the permission endpoint. This
> is done by the policy enforcer itself, internally. The SPI is mainly
> targeted for applications using our adapters.
>
> The SPI serves for two purposes:
>
> 1) Allow developers to customize permission requests and push arbitrary
> claims to the permission endpoint (extension point)
> 2) Serve as the backbone for built-in "Claim Information Points", provided
> by us OOTB.
>
> As an example, here is how a configuration should looks like:
>
> "claim-information-point": [
>
> ????"claims": {
>
> ????????"claim-a": "{request.parameter['abc']}"
>
> ???? },
>
>     "http-service": {
>
>         "url": "abc"
>
>     }
>
> ]
>
> "Claim Information Point" is pretty much the same thing as a Policy
> Information Point. Each CIP Provider provides its own way to define claims
> to a permission request. In the example above, you are "pushing" a
> "claim-a" to your policies where the value would be a request parameter
> "abc".
>
> Makes more sense now ?
>
>
> On Fri, Apr 6, 2018 at 12:49 AM, Bill Burke <bburke at redhat.com> wrote:
>
>> I dont' understand...Why do you need an plugin SPI for this?  Wouldn't
>> the developer just call into your api to create the invocation to the
>> permission endpoint?
>>
>> On Thu, Apr 5, 2018 at 10:41 AM, Pedro Igor Silva <psilva at redhat.com>
>> wrote:
>> > Hi,
>> >
>> > I'm currently working on https://issues.jboss.org/browse/KEYCLOAK-4903.
>> >
>> > This is all about allowing applications to push arbitrary claims to
>> > Keycloak prior to evaluating permissions on the server. A simple
>> example to
>> > illustrate the idea: a request arrives you extract what you want from
>> there
>> > (parameters, headers, etc) and "push" the information from the request
>> as
>> > claims in order to evaluate your permissions.
>> >
>> > There are endless possibilities on what you can push and how.
>> >
>> > >From a design perspective, I was thinking about providing a SPI on the
>> > adapter side (as simple as using ServiceLoader) to load built-in and
>> > user-defined "claim information points". Examples of built-in
>> > implementations would be:
>> >
>> > * Extract parameters
>> > * Extract headers
>> > * Extract path parameters
>> > * Extract cookies
>> > * Invoke an external "policy information point"
>> >
>> > What do you think ?
>> >
>> > Regards.
>> > Pedro Igor
>> > _______________________________________________
>> > keycloak-dev mailing list
>> > keycloak-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>>
>> --
>> Bill Burke
>> Red Hat
>>
>
>


-- 
Bill Burke
Red Hat

From bburke at redhat.com  Fri Apr  6 11:00:38 2018
From: bburke at redhat.com (Bill Burke)
Date: Fri, 6 Apr 2018 11:00:38 -0400
Subject: [keycloak-dev] https://github.com/keycloak/keycloak/pull/4952
In-Reply-To: <CAJgngAeV1AzVo9tX7djR8k6zWK9=0zkG-1TOGf9Pt5bmkGP3bQ@mail.gmail.com>
References: <CAJgngAeV1AzVo9tX7djR8k6zWK9=0zkG-1TOGf9Pt5bmkGP3bQ@mail.gmail.com>
Message-ID: <CABRXCmydJiRDst0mo23PtBY8L0DiYmUXPU2SrKH0QZkePLE_1Q@mail.gmail.com>

Including keycloak-dev

Anybody have a link to the old email thread?  IIRC, there was a JIRA
that stated how it easy it was for an actual user (not an attacker) to
become locked out forever.

1. set max retries to 3
2. user enters in wrong password 3 times
3. user gets temporarily locked out
4. user tries to login again before the timeout is expired
5. Login fails even if user enters in right password as the account is
locked out
6. brute force wait time is incremented because there was a failure.
7. Loop to 4

Can't break the loop.

In reality it should work the same as your iphone.  Where the wait
time is only incremented if you enter in invalid credentials.




On Fri, Apr 6, 2018 at 3:11 AM, Stian Thorgersen <sthorger at redhat.com> wrote:
> What's going on with this one? We never reached a conclusion I believe if
> the current behaviour is what we want and we just need to add some
> clarification to docs or if we should change the behaviour.



-- 
Bill Burke
Red Hat

From psilva at redhat.com  Fri Apr  6 11:37:04 2018
From: psilva at redhat.com (Pedro Igor Silva)
Date: Fri, 6 Apr 2018 12:37:04 -0300
Subject: [keycloak-dev] Pushing Claims from Policy Enforcer
In-Reply-To: <CABRXCmwCteS+VQM=OPqEX47q_0jbez74V0c4XJ3nh0+_LtQt3g@mail.gmail.com>
References: <CAJrcDBd32CLhW5=P8SCKMv0FrNwB7GxhKtRWhh8qxaNjRj+4Fw@mail.gmail.com>
	<CABRXCmydON+5e8WPv+iRk_RvLfSuTSRBty9CZcEJP2Q2Wht7uw@mail.gmail.com>
	<CAJrcDBf1wX451PwUtpz8_71DCtbnBvi2tTTVeOQtAkp8-ZCXRA@mail.gmail.com>
	<CABRXCmwCteS+VQM=OPqEX47q_0jbez74V0c4XJ3nh0+_LtQt3g@mail.gmail.com>
Message-ID: <CAJrcDBftbRV4VtCLbFbjLyzmYDHBrr3bJS0oANik89kGkYy7Vg@mail.gmail.com>

Yeah, it is. And the SPI provides that. That is only what we provide OOTB
so you don't need to implement boiler plate code. But yeah, you can always
use a hook to add whatever you want.

FYI, some of these requirements (specially the OOTB config) was gathered
from a customer.

On Fri, Apr 6, 2018 at 11:51 AM, Bill Burke <bburke at redhat.com> wrote:

> Wouldn't a more generic hook be better.  One that allowed people to add
> whatever they wanted to the attributes being pushed?  Rather than having
> all this composition login within json?  Not saying I'm right and you are
> wrong, just wondering if it would be better?
>
> On Fri, Apr 6, 2018 at 7:26 AM, Pedro Igor Silva <psilva at redhat.com>
> wrote:
>
>> If you are using the API directly, yes, you don't need this SPI ...
>>
>> But when using our policy enforcer (embedded within our adapters)
>> developers don't actually use our API to call the permission endpoint. This
>> is done by the policy enforcer itself, internally. The SPI is mainly
>> targeted for applications using our adapters.
>>
>> The SPI serves for two purposes:
>>
>> 1) Allow developers to customize permission requests and push arbitrary
>> claims to the permission endpoint (extension point)
>> 2) Serve as the backbone for built-in "Claim Information Points",
>> provided by us OOTB.
>>
>> As an example, here is how a configuration should looks like:
>>
>> "claim-information-point": [
>>
>> ????"claims": {
>>
>> ????????"claim-a": "{request.parameter['abc']}"
>>
>> ???? },
>>
>>     "http-service": {
>>
>>         "url": "abc"
>>
>>     }
>>
>> ]
>>
>> "Claim Information Point" is pretty much the same thing as a Policy
>> Information Point. Each CIP Provider provides its own way to define claims
>> to a permission request. In the example above, you are "pushing" a
>> "claim-a" to your policies where the value would be a request parameter
>> "abc".
>>
>> Makes more sense now ?
>>
>>
>> On Fri, Apr 6, 2018 at 12:49 AM, Bill Burke <bburke at redhat.com> wrote:
>>
>>> I dont' understand...Why do you need an plugin SPI for this?  Wouldn't
>>> the developer just call into your api to create the invocation to the
>>> permission endpoint?
>>>
>>> On Thu, Apr 5, 2018 at 10:41 AM, Pedro Igor Silva <psilva at redhat.com>
>>> wrote:
>>> > Hi,
>>> >
>>> > I'm currently working on https://issues.jboss.org/browse/KEYCLOAK-4903
>>> .
>>> >
>>> > This is all about allowing applications to push arbitrary claims to
>>> > Keycloak prior to evaluating permissions on the server. A simple
>>> example to
>>> > illustrate the idea: a request arrives you extract what you want from
>>> there
>>> > (parameters, headers, etc) and "push" the information from the request
>>> as
>>> > claims in order to evaluate your permissions.
>>> >
>>> > There are endless possibilities on what you can push and how.
>>> >
>>> > >From a design perspective, I was thinking about providing a SPI on the
>>> > adapter side (as simple as using ServiceLoader) to load built-in and
>>> > user-defined "claim information points". Examples of built-in
>>> > implementations would be:
>>> >
>>> > * Extract parameters
>>> > * Extract headers
>>> > * Extract path parameters
>>> > * Extract cookies
>>> > * Invoke an external "policy information point"
>>> >
>>> > What do you think ?
>>> >
>>> > Regards.
>>> > Pedro Igor
>>> > _______________________________________________
>>> > keycloak-dev mailing list
>>> > keycloak-dev at lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>>
>>>
>>> --
>>> Bill Burke
>>> Red Hat
>>>
>>
>>
>
>
> --
> Bill Burke
> Red Hat
>

From ssilvert at redhat.com  Fri Apr  6 14:57:05 2018
From: ssilvert at redhat.com (Stan Silvert)
Date: Fri, 6 Apr 2018 14:57:05 -0400
Subject: [keycloak-dev] Must clear cookies
Message-ID: <3dce8150-ebf7-85f9-dec4-655436398109@redhat.com>

I just rebuilt Keycloak from scratch.? I created my admin user with 
add-user-keycloak.bat.

On first login, it wouldn't let me in and put this error in the log 
several times:

14:43:23,735 WARN? [org.keycloak.events] (default task-7) 
type=LOGIN_ERROR, realmId=master, clientId=null, userId=null, 
ipAddress=127.0.0.1, error=expired_code, restart_after_timeout=true

In order to login I had to clear my cookies.

Not sure what caused that but I've never had to do it before. Anybody 
have insight?

Stan


From michael_furman at hotmail.com  Sun Apr  8 07:25:38 2018
From: michael_furman at hotmail.com (Michael Furman)
Date: Sun, 8 Apr 2018 11:25:38 +0000
Subject: [keycloak-dev] Hardcoded Group Mapper for the broker authentication
Message-ID: <HE1P193MB023568C587EB4AA724A7667EF4B80@HE1P193MB0235.EURP193.PROD.OUTLOOK.COM>

Hi all,
I want to develop and to contribute Hardcoded Group Mapper for the broker authentication.
The behavior will be similar to org.keycloak.broker.provider.HardcodedRoleMapper.
What is the best approach to do it?
To open Jira and then to submit a patch?

Will you agree to add it to 3.4.x version?

Best regards,
   Michael


From bburke at redhat.com  Sun Apr  8 21:04:59 2018
From: bburke at redhat.com (Bill Burke)
Date: Sun, 8 Apr 2018 21:04:59 -0400
Subject: [keycloak-dev] bug: how did javascript adapter ever work?
Message-ID: <CABRXCmyJbK=nExp7A6KLuLJLiL7A-cnc_12GBh69p=+f4cQiPw@mail.gmail.com>

Does our javascript adapter use code to token flow by default?  Is
that the preferred mechanism?  I don't think anybody is using it and
has never used it if so, because...its broken.

I'm integrating with a non-keycloak html5 app that is using code to
token and the code to token request is failing with a CORS error.
This is because we do not set allowed origins in TokenEndpoint:

https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/protocol/oidc/endpoints/TokenEndpoint.java#L416

Embarrassing?  Or am i missing something?

-- 
Bill Burke
Red Hat

From bburke at redhat.com  Sun Apr  8 21:09:05 2018
From: bburke at redhat.com (Bill Burke)
Date: Sun, 8 Apr 2018 21:09:05 -0400
Subject: [keycloak-dev] bug: how did javascript adapter ever work?
In-Reply-To: <CABRXCmyJbK=nExp7A6KLuLJLiL7A-cnc_12GBh69p=+f4cQiPw@mail.gmail.com>
References: <CABRXCmyJbK=nExp7A6KLuLJLiL7A-cnc_12GBh69p=+f4cQiPw@mail.gmail.com>
Message-ID: <CABRXCmz6eYBqDVPvtPRni-0EPP1J-fvfMQJfA-0v3hkHtZ=fnw@mail.gmail.com>

Maybe its just a firefox thing?  The preflight sets the
ACCESS_CONTROL_ALLOW_ORIGIN, but I think firefox doesn't remember this
and expects the same header for the POST response to code to token.

On Sun, Apr 8, 2018 at 9:04 PM, Bill Burke <bburke at redhat.com> wrote:
> Does our javascript adapter use code to token flow by default?  Is
> that the preferred mechanism?  I don't think anybody is using it and
> has never used it if so, because...its broken.
>
> I'm integrating with a non-keycloak html5 app that is using code to
> token and the code to token request is failing with a CORS error.
> This is because we do not set allowed origins in TokenEndpoint:
>
> https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/protocol/oidc/endpoints/TokenEndpoint.java#L416
>
> Embarrassing?  Or am i missing something?
>
> --
> Bill Burke
> Red Hat



-- 
Bill Burke
Red Hat

From bburke at redhat.com  Sun Apr  8 21:16:06 2018
From: bburke at redhat.com (Bill Burke)
Date: Sun, 8 Apr 2018 21:16:06 -0400
Subject: [keycloak-dev] bug: how did javascript adapter ever work?
In-Reply-To: <CABRXCmz6eYBqDVPvtPRni-0EPP1J-fvfMQJfA-0v3hkHtZ=fnw@mail.gmail.com>
References: <CABRXCmyJbK=nExp7A6KLuLJLiL7A-cnc_12GBh69p=+f4cQiPw@mail.gmail.com>
	<CABRXCmz6eYBqDVPvtPRni-0EPP1J-fvfMQJfA-0v3hkHtZ=fnw@mail.gmail.com>
Message-ID: <CABRXCmxEG_JBJ9o=kUej6xer7BkmDqNTKJ+tgkocYNztDr8Bkg@mail.gmail.com>

Sorry, nevermind...you have to add allowed origins to client or a "+"
to add redirects.

On Sun, Apr 8, 2018 at 9:09 PM, Bill Burke <bburke at redhat.com> wrote:
> Maybe its just a firefox thing?  The preflight sets the
> ACCESS_CONTROL_ALLOW_ORIGIN, but I think firefox doesn't remember this
> and expects the same header for the POST response to code to token.
>
> On Sun, Apr 8, 2018 at 9:04 PM, Bill Burke <bburke at redhat.com> wrote:
>> Does our javascript adapter use code to token flow by default?  Is
>> that the preferred mechanism?  I don't think anybody is using it and
>> has never used it if so, because...its broken.
>>
>> I'm integrating with a non-keycloak html5 app that is using code to
>> token and the code to token request is failing with a CORS error.
>> This is because we do not set allowed origins in TokenEndpoint:
>>
>> https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/protocol/oidc/endpoints/TokenEndpoint.java#L416
>>
>> Embarrassing?  Or am i missing something?
>>
>> --
>> Bill Burke
>> Red Hat
>
>
>
> --
> Bill Burke
> Red Hat



-- 
Bill Burke
Red Hat

From pkboucher801 at gmail.com  Tue Apr 10 15:11:06 2018
From: pkboucher801 at gmail.com (Peter K. Boucher)
Date: Tue, 10 Apr 2018 15:11:06 -0400
Subject: [keycloak-dev] Reopened bug in SAML processing - Destination
	Validation should ignore whether default port is explicitly
	specified
Message-ID: <001201d3d0ff$b02fd900$108f8b00$@gmail.com>

I don't have permission from my employer to make a pull request, but I did
enter a bug and tell you how to fix it:
https://issues.jboss.org/browse/KEYCLOAK-6832 



From sthorger at redhat.com  Tue Apr 10 15:18:13 2018
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 10 Apr 2018 21:18:13 +0200
Subject: [keycloak-dev] Hardcoded Group Mapper for the broker
	authentication
In-Reply-To: <HE1P193MB023568C587EB4AA724A7667EF4B80@HE1P193MB0235.EURP193.PROD.OUTLOOK.COM>
References: <HE1P193MB023568C587EB4AA724A7667EF4B80@HE1P193MB0235.EURP193.PROD.OUTLOOK.COM>
Message-ID: <CAJgngAeXR-VfX9pyd_KhKorH2MPFD1QEafn6ipcWZ75AK9HEwQ@mail.gmail.com>

On 8 April 2018 at 13:25, Michael Furman <michael_furman at hotmail.com> wrote:

> Hi all,
> I want to develop and to contribute Hardcoded Group Mapper for the broker
> authentication.
> The behavior will be similar to org.keycloak.broker.provider.
> HardcodedRoleMapper.
> What is the best approach to do it?
> To open Jira and then to submit a patch?
>

JIRA + PR including tests


>
> Will you agree to add it to 3.4.x version?
>

No, we are no longer maintaining 3.x in community and will not be doing any
more 3.x releases.


>
> Best regards,
>    Michael
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sthorger at redhat.com  Tue Apr 10 15:18:46 2018
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 10 Apr 2018 21:18:46 +0200
Subject: [keycloak-dev] Must clear cookies
In-Reply-To: <3dce8150-ebf7-85f9-dec4-655436398109@redhat.com>
References: <3dce8150-ebf7-85f9-dec4-655436398109@redhat.com>
Message-ID: <CAJgngAdjaqMtYRpiTQ1Jmm87BkoYRzh_6UWXaBwiRbF792XDpQ@mail.gmail.com>

That's not good. Do you know how to reproduce?

On 6 April 2018 at 20:57, Stan Silvert <ssilvert at redhat.com> wrote:

> I just rebuilt Keycloak from scratch.  I created my admin user with
> add-user-keycloak.bat.
>
> On first login, it wouldn't let me in and put this error in the log
> several times:
>
> 14:43:23,735 WARN  [org.keycloak.events] (default task-7)
> type=LOGIN_ERROR, realmId=master, clientId=null, userId=null,
> ipAddress=127.0.0.1, error=expired_code, restart_after_timeout=true
>
> In order to login I had to clear my cookies.
>
> Not sure what caused that but I've never had to do it before. Anybody
> have insight?
>
> Stan
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From beberg at redhat.com  Wed Apr 11 09:24:03 2018
From: beberg at redhat.com (Benjamin Berg)
Date: Wed, 11 Apr 2018 09:24:03 -0400
Subject: [keycloak-dev] Introduction and Opening Discussion about
 [KEYCLOAK-7043] Certificate Expiration Notification Feature
Message-ID: <CAKxE3M1Wkh=JsB-9VAEWcf=3CsAtme55+V4rG_0s3XcJzcB7PQ@mail.gmail.com>

Hi Keycloak Developers,

I'm Benjamin Berg, I'm an Associate Software Applications Engineer, have
recently joined a team that utilizes Keycloak and just about a week ago, I
submitted a pull request introducing a new feature into Keycloak.  Inside
that pull request on GitHub, I had received a comment from "stainst" to
come onto this mailing list and open a discussion.  So I thought I'd
introduce myself and send you some information about the feature (info down
below) I had developed.  I appreciate getting any feedback and I hope you
all like this new addition!

==========================================

*-Problem-*
Certificates in the realm(s) and client(s) expire quietly.
*-Solution-*
Certificates in the realm(s) and client(s) need to send out an email
notification if they are about to expire (or have already expired).
*-Pull Request https://github.com/keycloak/keycloak/pull/5121
<https://github.com/keycloak/keycloak/pull/5121>-*
You can now setup email notifications for when certificates in the realm(s)
and client(s) that are about to expire (or have already expired).














*-Description from the Pull Request-'''Description:You can now setup email
notifications for when certificates in the realm(s) and client(s) are about
to expire (or have already expired).High Level Overview of
Changes:Front-End: Incorporated a field to the "Realm Settings" tab "Email"
called "Certificate Notification Email Address" where you enter an email
address that you want to have certificate expiration notifications sent
to.Back-End: Created classes that are scheduled to check both the realm(s)
and client(s) for certificates that have or are about to
expire.Testing:Created unit tests for added code and Travis-CI tests
pass.JIRALink: *


*KEYCLOAK-7043 <https://issues.jboss.org/browse/KEYCLOAK-7043>Description:
Certificates in the realm(s) and client(s) need to send out an email
notification if they are about to expire (or have already expired).'''*
==========================================



Cheers!

-- 
Benjamin Jacob Berg
Associate Software Applications Engineer

Red Hat Inc
100 East Davie Street
Raleigh NC, 27601

Email: benjamin.berg at redhat.com
Phone: +19197490752
IRC: benjamin

From psilva at redhat.com  Thu Apr 12 09:27:01 2018
From: psilva at redhat.com (Pedro Igor Silva)
Date: Thu, 12 Apr 2018 10:27:01 -0300
Subject: [keycloak-dev] Buffered InputStream in HttpFacade
Message-ID: <CAJrcDBevm8m=96xpYNkzD6yU=3maR1U4rz-uOgZJFCTEVO+8WA@mail.gmail.com>

I would like to add a new method to HttpFacade.Request interface in order
to be able to obtain a buffered input stream.

The requirement is that I need to read the inputstream before passing it to
the application.

This will not change current behavior for those using
HttpFacade.Request.getInputStream.

Any objection ?

Regards.
Pedro Igor

From bburke at redhat.com  Thu Apr 12 13:36:02 2018
From: bburke at redhat.com (Bill Burke)
Date: Thu, 12 Apr 2018 13:36:02 -0400
Subject: [keycloak-dev] Buffered InputStream in HttpFacade
In-Reply-To: <CAJrcDBevm8m=96xpYNkzD6yU=3maR1U4rz-uOgZJFCTEVO+8WA@mail.gmail.com>
References: <CAJrcDBevm8m=96xpYNkzD6yU=3maR1U4rz-uOgZJFCTEVO+8WA@mail.gmail.com>
Message-ID: <CABRXCmwjQmzD+3K8nojMkG+=eXADHETSu8PMWOPxZivpK3hC+A@mail.gmail.com>

No objects so long as it works on Jetty, Tomcat too.

On Thu, Apr 12, 2018 at 9:27 AM, Pedro Igor Silva <psilva at redhat.com> wrote:
> I would like to add a new method to HttpFacade.Request interface in order
> to be able to obtain a buffered input stream.
>
> The requirement is that I need to read the inputstream before passing it to
> the application.
>
> This will not change current behavior for those using
> HttpFacade.Request.getInputStream.
>
> Any objection ?
>
> Regards.
> Pedro Igor
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



-- 
Bill Burke
Red Hat

From bburke at redhat.com  Thu Apr 12 18:06:32 2018
From: bburke at redhat.com (Bill Burke)
Date: Thu, 12 Apr 2018 18:06:32 -0400
Subject: [keycloak-dev] Pushing Claims from Policy Enforcer
In-Reply-To: <CAJrcDBftbRV4VtCLbFbjLyzmYDHBrr3bJS0oANik89kGkYy7Vg@mail.gmail.com>
References: <CAJrcDBd32CLhW5=P8SCKMv0FrNwB7GxhKtRWhh8qxaNjRj+4Fw@mail.gmail.com>
	<CABRXCmydON+5e8WPv+iRk_RvLfSuTSRBty9CZcEJP2Q2Wht7uw@mail.gmail.com>
	<CAJrcDBf1wX451PwUtpz8_71DCtbnBvi2tTTVeOQtAkp8-ZCXRA@mail.gmail.com>
	<CABRXCmwCteS+VQM=OPqEX47q_0jbez74V0c4XJ3nh0+_LtQt3g@mail.gmail.com>
	<CAJrcDBftbRV4VtCLbFbjLyzmYDHBrr3bJS0oANik89kGkYy7Vg@mail.gmail.com>
Message-ID: <CABRXCmyvr86NvzGoV=T8rP+sP4Skz528H43Auz-_vf2CqEtnpA@mail.gmail.com>

How are your golang skills?   We're going to need all this stuff in the
proxy :)  Don't know if you were in the meeting today...

On Fri, Apr 6, 2018 at 11:37 AM, Pedro Igor Silva <psilva at redhat.com> wrote:

> Yeah, it is. And the SPI provides that. That is only what we provide OOTB
> so you don't need to implement boiler plate code. But yeah, you can always
> use a hook to add whatever you want.
>
> FYI, some of these requirements (specially the OOTB config) was gathered
> from a customer.
>
> On Fri, Apr 6, 2018 at 11:51 AM, Bill Burke <bburke at redhat.com> wrote:
>
>> Wouldn't a more generic hook be better.  One that allowed people to add
>> whatever they wanted to the attributes being pushed?  Rather than having
>> all this composition login within json?  Not saying I'm right and you are
>> wrong, just wondering if it would be better?
>>
>> On Fri, Apr 6, 2018 at 7:26 AM, Pedro Igor Silva <psilva at redhat.com>
>> wrote:
>>
>>> If you are using the API directly, yes, you don't need this SPI ...
>>>
>>> But when using our policy enforcer (embedded within our adapters)
>>> developers don't actually use our API to call the permission endpoint. This
>>> is done by the policy enforcer itself, internally. The SPI is mainly
>>> targeted for applications using our adapters.
>>>
>>> The SPI serves for two purposes:
>>>
>>> 1) Allow developers to customize permission requests and push arbitrary
>>> claims to the permission endpoint (extension point)
>>> 2) Serve as the backbone for built-in "Claim Information Points",
>>> provided by us OOTB.
>>>
>>> As an example, here is how a configuration should looks like:
>>>
>>> "claim-information-point": [
>>>
>>> ????"claims": {
>>>
>>> ????????"claim-a": "{request.parameter['abc']}"
>>>
>>> ???? },
>>>
>>>     "http-service": {
>>>
>>>         "url": "abc"
>>>
>>>     }
>>>
>>> ]
>>>
>>> "Claim Information Point" is pretty much the same thing as a Policy
>>> Information Point. Each CIP Provider provides its own way to define claims
>>> to a permission request. In the example above, you are "pushing" a
>>> "claim-a" to your policies where the value would be a request parameter
>>> "abc".
>>>
>>> Makes more sense now ?
>>>
>>>
>>> On Fri, Apr 6, 2018 at 12:49 AM, Bill Burke <bburke at redhat.com> wrote:
>>>
>>>> I dont' understand...Why do you need an plugin SPI for this?  Wouldn't
>>>> the developer just call into your api to create the invocation to the
>>>> permission endpoint?
>>>>
>>>> On Thu, Apr 5, 2018 at 10:41 AM, Pedro Igor Silva <psilva at redhat.com>
>>>> wrote:
>>>> > Hi,
>>>> >
>>>> > I'm currently working on https://issues.jboss.org/brows
>>>> e/KEYCLOAK-4903.
>>>> >
>>>> > This is all about allowing applications to push arbitrary claims to
>>>> > Keycloak prior to evaluating permissions on the server. A simple
>>>> example to
>>>> > illustrate the idea: a request arrives you extract what you want from
>>>> there
>>>> > (parameters, headers, etc) and "push" the information from the
>>>> request as
>>>> > claims in order to evaluate your permissions.
>>>> >
>>>> > There are endless possibilities on what you can push and how.
>>>> >
>>>> > >From a design perspective, I was thinking about providing a SPI on
>>>> the
>>>> > adapter side (as simple as using ServiceLoader) to load built-in and
>>>> > user-defined "claim information points". Examples of built-in
>>>> > implementations would be:
>>>> >
>>>> > * Extract parameters
>>>> > * Extract headers
>>>> > * Extract path parameters
>>>> > * Extract cookies
>>>> > * Invoke an external "policy information point"
>>>> >
>>>> > What do you think ?
>>>> >
>>>> > Regards.
>>>> > Pedro Igor
>>>> > _______________________________________________
>>>> > keycloak-dev mailing list
>>>> > keycloak-dev at lists.jboss.org
>>>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>>>
>>>>
>>>> --
>>>> Bill Burke
>>>> Red Hat
>>>>
>>>
>>>
>>
>>
>> --
>> Bill Burke
>> Red Hat
>>
>
>


-- 
Bill Burke
Red Hat

From bburke at redhat.com  Thu Apr 12 18:09:36 2018
From: bburke at redhat.com (Bill Burke)
Date: Thu, 12 Apr 2018 18:09:36 -0400
Subject: [keycloak-dev] reference tokens
Message-ID: <CABRXCmxqZZxdcNfNyEtJpSo-QoMfywEt=5yYvKm-CzzrQSwkBQ@mail.gmail.com>

I'm going to need to implement reference tokens for openshift soon
after I come back from vacation.  I've tried to spec it out here:

https://issues.jboss.org/browse/KEYCLOAK-7002



-- 
Bill Burke
Red Hat

From sthorger at redhat.com  Fri Apr 13 01:15:04 2018
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 13 Apr 2018 07:15:04 +0200
Subject: [keycloak-dev] Introduction and Opening Discussion about
 [KEYCLOAK-7043] Certificate Expiration Notification Feature
In-Reply-To: <CAKxE3M1Wkh=JsB-9VAEWcf=3CsAtme55+V4rG_0s3XcJzcB7PQ@mail.gmail.com>
References: <CAKxE3M1Wkh=JsB-9VAEWcf=3CsAtme55+V4rG_0s3XcJzcB7PQ@mail.gmail.com>
Message-ID: <CAJgngAfzwNCvsdiRD2Y1YWVx1Hfvn2U7gE5E07G31FXjduuTxQ@mail.gmail.com>

Thanks, I added some comments to the PR

On 11 April 2018 at 15:24, Benjamin Berg <beberg at redhat.com> wrote:

> Hi Keycloak Developers,
>
> I'm Benjamin Berg, I'm an Associate Software Applications Engineer, have
> recently joined a team that utilizes Keycloak and just about a week ago, I
> submitted a pull request introducing a new feature into Keycloak.  Inside
> that pull request on GitHub, I had received a comment from "stainst" to
> come onto this mailing list and open a discussion.  So I thought I'd
> introduce myself and send you some information about the feature (info down
> below) I had developed.  I appreciate getting any feedback and I hope you
> all like this new addition!
>
> ==========================================
>
> *-Problem-*
> Certificates in the realm(s) and client(s) expire quietly.
> *-Solution-*
> Certificates in the realm(s) and client(s) need to send out an email
> notification if they are about to expire (or have already expired).
> *-Pull Request https://github.com/keycloak/keycloak/pull/5121
> <https://github.com/keycloak/keycloak/pull/5121>-*
> You can now setup email notifications for when certificates in the realm(s)
> and client(s) that are about to expire (or have already expired).
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *-Description from the Pull Request-'''Description:You can now setup email
> notifications for when certificates in the realm(s) and client(s) are about
> to expire (or have already expired).High Level Overview of
> Changes:Front-End: Incorporated a field to the "Realm Settings" tab "Email"
> called "Certificate Notification Email Address" where you enter an email
> address that you want to have certificate expiration notifications sent
> to.Back-End: Created classes that are scheduled to check both the realm(s)
> and client(s) for certificates that have or are about to
> expire.Testing:Created unit tests for added code and Travis-CI tests
> pass.JIRALink: *
>
>
> *KEYCLOAK-7043 <https://issues.jboss.org/browse/KEYCLOAK-7043>Description:
> Certificates in the realm(s) and client(s) need to send out an email
> notification if they are about to expire (or have already expired).'''*
> ==========================================
>
>
>
> Cheers!
>
> --
> Benjamin Jacob Berg
> Associate Software Applications Engineer
>
> Red Hat Inc
> 100 East Davie Street
> Raleigh NC, 27601
>
> Email: benjamin.berg at redhat.com
> Phone: +19197490752
> IRC: benjamin
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From psilva at redhat.com  Fri Apr 13 08:23:34 2018
From: psilva at redhat.com (Pedro Igor Silva)
Date: Fri, 13 Apr 2018 09:23:34 -0300
Subject: [keycloak-dev] Pushing Claims from Policy Enforcer
In-Reply-To: <CABRXCmyvr86NvzGoV=T8rP+sP4Skz528H43Auz-_vf2CqEtnpA@mail.gmail.com>
References: <CAJrcDBd32CLhW5=P8SCKMv0FrNwB7GxhKtRWhh8qxaNjRj+4Fw@mail.gmail.com>
	<CABRXCmydON+5e8WPv+iRk_RvLfSuTSRBty9CZcEJP2Q2Wht7uw@mail.gmail.com>
	<CAJrcDBf1wX451PwUtpz8_71DCtbnBvi2tTTVeOQtAkp8-ZCXRA@mail.gmail.com>
	<CABRXCmwCteS+VQM=OPqEX47q_0jbez74V0c4XJ3nh0+_LtQt3g@mail.gmail.com>
	<CAJrcDBftbRV4VtCLbFbjLyzmYDHBrr3bJS0oANik89kGkYy7Vg@mail.gmail.com>
	<CABRXCmyvr86NvzGoV=T8rP+sP4Skz528H43Auz-_vf2CqEtnpA@mail.gmail.com>
Message-ID: <CAJrcDBczBSKqs2p8gBjo1cOPi1z-gbv0Ue2cN63gZQAwawRmUQ@mail.gmail.com>

Yeah, I missed the meeting. But I have looked the slides and, yeah, we are
going to need our authz stuff there ....

In fact, I hope to start working more with team-cloud team and see how we
can improve authorization experience for cloud native applications. The
proxy will be a great start as well how we can leverage Istio/sidecars to
enable authz.

There is an open issue on for that proxy [1] around authorization using
Cabin. Feature wise we support the same thing but using a different model,
more integrated with Keycloak (of course) . Our use cases go beyond REST
security (which have improved a lot in Sprint 4) and also cover privacy,
with UMA.

Hope I can get some tips from you about go when I start this :)

[1] https://github.com/gambol99/keycloak-proxy

On Thu, Apr 12, 2018 at 7:06 PM, Bill Burke <bburke at redhat.com> wrote:

> How are your golang skills?   We're going to need all this stuff in the
> proxy :)  Don't know if you were in the meeting today...
>
> On Fri, Apr 6, 2018 at 11:37 AM, Pedro Igor Silva <psilva at redhat.com>
> wrote:
>
>> Yeah, it is. And the SPI provides that. That is only what we provide OOTB
>> so you don't need to implement boiler plate code. But yeah, you can always
>> use a hook to add whatever you want.
>>
>> FYI, some of these requirements (specially the OOTB config) was gathered
>> from a customer.
>>
>> On Fri, Apr 6, 2018 at 11:51 AM, Bill Burke <bburke at redhat.com> wrote:
>>
>>> Wouldn't a more generic hook be better.  One that allowed people to add
>>> whatever they wanted to the attributes being pushed?  Rather than having
>>> all this composition login within json?  Not saying I'm right and you are
>>> wrong, just wondering if it would be better?
>>>
>>> On Fri, Apr 6, 2018 at 7:26 AM, Pedro Igor Silva <psilva at redhat.com>
>>> wrote:
>>>
>>>> If you are using the API directly, yes, you don't need this SPI ...
>>>>
>>>> But when using our policy enforcer (embedded within our adapters)
>>>> developers don't actually use our API to call the permission endpoint. This
>>>> is done by the policy enforcer itself, internally. The SPI is mainly
>>>> targeted for applications using our adapters.
>>>>
>>>> The SPI serves for two purposes:
>>>>
>>>> 1) Allow developers to customize permission requests and push arbitrary
>>>> claims to the permission endpoint (extension point)
>>>> 2) Serve as the backbone for built-in "Claim Information Points",
>>>> provided by us OOTB.
>>>>
>>>> As an example, here is how a configuration should looks like:
>>>>
>>>> "claim-information-point": [
>>>>
>>>> ????"claims": {
>>>>
>>>> ????????"claim-a": "{request.parameter['abc']}"
>>>>
>>>> ???? },
>>>>
>>>>     "http-service": {
>>>>
>>>>         "url": "abc"
>>>>
>>>>     }
>>>>
>>>> ]
>>>>
>>>> "Claim Information Point" is pretty much the same thing as a Policy
>>>> Information Point. Each CIP Provider provides its own way to define claims
>>>> to a permission request. In the example above, you are "pushing" a
>>>> "claim-a" to your policies where the value would be a request parameter
>>>> "abc".
>>>>
>>>> Makes more sense now ?
>>>>
>>>>
>>>> On Fri, Apr 6, 2018 at 12:49 AM, Bill Burke <bburke at redhat.com> wrote:
>>>>
>>>>> I dont' understand...Why do you need an plugin SPI for this?  Wouldn't
>>>>> the developer just call into your api to create the invocation to the
>>>>> permission endpoint?
>>>>>
>>>>> On Thu, Apr 5, 2018 at 10:41 AM, Pedro Igor Silva <psilva at redhat.com>
>>>>> wrote:
>>>>> > Hi,
>>>>> >
>>>>> > I'm currently working on https://issues.jboss.org/brows
>>>>> e/KEYCLOAK-4903.
>>>>> >
>>>>> > This is all about allowing applications to push arbitrary claims to
>>>>> > Keycloak prior to evaluating permissions on the server. A simple
>>>>> example to
>>>>> > illustrate the idea: a request arrives you extract what you want
>>>>> from there
>>>>> > (parameters, headers, etc) and "push" the information from the
>>>>> request as
>>>>> > claims in order to evaluate your permissions.
>>>>> >
>>>>> > There are endless possibilities on what you can push and how.
>>>>> >
>>>>> > >From a design perspective, I was thinking about providing a SPI on
>>>>> the
>>>>> > adapter side (as simple as using ServiceLoader) to load built-in and
>>>>> > user-defined "claim information points". Examples of built-in
>>>>> > implementations would be:
>>>>> >
>>>>> > * Extract parameters
>>>>> > * Extract headers
>>>>> > * Extract path parameters
>>>>> > * Extract cookies
>>>>> > * Invoke an external "policy information point"
>>>>> >
>>>>> > What do you think ?
>>>>> >
>>>>> > Regards.
>>>>> > Pedro Igor
>>>>> > _______________________________________________
>>>>> > keycloak-dev mailing list
>>>>> > keycloak-dev at lists.jboss.org
>>>>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Bill Burke
>>>>> Red Hat
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Bill Burke
>>> Red Hat
>>>
>>
>>
>
>
> --
> Bill Burke
> Red Hat
>

From bburke at redhat.com  Fri Apr 13 09:18:55 2018
From: bburke at redhat.com (Bill Burke)
Date: Fri, 13 Apr 2018 09:18:55 -0400
Subject: [keycloak-dev] Pushing Claims from Policy Enforcer
In-Reply-To: <CAJrcDBczBSKqs2p8gBjo1cOPi1z-gbv0Ue2cN63gZQAwawRmUQ@mail.gmail.com>
References: <CAJrcDBd32CLhW5=P8SCKMv0FrNwB7GxhKtRWhh8qxaNjRj+4Fw@mail.gmail.com>
	<CABRXCmydON+5e8WPv+iRk_RvLfSuTSRBty9CZcEJP2Q2Wht7uw@mail.gmail.com>
	<CAJrcDBf1wX451PwUtpz8_71DCtbnBvi2tTTVeOQtAkp8-ZCXRA@mail.gmail.com>
	<CABRXCmwCteS+VQM=OPqEX47q_0jbez74V0c4XJ3nh0+_LtQt3g@mail.gmail.com>
	<CAJrcDBftbRV4VtCLbFbjLyzmYDHBrr3bJS0oANik89kGkYy7Vg@mail.gmail.com>
	<CABRXCmyvr86NvzGoV=T8rP+sP4Skz528H43Auz-_vf2CqEtnpA@mail.gmail.com>
	<CAJrcDBczBSKqs2p8gBjo1cOPi1z-gbv0Ue2cN63gZQAwawRmUQ@mail.gmail.com>
Message-ID: <CABRXCmz_tn3=q6=SHvu5PxFZp0SwYDo=Ph8og=z17-kXywC+iQ@mail.gmail.com>

I'm just brainstorming here and this probably should be under a different
topic, but:

I'm a bit concerned about putting all our eggs in the Istio basket.  The
first concern is it might have to be C++, although the APIs I looked at
were all Golang.  2nd the Golang APIs looked like they didn't have the
concept of an HTTP session.

On Fri, Apr 13, 2018 at 8:23 AM, Pedro Igor Silva <psilva at redhat.com> wrote:

> Yeah, I missed the meeting. But I have looked the slides and, yeah, we are
> going to need our authz stuff there ....
>
> In fact, I hope to start working more with team-cloud team and see how we
> can improve authorization experience for cloud native applications. The
> proxy will be a great start as well how we can leverage Istio/sidecars to
> enable authz.
>
> There is an open issue on for that proxy [1] around authorization using
> Cabin. Feature wise we support the same thing but using a different model,
> more integrated with Keycloak (of course) . Our use cases go beyond REST
> security (which have improved a lot in Sprint 4) and also cover privacy,
> with UMA.
>
> Hope I can get some tips from you about go when I start this :)
>
> [1] https://github.com/gambol99/keycloak-proxy
>
> On Thu, Apr 12, 2018 at 7:06 PM, Bill Burke <bburke at redhat.com> wrote:
>
>> How are your golang skills?   We're going to need all this stuff in the
>> proxy :)  Don't know if you were in the meeting today...
>>
>> On Fri, Apr 6, 2018 at 11:37 AM, Pedro Igor Silva <psilva at redhat.com>
>> wrote:
>>
>>> Yeah, it is. And the SPI provides that. That is only what we provide
>>> OOTB so you don't need to implement boiler plate code. But yeah, you can
>>> always use a hook to add whatever you want.
>>>
>>> FYI, some of these requirements (specially the OOTB config) was gathered
>>> from a customer.
>>>
>>> On Fri, Apr 6, 2018 at 11:51 AM, Bill Burke <bburke at redhat.com> wrote:
>>>
>>>> Wouldn't a more generic hook be better.  One that allowed people to add
>>>> whatever they wanted to the attributes being pushed?  Rather than having
>>>> all this composition login within json?  Not saying I'm right and you are
>>>> wrong, just wondering if it would be better?
>>>>
>>>> On Fri, Apr 6, 2018 at 7:26 AM, Pedro Igor Silva <psilva at redhat.com>
>>>> wrote:
>>>>
>>>>> If you are using the API directly, yes, you don't need this SPI ...
>>>>>
>>>>> But when using our policy enforcer (embedded within our adapters)
>>>>> developers don't actually use our API to call the permission endpoint. This
>>>>> is done by the policy enforcer itself, internally. The SPI is mainly
>>>>> targeted for applications using our adapters.
>>>>>
>>>>> The SPI serves for two purposes:
>>>>>
>>>>> 1) Allow developers to customize permission requests and push
>>>>> arbitrary claims to the permission endpoint (extension point)
>>>>> 2) Serve as the backbone for built-in "Claim Information Points",
>>>>> provided by us OOTB.
>>>>>
>>>>> As an example, here is how a configuration should looks like:
>>>>>
>>>>> "claim-information-point": [
>>>>>
>>>>> ????"claims": {
>>>>>
>>>>> ????????"claim-a": "{request.parameter['abc']}"
>>>>>
>>>>> ???? },
>>>>>
>>>>>     "http-service": {
>>>>>
>>>>>         "url": "abc"
>>>>>
>>>>>     }
>>>>>
>>>>> ]
>>>>>
>>>>> "Claim Information Point" is pretty much the same thing as a Policy
>>>>> Information Point. Each CIP Provider provides its own way to define claims
>>>>> to a permission request. In the example above, you are "pushing" a
>>>>> "claim-a" to your policies where the value would be a request parameter
>>>>> "abc".
>>>>>
>>>>> Makes more sense now ?
>>>>>
>>>>>
>>>>> On Fri, Apr 6, 2018 at 12:49 AM, Bill Burke <bburke at redhat.com> wrote:
>>>>>
>>>>>> I dont' understand...Why do you need an plugin SPI for this?  Wouldn't
>>>>>> the developer just call into your api to create the invocation to the
>>>>>> permission endpoint?
>>>>>>
>>>>>> On Thu, Apr 5, 2018 at 10:41 AM, Pedro Igor Silva <psilva at redhat.com>
>>>>>> wrote:
>>>>>> > Hi,
>>>>>> >
>>>>>> > I'm currently working on https://issues.jboss.org/brows
>>>>>> e/KEYCLOAK-4903.
>>>>>> >
>>>>>> > This is all about allowing applications to push arbitrary claims to
>>>>>> > Keycloak prior to evaluating permissions on the server. A simple
>>>>>> example to
>>>>>> > illustrate the idea: a request arrives you extract what you want
>>>>>> from there
>>>>>> > (parameters, headers, etc) and "push" the information from the
>>>>>> request as
>>>>>> > claims in order to evaluate your permissions.
>>>>>> >
>>>>>> > There are endless possibilities on what you can push and how.
>>>>>> >
>>>>>> > >From a design perspective, I was thinking about providing a SPI on
>>>>>> the
>>>>>> > adapter side (as simple as using ServiceLoader) to load built-in and
>>>>>> > user-defined "claim information points". Examples of built-in
>>>>>> > implementations would be:
>>>>>> >
>>>>>> > * Extract parameters
>>>>>> > * Extract headers
>>>>>> > * Extract path parameters
>>>>>> > * Extract cookies
>>>>>> > * Invoke an external "policy information point"
>>>>>> >
>>>>>> > What do you think ?
>>>>>> >
>>>>>> > Regards.
>>>>>> > Pedro Igor
>>>>>> > _______________________________________________
>>>>>> > keycloak-dev mailing list
>>>>>> > keycloak-dev at lists.jboss.org
>>>>>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Bill Burke
>>>>>> Red Hat
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Bill Burke
>>>> Red Hat
>>>>
>>>
>>>
>>
>>
>> --
>> Bill Burke
>> Red Hat
>>
>
>


-- 
Bill Burke
Red Hat

From ssilvert at redhat.com  Sun Apr 15 20:44:24 2018
From: ssilvert at redhat.com (Stan Silvert)
Date: Sun, 15 Apr 2018 20:44:24 -0400
Subject: [keycloak-dev] ui_locales query parameter?
Message-ID: <9599201b-a4ef-d306-0c10-a244a89812c1@redhat.com>

Does anyone know what ui_locales is actually used for?

I can't find usages except for in the testsuite.

The query param used to change locale is kc_locale.? Should ui_locales 
deprecated?

Stan


From sthorger at redhat.com  Mon Apr 16 02:45:53 2018
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 16 Apr 2018 08:45:53 +0200
Subject: [keycloak-dev] ui_locales query parameter?
In-Reply-To: <9599201b-a4ef-d306-0c10-a244a89812c1@redhat.com>
References: <9599201b-a4ef-d306-0c10-a244a89812c1@redhat.com>
Message-ID: <CAJgngAeU_vro9weu5C_Rfx6Jc0Gu4M+a5yWE5VvQ0XCfGDZv5w@mail.gmail.com>

It's a query param defined by OpenID Connect. See
http://openid.net/specs/openid-connect-core-1_0.html. It allows the
application to pass a list of req locales in case the application knows it.

When doing the redirect login flow the applications should use ui_locales.
kc_locale is an internal param and should really only be used by the locale
switcher on the login screen.

On 16 April 2018 at 02:44, Stan Silvert <ssilvert at redhat.com> wrote:

> Does anyone know what ui_locales is actually used for?
>
> I can't find usages except for in the testsuite.
>
> The query param used to change locale is kc_locale.  Should ui_locales
> deprecated?
>
> Stan
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From psilva at redhat.com  Mon Apr 16 08:46:19 2018
From: psilva at redhat.com (Pedro Igor Silva)
Date: Mon, 16 Apr 2018 09:46:19 -0300
Subject: [keycloak-dev] Pushing Claims from Policy Enforcer
In-Reply-To: <CABRXCmz_tn3=q6=SHvu5PxFZp0SwYDo=Ph8og=z17-kXywC+iQ@mail.gmail.com>
References: <CAJrcDBd32CLhW5=P8SCKMv0FrNwB7GxhKtRWhh8qxaNjRj+4Fw@mail.gmail.com>
	<CABRXCmydON+5e8WPv+iRk_RvLfSuTSRBty9CZcEJP2Q2Wht7uw@mail.gmail.com>
	<CAJrcDBf1wX451PwUtpz8_71DCtbnBvi2tTTVeOQtAkp8-ZCXRA@mail.gmail.com>
	<CABRXCmwCteS+VQM=OPqEX47q_0jbez74V0c4XJ3nh0+_LtQt3g@mail.gmail.com>
	<CAJrcDBftbRV4VtCLbFbjLyzmYDHBrr3bJS0oANik89kGkYy7Vg@mail.gmail.com>
	<CABRXCmyvr86NvzGoV=T8rP+sP4Skz528H43Auz-_vf2CqEtnpA@mail.gmail.com>
	<CAJrcDBczBSKqs2p8gBjo1cOPi1z-gbv0Ue2cN63gZQAwawRmUQ@mail.gmail.com>
	<CABRXCmz_tn3=q6=SHvu5PxFZp0SwYDo=Ph8og=z17-kXywC+iQ@mail.gmail.com>
Message-ID: <CAJrcDBdi7pJjZD2PUnEb=7DW2LoTHJ0qzY6qP92NSCwDmAhbqQ@mail.gmail.com>

On Fri, Apr 13, 2018 at 10:18 AM, Bill Burke <bburke at redhat.com> wrote:

> I'm just brainstorming here and this probably should be under a different
> topic, but:
>
> I'm a bit concerned about putting all our eggs in the Istio basket.  The
> first concern is it might have to be C++, although the APIs I looked at
> were all Golang.  2nd the Golang APIs looked like they didn't have the
> concept of an HTTP session.
>

Team cloud is looking the client proxy and I think (someone correct me if I
wrong) we probably going to use it as a sidecar. So we won't have to worry
about C++ and Envoy.


>
> On Fri, Apr 13, 2018 at 8:23 AM, Pedro Igor Silva <psilva at redhat.com>
> wrote:
>
>> Yeah, I missed the meeting. But I have looked the slides and, yeah, we
>> are going to need our authz stuff there ....
>>
>> In fact, I hope to start working more with team-cloud team and see how we
>> can improve authorization experience for cloud native applications. The
>> proxy will be a great start as well how we can leverage Istio/sidecars to
>> enable authz.
>>
>> There is an open issue on for that proxy [1] around authorization using
>> Cabin. Feature wise we support the same thing but using a different model,
>> more integrated with Keycloak (of course) . Our use cases go beyond REST
>> security (which have improved a lot in Sprint 4) and also cover privacy,
>> with UMA.
>>
>> Hope I can get some tips from you about go when I start this :)
>>
>> [1] https://github.com/gambol99/keycloak-proxy
>>
>> On Thu, Apr 12, 2018 at 7:06 PM, Bill Burke <bburke at redhat.com> wrote:
>>
>>> How are your golang skills?   We're going to need all this stuff in the
>>> proxy :)  Don't know if you were in the meeting today...
>>>
>>> On Fri, Apr 6, 2018 at 11:37 AM, Pedro Igor Silva <psilva at redhat.com>
>>> wrote:
>>>
>>>> Yeah, it is. And the SPI provides that. That is only what we provide
>>>> OOTB so you don't need to implement boiler plate code. But yeah, you can
>>>> always use a hook to add whatever you want.
>>>>
>>>> FYI, some of these requirements (specially the OOTB config) was
>>>> gathered from a customer.
>>>>
>>>> On Fri, Apr 6, 2018 at 11:51 AM, Bill Burke <bburke at redhat.com> wrote:
>>>>
>>>>> Wouldn't a more generic hook be better.  One that allowed people to
>>>>> add whatever they wanted to the attributes being pushed?  Rather than
>>>>> having all this composition login within json?  Not saying I'm right and
>>>>> you are wrong, just wondering if it would be better?
>>>>>
>>>>> On Fri, Apr 6, 2018 at 7:26 AM, Pedro Igor Silva <psilva at redhat.com>
>>>>> wrote:
>>>>>
>>>>>> If you are using the API directly, yes, you don't need this SPI ...
>>>>>>
>>>>>> But when using our policy enforcer (embedded within our adapters)
>>>>>> developers don't actually use our API to call the permission endpoint. This
>>>>>> is done by the policy enforcer itself, internally. The SPI is mainly
>>>>>> targeted for applications using our adapters.
>>>>>>
>>>>>> The SPI serves for two purposes:
>>>>>>
>>>>>> 1) Allow developers to customize permission requests and push
>>>>>> arbitrary claims to the permission endpoint (extension point)
>>>>>> 2) Serve as the backbone for built-in "Claim Information Points",
>>>>>> provided by us OOTB.
>>>>>>
>>>>>> As an example, here is how a configuration should looks like:
>>>>>>
>>>>>> "claim-information-point": [
>>>>>>
>>>>>> ????"claims": {
>>>>>>
>>>>>> ????????"claim-a": "{request.parameter['abc']}"
>>>>>>
>>>>>> ???? },
>>>>>>
>>>>>>     "http-service": {
>>>>>>
>>>>>>         "url": "abc"
>>>>>>
>>>>>>     }
>>>>>>
>>>>>> ]
>>>>>>
>>>>>> "Claim Information Point" is pretty much the same thing as a Policy
>>>>>> Information Point. Each CIP Provider provides its own way to define claims
>>>>>> to a permission request. In the example above, you are "pushing" a
>>>>>> "claim-a" to your policies where the value would be a request parameter
>>>>>> "abc".
>>>>>>
>>>>>> Makes more sense now ?
>>>>>>
>>>>>>
>>>>>> On Fri, Apr 6, 2018 at 12:49 AM, Bill Burke <bburke at redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>>> I dont' understand...Why do you need an plugin SPI for this?
>>>>>>> Wouldn't
>>>>>>> the developer just call into your api to create the invocation to the
>>>>>>> permission endpoint?
>>>>>>>
>>>>>>> On Thu, Apr 5, 2018 at 10:41 AM, Pedro Igor Silva <psilva at redhat.com>
>>>>>>> wrote:
>>>>>>> > Hi,
>>>>>>> >
>>>>>>> > I'm currently working on https://issues.jboss.org/brows
>>>>>>> e/KEYCLOAK-4903.
>>>>>>> >
>>>>>>> > This is all about allowing applications to push arbitrary claims to
>>>>>>> > Keycloak prior to evaluating permissions on the server. A simple
>>>>>>> example to
>>>>>>> > illustrate the idea: a request arrives you extract what you want
>>>>>>> from there
>>>>>>> > (parameters, headers, etc) and "push" the information from the
>>>>>>> request as
>>>>>>> > claims in order to evaluate your permissions.
>>>>>>> >
>>>>>>> > There are endless possibilities on what you can push and how.
>>>>>>> >
>>>>>>> > >From a design perspective, I was thinking about providing a SPI
>>>>>>> on the
>>>>>>> > adapter side (as simple as using ServiceLoader) to load built-in
>>>>>>> and
>>>>>>> > user-defined "claim information points". Examples of built-in
>>>>>>> > implementations would be:
>>>>>>> >
>>>>>>> > * Extract parameters
>>>>>>> > * Extract headers
>>>>>>> > * Extract path parameters
>>>>>>> > * Extract cookies
>>>>>>> > * Invoke an external "policy information point"
>>>>>>> >
>>>>>>> > What do you think ?
>>>>>>> >
>>>>>>> > Regards.
>>>>>>> > Pedro Igor
>>>>>>> > _______________________________________________
>>>>>>> > keycloak-dev mailing list
>>>>>>> > keycloak-dev at lists.jboss.org
>>>>>>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Bill Burke
>>>>>>> Red Hat
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Bill Burke
>>>>> Red Hat
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Bill Burke
>>> Red Hat
>>>
>>
>>
>
>
> --
> Bill Burke
> Red Hat
>

From ssilvert at redhat.com  Mon Apr 16 10:06:30 2018
From: ssilvert at redhat.com (Stan Silvert)
Date: Mon, 16 Apr 2018 10:06:30 -0400
Subject: [keycloak-dev] ui_locales query parameter?
In-Reply-To: <CAJgngAeU_vro9weu5C_Rfx6Jc0Gu4M+a5yWE5VvQ0XCfGDZv5w@mail.gmail.com>
References: <9599201b-a4ef-d306-0c10-a244a89812c1@redhat.com>
	<CAJgngAeU_vro9weu5C_Rfx6Jc0Gu4M+a5yWE5VvQ0XCfGDZv5w@mail.gmail.com>
Message-ID: <b0531f7e-5e69-4044-5ca3-caf6f219f013@redhat.com>

OK.

Does anyone object to adding kc_locale to the login options on the 
keycloak.js adapter?


On 4/16/2018 2:45 AM, Stian Thorgersen wrote:
> It's a query param defined by OpenID Connect. See 
> http://openid.net/specs/openid-connect-core-1_0.html. It allows the 
> application to pass a list of req locales in case the application 
> knows it.
>
> When doing the redirect login flow the applications should use 
> ui_locales. kc_locale is an internal param and should really only be 
> used by the locale switcher on the login screen.
>
> On 16 April 2018 at 02:44, Stan Silvert <ssilvert at redhat.com 
> <mailto:ssilvert at redhat.com>> wrote:
>
>     Does anyone know what ui_locales is actually used for?
>
>     I can't find usages except for in the testsuite.
>
>     The query param used to change locale is kc_locale.? Should
>     ui_locales
>     deprecated?
>
>     Stan
>
>     _______________________________________________
>     keycloak-dev mailing list
>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>     <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>
>


From sthorger at redhat.com  Mon Apr 16 13:51:58 2018
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 16 Apr 2018 19:51:58 +0200
Subject: [keycloak-dev] ui_locales query parameter?
In-Reply-To: <b0531f7e-5e69-4044-5ca3-caf6f219f013@redhat.com>
References: <9599201b-a4ef-d306-0c10-a244a89812c1@redhat.com>
	<CAJgngAeU_vro9weu5C_Rfx6Jc0Gu4M+a5yWE5VvQ0XCfGDZv5w@mail.gmail.com>
	<b0531f7e-5e69-4044-5ca3-caf6f219f013@redhat.com>
Message-ID: <CAJgngAdM3FV_sWZ1_oDszLw+FmyAPQ0fJbq09tKeFugfe_nZkg@mail.gmail.com>

kc_locale is only aimed at internal use. You should use ui_locales that's
the publicly available param.

On 16 April 2018 at 16:06, Stan Silvert <ssilvert at redhat.com> wrote:

> OK.
>
> Does anyone object to adding kc_locale to the login options on the
> keycloak.js adapter?
>
>
>
> On 4/16/2018 2:45 AM, Stian Thorgersen wrote:
>
> It's a query param defined by OpenID Connect. See http://openid.net/specs/
> openid-connect-core-1_0.html. It allows the application to pass a list of
> req locales in case the application knows it.
>
> When doing the redirect login flow the applications should use ui_locales.
> kc_locale is an internal param and should really only be used by the locale
> switcher on the login screen.
>
> On 16 April 2018 at 02:44, Stan Silvert <ssilvert at redhat.com> wrote:
>
>> Does anyone know what ui_locales is actually used for?
>>
>> I can't find usages except for in the testsuite.
>>
>> The query param used to change locale is kc_locale.  Should ui_locales
>> deprecated?
>>
>> Stan
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
>

From sthorger at redhat.com  Tue Apr 17 06:35:06 2018
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 17 Apr 2018 12:35:06 +0200
Subject: [keycloak-dev] Reference users
Message-ID: <CAJgngAfKnOzN3E8+zZ6=SnFVfTjW9=vcKM82fwR+JUVS49Ei_g@mail.gmail.com>

We would like to gather some information on what companies are currently
using or are planning to use Keycloak in production.

We are also looking for public references.

If you are able to share your story please contact me off list.

From ssilvert at redhat.com  Tue Apr 17 09:00:21 2018
From: ssilvert at redhat.com (Stan Silvert)
Date: Tue, 17 Apr 2018 09:00:21 -0400
Subject: [keycloak-dev] ui_locales query parameter?
In-Reply-To: <CAJgngAdM3FV_sWZ1_oDszLw+FmyAPQ0fJbq09tKeFugfe_nZkg@mail.gmail.com>
References: <9599201b-a4ef-d306-0c10-a244a89812c1@redhat.com>
	<CAJgngAeU_vro9weu5C_Rfx6Jc0Gu4M+a5yWE5VvQ0XCfGDZv5w@mail.gmail.com>
	<b0531f7e-5e69-4044-5ca3-caf6f219f013@redhat.com>
	<CAJgngAdM3FV_sWZ1_oDszLw+FmyAPQ0fJbq09tKeFugfe_nZkg@mail.gmail.com>
Message-ID: <1a8d1f96-dee9-f9bf-ac1d-cc068d458a92@redhat.com>

On 4/16/2018 1:51 PM, Stian Thorgersen wrote:
> kc_locale is only aimed at internal use. You should use ui_locales 
> that's the publicly available param.
The problem is that I need the server-side logic associated with 
kc_locale.? kc_locale will update the cookie and update the UserModel.? 
ui_locales is just a pass-through back to the application.

So we can either add kc_locale as a login param in keycloak.js or we can 
add the server-side logic to ui_locales.? The simplest is to do the 
former.? But perhaps we should have been doing the latter all along?

>
> On 16 April 2018 at 16:06, Stan Silvert <ssilvert at redhat.com 
> <mailto:ssilvert at redhat.com>> wrote:
>
>     OK.
>
>     Does anyone object to adding kc_locale to the login options on the
>     keycloak.js adapter?
>
>
>
>     On 4/16/2018 2:45 AM, Stian Thorgersen wrote:
>>     It's a query param defined by OpenID Connect. See
>>     http://openid.net/specs/openid-connect-core-1_0.html
>>     <http://openid.net/specs/openid-connect-core-1_0.html>. It allows
>>     the application to pass a list of req locales in case the
>>     application knows it.
>>
>>     When doing the redirect login flow the applications should use
>>     ui_locales. kc_locale is an internal param and should really only
>>     be used by the locale switcher on the login screen.
>>
>>     On 16 April 2018 at 02:44, Stan Silvert <ssilvert at redhat.com
>>     <mailto:ssilvert at redhat.com>> wrote:
>>
>>         Does anyone know what ui_locales is actually used for?
>>
>>         I can't find usages except for in the testsuite.
>>
>>         The query param used to change locale is kc_locale.? Should
>>         ui_locales
>>         deprecated?
>>
>>         Stan
>>
>>         _______________________________________________
>>         keycloak-dev mailing list
>>         keycloak-dev at lists.jboss.org
>>         <mailto:keycloak-dev at lists.jboss.org>
>>         https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>         <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>
>>
>
>


From jcain at redhat.com  Tue Apr 17 09:57:12 2018
From: jcain at redhat.com (Josh Cain)
Date: Tue, 17 Apr 2018 08:57:12 -0500
Subject: [keycloak-dev] bug: how did javascript adapter ever work?
In-Reply-To: <CABRXCmxEG_JBJ9o=kUej6xer7BkmDqNTKJ+tgkocYNztDr8Bkg@mail.gmail.com>
References: <CABRXCmyJbK=nExp7A6KLuLJLiL7A-cnc_12GBh69p=+f4cQiPw@mail.gmail.com>
	<CABRXCmz6eYBqDVPvtPRni-0EPP1J-fvfMQJfA-0v3hkHtZ=fnw@mail.gmail.com>
	<CABRXCmxEG_JBJ9o=kUej6xer7BkmDqNTKJ+tgkocYNztDr8Bkg@mail.gmail.com>
Message-ID: <6e9498b2-03bb-6e63-2f83-219df986eaa7@redhat.com>

I was about to say... Red Hat customer portal and a number of other apps
we have are running the 7.2 version in production just fine.  Although,
it remains a fork until we can get #3271[0] in the upstream :(

[0] https://github.com/keycloak/keycloak/pull/3271

On 04/08/2018 08:16 PM, Bill Burke wrote:
> Sorry, nevermind...you have to add allowed origins to client or a "+"
> to add redirects.
> 
> On Sun, Apr 8, 2018 at 9:09 PM, Bill Burke <bburke at redhat.com> wrote:
>> Maybe its just a firefox thing?  The preflight sets the
>> ACCESS_CONTROL_ALLOW_ORIGIN, but I think firefox doesn't remember this
>> and expects the same header for the POST response to code to token.
>>
>> On Sun, Apr 8, 2018 at 9:04 PM, Bill Burke <bburke at redhat.com> wrote:
>>> Does our javascript adapter use code to token flow by default?  Is
>>> that the preferred mechanism?  I don't think anybody is using it and
>>> has never used it if so, because...its broken.
>>>
>>> I'm integrating with a non-keycloak html5 app that is using code to
>>> token and the code to token request is failing with a CORS error.
>>> This is because we do not set allowed origins in TokenEndpoint:
>>>
>>> https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/protocol/oidc/endpoints/TokenEndpoint.java#L416
>>>
>>> Embarrassing?  Or am i missing something?
>>>
>>> --
>>> Bill Burke
>>> Red Hat
>>
>>
>>
>> --
>> Bill Burke
>> Red Hat
> 
> 
> 


From mposolda at redhat.com  Tue Apr 17 09:59:08 2018
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 17 Apr 2018 15:59:08 +0200
Subject: [keycloak-dev] ui_locales query parameter?
In-Reply-To: <1a8d1f96-dee9-f9bf-ac1d-cc068d458a92@redhat.com>
References: <9599201b-a4ef-d306-0c10-a244a89812c1@redhat.com>
	<CAJgngAeU_vro9weu5C_Rfx6Jc0Gu4M+a5yWE5VvQ0XCfGDZv5w@mail.gmail.com>
	<b0531f7e-5e69-4044-5ca3-caf6f219f013@redhat.com>
	<CAJgngAdM3FV_sWZ1_oDszLw+FmyAPQ0fJbq09tKeFugfe_nZkg@mail.gmail.com>
	<1a8d1f96-dee9-f9bf-ac1d-cc068d458a92@redhat.com>
Message-ID: <05def24f-3d66-2798-ef14-c73b3949eb10@redhat.com>

On 17/04/18 15:00, Stan Silvert wrote:
> On 4/16/2018 1:51 PM, Stian Thorgersen wrote:
>> kc_locale is only aimed at internal use. You should use ui_locales
>> that's the publicly available param.
> The problem is that I need the server-side logic associated with
> kc_locale.? kc_locale will update the cookie and update the UserModel.
> ui_locales is just a pass-through back to the application.
>
> So we can either add kc_locale as a login param in keycloak.js or we can
> add the server-side logic to ui_locales.? The simplest is to do the
> former.? But perhaps we should have been doing the latter all along?
IMO the ui_locales parameter shouldn't update the UserModel. It's 
possible that there would be 2 different applications and both of them 
will send different values of ui_locales parameter. In that case, when 
user switch between application1 and application2 (on each SSO login), 
there will be update to UserModel, which is not good regarding 
performance IMO.

I can see in LocaleHelper.getUserLocale that the order about how the 
locale is resolved is:
1. kc_locale parameter
2. KEYCLOAK_LOCALE cookie
3. UserModel attribute
4. ui_locales query parameter
5. Accept-Language header

Is this order proper or not? AFAIK the first 3 items are used just if 
user explicitly selects the language on Keycloak login screen (or 
account mgmt screen). If we put ui_locales up, we will defacto give the 
control to application to override the localization, which user 
explicitly chosen on login screen. Do we want to do that? Is it good 
regarding usability? I think that not, but maybe I am wrong...

Marek

>
>> On 16 April 2018 at 16:06, Stan Silvert <ssilvert at redhat.com
>> <mailto:ssilvert at redhat.com>> wrote:
>>
>>      OK.
>>
>>      Does anyone object to adding kc_locale to the login options on the
>>      keycloak.js adapter?
>>
>>
>>
>>      On 4/16/2018 2:45 AM, Stian Thorgersen wrote:
>>>      It's a query param defined by OpenID Connect. See
>>>      http://openid.net/specs/openid-connect-core-1_0.html
>>>      <http://openid.net/specs/openid-connect-core-1_0.html>. It allows
>>>      the application to pass a list of req locales in case the
>>>      application knows it.
>>>
>>>      When doing the redirect login flow the applications should use
>>>      ui_locales. kc_locale is an internal param and should really only
>>>      be used by the locale switcher on the login screen.
>>>
>>>      On 16 April 2018 at 02:44, Stan Silvert <ssilvert at redhat.com
>>>      <mailto:ssilvert at redhat.com>> wrote:
>>>
>>>          Does anyone know what ui_locales is actually used for?
>>>
>>>          I can't find usages except for in the testsuite.
>>>
>>>          The query param used to change locale is kc_locale.? Should
>>>          ui_locales
>>>          deprecated?
>>>
>>>          Stan
>>>
>>>          _______________________________________________
>>>          keycloak-dev mailing list
>>>          keycloak-dev at lists.jboss.org
>>>          <mailto:keycloak-dev at lists.jboss.org>
>>>          https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>          <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>>
>>>
>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



From mposolda at redhat.com  Tue Apr 17 10:05:21 2018
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 17 Apr 2018 16:05:21 +0200
Subject: [keycloak-dev] ui_locales query parameter?
In-Reply-To: <05def24f-3d66-2798-ef14-c73b3949eb10@redhat.com>
References: <9599201b-a4ef-d306-0c10-a244a89812c1@redhat.com>
	<CAJgngAeU_vro9weu5C_Rfx6Jc0Gu4M+a5yWE5VvQ0XCfGDZv5w@mail.gmail.com>
	<b0531f7e-5e69-4044-5ca3-caf6f219f013@redhat.com>
	<CAJgngAdM3FV_sWZ1_oDszLw+FmyAPQ0fJbq09tKeFugfe_nZkg@mail.gmail.com>
	<1a8d1f96-dee9-f9bf-ac1d-cc068d458a92@redhat.com>
	<05def24f-3d66-2798-ef14-c73b3949eb10@redhat.com>
Message-ID: <2875a9a4-7904-3b59-2c69-d0e789502bb0@redhat.com>

On 17/04/18 15:59, Marek Posolda wrote:
> On 17/04/18 15:00, Stan Silvert wrote:
>> On 4/16/2018 1:51 PM, Stian Thorgersen wrote:
>>> kc_locale is only aimed at internal use. You should use ui_locales
>>> that's the publicly available param.
>> The problem is that I need the server-side logic associated with
>> kc_locale.? kc_locale will update the cookie and update the UserModel.
>> ui_locales is just a pass-through back to the application.
>>
>> So we can either add kc_locale as a login param in keycloak.js or we can
>> add the server-side logic to ui_locales.? The simplest is to do the
>> former.? But perhaps we should have been doing the latter all along?
> IMO the ui_locales parameter shouldn't update the UserModel. It's 
> possible that there would be 2 different applications and both of them 
> will send different values of ui_locales parameter. In that case, when 
> user switch between application1 and application2 (on each SSO login), 
> there will be update to UserModel, which is not good regarding 
> performance IMO.
>
> I can see in LocaleHelper.getUserLocale that the order about how the 
> locale is resolved is:
> 1. kc_locale parameter
> 2. KEYCLOAK_LOCALE cookie
> 3. UserModel attribute
> 4. ui_locales query parameter
> 5. Accept-Language header
>
> Is this order proper or not? AFAIK the first 3 items are used just if 
> user explicitly selects the language on Keycloak login screen (or 
> account mgmt screen). If we put ui_locales up, we will defacto give 
> the control to application to override the localization, which user 
> explicitly chosen on login screen. Do we want to do that? Is it good 
> regarding usability? I think that not, but maybe I am wrong...
I noticed one more thing, that LocaleHelper is reading just the 
ui_locales parameter. This is not good as the ui_locales parameter is 
available just in very 1st request sent to the login screen, but not in 
subsequent requests. So for example I think that current flow is like this:
- Application sent parameter "ui_locales=cs"
- Login page is displayed in czech language (assuming user did not 
explicitly set locale before and hence his userModel doesn't have filled 
locale). This is correct behaviour
- User filled username/password. Now the TOTP page (or any 
requiredActions page for example) is shown. But it is shown in default 
locale as ui_locales query parameter is not available anymore. It is 
just in very 1st request to login screen. This is not correct behaviour 
IMO. The locale "cs" should be used for the rest of whole login session.

Am I correct that this workflow is broken?

If yes, the solution might be to add locale as the note to 
AuthenticationSessionModel . And then use the note from 
AuthenticationSessionModel in LocaleHelper instead of ui_locales query 
parameter.

Marek
>
> Marek
>
>>
>>> On 16 April 2018 at 16:06, Stan Silvert <ssilvert at redhat.com
>>> <mailto:ssilvert at redhat.com>> wrote:
>>>
>>> ???? OK.
>>>
>>> ???? Does anyone object to adding kc_locale to the login options on the
>>> ???? keycloak.js adapter?
>>>
>>>
>>>
>>> ???? On 4/16/2018 2:45 AM, Stian Thorgersen wrote:
>>>> ???? It's a query param defined by OpenID Connect. See
>>>> ???? http://openid.net/specs/openid-connect-core-1_0.html
>>>> <http://openid.net/specs/openid-connect-core-1_0.html>. It allows
>>>> ???? the application to pass a list of req locales in case the
>>>> ???? application knows it.
>>>>
>>>> ???? When doing the redirect login flow the applications should use
>>>> ???? ui_locales. kc_locale is an internal param and should really only
>>>> ???? be used by the locale switcher on the login screen.
>>>>
>>>> ???? On 16 April 2018 at 02:44, Stan Silvert <ssilvert at redhat.com
>>>> ???? <mailto:ssilvert at redhat.com>> wrote:
>>>>
>>>> ???????? Does anyone know what ui_locales is actually used for?
>>>>
>>>> ???????? I can't find usages except for in the testsuite.
>>>>
>>>> ???????? The query param used to change locale is kc_locale.? Should
>>>> ???????? ui_locales
>>>> ???????? deprecated?
>>>>
>>>> ???????? Stan
>>>>
>>>> ???????? _______________________________________________
>>>> ???????? keycloak-dev mailing list
>>>> ???????? keycloak-dev at lists.jboss.org
>>>> ???????? <mailto:keycloak-dev at lists.jboss.org>
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>> <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>>>
>>>>
>>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>


From ssilvert at redhat.com  Tue Apr 17 11:32:23 2018
From: ssilvert at redhat.com (Stan Silvert)
Date: Tue, 17 Apr 2018 11:32:23 -0400
Subject: [keycloak-dev] ui_locales query parameter?
In-Reply-To: <2875a9a4-7904-3b59-2c69-d0e789502bb0@redhat.com>
References: <9599201b-a4ef-d306-0c10-a244a89812c1@redhat.com>
	<CAJgngAeU_vro9weu5C_Rfx6Jc0Gu4M+a5yWE5VvQ0XCfGDZv5w@mail.gmail.com>
	<b0531f7e-5e69-4044-5ca3-caf6f219f013@redhat.com>
	<CAJgngAdM3FV_sWZ1_oDszLw+FmyAPQ0fJbq09tKeFugfe_nZkg@mail.gmail.com>
	<1a8d1f96-dee9-f9bf-ac1d-cc068d458a92@redhat.com>
	<05def24f-3d66-2798-ef14-c73b3949eb10@redhat.com>
	<2875a9a4-7904-3b59-2c69-d0e789502bb0@redhat.com>
Message-ID: <c96ce185-fd62-0ad3-1c40-1c9604599d53@redhat.com>

On 4/17/2018 10:05 AM, Marek Posolda wrote:
> On 17/04/18 15:59, Marek Posolda wrote:
>> On 17/04/18 15:00, Stan Silvert wrote:
>>> On 4/16/2018 1:51 PM, Stian Thorgersen wrote:
>>>> kc_locale is only aimed at internal use. You should use ui_locales
>>>> that's the publicly available param.
>>> The problem is that I need the server-side logic associated with
>>> kc_locale.? kc_locale will update the cookie and update the UserModel.
>>> ui_locales is just a pass-through back to the application.
>>>
>>> So we can either add kc_locale as a login param in keycloak.js or we 
>>> can
>>> add the server-side logic to ui_locales.? The simplest is to do the
>>> former.? But perhaps we should have been doing the latter all along?
>> IMO the ui_locales parameter shouldn't update the UserModel. It's 
>> possible that there would be 2 different applications and both of 
>> them will send different values of ui_locales parameter. In that 
>> case, when user switch between application1 and application2 (on each 
>> SSO login), there will be update to UserModel, which is not good 
>> regarding performance IMO.
>>
>> I can see in LocaleHelper.getUserLocale that the order about how the 
>> locale is resolved is:
>> 1. kc_locale parameter
>> 2. KEYCLOAK_LOCALE cookie
>> 3. UserModel attribute
>> 4. ui_locales query parameter
>> 5. Accept-Language header
>>
>> Is this order proper or not? AFAIK the first 3 items are used just if 
>> user explicitly selects the language on Keycloak login screen (or 
>> account mgmt screen). If we put ui_locales up, we will defacto give 
>> the control to application to override the localization, which user 
>> explicitly chosen on login screen. Do we want to do that? Is it good 
>> regarding usability? I think that not, but maybe I am wrong...
> I noticed one more thing, that LocaleHelper is reading just the 
> ui_locales parameter. This is not good as the ui_locales parameter is 
> available just in very 1st request sent to the login screen, but not 
> in subsequent requests. So for example I think that current flow is 
> like this:
> - Application sent parameter "ui_locales=cs"
> - Login page is displayed in czech language (assuming user did not 
> explicitly set locale before and hence his userModel doesn't have 
> filled locale). This is correct behaviour
> - User filled username/password. Now the TOTP page (or any 
> requiredActions page for example) is shown. But it is shown in default 
> locale as ui_locales query parameter is not available anymore. It is 
> just in very 1st request to login screen. This is not correct 
> behaviour IMO. The locale "cs" should be used for the rest of whole 
> login session.
>
> Am I correct that this workflow is broken?
>
> If yes, the solution might be to add locale as the note to 
> AuthenticationSessionModel . And then use the note from 
> AuthenticationSessionModel in LocaleHelper instead of ui_locales query 
> parameter.
>
> Marek
Here is what the spec says:

Preferred Locales
    OPs MUST support requests for preferred languages and scripts for
    the user interface and for Claims via the ui_locales and
    claims_locales request parameters, as defined in Section?3.1.2
    <http://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint>.
    (Note that the minimum level of support required for these
    parameters is simply to have their use not result in errors.) 

I think you are correct that Keycloak doesn't actually do anything with 
the ui_locales param except to possibly use it as the Locale for that 
one request.? We don't throw an error, so I guess we meet the minimum 
level of support?

It looks like kc_locale does what ui_locales was intended for. But the 
spec does not tell us exactly what the IDP must do when it sees ui_locales.

>>
>> Marek
>>
>>>
>>>> On 16 April 2018 at 16:06, Stan Silvert <ssilvert at redhat.com
>>>> <mailto:ssilvert at redhat.com>> wrote:
>>>>
>>>> ???? OK.
>>>>
>>>> ???? Does anyone object to adding kc_locale to the login options on 
>>>> the
>>>> ???? keycloak.js adapter?
>>>>
>>>>
>>>>
>>>> ???? On 4/16/2018 2:45 AM, Stian Thorgersen wrote:
>>>>> ???? It's a query param defined by OpenID Connect. See
>>>>> ???? http://openid.net/specs/openid-connect-core-1_0.html
>>>>> <http://openid.net/specs/openid-connect-core-1_0.html>. It allows
>>>>> ???? the application to pass a list of req locales in case the
>>>>> ???? application knows it.
>>>>>
>>>>> ???? When doing the redirect login flow the applications should use
>>>>> ???? ui_locales. kc_locale is an internal param and should really 
>>>>> only
>>>>> ???? be used by the locale switcher on the login screen.
>>>>>
>>>>> ???? On 16 April 2018 at 02:44, Stan Silvert <ssilvert at redhat.com
>>>>> ???? <mailto:ssilvert at redhat.com>> wrote:
>>>>>
>>>>> ???????? Does anyone know what ui_locales is actually used for?
>>>>>
>>>>> ???????? I can't find usages except for in the testsuite.
>>>>>
>>>>> ???????? The query param used to change locale is kc_locale.? Should
>>>>> ???????? ui_locales
>>>>> ???????? deprecated?
>>>>>
>>>>> ???????? Stan
>>>>>
>>>>> ???????? _______________________________________________
>>>>> ???????? keycloak-dev mailing list
>>>>> ???????? keycloak-dev at lists.jboss.org
>>>>> ???????? <mailto:keycloak-dev at lists.jboss.org>
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>> <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>>>>
>>>>>
>>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>


From ssilvert at redhat.com  Tue Apr 17 11:37:27 2018
From: ssilvert at redhat.com (Stan Silvert)
Date: Tue, 17 Apr 2018 11:37:27 -0400
Subject: [keycloak-dev] ui_locales query parameter?
In-Reply-To: <2875a9a4-7904-3b59-2c69-d0e789502bb0@redhat.com>
References: <9599201b-a4ef-d306-0c10-a244a89812c1@redhat.com>
	<CAJgngAeU_vro9weu5C_Rfx6Jc0Gu4M+a5yWE5VvQ0XCfGDZv5w@mail.gmail.com>
	<b0531f7e-5e69-4044-5ca3-caf6f219f013@redhat.com>
	<CAJgngAdM3FV_sWZ1_oDszLw+FmyAPQ0fJbq09tKeFugfe_nZkg@mail.gmail.com>
	<1a8d1f96-dee9-f9bf-ac1d-cc068d458a92@redhat.com>
	<05def24f-3d66-2798-ef14-c73b3949eb10@redhat.com>
	<2875a9a4-7904-3b59-2c69-d0e789502bb0@redhat.com>
Message-ID: <b8b03214-5608-2168-839c-c0cdd5327b4a@redhat.com>

The bottom line for the account management console is that we need a way 
to change the locale AFTER login.

In order to do this and make it "sticky", we need to do a request to the 
server, which:

  * Sets the cookie
  * Sets the UserModel
  * Reloads the page

I have found that merely setting kc_locale on a login() request meets 
this criteria perfectly.? That's why I'm asking if anyone objects to 
adding kc_locale to the LoginOptions in keycloak.js.

On 4/17/2018 10:05 AM, Marek Posolda wrote:
> On 17/04/18 15:59, Marek Posolda wrote:
>> On 17/04/18 15:00, Stan Silvert wrote:
>>> On 4/16/2018 1:51 PM, Stian Thorgersen wrote:
>>>> kc_locale is only aimed at internal use. You should use ui_locales
>>>> that's the publicly available param.
>>> The problem is that I need the server-side logic associated with
>>> kc_locale.? kc_locale will update the cookie and update the UserModel.
>>> ui_locales is just a pass-through back to the application.
>>>
>>> So we can either add kc_locale as a login param in keycloak.js or we 
>>> can
>>> add the server-side logic to ui_locales.? The simplest is to do the
>>> former.? But perhaps we should have been doing the latter all along?
>> IMO the ui_locales parameter shouldn't update the UserModel. It's 
>> possible that there would be 2 different applications and both of 
>> them will send different values of ui_locales parameter. In that 
>> case, when user switch between application1 and application2 (on each 
>> SSO login), there will be update to UserModel, which is not good 
>> regarding performance IMO.
>>
>> I can see in LocaleHelper.getUserLocale that the order about how the 
>> locale is resolved is:
>> 1. kc_locale parameter
>> 2. KEYCLOAK_LOCALE cookie
>> 3. UserModel attribute
>> 4. ui_locales query parameter
>> 5. Accept-Language header
>>
>> Is this order proper or not? AFAIK the first 3 items are used just if 
>> user explicitly selects the language on Keycloak login screen (or 
>> account mgmt screen). If we put ui_locales up, we will defacto give 
>> the control to application to override the localization, which user 
>> explicitly chosen on login screen. Do we want to do that? Is it good 
>> regarding usability? I think that not, but maybe I am wrong...
> I noticed one more thing, that LocaleHelper is reading just the 
> ui_locales parameter. This is not good as the ui_locales parameter is 
> available just in very 1st request sent to the login screen, but not 
> in subsequent requests. So for example I think that current flow is 
> like this:
> - Application sent parameter "ui_locales=cs"
> - Login page is displayed in czech language (assuming user did not 
> explicitly set locale before and hence his userModel doesn't have 
> filled locale). This is correct behaviour
> - User filled username/password. Now the TOTP page (or any 
> requiredActions page for example) is shown. But it is shown in default 
> locale as ui_locales query parameter is not available anymore. It is 
> just in very 1st request to login screen. This is not correct 
> behaviour IMO. The locale "cs" should be used for the rest of whole 
> login session.
>
> Am I correct that this workflow is broken?
>
> If yes, the solution might be to add locale as the note to 
> AuthenticationSessionModel . And then use the note from 
> AuthenticationSessionModel in LocaleHelper instead of ui_locales query 
> parameter.
>
> Marek
>>
>> Marek
>>
>>>
>>>> On 16 April 2018 at 16:06, Stan Silvert <ssilvert at redhat.com
>>>> <mailto:ssilvert at redhat.com>> wrote:
>>>>
>>>> ???? OK.
>>>>
>>>> ???? Does anyone object to adding kc_locale to the login options on 
>>>> the
>>>> ???? keycloak.js adapter?
>>>>
>>>>
>>>>
>>>> ???? On 4/16/2018 2:45 AM, Stian Thorgersen wrote:
>>>>> ???? It's a query param defined by OpenID Connect. See
>>>>> ???? http://openid.net/specs/openid-connect-core-1_0.html
>>>>> <http://openid.net/specs/openid-connect-core-1_0.html>. It allows
>>>>> ???? the application to pass a list of req locales in case the
>>>>> ???? application knows it.
>>>>>
>>>>> ???? When doing the redirect login flow the applications should use
>>>>> ???? ui_locales. kc_locale is an internal param and should really 
>>>>> only
>>>>> ???? be used by the locale switcher on the login screen.
>>>>>
>>>>> ???? On 16 April 2018 at 02:44, Stan Silvert <ssilvert at redhat.com
>>>>> ???? <mailto:ssilvert at redhat.com>> wrote:
>>>>>
>>>>> ???????? Does anyone know what ui_locales is actually used for?
>>>>>
>>>>> ???????? I can't find usages except for in the testsuite.
>>>>>
>>>>> ???????? The query param used to change locale is kc_locale.? Should
>>>>> ???????? ui_locales
>>>>> ???????? deprecated?
>>>>>
>>>>> ???????? Stan
>>>>>
>>>>> ???????? _______________________________________________
>>>>> ???????? keycloak-dev mailing list
>>>>> ???????? keycloak-dev at lists.jboss.org
>>>>> ???????? <mailto:keycloak-dev at lists.jboss.org>
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>> <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>>>>
>>>>>
>>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>


From sthorger at redhat.com  Tue Apr 17 13:59:27 2018
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 17 Apr 2018 19:59:27 +0200
Subject: [keycloak-dev] ui_locales query parameter?
In-Reply-To: <05def24f-3d66-2798-ef14-c73b3949eb10@redhat.com>
References: <9599201b-a4ef-d306-0c10-a244a89812c1@redhat.com>
	<CAJgngAeU_vro9weu5C_Rfx6Jc0Gu4M+a5yWE5VvQ0XCfGDZv5w@mail.gmail.com>
	<b0531f7e-5e69-4044-5ca3-caf6f219f013@redhat.com>
	<CAJgngAdM3FV_sWZ1_oDszLw+FmyAPQ0fJbq09tKeFugfe_nZkg@mail.gmail.com>
	<1a8d1f96-dee9-f9bf-ac1d-cc068d458a92@redhat.com>
	<05def24f-3d66-2798-ef14-c73b3949eb10@redhat.com>
Message-ID: <CAJgngAfgCwoLm7f1BeWxTyrEr55VspssinNnRQ6DnCFMs9_JZA@mail.gmail.com>

For the account management console I think the correct approach is the
following:

* Add an endpoint to account management service to allow setting the user
locale which the account management should call - it should not re-direct
to login back and do the whole login dance
* Change the way the account management console loads the messages - it
should load using a rest endpoint, not by injecting into the index.ftl.
That allows re-loading messages if the locale is changed without having to
do the login dance



On 17 April 2018 at 15:59, Marek Posolda <mposolda at redhat.com> wrote:

> On 17/04/18 15:00, Stan Silvert wrote:
>
>> On 4/16/2018 1:51 PM, Stian Thorgersen wrote:
>>
>>> kc_locale is only aimed at internal use. You should use ui_locales
>>> that's the publicly available param.
>>>
>> The problem is that I need the server-side logic associated with
>> kc_locale.  kc_locale will update the cookie and update the UserModel.
>> ui_locales is just a pass-through back to the application.
>>
>> So we can either add kc_locale as a login param in keycloak.js or we can
>> add the server-side logic to ui_locales.  The simplest is to do the
>> former.  But perhaps we should have been doing the latter all along?
>>
> IMO the ui_locales parameter shouldn't update the UserModel. It's possible
> that there would be 2 different applications and both of them will send
> different values of ui_locales parameter. In that case, when user switch
> between application1 and application2 (on each SSO login), there will be
> update to UserModel, which is not good regarding performance IMO.
>
> I can see in LocaleHelper.getUserLocale that the order about how the
> locale is resolved is:
> 1. kc_locale parameter
> 2. KEYCLOAK_LOCALE cookie
> 3. UserModel attribute
> 4. ui_locales query parameter
> 5. Accept-Language header
>
> Is this order proper or not? AFAIK the first 3 items are used just if user
> explicitly selects the language on Keycloak login screen (or account mgmt
> screen). If we put ui_locales up, we will defacto give the control to
> application to override the localization, which user explicitly chosen on
> login screen. Do we want to do that? Is it good regarding usability? I
> think that not, but maybe I am wrong...
>

I think the current order is correct.

1. Change locale if user has explicitly made the change - kc_locale should
only be set when the user changes it manually through login pages
2-3 Tries to figure out the users last pick
4. Provided by the application as a hint for what locale the user may want.
It should not override the users explicitly set locale
5. Accept-Language is supposed to give the users preferred locale. However,
this is often wrong and just defaults to en. Hence why it comes last.

There's been quite a lot of discussion to get this right in the past, so
I'm quite confident that the current logic works and it has been confirmed
by a surprising amount of folks. Well it was tweaked quite a few times
based on user feedback.


>
> Marek
>
>
>> On 16 April 2018 at 16:06, Stan Silvert <ssilvert at redhat.com
>>> <mailto:ssilvert at redhat.com>> wrote:
>>>
>>>      OK.
>>>
>>>      Does anyone object to adding kc_locale to the login options on the
>>>      keycloak.js adapter?
>>>
>>>
>>>
>>>      On 4/16/2018 2:45 AM, Stian Thorgersen wrote:
>>>
>>>>      It's a query param defined by OpenID Connect. See
>>>>      http://openid.net/specs/openid-connect-core-1_0.html
>>>>      <http://openid.net/specs/openid-connect-core-1_0.html>. It allows
>>>>      the application to pass a list of req locales in case the
>>>>      application knows it.
>>>>
>>>>      When doing the redirect login flow the applications should use
>>>>      ui_locales. kc_locale is an internal param and should really only
>>>>      be used by the locale switcher on the login screen.
>>>>
>>>>      On 16 April 2018 at 02:44, Stan Silvert <ssilvert at redhat.com
>>>>      <mailto:ssilvert at redhat.com>> wrote:
>>>>
>>>>          Does anyone know what ui_locales is actually used for?
>>>>
>>>>          I can't find usages except for in the testsuite.
>>>>
>>>>          The query param used to change locale is kc_locale.  Should
>>>>          ui_locales
>>>>          deprecated?
>>>>
>>>>          Stan
>>>>
>>>>          _______________________________________________
>>>>          keycloak-dev mailing list
>>>>          keycloak-dev at lists.jboss.org
>>>>          <mailto:keycloak-dev at lists.jboss.org>
>>>>          https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>          <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>>>
>>>>
>>>>
>>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
>

From ssilvert at redhat.com  Tue Apr 17 15:07:14 2018
From: ssilvert at redhat.com (Stan Silvert)
Date: Tue, 17 Apr 2018 15:07:14 -0400
Subject: [keycloak-dev] ui_locales query parameter?
In-Reply-To: <CAJgngAfgCwoLm7f1BeWxTyrEr55VspssinNnRQ6DnCFMs9_JZA@mail.gmail.com>
References: <9599201b-a4ef-d306-0c10-a244a89812c1@redhat.com>
	<CAJgngAeU_vro9weu5C_Rfx6Jc0Gu4M+a5yWE5VvQ0XCfGDZv5w@mail.gmail.com>
	<b0531f7e-5e69-4044-5ca3-caf6f219f013@redhat.com>
	<CAJgngAdM3FV_sWZ1_oDszLw+FmyAPQ0fJbq09tKeFugfe_nZkg@mail.gmail.com>
	<1a8d1f96-dee9-f9bf-ac1d-cc068d458a92@redhat.com>
	<05def24f-3d66-2798-ef14-c73b3949eb10@redhat.com>
	<CAJgngAfgCwoLm7f1BeWxTyrEr55VspssinNnRQ6DnCFMs9_JZA@mail.gmail.com>
Message-ID: <0d704542-de4d-a07f-3b42-deaa8b22633b@redhat.com>

On 4/17/2018 1:59 PM, Stian Thorgersen wrote:
> For the account management console I think the correct approach is the 
> following:
>
> * Add an endpoint to account management service to allow setting the 
> user locale which the account management should call - it should not 
> re-direct to login back and do the whole login dance
> * Change the way the account management console loads the messages - 
> it should load using a rest endpoint, not by injecting into the 
> index.ftl. That allows re-loading messages if the locale is changed 
> without having to do the login dance
What is it about the "login dance" that causes a problem?? It seems to 
do exactly what I need it to do, as long as I can pass in kc_locale.

>
>
>
> On 17 April 2018 at 15:59, Marek Posolda <mposolda at redhat.com 
> <mailto:mposolda at redhat.com>> wrote:
>
>     On 17/04/18 15:00, Stan Silvert wrote:
>
>         On 4/16/2018 1:51 PM, Stian Thorgersen wrote:
>
>             kc_locale is only aimed at internal use. You should use
>             ui_locales
>             that's the publicly available param.
>
>         The problem is that I need the server-side logic associated with
>         kc_locale.? kc_locale will update the cookie and update the
>         UserModel.
>         ui_locales is just a pass-through back to the application.
>
>         So we can either add kc_locale as a login param in keycloak.js
>         or we can
>         add the server-side logic to ui_locales.? The simplest is to
>         do the
>         former.? But perhaps we should have been doing the latter all
>         along?
>
>     IMO the ui_locales parameter shouldn't update the UserModel. It's
>     possible that there would be 2 different applications and both of
>     them will send different values of ui_locales parameter. In that
>     case, when user switch between application1 and application2 (on
>     each SSO login), there will be update to UserModel, which is not
>     good regarding performance IMO.
>
>     I can see in LocaleHelper.getUserLocale that the order about how
>     the locale is resolved is:
>     1. kc_locale parameter
>     2. KEYCLOAK_LOCALE cookie
>     3. UserModel attribute
>     4. ui_locales query parameter
>     5. Accept-Language header
>
>     Is this order proper or not? AFAIK the first 3 items are used just
>     if user explicitly selects the language on Keycloak login screen
>     (or account mgmt screen). If we put ui_locales up, we will defacto
>     give the control to application to override the localization,
>     which user explicitly chosen on login screen. Do we want to do
>     that? Is it good regarding usability? I think that not, but maybe
>     I am wrong...
>
>
> I think the current order is correct.
>
> 1. Change locale if user has explicitly made the change - kc_locale 
> should only be set when the user changes it manually through login pages
> 2-3 Tries to figure out the users last pick
> 4. Provided by the application as a hint for what locale the user may 
> want. It should not override the users explicitly set locale
> 5. Accept-Language is supposed to give the users preferred locale. 
> However, this is often wrong and just defaults to en. Hence why it 
> comes last.
>
> There's been quite a lot of discussion to get this right in the past, 
> so I'm quite confident that the current logic works and it has been 
> confirmed by a surprising amount of folks. Well it was tweaked quite a 
> few times based on user feedback.
>
>
>     Marek
>
>
>             On 16 April 2018 at 16:06, Stan Silvert
>             <ssilvert at redhat.com <mailto:ssilvert at redhat.com>
>             <mailto:ssilvert at redhat.com <mailto:ssilvert at redhat.com>>>
>             wrote:
>
>             ? ? ?OK.
>
>             ? ? ?Does anyone object to adding kc_locale to the login
>             options on the
>             ? ? ?keycloak.js adapter?
>
>
>
>             ? ? ?On 4/16/2018 2:45 AM, Stian Thorgersen wrote:
>
>                 ? ? ?It's a query param defined by OpenID Connect. See
>                 http://openid.net/specs/openid-connect-core-1_0.html
>                 <http://openid.net/specs/openid-connect-core-1_0.html>
>                 ? ?
>                 ?<http://openid.net/specs/openid-connect-core-1_0.html
>                 <http://openid.net/specs/openid-connect-core-1_0.html>>.
>                 It allows
>                 ? ? ?the application to pass a list of req locales in
>                 case the
>                 ? ? ?application knows it.
>
>                 ? ? ?When doing the redirect login flow the
>                 applications should use
>                 ? ? ?ui_locales. kc_locale is an internal param and
>                 should really only
>                 ? ? ?be used by the locale switcher on the login screen.
>
>                 ? ? ?On 16 April 2018 at 02:44, Stan Silvert
>                 <ssilvert at redhat.com <mailto:ssilvert at redhat.com>
>                 ? ? ?<mailto:ssilvert at redhat.com
>                 <mailto:ssilvert at redhat.com>>> wrote:
>
>                 ? ? ? ? ?Does anyone know what ui_locales is actually
>                 used for?
>
>                 ? ? ? ? ?I can't find usages except for in the testsuite.
>
>                 ? ? ? ? ?The query param used to change locale is
>                 kc_locale.? Should
>                 ? ? ? ? ?ui_locales
>                 ? ? ? ? ?deprecated?
>
>                 ? ? ? ? ?Stan
>
>                 ? ? ? ? ?_______________________________________________
>                 ? ? ? ? ?keycloak-dev mailing list
>                 keycloak-dev at lists.jboss.org
>                 <mailto:keycloak-dev at lists.jboss.org>
>                 ? ? ? ? ?<mailto:keycloak-dev at lists.jboss.org
>                 <mailto:keycloak-dev at lists.jboss.org>>
>                 https://lists.jboss.org/mailman/listinfo/keycloak-dev
>                 <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>                 ? ? ? ?
>                 ?<https://lists.jboss.org/mailman/listinfo/keycloak-dev
>                 <https://lists.jboss.org/mailman/listinfo/keycloak-dev>>
>
>
>
>         _______________________________________________
>         keycloak-dev mailing list
>         keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>         https://lists.jboss.org/mailman/listinfo/keycloak-dev
>         <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>
>
>
>


From ssilvert at redhat.com  Tue Apr 17 19:17:05 2018
From: ssilvert at redhat.com (Stan Silvert)
Date: Tue, 17 Apr 2018 19:17:05 -0400
Subject: [keycloak-dev] ui_locales query parameter?
In-Reply-To: <0d704542-de4d-a07f-3b42-deaa8b22633b@redhat.com>
References: <9599201b-a4ef-d306-0c10-a244a89812c1@redhat.com>
	<CAJgngAeU_vro9weu5C_Rfx6Jc0Gu4M+a5yWE5VvQ0XCfGDZv5w@mail.gmail.com>
	<b0531f7e-5e69-4044-5ca3-caf6f219f013@redhat.com>
	<CAJgngAdM3FV_sWZ1_oDszLw+FmyAPQ0fJbq09tKeFugfe_nZkg@mail.gmail.com>
	<1a8d1f96-dee9-f9bf-ac1d-cc068d458a92@redhat.com>
	<05def24f-3d66-2798-ef14-c73b3949eb10@redhat.com>
	<CAJgngAfgCwoLm7f1BeWxTyrEr55VspssinNnRQ6DnCFMs9_JZA@mail.gmail.com>
	<0d704542-de4d-a07f-3b42-deaa8b22633b@redhat.com>
Message-ID: <85f9a6da-023e-bc72-8897-35254dcfce25@redhat.com>

On 4/17/2018 3:07 PM, Stan Silvert wrote:
> On 4/17/2018 1:59 PM, Stian Thorgersen wrote:
>> For the account management console I think the correct approach is the
>> following:
>>
>> * Add an endpoint to account management service to allow setting the
>> user locale which the account management should call - it should not
>> re-direct to login back and do the whole login dance
>> * Change the way the account management console loads the messages -
>> it should load using a rest endpoint, not by injecting into the
>> index.ftl. That allows re-loading messages if the locale is changed
>> without having to do the login dance
> What is it about the "login dance" that causes a problem?? It seems to
> do exactly what I need it to do, as long as I can pass in kc_locale.
I was thinking that I actually need the redirect in order to 
re-initialize the welcome screen's localized text.? The welcome screen 
uses FreeMarker for localization.? But you can't get back to the welcome 
screen without logging out, so logout's redirect would take care of the 
re-initialization of the welcome screen. Therefore, adding an endpoint 
and reloading the messages in Angular would work.

A new endpoint for this would:
* Set the cookie to the new locale
* Set the UserModel to the new locale
* Return the localized message bundle

Then I would have to refactor all the language handling on the Angular 
side.? It would all just take a bit of time to implement. But if you 
really think it has to be done that way we can do it.

>
>>
>>
>> On 17 April 2018 at 15:59, Marek Posolda <mposolda at redhat.com
>> <mailto:mposolda at redhat.com>> wrote:
>>
>>      On 17/04/18 15:00, Stan Silvert wrote:
>>
>>          On 4/16/2018 1:51 PM, Stian Thorgersen wrote:
>>
>>              kc_locale is only aimed at internal use. You should use
>>              ui_locales
>>              that's the publicly available param.
>>
>>          The problem is that I need the server-side logic associated with
>>          kc_locale.? kc_locale will update the cookie and update the
>>          UserModel.
>>          ui_locales is just a pass-through back to the application.
>>
>>          So we can either add kc_locale as a login param in keycloak.js
>>          or we can
>>          add the server-side logic to ui_locales.? The simplest is to
>>          do the
>>          former.? But perhaps we should have been doing the latter all
>>          along?
>>
>>      IMO the ui_locales parameter shouldn't update the UserModel. It's
>>      possible that there would be 2 different applications and both of
>>      them will send different values of ui_locales parameter. In that
>>      case, when user switch between application1 and application2 (on
>>      each SSO login), there will be update to UserModel, which is not
>>      good regarding performance IMO.
>>
>>      I can see in LocaleHelper.getUserLocale that the order about how
>>      the locale is resolved is:
>>      1. kc_locale parameter
>>      2. KEYCLOAK_LOCALE cookie
>>      3. UserModel attribute
>>      4. ui_locales query parameter
>>      5. Accept-Language header
>>
>>      Is this order proper or not? AFAIK the first 3 items are used just
>>      if user explicitly selects the language on Keycloak login screen
>>      (or account mgmt screen). If we put ui_locales up, we will defacto
>>      give the control to application to override the localization,
>>      which user explicitly chosen on login screen. Do we want to do
>>      that? Is it good regarding usability? I think that not, but maybe
>>      I am wrong...
>>
>>
>> I think the current order is correct.
>>
>> 1. Change locale if user has explicitly made the change - kc_locale
>> should only be set when the user changes it manually through login pages
>> 2-3 Tries to figure out the users last pick
>> 4. Provided by the application as a hint for what locale the user may
>> want. It should not override the users explicitly set locale
>> 5. Accept-Language is supposed to give the users preferred locale.
>> However, this is often wrong and just defaults to en. Hence why it
>> comes last.
>>
>> There's been quite a lot of discussion to get this right in the past,
>> so I'm quite confident that the current logic works and it has been
>> confirmed by a surprising amount of folks. Well it was tweaked quite a
>> few times based on user feedback.
>>
>>
>>      Marek
>>
>>
>>              On 16 April 2018 at 16:06, Stan Silvert
>>              <ssilvert at redhat.com <mailto:ssilvert at redhat.com>
>>              <mailto:ssilvert at redhat.com <mailto:ssilvert at redhat.com>>>
>>              wrote:
>>
>>              ? ? ?OK.
>>
>>              ? ? ?Does anyone object to adding kc_locale to the login
>>              options on the
>>              ? ? ?keycloak.js adapter?
>>
>>
>>
>>              ? ? ?On 4/16/2018 2:45 AM, Stian Thorgersen wrote:
>>
>>                  ? ? ?It's a query param defined by OpenID Connect. See
>>                  http://openid.net/specs/openid-connect-core-1_0.html
>>                  <http://openid.net/specs/openid-connect-core-1_0.html>
>>                     
>>                  ?<http://openid.net/specs/openid-connect-core-1_0.html
>>                  <http://openid.net/specs/openid-connect-core-1_0.html>>.
>>                  It allows
>>                  ? ? ?the application to pass a list of req locales in
>>                  case the
>>                  ? ? ?application knows it.
>>
>>                  ? ? ?When doing the redirect login flow the
>>                  applications should use
>>                  ? ? ?ui_locales. kc_locale is an internal param and
>>                  should really only
>>                  ? ? ?be used by the locale switcher on the login screen.
>>
>>                  ? ? ?On 16 April 2018 at 02:44, Stan Silvert
>>                  <ssilvert at redhat.com <mailto:ssilvert at redhat.com>
>>                  ? ? ?<mailto:ssilvert at redhat.com
>>                  <mailto:ssilvert at redhat.com>>> wrote:
>>
>>                  ? ? ? ? ?Does anyone know what ui_locales is actually
>>                  used for?
>>
>>                  ? ? ? ? ?I can't find usages except for in the testsuite.
>>
>>                  ? ? ? ? ?The query param used to change locale is
>>                  kc_locale.? Should
>>                  ? ? ? ? ?ui_locales
>>                  ? ? ? ? ?deprecated?
>>
>>                  ? ? ? ? ?Stan
>>
>>                  ? ? ? ? ?_______________________________________________
>>                  ? ? ? ? ?keycloak-dev mailing list
>>                  keycloak-dev at lists.jboss.org
>>                  <mailto:keycloak-dev at lists.jboss.org>
>>                  ? ? ? ? ?<mailto:keycloak-dev at lists.jboss.org
>>                  <mailto:keycloak-dev at lists.jboss.org>>
>>                  https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>                  <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>                         
>>                  ?<https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>                  <https://lists.jboss.org/mailman/listinfo/keycloak-dev>>
>>
>>
>>
>>          _______________________________________________
>>          keycloak-dev mailing list
>>          keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>>          https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>          <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>
>>
>>
>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



From ssilvert at redhat.com  Wed Apr 18 07:02:25 2018
From: ssilvert at redhat.com (Stan Silvert)
Date: Wed, 18 Apr 2018 07:02:25 -0400
Subject: [keycloak-dev] New Account Management Console
Message-ID: <b33b83d6-fbec-22d4-5cc0-d586ae318d01@redhat.com>

As many of you know, we're working on a brand new Account Management 
Console with a modern look and feel, plus new functionality.

Our designers have been working hard on wireframes to get the look and 
feel just right.? If you would like to take a look at the overall 
design, an overview is here:

https://redhat.invisionapp.com/share/FMFGF7AP37B#/screens/274688541


At this time, we are requesting feedback from the following sections.? 
You can create a free invision account and leave comments directly on 
the wireframe.? Please only post high level comments on this mailing 
list.? Feedback on specific items should be done using the invision 
tool.? Thanks for your help.

1) Welcome Screen (https://issues.jboss.org/browse/KEYCLOAK-7164)

https://redhat.invisionapp.com/share/YEGX80V972M#/screens/291439592_Landingpage-1 


2) Authenticator (https://issues.jboss.org/browse/KEYCLOAK-6505)

https://redhat.invisionapp.com/share/PSGRN7QYT57#/screens

3) Consent Screen (https://issues.jboss.org/browse/KEYCLOAK-6965)

https://redhat.invisionapp.com/share/8RGM75AUMDZ#/289976806_v1-4-flatlist

4) Applications Page (https://issues.jboss.org/browse/KEYCLOAK-6501)

https://redhat.invisionapp.com/share/FMFGF7AP37B#/277860929_P68-Applications 



From christian.beikov at gmail.com  Wed Apr 18 07:45:06 2018
From: christian.beikov at gmail.com (Christian Beikov)
Date: Wed, 18 Apr 2018 13:45:06 +0200
Subject: [keycloak-dev] Application and server in separate networks
Message-ID: <41e1a805-cc38-50cf-f794-cda6afd49313@gmail.com>

Hi,

is it necessary that an application secured by Keycloak can access the 
Keycloak server? Or is it enough if the Browser can access the Keycloak 
server?

-- 

Mit freundlichen Gr??en,
------------------------------------------------------------------------
*Christian Beikov*

From sthorger at redhat.com  Wed Apr 18 07:46:25 2018
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 18 Apr 2018 13:46:25 +0200
Subject: [keycloak-dev] ui_locales query parameter?
In-Reply-To: <85f9a6da-023e-bc72-8897-35254dcfce25@redhat.com>
References: <9599201b-a4ef-d306-0c10-a244a89812c1@redhat.com>
	<CAJgngAeU_vro9weu5C_Rfx6Jc0Gu4M+a5yWE5VvQ0XCfGDZv5w@mail.gmail.com>
	<b0531f7e-5e69-4044-5ca3-caf6f219f013@redhat.com>
	<CAJgngAdM3FV_sWZ1_oDszLw+FmyAPQ0fJbq09tKeFugfe_nZkg@mail.gmail.com>
	<1a8d1f96-dee9-f9bf-ac1d-cc068d458a92@redhat.com>
	<05def24f-3d66-2798-ef14-c73b3949eb10@redhat.com>
	<CAJgngAfgCwoLm7f1BeWxTyrEr55VspssinNnRQ6DnCFMs9_JZA@mail.gmail.com>
	<0d704542-de4d-a07f-3b42-deaa8b22633b@redhat.com>
	<85f9a6da-023e-bc72-8897-35254dcfce25@redhat.com>
Message-ID: <CAJgngAeShg4HZL5tTR-zvziKYeBU3-gQ3S4t+DU-_uwDKvO_4w@mail.gmail.com>

I don't think it has to be done the way I propose so I don't see a strong
need to change it. As long as it works with kc_locale that's fine.

On 18 April 2018 at 01:17, Stan Silvert <ssilvert at redhat.com> wrote:

> On 4/17/2018 3:07 PM, Stan Silvert wrote:
> > On 4/17/2018 1:59 PM, Stian Thorgersen wrote:
> >> For the account management console I think the correct approach is the
> >> following:
> >>
> >> * Add an endpoint to account management service to allow setting the
> >> user locale which the account management should call - it should not
> >> re-direct to login back and do the whole login dance
> >> * Change the way the account management console loads the messages -
> >> it should load using a rest endpoint, not by injecting into the
> >> index.ftl. That allows re-loading messages if the locale is changed
> >> without having to do the login dance
> > What is it about the "login dance" that causes a problem?  It seems to
> > do exactly what I need it to do, as long as I can pass in kc_locale.
> I was thinking that I actually need the redirect in order to
> re-initialize the welcome screen's localized text.  The welcome screen
> uses FreeMarker for localization.  But you can't get back to the welcome
> screen without logging out, so logout's redirect would take care of the
> re-initialization of the welcome screen. Therefore, adding an endpoint
> and reloading the messages in Angular would work.
>
> A new endpoint for this would:
> * Set the cookie to the new locale
> * Set the UserModel to the new locale
> * Return the localized message bundle
>
> Then I would have to refactor all the language handling on the Angular
> side.  It would all just take a bit of time to implement. But if you
> really think it has to be done that way we can do it.
>
> >
> >>
> >>
> >> On 17 April 2018 at 15:59, Marek Posolda <mposolda at redhat.com
> >> <mailto:mposolda at redhat.com>> wrote:
> >>
> >>      On 17/04/18 15:00, Stan Silvert wrote:
> >>
> >>          On 4/16/2018 1:51 PM, Stian Thorgersen wrote:
> >>
> >>              kc_locale is only aimed at internal use. You should use
> >>              ui_locales
> >>              that's the publicly available param.
> >>
> >>          The problem is that I need the server-side logic associated
> with
> >>          kc_locale.  kc_locale will update the cookie and update the
> >>          UserModel.
> >>          ui_locales is just a pass-through back to the application.
> >>
> >>          So we can either add kc_locale as a login param in keycloak.js
> >>          or we can
> >>          add the server-side logic to ui_locales.  The simplest is to
> >>          do the
> >>          former.  But perhaps we should have been doing the latter all
> >>          along?
> >>
> >>      IMO the ui_locales parameter shouldn't update the UserModel. It's
> >>      possible that there would be 2 different applications and both of
> >>      them will send different values of ui_locales parameter. In that
> >>      case, when user switch between application1 and application2 (on
> >>      each SSO login), there will be update to UserModel, which is not
> >>      good regarding performance IMO.
> >>
> >>      I can see in LocaleHelper.getUserLocale that the order about how
> >>      the locale is resolved is:
> >>      1. kc_locale parameter
> >>      2. KEYCLOAK_LOCALE cookie
> >>      3. UserModel attribute
> >>      4. ui_locales query parameter
> >>      5. Accept-Language header
> >>
> >>      Is this order proper or not? AFAIK the first 3 items are used just
> >>      if user explicitly selects the language on Keycloak login screen
> >>      (or account mgmt screen). If we put ui_locales up, we will defacto
> >>      give the control to application to override the localization,
> >>      which user explicitly chosen on login screen. Do we want to do
> >>      that? Is it good regarding usability? I think that not, but maybe
> >>      I am wrong...
> >>
> >>
> >> I think the current order is correct.
> >>
> >> 1. Change locale if user has explicitly made the change - kc_locale
> >> should only be set when the user changes it manually through login pages
> >> 2-3 Tries to figure out the users last pick
> >> 4. Provided by the application as a hint for what locale the user may
> >> want. It should not override the users explicitly set locale
> >> 5. Accept-Language is supposed to give the users preferred locale.
> >> However, this is often wrong and just defaults to en. Hence why it
> >> comes last.
> >>
> >> There's been quite a lot of discussion to get this right in the past,
> >> so I'm quite confident that the current logic works and it has been
> >> confirmed by a surprising amount of folks. Well it was tweaked quite a
> >> few times based on user feedback.
> >>
> >>
> >>      Marek
> >>
> >>
> >>              On 16 April 2018 at 16:06, Stan Silvert
> >>              <ssilvert at redhat.com <mailto:ssilvert at redhat.com>
> >>              <mailto:ssilvert at redhat.com <mailto:ssilvert at redhat.com>>>
> >>              wrote:
> >>
> >>                   OK.
> >>
> >>                   Does anyone object to adding kc_locale to the login
> >>              options on the
> >>                   keycloak.js adapter?
> >>
> >>
> >>
> >>                   On 4/16/2018 2:45 AM, Stian Thorgersen wrote:
> >>
> >>                       It's a query param defined by OpenID Connect. See
> >>                  http://openid.net/specs/openid-connect-core-1_0.html
> >>                  <http://openid.net/specs/openid-connect-core-1_0.html>
> >>
> >>                   <http://openid.net/specs/openid-connect-core-1_0.html
> >>                  <http://openid.net/specs/openid-connect-core-1_0.html
> >>.
> >>                  It allows
> >>                       the application to pass a list of req locales in
> >>                  case the
> >>                       application knows it.
> >>
> >>                       When doing the redirect login flow the
> >>                  applications should use
> >>                       ui_locales. kc_locale is an internal param and
> >>                  should really only
> >>                       be used by the locale switcher on the login
> screen.
> >>
> >>                       On 16 April 2018 at 02:44, Stan Silvert
> >>                  <ssilvert at redhat.com <mailto:ssilvert at redhat.com>
> >>                       <mailto:ssilvert at redhat.com
> >>                  <mailto:ssilvert at redhat.com>>> wrote:
> >>
> >>                           Does anyone know what ui_locales is actually
> >>                  used for?
> >>
> >>                           I can't find usages except for in the
> testsuite.
> >>
> >>                           The query param used to change locale is
> >>                  kc_locale.  Should
> >>                           ui_locales
> >>                           deprecated?
> >>
> >>                           Stan
> >>
> >>                           _____________________________
> __________________
> >>                           keycloak-dev mailing list
> >>                  keycloak-dev at lists.jboss.org
> >>                  <mailto:keycloak-dev at lists.jboss.org>
> >>                           <mailto:keycloak-dev at lists.jboss.org
> >>                  <mailto:keycloak-dev at lists.jboss.org>>
> >>                  https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>                  <https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> >>
> >>                   <https://lists.jboss.org/
> mailman/listinfo/keycloak-dev
> >>                  <https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> >>
> >>
> >>
> >>          _______________________________________________
> >>          keycloak-dev mailing list
> >>          keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.
> jboss.org>
> >>          https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>          <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
> >>
> >>
> >>
> >>
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From ssilvert at redhat.com  Wed Apr 18 08:19:58 2018
From: ssilvert at redhat.com (Stan Silvert)
Date: Wed, 18 Apr 2018 08:19:58 -0400
Subject: [keycloak-dev] ui_locales query parameter?
In-Reply-To: <CAJgngAeShg4HZL5tTR-zvziKYeBU3-gQ3S4t+DU-_uwDKvO_4w@mail.gmail.com>
References: <9599201b-a4ef-d306-0c10-a244a89812c1@redhat.com>
	<CAJgngAeU_vro9weu5C_Rfx6Jc0Gu4M+a5yWE5VvQ0XCfGDZv5w@mail.gmail.com>
	<b0531f7e-5e69-4044-5ca3-caf6f219f013@redhat.com>
	<CAJgngAdM3FV_sWZ1_oDszLw+FmyAPQ0fJbq09tKeFugfe_nZkg@mail.gmail.com>
	<1a8d1f96-dee9-f9bf-ac1d-cc068d458a92@redhat.com>
	<05def24f-3d66-2798-ef14-c73b3949eb10@redhat.com>
	<CAJgngAfgCwoLm7f1BeWxTyrEr55VspssinNnRQ6DnCFMs9_JZA@mail.gmail.com>
	<0d704542-de4d-a07f-3b42-deaa8b22633b@redhat.com>
	<85f9a6da-023e-bc72-8897-35254dcfce25@redhat.com>
	<CAJgngAeShg4HZL5tTR-zvziKYeBU3-gQ3S4t+DU-_uwDKvO_4w@mail.gmail.com>
Message-ID: <c78a0305-d893-7fd6-e14a-2445cc983238@redhat.com>

On 4/18/2018 7:46 AM, Stian Thorgersen wrote:
> I don't think it has to be done the way I propose so I don't see a 
> strong need to change it. As long as it works with kc_locale that's fine.
OK.? I'll add the kc_locale param to keycloak.js.? It might be useful 
for others as well.

>
> On 18 April 2018 at 01:17, Stan Silvert <ssilvert at redhat.com 
> <mailto:ssilvert at redhat.com>> wrote:
>
>     On 4/17/2018 3:07 PM, Stan Silvert wrote:
>     > On 4/17/2018 1:59 PM, Stian Thorgersen wrote:
>     >> For the account management console I think the correct approach
>     is the
>     >> following:
>     >>
>     >> * Add an endpoint to account management service to allow
>     setting the
>     >> user locale which the account management should call - it
>     should not
>     >> re-direct to login back and do the whole login dance
>     >> * Change the way the account management console loads the
>     messages -
>     >> it should load using a rest endpoint, not by injecting into the
>     >> index.ftl. That allows re-loading messages if the locale is changed
>     >> without having to do the login dance
>     > What is it about the "login dance" that causes a problem?? It
>     seems to
>     > do exactly what I need it to do, as long as I can pass in kc_locale.
>     I was thinking that I actually need the redirect in order to
>     re-initialize the welcome screen's localized text.? The welcome
>     screen
>     uses FreeMarker for localization.? But you can't get back to the
>     welcome
>     screen without logging out, so logout's redirect would take care
>     of the
>     re-initialization of the welcome screen. Therefore, adding an
>     endpoint
>     and reloading the messages in Angular would work.
>
>     A new endpoint for this would:
>     * Set the cookie to the new locale
>     * Set the UserModel to the new locale
>     * Return the localized message bundle
>
>     Then I would have to refactor all the language handling on the
>     Angular
>     side.? It would all just take a bit of time to implement. But if you
>     really think it has to be done that way we can do it.
>
>     >
>     >>
>     >>
>     >> On 17 April 2018 at 15:59, Marek Posolda <mposolda at redhat.com
>     <mailto:mposolda at redhat.com>
>     >> <mailto:mposolda at redhat.com <mailto:mposolda at redhat.com>>> wrote:
>     >>
>     >>? ? ? On 17/04/18 15:00, Stan Silvert wrote:
>     >>
>     >>? ? ? ? ? On 4/16/2018 1:51 PM, Stian Thorgersen wrote:
>     >>
>     >>? ? ? ? ? ? ? kc_locale is only aimed at internal use. You
>     should use
>     >>? ? ? ? ? ? ? ui_locales
>     >>? ? ? ? ? ? ? that's the publicly available param.
>     >>
>     >>? ? ? ? ? The problem is that I need the server-side logic
>     associated with
>     >>? ? ? ? ? kc_locale.? kc_locale will update the cookie and
>     update the
>     >>? ? ? ? ? UserModel.
>     >>? ? ? ? ? ui_locales is just a pass-through back to the application.
>     >>
>     >>? ? ? ? ? So we can either add kc_locale as a login param in
>     keycloak.js
>     >>? ? ? ? ? or we can
>     >>? ? ? ? ? add the server-side logic to ui_locales.? The simplest
>     is to
>     >>? ? ? ? ? do the
>     >>? ? ? ? ? former.? But perhaps we should have been doing the
>     latter all
>     >>? ? ? ? ? along?
>     >>
>     >>? ? ? IMO the ui_locales parameter shouldn't update the
>     UserModel. It's
>     >>? ? ? possible that there would be 2 different applications and
>     both of
>     >>? ? ? them will send different values of ui_locales parameter.
>     In that
>     >>? ? ? case, when user switch between application1 and
>     application2 (on
>     >>? ? ? each SSO login), there will be update to UserModel, which
>     is not
>     >>? ? ? good regarding performance IMO.
>     >>
>     >>? ? ? I can see in LocaleHelper.getUserLocale that the order
>     about how
>     >>? ? ? the locale is resolved is:
>     >>? ? ? 1. kc_locale parameter
>     >>? ? ? 2. KEYCLOAK_LOCALE cookie
>     >>? ? ? 3. UserModel attribute
>     >>? ? ? 4. ui_locales query parameter
>     >>? ? ? 5. Accept-Language header
>     >>
>     >>? ? ? Is this order proper or not? AFAIK the first 3 items are
>     used just
>     >>? ? ? if user explicitly selects the language on Keycloak login
>     screen
>     >>? ? ? (or account mgmt screen). If we put ui_locales up, we will
>     defacto
>     >>? ? ? give the control to application to override the localization,
>     >>? ? ? which user explicitly chosen on login screen. Do we want to do
>     >>? ? ? that? Is it good regarding usability? I think that not,
>     but maybe
>     >>? ? ? I am wrong...
>     >>
>     >>
>     >> I think the current order is correct.
>     >>
>     >> 1. Change locale if user has explicitly made the change - kc_locale
>     >> should only be set when the user changes it manually through
>     login pages
>     >> 2-3 Tries to figure out the users last pick
>     >> 4. Provided by the application as a hint for what locale the
>     user may
>     >> want. It should not override the users explicitly set locale
>     >> 5. Accept-Language is supposed to give the users preferred locale.
>     >> However, this is often wrong and just defaults to en. Hence why it
>     >> comes last.
>     >>
>     >> There's been quite a lot of discussion to get this right in the
>     past,
>     >> so I'm quite confident that the current logic works and it has been
>     >> confirmed by a surprising amount of folks. Well it was tweaked
>     quite a
>     >> few times based on user feedback.
>     >>
>     >>
>     >>? ? ? Marek
>     >>
>     >>
>     >>? ? ? ? ? ? ? On 16 April 2018 at 16:06, Stan Silvert
>     >>? ? ? ? ? ? ? <ssilvert at redhat.com <mailto:ssilvert at redhat.com>
>     <mailto:ssilvert at redhat.com <mailto:ssilvert at redhat.com>>
>     >>? ? ? ? ? ? ? <mailto:ssilvert at redhat.com
>     <mailto:ssilvert at redhat.com> <mailto:ssilvert at redhat.com
>     <mailto:ssilvert at redhat.com>>>>
>     >>? ? ? ? ? ? ? wrote:
>     >>
>     >>? ? ? ? ? ? ? ? ? ?OK.
>     >>
>     >>? ? ? ? ? ? ? ? ? ?Does anyone object to adding kc_locale to the
>     login
>     >>? ? ? ? ? ? ? options on the
>     >>? ? ? ? ? ? ? ? ? ?keycloak.js adapter?
>     >>
>     >>
>     >>
>     >>? ? ? ? ? ? ? ? ? ?On 4/16/2018 2:45 AM, Stian Thorgersen wrote:
>     >>
>     >>? ? ? ? ? ? ? ? ? ? ? ?It's a query param defined by OpenID
>     Connect. See
>     >> http://openid.net/specs/openid-connect-core-1_0.html
>     <http://openid.net/specs/openid-connect-core-1_0.html>
>     >>? ? ? ? ? ? ? ? ?
>     <http://openid.net/specs/openid-connect-core-1_0.html
>     <http://openid.net/specs/openid-connect-core-1_0.html>>
>     >>
>     >>? ? ? ? ? ? ? ? ?
>     ?<http://openid.net/specs/openid-connect-core-1_0.html
>     <http://openid.net/specs/openid-connect-core-1_0.html>
>     >>? ? ? ? ? ? ? ? ?
>     <http://openid.net/specs/openid-connect-core-1_0.html
>     <http://openid.net/specs/openid-connect-core-1_0.html>>>.
>     >>? ? ? ? ? ? ? ? ? It allows
>     >>? ? ? ? ? ? ? ? ? ? ? ?the application to pass a list of req
>     locales in
>     >>? ? ? ? ? ? ? ? ? case the
>     >>? ? ? ? ? ? ? ? ? ? ? ?application knows it.
>     >>
>     >>? ? ? ? ? ? ? ? ? ? ? ?When doing the redirect login flow the
>     >>? ? ? ? ? ? ? ? ? applications should use
>     >>? ? ? ? ? ? ? ? ? ? ? ?ui_locales. kc_locale is an internal
>     param and
>     >>? ? ? ? ? ? ? ? ? should really only
>     >>? ? ? ? ? ? ? ? ? ? ? ?be used by the locale switcher on the
>     login screen.
>     >>
>     >>? ? ? ? ? ? ? ? ? ? ? ?On 16 April 2018 at 02:44, Stan Silvert
>     >>? ? ? ? ? ? ? ? ? <ssilvert at redhat.com
>     <mailto:ssilvert at redhat.com> <mailto:ssilvert at redhat.com
>     <mailto:ssilvert at redhat.com>>
>     >>? ? ? ? ? ? ? ? ? ? ? ?<mailto:ssilvert at redhat.com
>     <mailto:ssilvert at redhat.com>
>     >>? ? ? ? ? ? ? ? ? <mailto:ssilvert at redhat.com <mailto:ssilvert at redhat.com>>>> wrote:
>     >>
>     >>? ? ? ? ? ? ? ? ? ? ? ? ? ?Does anyone know what ui_locales is
>     actually
>     >>? ? ? ? ? ? ? ? ? used for?
>     >>
>     >>? ? ? ? ? ? ? ? ? ? ? ? ? ?I can't find usages except for in the
>     testsuite.
>     >>
>     >>? ? ? ? ? ? ? ? ? ? ? ? ? ?The query param used to change locale is
>     >>? ? ? ? ? ? ? ? ? kc_locale.? Should
>     >>? ? ? ? ? ? ? ? ? ? ? ? ? ?ui_locales
>     >>? ? ? ? ? ? ? ? ? ? ? ? ? ?deprecated?
>     >>
>     >>? ? ? ? ? ? ? ? ? ? ? ? ? ?Stan
>     >>
>     >> ?_______________________________________________
>     >>? ? ? ? ? ? ? ? ? ? ? ? ? ?keycloak-dev mailing list
>     >> keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     >>? ? ? ? ? ? ? ? ? <mailto:keycloak-dev at lists.jboss.org
>     <mailto:keycloak-dev at lists.jboss.org>>
>     >>? ? ? ? ? ? ? ? ? ? ? ? ? ?<mailto:keycloak-dev at lists.jboss.org
>     <mailto:keycloak-dev at lists.jboss.org>
>     >>? ? ? ? ? ? ? ? ? <mailto:keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>>>
>     >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>     <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>     >>? ? ? ? ? ? ? ? ?
>     <https://lists.jboss.org/mailman/listinfo/keycloak-dev
>     <https://lists.jboss.org/mailman/listinfo/keycloak-dev>>
>     >>
>     >>? ? ? ? ? ? ? ? ?
>     ?<https://lists.jboss.org/mailman/listinfo/keycloak-dev
>     <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>     >>? ? ? ? ? ? ? ? ?
>     <https://lists.jboss.org/mailman/listinfo/keycloak-dev
>     <https://lists.jboss.org/mailman/listinfo/keycloak-dev>>>
>     >>
>     >>
>     >>
>     >>? ? ? ? ? _______________________________________________
>     >>? ? ? ? ? keycloak-dev mailing list
>     >> keycloak-dev at lists.jboss.org
>     <mailto:keycloak-dev at lists.jboss.org>
>     <mailto:keycloak-dev at lists.jboss.org
>     <mailto:keycloak-dev at lists.jboss.org>>
>     >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>     <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>     >>? ? ? ? ? <https://lists.jboss.org/mailman/listinfo/keycloak-dev
>     <https://lists.jboss.org/mailman/listinfo/keycloak-dev>>
>     >>
>     >>
>     >>
>     >>
>     > _______________________________________________
>     > keycloak-dev mailing list
>     > keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>     <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>
>
>     _______________________________________________
>     keycloak-dev mailing list
>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>     <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>
>


From sthorger at redhat.com  Wed Apr 18 08:37:41 2018
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 18 Apr 2018 14:37:41 +0200
Subject: [keycloak-dev] ui_locales query parameter?
In-Reply-To: <c78a0305-d893-7fd6-e14a-2445cc983238@redhat.com>
References: <9599201b-a4ef-d306-0c10-a244a89812c1@redhat.com>
	<CAJgngAeU_vro9weu5C_Rfx6Jc0Gu4M+a5yWE5VvQ0XCfGDZv5w@mail.gmail.com>
	<b0531f7e-5e69-4044-5ca3-caf6f219f013@redhat.com>
	<CAJgngAdM3FV_sWZ1_oDszLw+FmyAPQ0fJbq09tKeFugfe_nZkg@mail.gmail.com>
	<1a8d1f96-dee9-f9bf-ac1d-cc068d458a92@redhat.com>
	<05def24f-3d66-2798-ef14-c73b3949eb10@redhat.com>
	<CAJgngAfgCwoLm7f1BeWxTyrEr55VspssinNnRQ6DnCFMs9_JZA@mail.gmail.com>
	<0d704542-de4d-a07f-3b42-deaa8b22633b@redhat.com>
	<85f9a6da-023e-bc72-8897-35254dcfce25@redhat.com>
	<CAJgngAeShg4HZL5tTR-zvziKYeBU3-gQ3S4t+DU-_uwDKvO_4w@mail.gmail.com>
	<c78a0305-d893-7fd6-e14a-2445cc983238@redhat.com>
Message-ID: <CAJgngAeSuTouzjuAqAS3mCrQMGt9on090qUe90qvA452PS72kQ@mail.gmail.com>

Not sure it should be added directly to keycloak.js as it's not strictly a
supported param. Either you should just use it from keycloak.js, but not
make it a direct option, or we should add it as a supported param. In the
latter case we should probably document it.

On 18 April 2018 at 14:19, Stan Silvert <ssilvert at redhat.com> wrote:

> On 4/18/2018 7:46 AM, Stian Thorgersen wrote:
>
> I don't think it has to be done the way I propose so I don't see a strong
> need to change it. As long as it works with kc_locale that's fine.
>
> OK.  I'll add the kc_locale param to keycloak.js.  It might be useful for
> others as well.
>
>
>
> On 18 April 2018 at 01:17, Stan Silvert <ssilvert at redhat.com> wrote:
>
>> On 4/17/2018 3:07 PM, Stan Silvert wrote:
>> > On 4/17/2018 1:59 PM, Stian Thorgersen wrote:
>> >> For the account management console I think the correct approach is the
>> >> following:
>> >>
>> >> * Add an endpoint to account management service to allow setting the
>> >> user locale which the account management should call - it should not
>> >> re-direct to login back and do the whole login dance
>> >> * Change the way the account management console loads the messages -
>> >> it should load using a rest endpoint, not by injecting into the
>> >> index.ftl. That allows re-loading messages if the locale is changed
>> >> without having to do the login dance
>> > What is it about the "login dance" that causes a problem?  It seems to
>> > do exactly what I need it to do, as long as I can pass in kc_locale.
>> I was thinking that I actually need the redirect in order to
>> re-initialize the welcome screen's localized text.  The welcome screen
>> uses FreeMarker for localization.  But you can't get back to the welcome
>> screen without logging out, so logout's redirect would take care of the
>> re-initialization of the welcome screen. Therefore, adding an endpoint
>> and reloading the messages in Angular would work.
>>
>> A new endpoint for this would:
>> * Set the cookie to the new locale
>> * Set the UserModel to the new locale
>> * Return the localized message bundle
>>
>> Then I would have to refactor all the language handling on the Angular
>> side.  It would all just take a bit of time to implement. But if you
>> really think it has to be done that way we can do it.
>>
>> >
>> >>
>> >>
>> >> On 17 April 2018 at 15:59, Marek Posolda <mposolda at redhat.com
>> >> <mailto:mposolda at redhat.com>> wrote:
>> >>
>> >>      On 17/04/18 15:00, Stan Silvert wrote:
>> >>
>> >>          On 4/16/2018 1:51 PM, Stian Thorgersen wrote:
>> >>
>> >>              kc_locale is only aimed at internal use. You should use
>> >>              ui_locales
>> >>              that's the publicly available param.
>> >>
>> >>          The problem is that I need the server-side logic associated
>> with
>> >>          kc_locale.  kc_locale will update the cookie and update the
>> >>          UserModel.
>> >>          ui_locales is just a pass-through back to the application.
>> >>
>> >>          So we can either add kc_locale as a login param in keycloak.js
>> >>          or we can
>> >>          add the server-side logic to ui_locales.  The simplest is to
>> >>          do the
>> >>          former.  But perhaps we should have been doing the latter all
>> >>          along?
>> >>
>> >>      IMO the ui_locales parameter shouldn't update the UserModel. It's
>> >>      possible that there would be 2 different applications and both of
>> >>      them will send different values of ui_locales parameter. In that
>> >>      case, when user switch between application1 and application2 (on
>> >>      each SSO login), there will be update to UserModel, which is not
>> >>      good regarding performance IMO.
>> >>
>> >>      I can see in LocaleHelper.getUserLocale that the order about how
>> >>      the locale is resolved is:
>> >>      1. kc_locale parameter
>> >>      2. KEYCLOAK_LOCALE cookie
>> >>      3. UserModel attribute
>> >>      4. ui_locales query parameter
>> >>      5. Accept-Language header
>> >>
>> >>      Is this order proper or not? AFAIK the first 3 items are used just
>> >>      if user explicitly selects the language on Keycloak login screen
>> >>      (or account mgmt screen). If we put ui_locales up, we will defacto
>> >>      give the control to application to override the localization,
>> >>      which user explicitly chosen on login screen. Do we want to do
>> >>      that? Is it good regarding usability? I think that not, but maybe
>> >>      I am wrong...
>> >>
>> >>
>> >> I think the current order is correct.
>> >>
>> >> 1. Change locale if user has explicitly made the change - kc_locale
>> >> should only be set when the user changes it manually through login
>> pages
>> >> 2-3 Tries to figure out the users last pick
>> >> 4. Provided by the application as a hint for what locale the user may
>> >> want. It should not override the users explicitly set locale
>> >> 5. Accept-Language is supposed to give the users preferred locale.
>> >> However, this is often wrong and just defaults to en. Hence why it
>> >> comes last.
>> >>
>> >> There's been quite a lot of discussion to get this right in the past,
>> >> so I'm quite confident that the current logic works and it has been
>> >> confirmed by a surprising amount of folks. Well it was tweaked quite a
>> >> few times based on user feedback.
>> >>
>> >>
>> >>      Marek
>> >>
>> >>
>> >>              On 16 April 2018 at 16:06, Stan Silvert
>> >>              <ssilvert at redhat.com <mailto:ssilvert at redhat.com>
>> >>              <mailto:ssilvert at redhat.com <mailto:ssilvert at redhat.com
>> >>>
>> >>              wrote:
>> >>
>> >>                   OK.
>> >>
>> >>                   Does anyone object to adding kc_locale to the login
>> >>              options on the
>> >>                   keycloak.js adapter?
>> >>
>> >>
>> >>
>> >>                   On 4/16/2018 2:45 AM, Stian Thorgersen wrote:
>> >>
>> >>                       It's a query param defined by OpenID Connect. See
>> >>                  http://openid.net/specs/openid-connect-core-1_0.html
>> >>                  <http://openid.net/specs/openid-connect-core-1_0.html
>> >
>> >>
>> >>                   <http://openid.net/specs/open
>> id-connect-core-1_0.html
>> >>                  <http://openid.net/specs/openid-connect-core-1_0.html
>> >>.
>> >>                  It allows
>> >>                       the application to pass a list of req locales in
>> >>                  case the
>> >>                       application knows it.
>> >>
>> >>                       When doing the redirect login flow the
>> >>                  applications should use
>> >>                       ui_locales. kc_locale is an internal param and
>> >>                  should really only
>> >>                       be used by the locale switcher on the login
>> screen.
>> >>
>> >>                       On 16 April 2018 at 02:44, Stan Silvert
>> >>                  <ssilvert at redhat.com <mailto:ssilvert at redhat.com>
>> >>                       <mailto:ssilvert at redhat.com
>> >>                  <mailto:ssilvert at redhat.com>>> wrote:
>> >>
>> >>                           Does anyone know what ui_locales is actually
>> >>                  used for?
>> >>
>> >>                           I can't find usages except for in the
>> testsuite.
>> >>
>> >>                           The query param used to change locale is
>> >>                  kc_locale.  Should
>> >>                           ui_locales
>> >>                           deprecated?
>> >>
>> >>                           Stan
>> >>
>> >>                           _____________________________
>> __________________
>> >>                           keycloak-dev mailing list
>> >>                  keycloak-dev at lists.jboss.org
>> >>                  <mailto:keycloak-dev at lists.jboss.org>
>> >>                           <mailto:keycloak-dev at lists.jboss.org
>> >>                  <mailto:keycloak-dev at lists.jboss.org>>
>> >>                  https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> >>                  <https://lists.jboss.org/mailm
>> an/listinfo/keycloak-dev>
>> >>
>> >>                   <https://lists.jboss.org/mail
>> man/listinfo/keycloak-dev
>> >>                  <https://lists.jboss.org/mailm
>> an/listinfo/keycloak-dev>>
>> >>
>> >>
>> >>
>> >>          _______________________________________________
>> >>          keycloak-dev mailing list
>> >>          keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jbo
>> ss.org>
>> >>          https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> >>          <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>> >>
>> >>
>> >>
>> >>
>> > _______________________________________________
>> > keycloak-dev mailing list
>> > keycloak-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
>

From thomas.darimont at googlemail.com  Wed Apr 18 08:48:52 2018
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Wed, 18 Apr 2018 14:48:52 +0200
Subject: [keycloak-dev] Application and server in separate networks
In-Reply-To: <41e1a805-cc38-50cf-f794-cda6afd49313@gmail.com>
References: <41e1a805-cc38-50cf-f794-cda6afd49313@gmail.com>
Message-ID: <CAK-7U1gGFnwc3EcgL3whgdGbSTH9xSVwVSHxc1i+JtetJ83H4g@mail.gmail.com>

Hello Christian,

your application server needs to communicate with the Keycloak server to
retrieve the realm public key referenced in the token to verify the token
signature.
The current implementation in Keycloak fetches & caches unknown public keys
automatically.

You could also use a fixed realm public key on the application server side
but it would not support key rotation anymore.

Cheers,
Thomas

2018-04-18 13:45 GMT+02:00 Christian Beikov <christian.beikov at gmail.com>:

> Hi,
>
> is it necessary that an application secured by Keycloak can access the
> Keycloak server? Or is it enough if the Browser can access the Keycloak
> server?
>
> --
>
> Mit freundlichen Gr??en,
> ------------------------------------------------------------------------
> *Christian Beikov*
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From christian.beikov at gmail.com  Wed Apr 18 09:10:03 2018
From: christian.beikov at gmail.com (Christian Beikov)
Date: Wed, 18 Apr 2018 15:10:03 +0200
Subject: [keycloak-dev] Application and server in separate networks
In-Reply-To: <CAK-7U1gGFnwc3EcgL3whgdGbSTH9xSVwVSHxc1i+JtetJ83H4g@mail.gmail.com>
References: <41e1a805-cc38-50cf-f794-cda6afd49313@gmail.com>
	<CAK-7U1gGFnwc3EcgL3whgdGbSTH9xSVwVSHxc1i+JtetJ83H4g@mail.gmail.com>
Message-ID: <3cb697ca-e3d1-4b3d-4581-3d344a884eb6@gmail.com>

Hey Thomas,

thanks for you quick answer. I read in the documentation that it's 
possible to define a "realm-public-key" in the keycloak.json but key 
rotation would break the adapter. Since the Keycloak server is only 
accessible within our private network, I would like to disable key 
rotation and use the realm-public-key, but I wasn't able to find the 
knob to deactivate that yet. Will a fixed realm public key enable me to 
run the scenario I described?


Mit freundlichen Gr??en,
------------------------------------------------------------------------
*Christian Beikov*
Am 18.04.2018 um 14:48 schrieb Thomas Darimont:
> Hello Christian,
>
> your application server needs to communicate with the Keycloak server 
> to retrieve the realm public key referenced in the token to verify the 
> token signature.
> The current implementation in Keycloak fetches & caches unknown public 
> keys automatically.
>
> You could also use a fixed realm public key on the application server 
> side but it would not support key rotation anymore.
>
> Cheers,
> Thomas
>
> 2018-04-18 13:45 GMT+02:00 Christian Beikov 
> <christian.beikov at gmail.com <mailto:christian.beikov at gmail.com>>:
>
>     Hi,
>
>     is it necessary that an application secured by Keycloak can access
>     the
>     Keycloak server? Or is it enough if the Browser can access the
>     Keycloak
>     server?
>
>     -- 
>
>     Mit freundlichen Gr??en,
>     ------------------------------------------------------------------------
>     *Christian Beikov*
>     _______________________________________________
>     keycloak-dev mailing list
>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>     <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>
>


From ssilvert at redhat.com  Wed Apr 18 10:23:35 2018
From: ssilvert at redhat.com (Stan Silvert)
Date: Wed, 18 Apr 2018 10:23:35 -0400
Subject: [keycloak-dev] ui_locales query parameter?
In-Reply-To: <CAJgngAeSuTouzjuAqAS3mCrQMGt9on090qUe90qvA452PS72kQ@mail.gmail.com>
References: <9599201b-a4ef-d306-0c10-a244a89812c1@redhat.com>
	<CAJgngAeU_vro9weu5C_Rfx6Jc0Gu4M+a5yWE5VvQ0XCfGDZv5w@mail.gmail.com>
	<b0531f7e-5e69-4044-5ca3-caf6f219f013@redhat.com>
	<CAJgngAdM3FV_sWZ1_oDszLw+FmyAPQ0fJbq09tKeFugfe_nZkg@mail.gmail.com>
	<1a8d1f96-dee9-f9bf-ac1d-cc068d458a92@redhat.com>
	<05def24f-3d66-2798-ef14-c73b3949eb10@redhat.com>
	<CAJgngAfgCwoLm7f1BeWxTyrEr55VspssinNnRQ6DnCFMs9_JZA@mail.gmail.com>
	<0d704542-de4d-a07f-3b42-deaa8b22633b@redhat.com>
	<85f9a6da-023e-bc72-8897-35254dcfce25@redhat.com>
	<CAJgngAeShg4HZL5tTR-zvziKYeBU3-gQ3S4t+DU-_uwDKvO_4w@mail.gmail.com>
	<c78a0305-d893-7fd6-e14a-2445cc983238@redhat.com>
	<CAJgngAeSuTouzjuAqAS3mCrQMGt9on090qUe90qvA452PS72kQ@mail.gmail.com>
Message-ID: <b9ac3768-0095-9df8-57f4-bebabd6d01cb@redhat.com>

On 4/18/2018 8:37 AM, Stian Thorgersen wrote:
> Not sure it should be added directly to keycloak.js as it's not 
> strictly a supported param. Either you should just use it from 
> keycloak.js, but not make it a direct option, or we should add it as a 
> supported param. In the latter case we should probably document it.
Yes, I'm proposing that we add it, support it, and document it.

I don't know how I can use it without adding it as an option.
>
> On 18 April 2018 at 14:19, Stan Silvert <ssilvert at redhat.com 
> <mailto:ssilvert at redhat.com>> wrote:
>
>     On 4/18/2018 7:46 AM, Stian Thorgersen wrote:
>>     I don't think it has to be done the way I propose so I don't see
>>     a strong need to change it. As long as it works with kc_locale
>>     that's fine.
>     OK.? I'll add the kc_locale param to keycloak.js. It might be
>     useful for others as well.
>
>
>>
>>     On 18 April 2018 at 01:17, Stan Silvert <ssilvert at redhat.com
>>     <mailto:ssilvert at redhat.com>> wrote:
>>
>>         On 4/17/2018 3:07 PM, Stan Silvert wrote:
>>         > On 4/17/2018 1:59 PM, Stian Thorgersen wrote:
>>         >> For the account management console I think the correct
>>         approach is the
>>         >> following:
>>         >>
>>         >> * Add an endpoint to account management service to allow
>>         setting the
>>         >> user locale which the account management should call - it
>>         should not
>>         >> re-direct to login back and do the whole login dance
>>         >> * Change the way the account management console loads the
>>         messages -
>>         >> it should load using a rest endpoint, not by injecting
>>         into the
>>         >> index.ftl. That allows re-loading messages if the locale
>>         is changed
>>         >> without having to do the login dance
>>         > What is it about the "login dance" that causes a problem??
>>         It seems to
>>         > do exactly what I need it to do, as long as I can pass in
>>         kc_locale.
>>         I was thinking that I actually need the redirect in order to
>>         re-initialize the welcome screen's localized text.? The
>>         welcome screen
>>         uses FreeMarker for localization.? But you can't get back to
>>         the welcome
>>         screen without logging out, so logout's redirect would take
>>         care of the
>>         re-initialization of the welcome screen. Therefore, adding an
>>         endpoint
>>         and reloading the messages in Angular would work.
>>
>>         A new endpoint for this would:
>>         * Set the cookie to the new locale
>>         * Set the UserModel to the new locale
>>         * Return the localized message bundle
>>
>>         Then I would have to refactor all the language handling on
>>         the Angular
>>         side.? It would all just take a bit of time to implement. But
>>         if you
>>         really think it has to be done that way we can do it.
>>
>>         >
>>         >>
>>         >>
>>         >> On 17 April 2018 at 15:59, Marek Posolda
>>         <mposolda at redhat.com <mailto:mposolda at redhat.com>
>>         >> <mailto:mposolda at redhat.com <mailto:mposolda at redhat.com>>>
>>         wrote:
>>         >>
>>         >>? ? ? On 17/04/18 15:00, Stan Silvert wrote:
>>         >>
>>         >>? ? ? ? ? On 4/16/2018 1:51 PM, Stian Thorgersen wrote:
>>         >>
>>         >>? ? ? ? ? ? ? kc_locale is only aimed at internal use. You
>>         should use
>>         >>? ? ? ? ? ? ? ui_locales
>>         >>? ? ? ? ? ? ? that's the publicly available param.
>>         >>
>>         >>? ? ? ? ? The problem is that I need the server-side logic
>>         associated with
>>         >>? ? ? ? ? kc_locale.? kc_locale will update the cookie and
>>         update the
>>         >>? ? ? ? ? UserModel.
>>         >>? ? ? ? ? ui_locales is just a pass-through back to the
>>         application.
>>         >>
>>         >>? ? ? ? ? So we can either add kc_locale as a login param
>>         in keycloak.js
>>         >>? ? ? ? ? or we can
>>         >>? ? ? ? ? add the server-side logic to ui_locales.? The
>>         simplest is to
>>         >>? ? ? ? ? do the
>>         >>? ? ? ? ? former.? But perhaps we should have been doing
>>         the latter all
>>         >>? ? ? ? ? along?
>>         >>
>>         >>? ? ? IMO the ui_locales parameter shouldn't update the
>>         UserModel. It's
>>         >>? ? ? possible that there would be 2 different applications
>>         and both of
>>         >>? ? ? them will send different values of ui_locales
>>         parameter. In that
>>         >>? ? ? case, when user switch between application1 and
>>         application2 (on
>>         >>? ? ? each SSO login), there will be update to UserModel,
>>         which is not
>>         >>? ? ? good regarding performance IMO.
>>         >>
>>         >>? ? ? I can see in LocaleHelper.getUserLocale that the
>>         order about how
>>         >>? ? ? the locale is resolved is:
>>         >>? ? ? 1. kc_locale parameter
>>         >>? ? ? 2. KEYCLOAK_LOCALE cookie
>>         >>? ? ? 3. UserModel attribute
>>         >>? ? ? 4. ui_locales query parameter
>>         >>? ? ? 5. Accept-Language header
>>         >>
>>         >>? ? ? Is this order proper or not? AFAIK the first 3 items
>>         are used just
>>         >>? ? ? if user explicitly selects the language on Keycloak
>>         login screen
>>         >>? ? ? (or account mgmt screen). If we put ui_locales up, we
>>         will defacto
>>         >>? ? ? give the control to application to override the
>>         localization,
>>         >>? ? ? which user explicitly chosen on login screen. Do we
>>         want to do
>>         >>? ? ? that? Is it good regarding usability? I think that
>>         not, but maybe
>>         >>? ? ? I am wrong...
>>         >>
>>         >>
>>         >> I think the current order is correct.
>>         >>
>>         >> 1. Change locale if user has explicitly made the change -
>>         kc_locale
>>         >> should only be set when the user changes it manually
>>         through login pages
>>         >> 2-3 Tries to figure out the users last pick
>>         >> 4. Provided by the application as a hint for what locale
>>         the user may
>>         >> want. It should not override the users explicitly set locale
>>         >> 5. Accept-Language is supposed to give the users preferred
>>         locale.
>>         >> However, this is often wrong and just defaults to en.
>>         Hence why it
>>         >> comes last.
>>         >>
>>         >> There's been quite a lot of discussion to get this right
>>         in the past,
>>         >> so I'm quite confident that the current logic works and it
>>         has been
>>         >> confirmed by a surprising amount of folks. Well it was
>>         tweaked quite a
>>         >> few times based on user feedback.
>>         >>
>>         >>
>>         >>? ? ? Marek
>>         >>
>>         >>
>>         >>? ? ? ? ? ? ? On 16 April 2018 at 16:06, Stan Silvert
>>         >>? ? ? ? ? ? ? <ssilvert at redhat.com
>>         <mailto:ssilvert at redhat.com> <mailto:ssilvert at redhat.com
>>         <mailto:ssilvert at redhat.com>>
>>         >>? ? ? ? ? ? ? <mailto:ssilvert at redhat.com
>>         <mailto:ssilvert at redhat.com> <mailto:ssilvert at redhat.com
>>         <mailto:ssilvert at redhat.com>>>>
>>         >>? ? ? ? ? ? ? wrote:
>>         >>
>>         >>? ? ? ? ? ? ? ? ? ?OK.
>>         >>
>>         >>? ? ? ? ? ? ? ? ? ?Does anyone object to adding kc_locale
>>         to the login
>>         >>? ? ? ? ? ? ? options on the
>>         >>? ? ? ? ? ? ? ? ? ?keycloak.js adapter?
>>         >>
>>         >>
>>         >>
>>         >>? ? ? ? ? ? ? ? ? ?On 4/16/2018 2:45 AM, Stian Thorgersen
>>         wrote:
>>         >>
>>         >>? ? ? ? ? ? ? ? ? ? ? ?It's a query param defined by OpenID
>>         Connect. See
>>         >> http://openid.net/specs/openid-connect-core-1_0.html
>>         <http://openid.net/specs/openid-connect-core-1_0.html>
>>         >>? ? ? ? ? ? ? ? ?
>>         <http://openid.net/specs/openid-connect-core-1_0.html
>>         <http://openid.net/specs/openid-connect-core-1_0.html>>
>>         >>
>>         >>? ? ? ? ? ? ? ? ?
>>         ?<http://openid.net/specs/openid-connect-core-1_0.html
>>         <http://openid.net/specs/openid-connect-core-1_0.html>
>>         >>? ? ? ? ? ? ? ? ?
>>         <http://openid.net/specs/openid-connect-core-1_0.html
>>         <http://openid.net/specs/openid-connect-core-1_0.html>>>.
>>         >>? ? ? ? ? ? ? ? ? It allows
>>         >>? ? ? ? ? ? ? ? ? ? ? ?the application to pass a list of
>>         req locales in
>>         >>? ? ? ? ? ? ? ? ? case the
>>         >>? ? ? ? ? ? ? ? ? ? ? ?application knows it.
>>         >>
>>         >>? ? ? ? ? ? ? ? ? ? ? ?When doing the redirect login flow the
>>         >>? ? ? ? ? ? ? ? ? applications should use
>>         >>? ? ? ? ? ? ? ? ? ? ? ?ui_locales. kc_locale is an internal
>>         param and
>>         >>? ? ? ? ? ? ? ? ? should really only
>>         >>? ? ? ? ? ? ? ? ? ? ? ?be used by the locale switcher on
>>         the login screen.
>>         >>
>>         >>? ? ? ? ? ? ? ? ? ? ? ?On 16 April 2018 at 02:44, Stan Silvert
>>         >>? ? ? ? ? ? ? ? ? <ssilvert at redhat.com
>>         <mailto:ssilvert at redhat.com> <mailto:ssilvert at redhat.com
>>         <mailto:ssilvert at redhat.com>>
>>         >> ?<mailto:ssilvert at redhat.com <mailto:ssilvert at redhat.com>
>>         >>? ? ? ? ? ? ? ? ? <mailto:ssilvert at redhat.com <mailto:ssilvert at redhat.com>>>> wrote:
>>         >>
>>         >>? ? ? ? ? ? ? ? ? ? ? ? ? ?Does anyone know what ui_locales
>>         is actually
>>         >>? ? ? ? ? ? ? ? ? used for?
>>         >>
>>         >>? ? ? ? ? ? ? ? ? ? ? ? ? ?I can't find usages except for
>>         in the testsuite.
>>         >>
>>         >>? ? ? ? ? ? ? ? ? ? ? ? ? ?The query param used to change
>>         locale is
>>         >>? ? ? ? ? ? ? ? ? kc_locale.? Should
>>         >> ?ui_locales
>>         >> ?deprecated?
>>         >>
>>         >>? ? ? ? ? ? ? ? ? ? ? ? ? ?Stan
>>         >>
>>         >> ?_______________________________________________
>>         >> ?keycloak-dev mailing list
>>         >> keycloak-dev at lists.jboss.org
>>         <mailto:keycloak-dev at lists.jboss.org>
>>         >>? ? ? ? ? ? ? ? ? <mailto:keycloak-dev at lists.jboss.org
>>         <mailto:keycloak-dev at lists.jboss.org>>
>>         >> ?<mailto:keycloak-dev at lists.jboss.org
>>         <mailto:keycloak-dev at lists.jboss.org>
>>         >>? ? ? ? ? ? ? ? ? <mailto:keycloak-dev at lists.jboss.org
>>         <mailto:keycloak-dev at lists.jboss.org>>>
>>         >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>         <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>         >>? ? ? ? ? ? ? ? ?
>>         <https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>         <https://lists.jboss.org/mailman/listinfo/keycloak-dev>>
>>         >>
>>         >>? ? ? ? ? ? ? ? ?
>>         ?<https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>         <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>         >>? ? ? ? ? ? ? ? ?
>>         <https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>         <https://lists.jboss.org/mailman/listinfo/keycloak-dev>>>
>>         >>
>>         >>
>>         >>
>>         >> _______________________________________________
>>         >>? ? ? ? ? keycloak-dev mailing list
>>         >> keycloak-dev at lists.jboss.org
>>         <mailto:keycloak-dev at lists.jboss.org>
>>         <mailto:keycloak-dev at lists.jboss.org
>>         <mailto:keycloak-dev at lists.jboss.org>>
>>         >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>         <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>         >>? ? ? ? ?
>>         <https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>         <https://lists.jboss.org/mailman/listinfo/keycloak-dev>>
>>         >>
>>         >>
>>         >>
>>         >>
>>         > _______________________________________________
>>         > keycloak-dev mailing list
>>         > keycloak-dev at lists.jboss.org
>>         <mailto:keycloak-dev at lists.jboss.org>
>>         > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>         <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>
>>
>>         _______________________________________________
>>         keycloak-dev mailing list
>>         keycloak-dev at lists.jboss.org
>>         <mailto:keycloak-dev at lists.jboss.org>
>>         https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>         <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>
>>
>
>


From mposolda at redhat.com  Wed Apr 18 11:29:53 2018
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 18 Apr 2018 17:29:53 +0200
Subject: [keycloak-dev] ui_locales query parameter?
In-Reply-To: <b9ac3768-0095-9df8-57f4-bebabd6d01cb@redhat.com>
References: <9599201b-a4ef-d306-0c10-a244a89812c1@redhat.com>
	<CAJgngAeU_vro9weu5C_Rfx6Jc0Gu4M+a5yWE5VvQ0XCfGDZv5w@mail.gmail.com>
	<b0531f7e-5e69-4044-5ca3-caf6f219f013@redhat.com>
	<CAJgngAdM3FV_sWZ1_oDszLw+FmyAPQ0fJbq09tKeFugfe_nZkg@mail.gmail.com>
	<1a8d1f96-dee9-f9bf-ac1d-cc068d458a92@redhat.com>
	<05def24f-3d66-2798-ef14-c73b3949eb10@redhat.com>
	<CAJgngAfgCwoLm7f1BeWxTyrEr55VspssinNnRQ6DnCFMs9_JZA@mail.gmail.com>
	<0d704542-de4d-a07f-3b42-deaa8b22633b@redhat.com>
	<85f9a6da-023e-bc72-8897-35254dcfce25@redhat.com>
	<CAJgngAeShg4HZL5tTR-zvziKYeBU3-gQ3S4t+DU-_uwDKvO_4w@mail.gmail.com>
	<c78a0305-d893-7fd6-e14a-2445cc983238@redhat.com>
	<CAJgngAeSuTouzjuAqAS3mCrQMGt9on090qUe90qvA452PS72kQ@mail.gmail.com>
	<b9ac3768-0095-9df8-57f4-bebabd6d01cb@redhat.com>
Message-ID: <4f4e73b9-8d96-5233-8811-5c8795693bcc@redhat.com>

Fyi. I've created https://issues.jboss.org/browse/KEYCLOAK-7192 for the 
better support of "ui_locales" parameter. Probably not directly related 
to this, but I found that issue when looking at this (and specially at 
LocaleHelper class).

Marek

On 18/04/18 16:23, Stan Silvert wrote:
> On 4/18/2018 8:37 AM, Stian Thorgersen wrote:
>> Not sure it should be added directly to keycloak.js as it's not
>> strictly a supported param. Either you should just use it from
>> keycloak.js, but not make it a direct option, or we should add it as a
>> supported param. In the latter case we should probably document it.
> Yes, I'm proposing that we add it, support it, and document it.
>
> I don't know how I can use it without adding it as an option.
>> On 18 April 2018 at 14:19, Stan Silvert <ssilvert at redhat.com
>> <mailto:ssilvert at redhat.com>> wrote:
>>
>>      On 4/18/2018 7:46 AM, Stian Thorgersen wrote:
>>>      I don't think it has to be done the way I propose so I don't see
>>>      a strong need to change it. As long as it works with kc_locale
>>>      that's fine.
>>      OK.? I'll add the kc_locale param to keycloak.js. It might be
>>      useful for others as well.
>>
>>
>>>      On 18 April 2018 at 01:17, Stan Silvert <ssilvert at redhat.com
>>>      <mailto:ssilvert at redhat.com>> wrote:
>>>
>>>          On 4/17/2018 3:07 PM, Stan Silvert wrote:
>>>          > On 4/17/2018 1:59 PM, Stian Thorgersen wrote:
>>>          >> For the account management console I think the correct
>>>          approach is the
>>>          >> following:
>>>          >>
>>>          >> * Add an endpoint to account management service to allow
>>>          setting the
>>>          >> user locale which the account management should call - it
>>>          should not
>>>          >> re-direct to login back and do the whole login dance
>>>          >> * Change the way the account management console loads the
>>>          messages -
>>>          >> it should load using a rest endpoint, not by injecting
>>>          into the
>>>          >> index.ftl. That allows re-loading messages if the locale
>>>          is changed
>>>          >> without having to do the login dance
>>>          > What is it about the "login dance" that causes a problem?
>>>          It seems to
>>>          > do exactly what I need it to do, as long as I can pass in
>>>          kc_locale.
>>>          I was thinking that I actually need the redirect in order to
>>>          re-initialize the welcome screen's localized text.? The
>>>          welcome screen
>>>          uses FreeMarker for localization.? But you can't get back to
>>>          the welcome
>>>          screen without logging out, so logout's redirect would take
>>>          care of the
>>>          re-initialization of the welcome screen. Therefore, adding an
>>>          endpoint
>>>          and reloading the messages in Angular would work.
>>>
>>>          A new endpoint for this would:
>>>          * Set the cookie to the new locale
>>>          * Set the UserModel to the new locale
>>>          * Return the localized message bundle
>>>
>>>          Then I would have to refactor all the language handling on
>>>          the Angular
>>>          side.? It would all just take a bit of time to implement. But
>>>          if you
>>>          really think it has to be done that way we can do it.
>>>
>>>          >
>>>          >>
>>>          >>
>>>          >> On 17 April 2018 at 15:59, Marek Posolda
>>>          <mposolda at redhat.com <mailto:mposolda at redhat.com>
>>>          >> <mailto:mposolda at redhat.com <mailto:mposolda at redhat.com>>>
>>>          wrote:
>>>          >>
>>>          >>? ? ? On 17/04/18 15:00, Stan Silvert wrote:
>>>          >>
>>>          >>? ? ? ? ? On 4/16/2018 1:51 PM, Stian Thorgersen wrote:
>>>          >>
>>>          >>? ? ? ? ? ? ? kc_locale is only aimed at internal use. You
>>>          should use
>>>          >>? ? ? ? ? ? ? ui_locales
>>>          >>? ? ? ? ? ? ? that's the publicly available param.
>>>          >>
>>>          >>? ? ? ? ? The problem is that I need the server-side logic
>>>          associated with
>>>          >>? ? ? ? ? kc_locale.? kc_locale will update the cookie and
>>>          update the
>>>          >>? ? ? ? ? UserModel.
>>>          >>? ? ? ? ? ui_locales is just a pass-through back to the
>>>          application.
>>>          >>
>>>          >>? ? ? ? ? So we can either add kc_locale as a login param
>>>          in keycloak.js
>>>          >>? ? ? ? ? or we can
>>>          >>? ? ? ? ? add the server-side logic to ui_locales.? The
>>>          simplest is to
>>>          >>? ? ? ? ? do the
>>>          >>? ? ? ? ? former.? But perhaps we should have been doing
>>>          the latter all
>>>          >>? ? ? ? ? along?
>>>          >>
>>>          >>? ? ? IMO the ui_locales parameter shouldn't update the
>>>          UserModel. It's
>>>          >>? ? ? possible that there would be 2 different applications
>>>          and both of
>>>          >>? ? ? them will send different values of ui_locales
>>>          parameter. In that
>>>          >>? ? ? case, when user switch between application1 and
>>>          application2 (on
>>>          >>? ? ? each SSO login), there will be update to UserModel,
>>>          which is not
>>>          >>? ? ? good regarding performance IMO.
>>>          >>
>>>          >>? ? ? I can see in LocaleHelper.getUserLocale that the
>>>          order about how
>>>          >>? ? ? the locale is resolved is:
>>>          >>? ? ? 1. kc_locale parameter
>>>          >>? ? ? 2. KEYCLOAK_LOCALE cookie
>>>          >>? ? ? 3. UserModel attribute
>>>          >>? ? ? 4. ui_locales query parameter
>>>          >>? ? ? 5. Accept-Language header
>>>          >>
>>>          >>? ? ? Is this order proper or not? AFAIK the first 3 items
>>>          are used just
>>>          >>? ? ? if user explicitly selects the language on Keycloak
>>>          login screen
>>>          >>? ? ? (or account mgmt screen). If we put ui_locales up, we
>>>          will defacto
>>>          >>? ? ? give the control to application to override the
>>>          localization,
>>>          >>? ? ? which user explicitly chosen on login screen. Do we
>>>          want to do
>>>          >>? ? ? that? Is it good regarding usability? I think that
>>>          not, but maybe
>>>          >>? ? ? I am wrong...
>>>          >>
>>>          >>
>>>          >> I think the current order is correct.
>>>          >>
>>>          >> 1. Change locale if user has explicitly made the change -
>>>          kc_locale
>>>          >> should only be set when the user changes it manually
>>>          through login pages
>>>          >> 2-3 Tries to figure out the users last pick
>>>          >> 4. Provided by the application as a hint for what locale
>>>          the user may
>>>          >> want. It should not override the users explicitly set locale
>>>          >> 5. Accept-Language is supposed to give the users preferred
>>>          locale.
>>>          >> However, this is often wrong and just defaults to en.
>>>          Hence why it
>>>          >> comes last.
>>>          >>
>>>          >> There's been quite a lot of discussion to get this right
>>>          in the past,
>>>          >> so I'm quite confident that the current logic works and it
>>>          has been
>>>          >> confirmed by a surprising amount of folks. Well it was
>>>          tweaked quite a
>>>          >> few times based on user feedback.
>>>          >>
>>>          >>
>>>          >>? ? ? Marek
>>>          >>
>>>          >>
>>>          >>? ? ? ? ? ? ? On 16 April 2018 at 16:06, Stan Silvert
>>>          >>? ? ? ? ? ? ? <ssilvert at redhat.com
>>>          <mailto:ssilvert at redhat.com> <mailto:ssilvert at redhat.com
>>>          <mailto:ssilvert at redhat.com>>
>>>          >>? ? ? ? ? ? ? <mailto:ssilvert at redhat.com
>>>          <mailto:ssilvert at redhat.com> <mailto:ssilvert at redhat.com
>>>          <mailto:ssilvert at redhat.com>>>>
>>>          >>? ? ? ? ? ? ? wrote:
>>>          >>
>>>          >>? ? ? ? ? ? ? ? ? ?OK.
>>>          >>
>>>          >>? ? ? ? ? ? ? ? ? ?Does anyone object to adding kc_locale
>>>          to the login
>>>          >>? ? ? ? ? ? ? options on the
>>>          >>? ? ? ? ? ? ? ? ? ?keycloak.js adapter?
>>>          >>
>>>          >>
>>>          >>
>>>          >>? ? ? ? ? ? ? ? ? ?On 4/16/2018 2:45 AM, Stian Thorgersen
>>>          wrote:
>>>          >>
>>>          >>? ? ? ? ? ? ? ? ? ? ? ?It's a query param defined by OpenID
>>>          Connect. See
>>>          >> http://openid.net/specs/openid-connect-core-1_0.html
>>>          <http://openid.net/specs/openid-connect-core-1_0.html>
>>>          >>
>>>          <http://openid.net/specs/openid-connect-core-1_0.html
>>>          <http://openid.net/specs/openid-connect-core-1_0.html>>
>>>          >>
>>>          >>
>>>          ?<http://openid.net/specs/openid-connect-core-1_0.html
>>>          <http://openid.net/specs/openid-connect-core-1_0.html>
>>>          >>
>>>          <http://openid.net/specs/openid-connect-core-1_0.html
>>>          <http://openid.net/specs/openid-connect-core-1_0.html>>>.
>>>          >>? ? ? ? ? ? ? ? ? It allows
>>>          >>? ? ? ? ? ? ? ? ? ? ? ?the application to pass a list of
>>>          req locales in
>>>          >>? ? ? ? ? ? ? ? ? case the
>>>          >>? ? ? ? ? ? ? ? ? ? ? ?application knows it.
>>>          >>
>>>          >>? ? ? ? ? ? ? ? ? ? ? ?When doing the redirect login flow the
>>>          >>? ? ? ? ? ? ? ? ? applications should use
>>>          >>? ? ? ? ? ? ? ? ? ? ? ?ui_locales. kc_locale is an internal
>>>          param and
>>>          >>? ? ? ? ? ? ? ? ? should really only
>>>          >>? ? ? ? ? ? ? ? ? ? ? ?be used by the locale switcher on
>>>          the login screen.
>>>          >>
>>>          >>? ? ? ? ? ? ? ? ? ? ? ?On 16 April 2018 at 02:44, Stan Silvert
>>>          >>? ? ? ? ? ? ? ? ? <ssilvert at redhat.com
>>>          <mailto:ssilvert at redhat.com> <mailto:ssilvert at redhat.com
>>>          <mailto:ssilvert at redhat.com>>
>>>          >> ?<mailto:ssilvert at redhat.com <mailto:ssilvert at redhat.com>
>>>          >>? ? ? ? ? ? ? ? ? <mailto:ssilvert at redhat.com <mailto:ssilvert at redhat.com>>>> wrote:
>>>          >>
>>>          >>? ? ? ? ? ? ? ? ? ? ? ? ? ?Does anyone know what ui_locales
>>>          is actually
>>>          >>? ? ? ? ? ? ? ? ? used for?
>>>          >>
>>>          >>? ? ? ? ? ? ? ? ? ? ? ? ? ?I can't find usages except for
>>>          in the testsuite.
>>>          >>
>>>          >>? ? ? ? ? ? ? ? ? ? ? ? ? ?The query param used to change
>>>          locale is
>>>          >>? ? ? ? ? ? ? ? ? kc_locale.? Should
>>>          >> ?ui_locales
>>>          >> ?deprecated?
>>>          >>
>>>          >>? ? ? ? ? ? ? ? ? ? ? ? ? ?Stan
>>>          >>
>>>          >> ?_______________________________________________
>>>          >> ?keycloak-dev mailing list
>>>          >> keycloak-dev at lists.jboss.org
>>>          <mailto:keycloak-dev at lists.jboss.org>
>>>          >>? ? ? ? ? ? ? ? ? <mailto:keycloak-dev at lists.jboss.org
>>>          <mailto:keycloak-dev at lists.jboss.org>>
>>>          >> ?<mailto:keycloak-dev at lists.jboss.org
>>>          <mailto:keycloak-dev at lists.jboss.org>
>>>          >>? ? ? ? ? ? ? ? ? <mailto:keycloak-dev at lists.jboss.org
>>>          <mailto:keycloak-dev at lists.jboss.org>>>
>>>          >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>          <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>>          >>
>>>          <https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>          <https://lists.jboss.org/mailman/listinfo/keycloak-dev>>
>>>          >>
>>>          >>
>>>          ?<https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>          <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>>          >>
>>>          <https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>          <https://lists.jboss.org/mailman/listinfo/keycloak-dev>>>
>>>          >>
>>>          >>
>>>          >>
>>>          >> _______________________________________________
>>>          >>? ? ? ? ? keycloak-dev mailing list
>>>          >> keycloak-dev at lists.jboss.org
>>>          <mailto:keycloak-dev at lists.jboss.org>
>>>          <mailto:keycloak-dev at lists.jboss.org
>>>          <mailto:keycloak-dev at lists.jboss.org>>
>>>          >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>          <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>>          >>
>>>          <https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>          <https://lists.jboss.org/mailman/listinfo/keycloak-dev>>
>>>          >>
>>>          >>
>>>          >>
>>>          >>
>>>          > _______________________________________________
>>>          > keycloak-dev mailing list
>>>          > keycloak-dev at lists.jboss.org
>>>          <mailto:keycloak-dev at lists.jboss.org>
>>>          > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>          <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>>
>>>
>>>          _______________________________________________
>>>          keycloak-dev mailing list
>>>          keycloak-dev at lists.jboss.org
>>>          <mailto:keycloak-dev at lists.jboss.org>
>>>          https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>          <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>>
>>>
>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



From christian.beikov at gmail.com  Wed Apr 18 11:35:14 2018
From: christian.beikov at gmail.com (Christian Beikov)
Date: Wed, 18 Apr 2018 17:35:14 +0200
Subject: [keycloak-dev] Application and server in separate networks
In-Reply-To: <CAK-7U1gGFnwc3EcgL3whgdGbSTH9xSVwVSHxc1i+JtetJ83H4g@mail.gmail.com>
References: <41e1a805-cc38-50cf-f794-cda6afd49313@gmail.com>
	<CAK-7U1gGFnwc3EcgL3whgdGbSTH9xSVwVSHxc1i+JtetJ83H4g@mail.gmail.com>
Message-ID: <24a0f868-9726-4024-6254-9a0b68b29c9f@gmail.com>

Is there any way to avoid the access code to access token exchange? 
Since the Keycloak server is not accessible, I'm getting an error during 
authentication:

 ?ERROR [org.keycloak.adapters.OAuthRequestAuthenticator] (default 
task-54) failed to turn code into token: java.net.UnknownHostException: 
blabla.local: unknown error
 ??????? ...
 ??????? at 
org.keycloak.adapters.ServerRequest.invokeAccessCodeToToken(ServerRequest.java:111)
 ??????? at 
org.keycloak.adapters.OAuthRequestAuthenticator.resolveCode(OAuthRequestAuthenticator.java:330)
 ??????? at 
org.keycloak.adapters.OAuthRequestAuthenticator.authenticate(OAuthRequestAuthenticator.java:275)
 ??????? at 
org.keycloak.adapters.RequestAuthenticator.authenticate(RequestAuthenticator.java:139)
 ??????? at 
org.keycloak.adapters.undertow.AbstractUndertowKeycloakAuthMech.keycloakAuthenticate(AbstractUndertowKeycloakAuthMech.java:110)
 ??????? at 
org.keycloak.adapters.undertow.ServletKeycloakAuthMech.authenticate(ServletKeycloakAuthMech.java:92)
 ??????? ...


Mit freundlichen Gr??en,
------------------------------------------------------------------------
*Christian Beikov*
Am 18.04.2018 um 14:48 schrieb Thomas Darimont:
> Hello Christian,
>
> your application server needs to communicate with the Keycloak server 
> to retrieve the realm public key referenced in the token to verify the 
> token signature.
> The current implementation in Keycloak fetches & caches unknown public 
> keys automatically.
>
> You could also use a fixed realm public key on the application server 
> side but it would not support key rotation anymore.
>
> Cheers,
> Thomas
>
> 2018-04-18 13:45 GMT+02:00 Christian Beikov 
> <christian.beikov at gmail.com <mailto:christian.beikov at gmail.com>>:
>
>     Hi,
>
>     is it necessary that an application secured by Keycloak can access
>     the
>     Keycloak server? Or is it enough if the Browser can access the
>     Keycloak
>     server?
>
>     -- 
>
>     Mit freundlichen Gr??en,
>     ------------------------------------------------------------------------
>     *Christian Beikov*
>     _______________________________________________
>     keycloak-dev mailing list
>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>     <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>
>


From christian.beikov at gmail.com  Wed Apr 18 12:16:47 2018
From: christian.beikov at gmail.com (Christian Beikov)
Date: Wed, 18 Apr 2018 18:16:47 +0200
Subject: [keycloak-dev] Application and server in separate networks
In-Reply-To: <24a0f868-9726-4024-6254-9a0b68b29c9f@gmail.com>
References: <41e1a805-cc38-50cf-f794-cda6afd49313@gmail.com>
	<CAK-7U1gGFnwc3EcgL3whgdGbSTH9xSVwVSHxc1i+JtetJ83H4g@mail.gmail.com>
	<24a0f868-9726-4024-6254-9a0b68b29c9f@gmail.com>
Message-ID: <569a7f4e-2fa6-6590-2dfb-d7a57c137db2@gmail.com>

As far as I see in the code, the Java Adapters always use the standard 
flow i.e. response_type=code

Please tell me this observation is wrong and there is an undocumented 
setting I just didn't see that I can use to tell the adapter to use the 
implicit flow instead :|

If this is really missing, where would you suggest this should be 
configured? I'd expect the setting to be in KeycloakDeployment and 
OAuthRequestAuthenticator#loginRedirect would then use the value instead 
of always using the "code" value.


Mit freundlichen Gr??en,
------------------------------------------------------------------------
*Christian Beikov*
Am 18.04.2018 um 17:35 schrieb Christian Beikov:
>
> Is there any way to avoid the access code to access token exchange? 
> Since the Keycloak server is not accessible, I'm getting an error 
> during authentication:
>
> ?ERROR [org.keycloak.adapters.OAuthRequestAuthenticator] (default 
> task-54) failed to turn code into token: 
> java.net.UnknownHostException: blabla.local: unknown error
> ??????? ...
> ??????? at 
> org.keycloak.adapters.ServerRequest.invokeAccessCodeToToken(ServerRequest.java:111)
> ??????? at 
> org.keycloak.adapters.OAuthRequestAuthenticator.resolveCode(OAuthRequestAuthenticator.java:330)
> ??????? at 
> org.keycloak.adapters.OAuthRequestAuthenticator.authenticate(OAuthRequestAuthenticator.java:275)
> ??????? at 
> org.keycloak.adapters.RequestAuthenticator.authenticate(RequestAuthenticator.java:139)
> ??????? at 
> org.keycloak.adapters.undertow.AbstractUndertowKeycloakAuthMech.keycloakAuthenticate(AbstractUndertowKeycloakAuthMech.java:110)
> ??????? at 
> org.keycloak.adapters.undertow.ServletKeycloakAuthMech.authenticate(ServletKeycloakAuthMech.java:92)
> ??????? ...
>
>
> Mit freundlichen Gr??en,
> ------------------------------------------------------------------------
> *Christian Beikov*
> Am 18.04.2018 um 14:48 schrieb Thomas Darimont:
>> Hello Christian,
>>
>> your application server needs to communicate with the Keycloak server 
>> to retrieve the realm public key referenced in the token to verify 
>> the token signature.
>> The current implementation in Keycloak fetches & caches unknown 
>> public keys automatically.
>>
>> You could also use a fixed realm public key on the application server 
>> side but it would not support key rotation anymore.
>>
>> Cheers,
>> Thomas
>>
>> 2018-04-18 13:45 GMT+02:00 Christian Beikov 
>> <christian.beikov at gmail.com <mailto:christian.beikov at gmail.com>>:
>>
>>     Hi,
>>
>>     is it necessary that an application secured by Keycloak can
>>     access the
>>     Keycloak server? Or is it enough if the Browser can access the
>>     Keycloak
>>     server?
>>
>>     -- 
>>
>>     Mit freundlichen Gr??en,
>>     ------------------------------------------------------------------------
>>     *Christian Beikov*
>>     _______________________________________________
>>     keycloak-dev mailing list
>>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>     <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>
>>
>


From sthorger at redhat.com  Thu Apr 19 05:50:30 2018
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 19 Apr 2018 11:50:30 +0200
Subject: [keycloak-dev] Keycloak Questionnaire
Message-ID: <CAJgngAeZYwBiVyRrZ9OpEaxWR+Y7oaJF=QfOjFUPQx=N7VXrtA@mail.gmail.com>

We would love to gather some information on who is using Keycloak and how
it is being used. With that intent we have created a form here
https://goo.gl/forms/TRSmCCU6eX25prhH2

I would greatly appreciate if as many as possible can fill this in.

Thanks,
Stian Thorgersen
Keycloak Project Lead

From umer at codexnow.com  Thu Apr 19 09:07:45 2018
From: umer at codexnow.com (Hafiz Syed Umer Ahmed)
Date: Thu, 19 Apr 2018 18:07:45 +0500
Subject: [keycloak-dev] keycloak-dev Digest, Vol 58, Issue 16
In-Reply-To: <mailman.100092.1524055082.4745.keycloak-dev@lists.jboss.org>
References: <mailman.100092.1524055082.4745.keycloak-dev@lists.jboss.org>
Message-ID: <CABfG-uYSf6e07Wyvi7tDNiLt5zECSkAV=udCtp3S7zE81veTCw@mail.gmail.com>

Hi,

I am using keycloak 3.4.1 final on docker with PostgreSQL. I have written a
spring boot application using keycloak admin client. The problem i am
facing is that when i make several request on a particular api for example
creating a user in keycloak it gets halt and does not respond.
For example : Create user api
after 10 successful request it does not process the 11th request and
postman or restlet client shows "sending request" . After halting state it
does not process any other api request until and unless i restart my spring
boot application. I am not getting what is the issue. I have checked all
the credentials and my application settings as well. Is there any rate
limit on api calling in keycloak or there is some other issue ??

Regards

Umer

On Wed, Apr 18, 2018 at 5:38 PM, <keycloak-dev-request at lists.jboss.org>
wrote:

> Send keycloak-dev mailing list submissions to
>         keycloak-dev at lists.jboss.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.jboss.org/mailman/listinfo/keycloak-dev
> or, via email, send a message with subject or body 'help' to
>         keycloak-dev-request at lists.jboss.org
>
> You can reach the person managing the list at
>         keycloak-dev-owner at lists.jboss.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of keycloak-dev digest..."
>
>
> Today's Topics:
>
>    1. Application and server in separate networks (Christian Beikov)
>    2. Re: ui_locales query parameter? (Stian Thorgersen)
>    3. Re: ui_locales query parameter? (Stan Silvert)
>    4. Re: ui_locales query parameter? (Stian Thorgersen)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 18 Apr 2018 13:45:06 +0200
> From: Christian Beikov <christian.beikov at gmail.com>
> Subject: [keycloak-dev] Application and server in separate networks
> To: keycloak-dev <keycloak-dev at lists.jboss.org>
> Message-ID: <41e1a805-cc38-50cf-f794-cda6afd49313 at gmail.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> Hi,
>
> is it necessary that an application secured by Keycloak can access the
> Keycloak server? Or is it enough if the Browser can access the Keycloak
> server?
>
> --
>
> Mit freundlichen Gr??en,
> ------------------------------------------------------------------------
> *Christian Beikov*
>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 18 Apr 2018 13:46:25 +0200
> From: Stian Thorgersen <sthorger at redhat.com>
> Subject: Re: [keycloak-dev] ui_locales query parameter?
> To: Stan Silvert <ssilvert at redhat.com>
> Cc: keycloak-dev <keycloak-dev at lists.jboss.org>
> Message-ID:
>         <CAJgngAeShg4HZL5tTR-zvziKYeBU3-gQ3S4t+DU-_uwDKvO_
> 4w at mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> I don't think it has to be done the way I propose so I don't see a strong
> need to change it. As long as it works with kc_locale that's fine.
>
> On 18 April 2018 at 01:17, Stan Silvert <ssilvert at redhat.com> wrote:
>
> > On 4/17/2018 3:07 PM, Stan Silvert wrote:
> > > On 4/17/2018 1:59 PM, Stian Thorgersen wrote:
> > >> For the account management console I think the correct approach is the
> > >> following:
> > >>
> > >> * Add an endpoint to account management service to allow setting the
> > >> user locale which the account management should call - it should not
> > >> re-direct to login back and do the whole login dance
> > >> * Change the way the account management console loads the messages -
> > >> it should load using a rest endpoint, not by injecting into the
> > >> index.ftl. That allows re-loading messages if the locale is changed
> > >> without having to do the login dance
> > > What is it about the "login dance" that causes a problem?  It seems to
> > > do exactly what I need it to do, as long as I can pass in kc_locale.
> > I was thinking that I actually need the redirect in order to
> > re-initialize the welcome screen's localized text.  The welcome screen
> > uses FreeMarker for localization.  But you can't get back to the welcome
> > screen without logging out, so logout's redirect would take care of the
> > re-initialization of the welcome screen. Therefore, adding an endpoint
> > and reloading the messages in Angular would work.
> >
> > A new endpoint for this would:
> > * Set the cookie to the new locale
> > * Set the UserModel to the new locale
> > * Return the localized message bundle
> >
> > Then I would have to refactor all the language handling on the Angular
> > side.  It would all just take a bit of time to implement. But if you
> > really think it has to be done that way we can do it.
> >
> > >
> > >>
> > >>
> > >> On 17 April 2018 at 15:59, Marek Posolda <mposolda at redhat.com
> > >> <mailto:mposolda at redhat.com>> wrote:
> > >>
> > >>      On 17/04/18 15:00, Stan Silvert wrote:
> > >>
> > >>          On 4/16/2018 1:51 PM, Stian Thorgersen wrote:
> > >>
> > >>              kc_locale is only aimed at internal use. You should use
> > >>              ui_locales
> > >>              that's the publicly available param.
> > >>
> > >>          The problem is that I need the server-side logic associated
> > with
> > >>          kc_locale.  kc_locale will update the cookie and update the
> > >>          UserModel.
> > >>          ui_locales is just a pass-through back to the application.
> > >>
> > >>          So we can either add kc_locale as a login param in
> keycloak.js
> > >>          or we can
> > >>          add the server-side logic to ui_locales.  The simplest is to
> > >>          do the
> > >>          former.  But perhaps we should have been doing the latter all
> > >>          along?
> > >>
> > >>      IMO the ui_locales parameter shouldn't update the UserModel. It's
> > >>      possible that there would be 2 different applications and both of
> > >>      them will send different values of ui_locales parameter. In that
> > >>      case, when user switch between application1 and application2 (on
> > >>      each SSO login), there will be update to UserModel, which is not
> > >>      good regarding performance IMO.
> > >>
> > >>      I can see in LocaleHelper.getUserLocale that the order about how
> > >>      the locale is resolved is:
> > >>      1. kc_locale parameter
> > >>      2. KEYCLOAK_LOCALE cookie
> > >>      3. UserModel attribute
> > >>      4. ui_locales query parameter
> > >>      5. Accept-Language header
> > >>
> > >>      Is this order proper or not? AFAIK the first 3 items are used
> just
> > >>      if user explicitly selects the language on Keycloak login screen
> > >>      (or account mgmt screen). If we put ui_locales up, we will
> defacto
> > >>      give the control to application to override the localization,
> > >>      which user explicitly chosen on login screen. Do we want to do
> > >>      that? Is it good regarding usability? I think that not, but maybe
> > >>      I am wrong...
> > >>
> > >>
> > >> I think the current order is correct.
> > >>
> > >> 1. Change locale if user has explicitly made the change - kc_locale
> > >> should only be set when the user changes it manually through login
> pages
> > >> 2-3 Tries to figure out the users last pick
> > >> 4. Provided by the application as a hint for what locale the user may
> > >> want. It should not override the users explicitly set locale
> > >> 5. Accept-Language is supposed to give the users preferred locale.
> > >> However, this is often wrong and just defaults to en. Hence why it
> > >> comes last.
> > >>
> > >> There's been quite a lot of discussion to get this right in the past,
> > >> so I'm quite confident that the current logic works and it has been
> > >> confirmed by a surprising amount of folks. Well it was tweaked quite a
> > >> few times based on user feedback.
> > >>
> > >>
> > >>      Marek
> > >>
> > >>
> > >>              On 16 April 2018 at 16:06, Stan Silvert
> > >>              <ssilvert at redhat.com <mailto:ssilvert at redhat.com>
> > >>              <mailto:ssilvert at redhat.com <mailto:ssilvert at redhat.com
> >>>
> > >>              wrote:
> > >>
> > >>                   OK.
> > >>
> > >>                   Does anyone object to adding kc_locale to the login
> > >>              options on the
> > >>                   keycloak.js adapter?
> > >>
> > >>
> > >>
> > >>                   On 4/16/2018 2:45 AM, Stian Thorgersen wrote:
> > >>
> > >>                       It's a query param defined by OpenID Connect.
> See
> > >>                  http://openid.net/specs/openid-connect-core-1_0.html
> > >>                  <http://openid.net/specs/
> openid-connect-core-1_0.html>
> > >>
> > >>                   <http://openid.net/specs/
> openid-connect-core-1_0.html
> > >>                  <http://openid.net/specs/
> openid-connect-core-1_0.html
> > >>.
> > >>                  It allows
> > >>                       the application to pass a list of req locales in
> > >>                  case the
> > >>                       application knows it.
> > >>
> > >>                       When doing the redirect login flow the
> > >>                  applications should use
> > >>                       ui_locales. kc_locale is an internal param and
> > >>                  should really only
> > >>                       be used by the locale switcher on the login
> > screen.
> > >>
> > >>                       On 16 April 2018 at 02:44, Stan Silvert
> > >>                  <ssilvert at redhat.com <mailto:ssilvert at redhat.com>
> > >>                       <mailto:ssilvert at redhat.com
> > >>                  <mailto:ssilvert at redhat.com>>> wrote:
> > >>
> > >>                           Does anyone know what ui_locales is actually
> > >>                  used for?
> > >>
> > >>                           I can't find usages except for in the
> > testsuite.
> > >>
> > >>                           The query param used to change locale is
> > >>                  kc_locale.  Should
> > >>                           ui_locales
> > >>                           deprecated?
> > >>
> > >>                           Stan
> > >>
> > >>                           _____________________________
> > __________________
> > >>                           keycloak-dev mailing list
> > >>                  keycloak-dev at lists.jboss.org
> > >>                  <mailto:keycloak-dev at lists.jboss.org>
> > >>                           <mailto:keycloak-dev at lists.jboss.org
> > >>                  <mailto:keycloak-dev at lists.jboss.org>>
> > >>                  https://lists.jboss.org/
> mailman/listinfo/keycloak-dev
> > >>                  <https://lists.jboss.org/
> mailman/listinfo/keycloak-dev
> > >
> > >>
> > >>                   <https://lists.jboss.org/
> > mailman/listinfo/keycloak-dev
> > >>                  <https://lists.jboss.org/
> mailman/listinfo/keycloak-dev
> > >>
> > >>
> > >>
> > >>
> > >>          _______________________________________________
> > >>          keycloak-dev mailing list
> > >>          keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.
> > jboss.org>
> > >>          https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > >>          <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
> > >>
> > >>
> > >>
> > >>
> > > _______________________________________________
> > > keycloak-dev mailing list
> > > keycloak-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> >
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
>
>
> ------------------------------
>
> Message: 3
> Date: Wed, 18 Apr 2018 08:19:58 -0400
> From: Stan Silvert <ssilvert at redhat.com>
> Subject: Re: [keycloak-dev] ui_locales query parameter?
> To: stian at redhat.com
> Cc: keycloak-dev <keycloak-dev at lists.jboss.org>
> Message-ID: <c78a0305-d893-7fd6-e14a-2445cc983238 at redhat.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> On 4/18/2018 7:46 AM, Stian Thorgersen wrote:
> > I don't think it has to be done the way I propose so I don't see a
> > strong need to change it. As long as it works with kc_locale that's fine.
> OK.? I'll add the kc_locale param to keycloak.js.? It might be useful
> for others as well.
>
> >
> > On 18 April 2018 at 01:17, Stan Silvert <ssilvert at redhat.com
> > <mailto:ssilvert at redhat.com>> wrote:
> >
> >     On 4/17/2018 3:07 PM, Stan Silvert wrote:
> >     > On 4/17/2018 1:59 PM, Stian Thorgersen wrote:
> >     >> For the account management console I think the correct approach
> >     is the
> >     >> following:
> >     >>
> >     >> * Add an endpoint to account management service to allow
> >     setting the
> >     >> user locale which the account management should call - it
> >     should not
> >     >> re-direct to login back and do the whole login dance
> >     >> * Change the way the account management console loads the
> >     messages -
> >     >> it should load using a rest endpoint, not by injecting into the
> >     >> index.ftl. That allows re-loading messages if the locale is
> changed
> >     >> without having to do the login dance
> >     > What is it about the "login dance" that causes a problem?? It
> >     seems to
> >     > do exactly what I need it to do, as long as I can pass in
> kc_locale.
> >     I was thinking that I actually need the redirect in order to
> >     re-initialize the welcome screen's localized text.? The welcome
> >     screen
> >     uses FreeMarker for localization.? But you can't get back to the
> >     welcome
> >     screen without logging out, so logout's redirect would take care
> >     of the
> >     re-initialization of the welcome screen. Therefore, adding an
> >     endpoint
> >     and reloading the messages in Angular would work.
> >
> >     A new endpoint for this would:
> >     * Set the cookie to the new locale
> >     * Set the UserModel to the new locale
> >     * Return the localized message bundle
> >
> >     Then I would have to refactor all the language handling on the
> >     Angular
> >     side.? It would all just take a bit of time to implement. But if you
> >     really think it has to be done that way we can do it.
> >
> >     >
> >     >>
> >     >>
> >     >> On 17 April 2018 at 15:59, Marek Posolda <mposolda at redhat.com
> >     <mailto:mposolda at redhat.com>
> >     >> <mailto:mposolda at redhat.com <mailto:mposolda at redhat.com>>> wrote:
> >     >>
> >     >>? ? ? On 17/04/18 15:00, Stan Silvert wrote:
> >     >>
> >     >>? ? ? ? ? On 4/16/2018 1:51 PM, Stian Thorgersen wrote:
> >     >>
> >     >>? ? ? ? ? ? ? kc_locale is only aimed at internal use. You
> >     should use
> >     >>? ? ? ? ? ? ? ui_locales
> >     >>? ? ? ? ? ? ? that's the publicly available param.
> >     >>
> >     >>? ? ? ? ? The problem is that I need the server-side logic
> >     associated with
> >     >>? ? ? ? ? kc_locale.? kc_locale will update the cookie and
> >     update the
> >     >>? ? ? ? ? UserModel.
> >     >>? ? ? ? ? ui_locales is just a pass-through back to the
> application.
> >     >>
> >     >>? ? ? ? ? So we can either add kc_locale as a login param in
> >     keycloak.js
> >     >>? ? ? ? ? or we can
> >     >>? ? ? ? ? add the server-side logic to ui_locales.? The simplest
> >     is to
> >     >>? ? ? ? ? do the
> >     >>? ? ? ? ? former.? But perhaps we should have been doing the
> >     latter all
> >     >>? ? ? ? ? along?
> >     >>
> >     >>? ? ? IMO the ui_locales parameter shouldn't update the
> >     UserModel. It's
> >     >>? ? ? possible that there would be 2 different applications and
> >     both of
> >     >>? ? ? them will send different values of ui_locales parameter.
> >     In that
> >     >>? ? ? case, when user switch between application1 and
> >     application2 (on
> >     >>? ? ? each SSO login), there will be update to UserModel, which
> >     is not
> >     >>? ? ? good regarding performance IMO.
> >     >>
> >     >>? ? ? I can see in LocaleHelper.getUserLocale that the order
> >     about how
> >     >>? ? ? the locale is resolved is:
> >     >>? ? ? 1. kc_locale parameter
> >     >>? ? ? 2. KEYCLOAK_LOCALE cookie
> >     >>? ? ? 3. UserModel attribute
> >     >>? ? ? 4. ui_locales query parameter
> >     >>? ? ? 5. Accept-Language header
> >     >>
> >     >>? ? ? Is this order proper or not? AFAIK the first 3 items are
> >     used just
> >     >>? ? ? if user explicitly selects the language on Keycloak login
> >     screen
> >     >>? ? ? (or account mgmt screen). If we put ui_locales up, we will
> >     defacto
> >     >>? ? ? give the control to application to override the localization,
> >     >>? ? ? which user explicitly chosen on login screen. Do we want to
> do
> >     >>? ? ? that? Is it good regarding usability? I think that not,
> >     but maybe
> >     >>? ? ? I am wrong...
> >     >>
> >     >>
> >     >> I think the current order is correct.
> >     >>
> >     >> 1. Change locale if user has explicitly made the change -
> kc_locale
> >     >> should only be set when the user changes it manually through
> >     login pages
> >     >> 2-3 Tries to figure out the users last pick
> >     >> 4. Provided by the application as a hint for what locale the
> >     user may
> >     >> want. It should not override the users explicitly set locale
> >     >> 5. Accept-Language is supposed to give the users preferred locale.
> >     >> However, this is often wrong and just defaults to en. Hence why it
> >     >> comes last.
> >     >>
> >     >> There's been quite a lot of discussion to get this right in the
> >     past,
> >     >> so I'm quite confident that the current logic works and it has
> been
> >     >> confirmed by a surprising amount of folks. Well it was tweaked
> >     quite a
> >     >> few times based on user feedback.
> >     >>
> >     >>
> >     >>? ? ? Marek
> >     >>
> >     >>
> >     >>? ? ? ? ? ? ? On 16 April 2018 at 16:06, Stan Silvert
> >     >>? ? ? ? ? ? ? <ssilvert at redhat.com <mailto:ssilvert at redhat.com>
> >     <mailto:ssilvert at redhat.com <mailto:ssilvert at redhat.com>>
> >     >>? ? ? ? ? ? ? <mailto:ssilvert at redhat.com
> >     <mailto:ssilvert at redhat.com> <mailto:ssilvert at redhat.com
> >     <mailto:ssilvert at redhat.com>>>>
> >     >>? ? ? ? ? ? ? wrote:
> >     >>
> >     >>? ? ? ? ? ? ? ? ? ?OK.
> >     >>
> >     >>? ? ? ? ? ? ? ? ? ?Does anyone object to adding kc_locale to the
> >     login
> >     >>? ? ? ? ? ? ? options on the
> >     >>? ? ? ? ? ? ? ? ? ?keycloak.js adapter?
> >     >>
> >     >>
> >     >>
> >     >>? ? ? ? ? ? ? ? ? ?On 4/16/2018 2:45 AM, Stian Thorgersen wrote:
> >     >>
> >     >>? ? ? ? ? ? ? ? ? ? ? ?It's a query param defined by OpenID
> >     Connect. See
> >     >> http://openid.net/specs/openid-connect-core-1_0.html
> >     <http://openid.net/specs/openid-connect-core-1_0.html>
> >     >>? ? ? ? ? ? ? ? ?
> >     <http://openid.net/specs/openid-connect-core-1_0.html
> >     <http://openid.net/specs/openid-connect-core-1_0.html>>
> >     >>
> >     >>? ? ? ? ? ? ? ? ?
> >     ?<http://openid.net/specs/openid-connect-core-1_0.html
> >     <http://openid.net/specs/openid-connect-core-1_0.html>
> >     >>? ? ? ? ? ? ? ? ?
> >     <http://openid.net/specs/openid-connect-core-1_0.html
> >     <http://openid.net/specs/openid-connect-core-1_0.html>>>.
> >     >>? ? ? ? ? ? ? ? ? It allows
> >     >>? ? ? ? ? ? ? ? ? ? ? ?the application to pass a list of req
> >     locales in
> >     >>? ? ? ? ? ? ? ? ? case the
> >     >>? ? ? ? ? ? ? ? ? ? ? ?application knows it.
> >     >>
> >     >>? ? ? ? ? ? ? ? ? ? ? ?When doing the redirect login flow the
> >     >>? ? ? ? ? ? ? ? ? applications should use
> >     >>? ? ? ? ? ? ? ? ? ? ? ?ui_locales. kc_locale is an internal
> >     param and
> >     >>? ? ? ? ? ? ? ? ? should really only
> >     >>? ? ? ? ? ? ? ? ? ? ? ?be used by the locale switcher on the
> >     login screen.
> >     >>
> >     >>? ? ? ? ? ? ? ? ? ? ? ?On 16 April 2018 at 02:44, Stan Silvert
> >     >>? ? ? ? ? ? ? ? ? <ssilvert at redhat.com
> >     <mailto:ssilvert at redhat.com> <mailto:ssilvert at redhat.com
> >     <mailto:ssilvert at redhat.com>>
> >     >>? ? ? ? ? ? ? ? ? ? ? ?<mailto:ssilvert at redhat.com
> >     <mailto:ssilvert at redhat.com>
> >     >>? ? ? ? ? ? ? ? ? <mailto:ssilvert at redhat.com <mailto:
> ssilvert at redhat.com>>>> wrote:
> >     >>
> >     >>? ? ? ? ? ? ? ? ? ? ? ? ? ?Does anyone know what ui_locales is
> >     actually
> >     >>? ? ? ? ? ? ? ? ? used for?
> >     >>
> >     >>? ? ? ? ? ? ? ? ? ? ? ? ? ?I can't find usages except for in the
> >     testsuite.
> >     >>
> >     >>? ? ? ? ? ? ? ? ? ? ? ? ? ?The query param used to change locale is
> >     >>? ? ? ? ? ? ? ? ? kc_locale.? Should
> >     >>? ? ? ? ? ? ? ? ? ? ? ? ? ?ui_locales
> >     >>? ? ? ? ? ? ? ? ? ? ? ? ? ?deprecated?
> >     >>
> >     >>? ? ? ? ? ? ? ? ? ? ? ? ? ?Stan
> >     >>
> >     >> ?_______________________________________________
> >     >>? ? ? ? ? ? ? ? ? ? ? ? ? ?keycloak-dev mailing list
> >     >> keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org
> >
> >     >>? ? ? ? ? ? ? ? ? <mailto:keycloak-dev at lists.jboss.org
> >     <mailto:keycloak-dev at lists.jboss.org>>
> >     >>? ? ? ? ? ? ? ? ? ? ? ? ? ?<mailto:keycloak-dev at lists.jboss.org
> >     <mailto:keycloak-dev at lists.jboss.org>
> >     >>? ? ? ? ? ? ? ? ? <mailto:keycloak-dev at lists.jboss.org <mailto:
> keycloak-dev at lists.jboss.org>>>
> >     >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >     <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
> >     >>? ? ? ? ? ? ? ? ?
> >     <https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >     <https://lists.jboss.org/mailman/listinfo/keycloak-dev>>
> >     >>
> >     >>? ? ? ? ? ? ? ? ?
> >     ?<https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >     <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
> >     >>? ? ? ? ? ? ? ? ?
> >     <https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >     <https://lists.jboss.org/mailman/listinfo/keycloak-dev>>>
> >     >>
> >     >>
> >     >>
> >     >>? ? ? ? ? _______________________________________________
> >     >>? ? ? ? ? keycloak-dev mailing list
> >     >> keycloak-dev at lists.jboss.org
> >     <mailto:keycloak-dev at lists.jboss.org>
> >     <mailto:keycloak-dev at lists.jboss.org
> >     <mailto:keycloak-dev at lists.jboss.org>>
> >     >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >     <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
> >     >>? ? ? ? ? <https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >     <https://lists.jboss.org/mailman/listinfo/keycloak-dev>>
> >     >>
> >     >>
> >     >>
> >     >>
> >     > _______________________________________________
> >     > keycloak-dev mailing list
> >     > keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
> >     > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >     <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
> >
> >
> >     _______________________________________________
> >     keycloak-dev mailing list
> >     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
> >     https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >     <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
> >
> >
>
>
>
> ------------------------------
>
> Message: 4
> Date: Wed, 18 Apr 2018 14:37:41 +0200
> From: Stian Thorgersen <sthorger at redhat.com>
> Subject: Re: [keycloak-dev] ui_locales query parameter?
> To: Stan Silvert <ssilvert at redhat.com>
> Cc: keycloak-dev <keycloak-dev at lists.jboss.org>
> Message-ID:
>         <CAJgngAeSuTouzjuAqAS3mCrQMGt9on090qUe90qvA452PS72kQ at mail.
> gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> Not sure it should be added directly to keycloak.js as it's not strictly a
> supported param. Either you should just use it from keycloak.js, but not
> make it a direct option, or we should add it as a supported param. In the
> latter case we should probably document it.
>
> On 18 April 2018 at 14:19, Stan Silvert <ssilvert at redhat.com> wrote:
>
> > On 4/18/2018 7:46 AM, Stian Thorgersen wrote:
> >
> > I don't think it has to be done the way I propose so I don't see a strong
> > need to change it. As long as it works with kc_locale that's fine.
> >
> > OK.  I'll add the kc_locale param to keycloak.js.  It might be useful for
> > others as well.
> >
> >
> >
> > On 18 April 2018 at 01:17, Stan Silvert <ssilvert at redhat.com> wrote:
> >
> >> On 4/17/2018 3:07 PM, Stan Silvert wrote:
> >> > On 4/17/2018 1:59 PM, Stian Thorgersen wrote:
> >> >> For the account management console I think the correct approach is
> the
> >> >> following:
> >> >>
> >> >> * Add an endpoint to account management service to allow setting the
> >> >> user locale which the account management should call - it should not
> >> >> re-direct to login back and do the whole login dance
> >> >> * Change the way the account management console loads the messages -
> >> >> it should load using a rest endpoint, not by injecting into the
> >> >> index.ftl. That allows re-loading messages if the locale is changed
> >> >> without having to do the login dance
> >> > What is it about the "login dance" that causes a problem?  It seems to
> >> > do exactly what I need it to do, as long as I can pass in kc_locale.
> >> I was thinking that I actually need the redirect in order to
> >> re-initialize the welcome screen's localized text.  The welcome screen
> >> uses FreeMarker for localization.  But you can't get back to the welcome
> >> screen without logging out, so logout's redirect would take care of the
> >> re-initialization of the welcome screen. Therefore, adding an endpoint
> >> and reloading the messages in Angular would work.
> >>
> >> A new endpoint for this would:
> >> * Set the cookie to the new locale
> >> * Set the UserModel to the new locale
> >> * Return the localized message bundle
> >>
> >> Then I would have to refactor all the language handling on the Angular
> >> side.  It would all just take a bit of time to implement. But if you
> >> really think it has to be done that way we can do it.
> >>
> >> >
> >> >>
> >> >>
> >> >> On 17 April 2018 at 15:59, Marek Posolda <mposolda at redhat.com
> >> >> <mailto:mposolda at redhat.com>> wrote:
> >> >>
> >> >>      On 17/04/18 15:00, Stan Silvert wrote:
> >> >>
> >> >>          On 4/16/2018 1:51 PM, Stian Thorgersen wrote:
> >> >>
> >> >>              kc_locale is only aimed at internal use. You should use
> >> >>              ui_locales
> >> >>              that's the publicly available param.
> >> >>
> >> >>          The problem is that I need the server-side logic associated
> >> with
> >> >>          kc_locale.  kc_locale will update the cookie and update the
> >> >>          UserModel.
> >> >>          ui_locales is just a pass-through back to the application.
> >> >>
> >> >>          So we can either add kc_locale as a login param in
> keycloak.js
> >> >>          or we can
> >> >>          add the server-side logic to ui_locales.  The simplest is to
> >> >>          do the
> >> >>          former.  But perhaps we should have been doing the latter
> all
> >> >>          along?
> >> >>
> >> >>      IMO the ui_locales parameter shouldn't update the UserModel.
> It's
> >> >>      possible that there would be 2 different applications and both
> of
> >> >>      them will send different values of ui_locales parameter. In that
> >> >>      case, when user switch between application1 and application2 (on
> >> >>      each SSO login), there will be update to UserModel, which is not
> >> >>      good regarding performance IMO.
> >> >>
> >> >>      I can see in LocaleHelper.getUserLocale that the order about how
> >> >>      the locale is resolved is:
> >> >>      1. kc_locale parameter
> >> >>      2. KEYCLOAK_LOCALE cookie
> >> >>      3. UserModel attribute
> >> >>      4. ui_locales query parameter
> >> >>      5. Accept-Language header
> >> >>
> >> >>      Is this order proper or not? AFAIK the first 3 items are used
> just
> >> >>      if user explicitly selects the language on Keycloak login screen
> >> >>      (or account mgmt screen). If we put ui_locales up, we will
> defacto
> >> >>      give the control to application to override the localization,
> >> >>      which user explicitly chosen on login screen. Do we want to do
> >> >>      that? Is it good regarding usability? I think that not, but
> maybe
> >> >>      I am wrong...
> >> >>
> >> >>
> >> >> I think the current order is correct.
> >> >>
> >> >> 1. Change locale if user has explicitly made the change - kc_locale
> >> >> should only be set when the user changes it manually through login
> >> pages
> >> >> 2-3 Tries to figure out the users last pick
> >> >> 4. Provided by the application as a hint for what locale the user may
> >> >> want. It should not override the users explicitly set locale
> >> >> 5. Accept-Language is supposed to give the users preferred locale.
> >> >> However, this is often wrong and just defaults to en. Hence why it
> >> >> comes last.
> >> >>
> >> >> There's been quite a lot of discussion to get this right in the past,
> >> >> so I'm quite confident that the current logic works and it has been
> >> >> confirmed by a surprising amount of folks. Well it was tweaked quite
> a
> >> >> few times based on user feedback.
> >> >>
> >> >>
> >> >>      Marek
> >> >>
> >> >>
> >> >>              On 16 April 2018 at 16:06, Stan Silvert
> >> >>              <ssilvert at redhat.com <mailto:ssilvert at redhat.com>
> >> >>              <mailto:ssilvert at redhat.com <mailto:ssilvert at redhat.com
> >> >>>
> >> >>              wrote:
> >> >>
> >> >>                   OK.
> >> >>
> >> >>                   Does anyone object to adding kc_locale to the login
> >> >>              options on the
> >> >>                   keycloak.js adapter?
> >> >>
> >> >>
> >> >>
> >> >>                   On 4/16/2018 2:45 AM, Stian Thorgersen wrote:
> >> >>
> >> >>                       It's a query param defined by OpenID Connect.
> See
> >> >>                  http://openid.net/specs/
> openid-connect-core-1_0.html
> >> >>                  <http://openid.net/specs/
> openid-connect-core-1_0.html
> >> >
> >> >>
> >> >>                   <http://openid.net/specs/open
> >> id-connect-core-1_0.html
> >> >>                  <http://openid.net/specs/
> openid-connect-core-1_0.html
> >> >>.
> >> >>                  It allows
> >> >>                       the application to pass a list of req locales
> in
> >> >>                  case the
> >> >>                       application knows it.
> >> >>
> >> >>                       When doing the redirect login flow the
> >> >>                  applications should use
> >> >>                       ui_locales. kc_locale is an internal param and
> >> >>                  should really only
> >> >>                       be used by the locale switcher on the login
> >> screen.
> >> >>
> >> >>                       On 16 April 2018 at 02:44, Stan Silvert
> >> >>                  <ssilvert at redhat.com <mailto:ssilvert at redhat.com>
> >> >>                       <mailto:ssilvert at redhat.com
> >> >>                  <mailto:ssilvert at redhat.com>>> wrote:
> >> >>
> >> >>                           Does anyone know what ui_locales is
> actually
> >> >>                  used for?
> >> >>
> >> >>                           I can't find usages except for in the
> >> testsuite.
> >> >>
> >> >>                           The query param used to change locale is
> >> >>                  kc_locale.  Should
> >> >>                           ui_locales
> >> >>                           deprecated?
> >> >>
> >> >>                           Stan
> >> >>
> >> >>                           _____________________________
> >> __________________
> >> >>                           keycloak-dev mailing list
> >> >>                  keycloak-dev at lists.jboss.org
> >> >>                  <mailto:keycloak-dev at lists.jboss.org>
> >> >>                           <mailto:keycloak-dev at lists.jboss.org
> >> >>                  <mailto:keycloak-dev at lists.jboss.org>>
> >> >>                  https://lists.jboss.org/
> mailman/listinfo/keycloak-dev
> >> >>                  <https://lists.jboss.org/mailm
> >> an/listinfo/keycloak-dev>
> >> >>
> >> >>                   <https://lists.jboss.org/mail
> >> man/listinfo/keycloak-dev
> >> >>                  <https://lists.jboss.org/mailm
> >> an/listinfo/keycloak-dev>>
> >> >>
> >> >>
> >> >>
> >> >>          _______________________________________________
> >> >>          keycloak-dev mailing list
> >> >>          keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jbo
> >> ss.org>
> >> >>          https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >> >>          <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
> >> >>
> >> >>
> >> >>
> >> >>
> >> > _______________________________________________
> >> > keycloak-dev mailing list
> >> > keycloak-dev at lists.jboss.org
> >> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> >>
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> >
> >
> >
>
>
> ------------------------------
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
> End of keycloak-dev Digest, Vol 58, Issue 16
> ********************************************
>

From sthorger at redhat.com  Thu Apr 19 15:21:15 2018
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 19 Apr 2018 21:21:15 +0200
Subject: [keycloak-dev] keycloak-dev Digest, Vol 58, Issue 16
In-Reply-To: <CABfG-uYSf6e07Wyvi7tDNiLt5zECSkAV=udCtp3S7zE81veTCw@mail.gmail.com>
References: <mailman.100092.1524055082.4745.keycloak-dev@lists.jboss.org>
	<CABfG-uYSf6e07Wyvi7tDNiLt5zECSkAV=udCtp3S7zE81veTCw@mail.gmail.com>
Message-ID: <CAJgngAeU9cp2-Ag6o=rwadGgmZ4QxpMAJuojDSsk84naGLQ04A@mail.gmail.com>

This is really a question for the user mailing list and not the developer
mailing list.

In either case the answer is simple. Some methods in the admin client
return a Response object. You need to call close on that. Otherwise the
connection won't be released back into the pool.

On 19 April 2018 at 15:07, Hafiz Syed Umer Ahmed <umer at codexnow.com> wrote:

> Hi,
>
> I am using keycloak 3.4.1 final on docker with PostgreSQL. I have written a
> spring boot application using keycloak admin client. The problem i am
> facing is that when i make several request on a particular api for example
> creating a user in keycloak it gets halt and does not respond.
> For example : Create user api
> after 10 successful request it does not process the 11th request and
> postman or restlet client shows "sending request" . After halting state it
> does not process any other api request until and unless i restart my spring
> boot application. I am not getting what is the issue. I have checked all
> the credentials and my application settings as well. Is there any rate
> limit on api calling in keycloak or there is some other issue ??
>
> Regards
>
> Umer
>
> On Wed, Apr 18, 2018 at 5:38 PM, <keycloak-dev-request at lists.jboss.org>
> wrote:
>
> > Send keycloak-dev mailing list submissions to
> >         keycloak-dev at lists.jboss.org
> >
> > To subscribe or unsubscribe via the World Wide Web, visit
> >         https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > or, via email, send a message with subject or body 'help' to
> >         keycloak-dev-request at lists.jboss.org
> >
> > You can reach the person managing the list at
> >         keycloak-dev-owner at lists.jboss.org
> >
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of keycloak-dev digest..."
> >
> >
> > Today's Topics:
> >
> >    1. Application and server in separate networks (Christian Beikov)
> >    2. Re: ui_locales query parameter? (Stian Thorgersen)
> >    3. Re: ui_locales query parameter? (Stan Silvert)
> >    4. Re: ui_locales query parameter? (Stian Thorgersen)
> >
> >
> > ----------------------------------------------------------------------
> >
> > Message: 1
> > Date: Wed, 18 Apr 2018 13:45:06 +0200
> > From: Christian Beikov <christian.beikov at gmail.com>
> > Subject: [keycloak-dev] Application and server in separate networks
> > To: keycloak-dev <keycloak-dev at lists.jboss.org>
> > Message-ID: <41e1a805-cc38-50cf-f794-cda6afd49313 at gmail.com>
> > Content-Type: text/plain; charset=utf-8; format=flowed
> >
> > Hi,
> >
> > is it necessary that an application secured by Keycloak can access the
> > Keycloak server? Or is it enough if the Browser can access the Keycloak
> > server?
> >
> > --
> >
> > Mit freundlichen Gr??en,
> > ------------------------------------------------------------------------
> > *Christian Beikov*
> >
> >
> > ------------------------------
> >
> > Message: 2
> > Date: Wed, 18 Apr 2018 13:46:25 +0200
> > From: Stian Thorgersen <sthorger at redhat.com>
> > Subject: Re: [keycloak-dev] ui_locales query parameter?
> > To: Stan Silvert <ssilvert at redhat.com>
> > Cc: keycloak-dev <keycloak-dev at lists.jboss.org>
> > Message-ID:
> >         <CAJgngAeShg4HZL5tTR-zvziKYeBU3-gQ3S4t+DU-_uwDKvO_
> > 4w at mail.gmail.com>
> > Content-Type: text/plain; charset="UTF-8"
> >
> > I don't think it has to be done the way I propose so I don't see a strong
> > need to change it. As long as it works with kc_locale that's fine.
> >
> > On 18 April 2018 at 01:17, Stan Silvert <ssilvert at redhat.com> wrote:
> >
> > > On 4/17/2018 3:07 PM, Stan Silvert wrote:
> > > > On 4/17/2018 1:59 PM, Stian Thorgersen wrote:
> > > >> For the account management console I think the correct approach is
> the
> > > >> following:
> > > >>
> > > >> * Add an endpoint to account management service to allow setting the
> > > >> user locale which the account management should call - it should not
> > > >> re-direct to login back and do the whole login dance
> > > >> * Change the way the account management console loads the messages -
> > > >> it should load using a rest endpoint, not by injecting into the
> > > >> index.ftl. That allows re-loading messages if the locale is changed
> > > >> without having to do the login dance
> > > > What is it about the "login dance" that causes a problem?  It seems
> to
> > > > do exactly what I need it to do, as long as I can pass in kc_locale.
> > > I was thinking that I actually need the redirect in order to
> > > re-initialize the welcome screen's localized text.  The welcome screen
> > > uses FreeMarker for localization.  But you can't get back to the
> welcome
> > > screen without logging out, so logout's redirect would take care of the
> > > re-initialization of the welcome screen. Therefore, adding an endpoint
> > > and reloading the messages in Angular would work.
> > >
> > > A new endpoint for this would:
> > > * Set the cookie to the new locale
> > > * Set the UserModel to the new locale
> > > * Return the localized message bundle
> > >
> > > Then I would have to refactor all the language handling on the Angular
> > > side.  It would all just take a bit of time to implement. But if you
> > > really think it has to be done that way we can do it.
> > >
> > > >
> > > >>
> > > >>
> > > >> On 17 April 2018 at 15:59, Marek Posolda <mposolda at redhat.com
> > > >> <mailto:mposolda at redhat.com>> wrote:
> > > >>
> > > >>      On 17/04/18 15:00, Stan Silvert wrote:
> > > >>
> > > >>          On 4/16/2018 1:51 PM, Stian Thorgersen wrote:
> > > >>
> > > >>              kc_locale is only aimed at internal use. You should use
> > > >>              ui_locales
> > > >>              that's the publicly available param.
> > > >>
> > > >>          The problem is that I need the server-side logic associated
> > > with
> > > >>          kc_locale.  kc_locale will update the cookie and update the
> > > >>          UserModel.
> > > >>          ui_locales is just a pass-through back to the application.
> > > >>
> > > >>          So we can either add kc_locale as a login param in
> > keycloak.js
> > > >>          or we can
> > > >>          add the server-side logic to ui_locales.  The simplest is
> to
> > > >>          do the
> > > >>          former.  But perhaps we should have been doing the latter
> all
> > > >>          along?
> > > >>
> > > >>      IMO the ui_locales parameter shouldn't update the UserModel.
> It's
> > > >>      possible that there would be 2 different applications and both
> of
> > > >>      them will send different values of ui_locales parameter. In
> that
> > > >>      case, when user switch between application1 and application2
> (on
> > > >>      each SSO login), there will be update to UserModel, which is
> not
> > > >>      good regarding performance IMO.
> > > >>
> > > >>      I can see in LocaleHelper.getUserLocale that the order about
> how
> > > >>      the locale is resolved is:
> > > >>      1. kc_locale parameter
> > > >>      2. KEYCLOAK_LOCALE cookie
> > > >>      3. UserModel attribute
> > > >>      4. ui_locales query parameter
> > > >>      5. Accept-Language header
> > > >>
> > > >>      Is this order proper or not? AFAIK the first 3 items are used
> > just
> > > >>      if user explicitly selects the language on Keycloak login
> screen
> > > >>      (or account mgmt screen). If we put ui_locales up, we will
> > defacto
> > > >>      give the control to application to override the localization,
> > > >>      which user explicitly chosen on login screen. Do we want to do
> > > >>      that? Is it good regarding usability? I think that not, but
> maybe
> > > >>      I am wrong...
> > > >>
> > > >>
> > > >> I think the current order is correct.
> > > >>
> > > >> 1. Change locale if user has explicitly made the change - kc_locale
> > > >> should only be set when the user changes it manually through login
> > pages
> > > >> 2-3 Tries to figure out the users last pick
> > > >> 4. Provided by the application as a hint for what locale the user
> may
> > > >> want. It should not override the users explicitly set locale
> > > >> 5. Accept-Language is supposed to give the users preferred locale.
> > > >> However, this is often wrong and just defaults to en. Hence why it
> > > >> comes last.
> > > >>
> > > >> There's been quite a lot of discussion to get this right in the
> past,
> > > >> so I'm quite confident that the current logic works and it has been
> > > >> confirmed by a surprising amount of folks. Well it was tweaked
> quite a
> > > >> few times based on user feedback.
> > > >>
> > > >>
> > > >>      Marek
> > > >>
> > > >>
> > > >>              On 16 April 2018 at 16:06, Stan Silvert
> > > >>              <ssilvert at redhat.com <mailto:ssilvert at redhat.com>
> > > >>              <mailto:ssilvert at redhat.com <mailto:
> ssilvert at redhat.com
> > >>>
> > > >>              wrote:
> > > >>
> > > >>                   OK.
> > > >>
> > > >>                   Does anyone object to adding kc_locale to the
> login
> > > >>              options on the
> > > >>                   keycloak.js adapter?
> > > >>
> > > >>
> > > >>
> > > >>                   On 4/16/2018 2:45 AM, Stian Thorgersen wrote:
> > > >>
> > > >>                       It's a query param defined by OpenID Connect.
> > See
> > > >>                  http://openid.net/specs/
> openid-connect-core-1_0.html
> > > >>                  <http://openid.net/specs/
> > openid-connect-core-1_0.html>
> > > >>
> > > >>                   <http://openid.net/specs/
> > openid-connect-core-1_0.html
> > > >>                  <http://openid.net/specs/
> > openid-connect-core-1_0.html
> > > >>.
> > > >>                  It allows
> > > >>                       the application to pass a list of req locales
> in
> > > >>                  case the
> > > >>                       application knows it.
> > > >>
> > > >>                       When doing the redirect login flow the
> > > >>                  applications should use
> > > >>                       ui_locales. kc_locale is an internal param and
> > > >>                  should really only
> > > >>                       be used by the locale switcher on the login
> > > screen.
> > > >>
> > > >>                       On 16 April 2018 at 02:44, Stan Silvert
> > > >>                  <ssilvert at redhat.com <mailto:ssilvert at redhat.com>
> > > >>                       <mailto:ssilvert at redhat.com
> > > >>                  <mailto:ssilvert at redhat.com>>> wrote:
> > > >>
> > > >>                           Does anyone know what ui_locales is
> actually
> > > >>                  used for?
> > > >>
> > > >>                           I can't find usages except for in the
> > > testsuite.
> > > >>
> > > >>                           The query param used to change locale is
> > > >>                  kc_locale.  Should
> > > >>                           ui_locales
> > > >>                           deprecated?
> > > >>
> > > >>                           Stan
> > > >>
> > > >>                           _____________________________
> > > __________________
> > > >>                           keycloak-dev mailing list
> > > >>                  keycloak-dev at lists.jboss.org
> > > >>                  <mailto:keycloak-dev at lists.jboss.org>
> > > >>                           <mailto:keycloak-dev at lists.jboss.org
> > > >>                  <mailto:keycloak-dev at lists.jboss.org>>
> > > >>                  https://lists.jboss.org/
> > mailman/listinfo/keycloak-dev
> > > >>                  <https://lists.jboss.org/
> > mailman/listinfo/keycloak-dev
> > > >
> > > >>
> > > >>                   <https://lists.jboss.org/
> > > mailman/listinfo/keycloak-dev
> > > >>                  <https://lists.jboss.org/
> > mailman/listinfo/keycloak-dev
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>          _______________________________________________
> > > >>          keycloak-dev mailing list
> > > >>          keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.
> > > jboss.org>
> > > >>          https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > >>          <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
> > > >>
> > > >>
> > > >>
> > > >>
> > > > _______________________________________________
> > > > keycloak-dev mailing list
> > > > keycloak-dev at lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > >
> > >
> > > _______________________________________________
> > > keycloak-dev mailing list
> > > keycloak-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > >
> >
> >
> > ------------------------------
> >
> > Message: 3
> > Date: Wed, 18 Apr 2018 08:19:58 -0400
> > From: Stan Silvert <ssilvert at redhat.com>
> > Subject: Re: [keycloak-dev] ui_locales query parameter?
> > To: stian at redhat.com
> > Cc: keycloak-dev <keycloak-dev at lists.jboss.org>
> > Message-ID: <c78a0305-d893-7fd6-e14a-2445cc983238 at redhat.com>
> > Content-Type: text/plain; charset=utf-8; format=flowed
> >
> > On 4/18/2018 7:46 AM, Stian Thorgersen wrote:
> > > I don't think it has to be done the way I propose so I don't see a
> > > strong need to change it. As long as it works with kc_locale that's
> fine.
> > OK.? I'll add the kc_locale param to keycloak.js.? It might be useful
> > for others as well.
> >
> > >
> > > On 18 April 2018 at 01:17, Stan Silvert <ssilvert at redhat.com
> > > <mailto:ssilvert at redhat.com>> wrote:
> > >
> > >     On 4/17/2018 3:07 PM, Stan Silvert wrote:
> > >     > On 4/17/2018 1:59 PM, Stian Thorgersen wrote:
> > >     >> For the account management console I think the correct approach
> > >     is the
> > >     >> following:
> > >     >>
> > >     >> * Add an endpoint to account management service to allow
> > >     setting the
> > >     >> user locale which the account management should call - it
> > >     should not
> > >     >> re-direct to login back and do the whole login dance
> > >     >> * Change the way the account management console loads the
> > >     messages -
> > >     >> it should load using a rest endpoint, not by injecting into the
> > >     >> index.ftl. That allows re-loading messages if the locale is
> > changed
> > >     >> without having to do the login dance
> > >     > What is it about the "login dance" that causes a problem?? It
> > >     seems to
> > >     > do exactly what I need it to do, as long as I can pass in
> > kc_locale.
> > >     I was thinking that I actually need the redirect in order to
> > >     re-initialize the welcome screen's localized text.? The welcome
> > >     screen
> > >     uses FreeMarker for localization.? But you can't get back to the
> > >     welcome
> > >     screen without logging out, so logout's redirect would take care
> > >     of the
> > >     re-initialization of the welcome screen. Therefore, adding an
> > >     endpoint
> > >     and reloading the messages in Angular would work.
> > >
> > >     A new endpoint for this would:
> > >     * Set the cookie to the new locale
> > >     * Set the UserModel to the new locale
> > >     * Return the localized message bundle
> > >
> > >     Then I would have to refactor all the language handling on the
> > >     Angular
> > >     side.? It would all just take a bit of time to implement. But if
> you
> > >     really think it has to be done that way we can do it.
> > >
> > >     >
> > >     >>
> > >     >>
> > >     >> On 17 April 2018 at 15:59, Marek Posolda <mposolda at redhat.com
> > >     <mailto:mposolda at redhat.com>
> > >     >> <mailto:mposolda at redhat.com <mailto:mposolda at redhat.com>>>
> wrote:
> > >     >>
> > >     >>? ? ? On 17/04/18 15:00, Stan Silvert wrote:
> > >     >>
> > >     >>? ? ? ? ? On 4/16/2018 1:51 PM, Stian Thorgersen wrote:
> > >     >>
> > >     >>? ? ? ? ? ? ? kc_locale is only aimed at internal use. You
> > >     should use
> > >     >>? ? ? ? ? ? ? ui_locales
> > >     >>? ? ? ? ? ? ? that's the publicly available param.
> > >     >>
> > >     >>? ? ? ? ? The problem is that I need the server-side logic
> > >     associated with
> > >     >>? ? ? ? ? kc_locale.? kc_locale will update the cookie and
> > >     update the
> > >     >>? ? ? ? ? UserModel.
> > >     >>? ? ? ? ? ui_locales is just a pass-through back to the
> > application.
> > >     >>
> > >     >>? ? ? ? ? So we can either add kc_locale as a login param in
> > >     keycloak.js
> > >     >>? ? ? ? ? or we can
> > >     >>? ? ? ? ? add the server-side logic to ui_locales.? The simplest
> > >     is to
> > >     >>? ? ? ? ? do the
> > >     >>? ? ? ? ? former.? But perhaps we should have been doing the
> > >     latter all
> > >     >>? ? ? ? ? along?
> > >     >>
> > >     >>? ? ? IMO the ui_locales parameter shouldn't update the
> > >     UserModel. It's
> > >     >>? ? ? possible that there would be 2 different applications and
> > >     both of
> > >     >>? ? ? them will send different values of ui_locales parameter.
> > >     In that
> > >     >>? ? ? case, when user switch between application1 and
> > >     application2 (on
> > >     >>? ? ? each SSO login), there will be update to UserModel, which
> > >     is not
> > >     >>? ? ? good regarding performance IMO.
> > >     >>
> > >     >>? ? ? I can see in LocaleHelper.getUserLocale that the order
> > >     about how
> > >     >>? ? ? the locale is resolved is:
> > >     >>? ? ? 1. kc_locale parameter
> > >     >>? ? ? 2. KEYCLOAK_LOCALE cookie
> > >     >>? ? ? 3. UserModel attribute
> > >     >>? ? ? 4. ui_locales query parameter
> > >     >>? ? ? 5. Accept-Language header
> > >     >>
> > >     >>? ? ? Is this order proper or not? AFAIK the first 3 items are
> > >     used just
> > >     >>? ? ? if user explicitly selects the language on Keycloak login
> > >     screen
> > >     >>? ? ? (or account mgmt screen). If we put ui_locales up, we will
> > >     defacto
> > >     >>? ? ? give the control to application to override the
> localization,
> > >     >>? ? ? which user explicitly chosen on login screen. Do we want to
> > do
> > >     >>? ? ? that? Is it good regarding usability? I think that not,
> > >     but maybe
> > >     >>? ? ? I am wrong...
> > >     >>
> > >     >>
> > >     >> I think the current order is correct.
> > >     >>
> > >     >> 1. Change locale if user has explicitly made the change -
> > kc_locale
> > >     >> should only be set when the user changes it manually through
> > >     login pages
> > >     >> 2-3 Tries to figure out the users last pick
> > >     >> 4. Provided by the application as a hint for what locale the
> > >     user may
> > >     >> want. It should not override the users explicitly set locale
> > >     >> 5. Accept-Language is supposed to give the users preferred
> locale.
> > >     >> However, this is often wrong and just defaults to en. Hence why
> it
> > >     >> comes last.
> > >     >>
> > >     >> There's been quite a lot of discussion to get this right in the
> > >     past,
> > >     >> so I'm quite confident that the current logic works and it has
> > been
> > >     >> confirmed by a surprising amount of folks. Well it was tweaked
> > >     quite a
> > >     >> few times based on user feedback.
> > >     >>
> > >     >>
> > >     >>? ? ? Marek
> > >     >>
> > >     >>
> > >     >>? ? ? ? ? ? ? On 16 April 2018 at 16:06, Stan Silvert
> > >     >>? ? ? ? ? ? ? <ssilvert at redhat.com <mailto:ssilvert at redhat.com>
> > >     <mailto:ssilvert at redhat.com <mailto:ssilvert at redhat.com>>
> > >     >>? ? ? ? ? ? ? <mailto:ssilvert at redhat.com
> > >     <mailto:ssilvert at redhat.com> <mailto:ssilvert at redhat.com
> > >     <mailto:ssilvert at redhat.com>>>>
> > >     >>? ? ? ? ? ? ? wrote:
> > >     >>
> > >     >>? ? ? ? ? ? ? ? ? ?OK.
> > >     >>
> > >     >>? ? ? ? ? ? ? ? ? ?Does anyone object to adding kc_locale to the
> > >     login
> > >     >>? ? ? ? ? ? ? options on the
> > >     >>? ? ? ? ? ? ? ? ? ?keycloak.js adapter?
> > >     >>
> > >     >>
> > >     >>
> > >     >>? ? ? ? ? ? ? ? ? ?On 4/16/2018 2:45 AM, Stian Thorgersen wrote:
> > >     >>
> > >     >>? ? ? ? ? ? ? ? ? ? ? ?It's a query param defined by OpenID
> > >     Connect. See
> > >     >> http://openid.net/specs/openid-connect-core-1_0.html
> > >     <http://openid.net/specs/openid-connect-core-1_0.html>
> > >     >>? ? ? ? ? ? ? ? ?
> > >     <http://openid.net/specs/openid-connect-core-1_0.html
> > >     <http://openid.net/specs/openid-connect-core-1_0.html>>
> > >     >>
> > >     >>? ? ? ? ? ? ? ? ?
> > >     ?<http://openid.net/specs/openid-connect-core-1_0.html
> > >     <http://openid.net/specs/openid-connect-core-1_0.html>
> > >     >>? ? ? ? ? ? ? ? ?
> > >     <http://openid.net/specs/openid-connect-core-1_0.html
> > >     <http://openid.net/specs/openid-connect-core-1_0.html>>>.
> > >     >>? ? ? ? ? ? ? ? ? It allows
> > >     >>? ? ? ? ? ? ? ? ? ? ? ?the application to pass a list of req
> > >     locales in
> > >     >>? ? ? ? ? ? ? ? ? case the
> > >     >>? ? ? ? ? ? ? ? ? ? ? ?application knows it.
> > >     >>
> > >     >>? ? ? ? ? ? ? ? ? ? ? ?When doing the redirect login flow the
> > >     >>? ? ? ? ? ? ? ? ? applications should use
> > >     >>? ? ? ? ? ? ? ? ? ? ? ?ui_locales. kc_locale is an internal
> > >     param and
> > >     >>? ? ? ? ? ? ? ? ? should really only
> > >     >>? ? ? ? ? ? ? ? ? ? ? ?be used by the locale switcher on the
> > >     login screen.
> > >     >>
> > >     >>? ? ? ? ? ? ? ? ? ? ? ?On 16 April 2018 at 02:44, Stan Silvert
> > >     >>? ? ? ? ? ? ? ? ? <ssilvert at redhat.com
> > >     <mailto:ssilvert at redhat.com> <mailto:ssilvert at redhat.com
> > >     <mailto:ssilvert at redhat.com>>
> > >     >>? ? ? ? ? ? ? ? ? ? ? ?<mailto:ssilvert at redhat.com
> > >     <mailto:ssilvert at redhat.com>
> > >     >>? ? ? ? ? ? ? ? ? <mailto:ssilvert at redhat.com <mailto:
> > ssilvert at redhat.com>>>> wrote:
> > >     >>
> > >     >>? ? ? ? ? ? ? ? ? ? ? ? ? ?Does anyone know what ui_locales is
> > >     actually
> > >     >>? ? ? ? ? ? ? ? ? used for?
> > >     >>
> > >     >>? ? ? ? ? ? ? ? ? ? ? ? ? ?I can't find usages except for in the
> > >     testsuite.
> > >     >>
> > >     >>? ? ? ? ? ? ? ? ? ? ? ? ? ?The query param used to change locale
> is
> > >     >>? ? ? ? ? ? ? ? ? kc_locale.? Should
> > >     >>? ? ? ? ? ? ? ? ? ? ? ? ? ?ui_locales
> > >     >>? ? ? ? ? ? ? ? ? ? ? ? ? ?deprecated?
> > >     >>
> > >     >>? ? ? ? ? ? ? ? ? ? ? ? ? ?Stan
> > >     >>
> > >     >> ?_______________________________________________
> > >     >>? ? ? ? ? ? ? ? ? ? ? ? ? ?keycloak-dev mailing list
> > >     >> keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.
> jboss.org
> > >
> > >     >>? ? ? ? ? ? ? ? ? <mailto:keycloak-dev at lists.jboss.org
> > >     <mailto:keycloak-dev at lists.jboss.org>>
> > >     >>? ? ? ? ? ? ? ? ? ? ? ? ? ?<mailto:keycloak-dev at lists.jboss.org
> > >     <mailto:keycloak-dev at lists.jboss.org>
> > >     >>? ? ? ? ? ? ? ? ? <mailto:keycloak-dev at lists.jboss.org <mailto:
> > keycloak-dev at lists.jboss.org>>>
> > >     >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > >     <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
> > >     >>? ? ? ? ? ? ? ? ?
> > >     <https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > >     <https://lists.jboss.org/mailman/listinfo/keycloak-dev>>
> > >     >>
> > >     >>? ? ? ? ? ? ? ? ?
> > >     ?<https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > >     <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
> > >     >>? ? ? ? ? ? ? ? ?
> > >     <https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > >     <https://lists.jboss.org/mailman/listinfo/keycloak-dev>>>
> > >     >>
> > >     >>
> > >     >>
> > >     >>? ? ? ? ? _______________________________________________
> > >     >>? ? ? ? ? keycloak-dev mailing list
> > >     >> keycloak-dev at lists.jboss.org
> > >     <mailto:keycloak-dev at lists.jboss.org>
> > >     <mailto:keycloak-dev at lists.jboss.org
> > >     <mailto:keycloak-dev at lists.jboss.org>>
> > >     >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > >     <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
> > >     >>? ? ? ? ? <https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > >     <https://lists.jboss.org/mailman/listinfo/keycloak-dev>>
> > >     >>
> > >     >>
> > >     >>
> > >     >>
> > >     > _______________________________________________
> > >     > keycloak-dev mailing list
> > >     > keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.
> jboss.org>
> > >     > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > >     <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
> > >
> > >
> > >     _______________________________________________
> > >     keycloak-dev mailing list
> > >     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
> > >     https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > >     <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
> > >
> > >
> >
> >
> >
> > ------------------------------
> >
> > Message: 4
> > Date: Wed, 18 Apr 2018 14:37:41 +0200
> > From: Stian Thorgersen <sthorger at redhat.com>
> > Subject: Re: [keycloak-dev] ui_locales query parameter?
> > To: Stan Silvert <ssilvert at redhat.com>
> > Cc: keycloak-dev <keycloak-dev at lists.jboss.org>
> > Message-ID:
> >         <CAJgngAeSuTouzjuAqAS3mCrQMGt9on090qUe90qvA452PS72kQ at mail.
> > gmail.com>
> > Content-Type: text/plain; charset="UTF-8"
> >
> > Not sure it should be added directly to keycloak.js as it's not strictly
> a
> > supported param. Either you should just use it from keycloak.js, but not
> > make it a direct option, or we should add it as a supported param. In the
> > latter case we should probably document it.
> >
> > On 18 April 2018 at 14:19, Stan Silvert <ssilvert at redhat.com> wrote:
> >
> > > On 4/18/2018 7:46 AM, Stian Thorgersen wrote:
> > >
> > > I don't think it has to be done the way I propose so I don't see a
> strong
> > > need to change it. As long as it works with kc_locale that's fine.
> > >
> > > OK.  I'll add the kc_locale param to keycloak.js.  It might be useful
> for
> > > others as well.
> > >
> > >
> > >
> > > On 18 April 2018 at 01:17, Stan Silvert <ssilvert at redhat.com> wrote:
> > >
> > >> On 4/17/2018 3:07 PM, Stan Silvert wrote:
> > >> > On 4/17/2018 1:59 PM, Stian Thorgersen wrote:
> > >> >> For the account management console I think the correct approach is
> > the
> > >> >> following:
> > >> >>
> > >> >> * Add an endpoint to account management service to allow setting
> the
> > >> >> user locale which the account management should call - it should
> not
> > >> >> re-direct to login back and do the whole login dance
> > >> >> * Change the way the account management console loads the messages
> -
> > >> >> it should load using a rest endpoint, not by injecting into the
> > >> >> index.ftl. That allows re-loading messages if the locale is changed
> > >> >> without having to do the login dance
> > >> > What is it about the "login dance" that causes a problem?  It seems
> to
> > >> > do exactly what I need it to do, as long as I can pass in kc_locale.
> > >> I was thinking that I actually need the redirect in order to
> > >> re-initialize the welcome screen's localized text.  The welcome screen
> > >> uses FreeMarker for localization.  But you can't get back to the
> welcome
> > >> screen without logging out, so logout's redirect would take care of
> the
> > >> re-initialization of the welcome screen. Therefore, adding an endpoint
> > >> and reloading the messages in Angular would work.
> > >>
> > >> A new endpoint for this would:
> > >> * Set the cookie to the new locale
> > >> * Set the UserModel to the new locale
> > >> * Return the localized message bundle
> > >>
> > >> Then I would have to refactor all the language handling on the Angular
> > >> side.  It would all just take a bit of time to implement. But if you
> > >> really think it has to be done that way we can do it.
> > >>
> > >> >
> > >> >>
> > >> >>
> > >> >> On 17 April 2018 at 15:59, Marek Posolda <mposolda at redhat.com
> > >> >> <mailto:mposolda at redhat.com>> wrote:
> > >> >>
> > >> >>      On 17/04/18 15:00, Stan Silvert wrote:
> > >> >>
> > >> >>          On 4/16/2018 1:51 PM, Stian Thorgersen wrote:
> > >> >>
> > >> >>              kc_locale is only aimed at internal use. You should
> use
> > >> >>              ui_locales
> > >> >>              that's the publicly available param.
> > >> >>
> > >> >>          The problem is that I need the server-side logic
> associated
> > >> with
> > >> >>          kc_locale.  kc_locale will update the cookie and update
> the
> > >> >>          UserModel.
> > >> >>          ui_locales is just a pass-through back to the application.
> > >> >>
> > >> >>          So we can either add kc_locale as a login param in
> > keycloak.js
> > >> >>          or we can
> > >> >>          add the server-side logic to ui_locales.  The simplest is
> to
> > >> >>          do the
> > >> >>          former.  But perhaps we should have been doing the latter
> > all
> > >> >>          along?
> > >> >>
> > >> >>      IMO the ui_locales parameter shouldn't update the UserModel.
> > It's
> > >> >>      possible that there would be 2 different applications and both
> > of
> > >> >>      them will send different values of ui_locales parameter. In
> that
> > >> >>      case, when user switch between application1 and application2
> (on
> > >> >>      each SSO login), there will be update to UserModel, which is
> not
> > >> >>      good regarding performance IMO.
> > >> >>
> > >> >>      I can see in LocaleHelper.getUserLocale that the order about
> how
> > >> >>      the locale is resolved is:
> > >> >>      1. kc_locale parameter
> > >> >>      2. KEYCLOAK_LOCALE cookie
> > >> >>      3. UserModel attribute
> > >> >>      4. ui_locales query parameter
> > >> >>      5. Accept-Language header
> > >> >>
> > >> >>      Is this order proper or not? AFAIK the first 3 items are used
> > just
> > >> >>      if user explicitly selects the language on Keycloak login
> screen
> > >> >>      (or account mgmt screen). If we put ui_locales up, we will
> > defacto
> > >> >>      give the control to application to override the localization,
> > >> >>      which user explicitly chosen on login screen. Do we want to do
> > >> >>      that? Is it good regarding usability? I think that not, but
> > maybe
> > >> >>      I am wrong...
> > >> >>
> > >> >>
> > >> >> I think the current order is correct.
> > >> >>
> > >> >> 1. Change locale if user has explicitly made the change - kc_locale
> > >> >> should only be set when the user changes it manually through login
> > >> pages
> > >> >> 2-3 Tries to figure out the users last pick
> > >> >> 4. Provided by the application as a hint for what locale the user
> may
> > >> >> want. It should not override the users explicitly set locale
> > >> >> 5. Accept-Language is supposed to give the users preferred locale.
> > >> >> However, this is often wrong and just defaults to en. Hence why it
> > >> >> comes last.
> > >> >>
> > >> >> There's been quite a lot of discussion to get this right in the
> past,
> > >> >> so I'm quite confident that the current logic works and it has been
> > >> >> confirmed by a surprising amount of folks. Well it was tweaked
> quite
> > a
> > >> >> few times based on user feedback.
> > >> >>
> > >> >>
> > >> >>      Marek
> > >> >>
> > >> >>
> > >> >>              On 16 April 2018 at 16:06, Stan Silvert
> > >> >>              <ssilvert at redhat.com <mailto:ssilvert at redhat.com>
> > >> >>              <mailto:ssilvert at redhat.com <mailto:
> ssilvert at redhat.com
> > >> >>>
> > >> >>              wrote:
> > >> >>
> > >> >>                   OK.
> > >> >>
> > >> >>                   Does anyone object to adding kc_locale to the
> login
> > >> >>              options on the
> > >> >>                   keycloak.js adapter?
> > >> >>
> > >> >>
> > >> >>
> > >> >>                   On 4/16/2018 2:45 AM, Stian Thorgersen wrote:
> > >> >>
> > >> >>                       It's a query param defined by OpenID Connect.
> > See
> > >> >>                  http://openid.net/specs/
> > openid-connect-core-1_0.html
> > >> >>                  <http://openid.net/specs/
> > openid-connect-core-1_0.html
> > >> >
> > >> >>
> > >> >>                   <http://openid.net/specs/open
> > >> id-connect-core-1_0.html
> > >> >>                  <http://openid.net/specs/
> > openid-connect-core-1_0.html
> > >> >>.
> > >> >>                  It allows
> > >> >>                       the application to pass a list of req locales
> > in
> > >> >>                  case the
> > >> >>                       application knows it.
> > >> >>
> > >> >>                       When doing the redirect login flow the
> > >> >>                  applications should use
> > >> >>                       ui_locales. kc_locale is an internal param
> and
> > >> >>                  should really only
> > >> >>                       be used by the locale switcher on the login
> > >> screen.
> > >> >>
> > >> >>                       On 16 April 2018 at 02:44, Stan Silvert
> > >> >>                  <ssilvert at redhat.com <mailto:ssilvert at redhat.com>
> > >> >>                       <mailto:ssilvert at redhat.com
> > >> >>                  <mailto:ssilvert at redhat.com>>> wrote:
> > >> >>
> > >> >>                           Does anyone know what ui_locales is
> > actually
> > >> >>                  used for?
> > >> >>
> > >> >>                           I can't find usages except for in the
> > >> testsuite.
> > >> >>
> > >> >>                           The query param used to change locale is
> > >> >>                  kc_locale.  Should
> > >> >>                           ui_locales
> > >> >>                           deprecated?
> > >> >>
> > >> >>                           Stan
> > >> >>
> > >> >>                           _____________________________
> > >> __________________
> > >> >>                           keycloak-dev mailing list
> > >> >>                  keycloak-dev at lists.jboss.org
> > >> >>                  <mailto:keycloak-dev at lists.jboss.org>
> > >> >>                           <mailto:keycloak-dev at lists.jboss.org
> > >> >>                  <mailto:keycloak-dev at lists.jboss.org>>
> > >> >>                  https://lists.jboss.org/
> > mailman/listinfo/keycloak-dev
> > >> >>                  <https://lists.jboss.org/mailm
> > >> an/listinfo/keycloak-dev>
> > >> >>
> > >> >>                   <https://lists.jboss.org/mail
> > >> man/listinfo/keycloak-dev
> > >> >>                  <https://lists.jboss.org/mailm
> > >> an/listinfo/keycloak-dev>>
> > >> >>
> > >> >>
> > >> >>
> > >> >>          _______________________________________________
> > >> >>          keycloak-dev mailing list
> > >> >>          keycloak-dev at lists.jboss.org <mailto:
> keycloak-dev at lists.jbo
> > >> ss.org>
> > >> >>          https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > >> >>          <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
> > >> >>
> > >> >>
> > >> >>
> > >> >>
> > >> > _______________________________________________
> > >> > keycloak-dev mailing list
> > >> > keycloak-dev at lists.jboss.org
> > >> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > >>
> > >>
> > >> _______________________________________________
> > >> keycloak-dev mailing list
> > >> keycloak-dev at lists.jboss.org
> > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > >>
> > >
> > >
> > >
> >
> >
> > ------------------------------
> >
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> > End of keycloak-dev Digest, Vol 58, Issue 16
> > ********************************************
> >
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From thomas.darimont at googlemail.com  Thu Apr 19 16:15:53 2018
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Thu, 19 Apr 2018 22:15:53 +0200
Subject: [keycloak-dev] keycloak-dev Digest, Vol 58, Issue 16
In-Reply-To: <CAJgngAeU9cp2-Ag6o=rwadGgmZ4QxpMAJuojDSsk84naGLQ04A@mail.gmail.com>
References: <mailman.100092.1524055082.4745.keycloak-dev@lists.jboss.org>
	<CABfG-uYSf6e07Wyvi7tDNiLt5zECSkAV=udCtp3S7zE81veTCw@mail.gmail.com>
	<CAJgngAeU9cp2-Ag6o=rwadGgmZ4QxpMAJuojDSsk84naGLQ04A@mail.gmail.com>
Message-ID: <CAK-7U1jR+Qf8fVkcVuiWdZRr7E8KvmgME6KteJSjkK5N7XDTmg@mail.gmail.com>

This looks like as if you're not closing your admin client resources
(Responses) correctly.

Take a look at this:
https://gist.github.com/thomasdarimont/3082a1e480cd856b474c1c4498aa3788

Cheers,
Thomas

2018-04-19 21:21 GMT+02:00 Stian Thorgersen <sthorger at redhat.com>:

> This is really a question for the user mailing list and not the developer
> mailing list.
>
> In either case the answer is simple. Some methods in the admin client
> return a Response object. You need to call close on that. Otherwise the
> connection won't be released back into the pool.
>
> On 19 April 2018 at 15:07, Hafiz Syed Umer Ahmed <umer at codexnow.com>
> wrote:
>
> > Hi,
> >
> > I am using keycloak 3.4.1 final on docker with PostgreSQL. I have
> written a
> > spring boot application using keycloak admin client. The problem i am
> > facing is that when i make several request on a particular api for
> example
> > creating a user in keycloak it gets halt and does not respond.
> > For example : Create user api
> > after 10 successful request it does not process the 11th request and
> > postman or restlet client shows "sending request" . After halting state
> it
> > does not process any other api request until and unless i restart my
> spring
> > boot application. I am not getting what is the issue. I have checked all
> > the credentials and my application settings as well. Is there any rate
> > limit on api calling in keycloak or there is some other issue ??
> >
> > Regards
> >
> > Umer
> >
> > On Wed, Apr 18, 2018 at 5:38 PM, <keycloak-dev-request at lists.jboss.org>
> > wrote:
> >
> > > Send keycloak-dev mailing list submissions to
> > >         keycloak-dev at lists.jboss.org
> > >
> > > To subscribe or unsubscribe via the World Wide Web, visit
> > >         https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > or, via email, send a message with subject or body 'help' to
> > >         keycloak-dev-request at lists.jboss.org
> > >
> > > You can reach the person managing the list at
> > >         keycloak-dev-owner at lists.jboss.org
> > >
> > > When replying, please edit your Subject line so it is more specific
> > > than "Re: Contents of keycloak-dev digest..."
> > >
> > >
> > > Today's Topics:
> > >
> > >    1. Application and server in separate networks (Christian Beikov)
> > >    2. Re: ui_locales query parameter? (Stian Thorgersen)
> > >    3. Re: ui_locales query parameter? (Stan Silvert)
> > >    4. Re: ui_locales query parameter? (Stian Thorgersen)
> > >
> > >
> > > ----------------------------------------------------------------------
> > >
> > > Message: 1
> > > Date: Wed, 18 Apr 2018 13:45:06 +0200
> > > From: Christian Beikov <christian.beikov at gmail.com>
> > > Subject: [keycloak-dev] Application and server in separate networks
> > > To: keycloak-dev <keycloak-dev at lists.jboss.org>
> > > Message-ID: <41e1a805-cc38-50cf-f794-cda6afd49313 at gmail.com>
> > > Content-Type: text/plain; charset=utf-8; format=flowed
> > >
> > > Hi,
> > >
> > > is it necessary that an application secured by Keycloak can access the
> > > Keycloak server? Or is it enough if the Browser can access the Keycloak
> > > server?
> > >
> > > --
> > >
> > > Mit freundlichen Gr??en,
> > > ------------------------------------------------------------
> ------------
> > > *Christian Beikov*
> > >
> > >
> > > ------------------------------
> > >
> > > Message: 2
> > > Date: Wed, 18 Apr 2018 13:46:25 +0200
> > > From: Stian Thorgersen <sthorger at redhat.com>
> > > Subject: Re: [keycloak-dev] ui_locales query parameter?
> > > To: Stan Silvert <ssilvert at redhat.com>
> > > Cc: keycloak-dev <keycloak-dev at lists.jboss.org>
> > > Message-ID:
> > >         <CAJgngAeShg4HZL5tTR-zvziKYeBU3-gQ3S4t+DU-_uwDKvO_
> > > 4w at mail.gmail.com>
> > > Content-Type: text/plain; charset="UTF-8"
> > >
> > > I don't think it has to be done the way I propose so I don't see a
> strong
> > > need to change it. As long as it works with kc_locale that's fine.
> > >
> > > On 18 April 2018 at 01:17, Stan Silvert <ssilvert at redhat.com> wrote:
> > >
> > > > On 4/17/2018 3:07 PM, Stan Silvert wrote:
> > > > > On 4/17/2018 1:59 PM, Stian Thorgersen wrote:
> > > > >> For the account management console I think the correct approach is
> > the
> > > > >> following:
> > > > >>
> > > > >> * Add an endpoint to account management service to allow setting
> the
> > > > >> user locale which the account management should call - it should
> not
> > > > >> re-direct to login back and do the whole login dance
> > > > >> * Change the way the account management console loads the
> messages -
> > > > >> it should load using a rest endpoint, not by injecting into the
> > > > >> index.ftl. That allows re-loading messages if the locale is
> changed
> > > > >> without having to do the login dance
> > > > > What is it about the "login dance" that causes a problem?  It seems
> > to
> > > > > do exactly what I need it to do, as long as I can pass in
> kc_locale.
> > > > I was thinking that I actually need the redirect in order to
> > > > re-initialize the welcome screen's localized text.  The welcome
> screen
> > > > uses FreeMarker for localization.  But you can't get back to the
> > welcome
> > > > screen without logging out, so logout's redirect would take care of
> the
> > > > re-initialization of the welcome screen. Therefore, adding an
> endpoint
> > > > and reloading the messages in Angular would work.
> > > >
> > > > A new endpoint for this would:
> > > > * Set the cookie to the new locale
> > > > * Set the UserModel to the new locale
> > > > * Return the localized message bundle
> > > >
> > > > Then I would have to refactor all the language handling on the
> Angular
> > > > side.  It would all just take a bit of time to implement. But if you
> > > > really think it has to be done that way we can do it.
> > > >
> > > > >
> > > > >>
> > > > >>
> > > > >> On 17 April 2018 at 15:59, Marek Posolda <mposolda at redhat.com
> > > > >> <mailto:mposolda at redhat.com>> wrote:
> > > > >>
> > > > >>      On 17/04/18 15:00, Stan Silvert wrote:
> > > > >>
> > > > >>          On 4/16/2018 1:51 PM, Stian Thorgersen wrote:
> > > > >>
> > > > >>              kc_locale is only aimed at internal use. You should
> use
> > > > >>              ui_locales
> > > > >>              that's the publicly available param.
> > > > >>
> > > > >>          The problem is that I need the server-side logic
> associated
> > > > with
> > > > >>          kc_locale.  kc_locale will update the cookie and update
> the
> > > > >>          UserModel.
> > > > >>          ui_locales is just a pass-through back to the
> application.
> > > > >>
> > > > >>          So we can either add kc_locale as a login param in
> > > keycloak.js
> > > > >>          or we can
> > > > >>          add the server-side logic to ui_locales.  The simplest is
> > to
> > > > >>          do the
> > > > >>          former.  But perhaps we should have been doing the latter
> > all
> > > > >>          along?
> > > > >>
> > > > >>      IMO the ui_locales parameter shouldn't update the UserModel.
> > It's
> > > > >>      possible that there would be 2 different applications and
> both
> > of
> > > > >>      them will send different values of ui_locales parameter. In
> > that
> > > > >>      case, when user switch between application1 and application2
> > (on
> > > > >>      each SSO login), there will be update to UserModel, which is
> > not
> > > > >>      good regarding performance IMO.
> > > > >>
> > > > >>      I can see in LocaleHelper.getUserLocale that the order about
> > how
> > > > >>      the locale is resolved is:
> > > > >>      1. kc_locale parameter
> > > > >>      2. KEYCLOAK_LOCALE cookie
> > > > >>      3. UserModel attribute
> > > > >>      4. ui_locales query parameter
> > > > >>      5. Accept-Language header
> > > > >>
> > > > >>      Is this order proper or not? AFAIK the first 3 items are used
> > > just
> > > > >>      if user explicitly selects the language on Keycloak login
> > screen
> > > > >>      (or account mgmt screen). If we put ui_locales up, we will
> > > defacto
> > > > >>      give the control to application to override the localization,
> > > > >>      which user explicitly chosen on login screen. Do we want to
> do
> > > > >>      that? Is it good regarding usability? I think that not, but
> > maybe
> > > > >>      I am wrong...
> > > > >>
> > > > >>
> > > > >> I think the current order is correct.
> > > > >>
> > > > >> 1. Change locale if user has explicitly made the change -
> kc_locale
> > > > >> should only be set when the user changes it manually through login
> > > pages
> > > > >> 2-3 Tries to figure out the users last pick
> > > > >> 4. Provided by the application as a hint for what locale the user
> > may
> > > > >> want. It should not override the users explicitly set locale
> > > > >> 5. Accept-Language is supposed to give the users preferred locale.
> > > > >> However, this is often wrong and just defaults to en. Hence why it
> > > > >> comes last.
> > > > >>
> > > > >> There's been quite a lot of discussion to get this right in the
> > past,
> > > > >> so I'm quite confident that the current logic works and it has
> been
> > > > >> confirmed by a surprising amount of folks. Well it was tweaked
> > quite a
> > > > >> few times based on user feedback.
> > > > >>
> > > > >>
> > > > >>      Marek
> > > > >>
> > > > >>
> > > > >>              On 16 April 2018 at 16:06, Stan Silvert
> > > > >>              <ssilvert at redhat.com <mailto:ssilvert at redhat.com>
> > > > >>              <mailto:ssilvert at redhat.com <mailto:
> > ssilvert at redhat.com
> > > >>>
> > > > >>              wrote:
> > > > >>
> > > > >>                   OK.
> > > > >>
> > > > >>                   Does anyone object to adding kc_locale to the
> > login
> > > > >>              options on the
> > > > >>                   keycloak.js adapter?
> > > > >>
> > > > >>
> > > > >>
> > > > >>                   On 4/16/2018 2:45 AM, Stian Thorgersen wrote:
> > > > >>
> > > > >>                       It's a query param defined by OpenID
> Connect.
> > > See
> > > > >>                  http://openid.net/specs/
> > openid-connect-core-1_0.html
> > > > >>                  <http://openid.net/specs/
> > > openid-connect-core-1_0.html>
> > > > >>
> > > > >>                   <http://openid.net/specs/
> > > openid-connect-core-1_0.html
> > > > >>                  <http://openid.net/specs/
> > > openid-connect-core-1_0.html
> > > > >>.
> > > > >>                  It allows
> > > > >>                       the application to pass a list of req
> locales
> > in
> > > > >>                  case the
> > > > >>                       application knows it.
> > > > >>
> > > > >>                       When doing the redirect login flow the
> > > > >>                  applications should use
> > > > >>                       ui_locales. kc_locale is an internal param
> and
> > > > >>                  should really only
> > > > >>                       be used by the locale switcher on the login
> > > > screen.
> > > > >>
> > > > >>                       On 16 April 2018 at 02:44, Stan Silvert
> > > > >>                  <ssilvert at redhat.com <mailto:ssilvert at redhat.com
> >
> > > > >>                       <mailto:ssilvert at redhat.com
> > > > >>                  <mailto:ssilvert at redhat.com>>> wrote:
> > > > >>
> > > > >>                           Does anyone know what ui_locales is
> > actually
> > > > >>                  used for?
> > > > >>
> > > > >>                           I can't find usages except for in the
> > > > testsuite.
> > > > >>
> > > > >>                           The query param used to change locale is
> > > > >>                  kc_locale.  Should
> > > > >>                           ui_locales
> > > > >>                           deprecated?
> > > > >>
> > > > >>                           Stan
> > > > >>
> > > > >>                           _____________________________
> > > > __________________
> > > > >>                           keycloak-dev mailing list
> > > > >>                  keycloak-dev at lists.jboss.org
> > > > >>                  <mailto:keycloak-dev at lists.jboss.org>
> > > > >>                           <mailto:keycloak-dev at lists.jboss.org
> > > > >>                  <mailto:keycloak-dev at lists.jboss.org>>
> > > > >>                  https://lists.jboss.org/
> > > mailman/listinfo/keycloak-dev
> > > > >>                  <https://lists.jboss.org/
> > > mailman/listinfo/keycloak-dev
> > > > >
> > > > >>
> > > > >>                   <https://lists.jboss.org/
> > > > mailman/listinfo/keycloak-dev
> > > > >>                  <https://lists.jboss.org/
> > > mailman/listinfo/keycloak-dev
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >>          _______________________________________________
> > > > >>          keycloak-dev mailing list
> > > > >>          keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.
> > > > jboss.org>
> > > > >>          https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > >>          <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > > _______________________________________________
> > > > > keycloak-dev mailing list
> > > > > keycloak-dev at lists.jboss.org
> > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > >
> > > >
> > > > _______________________________________________
> > > > keycloak-dev mailing list
> > > > keycloak-dev at lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > >
> > >
> > >
> > > ------------------------------
> > >
> > > Message: 3
> > > Date: Wed, 18 Apr 2018 08:19:58 -0400
> > > From: Stan Silvert <ssilvert at redhat.com>
> > > Subject: Re: [keycloak-dev] ui_locales query parameter?
> > > To: stian at redhat.com
> > > Cc: keycloak-dev <keycloak-dev at lists.jboss.org>
> > > Message-ID: <c78a0305-d893-7fd6-e14a-2445cc983238 at redhat.com>
> > > Content-Type: text/plain; charset=utf-8; format=flowed
> > >
> > > On 4/18/2018 7:46 AM, Stian Thorgersen wrote:
> > > > I don't think it has to be done the way I propose so I don't see a
> > > > strong need to change it. As long as it works with kc_locale that's
> > fine.
> > > OK.? I'll add the kc_locale param to keycloak.js.? It might be useful
> > > for others as well.
> > >
> > > >
> > > > On 18 April 2018 at 01:17, Stan Silvert <ssilvert at redhat.com
> > > > <mailto:ssilvert at redhat.com>> wrote:
> > > >
> > > >     On 4/17/2018 3:07 PM, Stan Silvert wrote:
> > > >     > On 4/17/2018 1:59 PM, Stian Thorgersen wrote:
> > > >     >> For the account management console I think the correct
> approach
> > > >     is the
> > > >     >> following:
> > > >     >>
> > > >     >> * Add an endpoint to account management service to allow
> > > >     setting the
> > > >     >> user locale which the account management should call - it
> > > >     should not
> > > >     >> re-direct to login back and do the whole login dance
> > > >     >> * Change the way the account management console loads the
> > > >     messages -
> > > >     >> it should load using a rest endpoint, not by injecting into
> the
> > > >     >> index.ftl. That allows re-loading messages if the locale is
> > > changed
> > > >     >> without having to do the login dance
> > > >     > What is it about the "login dance" that causes a problem?? It
> > > >     seems to
> > > >     > do exactly what I need it to do, as long as I can pass in
> > > kc_locale.
> > > >     I was thinking that I actually need the redirect in order to
> > > >     re-initialize the welcome screen's localized text.? The welcome
> > > >     screen
> > > >     uses FreeMarker for localization.? But you can't get back to the
> > > >     welcome
> > > >     screen without logging out, so logout's redirect would take care
> > > >     of the
> > > >     re-initialization of the welcome screen. Therefore, adding an
> > > >     endpoint
> > > >     and reloading the messages in Angular would work.
> > > >
> > > >     A new endpoint for this would:
> > > >     * Set the cookie to the new locale
> > > >     * Set the UserModel to the new locale
> > > >     * Return the localized message bundle
> > > >
> > > >     Then I would have to refactor all the language handling on the
> > > >     Angular
> > > >     side.? It would all just take a bit of time to implement. But if
> > you
> > > >     really think it has to be done that way we can do it.
> > > >
> > > >     >
> > > >     >>
> > > >     >>
> > > >     >> On 17 April 2018 at 15:59, Marek Posolda <mposolda at redhat.com
> > > >     <mailto:mposolda at redhat.com>
> > > >     >> <mailto:mposolda at redhat.com <mailto:mposolda at redhat.com>>>
> > wrote:
> > > >     >>
> > > >     >>? ? ? On 17/04/18 15:00, Stan Silvert wrote:
> > > >     >>
> > > >     >>? ? ? ? ? On 4/16/2018 1:51 PM, Stian Thorgersen wrote:
> > > >     >>
> > > >     >>? ? ? ? ? ? ? kc_locale is only aimed at internal use. You
> > > >     should use
> > > >     >>? ? ? ? ? ? ? ui_locales
> > > >     >>? ? ? ? ? ? ? that's the publicly available param.
> > > >     >>
> > > >     >>? ? ? ? ? The problem is that I need the server-side logic
> > > >     associated with
> > > >     >>? ? ? ? ? kc_locale.? kc_locale will update the cookie and
> > > >     update the
> > > >     >>? ? ? ? ? UserModel.
> > > >     >>? ? ? ? ? ui_locales is just a pass-through back to the
> > > application.
> > > >     >>
> > > >     >>? ? ? ? ? So we can either add kc_locale as a login param in
> > > >     keycloak.js
> > > >     >>? ? ? ? ? or we can
> > > >     >>? ? ? ? ? add the server-side logic to ui_locales.? The
> simplest
> > > >     is to
> > > >     >>? ? ? ? ? do the
> > > >     >>? ? ? ? ? former.? But perhaps we should have been doing the
> > > >     latter all
> > > >     >>? ? ? ? ? along?
> > > >     >>
> > > >     >>? ? ? IMO the ui_locales parameter shouldn't update the
> > > >     UserModel. It's
> > > >     >>? ? ? possible that there would be 2 different applications and
> > > >     both of
> > > >     >>? ? ? them will send different values of ui_locales parameter.
> > > >     In that
> > > >     >>? ? ? case, when user switch between application1 and
> > > >     application2 (on
> > > >     >>? ? ? each SSO login), there will be update to UserModel, which
> > > >     is not
> > > >     >>? ? ? good regarding performance IMO.
> > > >     >>
> > > >     >>? ? ? I can see in LocaleHelper.getUserLocale that the order
> > > >     about how
> > > >     >>? ? ? the locale is resolved is:
> > > >     >>? ? ? 1. kc_locale parameter
> > > >     >>? ? ? 2. KEYCLOAK_LOCALE cookie
> > > >     >>? ? ? 3. UserModel attribute
> > > >     >>? ? ? 4. ui_locales query parameter
> > > >     >>? ? ? 5. Accept-Language header
> > > >     >>
> > > >     >>? ? ? Is this order proper or not? AFAIK the first 3 items are
> > > >     used just
> > > >     >>? ? ? if user explicitly selects the language on Keycloak login
> > > >     screen
> > > >     >>? ? ? (or account mgmt screen). If we put ui_locales up, we
> will
> > > >     defacto
> > > >     >>? ? ? give the control to application to override the
> > localization,
> > > >     >>? ? ? which user explicitly chosen on login screen. Do we want
> to
> > > do
> > > >     >>? ? ? that? Is it good regarding usability? I think that not,
> > > >     but maybe
> > > >     >>? ? ? I am wrong...
> > > >     >>
> > > >     >>
> > > >     >> I think the current order is correct.
> > > >     >>
> > > >     >> 1. Change locale if user has explicitly made the change -
> > > kc_locale
> > > >     >> should only be set when the user changes it manually through
> > > >     login pages
> > > >     >> 2-3 Tries to figure out the users last pick
> > > >     >> 4. Provided by the application as a hint for what locale the
> > > >     user may
> > > >     >> want. It should not override the users explicitly set locale
> > > >     >> 5. Accept-Language is supposed to give the users preferred
> > locale.
> > > >     >> However, this is often wrong and just defaults to en. Hence
> why
> > it
> > > >     >> comes last.
> > > >     >>
> > > >     >> There's been quite a lot of discussion to get this right in
> the
> > > >     past,
> > > >     >> so I'm quite confident that the current logic works and it has
> > > been
> > > >     >> confirmed by a surprising amount of folks. Well it was tweaked
> > > >     quite a
> > > >     >> few times based on user feedback.
> > > >     >>
> > > >     >>
> > > >     >>? ? ? Marek
> > > >     >>
> > > >     >>
> > > >     >>? ? ? ? ? ? ? On 16 April 2018 at 16:06, Stan Silvert
> > > >     >>? ? ? ? ? ? ? <ssilvert at redhat.com <mailto:ssilvert at redhat.com
> >
> > > >     <mailto:ssilvert at redhat.com <mailto:ssilvert at redhat.com>>
> > > >     >>? ? ? ? ? ? ? <mailto:ssilvert at redhat.com
> > > >     <mailto:ssilvert at redhat.com> <mailto:ssilvert at redhat.com
> > > >     <mailto:ssilvert at redhat.com>>>>
> > > >     >>? ? ? ? ? ? ? wrote:
> > > >     >>
> > > >     >>? ? ? ? ? ? ? ? ? ?OK.
> > > >     >>
> > > >     >>? ? ? ? ? ? ? ? ? ?Does anyone object to adding kc_locale to
> the
> > > >     login
> > > >     >>? ? ? ? ? ? ? options on the
> > > >     >>? ? ? ? ? ? ? ? ? ?keycloak.js adapter?
> > > >     >>
> > > >     >>
> > > >     >>
> > > >     >>? ? ? ? ? ? ? ? ? ?On 4/16/2018 2:45 AM, Stian Thorgersen
> wrote:
> > > >     >>
> > > >     >>? ? ? ? ? ? ? ? ? ? ? ?It's a query param defined by OpenID
> > > >     Connect. See
> > > >     >> http://openid.net/specs/openid-connect-core-1_0.html
> > > >     <http://openid.net/specs/openid-connect-core-1_0.html>
> > > >     >>? ? ? ? ? ? ? ? ?
> > > >     <http://openid.net/specs/openid-connect-core-1_0.html
> > > >     <http://openid.net/specs/openid-connect-core-1_0.html>>
> > > >     >>
> > > >     >>? ? ? ? ? ? ? ? ?
> > > >     ?<http://openid.net/specs/openid-connect-core-1_0.html
> > > >     <http://openid.net/specs/openid-connect-core-1_0.html>
> > > >     >>? ? ? ? ? ? ? ? ?
> > > >     <http://openid.net/specs/openid-connect-core-1_0.html
> > > >     <http://openid.net/specs/openid-connect-core-1_0.html>>>.
> > > >     >>? ? ? ? ? ? ? ? ? It allows
> > > >     >>? ? ? ? ? ? ? ? ? ? ? ?the application to pass a list of req
> > > >     locales in
> > > >     >>? ? ? ? ? ? ? ? ? case the
> > > >     >>? ? ? ? ? ? ? ? ? ? ? ?application knows it.
> > > >     >>
> > > >     >>? ? ? ? ? ? ? ? ? ? ? ?When doing the redirect login flow the
> > > >     >>? ? ? ? ? ? ? ? ? applications should use
> > > >     >>? ? ? ? ? ? ? ? ? ? ? ?ui_locales. kc_locale is an internal
> > > >     param and
> > > >     >>? ? ? ? ? ? ? ? ? should really only
> > > >     >>? ? ? ? ? ? ? ? ? ? ? ?be used by the locale switcher on the
> > > >     login screen.
> > > >     >>
> > > >     >>? ? ? ? ? ? ? ? ? ? ? ?On 16 April 2018 at 02:44, Stan Silvert
> > > >     >>? ? ? ? ? ? ? ? ? <ssilvert at redhat.com
> > > >     <mailto:ssilvert at redhat.com> <mailto:ssilvert at redhat.com
> > > >     <mailto:ssilvert at redhat.com>>
> > > >     >>? ? ? ? ? ? ? ? ? ? ? ?<mailto:ssilvert at redhat.com
> > > >     <mailto:ssilvert at redhat.com>
> > > >     >>? ? ? ? ? ? ? ? ? <mailto:ssilvert at redhat.com <mailto:
> > > ssilvert at redhat.com>>>> wrote:
> > > >     >>
> > > >     >>? ? ? ? ? ? ? ? ? ? ? ? ? ?Does anyone know what ui_locales is
> > > >     actually
> > > >     >>? ? ? ? ? ? ? ? ? used for?
> > > >     >>
> > > >     >>? ? ? ? ? ? ? ? ? ? ? ? ? ?I can't find usages except for in
> the
> > > >     testsuite.
> > > >     >>
> > > >     >>? ? ? ? ? ? ? ? ? ? ? ? ? ?The query param used to change
> locale
> > is
> > > >     >>? ? ? ? ? ? ? ? ? kc_locale.? Should
> > > >     >>? ? ? ? ? ? ? ? ? ? ? ? ? ?ui_locales
> > > >     >>? ? ? ? ? ? ? ? ? ? ? ? ? ?deprecated?
> > > >     >>
> > > >     >>? ? ? ? ? ? ? ? ? ? ? ? ? ?Stan
> > > >     >>
> > > >     >> ?_______________________________________________
> > > >     >>? ? ? ? ? ? ? ? ? ? ? ? ? ?keycloak-dev mailing list
> > > >     >> keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.
> > jboss.org
> > > >
> > > >     >>? ? ? ? ? ? ? ? ? <mailto:keycloak-dev at lists.jboss.org
> > > >     <mailto:keycloak-dev at lists.jboss.org>>
> > > >     >>? ? ? ? ? ? ? ? ? ? ? ? ? ?<mailto:keycloak-dev at lists.
> jboss.org
> > > >     <mailto:keycloak-dev at lists.jboss.org>
> > > >     >>? ? ? ? ? ? ? ? ? <mailto:keycloak-dev at lists.jboss.org
> <mailto:
> > > keycloak-dev at lists.jboss.org>>>
> > > >     >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > >     <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
> > > >     >>? ? ? ? ? ? ? ? ?
> > > >     <https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > >     <https://lists.jboss.org/mailman/listinfo/keycloak-dev>>
> > > >     >>
> > > >     >>? ? ? ? ? ? ? ? ?
> > > >     ?<https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > >     <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
> > > >     >>? ? ? ? ? ? ? ? ?
> > > >     <https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > >     <https://lists.jboss.org/mailman/listinfo/keycloak-dev>>>
> > > >     >>
> > > >     >>
> > > >     >>
> > > >     >>? ? ? ? ? _______________________________________________
> > > >     >>? ? ? ? ? keycloak-dev mailing list
> > > >     >> keycloak-dev at lists.jboss.org
> > > >     <mailto:keycloak-dev at lists.jboss.org>
> > > >     <mailto:keycloak-dev at lists.jboss.org
> > > >     <mailto:keycloak-dev at lists.jboss.org>>
> > > >     >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > >     <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
> > > >     >>? ? ? ? ? <https://lists.jboss.org/
> mailman/listinfo/keycloak-dev
> > > >     <https://lists.jboss.org/mailman/listinfo/keycloak-dev>>
> > > >     >>
> > > >     >>
> > > >     >>
> > > >     >>
> > > >     > _______________________________________________
> > > >     > keycloak-dev mailing list
> > > >     > keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.
> > jboss.org>
> > > >     > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > >     <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
> > > >
> > > >
> > > >     _______________________________________________
> > > >     keycloak-dev mailing list
> > > >     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.
> jboss.org>
> > > >     https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > >     <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
> > > >
> > > >
> > >
> > >
> > >
> > > ------------------------------
> > >
> > > Message: 4
> > > Date: Wed, 18 Apr 2018 14:37:41 +0200
> > > From: Stian Thorgersen <sthorger at redhat.com>
> > > Subject: Re: [keycloak-dev] ui_locales query parameter?
> > > To: Stan Silvert <ssilvert at redhat.com>
> > > Cc: keycloak-dev <keycloak-dev at lists.jboss.org>
> > > Message-ID:
> > >         <CAJgngAeSuTouzjuAqAS3mCrQMGt9on090qUe90qvA452PS72kQ at mail.
> > > gmail.com>
> > > Content-Type: text/plain; charset="UTF-8"
> > >
> > > Not sure it should be added directly to keycloak.js as it's not
> strictly
> > a
> > > supported param. Either you should just use it from keycloak.js, but
> not
> > > make it a direct option, or we should add it as a supported param. In
> the
> > > latter case we should probably document it.
> > >
> > > On 18 April 2018 at 14:19, Stan Silvert <ssilvert at redhat.com> wrote:
> > >
> > > > On 4/18/2018 7:46 AM, Stian Thorgersen wrote:
> > > >
> > > > I don't think it has to be done the way I propose so I don't see a
> > strong
> > > > need to change it. As long as it works with kc_locale that's fine.
> > > >
> > > > OK.  I'll add the kc_locale param to keycloak.js.  It might be useful
> > for
> > > > others as well.
> > > >
> > > >
> > > >
> > > > On 18 April 2018 at 01:17, Stan Silvert <ssilvert at redhat.com> wrote:
> > > >
> > > >> On 4/17/2018 3:07 PM, Stan Silvert wrote:
> > > >> > On 4/17/2018 1:59 PM, Stian Thorgersen wrote:
> > > >> >> For the account management console I think the correct approach
> is
> > > the
> > > >> >> following:
> > > >> >>
> > > >> >> * Add an endpoint to account management service to allow setting
> > the
> > > >> >> user locale which the account management should call - it should
> > not
> > > >> >> re-direct to login back and do the whole login dance
> > > >> >> * Change the way the account management console loads the
> messages
> > -
> > > >> >> it should load using a rest endpoint, not by injecting into the
> > > >> >> index.ftl. That allows re-loading messages if the locale is
> changed
> > > >> >> without having to do the login dance
> > > >> > What is it about the "login dance" that causes a problem?  It
> seems
> > to
> > > >> > do exactly what I need it to do, as long as I can pass in
> kc_locale.
> > > >> I was thinking that I actually need the redirect in order to
> > > >> re-initialize the welcome screen's localized text.  The welcome
> screen
> > > >> uses FreeMarker for localization.  But you can't get back to the
> > welcome
> > > >> screen without logging out, so logout's redirect would take care of
> > the
> > > >> re-initialization of the welcome screen. Therefore, adding an
> endpoint
> > > >> and reloading the messages in Angular would work.
> > > >>
> > > >> A new endpoint for this would:
> > > >> * Set the cookie to the new locale
> > > >> * Set the UserModel to the new locale
> > > >> * Return the localized message bundle
> > > >>
> > > >> Then I would have to refactor all the language handling on the
> Angular
> > > >> side.  It would all just take a bit of time to implement. But if you
> > > >> really think it has to be done that way we can do it.
> > > >>
> > > >> >
> > > >> >>
> > > >> >>
> > > >> >> On 17 April 2018 at 15:59, Marek Posolda <mposolda at redhat.com
> > > >> >> <mailto:mposolda at redhat.com>> wrote:
> > > >> >>
> > > >> >>      On 17/04/18 15:00, Stan Silvert wrote:
> > > >> >>
> > > >> >>          On 4/16/2018 1:51 PM, Stian Thorgersen wrote:
> > > >> >>
> > > >> >>              kc_locale is only aimed at internal use. You should
> > use
> > > >> >>              ui_locales
> > > >> >>              that's the publicly available param.
> > > >> >>
> > > >> >>          The problem is that I need the server-side logic
> > associated
> > > >> with
> > > >> >>          kc_locale.  kc_locale will update the cookie and update
> > the
> > > >> >>          UserModel.
> > > >> >>          ui_locales is just a pass-through back to the
> application.
> > > >> >>
> > > >> >>          So we can either add kc_locale as a login param in
> > > keycloak.js
> > > >> >>          or we can
> > > >> >>          add the server-side logic to ui_locales.  The simplest
> is
> > to
> > > >> >>          do the
> > > >> >>          former.  But perhaps we should have been doing the
> latter
> > > all
> > > >> >>          along?
> > > >> >>
> > > >> >>      IMO the ui_locales parameter shouldn't update the UserModel.
> > > It's
> > > >> >>      possible that there would be 2 different applications and
> both
> > > of
> > > >> >>      them will send different values of ui_locales parameter. In
> > that
> > > >> >>      case, when user switch between application1 and application2
> > (on
> > > >> >>      each SSO login), there will be update to UserModel, which is
> > not
> > > >> >>      good regarding performance IMO.
> > > >> >>
> > > >> >>      I can see in LocaleHelper.getUserLocale that the order about
> > how
> > > >> >>      the locale is resolved is:
> > > >> >>      1. kc_locale parameter
> > > >> >>      2. KEYCLOAK_LOCALE cookie
> > > >> >>      3. UserModel attribute
> > > >> >>      4. ui_locales query parameter
> > > >> >>      5. Accept-Language header
> > > >> >>
> > > >> >>      Is this order proper or not? AFAIK the first 3 items are
> used
> > > just
> > > >> >>      if user explicitly selects the language on Keycloak login
> > screen
> > > >> >>      (or account mgmt screen). If we put ui_locales up, we will
> > > defacto
> > > >> >>      give the control to application to override the
> localization,
> > > >> >>      which user explicitly chosen on login screen. Do we want to
> do
> > > >> >>      that? Is it good regarding usability? I think that not, but
> > > maybe
> > > >> >>      I am wrong...
> > > >> >>
> > > >> >>
> > > >> >> I think the current order is correct.
> > > >> >>
> > > >> >> 1. Change locale if user has explicitly made the change -
> kc_locale
> > > >> >> should only be set when the user changes it manually through
> login
> > > >> pages
> > > >> >> 2-3 Tries to figure out the users last pick
> > > >> >> 4. Provided by the application as a hint for what locale the user
> > may
> > > >> >> want. It should not override the users explicitly set locale
> > > >> >> 5. Accept-Language is supposed to give the users preferred
> locale.
> > > >> >> However, this is often wrong and just defaults to en. Hence why
> it
> > > >> >> comes last.
> > > >> >>
> > > >> >> There's been quite a lot of discussion to get this right in the
> > past,
> > > >> >> so I'm quite confident that the current logic works and it has
> been
> > > >> >> confirmed by a surprising amount of folks. Well it was tweaked
> > quite
> > > a
> > > >> >> few times based on user feedback.
> > > >> >>
> > > >> >>
> > > >> >>      Marek
> > > >> >>
> > > >> >>
> > > >> >>              On 16 April 2018 at 16:06, Stan Silvert
> > > >> >>              <ssilvert at redhat.com <mailto:ssilvert at redhat.com>
> > > >> >>              <mailto:ssilvert at redhat.com <mailto:
> > ssilvert at redhat.com
> > > >> >>>
> > > >> >>              wrote:
> > > >> >>
> > > >> >>                   OK.
> > > >> >>
> > > >> >>                   Does anyone object to adding kc_locale to the
> > login
> > > >> >>              options on the
> > > >> >>                   keycloak.js adapter?
> > > >> >>
> > > >> >>
> > > >> >>
> > > >> >>                   On 4/16/2018 2:45 AM, Stian Thorgersen wrote:
> > > >> >>
> > > >> >>                       It's a query param defined by OpenID
> Connect.
> > > See
> > > >> >>                  http://openid.net/specs/
> > > openid-connect-core-1_0.html
> > > >> >>                  <http://openid.net/specs/
> > > openid-connect-core-1_0.html
> > > >> >
> > > >> >>
> > > >> >>                   <http://openid.net/specs/open
> > > >> id-connect-core-1_0.html
> > > >> >>                  <http://openid.net/specs/
> > > openid-connect-core-1_0.html
> > > >> >>.
> > > >> >>                  It allows
> > > >> >>                       the application to pass a list of req
> locales
> > > in
> > > >> >>                  case the
> > > >> >>                       application knows it.
> > > >> >>
> > > >> >>                       When doing the redirect login flow the
> > > >> >>                  applications should use
> > > >> >>                       ui_locales. kc_locale is an internal param
> > and
> > > >> >>                  should really only
> > > >> >>                       be used by the locale switcher on the login
> > > >> screen.
> > > >> >>
> > > >> >>                       On 16 April 2018 at 02:44, Stan Silvert
> > > >> >>                  <ssilvert at redhat.com <mailto:
> ssilvert at redhat.com>
> > > >> >>                       <mailto:ssilvert at redhat.com
> > > >> >>                  <mailto:ssilvert at redhat.com>>> wrote:
> > > >> >>
> > > >> >>                           Does anyone know what ui_locales is
> > > actually
> > > >> >>                  used for?
> > > >> >>
> > > >> >>                           I can't find usages except for in the
> > > >> testsuite.
> > > >> >>
> > > >> >>                           The query param used to change locale
> is
> > > >> >>                  kc_locale.  Should
> > > >> >>                           ui_locales
> > > >> >>                           deprecated?
> > > >> >>
> > > >> >>                           Stan
> > > >> >>
> > > >> >>                           _____________________________
> > > >> __________________
> > > >> >>                           keycloak-dev mailing list
> > > >> >>                  keycloak-dev at lists.jboss.org
> > > >> >>                  <mailto:keycloak-dev at lists.jboss.org>
> > > >> >>                           <mailto:keycloak-dev at lists.jboss.org
> > > >> >>                  <mailto:keycloak-dev at lists.jboss.org>>
> > > >> >>                  https://lists.jboss.org/
> > > mailman/listinfo/keycloak-dev
> > > >> >>                  <https://lists.jboss.org/mailm
> > > >> an/listinfo/keycloak-dev>
> > > >> >>
> > > >> >>                   <https://lists.jboss.org/mail
> > > >> man/listinfo/keycloak-dev
> > > >> >>                  <https://lists.jboss.org/mailm
> > > >> an/listinfo/keycloak-dev>>
> > > >> >>
> > > >> >>
> > > >> >>
> > > >> >>          _______________________________________________
> > > >> >>          keycloak-dev mailing list
> > > >> >>          keycloak-dev at lists.jboss.org <mailto:
> > keycloak-dev at lists.jbo
> > > >> ss.org>
> > > >> >>          https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > >> >>          <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
> > > >> >>
> > > >> >>
> > > >> >>
> > > >> >>
> > > >> > _______________________________________________
> > > >> > keycloak-dev mailing list
> > > >> > keycloak-dev at lists.jboss.org
> > > >> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > >>
> > > >>
> > > >> _______________________________________________
> > > >> keycloak-dev mailing list
> > > >> keycloak-dev at lists.jboss.org
> > > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > >>
> > > >
> > > >
> > > >
> > >
> > >
> > > ------------------------------
> > >
> > > _______________________________________________
> > > keycloak-dev mailing list
> > > keycloak-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > >
> > > End of keycloak-dev Digest, Vol 58, Issue 16
> > > ********************************************
> > >
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From takashi.norimatsu.ws at hitachi.com  Thu Apr 19 21:10:44 2018
From: takashi.norimatsu.ws at hitachi.com (=?iso-2022-jp?B?GyRCPmg+Pk40O1YbKEIgLyBOT1JJTUFUU1UbJEIhJBsoQlRBS0FTSEk=?=)
Date: Fri, 20 Apr 2018 01:10:44 +0000
Subject: [keycloak-dev] OIDC Identity Brokering with Client parameter forward
Message-ID: <KAXPR01MB10938D8AA21CA962542AF1B1CEB40@KAXPR01MB1093.jpnprd01.prod.outlook.com>

Hello.

When using OIDC Identity Brokering, I've found that the keycloak's built-in OIDC Identity Brokering provider does not have the feature of forwarding some parameters originated from a client application to an external IdP.

Such the feature might be beneficial when you host its own IdP and want to configure its UX based on forwarded client parameters and so on.

Previously, I had realized this feature by implementing custom Authentication provider and User Storage provider.
However, it had been too much complicated and I had the advice to use Identity Brokering.
https://github.com/keycloak/keycloak/pull/4260

Therefore, I've implemented this feature(Forwarding parameters) based on this OIDC Identity Brokering built-in provider.
https://github.com/keycloak/keycloak/pull/5163

Forwarded parameters are prefixed with "fwd_".

It needs some documentation so that I'd like to do that if this proposal is accepted.

Also, I've created corresponding JIRA ticket.
https://issues.jboss.org/browse/KEYCLOAK-7201

Hope this PR is reviewed and merged.

Best Regards
Takashi Norimatsu
Hitachi, Ltd.



From nielsbne at gmail.com  Fri Apr 20 03:15:54 2018
From: nielsbne at gmail.com (Niels Bertram)
Date: Fri, 20 Apr 2018 17:15:54 +1000
Subject: [keycloak-dev] Application and server in separate networks
In-Reply-To: <569a7f4e-2fa6-6590-2dfb-d7a57c137db2@gmail.com>
References: <41e1a805-cc38-50cf-f794-cda6afd49313@gmail.com>
	<CAK-7U1gGFnwc3EcgL3whgdGbSTH9xSVwVSHxc1i+JtetJ83H4g@mail.gmail.com>
	<24a0f868-9726-4024-6254-9a0b68b29c9f@gmail.com>
	<569a7f4e-2fa6-6590-2dfb-d7a57c137db2@gmail.com>
Message-ID: <CAPLPygm2BHoNkrrYMWaOUHx1gGT-PbvSccTNf7JuuLjGeATrLg@mail.gmail.com>

Hi Christian,

can't say for sure but the server side adapters always use standard
authorization flow, which requires your Java app to connect via a back
channel to (A) exchange code grant for access tokens and (B) to lookup jwks
for token validation.

The OpenID Connect specification does provide a pure browser based flow
called implicit flow
<http://openid.net/specs/openid-connect-core-1_0.html#ImplicitFlowAuth> but
that one has a few drawbacks such as auth tokens delivered in the redirect
URL and no refresh token capability. Using this flow could solve your
problem (A) to shift login flow to the frontend but still poses the
challenge for (B) validating the tokens at the backend.

I could not find a way to configure the Java adapter to work in pure
offline validation mode. We had a similar requirement some time ago and had
to code our own auth module to validate incoming tokens with a
pre-configured public key. The other common problem we ran into is wanting
to validate tokens from different (including non-keycloak) issuers on the
same backend. The Keycloak Java adapters do not support this use case
either. We originally looked at the Spring JWT adapter
<https://github.com/spring-projects/spring-security-oauth/tree/master/spring-security-jwt>
as an alternative but this project is not properly patched and
configuration is a wonderful garden of mystery like everything in Spring.

Very curious though to see what others are doing.

Cheers,
Niels


On Thu, Apr 19, 2018 at 2:16 AM, Christian Beikov <
christian.beikov at gmail.com> wrote:

> As far as I see in the code, the Java Adapters always use the standard
> flow i.e. response_type=code
>
> Please tell me this observation is wrong and there is an undocumented
> setting I just didn't see that I can use to tell the adapter to use the
> implicit flow instead :|
>
> If this is really missing, where would you suggest this should be
> configured? I'd expect the setting to be in KeycloakDeployment and
> OAuthRequestAuthenticator#loginRedirect would then use the value instead
> of always using the "code" value.
>
>
> Mit freundlichen Gr??en,
> ------------------------------------------------------------------------
> *Christian Beikov*
> Am 18.04.2018 um 17:35 schrieb Christian Beikov:
> >
> > Is there any way to avoid the access code to access token exchange?
> > Since the Keycloak server is not accessible, I'm getting an error
> > during authentication:
> >
> >  ERROR [org.keycloak.adapters.OAuthRequestAuthenticator] (default
> > task-54) failed to turn code into token:
> > java.net.UnknownHostException: blabla.local: unknown error
> >         ...
> >         at
> > org.keycloak.adapters.ServerRequest.invokeAccessCodeToToken(
> ServerRequest.java:111)
> >         at
> > org.keycloak.adapters.OAuthRequestAuthenticator.resolveCode(
> OAuthRequestAuthenticator.java:330)
> >         at
> > org.keycloak.adapters.OAuthRequestAuthenticator.authenticate(
> OAuthRequestAuthenticator.java:275)
> >         at
> > org.keycloak.adapters.RequestAuthenticator.authenticate(
> RequestAuthenticator.java:139)
> >         at
> > org.keycloak.adapters.undertow.AbstractUndertowKeycloakAuthMe
> ch.keycloakAuthenticate(AbstractUndertowKeycloakAuthMech.java:110)
> >         at
> > org.keycloak.adapters.undertow.ServletKeycloakAuthMech.authenticate(
> ServletKeycloakAuthMech.java:92)
> >         ...
> >
> >
> > Mit freundlichen Gr??en,
> > ------------------------------------------------------------------------
> > *Christian Beikov*
> > Am 18.04.2018 um 14:48 schrieb Thomas Darimont:
> >> Hello Christian,
> >>
> >> your application server needs to communicate with the Keycloak server
> >> to retrieve the realm public key referenced in the token to verify
> >> the token signature.
> >> The current implementation in Keycloak fetches & caches unknown
> >> public keys automatically.
> >>
> >> You could also use a fixed realm public key on the application server
> >> side but it would not support key rotation anymore.
> >>
> >> Cheers,
> >> Thomas
> >>
> >> 2018-04-18 13:45 GMT+02:00 Christian Beikov
> >> <christian.beikov at gmail.com <mailto:christian.beikov at gmail.com>>:
> >>
> >>     Hi,
> >>
> >>     is it necessary that an application secured by Keycloak can
> >>     access the
> >>     Keycloak server? Or is it enough if the Browser can access the
> >>     Keycloak
> >>     server?
> >>
> >>     --
> >>
> >>     Mit freundlichen Gr??en,
> >>     ------------------------------------------------------------
> ------------
> >>     *Christian Beikov*
> >>     _______________________________________________
> >>     keycloak-dev mailing list
> >>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
> >>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>     <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
> >>
> >>
> >
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From adesbiaux at vente-privee.com  Fri Apr 20 07:46:14 2018
From: adesbiaux at vente-privee.com (Adrien DESBIAUX)
Date: Fri, 20 Apr 2018 11:46:14 +0000
Subject: [keycloak-dev] Internationalization - question
Message-ID: <DB5PR02MB1685E7433B3077A16B4178239DB40@DB5PR02MB1685.eurprd02.prod.outlook.com>

Hello!

I would like to be sure to understand well how internationalization works in KC:

I can only access those 2 variables in the template:

- locale.supported
and
- locale.current

https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/theme/beans/LocaleBean.java


My issue is that ${locale.current} return the "language name" as a string.

But it would be very helpful to get the language code instead or another property to get for example "de" for Deutsch. That would make internationalization logics more standard to other tools.


Would you agree or did I miss something?


Thank you in advance for your feedback.


Keycloak is still an awesome tool :)


Cheers!



From ssilvert at redhat.com  Fri Apr 20 08:59:08 2018
From: ssilvert at redhat.com (Stan Silvert)
Date: Fri, 20 Apr 2018 08:59:08 -0400
Subject: [keycloak-dev] Internationalization - question
In-Reply-To: <DB5PR02MB1685E7433B3077A16B4178239DB40@DB5PR02MB1685.eurprd02.prod.outlook.com>
References: <DB5PR02MB1685E7433B3077A16B4178239DB40@DB5PR02MB1685.eurprd02.prod.outlook.com>
Message-ID: <0b5f9318-4d0f-4a9b-ad4a-ca4e06793f44@redhat.com>

 From the code, it looks like locale.supported will return a 
List<Locale>.?? This is not the regular java object Locale.? It is 
another version of Locale that only can return label and url.? However, 
the url will have an attribute kc_locale=<language code>.? So you could 
parse the url and extract the language code.

BTW, I agree with you.? For the next version of the account management 
console the language code should be much easier to get.


On 4/20/2018 7:46 AM, Adrien DESBIAUX wrote:
> Hello!
>
> I would like to be sure to understand well how internationalization works in KC:
>
> I can only access those 2 variables in the template:
>
> - locale.supported
> and
> - locale.current
>
> https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/theme/beans/LocaleBean.java
>
>
> My issue is that ${locale.current} return the "language name" as a string.
>
> But it would be very helpful to get the language code instead or another property to get for example "de" for Deutsch. That would make internationalization logics more standard to other tools.
>
>
> Would you agree or did I miss something?
>
>
> Thank you in advance for your feedback.
>
>
> Keycloak is still an awesome tool :)
>
>
> Cheers!
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



From sthorger at redhat.com  Mon Apr 23 15:10:01 2018
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 23 Apr 2018 21:10:01 +0200
Subject: [keycloak-dev] OIDC Identity Brokering with Client parameter
	forward
In-Reply-To: <KAXPR01MB10938D8AA21CA962542AF1B1CEB40@KAXPR01MB1093.jpnprd01.prod.outlook.com>
References: <KAXPR01MB10938D8AA21CA962542AF1B1CEB40@KAXPR01MB1093.jpnprd01.prod.outlook.com>
Message-ID: <CAJgngAe_0emRHZWtFzU2KQgUjDihjDLua-knXNN-epOi1guyTg@mail.gmail.com>

Please see discussion on GitHub PR.

On 20 April 2018 at 03:10, ???? / NORIMATSU?TAKASHI <
takashi.norimatsu.ws at hitachi.com> wrote:

> Hello.
>
> When using OIDC Identity Brokering, I've found that the keycloak's
> built-in OIDC Identity Brokering provider does not have the feature of
> forwarding some parameters originated from a client application to an
> external IdP.
>
> Such the feature might be beneficial when you host its own IdP and want to
> configure its UX based on forwarded client parameters and so on.
>
> Previously, I had realized this feature by implementing custom
> Authentication provider and User Storage provider.
> However, it had been too much complicated and I had the advice to use
> Identity Brokering.
> https://github.com/keycloak/keycloak/pull/4260
>
> Therefore, I've implemented this feature(Forwarding parameters) based on
> this OIDC Identity Brokering built-in provider.
> https://github.com/keycloak/keycloak/pull/5163
>
> Forwarded parameters are prefixed with "fwd_".
>
> It needs some documentation so that I'd like to do that if this proposal
> is accepted.
>
> Also, I've created corresponding JIRA ticket.
> https://issues.jboss.org/browse/KEYCLOAK-7201
>
> Hope this PR is reviewed and merged.
>
> Best Regards
> Takashi Norimatsu
> Hitachi, Ltd.
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sthorger at redhat.com  Mon Apr 23 16:06:35 2018
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 23 Apr 2018 22:06:35 +0200
Subject: [keycloak-dev] Blocker for 4.0.0.Beta2 release
Message-ID: <CAJgngAdmS2PfvQ9X1QSkOQNrXzMmefQ2pyxT=kSWC71t=MnH1Q@mail.gmail.com>

I've found a block for the 4.0.0.Beta2 release.

It seems to be caused when you have cookies from a previous installation
and upgrade to master. This is causing a redirect loop:

https://issues.jboss.org/browse/KEYCLOAK-7221

I believe this may have been caused by
https://issues.jboss.org/browse/KEYCLOAK-5270.

From sthorger at redhat.com  Tue Apr 24 03:15:14 2018
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 24 Apr 2018 09:15:14 +0200
Subject: [keycloak-dev] Keycloak Questionnaire
Message-ID: <CAJgngAfGMonAxabadrYy7H0ZHVPmm6geOr72XWuxLEf1pnveAw@mail.gmail.com>

We would love to gather some information on who is using Keycloak and how
it is being used. With that intent we have created a form here
https://goo.gl/forms/TRSmCCU6eX25prhH2

I would greatly appreciate if as many as possible can fill this in.

Thanks,
Stian Thorgersen
Keycloak Project Lead

From giovannicandido at outlook.com  Tue Apr 24 07:15:50 2018
From: giovannicandido at outlook.com (Giovanni Silva)
Date: Tue, 24 Apr 2018 11:15:50 +0000
Subject: [keycloak-dev] Angular Integration
Message-ID: <MWHPR15MB13909249A5E0ACC153B46257A9880@MWHPR15MB1390.namprd15.prod.outlook.com>

Hi,
Based on the awesome work in keycloak-js, I created integration with Angular 2 (4, 5), one of the most wide used javascript frameworks.

The integration expands on a couple of different ways:

Provide directives for condition hide display DOM elements, based on user roles

Provide Login guards for angular routes that intercept a not logged user and initiate the Oauth2 flow

Provide a service to be injected for queries like username and email

Automatically refresh and add the token on every http request to server, without any intervention.

It can also be used in ionic mobile applications, but I did not test this.

If anyone is interested in the project, I would appreciate any feedback or collaboration.

Code is release in MIT license

What is missing:

Authorization service integration (there is only role based directives)

More user cases

Code: https://github.com/giovannicandido/angular-spa
Docs: https://angular-spa.netlify.com
Demo: https://github.com/giovannicandido/angular-spa-example

Thanks,
Giovanni Silva


From vramik at redhat.com  Tue Apr 24 07:45:30 2018
From: vramik at redhat.com (Vlasta Ramik)
Date: Tue, 24 Apr 2018 13:45:30 +0200
Subject: [keycloak-dev] as7 wildfly8 adapter
Message-ID: <77fe5165-f79d-1f4e-15f7-2b800188efb6@redhat.com>

Hey guys,

I was considering a removal of as7 adapter (EAP6 adapter stays) and also 
wildfly8 adapter. AFAIK there was just few downloads of those in the 
past months.

I'm working on different test framework for adapter tests and IMO there 
is a waste of time to put an effort into those.

Any concerns or ideas?

Thanks

Vlasta


From Shankar_Bhaskaran at infosys.com  Tue Apr 24 08:24:49 2018
From: Shankar_Bhaskaran at infosys.com (Shankar_Bhaskaran)
Date: Tue, 24 Apr 2018 12:24:49 +0000
Subject: [keycloak-dev] No of Users
Message-ID: <KU1PR02MB2437800EF5DFC0DD0264EC6D9E880@KU1PR02MB2437.apcprd02.prod.outlook.com>

Hi ,

Is there any performance tests done to determine how many users can keycloak support .  Will it be able to support a million users if it is properly clustered

Regards,
Shankar

From psilva at redhat.com  Tue Apr 24 08:41:19 2018
From: psilva at redhat.com (Pedro Igor Silva)
Date: Tue, 24 Apr 2018 09:41:19 -0300
Subject: [keycloak-dev] OAuth2 Incremental Authorization
Message-ID: <CAJrcDBfFHU8G7Uv_AonPsGRd84RZjrJZuYS9deGuLN7Tx3vt9g@mail.gmail.com>

Hi,

I think this is related with what we discussed in our last meeting
regarding scopes.

See https://datatracker.ietf.org/doc/draft-wdenniss-oauth-incremental-auth/.

We have that in AuthZ Services, but this should be pure OAuth2.

Regards.
Pedro Igor

From sthorger at redhat.com  Wed Apr 25 03:13:24 2018
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 25 Apr 2018 09:13:24 +0200
Subject: [keycloak-dev] OAuth2 Incremental Authorization
In-Reply-To: <CAJrcDBfFHU8G7Uv_AonPsGRd84RZjrJZuYS9deGuLN7Tx3vt9g@mail.gmail.com>
References: <CAJrcDBfFHU8G7Uv_AonPsGRd84RZjrJZuYS9deGuLN7Tx3vt9g@mail.gmail.com>
Message-ID: <CAJgngAdKgMnXw-2mm-k6oYe+S52ba10Mi=6ZaP67UyDJCb+DHA@mail.gmail.com>

Haven't read that spec yet. With Marek's work it should be possible for a
client to request additional scopes by redirecting to login screen again,
but there's probably more to it than that. One thing that at least comes to
mind is that it should be the same authentication session.

On 24 April 2018 at 14:41, Pedro Igor Silva <psilva at redhat.com> wrote:

> Hi,
>
> I think this is related with what we discussed in our last meeting
> regarding scopes.
>
> See https://datatracker.ietf.org/doc/draft-wdenniss-oauth-
> incremental-auth/.
>
> We have that in AuthZ Services, but this should be pure OAuth2.
>
> Regards.
> Pedro Igor
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sthorger at redhat.com  Wed Apr 25 03:26:54 2018
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 25 Apr 2018 09:26:54 +0200
Subject: [keycloak-dev] as7 wildfly8 adapter
In-Reply-To: <77fe5165-f79d-1f4e-15f7-2b800188efb6@redhat.com>
References: <77fe5165-f79d-1f4e-15f7-2b800188efb6@redhat.com>
Message-ID: <CAJgngAdyj1=bbWhFGc3usb7N6oKCdHQVOHgaZ8Er=c4+6U_jjw@mail.gmail.com>

We can't keep supporting all old versions in-definitively so I agree with
removing these. It's been a long long time since AS7 and WildFly 8 was
released.

Here's some concrete download numbers from keycloak.org for 3.4.3.Final
adapters:

* WildFly adapter - 1140 dls
* AS7 adapter - 51 dls
* WF8 adapter - 42 dls

42 downloads doesn't translate into 42 users. My guess that translates into
perhaps 10-20 users.

Now while we're at it let's also look at Tomcat and Jetty:

* Tomcat 8 - 480
* Tomcat 7 - 113
* Tomcat 6 - 33
* Jetty 9.4 - 69
* Jetty 9.3 - 7
* Jetty 9.2 - 6
* Jetty 9.1 - 3
* Jetty 8.1 - 4

The list that looks obvious to remove to me are WF8, AS7, Tomcat 6, Jetty
9.3-Jetty 8.1.

Now let's consider the options for those few that may still be using:

* Stick with Keycloak 3.4.3.Final adapter
* Switch to the coming Keycloak Proxy adapter
* A different OIDC library
* Upgrade the container (this is what they should be doing really)

On 24 April 2018 at 13:45, Vlasta Ramik <vramik at redhat.com> wrote:

> Hey guys,
>
> I was considering a removal of as7 adapter (EAP6 adapter stays) and also
> wildfly8 adapter. AFAIK there was just few downloads of those in the
> past months.
>
> I'm working on different test framework for adapter tests and IMO there
> is a waste of time to put an effort into those.
>
> Any concerns or ideas?
>
> Thanks
>
> Vlasta
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From hmlnarik at redhat.com  Wed Apr 25 05:09:24 2018
From: hmlnarik at redhat.com (Hynek Mlnarik)
Date: Wed, 25 Apr 2018 11:09:24 +0200
Subject: [keycloak-dev] as7 wildfly8 adapter
In-Reply-To: <CAJgngAdyj1=bbWhFGc3usb7N6oKCdHQVOHgaZ8Er=c4+6U_jjw@mail.gmail.com>
References: <77fe5165-f79d-1f4e-15f7-2b800188efb6@redhat.com>
	<CAJgngAdyj1=bbWhFGc3usb7N6oKCdHQVOHgaZ8Er=c4+6U_jjw@mail.gmail.com>
Message-ID: <CAMvXD=FuD44GdxZ8V3yC4j-kx2Fj6X+_Q9FuHD6zS4aVS=h6Rw@mail.gmail.com>

I agree with all but Jetty 9.2 and 8.1 - those are needed for Fuse 6.3
support.

--Hynek

On Wed, Apr 25, 2018 at 9:26 AM, Stian Thorgersen <sthorger at redhat.com>
wrote:

> We can't keep supporting all old versions in-definitively so I agree with
> removing these. It's been a long long time since AS7 and WildFly 8 was
> released.
>
> Here's some concrete download numbers from keycloak.org for 3.4.3.Final
> adapters:
>
> * WildFly adapter - 1140 dls
> * AS7 adapter - 51 dls
> * WF8 adapter - 42 dls
>
> 42 downloads doesn't translate into 42 users. My guess that translates into
> perhaps 10-20 users.
>
> Now while we're at it let's also look at Tomcat and Jetty:
>
> * Tomcat 8 - 480
> * Tomcat 7 - 113
> * Tomcat 6 - 33
> * Jetty 9.4 - 69
> * Jetty 9.3 - 7
> * Jetty 9.2 - 6
> * Jetty 9.1 - 3
> * Jetty 8.1 - 4
>
> The list that looks obvious to remove to me are WF8, AS7, Tomcat 6, Jetty
> 9.3-Jetty 8.1.
>
> Now let's consider the options for those few that may still be using:
>
> * Stick with Keycloak 3.4.3.Final adapter
> * Switch to the coming Keycloak Proxy adapter
> * A different OIDC library
> * Upgrade the container (this is what they should be doing really)
>
> On 24 April 2018 at 13:45, Vlasta Ramik <vramik at redhat.com> wrote:
>
> > Hey guys,
> >
> > I was considering a removal of as7 adapter (EAP6 adapter stays) and also
> > wildfly8 adapter. AFAIK there was just few downloads of those in the
> > past months.
> >
> > I'm working on different test framework for adapter tests and IMO there
> > is a waste of time to put an effort into those.
> >
> > Any concerns or ideas?
> >
> > Thanks
> >
> > Vlasta
> >
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>



-- 

--Hynek

From psilva at redhat.com  Wed Apr 25 07:50:10 2018
From: psilva at redhat.com (Pedro Igor Silva)
Date: Wed, 25 Apr 2018 08:50:10 -0300
Subject: [keycloak-dev] OAuth2 Incremental Authorization
In-Reply-To: <CAJgngAdKgMnXw-2mm-k6oYe+S52ba10Mi=6ZaP67UyDJCb+DHA@mail.gmail.com>
References: <CAJrcDBfFHU8G7Uv_AonPsGRd84RZjrJZuYS9deGuLN7Tx3vt9g@mail.gmail.com>
	<CAJgngAdKgMnXw-2mm-k6oYe+S52ba10Mi=6ZaP67UyDJCb+DHA@mail.gmail.com>
Message-ID: <CAJrcDBdC4Jqyg2nPLmQhBgz1qQwn2FY-r5+5Th1yqZVVVeWBKA@mail.gmail.com>

Yeah, I agree it should be the same authentication session. And that spec
can be a good reference to make sure we are doing it correctly or at least
based on other experiences around this requirement.

>From what I have seen in oauth2 mailing list, people there are willing to
make it a standard.

On Wed, Apr 25, 2018 at 4:13 AM, Stian Thorgersen <sthorger at redhat.com>
wrote:

> Haven't read that spec yet. With Marek's work it should be possible for a
> client to request additional scopes by redirecting to login screen again,
> but there's probably more to it than that. One thing that at least comes to
> mind is that it should be the same authentication session.
>
> On 24 April 2018 at 14:41, Pedro Igor Silva <psilva at redhat.com> wrote:
>
>> Hi,
>>
>> I think this is related with what we discussed in our last meeting
>> regarding scopes.
>>
>> See https://datatracker.ietf.org/doc/draft-wdenniss-oauth-increm
>> ental-auth/.
>>
>> We have that in AuthZ Services, but this should be pure OAuth2.
>>
>> Regards.
>> Pedro Igor
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>

From bburke at redhat.com  Wed Apr 25 09:05:22 2018
From: bburke at redhat.com (Bill Burke)
Date: Wed, 25 Apr 2018 09:05:22 -0400
Subject: [keycloak-dev] OAuth2 Incremental Authorization
In-Reply-To: <CAJrcDBdC4Jqyg2nPLmQhBgz1qQwn2FY-r5+5Th1yqZVVVeWBKA@mail.gmail.com>
References: <CAJrcDBfFHU8G7Uv_AonPsGRd84RZjrJZuYS9deGuLN7Tx3vt9g@mail.gmail.com>
	<CAJgngAdKgMnXw-2mm-k6oYe+S52ba10Mi=6ZaP67UyDJCb+DHA@mail.gmail.com>
	<CAJrcDBdC4Jqyg2nPLmQhBgz1qQwn2FY-r5+5Th1yqZVVVeWBKA@mail.gmail.com>
Message-ID: <CABRXCmxF2zRMzuSchVB2ECqWPWAAmTSJ+S-63GBsC9PO2su3EQ@mail.gmail.com>

I'll ping the OAuth WG, but, its kind of redundant with token
exchange.  Unless client requires consent, not sure why this option
would be used.  Interesting that they require refresh token as a
credential for public clients though.

On Wed, Apr 25, 2018 at 7:50 AM, Pedro Igor Silva <psilva at redhat.com> wrote:
> Yeah, I agree it should be the same authentication session. And that spec
> can be a good reference to make sure we are doing it correctly or at least
> based on other experiences around this requirement.
>
> >From what I have seen in oauth2 mailing list, people there are willing to
> make it a standard.
>
> On Wed, Apr 25, 2018 at 4:13 AM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> Haven't read that spec yet. With Marek's work it should be possible for a
>> client to request additional scopes by redirecting to login screen again,
>> but there's probably more to it than that. One thing that at least comes to
>> mind is that it should be the same authentication session.
>>
>> On 24 April 2018 at 14:41, Pedro Igor Silva <psilva at redhat.com> wrote:
>>
>>> Hi,
>>>
>>> I think this is related with what we discussed in our last meeting
>>> regarding scopes.
>>>
>>> See https://datatracker.ietf.org/doc/draft-wdenniss-oauth-increm
>>> ental-auth/.
>>>
>>> We have that in AuthZ Services, but this should be pure OAuth2.
>>>
>>> Regards.
>>> Pedro Igor
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



-- 
Bill Burke
Red Hat

From psilva at redhat.com  Wed Apr 25 09:31:20 2018
From: psilva at redhat.com (Pedro Igor Silva)
Date: Wed, 25 Apr 2018 10:31:20 -0300
Subject: [keycloak-dev] OAuth2 Incremental Authorization
In-Reply-To: <CABRXCmxF2zRMzuSchVB2ECqWPWAAmTSJ+S-63GBsC9PO2su3EQ@mail.gmail.com>
References: <CAJrcDBfFHU8G7Uv_AonPsGRd84RZjrJZuYS9deGuLN7Tx3vt9g@mail.gmail.com>
	<CAJgngAdKgMnXw-2mm-k6oYe+S52ba10Mi=6ZaP67UyDJCb+DHA@mail.gmail.com>
	<CAJrcDBdC4Jqyg2nPLmQhBgz1qQwn2FY-r5+5Th1yqZVVVeWBKA@mail.gmail.com>
	<CABRXCmxF2zRMzuSchVB2ECqWPWAAmTSJ+S-63GBsC9PO2su3EQ@mail.gmail.com>
Message-ID: <CAJrcDBcom2FXjqis+BhpFRJKjg-zO_-fnxEXhRWmGC02kq0oHA@mail.gmail.com>

I'm not sure if the spec is redundant because of token exchange. Token
exchange aims a different use case and this stuff is just about incremental
authorization and granting scopes on demand. AFAIK, there is no change of
audience as it is all about an existing session (in case of public clients
+ refresh token) or previously granted scopes (in case of confidential
clients + client credentials).

Yeah, it is interesting. I think they are using a refresh token in order to
make sure client is obtaining tokens within the same session.

On Wed, Apr 25, 2018 at 10:05 AM, Bill Burke <bburke at redhat.com> wrote:

> I'll ping the OAuth WG, but, its kind of redundant with token
> exchange.  Unless client requires consent, not sure why this option
> would be used.  Interesting that they require refresh token as a
> credential for public clients though.
>
> On Wed, Apr 25, 2018 at 7:50 AM, Pedro Igor Silva <psilva at redhat.com>
> wrote:
> > Yeah, I agree it should be the same authentication session. And that spec
> > can be a good reference to make sure we are doing it correctly or at
> least
> > based on other experiences around this requirement.
> >
> > >From what I have seen in oauth2 mailing list, people there are willing
> to
> > make it a standard.
> >
> > On Wed, Apr 25, 2018 at 4:13 AM, Stian Thorgersen <sthorger at redhat.com>
> > wrote:
> >
> >> Haven't read that spec yet. With Marek's work it should be possible for
> a
> >> client to request additional scopes by redirecting to login screen
> again,
> >> but there's probably more to it than that. One thing that at least
> comes to
> >> mind is that it should be the same authentication session.
> >>
> >> On 24 April 2018 at 14:41, Pedro Igor Silva <psilva at redhat.com> wrote:
> >>
> >>> Hi,
> >>>
> >>> I think this is related with what we discussed in our last meeting
> >>> regarding scopes.
> >>>
> >>> See https://datatracker.ietf.org/doc/draft-wdenniss-oauth-increm
> >>> ental-auth/.
> >>>
> >>> We have that in AuthZ Services, but this should be pure OAuth2.
> >>>
> >>> Regards.
> >>> Pedro Igor
> >>> _______________________________________________
> >>> keycloak-dev mailing list
> >>> keycloak-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>
> >>
> >>
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
> --
> Bill Burke
> Red Hat
>

From youssef.elhouti at gmail.com  Wed Apr 25 10:01:17 2018
From: youssef.elhouti at gmail.com (Youssef EL HOUTI)
Date: Wed, 25 Apr 2018 16:01:17 +0200
Subject: [keycloak-dev] OAuth2 Incremental Authorization
In-Reply-To: <CAJrcDBcom2FXjqis+BhpFRJKjg-zO_-fnxEXhRWmGC02kq0oHA@mail.gmail.com>
References: <CAJrcDBfFHU8G7Uv_AonPsGRd84RZjrJZuYS9deGuLN7Tx3vt9g@mail.gmail.com>
	<CAJgngAdKgMnXw-2mm-k6oYe+S52ba10Mi=6ZaP67UyDJCb+DHA@mail.gmail.com>
	<CAJrcDBdC4Jqyg2nPLmQhBgz1qQwn2FY-r5+5Th1yqZVVVeWBKA@mail.gmail.com>
	<CABRXCmxF2zRMzuSchVB2ECqWPWAAmTSJ+S-63GBsC9PO2su3EQ@mail.gmail.com>
	<CAJrcDBcom2FXjqis+BhpFRJKjg-zO_-fnxEXhRWmGC02kq0oHA@mail.gmail.com>
Message-ID: <CAMZkV7yxgP29_6p=O6q53E9xJ7MfVd1R5+0Wq+UNJFOtvLzAsQ@mail.gmail.com>

Many issues have been opened previously about step up/adaptive
authentication, with the idea to trigger Authentication Steps only if a
Level of security is required (with security levels mapped to scopes...),
IMO this could be a good time to implement the two.

On Wed, Apr 25, 2018 at 3:31 PM, Pedro Igor Silva <psilva at redhat.com> wrote:

> I'm not sure if the spec is redundant because of token exchange. Token
> exchange aims a different use case and this stuff is just about incremental
> authorization and granting scopes on demand. AFAIK, there is no change of
> audience as it is all about an existing session (in case of public clients
> + refresh token) or previously granted scopes (in case of confidential
> clients + client credentials).
>
> Yeah, it is interesting. I think they are using a refresh token in order to
> make sure client is obtaining tokens within the same session.
>
> On Wed, Apr 25, 2018 at 10:05 AM, Bill Burke <bburke at redhat.com> wrote:
>
> > I'll ping the OAuth WG, but, its kind of redundant with token
> > exchange.  Unless client requires consent, not sure why this option
> > would be used.  Interesting that they require refresh token as a
> > credential for public clients though.
> >
> > On Wed, Apr 25, 2018 at 7:50 AM, Pedro Igor Silva <psilva at redhat.com>
> > wrote:
> > > Yeah, I agree it should be the same authentication session. And that
> spec
> > > can be a good reference to make sure we are doing it correctly or at
> > least
> > > based on other experiences around this requirement.
> > >
> > > >From what I have seen in oauth2 mailing list, people there are willing
> > to
> > > make it a standard.
> > >
> > > On Wed, Apr 25, 2018 at 4:13 AM, Stian Thorgersen <sthorger at redhat.com
> >
> > > wrote:
> > >
> > >> Haven't read that spec yet. With Marek's work it should be possible
> for
> > a
> > >> client to request additional scopes by redirecting to login screen
> > again,
> > >> but there's probably more to it than that. One thing that at least
> > comes to
> > >> mind is that it should be the same authentication session.
> > >>
> > >> On 24 April 2018 at 14:41, Pedro Igor Silva <psilva at redhat.com>
> wrote:
> > >>
> > >>> Hi,
> > >>>
> > >>> I think this is related with what we discussed in our last meeting
> > >>> regarding scopes.
> > >>>
> > >>> See https://datatracker.ietf.org/doc/draft-wdenniss-oauth-increm
> > >>> ental-auth/.
> > >>>
> > >>> We have that in AuthZ Services, but this should be pure OAuth2.
> > >>>
> > >>> Regards.
> > >>> Pedro Igor
> > >>> _______________________________________________
> > >>> keycloak-dev mailing list
> > >>> keycloak-dev at lists.jboss.org
> > >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > >>>
> > >>
> > >>
> > > _______________________________________________
> > > keycloak-dev mailing list
> > > keycloak-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> >
> >
> > --
> > Bill Burke
> > Red Hat
> >
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From psilva at redhat.com  Wed Apr 25 10:13:40 2018
From: psilva at redhat.com (Pedro Igor Silva)
Date: Wed, 25 Apr 2018 11:13:40 -0300
Subject: [keycloak-dev] OAuth2 Incremental Authorization
In-Reply-To: <CAJrcDBcom2FXjqis+BhpFRJKjg-zO_-fnxEXhRWmGC02kq0oHA@mail.gmail.com>
References: <CAJrcDBfFHU8G7Uv_AonPsGRd84RZjrJZuYS9deGuLN7Tx3vt9g@mail.gmail.com>
	<CAJgngAdKgMnXw-2mm-k6oYe+S52ba10Mi=6ZaP67UyDJCb+DHA@mail.gmail.com>
	<CAJrcDBdC4Jqyg2nPLmQhBgz1qQwn2FY-r5+5Th1yqZVVVeWBKA@mail.gmail.com>
	<CABRXCmxF2zRMzuSchVB2ECqWPWAAmTSJ+S-63GBsC9PO2su3EQ@mail.gmail.com>
	<CAJrcDBcom2FXjqis+BhpFRJKjg-zO_-fnxEXhRWmGC02kq0oHA@mail.gmail.com>
Message-ID: <CAJrcDBdybJphaN5rrG_sHFuhJGfL9V1A+tCUxtqWTnzjW1wv1Q@mail.gmail.com>

On Wed, Apr 25, 2018 at 10:31 AM, Pedro Igor Silva <psilva at redhat.com>
wrote:

> I'm not sure if the spec is redundant because of token exchange. Token
> exchange aims a different use case and this stuff is just about incremental
> authorization and granting scopes on demand. AFAIK, there is no change of
> audience as it is all about an existing session (in case of public clients
> + refresh token) or previously granted scopes (in case of confidential
> clients + client credentials).
>

In fact you should be able to have different audiences depending on the
scopes you ask. But it is not suitable for using token types other than
regular urn:ietf:params:oauth:token-type:access_token or obtaining a token
for delegation. Maybe impersonation at a certain degree as the client is
still acting on user behalf. But with incremental authorization the client
to which the token was issued for is always the same.


>
> Yeah, it is interesting. I think they are using a refresh token in order
> to make sure client is obtaining tokens within the same session.
>
> On Wed, Apr 25, 2018 at 10:05 AM, Bill Burke <bburke at redhat.com> wrote:
>
>> I'll ping the OAuth WG, but, its kind of redundant with token
>> exchange.  Unless client requires consent, not sure why this option
>> would be used.  Interesting that they require refresh token as a
>> credential for public clients though.
>>
>> On Wed, Apr 25, 2018 at 7:50 AM, Pedro Igor Silva <psilva at redhat.com>
>> wrote:
>> > Yeah, I agree it should be the same authentication session. And that
>> spec
>> > can be a good reference to make sure we are doing it correctly or at
>> least
>> > based on other experiences around this requirement.
>> >
>> > >From what I have seen in oauth2 mailing list, people there are willing
>> to
>> > make it a standard.
>> >
>> > On Wed, Apr 25, 2018 at 4:13 AM, Stian Thorgersen <sthorger at redhat.com>
>> > wrote:
>> >
>> >> Haven't read that spec yet. With Marek's work it should be possible
>> for a
>> >> client to request additional scopes by redirecting to login screen
>> again,
>> >> but there's probably more to it than that. One thing that at least
>> comes to
>> >> mind is that it should be the same authentication session.
>> >>
>> >> On 24 April 2018 at 14:41, Pedro Igor Silva <psilva at redhat.com> wrote:
>> >>
>> >>> Hi,
>> >>>
>> >>> I think this is related with what we discussed in our last meeting
>> >>> regarding scopes.
>> >>>
>> >>> See https://datatracker.ietf.org/doc/draft-wdenniss-oauth-increm
>> >>> ental-auth/.
>> >>>
>> >>> We have that in AuthZ Services, but this should be pure OAuth2.
>> >>>
>> >>> Regards.
>> >>> Pedro Igor
>> >>> _______________________________________________
>> >>> keycloak-dev mailing list
>> >>> keycloak-dev at lists.jboss.org
>> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> >>>
>> >>
>> >>
>> > _______________________________________________
>> > keycloak-dev mailing list
>> > keycloak-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>>
>> --
>> Bill Burke
>> Red Hat
>>
>
>

From psilva at redhat.com  Wed Apr 25 10:45:53 2018
From: psilva at redhat.com (Pedro Igor Silva)
Date: Wed, 25 Apr 2018 11:45:53 -0300
Subject: [keycloak-dev] OAuth2 Incremental Authorization
In-Reply-To: <CAMZkV7yxgP29_6p=O6q53E9xJ7MfVd1R5+0Wq+UNJFOtvLzAsQ@mail.gmail.com>
References: <CAJrcDBfFHU8G7Uv_AonPsGRd84RZjrJZuYS9deGuLN7Tx3vt9g@mail.gmail.com>
	<CAJgngAdKgMnXw-2mm-k6oYe+S52ba10Mi=6ZaP67UyDJCb+DHA@mail.gmail.com>
	<CAJrcDBdC4Jqyg2nPLmQhBgz1qQwn2FY-r5+5Th1yqZVVVeWBKA@mail.gmail.com>
	<CABRXCmxF2zRMzuSchVB2ECqWPWAAmTSJ+S-63GBsC9PO2su3EQ@mail.gmail.com>
	<CAJrcDBcom2FXjqis+BhpFRJKjg-zO_-fnxEXhRWmGC02kq0oHA@mail.gmail.com>
	<CAMZkV7yxgP29_6p=O6q53E9xJ7MfVd1R5+0Wq+UNJFOtvLzAsQ@mail.gmail.com>
Message-ID: <CAJrcDBfD7F37HfhMczYiOCW21pYredEJ1ByoXVpknShQNdOAHg@mail.gmail.com>

Adaptive authentication is a separated beast though as it may also
be related to risk-based authentication/authorization. Some form of
calculation based on different sources of information to obtain some score
to then take some action. It is a hell of a feature depending on how much
we want to invest in it.

On Wed, Apr 25, 2018 at 11:01 AM, Youssef EL HOUTI <
youssef.elhouti at gmail.com> wrote:

> Many issues have been opened previously about step up/adaptive
> authentication, with the idea to trigger Authentication Steps only if a
> Level of security is required (with security levels mapped to scopes...),
> IMO this could be a good time to implement the two.
>
> On Wed, Apr 25, 2018 at 3:31 PM, Pedro Igor Silva <psilva at redhat.com>
> wrote:
>
>> I'm not sure if the spec is redundant because of token exchange. Token
>> exchange aims a different use case and this stuff is just about
>> incremental
>> authorization and granting scopes on demand. AFAIK, there is no change of
>> audience as it is all about an existing session (in case of public clients
>> + refresh token) or previously granted scopes (in case of confidential
>> clients + client credentials).
>>
>> Yeah, it is interesting. I think they are using a refresh token in order
>> to
>> make sure client is obtaining tokens within the same session.
>>
>> On Wed, Apr 25, 2018 at 10:05 AM, Bill Burke <bburke at redhat.com> wrote:
>>
>> > I'll ping the OAuth WG, but, its kind of redundant with token
>> > exchange.  Unless client requires consent, not sure why this option
>> > would be used.  Interesting that they require refresh token as a
>> > credential for public clients though.
>> >
>> > On Wed, Apr 25, 2018 at 7:50 AM, Pedro Igor Silva <psilva at redhat.com>
>> > wrote:
>> > > Yeah, I agree it should be the same authentication session. And that
>> spec
>> > > can be a good reference to make sure we are doing it correctly or at
>> > least
>> > > based on other experiences around this requirement.
>> > >
>> > > >From what I have seen in oauth2 mailing list, people there are
>> willing
>> > to
>> > > make it a standard.
>> > >
>> > > On Wed, Apr 25, 2018 at 4:13 AM, Stian Thorgersen <
>> sthorger at redhat.com>
>> > > wrote:
>> > >
>> > >> Haven't read that spec yet. With Marek's work it should be possible
>> for
>> > a
>> > >> client to request additional scopes by redirecting to login screen
>> > again,
>> > >> but there's probably more to it than that. One thing that at least
>> > comes to
>> > >> mind is that it should be the same authentication session.
>> > >>
>> > >> On 24 April 2018 at 14:41, Pedro Igor Silva <psilva at redhat.com>
>> wrote:
>> > >>
>> > >>> Hi,
>> > >>>
>> > >>> I think this is related with what we discussed in our last meeting
>> > >>> regarding scopes.
>> > >>>
>> > >>> See https://datatracker.ietf.org/doc/draft-wdenniss-oauth-increm
>> > >>> ental-auth/.
>> > >>>
>> > >>> We have that in AuthZ Services, but this should be pure OAuth2.
>> > >>>
>> > >>> Regards.
>> > >>> Pedro Igor
>> > >>> _______________________________________________
>> > >>> keycloak-dev mailing list
>> > >>> keycloak-dev at lists.jboss.org
>> > >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> > >>>
>> > >>
>> > >>
>> > > _______________________________________________
>> > > keycloak-dev mailing list
>> > > keycloak-dev at lists.jboss.org
>> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> >
>> >
>> >
>> > --
>> > Bill Burke
>> > Red Hat
>> >
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>

From bburke at redhat.com  Wed Apr 25 10:54:52 2018
From: bburke at redhat.com (Bill Burke)
Date: Wed, 25 Apr 2018 10:54:52 -0400
Subject: [keycloak-dev] OAuth2 Incremental Authorization
In-Reply-To: <CAMZkV7yxgP29_6p=O6q53E9xJ7MfVd1R5+0Wq+UNJFOtvLzAsQ@mail.gmail.com>
References: <CAJrcDBfFHU8G7Uv_AonPsGRd84RZjrJZuYS9deGuLN7Tx3vt9g@mail.gmail.com>
	<CAJgngAdKgMnXw-2mm-k6oYe+S52ba10Mi=6ZaP67UyDJCb+DHA@mail.gmail.com>
	<CAJrcDBdC4Jqyg2nPLmQhBgz1qQwn2FY-r5+5Th1yqZVVVeWBKA@mail.gmail.com>
	<CABRXCmxF2zRMzuSchVB2ECqWPWAAmTSJ+S-63GBsC9PO2su3EQ@mail.gmail.com>
	<CAJrcDBcom2FXjqis+BhpFRJKjg-zO_-fnxEXhRWmGC02kq0oHA@mail.gmail.com>
	<CAMZkV7yxgP29_6p=O6q53E9xJ7MfVd1R5+0Wq+UNJFOtvLzAsQ@mail.gmail.com>
Message-ID: <CABRXCmxB_-6Vrm9wYRc_akZXaqdGiBR-oRaTzqWS+V+6LHrsPg@mail.gmail.com>

FYI, at least in master you can do a "poor man's" step up
authentication as you can define and override authentication flows per
client.  A more structured and formal way of doing this would be 100
times better though.

On Wed, Apr 25, 2018 at 10:01 AM, Youssef EL HOUTI
<youssef.elhouti at gmail.com> wrote:
> Many issues have been opened previously about step up/adaptive
> authentication, with the idea to trigger Authentication Steps only if a
> Level of security is required (with security levels mapped to scopes...),
> IMO this could be a good time to implement the two.
>
> On Wed, Apr 25, 2018 at 3:31 PM, Pedro Igor Silva <psilva at redhat.com> wrote:
>>
>> I'm not sure if the spec is redundant because of token exchange. Token
>> exchange aims a different use case and this stuff is just about
>> incremental
>> authorization and granting scopes on demand. AFAIK, there is no change of
>> audience as it is all about an existing session (in case of public clients
>> + refresh token) or previously granted scopes (in case of confidential
>> clients + client credentials).
>>
>> Yeah, it is interesting. I think they are using a refresh token in order
>> to
>> make sure client is obtaining tokens within the same session.
>>
>> On Wed, Apr 25, 2018 at 10:05 AM, Bill Burke <bburke at redhat.com> wrote:
>>
>> > I'll ping the OAuth WG, but, its kind of redundant with token
>> > exchange.  Unless client requires consent, not sure why this option
>> > would be used.  Interesting that they require refresh token as a
>> > credential for public clients though.
>> >
>> > On Wed, Apr 25, 2018 at 7:50 AM, Pedro Igor Silva <psilva at redhat.com>
>> > wrote:
>> > > Yeah, I agree it should be the same authentication session. And that
>> > > spec
>> > > can be a good reference to make sure we are doing it correctly or at
>> > least
>> > > based on other experiences around this requirement.
>> > >
>> > > >From what I have seen in oauth2 mailing list, people there are
>> > > willing
>> > to
>> > > make it a standard.
>> > >
>> > > On Wed, Apr 25, 2018 at 4:13 AM, Stian Thorgersen
>> > > <sthorger at redhat.com>
>> > > wrote:
>> > >
>> > >> Haven't read that spec yet. With Marek's work it should be possible
>> > >> for
>> > a
>> > >> client to request additional scopes by redirecting to login screen
>> > again,
>> > >> but there's probably more to it than that. One thing that at least
>> > comes to
>> > >> mind is that it should be the same authentication session.
>> > >>
>> > >> On 24 April 2018 at 14:41, Pedro Igor Silva <psilva at redhat.com>
>> > >> wrote:
>> > >>
>> > >>> Hi,
>> > >>>
>> > >>> I think this is related with what we discussed in our last meeting
>> > >>> regarding scopes.
>> > >>>
>> > >>> See https://datatracker.ietf.org/doc/draft-wdenniss-oauth-increm
>> > >>> ental-auth/.
>> > >>>
>> > >>> We have that in AuthZ Services, but this should be pure OAuth2.
>> > >>>
>> > >>> Regards.
>> > >>> Pedro Igor
>> > >>> _______________________________________________
>> > >>> keycloak-dev mailing list
>> > >>> keycloak-dev at lists.jboss.org
>> > >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> > >>>
>> > >>
>> > >>
>> > > _______________________________________________
>> > > keycloak-dev mailing list
>> > > keycloak-dev at lists.jboss.org
>> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> >
>> >
>> >
>> > --
>> > Bill Burke
>> > Red Hat
>> >
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>



-- 
Bill Burke
Red Hat

From bburke at redhat.com  Wed Apr 25 11:06:01 2018
From: bburke at redhat.com (Bill Burke)
Date: Wed, 25 Apr 2018 11:06:01 -0400
Subject: [keycloak-dev] OAuth2 Incremental Authorization
In-Reply-To: <CAJrcDBfD7F37HfhMczYiOCW21pYredEJ1ByoXVpknShQNdOAHg@mail.gmail.com>
References: <CAJrcDBfFHU8G7Uv_AonPsGRd84RZjrJZuYS9deGuLN7Tx3vt9g@mail.gmail.com>
	<CAJgngAdKgMnXw-2mm-k6oYe+S52ba10Mi=6ZaP67UyDJCb+DHA@mail.gmail.com>
	<CAJrcDBdC4Jqyg2nPLmQhBgz1qQwn2FY-r5+5Th1yqZVVVeWBKA@mail.gmail.com>
	<CABRXCmxF2zRMzuSchVB2ECqWPWAAmTSJ+S-63GBsC9PO2su3EQ@mail.gmail.com>
	<CAJrcDBcom2FXjqis+BhpFRJKjg-zO_-fnxEXhRWmGC02kq0oHA@mail.gmail.com>
	<CAMZkV7yxgP29_6p=O6q53E9xJ7MfVd1R5+0Wq+UNJFOtvLzAsQ@mail.gmail.com>
	<CAJrcDBfD7F37HfhMczYiOCW21pYredEJ1ByoXVpknShQNdOAHg@mail.gmail.com>
Message-ID: <CABRXCmxSi0fJ98KKtPaGAuev4zFggq8pRFr+BTDNN1F9pfwu6A@mail.gmail.com>

On Wed, Apr 25, 2018 at 10:45 AM, Pedro Igor Silva <psilva at redhat.com> wrote:
> Adaptive authentication is a separated beast though as it may also be
> related to risk-based authentication/authorization. Some form of calculation
> based on different sources of information to obtain some score to then take
> some action. It is a hell of a feature depending on how much we want to
> invest in it.
>

Lol, that *WOULD* be cool......I always worried that step-up
authentication would be an edge case as most customers/users would
want to require 2nd factor authentication up front.  Would a more
common case be that a certain client scope requires re-authentication?
i.e. to perform a sensitive operation?  FYI, I'm completely
speculating here.

-- 
Bill Burke
Red Hat

From psilva at redhat.com  Wed Apr 25 11:24:14 2018
From: psilva at redhat.com (Pedro Igor Silva)
Date: Wed, 25 Apr 2018 12:24:14 -0300
Subject: [keycloak-dev] OAuth2 Incremental Authorization
In-Reply-To: <CABRXCmxSi0fJ98KKtPaGAuev4zFggq8pRFr+BTDNN1F9pfwu6A@mail.gmail.com>
References: <CAJrcDBfFHU8G7Uv_AonPsGRd84RZjrJZuYS9deGuLN7Tx3vt9g@mail.gmail.com>
	<CAJgngAdKgMnXw-2mm-k6oYe+S52ba10Mi=6ZaP67UyDJCb+DHA@mail.gmail.com>
	<CAJrcDBdC4Jqyg2nPLmQhBgz1qQwn2FY-r5+5Th1yqZVVVeWBKA@mail.gmail.com>
	<CABRXCmxF2zRMzuSchVB2ECqWPWAAmTSJ+S-63GBsC9PO2su3EQ@mail.gmail.com>
	<CAJrcDBcom2FXjqis+BhpFRJKjg-zO_-fnxEXhRWmGC02kq0oHA@mail.gmail.com>
	<CAMZkV7yxgP29_6p=O6q53E9xJ7MfVd1R5+0Wq+UNJFOtvLzAsQ@mail.gmail.com>
	<CAJrcDBfD7F37HfhMczYiOCW21pYredEJ1ByoXVpknShQNdOAHg@mail.gmail.com>
	<CABRXCmxSi0fJ98KKtPaGAuev4zFggq8pRFr+BTDNN1F9pfwu6A@mail.gmail.com>
Message-ID: <CAJrcDBffjA7eRqzH3wnipf5+NMPPQ_J1=k988TqkzePe+=4iBg@mail.gmail.com>

Yeah, I believe so but we could also think about something slightly more
complete/complex ... Like Youseff mentioned, the concept of security levels
could also be an option for something more richer and flexible. For
instance, we could have some way to allow users to:

* Create a security level
* Define what a security level means. For instance, it requires
authentication method X, claims A, B, C. Where claims can be anything, from
user's location to the network he is using.
* Define actions that should be taken in order to gain a security level.
For instance, ask for authentication method X, show a page to provide
arbitrary information.

Then based on the security level check for scopes that require a specific
security level or even allow applications to perform validations based on
the security level available from the token. We would also allow client
applications to redirect the user to Keycloak in order to start a "raise
your level" flow, etc ...

FYI, I'm also completely speculating here :)

On Wed, Apr 25, 2018 at 12:06 PM, Bill Burke <bburke at redhat.com> wrote:

> On Wed, Apr 25, 2018 at 10:45 AM, Pedro Igor Silva <psilva at redhat.com>
> wrote:
> > Adaptive authentication is a separated beast though as it may also be
> > related to risk-based authentication/authorization. Some form of
> calculation
> > based on different sources of information to obtain some score to then
> take
> > some action. It is a hell of a feature depending on how much we want to
> > invest in it.
> >
>
> Lol, that *WOULD* be cool......I always worried that step-up
> authentication would be an edge case as most customers/users would
> want to require 2nd factor authentication up front.  Would a more
> common case be that a certain client scope requires re-authentication?
> i.e. to perform a sensitive operation?  FYI, I'm completely
> speculating here.
>
> --
> Bill Burke
> Red Hat
>

From Sebastian.Schuster at bosch-si.com  Wed Apr 25 12:05:08 2018
From: Sebastian.Schuster at bosch-si.com (Schuster Sebastian (INST/ESY1))
Date: Wed, 25 Apr 2018 16:05:08 +0000
Subject: [keycloak-dev] OAuth2 Incremental Authorization
In-Reply-To: <CABRXCmxSi0fJ98KKtPaGAuev4zFggq8pRFr+BTDNN1F9pfwu6A@mail.gmail.com>
References: <CAJrcDBfFHU8G7Uv_AonPsGRd84RZjrJZuYS9deGuLN7Tx3vt9g@mail.gmail.com>
	<CAJgngAdKgMnXw-2mm-k6oYe+S52ba10Mi=6ZaP67UyDJCb+DHA@mail.gmail.com>
	<CAJrcDBdC4Jqyg2nPLmQhBgz1qQwn2FY-r5+5Th1yqZVVVeWBKA@mail.gmail.com>
	<CABRXCmxF2zRMzuSchVB2ECqWPWAAmTSJ+S-63GBsC9PO2su3EQ@mail.gmail.com>
	<CAJrcDBcom2FXjqis+BhpFRJKjg-zO_-fnxEXhRWmGC02kq0oHA@mail.gmail.com>
	<CAMZkV7yxgP29_6p=O6q53E9xJ7MfVd1R5+0Wq+UNJFOtvLzAsQ@mail.gmail.com>
	<CAJrcDBfD7F37HfhMczYiOCW21pYredEJ1ByoXVpknShQNdOAHg@mail.gmail.com>
	<CABRXCmxSi0fJ98KKtPaGAuev4zFggq8pRFr+BTDNN1F9pfwu6A@mail.gmail.com>
Message-ID: <b4c28e4d16a74cd8909e398a92bba32e@bosch-si.com>

I think security levels should not be tied to client scopes directly because they represent the client's view (what he needs to ask for). Security levels should be bound to the resource servers view because he in the end decides what level of authentication is necessary to get access, e.g. by means of having certain roles in the token... However, I would like that feature.

Best regards,
Sebastian

Mit freundlichen Gr??en / Best regards

Dr.-Ing.  Sebastian Schuster

Engineering and Support (INST/ESY1) 
Bosch?Software Innovations?GmbH | Ullsteinstr. 128 | 12109 Berlin | GERMANY | www.bosch-si.com
Tel. +49 30 726112-485 | Fax +49 30 726112-100 | Sebastian.Schuster at bosch-si.com

Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B 
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten L?cke; Gesch?ftsf?hrung: Dr. Stefan Ferber, Michael Hahn 



-----Original Message-----
From: keycloak-dev-bounces at lists.jboss.org [mailto:keycloak-dev-bounces at lists.jboss.org] On Behalf Of Bill Burke
Sent: Mittwoch, 25. April 2018 17:06
To: Pedro Igor Silva <psilva at redhat.com>
Cc: Thorgersen, Stian <stian at redhat.com>; keycloak-dev <keycloak-dev at lists.jboss.org>
Subject: Re: [keycloak-dev] OAuth2 Incremental Authorization

On Wed, Apr 25, 2018 at 10:45 AM, Pedro Igor Silva <psilva at redhat.com> wrote:
> Adaptive authentication is a separated beast though as it may also be 
> related to risk-based authentication/authorization. Some form of 
> calculation based on different sources of information to obtain some 
> score to then take some action. It is a hell of a feature depending on 
> how much we want to invest in it.
>

Lol, that *WOULD* be cool......I always worried that step-up authentication would be an edge case as most customers/users would want to require 2nd factor authentication up front.  Would a more common case be that a certain client scope requires re-authentication?
i.e. to perform a sensitive operation?  FYI, I'm completely speculating here.

--
Bill Burke
Red Hat
_______________________________________________
keycloak-dev mailing list
keycloak-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev


From bburke at redhat.com  Wed Apr 25 12:37:10 2018
From: bburke at redhat.com (Bill Burke)
Date: Wed, 25 Apr 2018 12:37:10 -0400
Subject: [keycloak-dev] OAuth2 Incremental Authorization
In-Reply-To: <b4c28e4d16a74cd8909e398a92bba32e@bosch-si.com>
References: <CAJrcDBfFHU8G7Uv_AonPsGRd84RZjrJZuYS9deGuLN7Tx3vt9g@mail.gmail.com>
	<CAJgngAdKgMnXw-2mm-k6oYe+S52ba10Mi=6ZaP67UyDJCb+DHA@mail.gmail.com>
	<CAJrcDBdC4Jqyg2nPLmQhBgz1qQwn2FY-r5+5Th1yqZVVVeWBKA@mail.gmail.com>
	<CABRXCmxF2zRMzuSchVB2ECqWPWAAmTSJ+S-63GBsC9PO2su3EQ@mail.gmail.com>
	<CAJrcDBcom2FXjqis+BhpFRJKjg-zO_-fnxEXhRWmGC02kq0oHA@mail.gmail.com>
	<CAMZkV7yxgP29_6p=O6q53E9xJ7MfVd1R5+0Wq+UNJFOtvLzAsQ@mail.gmail.com>
	<CAJrcDBfD7F37HfhMczYiOCW21pYredEJ1ByoXVpknShQNdOAHg@mail.gmail.com>
	<CABRXCmxSi0fJ98KKtPaGAuev4zFggq8pRFr+BTDNN1F9pfwu6A@mail.gmail.com>
	<b4c28e4d16a74cd8909e398a92bba32e@bosch-si.com>
Message-ID: <CABRXCmyh+g6jof9GyepGbeg3Gm0geqGqQ16tabCorpQCoKH50g@mail.gmail.com>

On Wed, Apr 25, 2018 at 12:05 PM, Schuster Sebastian (INST/ESY1)
<Sebastian.Schuster at bosch-si.com> wrote:
> I think security levels should not be tied to client scopes directly because they represent the client's view (what he needs to ask for). Security levels should be bound to the resource servers view because he in the end decides what level of authentication is necessary to get access, e.g. by means of having certain roles in the token... However, I would like that feature.
>

So you think that security levels are decided by the app and not the
administrator?  That an app would request a certain security level
rather than the adminstrator mandating it?  IMO, I would think that it
would be better practice to have this metadata centralized and driven
by Keycloak rather than have the logic in the application.  That way
all the complexity is centralized too and there's a lot less coding
the app/service needs to do.  Think about it...if the app or service
decided on security levels, then any change in security policy would
require a refactor of the app/service and a respin/redeployment of it.
If everything is centralized then the app or service never needs to be
touched and can remain running.  Security policy changes become
immediate.



-- 
Bill Burke
Red Hat


From Sebastian.Schuster at bosch-si.com  Wed Apr 25 13:33:43 2018
From: Sebastian.Schuster at bosch-si.com (Schuster Sebastian (INST/ESY1))
Date: Wed, 25 Apr 2018 17:33:43 +0000
Subject: [keycloak-dev] OAuth2 Incremental Authorization
In-Reply-To: <CABRXCmyh+g6jof9GyepGbeg3Gm0geqGqQ16tabCorpQCoKH50g@mail.gmail.com>
References: <CAJrcDBfFHU8G7Uv_AonPsGRd84RZjrJZuYS9deGuLN7Tx3vt9g@mail.gmail.com>
	<CAJgngAdKgMnXw-2mm-k6oYe+S52ba10Mi=6ZaP67UyDJCb+DHA@mail.gmail.com>
	<CAJrcDBdC4Jqyg2nPLmQhBgz1qQwn2FY-r5+5Th1yqZVVVeWBKA@mail.gmail.com>
	<CABRXCmxF2zRMzuSchVB2ECqWPWAAmTSJ+S-63GBsC9PO2su3EQ@mail.gmail.com>
	<CAJrcDBcom2FXjqis+BhpFRJKjg-zO_-fnxEXhRWmGC02kq0oHA@mail.gmail.com>
	<CAMZkV7yxgP29_6p=O6q53E9xJ7MfVd1R5+0Wq+UNJFOtvLzAsQ@mail.gmail.com>
	<CAJrcDBfD7F37HfhMczYiOCW21pYredEJ1ByoXVpknShQNdOAHg@mail.gmail.com>
	<CABRXCmxSi0fJ98KKtPaGAuev4zFggq8pRFr+BTDNN1F9pfwu6A@mail.gmail.com>
	<b4c28e4d16a74cd8909e398a92bba32e@bosch-si.com>
	<CABRXCmyh+g6jof9GyepGbeg3Gm0geqGqQ16tabCorpQCoKH50g@mail.gmail.com>
Message-ID: <e1b51002206448d3803c0b6e56617330@bosch-si.com>

I still think this should be handled centrally inside Keycloak. I would just tie it to roles or any other token mapper generating a specific claim. Something in the line of the client requests a token, Keycloak finds out that the claims to be added to the token requires a certain security level, looks up the policy for that level and e.g. performs a stronger authentication if required for that level.

Assigning roles/claims to security levels would have to be done by the service developer since only he knows what these claims give access to. We would probably base this on security classifications we have to define for all data we handle anyways.

However, you are right, the policies necessary to get access to certain classification should be defined centrally and not only based on strength of authentication but might depend on things like location, internal/external network and the like... 

Best regards,
Sebastian

Mit freundlichen Gr??en / Best regards

Dr.-Ing.  Sebastian Schuster

Engineering and Support (INST/ESY1) 
Bosch?Software Innovations?GmbH | Ullsteinstr. 128 | 12109 Berlin | GERMANY | www.bosch-si.com
Tel. +49 30 726112-485 | Fax +49 30 726112-100 | Sebastian.Schuster at bosch-si.com

Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B 
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten L?cke; Gesch?ftsf?hrung: Dr. Stefan Ferber, Michael Hahn 




-----Original Message-----
From: Bill Burke [mailto:bburke at redhat.com] 
Sent: Mittwoch, 25. April 2018 18:37
To: Schuster Sebastian (INST/ESY1) <Sebastian.Schuster at bosch-si.com>
Cc: Pedro Igor Silva <psilva at redhat.com>; Thorgersen, Stian <stian at redhat.com>; keycloak-dev <keycloak-dev at lists.jboss.org>
Subject: Re: [keycloak-dev] OAuth2 Incremental Authorization

On Wed, Apr 25, 2018 at 12:05 PM, Schuster Sebastian (INST/ESY1) <Sebastian.Schuster at bosch-si.com> wrote:
> I think security levels should not be tied to client scopes directly because they represent the client's view (what he needs to ask for). Security levels should be bound to the resource servers view because he in the end decides what level of authentication is necessary to get access, e.g. by means of having certain roles in the token... However, I would like that feature.
>

So you think that security levels are decided by the app and not the administrator?  That an app would request a certain security level rather than the adminstrator mandating it?  IMO, I would think that it would be better practice to have this metadata centralized and driven by Keycloak rather than have the logic in the application.  That way all the complexity is centralized too and there's a lot less coding the app/service needs to do.  Think about it...if the app or service decided on security levels, then any change in security policy would require a refactor of the app/service and a respin/redeployment of it.
If everything is centralized then the app or service never needs to be touched and can remain running.  Security policy changes become immediate.



--
Bill Burke
Red Hat


From christian.beikov at gmail.com  Wed Apr 25 16:14:40 2018
From: christian.beikov at gmail.com (Christian Beikov)
Date: Wed, 25 Apr 2018 22:14:40 +0200
Subject: [keycloak-dev] Application and server in separate networks
In-Reply-To: <CAPLPygm2BHoNkrrYMWaOUHx1gGT-PbvSccTNf7JuuLjGeATrLg@mail.gmail.com>
References: <41e1a805-cc38-50cf-f794-cda6afd49313@gmail.com>
	<CAK-7U1gGFnwc3EcgL3whgdGbSTH9xSVwVSHxc1i+JtetJ83H4g@mail.gmail.com>
	<24a0f868-9726-4024-6254-9a0b68b29c9f@gmail.com>
	<569a7f4e-2fa6-6590-2dfb-d7a57c137db2@gmail.com>
	<CAPLPygm2BHoNkrrYMWaOUHx1gGT-PbvSccTNf7JuuLjGeATrLg@mail.gmail.com>
Message-ID: <d52de7b0-0041-46e2-f5ed-479fb0264528@gmail.com>

Hey all,

we reached a point where we are not sure how to proceed with the PR 
https://github.com/keycloak/keycloak/pull/5167 for 
https://issues.jboss.org/browse/KEYCLOAK-7195

We added a client adapter configuration for the flow and that part works 
so far, but we noticed that when the Keycloak server encounters a 
request for authetication via the implicit flow, it puts the token into 
the query fragment part which isn't sent to the application. This is the 
point where it becomes obvious this mechanism is intended for the JS 
adapter :)

To resolve the problem and make the flow usable for the Java adapter as 
well, we'd need some way to configure the response mode in the 
OIDCLoginProtocol. My question is, how you think this should be done.
I was thinking of either allowing a query parameter to specify the 
response mode or a configuration switch in the UI for the client. I kind 
of prefer the query parameter solution.

Is this even a change/feature you would be interested in? We need the 
implicit flow because the Keycloak server is in a private network that 
is separate from the application. Maybe there are other people out there 
that have similar needs?

Mit freundlichen Gr??en,
------------------------------------------------------------------------
*Christian Beikov*
Am 20.04.2018 um 09:15 schrieb Niels Bertram:
> Hi Christian,
>
> can't say for sure but the server side adapters always use standard 
> authorization flow, which requires your Java app to connect via a back 
> channel to (A) exchange code grant for access tokens and (B) to lookup 
> jwks for token validation.
>
> The OpenID Connect specification does provide a pure browser based 
> flow calledimplicit flow 
> <http://openid.net/specs/openid-connect-core-1_0.html#ImplicitFlowAuth>but 
> that one has a few drawbacks such as auth tokens delivered in the 
> redirect URL and no refresh token capability. Using this flow could 
> solve your problem (A) to shift login flow to the frontend but still 
> poses the challenge for (B) validating the tokens at the backend.
>
> I could not find a way to configure the Java adapter to work in pure 
> offline validation mode. We had a similar requirement some time ago 
> and had to code our own auth module to validate incoming tokens with a 
> pre-configured public key. The other common problem we ran into is 
> wanting to validate tokens from different (including non-keycloak) 
> issuers on the same backend. The Keycloak Java adapters do not support 
> this use case either. We originally looked at the Spring JWT adapter 
> <https://github.com/spring-projects/spring-security-oauth/tree/master/spring-security-jwt> 
> as an alternative but this project is not properly patched and 
> configuration is a wonderful garden of mystery like everything in Spring.
>
> Very curious though to see what others are doing.
>
> Cheers,
> Niels
>
>
> On Thu, Apr 19, 2018 at 2:16 AM, Christian Beikov 
> <christian.beikov at gmail.com <mailto:christian.beikov at gmail.com>> wrote:
>
>     As far as I see in the code, the Java Adapters always use the
>     standard
>     flow i.e. response_type=code
>
>     Please tell me this observation is wrong and there is an undocumented
>     setting I just didn't see that I can use to tell the adapter to
>     use the
>     implicit flow instead :|
>
>     If this is really missing, where would you suggest this should be
>     configured? I'd expect the setting to be in KeycloakDeployment and
>     OAuthRequestAuthenticator#loginRedirect would then use the value
>     instead
>     of always using the "code" value.
>
>
>     Mit freundlichen Gr??en,
>     ------------------------------------------------------------------------
>     *Christian Beikov*
>     Am 18.04.2018 um 17:35 schrieb Christian Beikov:
>     >
>     > Is there any way to avoid the access code to access token exchange?
>     > Since the Keycloak server is not accessible, I'm getting an error
>     > during authentication:
>     >
>     > ?ERROR [org.keycloak.adapters.OAuthRequestAuthenticator] (default
>     > task-54) failed to turn code into token:
>     > java.net.UnknownHostException: blabla.local: unknown error
>     > ??????? ...
>     > ??????? at
>     >
>     org.keycloak.adapters.ServerRequest.invokeAccessCodeToToken(ServerRequest.java:111)
>     > ??????? at
>     >
>     org.keycloak.adapters.OAuthRequestAuthenticator.resolveCode(OAuthRequestAuthenticator.java:330)
>     > ??????? at
>     >
>     org.keycloak.adapters.OAuthRequestAuthenticator.authenticate(OAuthRequestAuthenticator.java:275)
>     > ??????? at
>     >
>     org.keycloak.adapters.RequestAuthenticator.authenticate(RequestAuthenticator.java:139)
>     > ??????? at
>     >
>     org.keycloak.adapters.undertow.AbstractUndertowKeycloakAuthMech.keycloakAuthenticate(AbstractUndertowKeycloakAuthMech.java:110)
>     > ??????? at
>     >
>     org.keycloak.adapters.undertow.ServletKeycloakAuthMech.authenticate(ServletKeycloakAuthMech.java:92)
>     > ??????? ...
>     >
>     >
>     > Mit freundlichen Gr??en,
>     >
>     ------------------------------------------------------------------------
>     > *Christian Beikov*
>     > Am 18.04.2018 um 14:48 schrieb Thomas Darimont:
>     >> Hello Christian,
>     >>
>     >> your application server needs to communicate with the Keycloak
>     server
>     >> to retrieve the realm public key referenced in the token to verify
>     >> the token signature.
>     >> The current implementation in Keycloak fetches & caches unknown
>     >> public keys automatically.
>     >>
>     >> You could also use a fixed realm public key on the application
>     server
>     >> side but it would not support key rotation anymore.
>     >>
>     >> Cheers,
>     >> Thomas
>     >>
>     >> 2018-04-18 13:45 GMT+02:00 Christian Beikov
>     >> <christian.beikov at gmail.com <mailto:christian.beikov at gmail.com>
>     <mailto:christian.beikov at gmail.com
>     <mailto:christian.beikov at gmail.com>>>:
>     >>
>     >>? ? ?Hi,
>     >>
>     >>? ? ?is it necessary that an application secured by Keycloak can
>     >>? ? ?access the
>     >>? ? ?Keycloak server? Or is it enough if the Browser can access the
>     >>? ? ?Keycloak
>     >>? ? ?server?
>     >>
>     >>? ? ?--
>     >>
>     >>? ? ?Mit freundlichen Gr??en,
>     >>? ?
>     ?------------------------------------------------------------------------
>     >>? ? ?*Christian Beikov*
>     >>? ? ?_______________________________________________
>     >>? ? ?keycloak-dev mailing list
>     >> keycloak-dev at lists.jboss.org
>     <mailto:keycloak-dev at lists.jboss.org>
>     <mailto:keycloak-dev at lists.jboss.org
>     <mailto:keycloak-dev at lists.jboss.org>>
>     >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>     <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>     >>? ? ?<https://lists.jboss.org/mailman/listinfo/keycloak-dev
>     <https://lists.jboss.org/mailman/listinfo/keycloak-dev>>
>     >>
>     >>
>     >
>
>     _______________________________________________
>     keycloak-dev mailing list
>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>     <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>
>


From bburke at redhat.com  Wed Apr 25 17:20:43 2018
From: bburke at redhat.com (Bill Burke)
Date: Wed, 25 Apr 2018 17:20:43 -0400
Subject: [keycloak-dev] Application and server in separate networks
In-Reply-To: <d52de7b0-0041-46e2-f5ed-479fb0264528@gmail.com>
References: <41e1a805-cc38-50cf-f794-cda6afd49313@gmail.com>
	<CAK-7U1gGFnwc3EcgL3whgdGbSTH9xSVwVSHxc1i+JtetJ83H4g@mail.gmail.com>
	<24a0f868-9726-4024-6254-9a0b68b29c9f@gmail.com>
	<569a7f4e-2fa6-6590-2dfb-d7a57c137db2@gmail.com>
	<CAPLPygm2BHoNkrrYMWaOUHx1gGT-PbvSccTNf7JuuLjGeATrLg@mail.gmail.com>
	<d52de7b0-0041-46e2-f5ed-479fb0264528@gmail.com>
Message-ID: <CABRXCmzfPqd-7rrMzox9UUAXkJZFngU=F6nUfh3ReNcA2P-6qg@mail.gmail.com>

We should probably support response_mode parameter [1] and allow
"query" mode for implicit invocations.  IMO, the HTML POST mode [2]
(like SAML does) would be better as with implicit mode, the access
token is leaked to browser history.

[1] https://openid.net/specs/oauth-v2-multiple-response-types-1_0.html
[2] http://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html

On Wed, Apr 25, 2018 at 4:14 PM, Christian Beikov
<christian.beikov at gmail.com> wrote:
> Hey all,
>
> we reached a point where we are not sure how to proceed with the PR
> https://github.com/keycloak/keycloak/pull/5167 for
> https://issues.jboss.org/browse/KEYCLOAK-7195
>
> We added a client adapter configuration for the flow and that part works
> so far, but we noticed that when the Keycloak server encounters a
> request for authetication via the implicit flow, it puts the token into
> the query fragment part which isn't sent to the application. This is the
> point where it becomes obvious this mechanism is intended for the JS
> adapter :)
>
> To resolve the problem and make the flow usable for the Java adapter as
> well, we'd need some way to configure the response mode in the
> OIDCLoginProtocol. My question is, how you think this should be done.
> I was thinking of either allowing a query parameter to specify the
> response mode or a configuration switch in the UI for the client. I kind
> of prefer the query parameter solution.
>
> Is this even a change/feature you would be interested in? We need the
> implicit flow because the Keycloak server is in a private network that
> is separate from the application. Maybe there are other people out there
> that have similar needs?
>
> Mit freundlichen Gr??en,
> ------------------------------------------------------------------------
> *Christian Beikov*
> Am 20.04.2018 um 09:15 schrieb Niels Bertram:
>> Hi Christian,
>>
>> can't say for sure but the server side adapters always use standard
>> authorization flow, which requires your Java app to connect via a back
>> channel to (A) exchange code grant for access tokens and (B) to lookup
>> jwks for token validation.
>>
>> The OpenID Connect specification does provide a pure browser based
>> flow calledimplicit flow
>> <http://openid.net/specs/openid-connect-core-1_0.html#ImplicitFlowAuth>but
>> that one has a few drawbacks such as auth tokens delivered in the
>> redirect URL and no refresh token capability. Using this flow could
>> solve your problem (A) to shift login flow to the frontend but still
>> poses the challenge for (B) validating the tokens at the backend.
>>
>> I could not find a way to configure the Java adapter to work in pure
>> offline validation mode. We had a similar requirement some time ago
>> and had to code our own auth module to validate incoming tokens with a
>> pre-configured public key. The other common problem we ran into is
>> wanting to validate tokens from different (including non-keycloak)
>> issuers on the same backend. The Keycloak Java adapters do not support
>> this use case either. We originally looked at the Spring JWT adapter
>> <https://github.com/spring-projects/spring-security-oauth/tree/master/spring-security-jwt>
>> as an alternative but this project is not properly patched and
>> configuration is a wonderful garden of mystery like everything in Spring.
>>
>> Very curious though to see what others are doing.
>>
>> Cheers,
>> Niels
>>
>>
>> On Thu, Apr 19, 2018 at 2:16 AM, Christian Beikov
>> <christian.beikov at gmail.com <mailto:christian.beikov at gmail.com>> wrote:
>>
>>     As far as I see in the code, the Java Adapters always use the
>>     standard
>>     flow i.e. response_type=code
>>
>>     Please tell me this observation is wrong and there is an undocumented
>>     setting I just didn't see that I can use to tell the adapter to
>>     use the
>>     implicit flow instead :|
>>
>>     If this is really missing, where would you suggest this should be
>>     configured? I'd expect the setting to be in KeycloakDeployment and
>>     OAuthRequestAuthenticator#loginRedirect would then use the value
>>     instead
>>     of always using the "code" value.
>>
>>
>>     Mit freundlichen Gr??en,
>>     ------------------------------------------------------------------------
>>     *Christian Beikov*
>>     Am 18.04.2018 um 17:35 schrieb Christian Beikov:
>>     >
>>     > Is there any way to avoid the access code to access token exchange?
>>     > Since the Keycloak server is not accessible, I'm getting an error
>>     > during authentication:
>>     >
>>     >  ERROR [org.keycloak.adapters.OAuthRequestAuthenticator] (default
>>     > task-54) failed to turn code into token:
>>     > java.net.UnknownHostException: blabla.local: unknown error
>>     >         ...
>>     >         at
>>     >
>>     org.keycloak.adapters.ServerRequest.invokeAccessCodeToToken(ServerRequest.java:111)
>>     >         at
>>     >
>>     org.keycloak.adapters.OAuthRequestAuthenticator.resolveCode(OAuthRequestAuthenticator.java:330)
>>     >         at
>>     >
>>     org.keycloak.adapters.OAuthRequestAuthenticator.authenticate(OAuthRequestAuthenticator.java:275)
>>     >         at
>>     >
>>     org.keycloak.adapters.RequestAuthenticator.authenticate(RequestAuthenticator.java:139)
>>     >         at
>>     >
>>     org.keycloak.adapters.undertow.AbstractUndertowKeycloakAuthMech.keycloakAuthenticate(AbstractUndertowKeycloakAuthMech.java:110)
>>     >         at
>>     >
>>     org.keycloak.adapters.undertow.ServletKeycloakAuthMech.authenticate(ServletKeycloakAuthMech.java:92)
>>     >         ...
>>     >
>>     >
>>     > Mit freundlichen Gr??en,
>>     >
>>     ------------------------------------------------------------------------
>>     > *Christian Beikov*
>>     > Am 18.04.2018 um 14:48 schrieb Thomas Darimont:
>>     >> Hello Christian,
>>     >>
>>     >> your application server needs to communicate with the Keycloak
>>     server
>>     >> to retrieve the realm public key referenced in the token to verify
>>     >> the token signature.
>>     >> The current implementation in Keycloak fetches & caches unknown
>>     >> public keys automatically.
>>     >>
>>     >> You could also use a fixed realm public key on the application
>>     server
>>     >> side but it would not support key rotation anymore.
>>     >>
>>     >> Cheers,
>>     >> Thomas
>>     >>
>>     >> 2018-04-18 13:45 GMT+02:00 Christian Beikov
>>     >> <christian.beikov at gmail.com <mailto:christian.beikov at gmail.com>
>>     <mailto:christian.beikov at gmail.com
>>     <mailto:christian.beikov at gmail.com>>>:
>>     >>
>>     >>     Hi,
>>     >>
>>     >>     is it necessary that an application secured by Keycloak can
>>     >>     access the
>>     >>     Keycloak server? Or is it enough if the Browser can access the
>>     >>     Keycloak
>>     >>     server?
>>     >>
>>     >>     --
>>     >>
>>     >>     Mit freundlichen Gr??en,
>>     >>
>>      ------------------------------------------------------------------------
>>     >>     *Christian Beikov*
>>     >>     _______________________________________________
>>     >>     keycloak-dev mailing list
>>     >> keycloak-dev at lists.jboss.org
>>     <mailto:keycloak-dev at lists.jboss.org>
>>     <mailto:keycloak-dev at lists.jboss.org
>>     <mailto:keycloak-dev at lists.jboss.org>>
>>     >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>     <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>     >>     <https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>     <https://lists.jboss.org/mailman/listinfo/keycloak-dev>>
>>     >>
>>     >>
>>     >
>>
>>     _______________________________________________
>>     keycloak-dev mailing list
>>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>     <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>
>>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



-- 
Bill Burke
Red Hat


From luke at code-house.org  Wed Apr 25 19:15:12 2018
From: luke at code-house.org (=?UTF-8?Q?=c5=81ukasz_Dywicki?=)
Date: Thu, 26 Apr 2018 01:15:12 +0200
Subject: [keycloak-dev] Mobile application and keycloak
Message-ID: <121b44bb-00b9-6a3c-e653-7776c196af81@code-house.org>

Hi,
I have a usecase with mobile application which is authenticate over
keycloak inside web view.

My concern is caused by "usability" of links generated in certain
actions - for example when user opens verification mail on his phone and
clicks confirmation link he should be "redirected" to moile application
in order to continue over this channel. Once he will finish process
mobile application will be ready to continue.

Another option I see is custom flow, however I am a little bit concerned
given that there are several flows which needs to be ammended and they
do generate HTML output in most of cases which needs to be kept.

What come to my mind is custom SPI, which could be added to keycloak.
Such SPI which would allow to register custom JAXRS filters for
request/response processing. By this way it would be possible to have a
very generic way to customize request handling without necessity to
amending default workflows.
Reason why I include dev mailing list is to see, if there would be
interest in having such extensibility provided by keycloak.

Kind regards,
Lukasz

From mposolda at redhat.com  Thu Apr 26 04:16:45 2018
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 26 Apr 2018 10:16:45 +0200
Subject: [keycloak-dev] Application and server in separate networks
In-Reply-To: <CABRXCmzfPqd-7rrMzox9UUAXkJZFngU=F6nUfh3ReNcA2P-6qg@mail.gmail.com>
References: <41e1a805-cc38-50cf-f794-cda6afd49313@gmail.com>
	<CAK-7U1gGFnwc3EcgL3whgdGbSTH9xSVwVSHxc1i+JtetJ83H4g@mail.gmail.com>
	<24a0f868-9726-4024-6254-9a0b68b29c9f@gmail.com>
	<569a7f4e-2fa6-6590-2dfb-d7a57c137db2@gmail.com>
	<CAPLPygm2BHoNkrrYMWaOUHx1gGT-PbvSccTNf7JuuLjGeATrLg@mail.gmail.com>
	<d52de7b0-0041-46e2-f5ed-479fb0264528@gmail.com>
	<CABRXCmzfPqd-7rrMzox9UUAXkJZFngU=F6nUfh3ReNcA2P-6qg@mail.gmail.com>
Message-ID: <e01068f2-8cd5-e855-86e3-1645ed36b118@redhat.com>

We support response_mode parameter and we also support HTML POST mode 
already on server side. But we specifically disallow "query" 
response_mode with implicit flow [1] . This is required per 
specification and OIDC certification had a test exactly for this AFAIR.

[1] 
https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/protocol/oidc/endpoints/AuthorizationEndpoint.java#L227

Marek

On 25/04/18 23:20, Bill Burke wrote:
> We should probably support response_mode parameter [1] and allow
> "query" mode for implicit invocations.  IMO, the HTML POST mode [2]
> (like SAML does) would be better as with implicit mode, the access
> token is leaked to browser history.
>
> [1] https://openid.net/specs/oauth-v2-multiple-response-types-1_0.html
> [2] http://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html
>
> On Wed, Apr 25, 2018 at 4:14 PM, Christian Beikov
> <christian.beikov at gmail.com> wrote:
>> Hey all,
>>
>> we reached a point where we are not sure how to proceed with the PR
>> https://github.com/keycloak/keycloak/pull/5167 for
>> https://issues.jboss.org/browse/KEYCLOAK-7195
>>
>> We added a client adapter configuration for the flow and that part works
>> so far, but we noticed that when the Keycloak server encounters a
>> request for authetication via the implicit flow, it puts the token into
>> the query fragment part which isn't sent to the application. This is the
>> point where it becomes obvious this mechanism is intended for the JS
>> adapter :)
>>
>> To resolve the problem and make the flow usable for the Java adapter as
>> well, we'd need some way to configure the response mode in the
>> OIDCLoginProtocol. My question is, how you think this should be done.
>> I was thinking of either allowing a query parameter to specify the
>> response mode or a configuration switch in the UI for the client. I kind
>> of prefer the query parameter solution.
>>
>> Is this even a change/feature you would be interested in? We need the
>> implicit flow because the Keycloak server is in a private network that
>> is separate from the application. Maybe there are other people out there
>> that have similar needs?
>>
>> Mit freundlichen Gr??en,
>> ------------------------------------------------------------------------
>> *Christian Beikov*
>> Am 20.04.2018 um 09:15 schrieb Niels Bertram:
>>> Hi Christian,
>>>
>>> can't say for sure but the server side adapters always use standard
>>> authorization flow, which requires your Java app to connect via a back
>>> channel to (A) exchange code grant for access tokens and (B) to lookup
>>> jwks for token validation.
>>>
>>> The OpenID Connect specification does provide a pure browser based
>>> flow calledimplicit flow
>>> <http://openid.net/specs/openid-connect-core-1_0.html#ImplicitFlowAuth>but
>>> that one has a few drawbacks such as auth tokens delivered in the
>>> redirect URL and no refresh token capability. Using this flow could
>>> solve your problem (A) to shift login flow to the frontend but still
>>> poses the challenge for (B) validating the tokens at the backend.
>>>
>>> I could not find a way to configure the Java adapter to work in pure
>>> offline validation mode. We had a similar requirement some time ago
>>> and had to code our own auth module to validate incoming tokens with a
>>> pre-configured public key. The other common problem we ran into is
>>> wanting to validate tokens from different (including non-keycloak)
>>> issuers on the same backend. The Keycloak Java adapters do not support
>>> this use case either. We originally looked at the Spring JWT adapter
>>> <https://github.com/spring-projects/spring-security-oauth/tree/master/spring-security-jwt>
>>> as an alternative but this project is not properly patched and
>>> configuration is a wonderful garden of mystery like everything in Spring.
>>>
>>> Very curious though to see what others are doing.
>>>
>>> Cheers,
>>> Niels
>>>
>>>
>>> On Thu, Apr 19, 2018 at 2:16 AM, Christian Beikov
>>> <christian.beikov at gmail.com <mailto:christian.beikov at gmail.com>> wrote:
>>>
>>>      As far as I see in the code, the Java Adapters always use the
>>>      standard
>>>      flow i.e. response_type=code
>>>
>>>      Please tell me this observation is wrong and there is an undocumented
>>>      setting I just didn't see that I can use to tell the adapter to
>>>      use the
>>>      implicit flow instead :|
>>>
>>>      If this is really missing, where would you suggest this should be
>>>      configured? I'd expect the setting to be in KeycloakDeployment and
>>>      OAuthRequestAuthenticator#loginRedirect would then use the value
>>>      instead
>>>      of always using the "code" value.
>>>
>>>
>>>      Mit freundlichen Gr??en,
>>>      ------------------------------------------------------------------------
>>>      *Christian Beikov*
>>>      Am 18.04.2018 um 17:35 schrieb Christian Beikov:
>>>      >
>>>      > Is there any way to avoid the access code to access token exchange?
>>>      > Since the Keycloak server is not accessible, I'm getting an error
>>>      > during authentication:
>>>      >
>>>      >  ERROR [org.keycloak.adapters.OAuthRequestAuthenticator] (default
>>>      > task-54) failed to turn code into token:
>>>      > java.net.UnknownHostException: blabla.local: unknown error
>>>      >         ...
>>>      >         at
>>>      >
>>>      org.keycloak.adapters.ServerRequest.invokeAccessCodeToToken(ServerRequest.java:111)
>>>      >         at
>>>      >
>>>      org.keycloak.adapters.OAuthRequestAuthenticator.resolveCode(OAuthRequestAuthenticator.java:330)
>>>      >         at
>>>      >
>>>      org.keycloak.adapters.OAuthRequestAuthenticator.authenticate(OAuthRequestAuthenticator.java:275)
>>>      >         at
>>>      >
>>>      org.keycloak.adapters.RequestAuthenticator.authenticate(RequestAuthenticator.java:139)
>>>      >         at
>>>      >
>>>      org.keycloak.adapters.undertow.AbstractUndertowKeycloakAuthMech.keycloakAuthenticate(AbstractUndertowKeycloakAuthMech.java:110)
>>>      >         at
>>>      >
>>>      org.keycloak.adapters.undertow.ServletKeycloakAuthMech.authenticate(ServletKeycloakAuthMech.java:92)
>>>      >         ...
>>>      >
>>>      >
>>>      > Mit freundlichen Gr??en,
>>>      >
>>>      ------------------------------------------------------------------------
>>>      > *Christian Beikov*
>>>      > Am 18.04.2018 um 14:48 schrieb Thomas Darimont:
>>>      >> Hello Christian,
>>>      >>
>>>      >> your application server needs to communicate with the Keycloak
>>>      server
>>>      >> to retrieve the realm public key referenced in the token to verify
>>>      >> the token signature.
>>>      >> The current implementation in Keycloak fetches & caches unknown
>>>      >> public keys automatically.
>>>      >>
>>>      >> You could also use a fixed realm public key on the application
>>>      server
>>>      >> side but it would not support key rotation anymore.
>>>      >>
>>>      >> Cheers,
>>>      >> Thomas
>>>      >>
>>>      >> 2018-04-18 13:45 GMT+02:00 Christian Beikov
>>>      >> <christian.beikov at gmail.com <mailto:christian.beikov at gmail.com>
>>>      <mailto:christian.beikov at gmail.com
>>>      <mailto:christian.beikov at gmail.com>>>:
>>>      >>
>>>      >>     Hi,
>>>      >>
>>>      >>     is it necessary that an application secured by Keycloak can
>>>      >>     access the
>>>      >>     Keycloak server? Or is it enough if the Browser can access the
>>>      >>     Keycloak
>>>      >>     server?
>>>      >>
>>>      >>     --
>>>      >>
>>>      >>     Mit freundlichen Gr??en,
>>>      >>
>>>       ------------------------------------------------------------------------
>>>      >>     *Christian Beikov*
>>>      >>     _______________________________________________
>>>      >>     keycloak-dev mailing list
>>>      >> keycloak-dev at lists.jboss.org
>>>      <mailto:keycloak-dev at lists.jboss.org>
>>>      <mailto:keycloak-dev at lists.jboss.org
>>>      <mailto:keycloak-dev at lists.jboss.org>>
>>>      >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>      <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>>      >>     <https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>      <https://lists.jboss.org/mailman/listinfo/keycloak-dev>>
>>>      >>
>>>      >>
>>>      >
>>>
>>>      _______________________________________________
>>>      keycloak-dev mailing list
>>>      keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>>>      https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>      <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>>
>>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>


From bburke at redhat.com  Thu Apr 26 08:38:10 2018
From: bburke at redhat.com (Bill Burke)
Date: Thu, 26 Apr 2018 08:38:10 -0400
Subject: [keycloak-dev] Application and server in separate networks
In-Reply-To: <e01068f2-8cd5-e855-86e3-1645ed36b118@redhat.com>
References: <41e1a805-cc38-50cf-f794-cda6afd49313@gmail.com>
	<CAK-7U1gGFnwc3EcgL3whgdGbSTH9xSVwVSHxc1i+JtetJ83H4g@mail.gmail.com>
	<24a0f868-9726-4024-6254-9a0b68b29c9f@gmail.com>
	<569a7f4e-2fa6-6590-2dfb-d7a57c137db2@gmail.com>
	<CAPLPygm2BHoNkrrYMWaOUHx1gGT-PbvSccTNf7JuuLjGeATrLg@mail.gmail.com>
	<d52de7b0-0041-46e2-f5ed-479fb0264528@gmail.com>
	<CABRXCmzfPqd-7rrMzox9UUAXkJZFngU=F6nUfh3ReNcA2P-6qg@mail.gmail.com>
	<e01068f2-8cd5-e855-86e3-1645ed36b118@redhat.com>
Message-ID: <CABRXCmxdn_jnTPzRtLx6Rz80OUJUgMRRBvSg9jFDkyqP5zDyxg@mail.gmail.com>

Cool, so POST mode works with Implicit?

On Thu, Apr 26, 2018 at 4:16 AM, Marek Posolda <mposolda at redhat.com> wrote:
> We support response_mode parameter and we also support HTML POST mode
> already on server side. But we specifically disallow "query" response_mode
> with implicit flow [1] . This is required per specification and OIDC
> certification had a test exactly for this AFAIR.
>
> [1]
> https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/protocol/oidc/endpoints/AuthorizationEndpoint.java#L227
>
> Marek
>
>
> On 25/04/18 23:20, Bill Burke wrote:
>>
>> We should probably support response_mode parameter [1] and allow
>> "query" mode for implicit invocations.  IMO, the HTML POST mode [2]
>> (like SAML does) would be better as with implicit mode, the access
>> token is leaked to browser history.
>>
>> [1] https://openid.net/specs/oauth-v2-multiple-response-types-1_0.html
>> [2] http://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html
>>
>> On Wed, Apr 25, 2018 at 4:14 PM, Christian Beikov
>> <christian.beikov at gmail.com> wrote:
>>>
>>> Hey all,
>>>
>>> we reached a point where we are not sure how to proceed with the PR
>>> https://github.com/keycloak/keycloak/pull/5167 for
>>> https://issues.jboss.org/browse/KEYCLOAK-7195
>>>
>>> We added a client adapter configuration for the flow and that part works
>>> so far, but we noticed that when the Keycloak server encounters a
>>> request for authetication via the implicit flow, it puts the token into
>>> the query fragment part which isn't sent to the application. This is the
>>> point where it becomes obvious this mechanism is intended for the JS
>>> adapter :)
>>>
>>> To resolve the problem and make the flow usable for the Java adapter as
>>> well, we'd need some way to configure the response mode in the
>>> OIDCLoginProtocol. My question is, how you think this should be done.
>>> I was thinking of either allowing a query parameter to specify the
>>> response mode or a configuration switch in the UI for the client. I kind
>>> of prefer the query parameter solution.
>>>
>>> Is this even a change/feature you would be interested in? We need the
>>> implicit flow because the Keycloak server is in a private network that
>>> is separate from the application. Maybe there are other people out there
>>> that have similar needs?
>>>
>>> Mit freundlichen Gr??en,
>>> ------------------------------------------------------------------------
>>> *Christian Beikov*
>>> Am 20.04.2018 um 09:15 schrieb Niels Bertram:
>>>>
>>>> Hi Christian,
>>>>
>>>> can't say for sure but the server side adapters always use standard
>>>> authorization flow, which requires your Java app to connect via a back
>>>> channel to (A) exchange code grant for access tokens and (B) to lookup
>>>> jwks for token validation.
>>>>
>>>> The OpenID Connect specification does provide a pure browser based
>>>> flow calledimplicit flow
>>>>
>>>> <http://openid.net/specs/openid-connect-core-1_0.html#ImplicitFlowAuth>but
>>>> that one has a few drawbacks such as auth tokens delivered in the
>>>> redirect URL and no refresh token capability. Using this flow could
>>>> solve your problem (A) to shift login flow to the frontend but still
>>>> poses the challenge for (B) validating the tokens at the backend.
>>>>
>>>> I could not find a way to configure the Java adapter to work in pure
>>>> offline validation mode. We had a similar requirement some time ago
>>>> and had to code our own auth module to validate incoming tokens with a
>>>> pre-configured public key. The other common problem we ran into is
>>>> wanting to validate tokens from different (including non-keycloak)
>>>> issuers on the same backend. The Keycloak Java adapters do not support
>>>> this use case either. We originally looked at the Spring JWT adapter
>>>>
>>>> <https://github.com/spring-projects/spring-security-oauth/tree/master/spring-security-jwt>
>>>> as an alternative but this project is not properly patched and
>>>> configuration is a wonderful garden of mystery like everything in
>>>> Spring.
>>>>
>>>> Very curious though to see what others are doing.
>>>>
>>>> Cheers,
>>>> Niels
>>>>
>>>>
>>>> On Thu, Apr 19, 2018 at 2:16 AM, Christian Beikov
>>>> <christian.beikov at gmail.com <mailto:christian.beikov at gmail.com>> wrote:
>>>>
>>>>      As far as I see in the code, the Java Adapters always use the
>>>>      standard
>>>>      flow i.e. response_type=code
>>>>
>>>>      Please tell me this observation is wrong and there is an
>>>> undocumented
>>>>      setting I just didn't see that I can use to tell the adapter to
>>>>      use the
>>>>      implicit flow instead :|
>>>>
>>>>      If this is really missing, where would you suggest this should be
>>>>      configured? I'd expect the setting to be in KeycloakDeployment and
>>>>      OAuthRequestAuthenticator#loginRedirect would then use the value
>>>>      instead
>>>>      of always using the "code" value.
>>>>
>>>>
>>>>      Mit freundlichen Gr??en,
>>>>
>>>> ------------------------------------------------------------------------
>>>>      *Christian Beikov*
>>>>      Am 18.04.2018 um 17:35 schrieb Christian Beikov:
>>>>      >
>>>>      > Is there any way to avoid the access code to access token
>>>> exchange?
>>>>      > Since the Keycloak server is not accessible, I'm getting an error
>>>>      > during authentication:
>>>>      >
>>>>      >  ERROR [org.keycloak.adapters.OAuthRequestAuthenticator] (default
>>>>      > task-54) failed to turn code into token:
>>>>      > java.net.UnknownHostException: blabla.local: unknown error
>>>>      >         ...
>>>>      >         at
>>>>      >
>>>>
>>>> org.keycloak.adapters.ServerRequest.invokeAccessCodeToToken(ServerRequest.java:111)
>>>>      >         at
>>>>      >
>>>>
>>>> org.keycloak.adapters.OAuthRequestAuthenticator.resolveCode(OAuthRequestAuthenticator.java:330)
>>>>      >         at
>>>>      >
>>>>
>>>> org.keycloak.adapters.OAuthRequestAuthenticator.authenticate(OAuthRequestAuthenticator.java:275)
>>>>      >         at
>>>>      >
>>>>
>>>> org.keycloak.adapters.RequestAuthenticator.authenticate(RequestAuthenticator.java:139)
>>>>      >         at
>>>>      >
>>>>
>>>> org.keycloak.adapters.undertow.AbstractUndertowKeycloakAuthMech.keycloakAuthenticate(AbstractUndertowKeycloakAuthMech.java:110)
>>>>      >         at
>>>>      >
>>>>
>>>> org.keycloak.adapters.undertow.ServletKeycloakAuthMech.authenticate(ServletKeycloakAuthMech.java:92)
>>>>      >         ...
>>>>      >
>>>>      >
>>>>      > Mit freundlichen Gr??en,
>>>>      >
>>>>
>>>> ------------------------------------------------------------------------
>>>>      > *Christian Beikov*
>>>>      > Am 18.04.2018 um 14:48 schrieb Thomas Darimont:
>>>>      >> Hello Christian,
>>>>      >>
>>>>      >> your application server needs to communicate with the Keycloak
>>>>      server
>>>>      >> to retrieve the realm public key referenced in the token to
>>>> verify
>>>>      >> the token signature.
>>>>      >> The current implementation in Keycloak fetches & caches unknown
>>>>      >> public keys automatically.
>>>>      >>
>>>>      >> You could also use a fixed realm public key on the application
>>>>      server
>>>>      >> side but it would not support key rotation anymore.
>>>>      >>
>>>>      >> Cheers,
>>>>      >> Thomas
>>>>      >>
>>>>      >> 2018-04-18 13:45 GMT+02:00 Christian Beikov
>>>>      >> <christian.beikov at gmail.com <mailto:christian.beikov at gmail.com>
>>>>      <mailto:christian.beikov at gmail.com
>>>>      <mailto:christian.beikov at gmail.com>>>:
>>>>      >>
>>>>      >>     Hi,
>>>>      >>
>>>>      >>     is it necessary that an application secured by Keycloak can
>>>>      >>     access the
>>>>      >>     Keycloak server? Or is it enough if the Browser can access
>>>> the
>>>>      >>     Keycloak
>>>>      >>     server?
>>>>      >>
>>>>      >>     --
>>>>      >>
>>>>      >>     Mit freundlichen Gr??en,
>>>>      >>
>>>>
>>>> ------------------------------------------------------------------------
>>>>      >>     *Christian Beikov*
>>>>      >>     _______________________________________________
>>>>      >>     keycloak-dev mailing list
>>>>      >> keycloak-dev at lists.jboss.org
>>>>      <mailto:keycloak-dev at lists.jboss.org>
>>>>      <mailto:keycloak-dev at lists.jboss.org
>>>>      <mailto:keycloak-dev at lists.jboss.org>>
>>>>      >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>      <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>>>      >>     <https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>      <https://lists.jboss.org/mailman/listinfo/keycloak-dev>>
>>>>      >>
>>>>      >>
>>>>      >
>>>>
>>>>      _______________________________________________
>>>>      keycloak-dev mailing list
>>>>      keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>>>>      https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>      <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>>>
>>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>>
>



-- 
Bill Burke
Red Hat


From mposolda at redhat.com  Thu Apr 26 09:06:21 2018
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 26 Apr 2018 15:06:21 +0200
Subject: [keycloak-dev] Application and server in separate networks
In-Reply-To: <CABRXCmxdn_jnTPzRtLx6Rz80OUJUgMRRBvSg9jFDkyqP5zDyxg@mail.gmail.com>
References: <41e1a805-cc38-50cf-f794-cda6afd49313@gmail.com>
	<CAK-7U1gGFnwc3EcgL3whgdGbSTH9xSVwVSHxc1i+JtetJ83H4g@mail.gmail.com>
	<24a0f868-9726-4024-6254-9a0b68b29c9f@gmail.com>
	<569a7f4e-2fa6-6590-2dfb-d7a57c137db2@gmail.com>
	<CAPLPygm2BHoNkrrYMWaOUHx1gGT-PbvSccTNf7JuuLjGeATrLg@mail.gmail.com>
	<d52de7b0-0041-46e2-f5ed-479fb0264528@gmail.com>
	<CABRXCmzfPqd-7rrMzox9UUAXkJZFngU=F6nUfh3ReNcA2P-6qg@mail.gmail.com>
	<e01068f2-8cd5-e855-86e3-1645ed36b118@redhat.com>
	<CABRXCmxdn_jnTPzRtLx6Rz80OUJUgMRRBvSg9jFDkyqP5zDyxg@mail.gmail.com>
Message-ID: <1a844bee-aaf8-8c23-3e2d-c5bbefffa48e@redhat.com>

I think it works, but didn't tested that combination. And POST is not 
supported by any of our adapters ATM, just by server. I know that some 
of our users use Form POST with 3rd party adapters, but likely the 
combination of FormPOST with standard flow.

On 26/04/18 14:38, Bill Burke wrote:
> Cool, so POST mode works with Implicit?
>
> On Thu, Apr 26, 2018 at 4:16 AM, Marek Posolda <mposolda at redhat.com> wrote:
>> We support response_mode parameter and we also support HTML POST mode
>> already on server side. But we specifically disallow "query" response_mode
>> with implicit flow [1] . This is required per specification and OIDC
>> certification had a test exactly for this AFAIR.
>>
>> [1]
>> https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/protocol/oidc/endpoints/AuthorizationEndpoint.java#L227
>>
>> Marek
>>
>>
>> On 25/04/18 23:20, Bill Burke wrote:
>>> We should probably support response_mode parameter [1] and allow
>>> "query" mode for implicit invocations.  IMO, the HTML POST mode [2]
>>> (like SAML does) would be better as with implicit mode, the access
>>> token is leaked to browser history.
>>>
>>> [1] https://openid.net/specs/oauth-v2-multiple-response-types-1_0.html
>>> [2] http://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html
>>>
>>> On Wed, Apr 25, 2018 at 4:14 PM, Christian Beikov
>>> <christian.beikov at gmail.com> wrote:
>>>> Hey all,
>>>>
>>>> we reached a point where we are not sure how to proceed with the PR
>>>> https://github.com/keycloak/keycloak/pull/5167 for
>>>> https://issues.jboss.org/browse/KEYCLOAK-7195
>>>>
>>>> We added a client adapter configuration for the flow and that part works
>>>> so far, but we noticed that when the Keycloak server encounters a
>>>> request for authetication via the implicit flow, it puts the token into
>>>> the query fragment part which isn't sent to the application. This is the
>>>> point where it becomes obvious this mechanism is intended for the JS
>>>> adapter :)
>>>>
>>>> To resolve the problem and make the flow usable for the Java adapter as
>>>> well, we'd need some way to configure the response mode in the
>>>> OIDCLoginProtocol. My question is, how you think this should be done.
>>>> I was thinking of either allowing a query parameter to specify the
>>>> response mode or a configuration switch in the UI for the client. I kind
>>>> of prefer the query parameter solution.
>>>>
>>>> Is this even a change/feature you would be interested in? We need the
>>>> implicit flow because the Keycloak server is in a private network that
>>>> is separate from the application. Maybe there are other people out there
>>>> that have similar needs?
>>>>
>>>> Mit freundlichen Gr??en,
>>>> ------------------------------------------------------------------------
>>>> *Christian Beikov*
>>>> Am 20.04.2018 um 09:15 schrieb Niels Bertram:
>>>>> Hi Christian,
>>>>>
>>>>> can't say for sure but the server side adapters always use standard
>>>>> authorization flow, which requires your Java app to connect via a back
>>>>> channel to (A) exchange code grant for access tokens and (B) to lookup
>>>>> jwks for token validation.
>>>>>
>>>>> The OpenID Connect specification does provide a pure browser based
>>>>> flow calledimplicit flow
>>>>>
>>>>> <http://openid.net/specs/openid-connect-core-1_0.html#ImplicitFlowAuth>but
>>>>> that one has a few drawbacks such as auth tokens delivered in the
>>>>> redirect URL and no refresh token capability. Using this flow could
>>>>> solve your problem (A) to shift login flow to the frontend but still
>>>>> poses the challenge for (B) validating the tokens at the backend.
>>>>>
>>>>> I could not find a way to configure the Java adapter to work in pure
>>>>> offline validation mode. We had a similar requirement some time ago
>>>>> and had to code our own auth module to validate incoming tokens with a
>>>>> pre-configured public key. The other common problem we ran into is
>>>>> wanting to validate tokens from different (including non-keycloak)
>>>>> issuers on the same backend. The Keycloak Java adapters do not support
>>>>> this use case either. We originally looked at the Spring JWT adapter
>>>>>
>>>>> <https://github.com/spring-projects/spring-security-oauth/tree/master/spring-security-jwt>
>>>>> as an alternative but this project is not properly patched and
>>>>> configuration is a wonderful garden of mystery like everything in
>>>>> Spring.
>>>>>
>>>>> Very curious though to see what others are doing.
>>>>>
>>>>> Cheers,
>>>>> Niels
>>>>>
>>>>>
>>>>> On Thu, Apr 19, 2018 at 2:16 AM, Christian Beikov
>>>>> <christian.beikov at gmail.com <mailto:christian.beikov at gmail.com>> wrote:
>>>>>
>>>>>       As far as I see in the code, the Java Adapters always use the
>>>>>       standard
>>>>>       flow i.e. response_type=code
>>>>>
>>>>>       Please tell me this observation is wrong and there is an
>>>>> undocumented
>>>>>       setting I just didn't see that I can use to tell the adapter to
>>>>>       use the
>>>>>       implicit flow instead :|
>>>>>
>>>>>       If this is really missing, where would you suggest this should be
>>>>>       configured? I'd expect the setting to be in KeycloakDeployment and
>>>>>       OAuthRequestAuthenticator#loginRedirect would then use the value
>>>>>       instead
>>>>>       of always using the "code" value.
>>>>>
>>>>>
>>>>>       Mit freundlichen Gr??en,
>>>>>
>>>>> ------------------------------------------------------------------------
>>>>>       *Christian Beikov*
>>>>>       Am 18.04.2018 um 17:35 schrieb Christian Beikov:
>>>>>       >
>>>>>       > Is there any way to avoid the access code to access token
>>>>> exchange?
>>>>>       > Since the Keycloak server is not accessible, I'm getting an error
>>>>>       > during authentication:
>>>>>       >
>>>>>       >  ERROR [org.keycloak.adapters.OAuthRequestAuthenticator] (default
>>>>>       > task-54) failed to turn code into token:
>>>>>       > java.net.UnknownHostException: blabla.local: unknown error
>>>>>       >         ...
>>>>>       >         at
>>>>>       >
>>>>>
>>>>> org.keycloak.adapters.ServerRequest.invokeAccessCodeToToken(ServerRequest.java:111)
>>>>>       >         at
>>>>>       >
>>>>>
>>>>> org.keycloak.adapters.OAuthRequestAuthenticator.resolveCode(OAuthRequestAuthenticator.java:330)
>>>>>       >         at
>>>>>       >
>>>>>
>>>>> org.keycloak.adapters.OAuthRequestAuthenticator.authenticate(OAuthRequestAuthenticator.java:275)
>>>>>       >         at
>>>>>       >
>>>>>
>>>>> org.keycloak.adapters.RequestAuthenticator.authenticate(RequestAuthenticator.java:139)
>>>>>       >         at
>>>>>       >
>>>>>
>>>>> org.keycloak.adapters.undertow.AbstractUndertowKeycloakAuthMech.keycloakAuthenticate(AbstractUndertowKeycloakAuthMech.java:110)
>>>>>       >         at
>>>>>       >
>>>>>
>>>>> org.keycloak.adapters.undertow.ServletKeycloakAuthMech.authenticate(ServletKeycloakAuthMech.java:92)
>>>>>       >         ...
>>>>>       >
>>>>>       >
>>>>>       > Mit freundlichen Gr??en,
>>>>>       >
>>>>>
>>>>> ------------------------------------------------------------------------
>>>>>       > *Christian Beikov*
>>>>>       > Am 18.04.2018 um 14:48 schrieb Thomas Darimont:
>>>>>       >> Hello Christian,
>>>>>       >>
>>>>>       >> your application server needs to communicate with the Keycloak
>>>>>       server
>>>>>       >> to retrieve the realm public key referenced in the token to
>>>>> verify
>>>>>       >> the token signature.
>>>>>       >> The current implementation in Keycloak fetches & caches unknown
>>>>>       >> public keys automatically.
>>>>>       >>
>>>>>       >> You could also use a fixed realm public key on the application
>>>>>       server
>>>>>       >> side but it would not support key rotation anymore.
>>>>>       >>
>>>>>       >> Cheers,
>>>>>       >> Thomas
>>>>>       >>
>>>>>       >> 2018-04-18 13:45 GMT+02:00 Christian Beikov
>>>>>       >> <christian.beikov at gmail.com <mailto:christian.beikov at gmail.com>
>>>>>       <mailto:christian.beikov at gmail.com
>>>>>       <mailto:christian.beikov at gmail.com>>>:
>>>>>       >>
>>>>>       >>     Hi,
>>>>>       >>
>>>>>       >>     is it necessary that an application secured by Keycloak can
>>>>>       >>     access the
>>>>>       >>     Keycloak server? Or is it enough if the Browser can access
>>>>> the
>>>>>       >>     Keycloak
>>>>>       >>     server?
>>>>>       >>
>>>>>       >>     --
>>>>>       >>
>>>>>       >>     Mit freundlichen Gr??en,
>>>>>       >>
>>>>>
>>>>> ------------------------------------------------------------------------
>>>>>       >>     *Christian Beikov*
>>>>>       >>     _______________________________________________
>>>>>       >>     keycloak-dev mailing list
>>>>>       >> keycloak-dev at lists.jboss.org
>>>>>       <mailto:keycloak-dev at lists.jboss.org>
>>>>>       <mailto:keycloak-dev at lists.jboss.org
>>>>>       <mailto:keycloak-dev at lists.jboss.org>>
>>>>>       >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>       <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>>>>       >>     <https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>       <https://lists.jboss.org/mailman/listinfo/keycloak-dev>>
>>>>>       >>
>>>>>       >>
>>>>>       >
>>>>>
>>>>>       _______________________________________________
>>>>>       keycloak-dev mailing list
>>>>>       keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>>>>>       https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>       <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>>>>
>>>>>
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>>
>
>


From christian.beikov at gmail.com  Thu Apr 26 09:59:31 2018
From: christian.beikov at gmail.com (Christian Beikov)
Date: Thu, 26 Apr 2018 15:59:31 +0200
Subject: [keycloak-dev] Application and server in separate networks
In-Reply-To: <1a844bee-aaf8-8c23-3e2d-c5bbefffa48e@redhat.com>
References: <41e1a805-cc38-50cf-f794-cda6afd49313@gmail.com>
	<CAK-7U1gGFnwc3EcgL3whgdGbSTH9xSVwVSHxc1i+JtetJ83H4g@mail.gmail.com>
	<24a0f868-9726-4024-6254-9a0b68b29c9f@gmail.com>
	<569a7f4e-2fa6-6590-2dfb-d7a57c137db2@gmail.com>
	<CAPLPygm2BHoNkrrYMWaOUHx1gGT-PbvSccTNf7JuuLjGeATrLg@mail.gmail.com>
	<d52de7b0-0041-46e2-f5ed-479fb0264528@gmail.com>
	<CABRXCmzfPqd-7rrMzox9UUAXkJZFngU=F6nUfh3ReNcA2P-6qg@mail.gmail.com>
	<e01068f2-8cd5-e855-86e3-1645ed36b118@redhat.com>
	<CABRXCmxdn_jnTPzRtLx6Rz80OUJUgMRRBvSg9jFDkyqP5zDyxg@mail.gmail.com>
	<1a844bee-aaf8-8c23-3e2d-c5bbefffa48e@redhat.com>
Message-ID: <95470200-8cff-362d-5f0a-c345eed70b3c@gmail.com>

Thanks for the hints. I'll try to see if I can get SAML to work and let 
you know of the result. Anyway, the POST response_mode sounds promising 
and would definitely work in our case. When I put the URL hash I got 
while testing into the query part of the URL, the authentication worked 
properly. So doing a form encoded POST would probably work as well.


Mit freundlichen Gr??en,
------------------------------------------------------------------------
*Christian Beikov*
Am 26.04.2018 um 15:06 schrieb Marek Posolda:
> I think it works, but didn't tested that combination. And POST is not 
> supported by any of our adapters ATM, just by server. I know that some 
> of our users use Form POST with 3rd party adapters, but likely the 
> combination of FormPOST with standard flow.
>
> On 26/04/18 14:38, Bill Burke wrote:
>> Cool, so POST mode works with Implicit?
>>
>> On Thu, Apr 26, 2018 at 4:16 AM, Marek Posolda <mposolda at redhat.com> 
>> wrote:
>>> We support response_mode parameter and we also support HTML POST mode
>>> already on server side. But we specifically disallow "query" 
>>> response_mode
>>> with implicit flow [1] . This is required per specification and OIDC
>>> certification had a test exactly for this AFAIR.
>>>
>>> [1]
>>> https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/protocol/oidc/endpoints/AuthorizationEndpoint.java#L227 
>>>
>>>
>>> Marek
>>>
>>>
>>> On 25/04/18 23:20, Bill Burke wrote:
>>>> We should probably support response_mode parameter [1] and allow
>>>> "query" mode for implicit invocations.? IMO, the HTML POST mode [2]
>>>> (like SAML does) would be better as with implicit mode, the access
>>>> token is leaked to browser history.
>>>>
>>>> [1] https://openid.net/specs/oauth-v2-multiple-response-types-1_0.html
>>>> [2] http://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html
>>>>
>>>> On Wed, Apr 25, 2018 at 4:14 PM, Christian Beikov
>>>> <christian.beikov at gmail.com> wrote:
>>>>> Hey all,
>>>>>
>>>>> we reached a point where we are not sure how to proceed with the PR
>>>>> https://github.com/keycloak/keycloak/pull/5167 for
>>>>> https://issues.jboss.org/browse/KEYCLOAK-7195
>>>>>
>>>>> We added a client adapter configuration for the flow and that part 
>>>>> works
>>>>> so far, but we noticed that when the Keycloak server encounters a
>>>>> request for authetication via the implicit flow, it puts the token 
>>>>> into
>>>>> the query fragment part which isn't sent to the application. This 
>>>>> is the
>>>>> point where it becomes obvious this mechanism is intended for the JS
>>>>> adapter :)
>>>>>
>>>>> To resolve the problem and make the flow usable for the Java 
>>>>> adapter as
>>>>> well, we'd need some way to configure the response mode in the
>>>>> OIDCLoginProtocol. My question is, how you think this should be done.
>>>>> I was thinking of either allowing a query parameter to specify the
>>>>> response mode or a configuration switch in the UI for the client. 
>>>>> I kind
>>>>> of prefer the query parameter solution.
>>>>>
>>>>> Is this even a change/feature you would be interested in? We need the
>>>>> implicit flow because the Keycloak server is in a private network 
>>>>> that
>>>>> is separate from the application. Maybe there are other people out 
>>>>> there
>>>>> that have similar needs?
>>>>>
>>>>> Mit freundlichen Gr??en,
>>>>> ------------------------------------------------------------------------ 
>>>>>
>>>>> *Christian Beikov*
>>>>> Am 20.04.2018 um 09:15 schrieb Niels Bertram:
>>>>>> Hi Christian,
>>>>>>
>>>>>> can't say for sure but the server side adapters always use standard
>>>>>> authorization flow, which requires your Java app to connect via a 
>>>>>> back
>>>>>> channel to (A) exchange code grant for access tokens and (B) to 
>>>>>> lookup
>>>>>> jwks for token validation.
>>>>>>
>>>>>> The OpenID Connect specification does provide a pure browser based
>>>>>> flow calledimplicit flow
>>>>>>
>>>>>> <http://openid.net/specs/openid-connect-core-1_0.html#ImplicitFlowAuth>but 
>>>>>>
>>>>>> that one has a few drawbacks such as auth tokens delivered in the
>>>>>> redirect URL and no refresh token capability. Using this flow could
>>>>>> solve your problem (A) to shift login flow to the frontend but still
>>>>>> poses the challenge for (B) validating the tokens at the backend.
>>>>>>
>>>>>> I could not find a way to configure the Java adapter to work in pure
>>>>>> offline validation mode. We had a similar requirement some time ago
>>>>>> and had to code our own auth module to validate incoming tokens 
>>>>>> with a
>>>>>> pre-configured public key. The other common problem we ran into is
>>>>>> wanting to validate tokens from different (including non-keycloak)
>>>>>> issuers on the same backend. The Keycloak Java adapters do not 
>>>>>> support
>>>>>> this use case either. We originally looked at the Spring JWT adapter
>>>>>>
>>>>>> <https://github.com/spring-projects/spring-security-oauth/tree/master/spring-security-jwt> 
>>>>>>
>>>>>> as an alternative but this project is not properly patched and
>>>>>> configuration is a wonderful garden of mystery like everything in
>>>>>> Spring.
>>>>>>
>>>>>> Very curious though to see what others are doing.
>>>>>>
>>>>>> Cheers,
>>>>>> Niels
>>>>>>
>>>>>>
>>>>>> On Thu, Apr 19, 2018 at 2:16 AM, Christian Beikov
>>>>>> <christian.beikov at gmail.com <mailto:christian.beikov at gmail.com>> 
>>>>>> wrote:
>>>>>>
>>>>>> ????? As far as I see in the code, the Java Adapters always use the
>>>>>> ????? standard
>>>>>> ????? flow i.e. response_type=code
>>>>>>
>>>>>> ????? Please tell me this observation is wrong and there is an
>>>>>> undocumented
>>>>>> ????? setting I just didn't see that I can use to tell the 
>>>>>> adapter to
>>>>>> ????? use the
>>>>>> ????? implicit flow instead :|
>>>>>>
>>>>>> ????? If this is really missing, where would you suggest this 
>>>>>> should be
>>>>>> ????? configured? I'd expect the setting to be in 
>>>>>> KeycloakDeployment and
>>>>>> ????? OAuthRequestAuthenticator#loginRedirect would then use the 
>>>>>> value
>>>>>> ????? instead
>>>>>> ????? of always using the "code" value.
>>>>>>
>>>>>>
>>>>>> ????? Mit freundlichen Gr??en,
>>>>>>
>>>>>> ------------------------------------------------------------------------ 
>>>>>>
>>>>>> ????? *Christian Beikov*
>>>>>> ????? Am 18.04.2018 um 17:35 schrieb Christian Beikov:
>>>>>> ????? >
>>>>>> ????? > Is there any way to avoid the access code to access token
>>>>>> exchange?
>>>>>> ????? > Since the Keycloak server is not accessible, I'm getting 
>>>>>> an error
>>>>>> ????? > during authentication:
>>>>>> ????? >
>>>>>> ????? >? ERROR [org.keycloak.adapters.OAuthRequestAuthenticator] 
>>>>>> (default
>>>>>> ????? > task-54) failed to turn code into token:
>>>>>> ????? > java.net.UnknownHostException: blabla.local: unknown error
>>>>>> ????? >???????? ...
>>>>>> ????? >???????? at
>>>>>> ????? >
>>>>>>
>>>>>> org.keycloak.adapters.ServerRequest.invokeAccessCodeToToken(ServerRequest.java:111) 
>>>>>>
>>>>>> ????? >???????? at
>>>>>> ????? >
>>>>>>
>>>>>> org.keycloak.adapters.OAuthRequestAuthenticator.resolveCode(OAuthRequestAuthenticator.java:330) 
>>>>>>
>>>>>> ????? >???????? at
>>>>>> ????? >
>>>>>>
>>>>>> org.keycloak.adapters.OAuthRequestAuthenticator.authenticate(OAuthRequestAuthenticator.java:275) 
>>>>>>
>>>>>> ????? >???????? at
>>>>>> ????? >
>>>>>>
>>>>>> org.keycloak.adapters.RequestAuthenticator.authenticate(RequestAuthenticator.java:139) 
>>>>>>
>>>>>> ????? >???????? at
>>>>>> ????? >
>>>>>>
>>>>>> org.keycloak.adapters.undertow.AbstractUndertowKeycloakAuthMech.keycloakAuthenticate(AbstractUndertowKeycloakAuthMech.java:110) 
>>>>>>
>>>>>> ????? >???????? at
>>>>>> ????? >
>>>>>>
>>>>>> org.keycloak.adapters.undertow.ServletKeycloakAuthMech.authenticate(ServletKeycloakAuthMech.java:92) 
>>>>>>
>>>>>> ????? >???????? ...
>>>>>> ????? >
>>>>>> ????? >
>>>>>> ????? > Mit freundlichen Gr??en,
>>>>>> ????? >
>>>>>>
>>>>>> ------------------------------------------------------------------------ 
>>>>>>
>>>>>> ????? > *Christian Beikov*
>>>>>> ????? > Am 18.04.2018 um 14:48 schrieb Thomas Darimont:
>>>>>> ????? >> Hello Christian,
>>>>>> ????? >>
>>>>>> ????? >> your application server needs to communicate with the 
>>>>>> Keycloak
>>>>>> ????? server
>>>>>> ????? >> to retrieve the realm public key referenced in the token to
>>>>>> verify
>>>>>> ????? >> the token signature.
>>>>>> ????? >> The current implementation in Keycloak fetches & caches 
>>>>>> unknown
>>>>>> ????? >> public keys automatically.
>>>>>> ????? >>
>>>>>> ????? >> You could also use a fixed realm public key on the 
>>>>>> application
>>>>>> ????? server
>>>>>> ????? >> side but it would not support key rotation anymore.
>>>>>> ????? >>
>>>>>> ????? >> Cheers,
>>>>>> ????? >> Thomas
>>>>>> ????? >>
>>>>>> ????? >> 2018-04-18 13:45 GMT+02:00 Christian Beikov
>>>>>> ????? >> <christian.beikov at gmail.com 
>>>>>> <mailto:christian.beikov at gmail.com>
>>>>>> ????? <mailto:christian.beikov at gmail.com
>>>>>> ????? <mailto:christian.beikov at gmail.com>>>:
>>>>>> ????? >>
>>>>>> ????? >>???? Hi,
>>>>>> ????? >>
>>>>>> ????? >>???? is it necessary that an application secured by 
>>>>>> Keycloak can
>>>>>> ????? >>???? access the
>>>>>> ????? >>???? Keycloak server? Or is it enough if the Browser can 
>>>>>> access
>>>>>> the
>>>>>> ????? >>???? Keycloak
>>>>>> ????? >>???? server?
>>>>>> ????? >>
>>>>>> ????? >>???? --
>>>>>> ????? >>
>>>>>> ????? >>???? Mit freundlichen Gr??en,
>>>>>> ????? >>
>>>>>>
>>>>>> ------------------------------------------------------------------------ 
>>>>>>
>>>>>> ????? >>???? *Christian Beikov*
>>>>>> ????? >> _______________________________________________
>>>>>> ????? >>???? keycloak-dev mailing list
>>>>>> ????? >> keycloak-dev at lists.jboss.org
>>>>>> ????? <mailto:keycloak-dev at lists.jboss.org>
>>>>>> ????? <mailto:keycloak-dev at lists.jboss.org
>>>>>> ????? <mailto:keycloak-dev at lists.jboss.org>>
>>>>>> ????? >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>> <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>>>>> ????? >> <https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>> <https://lists.jboss.org/mailman/listinfo/keycloak-dev>>
>>>>>> ????? >>
>>>>>> ????? >>
>>>>>> ????? >
>>>>>>
>>>>>> ????? _______________________________________________
>>>>>> ????? keycloak-dev mailing list
>>>>>> ????? keycloak-dev at lists.jboss.org 
>>>>>> <mailto:keycloak-dev at lists.jboss.org>
>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>> <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> keycloak-dev mailing list
>>>>> keycloak-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>>>
>>
>>
>


From sthorger at redhat.com  Thu Apr 26 09:59:52 2018
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 26 Apr 2018 15:59:52 +0200
Subject: [keycloak-dev] Angular Integration
In-Reply-To: <MWHPR15MB13909249A5E0ACC153B46257A9880@MWHPR15MB1390.namprd15.prod.outlook.com>
References: <MWHPR15MB13909249A5E0ACC153B46257A9880@MWHPR15MB1390.namprd15.prod.outlook.com>
Message-ID: <CAJgngAfLP2sPCZEhkdQUJVZGYBvAz4B8ETfrLZe7JrLoOYZL1Q@mail.gmail.com>

Did you by any chance take a look at
https://github.com/ssilvert/keycloak-schematic. This seems to compliment
that rather than duplicate it.

On 24 April 2018 at 13:15, Giovanni Silva <giovannicandido at outlook.com>
wrote:

> Hi,
> Based on the awesome work in keycloak-js, I created integration with
> Angular 2 (4, 5), one of the most wide used javascript frameworks.
>
> The integration expands on a couple of different ways:
>
> Provide directives for condition hide display DOM elements, based on user
> roles
>
> Provide Login guards for angular routes that intercept a not logged user
> and initiate the Oauth2 flow
>
> Provide a service to be injected for queries like username and email
>
> Automatically refresh and add the token on every http request to server,
> without any intervention.
>
> It can also be used in ionic mobile applications, but I did not test this.
>
> If anyone is interested in the project, I would appreciate any feedback or
> collaboration.
>
> Code is release in MIT license
>
> What is missing:
>
> Authorization service integration (there is only role based directives)
>
> More user cases
>
> Code: https://github.com/giovannicandido/angular-spa
> Docs: https://angular-spa.netlify.com
> Demo: https://github.com/giovannicandido/angular-spa-example
>
> Thanks,
> Giovanni Silva
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From bburke at redhat.com  Thu Apr 26 10:50:41 2018
From: bburke at redhat.com (Bill Burke)
Date: Thu, 26 Apr 2018 10:50:41 -0400
Subject: [keycloak-dev] Application and server in separate networks
In-Reply-To: <95470200-8cff-362d-5f0a-c345eed70b3c@gmail.com>
References: <41e1a805-cc38-50cf-f794-cda6afd49313@gmail.com>
	<CAK-7U1gGFnwc3EcgL3whgdGbSTH9xSVwVSHxc1i+JtetJ83H4g@mail.gmail.com>
	<24a0f868-9726-4024-6254-9a0b68b29c9f@gmail.com>
	<569a7f4e-2fa6-6590-2dfb-d7a57c137db2@gmail.com>
	<CAPLPygm2BHoNkrrYMWaOUHx1gGT-PbvSccTNf7JuuLjGeATrLg@mail.gmail.com>
	<d52de7b0-0041-46e2-f5ed-479fb0264528@gmail.com>
	<CABRXCmzfPqd-7rrMzox9UUAXkJZFngU=F6nUfh3ReNcA2P-6qg@mail.gmail.com>
	<e01068f2-8cd5-e855-86e3-1645ed36b118@redhat.com>
	<CABRXCmxdn_jnTPzRtLx6Rz80OUJUgMRRBvSg9jFDkyqP5zDyxg@mail.gmail.com>
	<1a844bee-aaf8-8c23-3e2d-c5bbefffa48e@redhat.com>
	<95470200-8cff-362d-5f0a-c345eed70b3c@gmail.com>
Message-ID: <CABRXCmw_DpdufKjVAZJ-=dNDLxnG=rQEw=ExKD7nwWuyQ7qhgQ@mail.gmail.com>

SAML would definitely work for your case so long as you don't need a
token to make other REST invocations.

On Thu, Apr 26, 2018 at 9:59 AM, Christian Beikov
<christian.beikov at gmail.com> wrote:
> Thanks for the hints. I'll try to see if I can get SAML to work and let
> you know of the result. Anyway, the POST response_mode sounds promising
> and would definitely work in our case. When I put the URL hash I got
> while testing into the query part of the URL, the authentication worked
> properly. So doing a form encoded POST would probably work as well.
>
>
> Mit freundlichen Gr??en,
> ------------------------------------------------------------------------
> *Christian Beikov*
> Am 26.04.2018 um 15:06 schrieb Marek Posolda:
>> I think it works, but didn't tested that combination. And POST is not
>> supported by any of our adapters ATM, just by server. I know that some
>> of our users use Form POST with 3rd party adapters, but likely the
>> combination of FormPOST with standard flow.
>>
>> On 26/04/18 14:38, Bill Burke wrote:
>>> Cool, so POST mode works with Implicit?
>>>
>>> On Thu, Apr 26, 2018 at 4:16 AM, Marek Posolda <mposolda at redhat.com>
>>> wrote:
>>>> We support response_mode parameter and we also support HTML POST mode
>>>> already on server side. But we specifically disallow "query"
>>>> response_mode
>>>> with implicit flow [1] . This is required per specification and OIDC
>>>> certification had a test exactly for this AFAIR.
>>>>
>>>> [1]
>>>> https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/protocol/oidc/endpoints/AuthorizationEndpoint.java#L227
>>>>
>>>>
>>>> Marek
>>>>
>>>>
>>>> On 25/04/18 23:20, Bill Burke wrote:
>>>>> We should probably support response_mode parameter [1] and allow
>>>>> "query" mode for implicit invocations.  IMO, the HTML POST mode [2]
>>>>> (like SAML does) would be better as with implicit mode, the access
>>>>> token is leaked to browser history.
>>>>>
>>>>> [1] https://openid.net/specs/oauth-v2-multiple-response-types-1_0.html
>>>>> [2] http://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html
>>>>>
>>>>> On Wed, Apr 25, 2018 at 4:14 PM, Christian Beikov
>>>>> <christian.beikov at gmail.com> wrote:
>>>>>> Hey all,
>>>>>>
>>>>>> we reached a point where we are not sure how to proceed with the PR
>>>>>> https://github.com/keycloak/keycloak/pull/5167 for
>>>>>> https://issues.jboss.org/browse/KEYCLOAK-7195
>>>>>>
>>>>>> We added a client adapter configuration for the flow and that part
>>>>>> works
>>>>>> so far, but we noticed that when the Keycloak server encounters a
>>>>>> request for authetication via the implicit flow, it puts the token
>>>>>> into
>>>>>> the query fragment part which isn't sent to the application. This
>>>>>> is the
>>>>>> point where it becomes obvious this mechanism is intended for the JS
>>>>>> adapter :)
>>>>>>
>>>>>> To resolve the problem and make the flow usable for the Java
>>>>>> adapter as
>>>>>> well, we'd need some way to configure the response mode in the
>>>>>> OIDCLoginProtocol. My question is, how you think this should be done.
>>>>>> I was thinking of either allowing a query parameter to specify the
>>>>>> response mode or a configuration switch in the UI for the client.
>>>>>> I kind
>>>>>> of prefer the query parameter solution.
>>>>>>
>>>>>> Is this even a change/feature you would be interested in? We need the
>>>>>> implicit flow because the Keycloak server is in a private network
>>>>>> that
>>>>>> is separate from the application. Maybe there are other people out
>>>>>> there
>>>>>> that have similar needs?
>>>>>>
>>>>>> Mit freundlichen Gr??en,
>>>>>> ------------------------------------------------------------------------
>>>>>>
>>>>>> *Christian Beikov*
>>>>>> Am 20.04.2018 um 09:15 schrieb Niels Bertram:
>>>>>>> Hi Christian,
>>>>>>>
>>>>>>> can't say for sure but the server side adapters always use standard
>>>>>>> authorization flow, which requires your Java app to connect via a
>>>>>>> back
>>>>>>> channel to (A) exchange code grant for access tokens and (B) to
>>>>>>> lookup
>>>>>>> jwks for token validation.
>>>>>>>
>>>>>>> The OpenID Connect specification does provide a pure browser based
>>>>>>> flow calledimplicit flow
>>>>>>>
>>>>>>> <http://openid.net/specs/openid-connect-core-1_0.html#ImplicitFlowAuth>but
>>>>>>>
>>>>>>> that one has a few drawbacks such as auth tokens delivered in the
>>>>>>> redirect URL and no refresh token capability. Using this flow could
>>>>>>> solve your problem (A) to shift login flow to the frontend but still
>>>>>>> poses the challenge for (B) validating the tokens at the backend.
>>>>>>>
>>>>>>> I could not find a way to configure the Java adapter to work in pure
>>>>>>> offline validation mode. We had a similar requirement some time ago
>>>>>>> and had to code our own auth module to validate incoming tokens
>>>>>>> with a
>>>>>>> pre-configured public key. The other common problem we ran into is
>>>>>>> wanting to validate tokens from different (including non-keycloak)
>>>>>>> issuers on the same backend. The Keycloak Java adapters do not
>>>>>>> support
>>>>>>> this use case either. We originally looked at the Spring JWT adapter
>>>>>>>
>>>>>>> <https://github.com/spring-projects/spring-security-oauth/tree/master/spring-security-jwt>
>>>>>>>
>>>>>>> as an alternative but this project is not properly patched and
>>>>>>> configuration is a wonderful garden of mystery like everything in
>>>>>>> Spring.
>>>>>>>
>>>>>>> Very curious though to see what others are doing.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Niels
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Apr 19, 2018 at 2:16 AM, Christian Beikov
>>>>>>> <christian.beikov at gmail.com <mailto:christian.beikov at gmail.com>>
>>>>>>> wrote:
>>>>>>>
>>>>>>>       As far as I see in the code, the Java Adapters always use the
>>>>>>>       standard
>>>>>>>       flow i.e. response_type=code
>>>>>>>
>>>>>>>       Please tell me this observation is wrong and there is an
>>>>>>> undocumented
>>>>>>>       setting I just didn't see that I can use to tell the
>>>>>>> adapter to
>>>>>>>       use the
>>>>>>>       implicit flow instead :|
>>>>>>>
>>>>>>>       If this is really missing, where would you suggest this
>>>>>>> should be
>>>>>>>       configured? I'd expect the setting to be in
>>>>>>> KeycloakDeployment and
>>>>>>>       OAuthRequestAuthenticator#loginRedirect would then use the
>>>>>>> value
>>>>>>>       instead
>>>>>>>       of always using the "code" value.
>>>>>>>
>>>>>>>
>>>>>>>       Mit freundlichen Gr??en,
>>>>>>>
>>>>>>> ------------------------------------------------------------------------
>>>>>>>
>>>>>>>       *Christian Beikov*
>>>>>>>       Am 18.04.2018 um 17:35 schrieb Christian Beikov:
>>>>>>>       >
>>>>>>>       > Is there any way to avoid the access code to access token
>>>>>>> exchange?
>>>>>>>       > Since the Keycloak server is not accessible, I'm getting
>>>>>>> an error
>>>>>>>       > during authentication:
>>>>>>>       >
>>>>>>>       >  ERROR [org.keycloak.adapters.OAuthRequestAuthenticator]
>>>>>>> (default
>>>>>>>       > task-54) failed to turn code into token:
>>>>>>>       > java.net.UnknownHostException: blabla.local: unknown error
>>>>>>>       >         ...
>>>>>>>       >         at
>>>>>>>       >
>>>>>>>
>>>>>>> org.keycloak.adapters.ServerRequest.invokeAccessCodeToToken(ServerRequest.java:111)
>>>>>>>
>>>>>>>       >         at
>>>>>>>       >
>>>>>>>
>>>>>>> org.keycloak.adapters.OAuthRequestAuthenticator.resolveCode(OAuthRequestAuthenticator.java:330)
>>>>>>>
>>>>>>>       >         at
>>>>>>>       >
>>>>>>>
>>>>>>> org.keycloak.adapters.OAuthRequestAuthenticator.authenticate(OAuthRequestAuthenticator.java:275)
>>>>>>>
>>>>>>>       >         at
>>>>>>>       >
>>>>>>>
>>>>>>> org.keycloak.adapters.RequestAuthenticator.authenticate(RequestAuthenticator.java:139)
>>>>>>>
>>>>>>>       >         at
>>>>>>>       >
>>>>>>>
>>>>>>> org.keycloak.adapters.undertow.AbstractUndertowKeycloakAuthMech.keycloakAuthenticate(AbstractUndertowKeycloakAuthMech.java:110)
>>>>>>>
>>>>>>>       >         at
>>>>>>>       >
>>>>>>>
>>>>>>> org.keycloak.adapters.undertow.ServletKeycloakAuthMech.authenticate(ServletKeycloakAuthMech.java:92)
>>>>>>>
>>>>>>>       >         ...
>>>>>>>       >
>>>>>>>       >
>>>>>>>       > Mit freundlichen Gr??en,
>>>>>>>       >
>>>>>>>
>>>>>>> ------------------------------------------------------------------------
>>>>>>>
>>>>>>>       > *Christian Beikov*
>>>>>>>       > Am 18.04.2018 um 14:48 schrieb Thomas Darimont:
>>>>>>>       >> Hello Christian,
>>>>>>>       >>
>>>>>>>       >> your application server needs to communicate with the
>>>>>>> Keycloak
>>>>>>>       server
>>>>>>>       >> to retrieve the realm public key referenced in the token to
>>>>>>> verify
>>>>>>>       >> the token signature.
>>>>>>>       >> The current implementation in Keycloak fetches & caches
>>>>>>> unknown
>>>>>>>       >> public keys automatically.
>>>>>>>       >>
>>>>>>>       >> You could also use a fixed realm public key on the
>>>>>>> application
>>>>>>>       server
>>>>>>>       >> side but it would not support key rotation anymore.
>>>>>>>       >>
>>>>>>>       >> Cheers,
>>>>>>>       >> Thomas
>>>>>>>       >>
>>>>>>>       >> 2018-04-18 13:45 GMT+02:00 Christian Beikov
>>>>>>>       >> <christian.beikov at gmail.com
>>>>>>> <mailto:christian.beikov at gmail.com>
>>>>>>>       <mailto:christian.beikov at gmail.com
>>>>>>>       <mailto:christian.beikov at gmail.com>>>:
>>>>>>>       >>
>>>>>>>       >>     Hi,
>>>>>>>       >>
>>>>>>>       >>     is it necessary that an application secured by
>>>>>>> Keycloak can
>>>>>>>       >>     access the
>>>>>>>       >>     Keycloak server? Or is it enough if the Browser can
>>>>>>> access
>>>>>>> the
>>>>>>>       >>     Keycloak
>>>>>>>       >>     server?
>>>>>>>       >>
>>>>>>>       >>     --
>>>>>>>       >>
>>>>>>>       >>     Mit freundlichen Gr??en,
>>>>>>>       >>
>>>>>>>
>>>>>>> ------------------------------------------------------------------------
>>>>>>>
>>>>>>>       >>     *Christian Beikov*
>>>>>>>       >> _______________________________________________
>>>>>>>       >>     keycloak-dev mailing list
>>>>>>>       >> keycloak-dev at lists.jboss.org
>>>>>>>       <mailto:keycloak-dev at lists.jboss.org>
>>>>>>>       <mailto:keycloak-dev at lists.jboss.org
>>>>>>>       <mailto:keycloak-dev at lists.jboss.org>>
>>>>>>>       >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>> <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>>>>>>       >> <https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>> <https://lists.jboss.org/mailman/listinfo/keycloak-dev>>
>>>>>>>       >>
>>>>>>>       >>
>>>>>>>       >
>>>>>>>
>>>>>>>       _______________________________________________
>>>>>>>       keycloak-dev mailing list
>>>>>>>       keycloak-dev at lists.jboss.org
>>>>>>> <mailto:keycloak-dev at lists.jboss.org>
>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>> <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>>>>>>
>>>>>>>
>>>>>> _______________________________________________
>>>>>> keycloak-dev mailing list
>>>>>> keycloak-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>
>>>>>
>>>
>>>
>>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



-- 
Bill Burke
Red Hat


From cedric.couralet at gmail.com  Fri Apr 27 04:12:20 2018
From: cedric.couralet at gmail.com (=?UTF-8?Q?C=C3=A9dric_Couralet?=)
Date: Fri, 27 Apr 2018 10:12:20 +0200
Subject: [keycloak-dev] Application and server in separate networks
In-Reply-To: <CABRXCmw_DpdufKjVAZJ-=dNDLxnG=rQEw=ExKD7nwWuyQ7qhgQ@mail.gmail.com>
References: <41e1a805-cc38-50cf-f794-cda6afd49313@gmail.com>
	<CAK-7U1gGFnwc3EcgL3whgdGbSTH9xSVwVSHxc1i+JtetJ83H4g@mail.gmail.com>
	<24a0f868-9726-4024-6254-9a0b68b29c9f@gmail.com>
	<569a7f4e-2fa6-6590-2dfb-d7a57c137db2@gmail.com>
	<CAPLPygm2BHoNkrrYMWaOUHx1gGT-PbvSccTNf7JuuLjGeATrLg@mail.gmail.com>
	<d52de7b0-0041-46e2-f5ed-479fb0264528@gmail.com>
	<CABRXCmzfPqd-7rrMzox9UUAXkJZFngU=F6nUfh3ReNcA2P-6qg@mail.gmail.com>
	<e01068f2-8cd5-e855-86e3-1645ed36b118@redhat.com>
	<CABRXCmxdn_jnTPzRtLx6Rz80OUJUgMRRBvSg9jFDkyqP5zDyxg@mail.gmail.com>
	<1a844bee-aaf8-8c23-3e2d-c5bbefffa48e@redhat.com>
	<95470200-8cff-362d-5f0a-c345eed70b3c@gmail.com>
	<CABRXCmw_DpdufKjVAZJ-=dNDLxnG=rQEw=ExKD7nwWuyQ7qhgQ@mail.gmail.com>
Message-ID: <CAMwoAzcEJ7POg0svyQDMF0sHr0txZZAFsUmieEuCxsk-ezmMPw@mail.gmail.com>

2018-04-26 16:50 GMT+02:00 Bill Burke <bburke at redhat.com>:
> SAML would definitely work for your case so long as you don't need a
> token to make other REST invocations.

Hello,

A bit off topic, do you think keycloak could eventually support
https://tools.ietf.org/html/rfc7522 which allows to exchange a SAML
assertion for an oauth2 token, or is it not really in the scope ?

From Thomas.Dupont at UGent.be  Fri Apr 27 07:43:18 2018
From: Thomas.Dupont at UGent.be (Thomas Dupont (UGent-imec))
Date: Fri, 27 Apr 2018 11:43:18 +0000
Subject: [keycloak-dev] ProtocolMapper SPI NoClassDefFound on interfaces &
	abstract classes
Message-ID: <297a9d4fc81247efa02c090ebdbdbd4b@xmail403.UGent.be>

Hi,

I am currently implementing a custom ProtocolMapper for OIDC. The idea is that it can gather the value of an attribute field per group and add it to the token as an object indexed by group (for all groups the user is member of). eg. {myclaim: { group1: val1##val2, group2: val2##val3}}
I implemented a SimpleMapper class (implementing ProtocolMapper) and added the necessary META-INF/services/org.keycloak.protocol.ProtocolMapper file with the FQN of my class.
Deploying this works, and I can select the mapper in the keycloak mapping section.

If however I want my class to implement extra interfaces (like ) and extend org.keycloak.protocol.oidc.mappers.AbstractOIDCProtocolMapper, I get a NoClassDefFound in the logs of keycloak when deploying. The same issue arises when I want to use org.keycloak.protocol.oidc.mappers.OIDCAttributeMapperHelper in this class.

My dependencies in pom.xml are as follows (keycloak.version = 4.0.0.Beta1):

<dependencies>
    <dependency>
        <groupId>org.keycloak</groupId>
        <artifactId>keycloak-core</artifactId>
        <version>${keycloak.version}</version>
    </dependency>
    <dependency>
        <groupId>org.keycloak</groupId>
        <artifactId>keycloak-server-spi</artifactId>
        <version>${keycloak.version}</version>
    </dependency>
    <dependency>
        <groupId>org.keycloak</groupId>
        <artifactId>keycloak-server-spi-private</artifactId>
        <version>${keycloak.version}</version>
    </dependency>
    <dependency>
        <groupId>org.keycloak</groupId>
        <artifactId>keycloak-services</artifactId>
        <version>${keycloak.version}</version>
    </dependency>
</dependencies>

How can I implement from those interfaces, extend from that class or use the helper class? Am I missing something here? Any help is greatly appreciated!


From christian.beikov at gmail.com  Sat Apr 28 11:11:26 2018
From: christian.beikov at gmail.com (Christian Beikov)
Date: Sat, 28 Apr 2018 17:11:26 +0200
Subject: [keycloak-dev] Application and server in separate networks
In-Reply-To: <CABRXCmw_DpdufKjVAZJ-=dNDLxnG=rQEw=ExKD7nwWuyQ7qhgQ@mail.gmail.com>
References: <41e1a805-cc38-50cf-f794-cda6afd49313@gmail.com>
	<CAK-7U1gGFnwc3EcgL3whgdGbSTH9xSVwVSHxc1i+JtetJ83H4g@mail.gmail.com>
	<24a0f868-9726-4024-6254-9a0b68b29c9f@gmail.com>
	<569a7f4e-2fa6-6590-2dfb-d7a57c137db2@gmail.com>
	<CAPLPygm2BHoNkrrYMWaOUHx1gGT-PbvSccTNf7JuuLjGeATrLg@mail.gmail.com>
	<d52de7b0-0041-46e2-f5ed-479fb0264528@gmail.com>
	<CABRXCmzfPqd-7rrMzox9UUAXkJZFngU=F6nUfh3ReNcA2P-6qg@mail.gmail.com>
	<e01068f2-8cd5-e855-86e3-1645ed36b118@redhat.com>
	<CABRXCmxdn_jnTPzRtLx6Rz80OUJUgMRRBvSg9jFDkyqP5zDyxg@mail.gmail.com>
	<1a844bee-aaf8-8c23-3e2d-c5bbefffa48e@redhat.com>
	<95470200-8cff-362d-5f0a-c345eed70b3c@gmail.com>
	<CABRXCmw_DpdufKjVAZJ-=dNDLxnG=rQEw=ExKD7nwWuyQ7qhgQ@mail.gmail.com>
Message-ID: <7f7e0950-7d2d-7794-830f-f5edd2ec0ec0@gmail.com>

I can't get SAML to work. Everytime I try to access a protected page, I 
get the error "Client is not allowed to initiate browser login with 
given response_type. Standard flow is disabled for the client".

In the logs I see "type=LOGIN_ERROR, realmId=LOCAL, clientId=null, 
userId=null, ipAddress=10.0.0.1, error=not_allowed"

Is there anything I can do to further debug this? I'm using 3.3.0.Final 
and configured SAML via keycloak-saml.xml having roughly the following 
content

<?xml version="1.0" encoding="UTF-8"?>
<keycloak-saml-adapter xmlns="urn:keycloak:saml:adapter"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:keycloak:saml:adapter 
http://www.keycloak.org/schema/keycloak_saml_adapter_1_7.xsd">
 ??? <SP entityID="myapp"
 ??????? sslPolicy="EXTERNAL"
nameIDPolicyFormat="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"
 ??????? logoutPage="/logout"
 ??????? forceAuthentication="false"
 ??????? isPassive="false"
 ??????? turnOffChangeSessionIdOnLogin="false">
 ??????? <IDP entityID="idp"
 ???????????? signaturesRequired="false">
 ??????????? <SingleSignOnService requestBinding="POST"
bindingUrl="http://auth.company.com:8081/auth/realms/LOCAL/protocol/saml"
 ??????????? />

 ??????????? <SingleLogoutService
 ??????????????????? requestBinding="POST"
 ??????????????????? responseBinding="POST"
postBindingUrl="http://auth.company.com:8081/auth/realms/LOCAL/protocol/saml"
redirectBindingUrl="http://auth.company.com:8081/auth/realms/LOCAL/protocol/saml"
 ??????????? />
 ??????? </IDP>
 ??? </SP>
</keycloak-saml-adapter>

Am I missing something or is having a SAML endpoint on Keycloak along 
with a SAML client not a supported scenario configuration?

Mit freundlichen Gr??en,
------------------------------------------------------------------------
*Christian Beikov*
Am 26.04.2018 um 16:50 schrieb Bill Burke:
> SAML would definitely work for your case so long as you don't need a
> token to make other REST invocations.
>
> On Thu, Apr 26, 2018 at 9:59 AM, Christian Beikov
> <christian.beikov at gmail.com> wrote:
>> Thanks for the hints. I'll try to see if I can get SAML to work and let
>> you know of the result. Anyway, the POST response_mode sounds promising
>> and would definitely work in our case. When I put the URL hash I got
>> while testing into the query part of the URL, the authentication worked
>> properly. So doing a form encoded POST would probably work as well.
>>
>>
>> Mit freundlichen Gr??en,
>> ------------------------------------------------------------------------
>> *Christian Beikov*
>> Am 26.04.2018 um 15:06 schrieb Marek Posolda:
>>> I think it works, but didn't tested that combination. And POST is not
>>> supported by any of our adapters ATM, just by server. I know that some
>>> of our users use Form POST with 3rd party adapters, but likely the
>>> combination of FormPOST with standard flow.
>>>
>>> On 26/04/18 14:38, Bill Burke wrote:
>>>> Cool, so POST mode works with Implicit?
>>>>
>>>> On Thu, Apr 26, 2018 at 4:16 AM, Marek Posolda <mposolda at redhat.com>
>>>> wrote:
>>>>> We support response_mode parameter and we also support HTML POST mode
>>>>> already on server side. But we specifically disallow "query"
>>>>> response_mode
>>>>> with implicit flow [1] . This is required per specification and OIDC
>>>>> certification had a test exactly for this AFAIR.
>>>>>
>>>>> [1]
>>>>> https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/protocol/oidc/endpoints/AuthorizationEndpoint.java#L227
>>>>>
>>>>>
>>>>> Marek
>>>>>
>>>>>
>>>>> On 25/04/18 23:20, Bill Burke wrote:
>>>>>> We should probably support response_mode parameter [1] and allow
>>>>>> "query" mode for implicit invocations.  IMO, the HTML POST mode [2]
>>>>>> (like SAML does) would be better as with implicit mode, the access
>>>>>> token is leaked to browser history.
>>>>>>
>>>>>> [1] https://openid.net/specs/oauth-v2-multiple-response-types-1_0.html
>>>>>> [2] http://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html
>>>>>>
>>>>>> On Wed, Apr 25, 2018 at 4:14 PM, Christian Beikov
>>>>>> <christian.beikov at gmail.com> wrote:
>>>>>>> Hey all,
>>>>>>>
>>>>>>> we reached a point where we are not sure how to proceed with the PR
>>>>>>> https://github.com/keycloak/keycloak/pull/5167 for
>>>>>>> https://issues.jboss.org/browse/KEYCLOAK-7195
>>>>>>>
>>>>>>> We added a client adapter configuration for the flow and that part
>>>>>>> works
>>>>>>> so far, but we noticed that when the Keycloak server encounters a
>>>>>>> request for authetication via the implicit flow, it puts the token
>>>>>>> into
>>>>>>> the query fragment part which isn't sent to the application. This
>>>>>>> is the
>>>>>>> point where it becomes obvious this mechanism is intended for the JS
>>>>>>> adapter :)
>>>>>>>
>>>>>>> To resolve the problem and make the flow usable for the Java
>>>>>>> adapter as
>>>>>>> well, we'd need some way to configure the response mode in the
>>>>>>> OIDCLoginProtocol. My question is, how you think this should be done.
>>>>>>> I was thinking of either allowing a query parameter to specify the
>>>>>>> response mode or a configuration switch in the UI for the client.
>>>>>>> I kind
>>>>>>> of prefer the query parameter solution.
>>>>>>>
>>>>>>> Is this even a change/feature you would be interested in? We need the
>>>>>>> implicit flow because the Keycloak server is in a private network
>>>>>>> that
>>>>>>> is separate from the application. Maybe there are other people out
>>>>>>> there
>>>>>>> that have similar needs?
>>>>>>>
>>>>>>> Mit freundlichen Gr??en,
>>>>>>> ------------------------------------------------------------------------
>>>>>>>
>>>>>>> *Christian Beikov*
>>>>>>> Am 20.04.2018 um 09:15 schrieb Niels Bertram:
>>>>>>>> Hi Christian,
>>>>>>>>
>>>>>>>> can't say for sure but the server side adapters always use standard
>>>>>>>> authorization flow, which requires your Java app to connect via a
>>>>>>>> back
>>>>>>>> channel to (A) exchange code grant for access tokens and (B) to
>>>>>>>> lookup
>>>>>>>> jwks for token validation.
>>>>>>>>
>>>>>>>> The OpenID Connect specification does provide a pure browser based
>>>>>>>> flow calledimplicit flow
>>>>>>>>
>>>>>>>> <http://openid.net/specs/openid-connect-core-1_0.html#ImplicitFlowAuth>but
>>>>>>>>
>>>>>>>> that one has a few drawbacks such as auth tokens delivered in the
>>>>>>>> redirect URL and no refresh token capability. Using this flow could
>>>>>>>> solve your problem (A) to shift login flow to the frontend but still
>>>>>>>> poses the challenge for (B) validating the tokens at the backend.
>>>>>>>>
>>>>>>>> I could not find a way to configure the Java adapter to work in pure
>>>>>>>> offline validation mode. We had a similar requirement some time ago
>>>>>>>> and had to code our own auth module to validate incoming tokens
>>>>>>>> with a
>>>>>>>> pre-configured public key. The other common problem we ran into is
>>>>>>>> wanting to validate tokens from different (including non-keycloak)
>>>>>>>> issuers on the same backend. The Keycloak Java adapters do not
>>>>>>>> support
>>>>>>>> this use case either. We originally looked at the Spring JWT adapter
>>>>>>>>
>>>>>>>> <https://github.com/spring-projects/spring-security-oauth/tree/master/spring-security-jwt>
>>>>>>>>
>>>>>>>> as an alternative but this project is not properly patched and
>>>>>>>> configuration is a wonderful garden of mystery like everything in
>>>>>>>> Spring.
>>>>>>>>
>>>>>>>> Very curious though to see what others are doing.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Niels
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, Apr 19, 2018 at 2:16 AM, Christian Beikov
>>>>>>>> <christian.beikov at gmail.com <mailto:christian.beikov at gmail.com>>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>        As far as I see in the code, the Java Adapters always use the
>>>>>>>>        standard
>>>>>>>>        flow i.e. response_type=code
>>>>>>>>
>>>>>>>>        Please tell me this observation is wrong and there is an
>>>>>>>> undocumented
>>>>>>>>        setting I just didn't see that I can use to tell the
>>>>>>>> adapter to
>>>>>>>>        use the
>>>>>>>>        implicit flow instead :|
>>>>>>>>
>>>>>>>>        If this is really missing, where would you suggest this
>>>>>>>> should be
>>>>>>>>        configured? I'd expect the setting to be in
>>>>>>>> KeycloakDeployment and
>>>>>>>>        OAuthRequestAuthenticator#loginRedirect would then use the
>>>>>>>> value
>>>>>>>>        instead
>>>>>>>>        of always using the "code" value.
>>>>>>>>
>>>>>>>>
>>>>>>>>        Mit freundlichen Gr??en,
>>>>>>>>
>>>>>>>> ------------------------------------------------------------------------
>>>>>>>>
>>>>>>>>        *Christian Beikov*
>>>>>>>>        Am 18.04.2018 um 17:35 schrieb Christian Beikov:
>>>>>>>>        >
>>>>>>>>        > Is there any way to avoid the access code to access token
>>>>>>>> exchange?
>>>>>>>>        > Since the Keycloak server is not accessible, I'm getting
>>>>>>>> an error
>>>>>>>>        > during authentication:
>>>>>>>>        >
>>>>>>>>        >  ERROR [org.keycloak.adapters.OAuthRequestAuthenticator]
>>>>>>>> (default
>>>>>>>>        > task-54) failed to turn code into token:
>>>>>>>>        > java.net.UnknownHostException: blabla.local: unknown error
>>>>>>>>        >         ...
>>>>>>>>        >         at
>>>>>>>>        >
>>>>>>>>
>>>>>>>> org.keycloak.adapters.ServerRequest.invokeAccessCodeToToken(ServerRequest.java:111)
>>>>>>>>
>>>>>>>>        >         at
>>>>>>>>        >
>>>>>>>>
>>>>>>>> org.keycloak.adapters.OAuthRequestAuthenticator.resolveCode(OAuthRequestAuthenticator.java:330)
>>>>>>>>
>>>>>>>>        >         at
>>>>>>>>        >
>>>>>>>>
>>>>>>>> org.keycloak.adapters.OAuthRequestAuthenticator.authenticate(OAuthRequestAuthenticator.java:275)
>>>>>>>>
>>>>>>>>        >         at
>>>>>>>>        >
>>>>>>>>
>>>>>>>> org.keycloak.adapters.RequestAuthenticator.authenticate(RequestAuthenticator.java:139)
>>>>>>>>
>>>>>>>>        >         at
>>>>>>>>        >
>>>>>>>>
>>>>>>>> org.keycloak.adapters.undertow.AbstractUndertowKeycloakAuthMech.keycloakAuthenticate(AbstractUndertowKeycloakAuthMech.java:110)
>>>>>>>>
>>>>>>>>        >         at
>>>>>>>>        >
>>>>>>>>
>>>>>>>> org.keycloak.adapters.undertow.ServletKeycloakAuthMech.authenticate(ServletKeycloakAuthMech.java:92)
>>>>>>>>
>>>>>>>>        >         ...
>>>>>>>>        >
>>>>>>>>        >
>>>>>>>>        > Mit freundlichen Gr??en,
>>>>>>>>        >
>>>>>>>>
>>>>>>>> ------------------------------------------------------------------------
>>>>>>>>
>>>>>>>>        > *Christian Beikov*
>>>>>>>>        > Am 18.04.2018 um 14:48 schrieb Thomas Darimont:
>>>>>>>>        >> Hello Christian,
>>>>>>>>        >>
>>>>>>>>        >> your application server needs to communicate with the
>>>>>>>> Keycloak
>>>>>>>>        server
>>>>>>>>        >> to retrieve the realm public key referenced in the token to
>>>>>>>> verify
>>>>>>>>        >> the token signature.
>>>>>>>>        >> The current implementation in Keycloak fetches & caches
>>>>>>>> unknown
>>>>>>>>        >> public keys automatically.
>>>>>>>>        >>
>>>>>>>>        >> You could also use a fixed realm public key on the
>>>>>>>> application
>>>>>>>>        server
>>>>>>>>        >> side but it would not support key rotation anymore.
>>>>>>>>        >>
>>>>>>>>        >> Cheers,
>>>>>>>>        >> Thomas
>>>>>>>>        >>
>>>>>>>>        >> 2018-04-18 13:45 GMT+02:00 Christian Beikov
>>>>>>>>        >> <christian.beikov at gmail.com
>>>>>>>> <mailto:christian.beikov at gmail.com>
>>>>>>>>        <mailto:christian.beikov at gmail.com
>>>>>>>>        <mailto:christian.beikov at gmail.com>>>:
>>>>>>>>        >>
>>>>>>>>        >>     Hi,
>>>>>>>>        >>
>>>>>>>>        >>     is it necessary that an application secured by
>>>>>>>> Keycloak can
>>>>>>>>        >>     access the
>>>>>>>>        >>     Keycloak server? Or is it enough if the Browser can
>>>>>>>> access
>>>>>>>> the
>>>>>>>>        >>     Keycloak
>>>>>>>>        >>     server?
>>>>>>>>        >>
>>>>>>>>        >>     --
>>>>>>>>        >>
>>>>>>>>        >>     Mit freundlichen Gr??en,
>>>>>>>>        >>
>>>>>>>>
>>>>>>>> ------------------------------------------------------------------------
>>>>>>>>
>>>>>>>>        >>     *Christian Beikov*
>>>>>>>>        >> _______________________________________________
>>>>>>>>        >>     keycloak-dev mailing list
>>>>>>>>        >> keycloak-dev at lists.jboss.org
>>>>>>>>        <mailto:keycloak-dev at lists.jboss.org>
>>>>>>>>        <mailto:keycloak-dev at lists.jboss.org
>>>>>>>>        <mailto:keycloak-dev at lists.jboss.org>>
>>>>>>>>        >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>> <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>>>>>>>        >> <https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>> <https://lists.jboss.org/mailman/listinfo/keycloak-dev>>
>>>>>>>>        >>
>>>>>>>>        >>
>>>>>>>>        >
>>>>>>>>
>>>>>>>>        _______________________________________________
>>>>>>>>        keycloak-dev mailing list
>>>>>>>>        keycloak-dev at lists.jboss.org
>>>>>>>> <mailto:keycloak-dev at lists.jboss.org>
>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>> <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>>>>>>>
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> keycloak-dev mailing list
>>>>>>> keycloak-dev at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>
>>>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>


From bburke at redhat.com  Sat Apr 28 12:32:14 2018
From: bburke at redhat.com (Bill Burke)
Date: Sat, 28 Apr 2018 12:32:14 -0400
Subject: [keycloak-dev] Application and server in separate networks
In-Reply-To: <7f7e0950-7d2d-7794-830f-f5edd2ec0ec0@gmail.com>
References: <41e1a805-cc38-50cf-f794-cda6afd49313@gmail.com>
	<CAK-7U1gGFnwc3EcgL3whgdGbSTH9xSVwVSHxc1i+JtetJ83H4g@mail.gmail.com>
	<24a0f868-9726-4024-6254-9a0b68b29c9f@gmail.com>
	<569a7f4e-2fa6-6590-2dfb-d7a57c137db2@gmail.com>
	<CAPLPygm2BHoNkrrYMWaOUHx1gGT-PbvSccTNf7JuuLjGeATrLg@mail.gmail.com>
	<d52de7b0-0041-46e2-f5ed-479fb0264528@gmail.com>
	<CABRXCmzfPqd-7rrMzox9UUAXkJZFngU=F6nUfh3ReNcA2P-6qg@mail.gmail.com>
	<e01068f2-8cd5-e855-86e3-1645ed36b118@redhat.com>
	<CABRXCmxdn_jnTPzRtLx6Rz80OUJUgMRRBvSg9jFDkyqP5zDyxg@mail.gmail.com>
	<1a844bee-aaf8-8c23-3e2d-c5bbefffa48e@redhat.com>
	<95470200-8cff-362d-5f0a-c345eed70b3c@gmail.com>
	<CABRXCmw_DpdufKjVAZJ-=dNDLxnG=rQEw=ExKD7nwWuyQ7qhgQ@mail.gmail.com>
	<7f7e0950-7d2d-7794-830f-f5edd2ec0ec0@gmail.com>
Message-ID: <CABRXCmyzLO8r=c3Wfq=zg=Vo=ngZCHpp+zAV3Ut1MyY=1Zj2zA@mail.gmail.com>

Enable standard flow for the client.  Its a switch in admin console
client config.

On Sat, Apr 28, 2018 at 11:11 AM, Christian Beikov
<christian.beikov at gmail.com> wrote:
> I can't get SAML to work. Everytime I try to access a protected page, I
> get the error "Client is not allowed to initiate browser login with
> given response_type. Standard flow is disabled for the client".
>
> In the logs I see "type=LOGIN_ERROR, realmId=LOCAL, clientId=null,
> userId=null, ipAddress=10.0.0.1, error=not_allowed"
>
> Is there anything I can do to further debug this? I'm using 3.3.0.Final
> and configured SAML via keycloak-saml.xml having roughly the following
> content
>
> <?xml version="1.0" encoding="UTF-8"?>
> <keycloak-saml-adapter xmlns="urn:keycloak:saml:adapter"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="urn:keycloak:saml:adapter
> http://www.keycloak.org/schema/keycloak_saml_adapter_1_7.xsd">
>      <SP entityID="myapp"
>          sslPolicy="EXTERNAL"
> nameIDPolicyFormat="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"
>          logoutPage="/logout"
>          forceAuthentication="false"
>          isPassive="false"
>          turnOffChangeSessionIdOnLogin="false">
>          <IDP entityID="idp"
>               signaturesRequired="false">
>              <SingleSignOnService requestBinding="POST"
> bindingUrl="http://auth.company.com:8081/auth/realms/LOCAL/protocol/saml"
>              />
>
>              <SingleLogoutService
>                      requestBinding="POST"
>                      responseBinding="POST"
> postBindingUrl="http://auth.company.com:8081/auth/realms/LOCAL/protocol/saml"
> redirectBindingUrl="http://auth.company.com:8081/auth/realms/LOCAL/protocol/saml"
>              />
>          </IDP>
>      </SP>
> </keycloak-saml-adapter>
>
> Am I missing something or is having a SAML endpoint on Keycloak along
> with a SAML client not a supported scenario configuration?
>
> Mit freundlichen Gr??en,
> ------------------------------------------------------------------------
> *Christian Beikov*
> Am 26.04.2018 um 16:50 schrieb Bill Burke:
>> SAML would definitely work for your case so long as you don't need a
>> token to make other REST invocations.
>>
>> On Thu, Apr 26, 2018 at 9:59 AM, Christian Beikov
>> <christian.beikov at gmail.com> wrote:
>>> Thanks for the hints. I'll try to see if I can get SAML to work and let
>>> you know of the result. Anyway, the POST response_mode sounds promising
>>> and would definitely work in our case. When I put the URL hash I got
>>> while testing into the query part of the URL, the authentication worked
>>> properly. So doing a form encoded POST would probably work as well.
>>>
>>>
>>> Mit freundlichen Gr??en,
>>> ------------------------------------------------------------------------
>>> *Christian Beikov*
>>> Am 26.04.2018 um 15:06 schrieb Marek Posolda:
>>>> I think it works, but didn't tested that combination. And POST is not
>>>> supported by any of our adapters ATM, just by server. I know that some
>>>> of our users use Form POST with 3rd party adapters, but likely the
>>>> combination of FormPOST with standard flow.
>>>>
>>>> On 26/04/18 14:38, Bill Burke wrote:
>>>>> Cool, so POST mode works with Implicit?
>>>>>
>>>>> On Thu, Apr 26, 2018 at 4:16 AM, Marek Posolda <mposolda at redhat.com>
>>>>> wrote:
>>>>>> We support response_mode parameter and we also support HTML POST mode
>>>>>> already on server side. But we specifically disallow "query"
>>>>>> response_mode
>>>>>> with implicit flow [1] . This is required per specification and OIDC
>>>>>> certification had a test exactly for this AFAIR.
>>>>>>
>>>>>> [1]
>>>>>> https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/protocol/oidc/endpoints/AuthorizationEndpoint.java#L227
>>>>>>
>>>>>>
>>>>>> Marek
>>>>>>
>>>>>>
>>>>>> On 25/04/18 23:20, Bill Burke wrote:
>>>>>>> We should probably support response_mode parameter [1] and allow
>>>>>>> "query" mode for implicit invocations.  IMO, the HTML POST mode [2]
>>>>>>> (like SAML does) would be better as with implicit mode, the access
>>>>>>> token is leaked to browser history.
>>>>>>>
>>>>>>> [1] https://openid.net/specs/oauth-v2-multiple-response-types-1_0.html
>>>>>>> [2] http://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html
>>>>>>>
>>>>>>> On Wed, Apr 25, 2018 at 4:14 PM, Christian Beikov
>>>>>>> <christian.beikov at gmail.com> wrote:
>>>>>>>> Hey all,
>>>>>>>>
>>>>>>>> we reached a point where we are not sure how to proceed with the PR
>>>>>>>> https://github.com/keycloak/keycloak/pull/5167 for
>>>>>>>> https://issues.jboss.org/browse/KEYCLOAK-7195
>>>>>>>>
>>>>>>>> We added a client adapter configuration for the flow and that part
>>>>>>>> works
>>>>>>>> so far, but we noticed that when the Keycloak server encounters a
>>>>>>>> request for authetication via the implicit flow, it puts the token
>>>>>>>> into
>>>>>>>> the query fragment part which isn't sent to the application. This
>>>>>>>> is the
>>>>>>>> point where it becomes obvious this mechanism is intended for the JS
>>>>>>>> adapter :)
>>>>>>>>
>>>>>>>> To resolve the problem and make the flow usable for the Java
>>>>>>>> adapter as
>>>>>>>> well, we'd need some way to configure the response mode in the
>>>>>>>> OIDCLoginProtocol. My question is, how you think this should be done.
>>>>>>>> I was thinking of either allowing a query parameter to specify the
>>>>>>>> response mode or a configuration switch in the UI for the client.
>>>>>>>> I kind
>>>>>>>> of prefer the query parameter solution.
>>>>>>>>
>>>>>>>> Is this even a change/feature you would be interested in? We need the
>>>>>>>> implicit flow because the Keycloak server is in a private network
>>>>>>>> that
>>>>>>>> is separate from the application. Maybe there are other people out
>>>>>>>> there
>>>>>>>> that have similar needs?
>>>>>>>>
>>>>>>>> Mit freundlichen Gr??en,
>>>>>>>> ------------------------------------------------------------------------
>>>>>>>>
>>>>>>>> *Christian Beikov*
>>>>>>>> Am 20.04.2018 um 09:15 schrieb Niels Bertram:
>>>>>>>>> Hi Christian,
>>>>>>>>>
>>>>>>>>> can't say for sure but the server side adapters always use standard
>>>>>>>>> authorization flow, which requires your Java app to connect via a
>>>>>>>>> back
>>>>>>>>> channel to (A) exchange code grant for access tokens and (B) to
>>>>>>>>> lookup
>>>>>>>>> jwks for token validation.
>>>>>>>>>
>>>>>>>>> The OpenID Connect specification does provide a pure browser based
>>>>>>>>> flow calledimplicit flow
>>>>>>>>>
>>>>>>>>> <http://openid.net/specs/openid-connect-core-1_0.html#ImplicitFlowAuth>but
>>>>>>>>>
>>>>>>>>> that one has a few drawbacks such as auth tokens delivered in the
>>>>>>>>> redirect URL and no refresh token capability. Using this flow could
>>>>>>>>> solve your problem (A) to shift login flow to the frontend but still
>>>>>>>>> poses the challenge for (B) validating the tokens at the backend.
>>>>>>>>>
>>>>>>>>> I could not find a way to configure the Java adapter to work in pure
>>>>>>>>> offline validation mode. We had a similar requirement some time ago
>>>>>>>>> and had to code our own auth module to validate incoming tokens
>>>>>>>>> with a
>>>>>>>>> pre-configured public key. The other common problem we ran into is
>>>>>>>>> wanting to validate tokens from different (including non-keycloak)
>>>>>>>>> issuers on the same backend. The Keycloak Java adapters do not
>>>>>>>>> support
>>>>>>>>> this use case either. We originally looked at the Spring JWT adapter
>>>>>>>>>
>>>>>>>>> <https://github.com/spring-projects/spring-security-oauth/tree/master/spring-security-jwt>
>>>>>>>>>
>>>>>>>>> as an alternative but this project is not properly patched and
>>>>>>>>> configuration is a wonderful garden of mystery like everything in
>>>>>>>>> Spring.
>>>>>>>>>
>>>>>>>>> Very curious though to see what others are doing.
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Niels
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Thu, Apr 19, 2018 at 2:16 AM, Christian Beikov
>>>>>>>>> <christian.beikov at gmail.com <mailto:christian.beikov at gmail.com>>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>        As far as I see in the code, the Java Adapters always use the
>>>>>>>>>        standard
>>>>>>>>>        flow i.e. response_type=code
>>>>>>>>>
>>>>>>>>>        Please tell me this observation is wrong and there is an
>>>>>>>>> undocumented
>>>>>>>>>        setting I just didn't see that I can use to tell the
>>>>>>>>> adapter to
>>>>>>>>>        use the
>>>>>>>>>        implicit flow instead :|
>>>>>>>>>
>>>>>>>>>        If this is really missing, where would you suggest this
>>>>>>>>> should be
>>>>>>>>>        configured? I'd expect the setting to be in
>>>>>>>>> KeycloakDeployment and
>>>>>>>>>        OAuthRequestAuthenticator#loginRedirect would then use the
>>>>>>>>> value
>>>>>>>>>        instead
>>>>>>>>>        of always using the "code" value.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>        Mit freundlichen Gr??en,
>>>>>>>>>
>>>>>>>>> ------------------------------------------------------------------------
>>>>>>>>>
>>>>>>>>>        *Christian Beikov*
>>>>>>>>>        Am 18.04.2018 um 17:35 schrieb Christian Beikov:
>>>>>>>>>        >
>>>>>>>>>        > Is there any way to avoid the access code to access token
>>>>>>>>> exchange?
>>>>>>>>>        > Since the Keycloak server is not accessible, I'm getting
>>>>>>>>> an error
>>>>>>>>>        > during authentication:
>>>>>>>>>        >
>>>>>>>>>        >  ERROR [org.keycloak.adapters.OAuthRequestAuthenticator]
>>>>>>>>> (default
>>>>>>>>>        > task-54) failed to turn code into token:
>>>>>>>>>        > java.net.UnknownHostException: blabla.local: unknown error
>>>>>>>>>        >         ...
>>>>>>>>>        >         at
>>>>>>>>>        >
>>>>>>>>>
>>>>>>>>> org.keycloak.adapters.ServerRequest.invokeAccessCodeToToken(ServerRequest.java:111)
>>>>>>>>>
>>>>>>>>>        >         at
>>>>>>>>>        >
>>>>>>>>>
>>>>>>>>> org.keycloak.adapters.OAuthRequestAuthenticator.resolveCode(OAuthRequestAuthenticator.java:330)
>>>>>>>>>
>>>>>>>>>        >         at
>>>>>>>>>        >
>>>>>>>>>
>>>>>>>>> org.keycloak.adapters.OAuthRequestAuthenticator.authenticate(OAuthRequestAuthenticator.java:275)
>>>>>>>>>
>>>>>>>>>        >         at
>>>>>>>>>        >
>>>>>>>>>
>>>>>>>>> org.keycloak.adapters.RequestAuthenticator.authenticate(RequestAuthenticator.java:139)
>>>>>>>>>
>>>>>>>>>        >         at
>>>>>>>>>        >
>>>>>>>>>
>>>>>>>>> org.keycloak.adapters.undertow.AbstractUndertowKeycloakAuthMech.keycloakAuthenticate(AbstractUndertowKeycloakAuthMech.java:110)
>>>>>>>>>
>>>>>>>>>        >         at
>>>>>>>>>        >
>>>>>>>>>
>>>>>>>>> org.keycloak.adapters.undertow.ServletKeycloakAuthMech.authenticate(ServletKeycloakAuthMech.java:92)
>>>>>>>>>
>>>>>>>>>        >         ...
>>>>>>>>>        >
>>>>>>>>>        >
>>>>>>>>>        > Mit freundlichen Gr??en,
>>>>>>>>>        >
>>>>>>>>>
>>>>>>>>> ------------------------------------------------------------------------
>>>>>>>>>
>>>>>>>>>        > *Christian Beikov*
>>>>>>>>>        > Am 18.04.2018 um 14:48 schrieb Thomas Darimont:
>>>>>>>>>        >> Hello Christian,
>>>>>>>>>        >>
>>>>>>>>>        >> your application server needs to communicate with the
>>>>>>>>> Keycloak
>>>>>>>>>        server
>>>>>>>>>        >> to retrieve the realm public key referenced in the token to
>>>>>>>>> verify
>>>>>>>>>        >> the token signature.
>>>>>>>>>        >> The current implementation in Keycloak fetches & caches
>>>>>>>>> unknown
>>>>>>>>>        >> public keys automatically.
>>>>>>>>>        >>
>>>>>>>>>        >> You could also use a fixed realm public key on the
>>>>>>>>> application
>>>>>>>>>        server
>>>>>>>>>        >> side but it would not support key rotation anymore.
>>>>>>>>>        >>
>>>>>>>>>        >> Cheers,
>>>>>>>>>        >> Thomas
>>>>>>>>>        >>
>>>>>>>>>        >> 2018-04-18 13:45 GMT+02:00 Christian Beikov
>>>>>>>>>        >> <christian.beikov at gmail.com
>>>>>>>>> <mailto:christian.beikov at gmail.com>
>>>>>>>>>        <mailto:christian.beikov at gmail.com
>>>>>>>>>        <mailto:christian.beikov at gmail.com>>>:
>>>>>>>>>        >>
>>>>>>>>>        >>     Hi,
>>>>>>>>>        >>
>>>>>>>>>        >>     is it necessary that an application secured by
>>>>>>>>> Keycloak can
>>>>>>>>>        >>     access the
>>>>>>>>>        >>     Keycloak server? Or is it enough if the Browser can
>>>>>>>>> access
>>>>>>>>> the
>>>>>>>>>        >>     Keycloak
>>>>>>>>>        >>     server?
>>>>>>>>>        >>
>>>>>>>>>        >>     --
>>>>>>>>>        >>
>>>>>>>>>        >>     Mit freundlichen Gr??en,
>>>>>>>>>        >>
>>>>>>>>>
>>>>>>>>> ------------------------------------------------------------------------
>>>>>>>>>
>>>>>>>>>        >>     *Christian Beikov*
>>>>>>>>>        >> _______________________________________________
>>>>>>>>>        >>     keycloak-dev mailing list
>>>>>>>>>        >> keycloak-dev at lists.jboss.org
>>>>>>>>>        <mailto:keycloak-dev at lists.jboss.org>
>>>>>>>>>        <mailto:keycloak-dev at lists.jboss.org
>>>>>>>>>        <mailto:keycloak-dev at lists.jboss.org>>
>>>>>>>>>        >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>>> <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>>>>>>>>        >> <https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>>> <https://lists.jboss.org/mailman/listinfo/keycloak-dev>>
>>>>>>>>>        >>
>>>>>>>>>        >>
>>>>>>>>>        >
>>>>>>>>>
>>>>>>>>>        _______________________________________________
>>>>>>>>>        keycloak-dev mailing list
>>>>>>>>>        keycloak-dev at lists.jboss.org
>>>>>>>>> <mailto:keycloak-dev at lists.jboss.org>
>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>>> <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> keycloak-dev mailing list
>>>>>>>> keycloak-dev at lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>
>>>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



-- 
Bill Burke
Red Hat


From bburke at redhat.com  Sat Apr 28 12:33:20 2018
From: bburke at redhat.com (Bill Burke)
Date: Sat, 28 Apr 2018 12:33:20 -0400
Subject: [keycloak-dev] Application and server in separate networks
In-Reply-To: <CABRXCmyzLO8r=c3Wfq=zg=Vo=ngZCHpp+zAV3Ut1MyY=1Zj2zA@mail.gmail.com>
References: <41e1a805-cc38-50cf-f794-cda6afd49313@gmail.com>
	<CAK-7U1gGFnwc3EcgL3whgdGbSTH9xSVwVSHxc1i+JtetJ83H4g@mail.gmail.com>
	<24a0f868-9726-4024-6254-9a0b68b29c9f@gmail.com>
	<569a7f4e-2fa6-6590-2dfb-d7a57c137db2@gmail.com>
	<CAPLPygm2BHoNkrrYMWaOUHx1gGT-PbvSccTNf7JuuLjGeATrLg@mail.gmail.com>
	<d52de7b0-0041-46e2-f5ed-479fb0264528@gmail.com>
	<CABRXCmzfPqd-7rrMzox9UUAXkJZFngU=F6nUfh3ReNcA2P-6qg@mail.gmail.com>
	<e01068f2-8cd5-e855-86e3-1645ed36b118@redhat.com>
	<CABRXCmxdn_jnTPzRtLx6Rz80OUJUgMRRBvSg9jFDkyqP5zDyxg@mail.gmail.com>
	<1a844bee-aaf8-8c23-3e2d-c5bbefffa48e@redhat.com>
	<95470200-8cff-362d-5f0a-c345eed70b3c@gmail.com>
	<CABRXCmw_DpdufKjVAZJ-=dNDLxnG=rQEw=ExKD7nwWuyQ7qhgQ@mail.gmail.com>
	<7f7e0950-7d2d-7794-830f-f5edd2ec0ec0@gmail.com>
	<CABRXCmyzLO8r=c3Wfq=zg=Vo=ngZCHpp+zAV3Ut1MyY=1Zj2zA@mail.gmail.com>
Message-ID: <CABRXCmwvjmYuLXJg4hXR8HZs=YX_U9pza5sGcLXd0_hQ-03cDg@mail.gmail.com>

Also make sure that your client id matches the one configured for the
client in the admin console.  That might be the problem too.

On Sat, Apr 28, 2018 at 12:32 PM, Bill Burke <bburke at redhat.com> wrote:
> Enable standard flow for the client.  Its a switch in admin console
> client config.
>
> On Sat, Apr 28, 2018 at 11:11 AM, Christian Beikov
> <christian.beikov at gmail.com> wrote:
>> I can't get SAML to work. Everytime I try to access a protected page, I
>> get the error "Client is not allowed to initiate browser login with
>> given response_type. Standard flow is disabled for the client".
>>
>> In the logs I see "type=LOGIN_ERROR, realmId=LOCAL, clientId=null,
>> userId=null, ipAddress=10.0.0.1, error=not_allowed"
>>
>> Is there anything I can do to further debug this? I'm using 3.3.0.Final
>> and configured SAML via keycloak-saml.xml having roughly the following
>> content
>>
>> <?xml version="1.0" encoding="UTF-8"?>
>> <keycloak-saml-adapter xmlns="urn:keycloak:saml:adapter"
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>> xsi:schemaLocation="urn:keycloak:saml:adapter
>> http://www.keycloak.org/schema/keycloak_saml_adapter_1_7.xsd">
>>      <SP entityID="myapp"
>>          sslPolicy="EXTERNAL"
>> nameIDPolicyFormat="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"
>>          logoutPage="/logout"
>>          forceAuthentication="false"
>>          isPassive="false"
>>          turnOffChangeSessionIdOnLogin="false">
>>          <IDP entityID="idp"
>>               signaturesRequired="false">
>>              <SingleSignOnService requestBinding="POST"
>> bindingUrl="http://auth.company.com:8081/auth/realms/LOCAL/protocol/saml"
>>              />
>>
>>              <SingleLogoutService
>>                      requestBinding="POST"
>>                      responseBinding="POST"
>> postBindingUrl="http://auth.company.com:8081/auth/realms/LOCAL/protocol/saml"
>> redirectBindingUrl="http://auth.company.com:8081/auth/realms/LOCAL/protocol/saml"
>>              />
>>          </IDP>
>>      </SP>
>> </keycloak-saml-adapter>
>>
>> Am I missing something or is having a SAML endpoint on Keycloak along
>> with a SAML client not a supported scenario configuration?
>>
>> Mit freundlichen Gr??en,
>> ------------------------------------------------------------------------
>> *Christian Beikov*
>> Am 26.04.2018 um 16:50 schrieb Bill Burke:
>>> SAML would definitely work for your case so long as you don't need a
>>> token to make other REST invocations.
>>>
>>> On Thu, Apr 26, 2018 at 9:59 AM, Christian Beikov
>>> <christian.beikov at gmail.com> wrote:
>>>> Thanks for the hints. I'll try to see if I can get SAML to work and let
>>>> you know of the result. Anyway, the POST response_mode sounds promising
>>>> and would definitely work in our case. When I put the URL hash I got
>>>> while testing into the query part of the URL, the authentication worked
>>>> properly. So doing a form encoded POST would probably work as well.
>>>>
>>>>
>>>> Mit freundlichen Gr??en,
>>>> ------------------------------------------------------------------------
>>>> *Christian Beikov*
>>>> Am 26.04.2018 um 15:06 schrieb Marek Posolda:
>>>>> I think it works, but didn't tested that combination. And POST is not
>>>>> supported by any of our adapters ATM, just by server. I know that some
>>>>> of our users use Form POST with 3rd party adapters, but likely the
>>>>> combination of FormPOST with standard flow.
>>>>>
>>>>> On 26/04/18 14:38, Bill Burke wrote:
>>>>>> Cool, so POST mode works with Implicit?
>>>>>>
>>>>>> On Thu, Apr 26, 2018 at 4:16 AM, Marek Posolda <mposolda at redhat.com>
>>>>>> wrote:
>>>>>>> We support response_mode parameter and we also support HTML POST mode
>>>>>>> already on server side. But we specifically disallow "query"
>>>>>>> response_mode
>>>>>>> with implicit flow [1] . This is required per specification and OIDC
>>>>>>> certification had a test exactly for this AFAIR.
>>>>>>>
>>>>>>> [1]
>>>>>>> https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/protocol/oidc/endpoints/AuthorizationEndpoint.java#L227
>>>>>>>
>>>>>>>
>>>>>>> Marek
>>>>>>>
>>>>>>>
>>>>>>> On 25/04/18 23:20, Bill Burke wrote:
>>>>>>>> We should probably support response_mode parameter [1] and allow
>>>>>>>> "query" mode for implicit invocations.  IMO, the HTML POST mode [2]
>>>>>>>> (like SAML does) would be better as with implicit mode, the access
>>>>>>>> token is leaked to browser history.
>>>>>>>>
>>>>>>>> [1] https://openid.net/specs/oauth-v2-multiple-response-types-1_0.html
>>>>>>>> [2] http://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html
>>>>>>>>
>>>>>>>> On Wed, Apr 25, 2018 at 4:14 PM, Christian Beikov
>>>>>>>> <christian.beikov at gmail.com> wrote:
>>>>>>>>> Hey all,
>>>>>>>>>
>>>>>>>>> we reached a point where we are not sure how to proceed with the PR
>>>>>>>>> https://github.com/keycloak/keycloak/pull/5167 for
>>>>>>>>> https://issues.jboss.org/browse/KEYCLOAK-7195
>>>>>>>>>
>>>>>>>>> We added a client adapter configuration for the flow and that part
>>>>>>>>> works
>>>>>>>>> so far, but we noticed that when the Keycloak server encounters a
>>>>>>>>> request for authetication via the implicit flow, it puts the token
>>>>>>>>> into
>>>>>>>>> the query fragment part which isn't sent to the application. This
>>>>>>>>> is the
>>>>>>>>> point where it becomes obvious this mechanism is intended for the JS
>>>>>>>>> adapter :)
>>>>>>>>>
>>>>>>>>> To resolve the problem and make the flow usable for the Java
>>>>>>>>> adapter as
>>>>>>>>> well, we'd need some way to configure the response mode in the
>>>>>>>>> OIDCLoginProtocol. My question is, how you think this should be done.
>>>>>>>>> I was thinking of either allowing a query parameter to specify the
>>>>>>>>> response mode or a configuration switch in the UI for the client.
>>>>>>>>> I kind
>>>>>>>>> of prefer the query parameter solution.
>>>>>>>>>
>>>>>>>>> Is this even a change/feature you would be interested in? We need the
>>>>>>>>> implicit flow because the Keycloak server is in a private network
>>>>>>>>> that
>>>>>>>>> is separate from the application. Maybe there are other people out
>>>>>>>>> there
>>>>>>>>> that have similar needs?
>>>>>>>>>
>>>>>>>>> Mit freundlichen Gr??en,
>>>>>>>>> ------------------------------------------------------------------------
>>>>>>>>>
>>>>>>>>> *Christian Beikov*
>>>>>>>>> Am 20.04.2018 um 09:15 schrieb Niels Bertram:
>>>>>>>>>> Hi Christian,
>>>>>>>>>>
>>>>>>>>>> can't say for sure but the server side adapters always use standard
>>>>>>>>>> authorization flow, which requires your Java app to connect via a
>>>>>>>>>> back
>>>>>>>>>> channel to (A) exchange code grant for access tokens and (B) to
>>>>>>>>>> lookup
>>>>>>>>>> jwks for token validation.
>>>>>>>>>>
>>>>>>>>>> The OpenID Connect specification does provide a pure browser based
>>>>>>>>>> flow calledimplicit flow
>>>>>>>>>>
>>>>>>>>>> <http://openid.net/specs/openid-connect-core-1_0.html#ImplicitFlowAuth>but
>>>>>>>>>>
>>>>>>>>>> that one has a few drawbacks such as auth tokens delivered in the
>>>>>>>>>> redirect URL and no refresh token capability. Using this flow could
>>>>>>>>>> solve your problem (A) to shift login flow to the frontend but still
>>>>>>>>>> poses the challenge for (B) validating the tokens at the backend.
>>>>>>>>>>
>>>>>>>>>> I could not find a way to configure the Java adapter to work in pure
>>>>>>>>>> offline validation mode. We had a similar requirement some time ago
>>>>>>>>>> and had to code our own auth module to validate incoming tokens
>>>>>>>>>> with a
>>>>>>>>>> pre-configured public key. The other common problem we ran into is
>>>>>>>>>> wanting to validate tokens from different (including non-keycloak)
>>>>>>>>>> issuers on the same backend. The Keycloak Java adapters do not
>>>>>>>>>> support
>>>>>>>>>> this use case either. We originally looked at the Spring JWT adapter
>>>>>>>>>>
>>>>>>>>>> <https://github.com/spring-projects/spring-security-oauth/tree/master/spring-security-jwt>
>>>>>>>>>>
>>>>>>>>>> as an alternative but this project is not properly patched and
>>>>>>>>>> configuration is a wonderful garden of mystery like everything in
>>>>>>>>>> Spring.
>>>>>>>>>>
>>>>>>>>>> Very curious though to see what others are doing.
>>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>> Niels
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Thu, Apr 19, 2018 at 2:16 AM, Christian Beikov
>>>>>>>>>> <christian.beikov at gmail.com <mailto:christian.beikov at gmail.com>>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>        As far as I see in the code, the Java Adapters always use the
>>>>>>>>>>        standard
>>>>>>>>>>        flow i.e. response_type=code
>>>>>>>>>>
>>>>>>>>>>        Please tell me this observation is wrong and there is an
>>>>>>>>>> undocumented
>>>>>>>>>>        setting I just didn't see that I can use to tell the
>>>>>>>>>> adapter to
>>>>>>>>>>        use the
>>>>>>>>>>        implicit flow instead :|
>>>>>>>>>>
>>>>>>>>>>        If this is really missing, where would you suggest this
>>>>>>>>>> should be
>>>>>>>>>>        configured? I'd expect the setting to be in
>>>>>>>>>> KeycloakDeployment and
>>>>>>>>>>        OAuthRequestAuthenticator#loginRedirect would then use the
>>>>>>>>>> value
>>>>>>>>>>        instead
>>>>>>>>>>        of always using the "code" value.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>        Mit freundlichen Gr??en,
>>>>>>>>>>
>>>>>>>>>> ------------------------------------------------------------------------
>>>>>>>>>>
>>>>>>>>>>        *Christian Beikov*
>>>>>>>>>>        Am 18.04.2018 um 17:35 schrieb Christian Beikov:
>>>>>>>>>>        >
>>>>>>>>>>        > Is there any way to avoid the access code to access token
>>>>>>>>>> exchange?
>>>>>>>>>>        > Since the Keycloak server is not accessible, I'm getting
>>>>>>>>>> an error
>>>>>>>>>>        > during authentication:
>>>>>>>>>>        >
>>>>>>>>>>        >  ERROR [org.keycloak.adapters.OAuthRequestAuthenticator]
>>>>>>>>>> (default
>>>>>>>>>>        > task-54) failed to turn code into token:
>>>>>>>>>>        > java.net.UnknownHostException: blabla.local: unknown error
>>>>>>>>>>        >         ...
>>>>>>>>>>        >         at
>>>>>>>>>>        >
>>>>>>>>>>
>>>>>>>>>> org.keycloak.adapters.ServerRequest.invokeAccessCodeToToken(ServerRequest.java:111)
>>>>>>>>>>
>>>>>>>>>>        >         at
>>>>>>>>>>        >
>>>>>>>>>>
>>>>>>>>>> org.keycloak.adapters.OAuthRequestAuthenticator.resolveCode(OAuthRequestAuthenticator.java:330)
>>>>>>>>>>
>>>>>>>>>>        >         at
>>>>>>>>>>        >
>>>>>>>>>>
>>>>>>>>>> org.keycloak.adapters.OAuthRequestAuthenticator.authenticate(OAuthRequestAuthenticator.java:275)
>>>>>>>>>>
>>>>>>>>>>        >         at
>>>>>>>>>>        >
>>>>>>>>>>
>>>>>>>>>> org.keycloak.adapters.RequestAuthenticator.authenticate(RequestAuthenticator.java:139)
>>>>>>>>>>
>>>>>>>>>>        >         at
>>>>>>>>>>        >
>>>>>>>>>>
>>>>>>>>>> org.keycloak.adapters.undertow.AbstractUndertowKeycloakAuthMech.keycloakAuthenticate(AbstractUndertowKeycloakAuthMech.java:110)
>>>>>>>>>>
>>>>>>>>>>        >         at
>>>>>>>>>>        >
>>>>>>>>>>
>>>>>>>>>> org.keycloak.adapters.undertow.ServletKeycloakAuthMech.authenticate(ServletKeycloakAuthMech.java:92)
>>>>>>>>>>
>>>>>>>>>>        >         ...
>>>>>>>>>>        >
>>>>>>>>>>        >
>>>>>>>>>>        > Mit freundlichen Gr??en,
>>>>>>>>>>        >
>>>>>>>>>>
>>>>>>>>>> ------------------------------------------------------------------------
>>>>>>>>>>
>>>>>>>>>>        > *Christian Beikov*
>>>>>>>>>>        > Am 18.04.2018 um 14:48 schrieb Thomas Darimont:
>>>>>>>>>>        >> Hello Christian,
>>>>>>>>>>        >>
>>>>>>>>>>        >> your application server needs to communicate with the
>>>>>>>>>> Keycloak
>>>>>>>>>>        server
>>>>>>>>>>        >> to retrieve the realm public key referenced in the token to
>>>>>>>>>> verify
>>>>>>>>>>        >> the token signature.
>>>>>>>>>>        >> The current implementation in Keycloak fetches & caches
>>>>>>>>>> unknown
>>>>>>>>>>        >> public keys automatically.
>>>>>>>>>>        >>
>>>>>>>>>>        >> You could also use a fixed realm public key on the
>>>>>>>>>> application
>>>>>>>>>>        server
>>>>>>>>>>        >> side but it would not support key rotation anymore.
>>>>>>>>>>        >>
>>>>>>>>>>        >> Cheers,
>>>>>>>>>>        >> Thomas
>>>>>>>>>>        >>
>>>>>>>>>>        >> 2018-04-18 13:45 GMT+02:00 Christian Beikov
>>>>>>>>>>        >> <christian.beikov at gmail.com
>>>>>>>>>> <mailto:christian.beikov at gmail.com>
>>>>>>>>>>        <mailto:christian.beikov at gmail.com
>>>>>>>>>>        <mailto:christian.beikov at gmail.com>>>:
>>>>>>>>>>        >>
>>>>>>>>>>        >>     Hi,
>>>>>>>>>>        >>
>>>>>>>>>>        >>     is it necessary that an application secured by
>>>>>>>>>> Keycloak can
>>>>>>>>>>        >>     access the
>>>>>>>>>>        >>     Keycloak server? Or is it enough if the Browser can
>>>>>>>>>> access
>>>>>>>>>> the
>>>>>>>>>>        >>     Keycloak
>>>>>>>>>>        >>     server?
>>>>>>>>>>        >>
>>>>>>>>>>        >>     --
>>>>>>>>>>        >>
>>>>>>>>>>        >>     Mit freundlichen Gr??en,
>>>>>>>>>>        >>
>>>>>>>>>>
>>>>>>>>>> ------------------------------------------------------------------------
>>>>>>>>>>
>>>>>>>>>>        >>     *Christian Beikov*
>>>>>>>>>>        >> _______________________________________________
>>>>>>>>>>        >>     keycloak-dev mailing list
>>>>>>>>>>        >> keycloak-dev at lists.jboss.org
>>>>>>>>>>        <mailto:keycloak-dev at lists.jboss.org>
>>>>>>>>>>        <mailto:keycloak-dev at lists.jboss.org
>>>>>>>>>>        <mailto:keycloak-dev at lists.jboss.org>>
>>>>>>>>>>        >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>>>> <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>>>>>>>>>        >> <https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>>>> <https://lists.jboss.org/mailman/listinfo/keycloak-dev>>
>>>>>>>>>>        >>
>>>>>>>>>>        >>
>>>>>>>>>>        >
>>>>>>>>>>
>>>>>>>>>>        _______________________________________________
>>>>>>>>>>        keycloak-dev mailing list
>>>>>>>>>>        keycloak-dev at lists.jboss.org
>>>>>>>>>> <mailto:keycloak-dev at lists.jboss.org>
>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>>>> <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> keycloak-dev mailing list
>>>>>>>>> keycloak-dev at lists.jboss.org
>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>>
>>>>>>
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
> --
> Bill Burke
> Red Hat



-- 
Bill Burke
Red Hat


From christian.beikov at gmail.com  Sat Apr 28 12:40:53 2018
From: christian.beikov at gmail.com (Christian Beikov)
Date: Sat, 28 Apr 2018 18:40:53 +0200
Subject: [keycloak-dev] Application and server in separate networks
In-Reply-To: <CABRXCmwvjmYuLXJg4hXR8HZs=YX_U9pza5sGcLXd0_hQ-03cDg@mail.gmail.com>
References: <41e1a805-cc38-50cf-f794-cda6afd49313@gmail.com>
	<CAK-7U1gGFnwc3EcgL3whgdGbSTH9xSVwVSHxc1i+JtetJ83H4g@mail.gmail.com>
	<24a0f868-9726-4024-6254-9a0b68b29c9f@gmail.com>
	<569a7f4e-2fa6-6590-2dfb-d7a57c137db2@gmail.com>
	<CAPLPygm2BHoNkrrYMWaOUHx1gGT-PbvSccTNf7JuuLjGeATrLg@mail.gmail.com>
	<d52de7b0-0041-46e2-f5ed-479fb0264528@gmail.com>
	<CABRXCmzfPqd-7rrMzox9UUAXkJZFngU=F6nUfh3ReNcA2P-6qg@mail.gmail.com>
	<e01068f2-8cd5-e855-86e3-1645ed36b118@redhat.com>
	<CABRXCmxdn_jnTPzRtLx6Rz80OUJUgMRRBvSg9jFDkyqP5zDyxg@mail.gmail.com>
	<1a844bee-aaf8-8c23-3e2d-c5bbefffa48e@redhat.com>
	<95470200-8cff-362d-5f0a-c345eed70b3c@gmail.com>
	<CABRXCmw_DpdufKjVAZJ-=dNDLxnG=rQEw=ExKD7nwWuyQ7qhgQ@mail.gmail.com>
	<7f7e0950-7d2d-7794-830f-f5edd2ec0ec0@gmail.com>
	<CABRXCmyzLO8r=c3Wfq=zg=Vo=ngZCHpp+zAV3Ut1MyY=1Zj2zA@mail.gmail.com>
	<CABRXCmwvjmYuLXJg4hXR8HZs=YX_U9pza5sGcLXd0_hQ-03cDg@mail.gmail.com>
Message-ID: <9686afb6-4783-ff82-5c5d-b68618c7073b@gmail.com>

Thanks for the fast answer. There is no configuration for a flow in the 
administration for the client. The client id matches the entityID 
attribute. I actually used the generated configuration. Here is the list 
of configurable attributes for the client

  * Client ID
  * Name
  * Description
  * Enabled
  * Consent Required
  * Client Protocol
  * Client Template
  * Include AuthnStatement
  * Include OneTimeUse Condition
  * Sign Documents
  * Sign Assertions
  * Encrypt Assertions
  * Client Signature Required
  * Force POST Binding
  * Front Channel Logout
  * Force Name ID Format
  * Name ID Format
  * Root URL
  * Valid Redirect URIs
  * Base URL
  * Master SAML Processing URL
  * IDP Initiated SSO URL Name
  * IDP Initiated SSO Relay State
  * Assertion Consumer Service POST Binding URL
  * Assertion Consumer Service Redirect Binding URL
  * Logout Service POST Binding URL
  * Logout Service Redirect Binding URL


Mit freundlichen Gr??en,
------------------------------------------------------------------------
*Christian Beikov*
Am 28.04.2018 um 18:33 schrieb Bill Burke:
> Also make sure that your client id matches the one configured for the
> client in the admin console.  That might be the problem too.
>
> On Sat, Apr 28, 2018 at 12:32 PM, Bill Burke <bburke at redhat.com> wrote:
>> Enable standard flow for the client.  Its a switch in admin console
>> client config.
>>
>> On Sat, Apr 28, 2018 at 11:11 AM, Christian Beikov
>> <christian.beikov at gmail.com> wrote:
>>> I can't get SAML to work. Everytime I try to access a protected page, I
>>> get the error "Client is not allowed to initiate browser login with
>>> given response_type. Standard flow is disabled for the client".
>>>
>>> In the logs I see "type=LOGIN_ERROR, realmId=LOCAL, clientId=null,
>>> userId=null, ipAddress=10.0.0.1, error=not_allowed"
>>>
>>> Is there anything I can do to further debug this? I'm using 3.3.0.Final
>>> and configured SAML via keycloak-saml.xml having roughly the following
>>> content
>>>
>>> <?xml version="1.0" encoding="UTF-8"?>
>>> <keycloak-saml-adapter xmlns="urn:keycloak:saml:adapter"
>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>> xsi:schemaLocation="urn:keycloak:saml:adapter
>>> http://www.keycloak.org/schema/keycloak_saml_adapter_1_7.xsd">
>>>       <SP entityID="myapp"
>>>           sslPolicy="EXTERNAL"
>>> nameIDPolicyFormat="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"
>>>           logoutPage="/logout"
>>>           forceAuthentication="false"
>>>           isPassive="false"
>>>           turnOffChangeSessionIdOnLogin="false">
>>>           <IDP entityID="idp"
>>>                signaturesRequired="false">
>>>               <SingleSignOnService requestBinding="POST"
>>> bindingUrl="http://auth.company.com:8081/auth/realms/LOCAL/protocol/saml"
>>>               />
>>>
>>>               <SingleLogoutService
>>>                       requestBinding="POST"
>>>                       responseBinding="POST"
>>> postBindingUrl="http://auth.company.com:8081/auth/realms/LOCAL/protocol/saml"
>>> redirectBindingUrl="http://auth.company.com:8081/auth/realms/LOCAL/protocol/saml"
>>>               />
>>>           </IDP>
>>>       </SP>
>>> </keycloak-saml-adapter>
>>>
>>> Am I missing something or is having a SAML endpoint on Keycloak along
>>> with a SAML client not a supported scenario configuration?
>>>
>>> Mit freundlichen Gr??en,
>>> ------------------------------------------------------------------------
>>> *Christian Beikov*
>>> Am 26.04.2018 um 16:50 schrieb Bill Burke:
>>>> SAML would definitely work for your case so long as you don't need a
>>>> token to make other REST invocations.
>>>>
>>>> On Thu, Apr 26, 2018 at 9:59 AM, Christian Beikov
>>>> <christian.beikov at gmail.com> wrote:
>>>>> Thanks for the hints. I'll try to see if I can get SAML to work and let
>>>>> you know of the result. Anyway, the POST response_mode sounds promising
>>>>> and would definitely work in our case. When I put the URL hash I got
>>>>> while testing into the query part of the URL, the authentication worked
>>>>> properly. So doing a form encoded POST would probably work as well.
>>>>>
>>>>>
>>>>> Mit freundlichen Gr??en,
>>>>> ------------------------------------------------------------------------
>>>>> *Christian Beikov*
>>>>> Am 26.04.2018 um 15:06 schrieb Marek Posolda:
>>>>>> I think it works, but didn't tested that combination. And POST is not
>>>>>> supported by any of our adapters ATM, just by server. I know that some
>>>>>> of our users use Form POST with 3rd party adapters, but likely the
>>>>>> combination of FormPOST with standard flow.
>>>>>>
>>>>>> On 26/04/18 14:38, Bill Burke wrote:
>>>>>>> Cool, so POST mode works with Implicit?
>>>>>>>
>>>>>>> On Thu, Apr 26, 2018 at 4:16 AM, Marek Posolda <mposolda at redhat.com>
>>>>>>> wrote:
>>>>>>>> We support response_mode parameter and we also support HTML POST mode
>>>>>>>> already on server side. But we specifically disallow "query"
>>>>>>>> response_mode
>>>>>>>> with implicit flow [1] . This is required per specification and OIDC
>>>>>>>> certification had a test exactly for this AFAIR.
>>>>>>>>
>>>>>>>> [1]
>>>>>>>> https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/protocol/oidc/endpoints/AuthorizationEndpoint.java#L227
>>>>>>>>
>>>>>>>>
>>>>>>>> Marek
>>>>>>>>
>>>>>>>>
>>>>>>>> On 25/04/18 23:20, Bill Burke wrote:
>>>>>>>>> We should probably support response_mode parameter [1] and allow
>>>>>>>>> "query" mode for implicit invocations.  IMO, the HTML POST mode [2]
>>>>>>>>> (like SAML does) would be better as with implicit mode, the access
>>>>>>>>> token is leaked to browser history.
>>>>>>>>>
>>>>>>>>> [1] https://openid.net/specs/oauth-v2-multiple-response-types-1_0.html
>>>>>>>>> [2] http://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html
>>>>>>>>>
>>>>>>>>> On Wed, Apr 25, 2018 at 4:14 PM, Christian Beikov
>>>>>>>>> <christian.beikov at gmail.com> wrote:
>>>>>>>>>> Hey all,
>>>>>>>>>>
>>>>>>>>>> we reached a point where we are not sure how to proceed with the PR
>>>>>>>>>> https://github.com/keycloak/keycloak/pull/5167 for
>>>>>>>>>> https://issues.jboss.org/browse/KEYCLOAK-7195
>>>>>>>>>>
>>>>>>>>>> We added a client adapter configuration for the flow and that part
>>>>>>>>>> works
>>>>>>>>>> so far, but we noticed that when the Keycloak server encounters a
>>>>>>>>>> request for authetication via the implicit flow, it puts the token
>>>>>>>>>> into
>>>>>>>>>> the query fragment part which isn't sent to the application. This
>>>>>>>>>> is the
>>>>>>>>>> point where it becomes obvious this mechanism is intended for the JS
>>>>>>>>>> adapter :)
>>>>>>>>>>
>>>>>>>>>> To resolve the problem and make the flow usable for the Java
>>>>>>>>>> adapter as
>>>>>>>>>> well, we'd need some way to configure the response mode in the
>>>>>>>>>> OIDCLoginProtocol. My question is, how you think this should be done.
>>>>>>>>>> I was thinking of either allowing a query parameter to specify the
>>>>>>>>>> response mode or a configuration switch in the UI for the client.
>>>>>>>>>> I kind
>>>>>>>>>> of prefer the query parameter solution.
>>>>>>>>>>
>>>>>>>>>> Is this even a change/feature you would be interested in? We need the
>>>>>>>>>> implicit flow because the Keycloak server is in a private network
>>>>>>>>>> that
>>>>>>>>>> is separate from the application. Maybe there are other people out
>>>>>>>>>> there
>>>>>>>>>> that have similar needs?
>>>>>>>>>>
>>>>>>>>>> Mit freundlichen Gr??en,
>>>>>>>>>> ------------------------------------------------------------------------
>>>>>>>>>>
>>>>>>>>>> *Christian Beikov*
>>>>>>>>>> Am 20.04.2018 um 09:15 schrieb Niels Bertram:
>>>>>>>>>>> Hi Christian,
>>>>>>>>>>>
>>>>>>>>>>> can't say for sure but the server side adapters always use standard
>>>>>>>>>>> authorization flow, which requires your Java app to connect via a
>>>>>>>>>>> back
>>>>>>>>>>> channel to (A) exchange code grant for access tokens and (B) to
>>>>>>>>>>> lookup
>>>>>>>>>>> jwks for token validation.
>>>>>>>>>>>
>>>>>>>>>>> The OpenID Connect specification does provide a pure browser based
>>>>>>>>>>> flow calledimplicit flow
>>>>>>>>>>>
>>>>>>>>>>> <http://openid.net/specs/openid-connect-core-1_0.html#ImplicitFlowAuth>but
>>>>>>>>>>>
>>>>>>>>>>> that one has a few drawbacks such as auth tokens delivered in the
>>>>>>>>>>> redirect URL and no refresh token capability. Using this flow could
>>>>>>>>>>> solve your problem (A) to shift login flow to the frontend but still
>>>>>>>>>>> poses the challenge for (B) validating the tokens at the backend.
>>>>>>>>>>>
>>>>>>>>>>> I could not find a way to configure the Java adapter to work in pure
>>>>>>>>>>> offline validation mode. We had a similar requirement some time ago
>>>>>>>>>>> and had to code our own auth module to validate incoming tokens
>>>>>>>>>>> with a
>>>>>>>>>>> pre-configured public key. The other common problem we ran into is
>>>>>>>>>>> wanting to validate tokens from different (including non-keycloak)
>>>>>>>>>>> issuers on the same backend. The Keycloak Java adapters do not
>>>>>>>>>>> support
>>>>>>>>>>> this use case either. We originally looked at the Spring JWT adapter
>>>>>>>>>>>
>>>>>>>>>>> <https://github.com/spring-projects/spring-security-oauth/tree/master/spring-security-jwt>
>>>>>>>>>>>
>>>>>>>>>>> as an alternative but this project is not properly patched and
>>>>>>>>>>> configuration is a wonderful garden of mystery like everything in
>>>>>>>>>>> Spring.
>>>>>>>>>>>
>>>>>>>>>>> Very curious though to see what others are doing.
>>>>>>>>>>>
>>>>>>>>>>> Cheers,
>>>>>>>>>>> Niels
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Thu, Apr 19, 2018 at 2:16 AM, Christian Beikov
>>>>>>>>>>> <christian.beikov at gmail.com <mailto:christian.beikov at gmail.com>>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>         As far as I see in the code, the Java Adapters always use the
>>>>>>>>>>>         standard
>>>>>>>>>>>         flow i.e. response_type=code
>>>>>>>>>>>
>>>>>>>>>>>         Please tell me this observation is wrong and there is an
>>>>>>>>>>> undocumented
>>>>>>>>>>>         setting I just didn't see that I can use to tell the
>>>>>>>>>>> adapter to
>>>>>>>>>>>         use the
>>>>>>>>>>>         implicit flow instead :|
>>>>>>>>>>>
>>>>>>>>>>>         If this is really missing, where would you suggest this
>>>>>>>>>>> should be
>>>>>>>>>>>         configured? I'd expect the setting to be in
>>>>>>>>>>> KeycloakDeployment and
>>>>>>>>>>>         OAuthRequestAuthenticator#loginRedirect would then use the
>>>>>>>>>>> value
>>>>>>>>>>>         instead
>>>>>>>>>>>         of always using the "code" value.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>         Mit freundlichen Gr??en,
>>>>>>>>>>>
>>>>>>>>>>> ------------------------------------------------------------------------
>>>>>>>>>>>
>>>>>>>>>>>         *Christian Beikov*
>>>>>>>>>>>         Am 18.04.2018 um 17:35 schrieb Christian Beikov:
>>>>>>>>>>>         >
>>>>>>>>>>>         > Is there any way to avoid the access code to access token
>>>>>>>>>>> exchange?
>>>>>>>>>>>         > Since the Keycloak server is not accessible, I'm getting
>>>>>>>>>>> an error
>>>>>>>>>>>         > during authentication:
>>>>>>>>>>>         >
>>>>>>>>>>>         >  ERROR [org.keycloak.adapters.OAuthRequestAuthenticator]
>>>>>>>>>>> (default
>>>>>>>>>>>         > task-54) failed to turn code into token:
>>>>>>>>>>>         > java.net.UnknownHostException: blabla.local: unknown error
>>>>>>>>>>>         >         ...
>>>>>>>>>>>         >         at
>>>>>>>>>>>         >
>>>>>>>>>>>
>>>>>>>>>>> org.keycloak.adapters.ServerRequest.invokeAccessCodeToToken(ServerRequest.java:111)
>>>>>>>>>>>
>>>>>>>>>>>         >         at
>>>>>>>>>>>         >
>>>>>>>>>>>
>>>>>>>>>>> org.keycloak.adapters.OAuthRequestAuthenticator.resolveCode(OAuthRequestAuthenticator.java:330)
>>>>>>>>>>>
>>>>>>>>>>>         >         at
>>>>>>>>>>>         >
>>>>>>>>>>>
>>>>>>>>>>> org.keycloak.adapters.OAuthRequestAuthenticator.authenticate(OAuthRequestAuthenticator.java:275)
>>>>>>>>>>>
>>>>>>>>>>>         >         at
>>>>>>>>>>>         >
>>>>>>>>>>>
>>>>>>>>>>> org.keycloak.adapters.RequestAuthenticator.authenticate(RequestAuthenticator.java:139)
>>>>>>>>>>>
>>>>>>>>>>>         >         at
>>>>>>>>>>>         >
>>>>>>>>>>>
>>>>>>>>>>> org.keycloak.adapters.undertow.AbstractUndertowKeycloakAuthMech.keycloakAuthenticate(AbstractUndertowKeycloakAuthMech.java:110)
>>>>>>>>>>>
>>>>>>>>>>>         >         at
>>>>>>>>>>>         >
>>>>>>>>>>>
>>>>>>>>>>> org.keycloak.adapters.undertow.ServletKeycloakAuthMech.authenticate(ServletKeycloakAuthMech.java:92)
>>>>>>>>>>>
>>>>>>>>>>>         >         ...
>>>>>>>>>>>         >
>>>>>>>>>>>         >
>>>>>>>>>>>         > Mit freundlichen Gr??en,
>>>>>>>>>>>         >
>>>>>>>>>>>
>>>>>>>>>>> ------------------------------------------------------------------------
>>>>>>>>>>>
>>>>>>>>>>>         > *Christian Beikov*
>>>>>>>>>>>         > Am 18.04.2018 um 14:48 schrieb Thomas Darimont:
>>>>>>>>>>>         >> Hello Christian,
>>>>>>>>>>>         >>
>>>>>>>>>>>         >> your application server needs to communicate with the
>>>>>>>>>>> Keycloak
>>>>>>>>>>>         server
>>>>>>>>>>>         >> to retrieve the realm public key referenced in the token to
>>>>>>>>>>> verify
>>>>>>>>>>>         >> the token signature.
>>>>>>>>>>>         >> The current implementation in Keycloak fetches & caches
>>>>>>>>>>> unknown
>>>>>>>>>>>         >> public keys automatically.
>>>>>>>>>>>         >>
>>>>>>>>>>>         >> You could also use a fixed realm public key on the
>>>>>>>>>>> application
>>>>>>>>>>>         server
>>>>>>>>>>>         >> side but it would not support key rotation anymore.
>>>>>>>>>>>         >>
>>>>>>>>>>>         >> Cheers,
>>>>>>>>>>>         >> Thomas
>>>>>>>>>>>         >>
>>>>>>>>>>>         >> 2018-04-18 13:45 GMT+02:00 Christian Beikov
>>>>>>>>>>>         >> <christian.beikov at gmail.com
>>>>>>>>>>> <mailto:christian.beikov at gmail.com>
>>>>>>>>>>>         <mailto:christian.beikov at gmail.com
>>>>>>>>>>>         <mailto:christian.beikov at gmail.com>>>:
>>>>>>>>>>>         >>
>>>>>>>>>>>         >>     Hi,
>>>>>>>>>>>         >>
>>>>>>>>>>>         >>     is it necessary that an application secured by
>>>>>>>>>>> Keycloak can
>>>>>>>>>>>         >>     access the
>>>>>>>>>>>         >>     Keycloak server? Or is it enough if the Browser can
>>>>>>>>>>> access
>>>>>>>>>>> the
>>>>>>>>>>>         >>     Keycloak
>>>>>>>>>>>         >>     server?
>>>>>>>>>>>         >>
>>>>>>>>>>>         >>     --
>>>>>>>>>>>         >>
>>>>>>>>>>>         >>     Mit freundlichen Gr??en,
>>>>>>>>>>>         >>
>>>>>>>>>>>
>>>>>>>>>>> ------------------------------------------------------------------------
>>>>>>>>>>>
>>>>>>>>>>>         >>     *Christian Beikov*
>>>>>>>>>>>         >> _______________________________________________
>>>>>>>>>>>         >>     keycloak-dev mailing list
>>>>>>>>>>>         >> keycloak-dev at lists.jboss.org
>>>>>>>>>>>         <mailto:keycloak-dev at lists.jboss.org>
>>>>>>>>>>>         <mailto:keycloak-dev at lists.jboss.org
>>>>>>>>>>>         <mailto:keycloak-dev at lists.jboss.org>>
>>>>>>>>>>>         >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>>>>> <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>>>>>>>>>>         >> <https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>>>>> <https://lists.jboss.org/mailman/listinfo/keycloak-dev>>
>>>>>>>>>>>         >>
>>>>>>>>>>>         >>
>>>>>>>>>>>         >
>>>>>>>>>>>
>>>>>>>>>>>         _______________________________________________
>>>>>>>>>>>         keycloak-dev mailing list
>>>>>>>>>>>         keycloak-dev at lists.jboss.org
>>>>>>>>>>> <mailto:keycloak-dev at lists.jboss.org>
>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>>>>> <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> keycloak-dev mailing list
>>>>>>>>>> keycloak-dev at lists.jboss.org
>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>> _______________________________________________
>>>>> keycloak-dev mailing list
>>>>> keycloak-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>> --
>> Bill Burke
>> Red Hat
>
>


From christian.beikov at gmail.com  Sat Apr 28 13:16:40 2018
From: christian.beikov at gmail.com (Christian Beikov)
Date: Sat, 28 Apr 2018 19:16:40 +0200
Subject: [keycloak-dev] Application and server in separate networks
In-Reply-To: <CABRXCmwvjmYuLXJg4hXR8HZs=YX_U9pza5sGcLXd0_hQ-03cDg@mail.gmail.com>
References: <41e1a805-cc38-50cf-f794-cda6afd49313@gmail.com>
	<CAK-7U1gGFnwc3EcgL3whgdGbSTH9xSVwVSHxc1i+JtetJ83H4g@mail.gmail.com>
	<24a0f868-9726-4024-6254-9a0b68b29c9f@gmail.com>
	<569a7f4e-2fa6-6590-2dfb-d7a57c137db2@gmail.com>
	<CAPLPygm2BHoNkrrYMWaOUHx1gGT-PbvSccTNf7JuuLjGeATrLg@mail.gmail.com>
	<d52de7b0-0041-46e2-f5ed-479fb0264528@gmail.com>
	<CABRXCmzfPqd-7rrMzox9UUAXkJZFngU=F6nUfh3ReNcA2P-6qg@mail.gmail.com>
	<e01068f2-8cd5-e855-86e3-1645ed36b118@redhat.com>
	<CABRXCmxdn_jnTPzRtLx6Rz80OUJUgMRRBvSg9jFDkyqP5zDyxg@mail.gmail.com>
	<1a844bee-aaf8-8c23-3e2d-c5bbefffa48e@redhat.com>
	<95470200-8cff-362d-5f0a-c345eed70b3c@gmail.com>
	<CABRXCmw_DpdufKjVAZJ-=dNDLxnG=rQEw=ExKD7nwWuyQ7qhgQ@mail.gmail.com>
	<7f7e0950-7d2d-7794-830f-f5edd2ec0ec0@gmail.com>
	<CABRXCmyzLO8r=c3Wfq=zg=Vo=ngZCHpp+zAV3Ut1MyY=1Zj2zA@mail.gmail.com>
	<CABRXCmwvjmYuLXJg4hXR8HZs=YX_U9pza5sGcLXd0_hQ-03cDg@mail.gmail.com>
Message-ID: <0b9d0fbb-a374-0c06-506c-f736701ba67c@gmail.com>

It seems that switching a client from OIDC to SAML is buggy as I just 
tried to create a new client and now I get a different error I don't 
understand.

I have configured "http://localhost:8080/*" as valid redirect URL but 
get the error "invalid_redirect_uri". I inspected the Base64 encoded 
SAML request and noticed that it doesn't contain a redirect URL. The 
only URL the Keycloak server could redirect me to is the Referrer which 
would match the pattern, but I guess I am simply missing some 
configuration in the keycloak-saml.xml?


Mit freundlichen Gr??en,
------------------------------------------------------------------------
*Christian Beikov*
Am 28.04.2018 um 18:33 schrieb Bill Burke:
> Also make sure that your client id matches the one configured for the
> client in the admin console.  That might be the problem too.
>
> On Sat, Apr 28, 2018 at 12:32 PM, Bill Burke <bburke at redhat.com> wrote:
>> Enable standard flow for the client.  Its a switch in admin console
>> client config.
>>
>> On Sat, Apr 28, 2018 at 11:11 AM, Christian Beikov
>> <christian.beikov at gmail.com> wrote:
>>> I can't get SAML to work. Everytime I try to access a protected page, I
>>> get the error "Client is not allowed to initiate browser login with
>>> given response_type. Standard flow is disabled for the client".
>>>
>>> In the logs I see "type=LOGIN_ERROR, realmId=LOCAL, clientId=null,
>>> userId=null, ipAddress=10.0.0.1, error=not_allowed"
>>>
>>> Is there anything I can do to further debug this? I'm using 3.3.0.Final
>>> and configured SAML via keycloak-saml.xml having roughly the following
>>> content
>>>
>>> <?xml version="1.0" encoding="UTF-8"?>
>>> <keycloak-saml-adapter xmlns="urn:keycloak:saml:adapter"
>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>> xsi:schemaLocation="urn:keycloak:saml:adapter
>>> http://www.keycloak.org/schema/keycloak_saml_adapter_1_7.xsd">
>>>       <SP entityID="myapp"
>>>           sslPolicy="EXTERNAL"
>>> nameIDPolicyFormat="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"
>>>           logoutPage="/logout"
>>>           forceAuthentication="false"
>>>           isPassive="false"
>>>           turnOffChangeSessionIdOnLogin="false">
>>>           <IDP entityID="idp"
>>>                signaturesRequired="false">
>>>               <SingleSignOnService requestBinding="POST"
>>> bindingUrl="http://auth.company.com:8081/auth/realms/LOCAL/protocol/saml"
>>>               />
>>>
>>>               <SingleLogoutService
>>>                       requestBinding="POST"
>>>                       responseBinding="POST"
>>> postBindingUrl="http://auth.company.com:8081/auth/realms/LOCAL/protocol/saml"
>>> redirectBindingUrl="http://auth.company.com:8081/auth/realms/LOCAL/protocol/saml"
>>>               />
>>>           </IDP>
>>>       </SP>
>>> </keycloak-saml-adapter>
>>>
>>> Am I missing something or is having a SAML endpoint on Keycloak along
>>> with a SAML client not a supported scenario configuration?
>>>
>>> Mit freundlichen Gr??en,
>>> ------------------------------------------------------------------------
>>> *Christian Beikov*
>>> Am 26.04.2018 um 16:50 schrieb Bill Burke:
>>>> SAML would definitely work for your case so long as you don't need a
>>>> token to make other REST invocations.
>>>>
>>>> On Thu, Apr 26, 2018 at 9:59 AM, Christian Beikov
>>>> <christian.beikov at gmail.com> wrote:
>>>>> Thanks for the hints. I'll try to see if I can get SAML to work and let
>>>>> you know of the result. Anyway, the POST response_mode sounds promising
>>>>> and would definitely work in our case. When I put the URL hash I got
>>>>> while testing into the query part of the URL, the authentication worked
>>>>> properly. So doing a form encoded POST would probably work as well.
>>>>>
>>>>>
>>>>> Mit freundlichen Gr??en,
>>>>> ------------------------------------------------------------------------
>>>>> *Christian Beikov*
>>>>> Am 26.04.2018 um 15:06 schrieb Marek Posolda:
>>>>>> I think it works, but didn't tested that combination. And POST is not
>>>>>> supported by any of our adapters ATM, just by server. I know that some
>>>>>> of our users use Form POST with 3rd party adapters, but likely the
>>>>>> combination of FormPOST with standard flow.
>>>>>>
>>>>>> On 26/04/18 14:38, Bill Burke wrote:
>>>>>>> Cool, so POST mode works with Implicit?
>>>>>>>
>>>>>>> On Thu, Apr 26, 2018 at 4:16 AM, Marek Posolda <mposolda at redhat.com>
>>>>>>> wrote:
>>>>>>>> We support response_mode parameter and we also support HTML POST mode
>>>>>>>> already on server side. But we specifically disallow "query"
>>>>>>>> response_mode
>>>>>>>> with implicit flow [1] . This is required per specification and OIDC
>>>>>>>> certification had a test exactly for this AFAIR.
>>>>>>>>
>>>>>>>> [1]
>>>>>>>> https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/protocol/oidc/endpoints/AuthorizationEndpoint.java#L227
>>>>>>>>
>>>>>>>>
>>>>>>>> Marek
>>>>>>>>
>>>>>>>>
>>>>>>>> On 25/04/18 23:20, Bill Burke wrote:
>>>>>>>>> We should probably support response_mode parameter [1] and allow
>>>>>>>>> "query" mode for implicit invocations.  IMO, the HTML POST mode [2]
>>>>>>>>> (like SAML does) would be better as with implicit mode, the access
>>>>>>>>> token is leaked to browser history.
>>>>>>>>>
>>>>>>>>> [1] https://openid.net/specs/oauth-v2-multiple-response-types-1_0.html
>>>>>>>>> [2] http://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html
>>>>>>>>>
>>>>>>>>> On Wed, Apr 25, 2018 at 4:14 PM, Christian Beikov
>>>>>>>>> <christian.beikov at gmail.com> wrote:
>>>>>>>>>> Hey all,
>>>>>>>>>>
>>>>>>>>>> we reached a point where we are not sure how to proceed with the PR
>>>>>>>>>> https://github.com/keycloak/keycloak/pull/5167 for
>>>>>>>>>> https://issues.jboss.org/browse/KEYCLOAK-7195
>>>>>>>>>>
>>>>>>>>>> We added a client adapter configuration for the flow and that part
>>>>>>>>>> works
>>>>>>>>>> so far, but we noticed that when the Keycloak server encounters a
>>>>>>>>>> request for authetication via the implicit flow, it puts the token
>>>>>>>>>> into
>>>>>>>>>> the query fragment part which isn't sent to the application. This
>>>>>>>>>> is the
>>>>>>>>>> point where it becomes obvious this mechanism is intended for the JS
>>>>>>>>>> adapter :)
>>>>>>>>>>
>>>>>>>>>> To resolve the problem and make the flow usable for the Java
>>>>>>>>>> adapter as
>>>>>>>>>> well, we'd need some way to configure the response mode in the
>>>>>>>>>> OIDCLoginProtocol. My question is, how you think this should be done.
>>>>>>>>>> I was thinking of either allowing a query parameter to specify the
>>>>>>>>>> response mode or a configuration switch in the UI for the client.
>>>>>>>>>> I kind
>>>>>>>>>> of prefer the query parameter solution.
>>>>>>>>>>
>>>>>>>>>> Is this even a change/feature you would be interested in? We need the
>>>>>>>>>> implicit flow because the Keycloak server is in a private network
>>>>>>>>>> that
>>>>>>>>>> is separate from the application. Maybe there are other people out
>>>>>>>>>> there
>>>>>>>>>> that have similar needs?
>>>>>>>>>>
>>>>>>>>>> Mit freundlichen Gr??en,
>>>>>>>>>> ------------------------------------------------------------------------
>>>>>>>>>>
>>>>>>>>>> *Christian Beikov*
>>>>>>>>>> Am 20.04.2018 um 09:15 schrieb Niels Bertram:
>>>>>>>>>>> Hi Christian,
>>>>>>>>>>>
>>>>>>>>>>> can't say for sure but the server side adapters always use standard
>>>>>>>>>>> authorization flow, which requires your Java app to connect via a
>>>>>>>>>>> back
>>>>>>>>>>> channel to (A) exchange code grant for access tokens and (B) to
>>>>>>>>>>> lookup
>>>>>>>>>>> jwks for token validation.
>>>>>>>>>>>
>>>>>>>>>>> The OpenID Connect specification does provide a pure browser based
>>>>>>>>>>> flow calledimplicit flow
>>>>>>>>>>>
>>>>>>>>>>> <http://openid.net/specs/openid-connect-core-1_0.html#ImplicitFlowAuth>but
>>>>>>>>>>>
>>>>>>>>>>> that one has a few drawbacks such as auth tokens delivered in the
>>>>>>>>>>> redirect URL and no refresh token capability. Using this flow could
>>>>>>>>>>> solve your problem (A) to shift login flow to the frontend but still
>>>>>>>>>>> poses the challenge for (B) validating the tokens at the backend.
>>>>>>>>>>>
>>>>>>>>>>> I could not find a way to configure the Java adapter to work in pure
>>>>>>>>>>> offline validation mode. We had a similar requirement some time ago
>>>>>>>>>>> and had to code our own auth module to validate incoming tokens
>>>>>>>>>>> with a
>>>>>>>>>>> pre-configured public key. The other common problem we ran into is
>>>>>>>>>>> wanting to validate tokens from different (including non-keycloak)
>>>>>>>>>>> issuers on the same backend. The Keycloak Java adapters do not
>>>>>>>>>>> support
>>>>>>>>>>> this use case either. We originally looked at the Spring JWT adapter
>>>>>>>>>>>
>>>>>>>>>>> <https://github.com/spring-projects/spring-security-oauth/tree/master/spring-security-jwt>
>>>>>>>>>>>
>>>>>>>>>>> as an alternative but this project is not properly patched and
>>>>>>>>>>> configuration is a wonderful garden of mystery like everything in
>>>>>>>>>>> Spring.
>>>>>>>>>>>
>>>>>>>>>>> Very curious though to see what others are doing.
>>>>>>>>>>>
>>>>>>>>>>> Cheers,
>>>>>>>>>>> Niels
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Thu, Apr 19, 2018 at 2:16 AM, Christian Beikov
>>>>>>>>>>> <christian.beikov at gmail.com <mailto:christian.beikov at gmail.com>>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>         As far as I see in the code, the Java Adapters always use the
>>>>>>>>>>>         standard
>>>>>>>>>>>         flow i.e. response_type=code
>>>>>>>>>>>
>>>>>>>>>>>         Please tell me this observation is wrong and there is an
>>>>>>>>>>> undocumented
>>>>>>>>>>>         setting I just didn't see that I can use to tell the
>>>>>>>>>>> adapter to
>>>>>>>>>>>         use the
>>>>>>>>>>>         implicit flow instead :|
>>>>>>>>>>>
>>>>>>>>>>>         If this is really missing, where would you suggest this
>>>>>>>>>>> should be
>>>>>>>>>>>         configured? I'd expect the setting to be in
>>>>>>>>>>> KeycloakDeployment and
>>>>>>>>>>>         OAuthRequestAuthenticator#loginRedirect would then use the
>>>>>>>>>>> value
>>>>>>>>>>>         instead
>>>>>>>>>>>         of always using the "code" value.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>         Mit freundlichen Gr??en,
>>>>>>>>>>>
>>>>>>>>>>> ------------------------------------------------------------------------
>>>>>>>>>>>
>>>>>>>>>>>         *Christian Beikov*
>>>>>>>>>>>         Am 18.04.2018 um 17:35 schrieb Christian Beikov:
>>>>>>>>>>>         >
>>>>>>>>>>>         > Is there any way to avoid the access code to access token
>>>>>>>>>>> exchange?
>>>>>>>>>>>         > Since the Keycloak server is not accessible, I'm getting
>>>>>>>>>>> an error
>>>>>>>>>>>         > during authentication:
>>>>>>>>>>>         >
>>>>>>>>>>>         >  ERROR [org.keycloak.adapters.OAuthRequestAuthenticator]
>>>>>>>>>>> (default
>>>>>>>>>>>         > task-54) failed to turn code into token:
>>>>>>>>>>>         > java.net.UnknownHostException: blabla.local: unknown error
>>>>>>>>>>>         >         ...
>>>>>>>>>>>         >         at
>>>>>>>>>>>         >
>>>>>>>>>>>
>>>>>>>>>>> org.keycloak.adapters.ServerRequest.invokeAccessCodeToToken(ServerRequest.java:111)
>>>>>>>>>>>
>>>>>>>>>>>         >         at
>>>>>>>>>>>         >
>>>>>>>>>>>
>>>>>>>>>>> org.keycloak.adapters.OAuthRequestAuthenticator.resolveCode(OAuthRequestAuthenticator.java:330)
>>>>>>>>>>>
>>>>>>>>>>>         >         at
>>>>>>>>>>>         >
>>>>>>>>>>>
>>>>>>>>>>> org.keycloak.adapters.OAuthRequestAuthenticator.authenticate(OAuthRequestAuthenticator.java:275)
>>>>>>>>>>>
>>>>>>>>>>>         >         at
>>>>>>>>>>>         >
>>>>>>>>>>>
>>>>>>>>>>> org.keycloak.adapters.RequestAuthenticator.authenticate(RequestAuthenticator.java:139)
>>>>>>>>>>>
>>>>>>>>>>>         >         at
>>>>>>>>>>>         >
>>>>>>>>>>>
>>>>>>>>>>> org.keycloak.adapters.undertow.AbstractUndertowKeycloakAuthMech.keycloakAuthenticate(AbstractUndertowKeycloakAuthMech.java:110)
>>>>>>>>>>>
>>>>>>>>>>>         >         at
>>>>>>>>>>>         >
>>>>>>>>>>>
>>>>>>>>>>> org.keycloak.adapters.undertow.ServletKeycloakAuthMech.authenticate(ServletKeycloakAuthMech.java:92)
>>>>>>>>>>>
>>>>>>>>>>>         >         ...
>>>>>>>>>>>         >
>>>>>>>>>>>         >
>>>>>>>>>>>         > Mit freundlichen Gr??en,
>>>>>>>>>>>         >
>>>>>>>>>>>
>>>>>>>>>>> ------------------------------------------------------------------------
>>>>>>>>>>>
>>>>>>>>>>>         > *Christian Beikov*
>>>>>>>>>>>         > Am 18.04.2018 um 14:48 schrieb Thomas Darimont:
>>>>>>>>>>>         >> Hello Christian,
>>>>>>>>>>>         >>
>>>>>>>>>>>         >> your application server needs to communicate with the
>>>>>>>>>>> Keycloak
>>>>>>>>>>>         server
>>>>>>>>>>>         >> to retrieve the realm public key referenced in the token to
>>>>>>>>>>> verify
>>>>>>>>>>>         >> the token signature.
>>>>>>>>>>>         >> The current implementation in Keycloak fetches & caches
>>>>>>>>>>> unknown
>>>>>>>>>>>         >> public keys automatically.
>>>>>>>>>>>         >>
>>>>>>>>>>>         >> You could also use a fixed realm public key on the
>>>>>>>>>>> application
>>>>>>>>>>>         server
>>>>>>>>>>>         >> side but it would not support key rotation anymore.
>>>>>>>>>>>         >>
>>>>>>>>>>>         >> Cheers,
>>>>>>>>>>>         >> Thomas
>>>>>>>>>>>         >>
>>>>>>>>>>>         >> 2018-04-18 13:45 GMT+02:00 Christian Beikov
>>>>>>>>>>>         >> <christian.beikov at gmail.com
>>>>>>>>>>> <mailto:christian.beikov at gmail.com>
>>>>>>>>>>>         <mailto:christian.beikov at gmail.com
>>>>>>>>>>>         <mailto:christian.beikov at gmail.com>>>:
>>>>>>>>>>>         >>
>>>>>>>>>>>         >>     Hi,
>>>>>>>>>>>         >>
>>>>>>>>>>>         >>     is it necessary that an application secured by
>>>>>>>>>>> Keycloak can
>>>>>>>>>>>         >>     access the
>>>>>>>>>>>         >>     Keycloak server? Or is it enough if the Browser can
>>>>>>>>>>> access
>>>>>>>>>>> the
>>>>>>>>>>>         >>     Keycloak
>>>>>>>>>>>         >>     server?
>>>>>>>>>>>         >>
>>>>>>>>>>>         >>     --
>>>>>>>>>>>         >>
>>>>>>>>>>>         >>     Mit freundlichen Gr??en,
>>>>>>>>>>>         >>
>>>>>>>>>>>
>>>>>>>>>>> ------------------------------------------------------------------------
>>>>>>>>>>>
>>>>>>>>>>>         >>     *Christian Beikov*
>>>>>>>>>>>         >> _______________________________________________
>>>>>>>>>>>         >>     keycloak-dev mailing list
>>>>>>>>>>>         >> keycloak-dev at lists.jboss.org
>>>>>>>>>>>         <mailto:keycloak-dev at lists.jboss.org>
>>>>>>>>>>>         <mailto:keycloak-dev at lists.jboss.org
>>>>>>>>>>>         <mailto:keycloak-dev at lists.jboss.org>>
>>>>>>>>>>>         >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>>>>> <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>>>>>>>>>>         >> <https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>>>>> <https://lists.jboss.org/mailman/listinfo/keycloak-dev>>
>>>>>>>>>>>         >>
>>>>>>>>>>>         >>
>>>>>>>>>>>         >
>>>>>>>>>>>
>>>>>>>>>>>         _______________________________________________
>>>>>>>>>>>         keycloak-dev mailing list
>>>>>>>>>>>         keycloak-dev at lists.jboss.org
>>>>>>>>>>> <mailto:keycloak-dev at lists.jboss.org>
>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>>>>> <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> keycloak-dev mailing list
>>>>>>>>>> keycloak-dev at lists.jboss.org
>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>> _______________________________________________
>>>>> keycloak-dev mailing list
>>>>> keycloak-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>> --
>> Bill Burke
>> Red Hat
>
>


From ramunask at gmail.com  Sun Apr 29 14:53:34 2018
From: ramunask at gmail.com (Ramunas)
Date: Sun, 29 Apr 2018 21:53:34 +0300
Subject: [keycloak-dev] Application and server in separate networks
In-Reply-To: <0b9d0fbb-a374-0c06-506c-f736701ba67c@gmail.com>
References: <41e1a805-cc38-50cf-f794-cda6afd49313@gmail.com>
	<CAK-7U1gGFnwc3EcgL3whgdGbSTH9xSVwVSHxc1i+JtetJ83H4g@mail.gmail.com>
	<24a0f868-9726-4024-6254-9a0b68b29c9f@gmail.com>
	<569a7f4e-2fa6-6590-2dfb-d7a57c137db2@gmail.com>
	<CAPLPygm2BHoNkrrYMWaOUHx1gGT-PbvSccTNf7JuuLjGeATrLg@mail.gmail.com>
	<d52de7b0-0041-46e2-f5ed-479fb0264528@gmail.com>
	<CABRXCmzfPqd-7rrMzox9UUAXkJZFngU=F6nUfh3ReNcA2P-6qg@mail.gmail.com>
	<e01068f2-8cd5-e855-86e3-1645ed36b118@redhat.com>
	<CABRXCmxdn_jnTPzRtLx6Rz80OUJUgMRRBvSg9jFDkyqP5zDyxg@mail.gmail.com>
	<1a844bee-aaf8-8c23-3e2d-c5bbefffa48e@redhat.com>
	<95470200-8cff-362d-5f0a-c345eed70b3c@gmail.com>
	<CABRXCmw_DpdufKjVAZJ-=dNDLxnG=rQEw=ExKD7nwWuyQ7qhgQ@mail.gmail.com>
	<7f7e0950-7d2d-7794-830f-f5edd2ec0ec0@gmail.com>
	<CABRXCmyzLO8r=c3Wfq=zg=Vo=ngZCHpp+zAV3Ut1MyY=1Zj2zA@mail.gmail.com>
	<CABRXCmwvjmYuLXJg4hXR8HZs=YX_U9pza5sGcLXd0_hQ-03cDg@mail.gmail.com>
	<0b9d0fbb-a374-0c06-506c-f736701ba67c@gmail.com>
Message-ID: <CAHYJo19K_nt7G7ENgpKDvEt38waGg67tYNyvsFko_2OBe-AixQ@mail.gmail.com>

Try configure without asterix - "http://localhost:8080/".

From christian.beikov at gmail.com  Sun Apr 29 17:50:33 2018
From: christian.beikov at gmail.com (Christian Beikov)
Date: Sun, 29 Apr 2018 23:50:33 +0200
Subject: [keycloak-dev] Application and server in separate networks
In-Reply-To: <CAHYJo19K_nt7G7ENgpKDvEt38waGg67tYNyvsFko_2OBe-AixQ@mail.gmail.com>
References: <41e1a805-cc38-50cf-f794-cda6afd49313@gmail.com>
	<24a0f868-9726-4024-6254-9a0b68b29c9f@gmail.com>
	<569a7f4e-2fa6-6590-2dfb-d7a57c137db2@gmail.com>
	<CAPLPygm2BHoNkrrYMWaOUHx1gGT-PbvSccTNf7JuuLjGeATrLg@mail.gmail.com>
	<d52de7b0-0041-46e2-f5ed-479fb0264528@gmail.com>
	<CABRXCmzfPqd-7rrMzox9UUAXkJZFngU=F6nUfh3ReNcA2P-6qg@mail.gmail.com>
	<e01068f2-8cd5-e855-86e3-1645ed36b118@redhat.com>
	<CABRXCmxdn_jnTPzRtLx6Rz80OUJUgMRRBvSg9jFDkyqP5zDyxg@mail.gmail.com>
	<1a844bee-aaf8-8c23-3e2d-c5bbefffa48e@redhat.com>
	<95470200-8cff-362d-5f0a-c345eed70b3c@gmail.com>
	<CABRXCmw_DpdufKjVAZJ-=dNDLxnG=rQEw=ExKD7nwWuyQ7qhgQ@mail.gmail.com>
	<7f7e0950-7d2d-7794-830f-f5edd2ec0ec0@gmail.com>
	<CABRXCmyzLO8r=c3Wfq=zg=Vo=ngZCHpp+zAV3Ut1MyY=1Zj2zA@mail.gmail.com>
	<CABRXCmwvjmYuLXJg4hXR8HZs=YX_U9pza5sGcLXd0_hQ-03cDg@mail.gmail.com>
	<0b9d0fbb-a374-0c06-506c-f736701ba67c@gmail.com>
	<CAHYJo19K_nt7G7ENgpKDvEt38waGg67tYNyvsFko_2OBe-AixQ@mail.gmail.com>
Message-ID: <98858f88-5db8-21f6-30c8-e559e74d3aac@gmail.com>

That doesn't work either.


Mit freundlichen Gr??en,
------------------------------------------------------------------------
*Christian Beikov*
Am 29.04.2018 um 20:53 schrieb Ramunas:
> Try configure without asterix - "http://localhost:8080/".


From mposolda at redhat.com  Mon Apr 30 03:02:46 2018
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 30 Apr 2018 09:02:46 +0200
Subject: [keycloak-dev] Application and server in separate networks
In-Reply-To: <98858f88-5db8-21f6-30c8-e559e74d3aac@gmail.com>
References: <41e1a805-cc38-50cf-f794-cda6afd49313@gmail.com>
	<24a0f868-9726-4024-6254-9a0b68b29c9f@gmail.com>
	<569a7f4e-2fa6-6590-2dfb-d7a57c137db2@gmail.com>
	<CAPLPygm2BHoNkrrYMWaOUHx1gGT-PbvSccTNf7JuuLjGeATrLg@mail.gmail.com>
	<d52de7b0-0041-46e2-f5ed-479fb0264528@gmail.com>
	<CABRXCmzfPqd-7rrMzox9UUAXkJZFngU=F6nUfh3ReNcA2P-6qg@mail.gmail.com>
	<e01068f2-8cd5-e855-86e3-1645ed36b118@redhat.com>
	<CABRXCmxdn_jnTPzRtLx6Rz80OUJUgMRRBvSg9jFDkyqP5zDyxg@mail.gmail.com>
	<1a844bee-aaf8-8c23-3e2d-c5bbefffa48e@redhat.com>
	<95470200-8cff-362d-5f0a-c345eed70b3c@gmail.com>
	<CABRXCmw_DpdufKjVAZJ-=dNDLxnG=rQEw=ExKD7nwWuyQ7qhgQ@mail.gmail.com>
	<7f7e0950-7d2d-7794-830f-f5edd2ec0ec0@gmail.com>
	<CABRXCmyzLO8r=c3Wfq=zg=Vo=ngZCHpp+zAV3Ut1MyY=1Zj2zA@mail.gmail.com>
	<CABRXCmwvjmYuLXJg4hXR8HZs=YX_U9pza5sGcLXd0_hQ-03cDg@mail.gmail.com>
	<0b9d0fbb-a374-0c06-506c-f736701ba67c@gmail.com>
	<CAHYJo19K_nt7G7ENgpKDvEt38waGg67tYNyvsFko_2OBe-AixQ@mail.gmail.com>
	<98858f88-5db8-21f6-30c8-e559e74d3aac@gmail.com>
Message-ID: <a0373121-6ff5-418d-214b-1277ec08c808@redhat.com>

I suggest to look at our SAML quickstarts/examples and compare their 
configurations,setup etc with yours. That can show the difference why 
they work when yours doesn't work.

Marek

On 29/04/18 23:50, Christian Beikov wrote:
> That doesn't work either.
>
>
> Mit freundlichen Gr??en,
> ------------------------------------------------------------------------
> *Christian Beikov*
> Am 29.04.2018 um 20:53 schrieb Ramunas:
>> Try configure without asterix - "http://localhost:8080/".
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



From christian.beikov at gmail.com  Mon Apr 30 06:20:03 2018
From: christian.beikov at gmail.com (Christian Beikov)
Date: Mon, 30 Apr 2018 12:20:03 +0200
Subject: [keycloak-dev] Application and server in separate networks
In-Reply-To: <a0373121-6ff5-418d-214b-1277ec08c808@redhat.com>
References: <41e1a805-cc38-50cf-f794-cda6afd49313@gmail.com>
	<569a7f4e-2fa6-6590-2dfb-d7a57c137db2@gmail.com>
	<CAPLPygm2BHoNkrrYMWaOUHx1gGT-PbvSccTNf7JuuLjGeATrLg@mail.gmail.com>
	<d52de7b0-0041-46e2-f5ed-479fb0264528@gmail.com>
	<CABRXCmzfPqd-7rrMzox9UUAXkJZFngU=F6nUfh3ReNcA2P-6qg@mail.gmail.com>
	<e01068f2-8cd5-e855-86e3-1645ed36b118@redhat.com>
	<CABRXCmxdn_jnTPzRtLx6Rz80OUJUgMRRBvSg9jFDkyqP5zDyxg@mail.gmail.com>
	<1a844bee-aaf8-8c23-3e2d-c5bbefffa48e@redhat.com>
	<95470200-8cff-362d-5f0a-c345eed70b3c@gmail.com>
	<CABRXCmw_DpdufKjVAZJ-=dNDLxnG=rQEw=ExKD7nwWuyQ7qhgQ@mail.gmail.com>
	<7f7e0950-7d2d-7794-830f-f5edd2ec0ec0@gmail.com>
	<CABRXCmyzLO8r=c3Wfq=zg=Vo=ngZCHpp+zAV3Ut1MyY=1Zj2zA@mail.gmail.com>
	<CABRXCmwvjmYuLXJg4hXR8HZs=YX_U9pza5sGcLXd0_hQ-03cDg@mail.gmail.com>
	<0b9d0fbb-a374-0c06-506c-f736701ba67c@gmail.com>
	<CAHYJo19K_nt7G7ENgpKDvEt38waGg67tYNyvsFko_2OBe-AixQ@mail.gmail.com>
	<98858f88-5db8-21f6-30c8-e559e74d3aac@gmail.com>
	<a0373121-6ff5-418d-214b-1277ec08c808@redhat.com>
Message-ID: <0c5ceaf0-f74f-1e6f-ce34-c294ecbd6533@gmail.com>

I don't know why the Redirect URI configuration didn't work yesterday. 
When I tried to use http://localhost:8080/* today, it worked. Maybe 
there is a TTL based cache for the client that wasn't invalidated 
properly after I deleted the client?

After many hours of trial and error I finally found a configuration that 
works. Apparently, the configuration "Master SAML Processing URL" is 
required for the authentication to work, which begs the question, why 
isn't the field required in the UI or has a default to "Root URL + /saml" ?

Thanks for your help!


Mit freundlichen Gr??en,
------------------------------------------------------------------------
*Christian Beikov*
Am 30.04.2018 um 09:02 schrieb Marek Posolda:
> I suggest to look at our SAML quickstarts/examples and compare their 
> configurations,setup etc with yours. That can show the difference why 
> they work when yours doesn't work.
>
> Marek
>
> On 29/04/18 23:50, Christian Beikov wrote:
>> That doesn't work either.
>>
>>
>> Mit freundlichen Gr??en,
>> ------------------------------------------------------------------------
>> *Christian Beikov*
>> Am 29.04.2018 um 20:53 schrieb Ramunas:
>>> Try configure without asterix - "http://localhost:8080/".
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>