From sthorger at redhat.com  Fri Dec  1 03:39:31 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 1 Dec 2017 09:39:31 +0100
Subject: [keycloak-dev] Strip default port from URLs in KeycloakUriBilder
Message-ID: <CAJgngAerRB_1aN5LdYTXfnBTO+-Tb=9GVjob4DGma396zCsouQ@mail.gmail.com>

I've sent a PR [1] that strips default ports (80 if http, 443 if https)
from the URL in KeycloakUriBuilder. This is to make sure URLs matches URLs
in browsers (browsers already do this) and also strips default ports from
adapter configs which resolves [2].

[2] although strictly bad config is nice to be able to do if you have a
keycloak.json file that takes the port from environment variables to for
instance run on 8080 in test and 80 in prod.

Anyone have any concerns with this PR?

[1] https://github.com/keycloak/keycloak/pull/4774
[2] https://issues.jboss.org/browse/KEYCLOAK-5945

From sthorger at redhat.com  Fri Dec  1 03:43:27 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 1 Dec 2017 09:43:27 +0100
Subject: [keycloak-dev] Is there a way to log the details from
	ErrorResponseExceptions?
In-Reply-To: <CALO-DfDczCJr2i17R=xL9yOB3Mb_rBTDHp2iKnfJ0btvkXL8KQ@mail.gmail.com>
References: <CALO-DfDczCJr2i17R=xL9yOB3Mb_rBTDHp2iKnfJ0btvkXL8KQ@mail.gmail.com>
Message-ID: <CAJgngAd0huH2Wc8=M+o-C_3eJPsKkOD4UPzit3UkTmjxxL85uQ@mail.gmail.com>

We should probably update the events to include the description or add some
debug logging. I'd say updating events is probably the ideal approach.
Would need changes in Keycloak though.

On 27 November 2017 at 17:57, Jared Blashka <jblashka at redhat.com> wrote:

> Some of our clients are generating many REFRESH_TOKEN_ERROR events but I
> don't see anywhere that the error description from the exception is
> logged/stored. The keycloak event itself only says 'invalid token', but I'd
> like to see the '{"error":"invalid_grant","error_description":"Session not
> active"}' details as well to be able to provide specific guidance around
> why their refresh calls are failing.
>
> I tried registering an Exception Mapper provider, but it doesn't looks like
> that's supported yet (
> http://lists.jboss.org/pipermail/keycloak-dev/2016-June/007361.html).
>
> We're running RH-SSO 7.1.3.
>
> Thanks!
> Jared Blashka
> 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  Fri Dec  1 03:47:01 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 1 Dec 2017 09:47:01 +0100
Subject: [keycloak-dev] Problem with 3.4.0 (not present in 3.2.1)
In-Reply-To: <CAAg5f2ScaB94TWu3BKt9uwv=rud2goHS75M8ekWtDxxKXMxH1g@mail.gmail.com>
References: <CAAg5f2ScaB94TWu3BKt9uwv=rud2goHS75M8ekWtDxxKXMxH1g@mail.gmail.com>
Message-ID: <CAJgngAfyFjT_a5xJmsZqexZVNtGkF0m2Doqv+W9NS4Bu_LFyTA@mail.gmail.com>

Did you get a chance to try out
https://github.com/keycloak/keycloak/pull/4773?

I wasn't able to reproduce this, but if you give me steps on how to run it
I can try to debug it.

On 27 November 2017 at 15:14, Matthias Wessendorf <matzew at apache.org> wrote:

> Hi,
>
> I am on 3,2,1 and all works fine. Updating to 3.4.0 causes a problem:
>
> * After I enter user/passwd on the keycloak login form. I get an endless
> redirect loop, with the following log message in Chrome (FF has same
> redirect loop):
>
>
> The value of the 'Access-Control-Allow-Origin' header in the response must
> not be the wildcard '*' when the request's credentials mode is 'include'.
> Origin 'http://localhost:9191' is therefore not allowed access. The
> credentials mode of requests initiated by the XMLHttpRequest is controlled
> by the withCredentials attribute.
>
>
> I've updated my java adapters to 3.4.0 as well the as the angular one:
> https://github.com/aerogear/unifiedpush-admin-ui/pull/14/files
>
> I have this in the config of my realm:
> https://github.com/aerogear/aerogear-unifiedpush-server/
> blob/master/docker-compose/keycloak-realm/ups-realm-sample.json#L62
>
> and as said before w/ the 3.2.1 it all works - with 3.4.0 not
>
> Anyone seen this before ?
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> twitter: http://twitter.com/mwessendorf
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From wtrocki at redhat.com  Fri Dec  1 07:19:41 2017
From: wtrocki at redhat.com (Wojciech Trocki)
Date: Fri, 1 Dec 2017 12:19:41 +0000
Subject: [keycloak-dev] Keycloak login without redirect to external login
	page
Message-ID: <CAO0+n+qfJ-KEdO0h0tNy=tdfy+S_T6G_gL=T=g5zoynurtq79A@mail.gmail.com>

I'm investigating possible options for creating javascript client that will
help mobile developers (cordova, react native) to integrate with keycloak.

The main idea will be to mimic other solutions that allow to login to the
auth server using single method (instead of redirecting to the login page)

For example:

*authbase.auth().signInWithEmailAndPassword(email, password).then(...);*

JavaScript adapter from keycloak team works fine for both Android and IOS,
but mounting login page in webview and styling login page, may be barrier
for the developers starting with keycloak.

*Questions:*

1) Is possible to use keycloak without redirect to keycloak login page?

2) Do you have any suggestions for areas were mobile experience can be
improved?

This topic was raised before on both dev and users lists before, but
without definitive answer[1]
I'm looking for any information that may be helpful.

[1] http://lists.jboss.org/pipermail/keycloak-user/2016-November/008295.html

-- 

WOJCIECH TROCKI

Red Hat Mobile <https://www.redhat.com/>

IM: wtrocki
<https://red.ht/sig>

From wtrocki at redhat.com  Fri Dec  1 07:30:21 2017
From: wtrocki at redhat.com (Wojciech Trocki)
Date: Fri, 1 Dec 2017 12:30:21 +0000
Subject: [keycloak-dev] Keycloak login without redirect to external
	login page
In-Reply-To: <CAO0+n+qfJ-KEdO0h0tNy=tdfy+S_T6G_gL=T=g5zoynurtq79A@mail.gmail.com>
References: <CAO0+n+qfJ-KEdO0h0tNy=tdfy+S_T6G_gL=T=g5zoynurtq79A@mail.gmail.com>
Message-ID: <CAO0+n+qid-LRx1dns_Z3_HmDDt33xL59ansbywxn5=iZbRVBSQ@mail.gmail.com>

TL;DR - I'm looking to contribute to keycloak in my spare time.
I'm interested in mobile areas, mostly related with the login process.

On Fri, Dec 1, 2017 at 12:19 PM, Wojciech Trocki <wtrocki at redhat.com> wrote:

> I'm investigating possible options for creating javascript client that
> will help mobile developers (cordova, react native) to integrate with
> keycloak.
>
> The main idea will be to mimic other solutions that allow to login to the
> auth server using single method (instead of redirecting to the login page)
>
> For example:
>
> *authbase.auth().signInWithEmailAndPassword(email, password).then(...);*
>
> JavaScript adapter from keycloak team works fine for both Android and IOS,
> but mounting login page in webview and styling login page, may be barrier
> for the developers starting with keycloak.
>
> *Questions:*
>
> 1) Is possible to use keycloak without redirect to keycloak login page?
>
> 2) Do you have any suggestions for areas were mobile experience can be
> improved?
>
> This topic was raised before on both dev and users lists before, but
> without definitive answer[1]
> I'm looking for any information that may be helpful.
>
> [1] http://lists.jboss.org/pipermail/keycloak-user/2016-
> November/008295.html
>
>

From bburke at redhat.com  Fri Dec  1 08:53:49 2017
From: bburke at redhat.com (Bill Burke)
Date: Fri, 1 Dec 2017 08:53:49 -0500
Subject: [keycloak-dev] Better support authenticationSessions in
 multiple browser tabs
In-Reply-To: <7e6d1466-9634-c483-5750-a5c7d83c83f3@redhat.com>
References: <df2376a1-d9c4-1b41-237b-ffd7ee073e18@redhat.com>
	<CAJgngAd++v1+4wQr+O7AizTDgcfe3nYUJZ5WG+tv+r+d942rnw@mail.gmail.com>
	<7e6d1466-9634-c483-5750-a5c7d83c83f3@redhat.com>
Message-ID: <CABRXCmz78dM=tdA+-wycHWLf476NQfsWJ20kexF5Lq=b82Qwhg@mail.gmail.com>

On Wed, Nov 29, 2017 at 9:09 AM, Marek Posolda <mposolda at redhat.com> wrote:
> On 29/11/17 14:44, Stian Thorgersen wrote:
>> I would target this to 3.4.2. I don't want to delay the 3.4.1 release
>> if we can help it.
>>
>> I'd also suggest some (short if possible) random key (or a counter?!)
>> rather than relying on protocol specific values. 'state' is not
>> actually required in OAuth right? It's just recommended.
> Yes, it's not required. And same for SAML. Was wondering about the same.
> Will use the random key or counter. Thinking if counter doesn't have
> some corner case issues (EG. If 2 tabs are opened concurrently after
> logout and will try to use same counter value as authSession update from
> tab2 won't be yet visible in tab1).
>

the "state" parameter IS required.  Its how the client can figure out
that it initiated the login or not.

I don't understand your solution...BTW, going back to auth_session_id
within the URL instead of a cookie like we used to do would fix this
too :).  If you're already going to add a "client-id" query parameter,
why not just revert back to the old way of doing this?

--
Bill Burke
Red Hat

From Gael.THIABAUD at almerys.com  Fri Dec  1 09:43:31 2017
From: Gael.THIABAUD at almerys.com (Gael THIABAUD)
Date: Fri, 1 Dec 2017 14:43:31 +0000
Subject: [keycloak-dev] Feature request: Internal Token to External Token
 Exchange with automatic user linking in the External realm
Message-ID: <e6a05564bfb343b694e76a13759da341@excmb02-prd.ressources.priv>

Dear Keycloak team,

The current usage of " Internal Token to External Token Exchange" is based on the fact that the user in the "external" realm was previously linked with the "Internal" Realm.
The current implementation of Client Initiated Account Linking is taking care only of the request coming from a Web Browser.

I need to have it working if the requester is an application backend.
Eg: A back end of a web application need to use a REST service that is not managed by the same realm.

USER --> Web APP -redirect->KC Realm A -Credential request-> USER -credentials> KC Realm A -token & redirect -> USER -redirect-> Web APP - Internal to External Token Exchange -> KC Realm A -request token exchange > KC Realm B - create user from token -> KC Realm B -Realm B Token -> KC Realm A -> Web APP - Realm B Token in bearer mode -> REST server depending of Realm B

Is my use case clear ?
Do you have a proposal ?
Can we help for the implementation ?

Regards

Ga?l THIABAUD
Direction Technique
mailto:gael.thiabaud at almerys.com

T?l?phone: 04 73 74 82 84
almerys, 46 Rue du Ressort, 63967 Clermont-Ferrand Cedex 9
www.almerys.com
      Scrum Master




From sblanc at redhat.com  Fri Dec  1 11:09:08 2017
From: sblanc at redhat.com (Sebastien Blanc)
Date: Fri, 1 Dec 2017 17:09:08 +0100
Subject: [keycloak-dev] Strip default port from URLs in KeycloakUriBilder
In-Reply-To: <CAJgngAerRB_1aN5LdYTXfnBTO+-Tb=9GVjob4DGma396zCsouQ@mail.gmail.com>
References: <CAJgngAerRB_1aN5LdYTXfnBTO+-Tb=9GVjob4DGma396zCsouQ@mail.gmail.com>
Message-ID: <CAMZCGg-Ux6st=rKPCs2254CiWCzjV8fn=yfJ3ExpzqrnFO0L5Q@mail.gmail.com>

Make sense to me

On Fri, Dec 1, 2017 at 9:39 AM, Stian Thorgersen <sthorger at redhat.com>
wrote:

> I've sent a PR [1] that strips default ports (80 if http, 443 if https)
> from the URL in KeycloakUriBuilder. This is to make sure URLs matches URLs
> in browsers (browsers already do this) and also strips default ports from
> adapter configs which resolves [2].
>
> [2] although strictly bad config is nice to be able to do if you have a
> keycloak.json file that takes the port from environment variables to for
> instance run on 8080 in test and 80 in prod.
>
> Anyone have any concerns with this PR?
>
> [1] https://github.com/keycloak/keycloak/pull/4774
> [2] https://issues.jboss.org/browse/KEYCLOAK-5945
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sblanc at redhat.com  Fri Dec  1 11:13:02 2017
From: sblanc at redhat.com (Sebastien Blanc)
Date: Fri, 1 Dec 2017 17:13:02 +0100
Subject: [keycloak-dev] Keycloak login without redirect to external
	login page
In-Reply-To: <CAO0+n+qid-LRx1dns_Z3_HmDDt33xL59ansbywxn5=iZbRVBSQ@mail.gmail.com>
References: <CAO0+n+qfJ-KEdO0h0tNy=tdfy+S_T6G_gL=T=g5zoynurtq79A@mail.gmail.com>
	<CAO0+n+qid-LRx1dns_Z3_HmDDt33xL59ansbywxn5=iZbRVBSQ@mail.gmail.com>
Message-ID: <CAMZCGg9_2naKpDwyzbnXjt6pwnKBK=4uraie+dsM4P-y2g=ojg@mail.gmail.com>

Hi !

Have you talked with Summers about this, he know he had also some ideas ?

For your first question, yes you can bypass the redirect by using Direct
Grant but it's not really a good practice and you loose most of the SSO
benefits.

Sebi


On Fri, Dec 1, 2017 at 1:30 PM, Wojciech Trocki <wtrocki at redhat.com> wrote:

> TL;DR - I'm looking to contribute to keycloak in my spare time.
> I'm interested in mobile areas, mostly related with the login process.
>
> On Fri, Dec 1, 2017 at 12:19 PM, Wojciech Trocki <wtrocki at redhat.com>
> wrote:
>
> > I'm investigating possible options for creating javascript client that
> > will help mobile developers (cordova, react native) to integrate with
> > keycloak.
> >
> > The main idea will be to mimic other solutions that allow to login to the
> > auth server using single method (instead of redirecting to the login
> page)
> >
> > For example:
> >
> > *authbase.auth().signInWithEmailAndPassword(email, password).then(...);*
> >
> > JavaScript adapter from keycloak team works fine for both Android and
> IOS,
> > but mounting login page in webview and styling login page, may be barrier
> > for the developers starting with keycloak.
> >
> > *Questions:*
> >
> > 1) Is possible to use keycloak without redirect to keycloak login page?
> >
> > 2) Do you have any suggestions for areas were mobile experience can be
> > improved?
> >
> > This topic was raised before on both dev and users lists before, but
> > without definitive answer[1]
> > I'm looking for any information that may be helpful.
> >
> > [1] http://lists.jboss.org/pipermail/keycloak-user/2016-
> > November/008295.html
> >
> >
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From supittma at redhat.com  Fri Dec  1 14:38:32 2017
From: supittma at redhat.com (Summers Pittman)
Date: Fri, 1 Dec 2017 14:38:32 -0500
Subject: [keycloak-dev] Keycloak login without redirect to external
	login page
In-Reply-To: <CAO0+n+qfJ-KEdO0h0tNy=tdfy+S_T6G_gL=T=g5zoynurtq79A@mail.gmail.com>
References: <CAO0+n+qfJ-KEdO0h0tNy=tdfy+S_T6G_gL=T=g5zoynurtq79A@mail.gmail.com>
Message-ID: <CAEQz2CsfXxCrjWpMUDbjUhQaj6u4zT4Zq0HwjAigWTmxgHSscA@mail.gmail.com>

On Fri, Dec 1, 2017 at 7:19 AM, Wojciech Trocki <wtrocki at redhat.com> wrote:

> I'm investigating possible options for creating javascript client that
> will help mobile developers (cordova, react native) to integrate with
> keycloak.
>
> The main idea will be to mimic other solutions that allow to login to the
> auth server using single method (instead of redirecting to the login page)
>
> For example:
>
> *authbase.auth().signInWithEmailAndPassword(email, password).then(...);*
>
> JavaScript adapter from keycloak team works fine for both Android and IOS,
> but mounting login page in webview and styling login page, may be barrier
> for the developers starting with keycloak.
>
> *Questions:*
>
> 1) Is possible to use keycloak without redirect to keycloak login page?
>
>

> 2) Do you have any suggestions for areas were mobile experience can be
> improved?
>
>
I don't have a JavaScript answer for you (boo!), but I have been tumbling
around in my head what it would take to make a broker that you can log in
to.  A broker would basically act as a ghetto IdP and sock puppet account
mgmt in KeyCloak.  That is a lot more work than just opening a web browser.

See my post here for a better version of that idea :
http://lists.jboss.org/pipermail/keycloak-user/2017-November/012404.html

Alternatively many systems have native token management that you might be
able to hook into as well.  It doesn't negate the need to go to the system
browser, but if you are using the same account in multiple apps it could
give you a way to share a session without having each app log in separately.

However, the system browsers are starting to get smarter about their role
in modern authentication so you might be able to leverage them as well.
IIRC Chrome on Android treats the Google account special and I am sure you
can find something similar with safari on iOS.



> This topic was raised before on both dev and users lists before, but
> without definitive answer[1]
> I'm looking for any information that may be helpful.
>
> [1] http://lists.jboss.org/pipermail/keycloak-user/2016-
> November/008295.html
>
> --
>
> WOJCIECH TROCKI
>
> Red Hat Mobile <https://www.redhat.com/>
>
> IM: wtrocki
> <https://red.ht/sig>
>

From aron.bustya.js at gmail.com  Fri Dec  1 22:44:38 2017
From: aron.bustya.js at gmail.com (Aron Bustya)
Date: Sat, 2 Dec 2017 04:44:38 +0100
Subject: [keycloak-dev] make sending a request object mandatory for certain
	clients
Message-ID: <CAGZZ5Oh5AEhrzpYqA+weqDBfLzGezd0WMMCsnxqHYm-2MLCajw@mail.gmail.com>

Hi!

I have a use case where the server must accept authorization requests only
when they contain a signed request object (should be configurable per
client).

I have found a way to make the signing of the request object mandatory by
specifying a 'request.object.signature.alg' attribute on the client, but
this only applies if a request object exists in the first place.

I would like to propose a pull request: It defines a new client attribute
'request.object.required'. If this is set to 'true', the client must send a
request object when initiating an authorization request.

Current code can be checked here:
https://github.com/abustya/keycloak/commit/476912906a3ad0d290220a1f54abee073dba687a

What do you think?

Regards,
?ron Bustya

From sthorger at redhat.com  Mon Dec  4 02:56:35 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 4 Dec 2017 08:56:35 +0100
Subject: [keycloak-dev] Better support authenticationSessions in
 multiple browser tabs
In-Reply-To: <CABRXCmz78dM=tdA+-wycHWLf476NQfsWJ20kexF5Lq=b82Qwhg@mail.gmail.com>
References: <df2376a1-d9c4-1b41-237b-ffd7ee073e18@redhat.com>
	<CAJgngAd++v1+4wQr+O7AizTDgcfe3nYUJZ5WG+tv+r+d942rnw@mail.gmail.com>
	<7e6d1466-9634-c483-5750-a5c7d83c83f3@redhat.com>
	<CABRXCmz78dM=tdA+-wycHWLf476NQfsWJ20kexF5Lq=b82Qwhg@mail.gmail.com>
Message-ID: <CAJgngAfzALbsmshoHZ4JtSRNuMpB9X0r2N-rgZDigj=ToAB1tw@mail.gmail.com>

On 1 December 2017 at 14:53, Bill Burke <bburke at redhat.com> wrote:

> On Wed, Nov 29, 2017 at 9:09 AM, Marek Posolda <mposolda at redhat.com>
> wrote:
> > On 29/11/17 14:44, Stian Thorgersen wrote:
> >> I would target this to 3.4.2. I don't want to delay the 3.4.1 release
> >> if we can help it.
> >>
> >> I'd also suggest some (short if possible) random key (or a counter?!)
> >> rather than relying on protocol specific values. 'state' is not
> >> actually required in OAuth right? It's just recommended.
> > Yes, it's not required. And same for SAML. Was wondering about the same.
> > Will use the random key or counter. Thinking if counter doesn't have
> > some corner case issues (EG. If 2 tabs are opened concurrently after
> > logout and will try to use same counter value as authSession update from
> > tab2 won't be yet visible in tab1).
> >
>
> the "state" parameter IS required.  Its how the client can figure out
> that it initiated the login or not.
>

https://tools.ietf.org/html/rfc6749#section-4.1.1

It's RECOMMENDED


>
> I don't understand your solution...BTW, going back to auth_session_id
> within the URL instead of a cookie like we used to do would fix this
> too :).  If you're already going to add a "client-id" query parameter,
> why not just revert back to the old way of doing this?
>

Cookie solves a lot of issues. Can't remember the details of all of them,
but these have been discussed several times on the mailing list this year.


>
> --
> Bill Burke
> Red Hat
>

From mposolda at redhat.com  Mon Dec  4 04:21:57 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 4 Dec 2017 10:21:57 +0100
Subject: [keycloak-dev] Better support authenticationSessions in
 multiple browser tabs
In-Reply-To: <CABRXCmz78dM=tdA+-wycHWLf476NQfsWJ20kexF5Lq=b82Qwhg@mail.gmail.com>
References: <df2376a1-d9c4-1b41-237b-ffd7ee073e18@redhat.com>
	<CAJgngAd++v1+4wQr+O7AizTDgcfe3nYUJZ5WG+tv+r+d942rnw@mail.gmail.com>
	<7e6d1466-9634-c483-5750-a5c7d83c83f3@redhat.com>
	<CABRXCmz78dM=tdA+-wycHWLf476NQfsWJ20kexF5Lq=b82Qwhg@mail.gmail.com>
Message-ID: <07aace84-a53b-17d0-5bdd-21369662a86d@redhat.com>

On 01/12/17 14:53, Bill Burke wrote:
> On Wed, Nov 29, 2017 at 9:09 AM, Marek Posolda <mposolda at redhat.com> wrote:
>> On 29/11/17 14:44, Stian Thorgersen wrote:
>>> I would target this to 3.4.2. I don't want to delay the 3.4.1 release
>>> if we can help it.
>>>
>>> I'd also suggest some (short if possible) random key (or a counter?!)
>>> rather than relying on protocol specific values. 'state' is not
>>> actually required in OAuth right? It's just recommended.
>> Yes, it's not required. And same for SAML. Was wondering about the same.
>> Will use the random key or counter. Thinking if counter doesn't have
>> some corner case issues (EG. If 2 tabs are opened concurrently after
>> logout and will try to use same counter value as authSession update from
>> tab2 won't be yet visible in tab1).
>>
> the "state" parameter IS required.  Its how the client can figure out
> that it initiated the login or not.
>
> I don't understand your solution...BTW, going back to auth_session_id
> within the URL instead of a cookie like we used to do would fix this
> too :).  If you're already going to add a "client-id" query parameter,
> why not just revert back to the old way of doing this?
Yes, it would fix it to add the ID to the URL. That's the plan.

But at the same time, we also need the cookie as we need sticky session 
for cluster and especially for cross-dc. Hence to be able to continue 
existing authenticationSession flow, you will need both:
- AUTH_SESSION_ID cookie, which would allow to lookup 
"RootAuthenticationSessionModel" from the infinispan cache
- The state in the URL, which would allow to lookup the children 
AuthenticationSessionModel within RootAuthenticationSessionModel.

I've added more details in the other mail. Hope not too much :)

Marek

>
> --
> Bill Burke
> Red Hat



From bburke at redhat.com  Tue Dec  5 17:27:31 2017
From: bburke at redhat.com (Bill Burke)
Date: Tue, 5 Dec 2017 17:27:31 -0500
Subject: [keycloak-dev] Why are offline sessions imported?
Message-ID: <CABRXCmw6M8nYh56=gb6X9MA=K2BMD_UJFYuxPabtmmVG2+hYtQ@mail.gmail.com>

I'm working on:

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

This can be fixed by having a try/catch block when loading a user
within JpaUserSessionPersisterProvider.loadUserSessions() and skipping
that particular offline token.

My question is, Why are offline tokens "imported" into the user
session cache at boot?  Why aren't they just pulled on demand (i.e. a
refresh token request)? Imagine booting keycloak when LDAP is down (as
per the JIRA above).  The fix will allow Keycloak to boot, but all
offline tokens originating from this LDAP will no longer work.
Keycloak would need to be restarted after LDAP is back up in order for
any offline tokens to work again.

-- 
Bill Burke
Red Hat

From jweckhart at gmail.com  Tue Dec  5 17:54:38 2017
From: jweckhart at gmail.com (John Eckhart)
Date: Tue, 05 Dec 2017 22:54:38 +0000
Subject: [keycloak-dev] Adding a custom field to OIDC/SAML provider setup
Message-ID: <CA+B5SuigAkSpBH9R1qQKx5Q1T=AnNBLfSW9bwQFJXHrpeaKhpw@mail.gmail.com>

I would like to add a custom field/property/attribute to an OIDC or SAML
provider and I'm looking for a few pointers.

The use-case is to have many identity providers configured in Keycloak and
prompt the user to enter their email address to determine which IdP to
redirect the user. Each IdP would have one email suffix that it provides
logins for (this would be the custom field). This is a similar flow to
Microsoft's Office 365 and OpsGenie's federated login.

Although this could be implemented outside of Keycloak, ideally we could
contain this as a custom Rest API added to KC while extending a theme and
SPI reusing as much as possible inside Keycloak.

Any thoughts/tips are much appreciated.

From supittma at redhat.com  Thu Dec  7 09:12:57 2017
From: supittma at redhat.com (Summers Pittman)
Date: Thu, 7 Dec 2017 09:12:57 -0500
Subject: [keycloak-dev] Keycloak login without redirect to external
	login page
In-Reply-To: <CAEQz2CsfXxCrjWpMUDbjUhQaj6u4zT4Zq0HwjAigWTmxgHSscA@mail.gmail.com>
References: <CAO0+n+qfJ-KEdO0h0tNy=tdfy+S_T6G_gL=T=g5zoynurtq79A@mail.gmail.com>
	<CAEQz2CsfXxCrjWpMUDbjUhQaj6u4zT4Zq0HwjAigWTmxgHSscA@mail.gmail.com>
Message-ID: <CAEQz2CuT_bojYtV0uvO2xb5L1yCoo9KK=8K9E3-iGj3nsycLOw@mail.gmail.com>

I have been able to sign into KeyCloak without writing a broker service and
using the external/internal key exchange, Google's OpenID endpoints, and
the Google Android SDK.

Basically just follow the docs here :
http://www.keycloak.org/docs/latest/securing_apps/index.html#external-token-to-internal-token-exchange
to setup the server.

There are a couple caveats I discovered to making it work with Google.
First you have to create a generic OpenID Connect IdP configuration in
Keycloak instead of using the Google one.  With the exception of Google's
Client ID and secret you can prefill all of the values using Google's well
known file (https://accounts.google.com/.well-known/openid-configuration).
Secondly I disabled the userInfo endpoint because Google needs a Auth token
that is not the ID Token they send you which is used in the KeyCloak key
Exchange.

You can checkout my quick and dirty Android code here :
https://github.com/secondsun/TokenExchangeDemo
(Warning, there may be code gore).

I haven't tested it with non Google IdPs, but I would imagine most OpenID
Connect services will work as well.  This isn't quite your use case, but I
hope it gets you closer.


On Fri, Dec 1, 2017 at 2:38 PM, Summers Pittman <supittma at redhat.com> wrote:

>
>
> On Fri, Dec 1, 2017 at 7:19 AM, Wojciech Trocki <wtrocki at redhat.com>
> wrote:
>
>> I'm investigating possible options for creating javascript client that
>> will help mobile developers (cordova, react native) to integrate with
>> keycloak.
>>
>> The main idea will be to mimic other solutions that allow to login to the
>> auth server using single method (instead of redirecting to the login page)
>>
>> For example:
>>
>> *authbase.auth().signInWithEmailAndPassword(email, password).then(...);*
>>
>> JavaScript adapter from keycloak team works fine for both Android and
>> IOS, but mounting login page in webview and styling login page, may be
>> barrier for the developers starting with keycloak.
>>
>> *Questions:*
>>
>> 1) Is possible to use keycloak without redirect to keycloak login page?
>>
>>
>
>> 2) Do you have any suggestions for areas were mobile experience can be
>> improved?
>>
>>
> I don't have a JavaScript answer for you (boo!), but I have been tumbling
> around in my head what it would take to make a broker that you can log in
> to.  A broker would basically act as a ghetto IdP and sock puppet account
> mgmt in KeyCloak.  That is a lot more work than just opening a web browser.
>
> See my post here for a better version of that idea :
> http://lists.jboss.org/pipermail/keycloak-user/2017-November/012404.html
>
> Alternatively many systems have native token management that you might be
> able to hook into as well.  It doesn't negate the need to go to the system
> browser, but if you are using the same account in multiple apps it could
> give you a way to share a session without having each app log in separately.
>
> However, the system browsers are starting to get smarter about their role
> in modern authentication so you might be able to leverage them as well.
> IIRC Chrome on Android treats the Google account special and I am sure you
> can find something similar with safari on iOS.
>
>
>
>> This topic was raised before on both dev and users lists before, but
>> without definitive answer[1]
>> I'm looking for any information that may be helpful.
>>
>> [1] http://lists.jboss.org/pipermail/keycloak-user/2016-Nove
>> mber/008295.html
>>
>> --
>>
>> WOJCIECH TROCKI
>>
>> Red Hat Mobile <https://www.redhat.com/>
>>
>> IM: wtrocki
>> <https://red.ht/sig>
>>
>
>

From thom.nocon at gmail.com  Thu Dec  7 10:04:15 2017
From: thom.nocon at gmail.com (Tomek)
Date: Thu, 7 Dec 2017 16:04:15 +0100
Subject: [keycloak-dev] [Improvment Request] Add context for an permission
	requests
Message-ID: <CAFGTxA4qDNSfrtbc9HoKnq3YbEYPHxGZzkujwMdyLS3Wq_FT1g@mail.gmail.com>

Hello guys,

we would like to propose an improvment that can be added to the *Entitlment
API*. This topic was already opened in this mail: link
<http://lists.jboss.org/pipermail/keycloak-user/2017-February/009391.html>.
The main purpose of this improvment is to add an optional contextual data
for an permission requests.

Let's take into account an examle bussines case: evaluate permission to
orders in the context of specific shops. Those shops can be added to
the *Keycloak
*as a specific resources or scopes inside the *Order* resource. In our
point of view this is an overhead when we must synchronize all shops from
DB with *Keycloak*.

We have prepared a simple improvment. Here is an example of entitlment
request:

*POST /auth/realms/{realmName}/authz/entitlement/{clientName}*
*{*
* "permissions": [*
* {*
* "resource_set_name": "Orders Resource",*
* "context": {*
* "shops": ["shop1", "shop2"]*
* }*
* },*
* {*
* "resource_set_name": "Shop Resource"*
* }*
* ]*
*}*

The *context* is a map: *Map<String, Collection<String>> *and it could be
injected to the *Attributes* inside the *EvaluationContext* class before
policy evaluation.

The result of this request is an *RPT* token that also contains the
contextual data, so it can be later re-used. An example encoded *RPT* token:

*{*
*.....*
* "authorization": {*
* "permissions": [*
* {*
* "resource_set_id": "76bb1db0-b3c3-47a1-9d06-8f3b98d2ba10",*
* "resource_set_name": "Default Resource",*
* "context": {*
* "shops": ["shop1", "shop2"]*
* }*
* }*
* ]*
* }*
*.....*
*}*

The reason for this improvement is the overhead that arises when we have a
lot of resources to handle and they are added dynamically.

I have already implemented a working proof of concept, that is accessible
in the following link
<https://github.com/nocotom/keycloak/tree/feature/permission-context>.
(the context in the returned *RPT *token is missing, but the input context
is propagated to the policy evaluation)

Is this something *Keycloak *might have implemented?
What you think, guys?

Regards,
Tom Noco?

From mikolaj.buda at contractors.roche.com  Fri Dec  8 02:52:34 2017
From: mikolaj.buda at contractors.roche.com (Buda, Mikolaj)
Date: Fri, 8 Dec 2017 08:52:34 +0100
Subject: [keycloak-dev] SAML token authentication
Message-ID: <CADdJyKpDas3Rk=5oeXe1yqW9iVSP4GUymw1-bLuaopBuBzMA8Q@mail.gmail.com>

Hello,

I would like to debug my local keycloak 1.9.2 instance. I'm looking for the
class which is responsible for SAML token authentication during log in
using IDP url. Which class is it?

Best regards,
Miko?aj

From sthorger at redhat.com  Fri Dec  8 03:37:40 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 8 Dec 2017 09:37:40 +0100
Subject: [keycloak-dev] SAML token authentication
In-Reply-To: <CADdJyKpDas3Rk=5oeXe1yqW9iVSP4GUymw1-bLuaopBuBzMA8Q@mail.gmail.com>
References: <CADdJyKpDas3Rk=5oeXe1yqW9iVSP4GUymw1-bLuaopBuBzMA8Q@mail.gmail.com>
Message-ID: <CAJgngAdfi55oyMCion5JA0dgTjtAyV-qZtdSjFOUVap=ds2R+A@mail.gmail.com>

Please use the user mailing list for questions. Also, you are using an old
version of Keycloak we no longer support and haven't done for a long time.

On 8 December 2017 at 08:52, Buda, Mikolaj <
mikolaj.buda at contractors.roche.com> wrote:

> Hello,
>
> I would like to debug my local keycloak 1.9.2 instance. I'm looking for the
> class which is responsible for SAML token authentication during log in
> using IDP url. Which class is it?
>
> Best regards,
> Miko?aj
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From sthorger at redhat.com  Fri Dec  8 08:06:48 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 8 Dec 2017 14:06:48 +0100
Subject: [keycloak-dev] Keycloak 3.4.1.Final Released
Message-ID: <CAJgngAf_WJfemqzaG5=qv8B7r=n_-xUnH+E6BbD4RtPGR3R0+w@mail.gmail.com>

We've just released Keycloak 3.4.1.Final.

To download the release go to the Keycloak homepage
<http://www.keycloak.org/downloads>.

The full list of resolved issues is available in JIRA
<https://issues.jboss.org/issues/?jql=project%20%3D%20keycloak%20and%20fixVersion%20%3D%203.4.1.Final>
.
Upgrading

Before you upgrade remember to backup your database and check the upgrade
guide <http://www.keycloak.org/docs/latest/upgrading/index.html> for
anything that may have changed.

From javier.roman-navarrete at daimler.com  Mon Dec 11 03:39:12 2017
From: javier.roman-navarrete at daimler.com (javier.roman-navarrete at daimler.com)
Date: Mon, 11 Dec 2017 08:39:12 +0000
Subject: [keycloak-dev] Skip updateAllTimeStamps of offline sessions on init
Message-ID: <b158d782d51644c691d84e56631492c6@DE36S004EXC1C.wp.corpintra.net>

Upon startup, all offline sessions timestamps are updated (both in the client and user tables). This can be quite time consuming, and we are trying to find out the real purpose of it. There is even a comment on the source code

// TODO: check if update of timestamps in persister can be skipped entirely

That hints it might be superfluous. What would be the downside of avoiding this update?

Regards,

Javier Rom?n Navarrete



If you are not the addressee, please inform us immediately that you have received this e-mail by mistake, and delete it. We thank you for your support.


From mposolda at redhat.com  Mon Dec 11 07:27:24 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 11 Dec 2017 13:27:24 +0100
Subject: [keycloak-dev] Better support authenticationSessions in
 multiple browser tabs
In-Reply-To: <7e6d1466-9634-c483-5750-a5c7d83c83f3@redhat.com>
References: <df2376a1-d9c4-1b41-237b-ffd7ee073e18@redhat.com>
	<CAJgngAd++v1+4wQr+O7AizTDgcfe3nYUJZ5WG+tv+r+d942rnw@mail.gmail.com>
	<7e6d1466-9634-c483-5750-a5c7d83c83f3@redhat.com>
Message-ID: <f696d4a1-b1f0-bf74-7e8e-f048400f0217@redhat.com>

So I've sent PR https://github.com/keycloak/keycloak/pull/4832 for this. 
Now there is support of authenticationSessions in multiple browser tabs. 
Summary of the changes in PR:

- It adds the new parameter "tab_id" to the endpoints Authentication 
Flow endpoints (especially those in LoginActionsService and few in 
IdentityBrokerService).

- AuthenticationSessionModel needs to be looked up by the ID from cookie 
(AUTH_SESSION_ID) together with tab_id and client.

- When application redirects to Keycloak login screen through sending 
request to the OIDC AuthorizationEndpoint or corresponding SAML or 
DockerProtocol authentication endpoint (opening authz endpoint in new 
browser tab), the new Authentication session is always created with new 
tab_id. There is no join existing AuthenticationSessionModel. The cookie 
AUTH_SESSION_ID is still the same. At infinispan level, there is 
RootAuthenticationSessionModel, which represents whole browser and it 
contains list of AuthenticationSessionModel, where every 
authenticationSessionModel represents browser tab.

- All the state of authentication (executions, authNotes, clientNotes) 
is still tracked in AuthenticationSessionModel. So the state is not 
shared among browser tabs.

- The whole RootAuthenticationSession is cleared after login and also 
after logout (In case of logout, there is "helper" AuthenticationSession 
used just during logout to track the logout state of clients among 
multiple redirects from frontchannel-logout clients). The cookie 
AUTH_SESSION_ID is still kept, so sticky session is still preserved and 
the UserSessionModel created after authentication should be available 
locally during SSO logins (or also during backchannel requests from 
javascript clients as those participate in sticky session too).

- The PR fixes those JIRAs and adds automated tests for them:
https://issues.jboss.org/browse/KEYCLOAK-5938 - Support 
authenticationSession for login same client in multiple browser tabs
https://issues.jboss.org/browse/KEYCLOAK-5936 - Use of Back button on 
"Create user from social provider account" leads to Exception
https://issues.jboss.org/browse/KEYCLOAK-5466 - X.509 Auth - cannot 
login after an error
https://issues.jboss.org/browse/KEYCLOAK-6001 - WARNING in the log when 
logout from admin console
https://issues.jboss.org/browse/KEYCLOAK-6012 - Refresh after setting 
VERIFY_ACTION leads to Already authenticated . Thanks Hynek for adding 
automated tests!

- It should also fix:
https://issues.jboss.org/browse/KEYCLOAK-5982 - NPE when logout from 
wordpress OneLogin SAML SSO
https://issues.jboss.org/browse/KEYCLOAK-5981 - Impersonate function not 
working after logout

but need to add the automated tests for those. I hope to send separate 
PRs for it.

WDYT?

Marek

On 29/11/17 15:09, Marek Posolda wrote:
> On 29/11/17 14:44, Stian Thorgersen wrote:
>> I would target this to 3.4.2. I don't want to delay the 3.4.1 release 
>> if we can help it.
>>
>> I'd also suggest some (short if possible) random key (or a counter?!) 
>> rather than relying on protocol specific values. 'state' is not 
>> actually required in OAuth right? It's just recommended.
> Yes, it's not required. And same for SAML. Was wondering about the 
> same. Will use the random key or counter. Thinking if counter doesn't 
> have some corner case issues (EG. If 2 tabs are opened concurrently 
> after logout and will try to use same counter value as authSession 
> update from tab2 won't be yet visible in tab1).
>
> Marek
>>
>> On 29 November 2017 at 13:00, Marek Posolda <mposolda at redhat.com 
>> <mailto:mposolda at redhat.com>> wrote:
>>
>>     I am looking at https://issues.jboss.org/browse/KEYCLOAK-5797
>>     <https://issues.jboss.org/browse/KEYCLOAK-5797> issue now.
>>     It's about the fact, that when user has opened browser with multiple
>>     browser tabs, then after successful login in tab1 (clientA), he
>>     may be
>>     redirected to the incorrect client (clientB, which was opened in
>>     tab2).
>>
>>     The thing is, that authenticationSession was tracked by the
>>     cookie and
>>     didn't support multiple clients. So both browser tabs "tab1" and
>>     "tab2"
>>     used same authenticationSession, which can reference just one of the
>>     clients, hence there could be the conflict and one of the tabs
>>     redirected to incorrect client after authentication.
>>
>>     I am working on a fix, that allow better support for multiple
>>     clients.
>>     What I am doing is, that there is "RootAuthenticationSessionModel",
>>     which is now referenced by the ID from the cookie. That root
>>     session can
>>     reference more actual authentication sessions through the map like
>>     "Map<String, AuthenticationSessionModel>" . The key is the client
>>     UUID.
>>     In the Authentication SPI, there are no changes. Those still use the
>>     AuthenticationSessionModel as before.
>>
>>     This is easily possible as we have "client-id" parameter already
>>     available during authentication flows in every tab. So every
>>     browser tab
>>     can reference correct client and redirect to it.
>>
>>     However even with the fix, there is another corner case about support
>>     for multiple browser tabs with *same* client. This will be still an
>>     issue, especially for the javascript clients. I've created
>>     another JIRA
>>     https://issues.jboss.org/browse/KEYCLOAK-5938
>>     <https://issues.jboss.org/browse/KEYCLOAK-5938> with the example
>>     issue,
>>     which can be simulated with our admin console. To properly support
>>     multiple tabs of same client, the key will need to be like:
>>     "client-id +
>>     state" instead of just "client-id"  The "state" will need to be
>>     either
>>     the OIDC/SAML state or some randomly generated string (As in both the
>>     OAuth2 and SAML, the state/relayState parameter is not mandatory
>>     AFAIK),
>>     which will need to be added to the URL during authentication
>>     flows as well.
>>
>>     Fixing this will take me another few days of work (maybe 2?) as there
>>     will need to be change in many files for adding the new parameter
>>     + some
>>     more authenticationSession model changes etc. So I wonder if we
>>     want to:
>>     1) Fix this in 3.4.1 . Will likely mean to delay the release?
>>     2) Fix this in 3.4.2. It will affect many files and there is some
>>     chance
>>     of regression (hopefully not big as we have lots of the tests for
>>     various other corner cases)
>>     3) Fix this later in 4.X .
>>
>>     My vote is 1 or 2. WDYT? Any other possibility?
>>
>>     Marek
>>
>>     _______________________________________________
>>     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 Dec 11 08:31:08 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 11 Dec 2017 14:31:08 +0100
Subject: [keycloak-dev] Better support authenticationSessions in
 multiple browser tabs
In-Reply-To: <f696d4a1-b1f0-bf74-7e8e-f048400f0217@redhat.com>
References: <df2376a1-d9c4-1b41-237b-ffd7ee073e18@redhat.com>
	<CAJgngAd++v1+4wQr+O7AizTDgcfe3nYUJZ5WG+tv+r+d942rnw@mail.gmail.com>
	<7e6d1466-9634-c483-5750-a5c7d83c83f3@redhat.com>
	<f696d4a1-b1f0-bf74-7e8e-f048400f0217@redhat.com>
Message-ID: <CAJgngAc5BUmtCHGaZVUqci5Bv18fAL_-+T-CBaC028bD4YpJNw@mail.gmail.com>

Looks good to me

On 11 December 2017 at 13:27, Marek Posolda <mposolda at redhat.com> wrote:

> So I've sent PR https://github.com/keycloak/keycloak/pull/4832 for this.
> Now there is support of authenticationSessions in multiple browser tabs.
> Summary of the changes in PR:
>
> - It adds the new parameter "tab_id" to the endpoints Authentication Flow
> endpoints (especially those in LoginActionsService and few in
> IdentityBrokerService).
>
> - AuthenticationSessionModel needs to be looked up by the ID from cookie
> (AUTH_SESSION_ID) together with tab_id and client.
>
> - When application redirects to Keycloak login screen through sending
> request to the OIDC AuthorizationEndpoint or corresponding SAML or
> DockerProtocol authentication endpoint (opening authz endpoint in new
> browser tab), the new Authentication session is always created with new
> tab_id. There is no join existing AuthenticationSessionModel. The cookie
> AUTH_SESSION_ID is still the same. At infinispan level, there is
> RootAuthenticationSessionModel, which represents whole browser and it
> contains list of AuthenticationSessionModel, where every
> authenticationSessionModel represents browser tab.
>
> - All the state of authentication (executions, authNotes, clientNotes) is
> still tracked in AuthenticationSessionModel. So the state is not shared
> among browser tabs.
>
> - The whole RootAuthenticationSession is cleared after login and also
> after logout (In case of logout, there is "helper" AuthenticationSession
> used just during logout to track the logout state of clients among multiple
> redirects from frontchannel-logout clients). The cookie AUTH_SESSION_ID is
> still kept, so sticky session is still preserved and the UserSessionModel
> created after authentication should be available locally during SSO logins
> (or also during backchannel requests from javascript clients as those
> participate in sticky session too).
>
> - The PR fixes those JIRAs and adds automated tests for them:
> https://issues.jboss.org/browse/KEYCLOAK-5938 - Support
> authenticationSession for login same client in multiple browser tabs
> https://issues.jboss.org/browse/KEYCLOAK-5936 - Use of Back button on
> "Create user from social provider account" leads to Exception
> https://issues.jboss.org/browse/KEYCLOAK-5466 - X.509 Auth - cannot login
> after an error
> https://issues.jboss.org/browse/KEYCLOAK-6001 - WARNING in the log when
> logout from admin console
> https://issues.jboss.org/browse/KEYCLOAK-6012 - Refresh after setting
> VERIFY_ACTION leads to Already authenticated . Thanks Hynek for adding
> automated tests!
>
> - It should also fix:
> https://issues.jboss.org/browse/KEYCLOAK-5982 - NPE when logout from
> wordpress OneLogin SAML SSO
> https://issues.jboss.org/browse/KEYCLOAK-5981 - Impersonate function not
> working after logout
>
> but need to add the automated tests for those. I hope to send separate PRs
> for it.
>
> WDYT?
>
> Marek
>
>
> On 29/11/17 15:09, Marek Posolda wrote:
>
> On 29/11/17 14:44, Stian Thorgersen wrote:
>
> I would target this to 3.4.2. I don't want to delay the 3.4.1 release if
> we can help it.
>
> I'd also suggest some (short if possible) random key (or a counter?!)
> rather than relying on protocol specific values. 'state' is not actually
> required in OAuth right? It's just recommended.
>
> Yes, it's not required. And same for SAML. Was wondering about the same.
> Will use the random key or counter. Thinking if counter doesn't have some
> corner case issues (EG. If 2 tabs are opened concurrently after logout and
> will try to use same counter value as authSession update from tab2 won't be
> yet visible in tab1).
>
> Marek
>
>
> On 29 November 2017 at 13:00, Marek Posolda <mposolda at redhat.com> wrote:
>
>> I am looking at https://issues.jboss.org/browse/KEYCLOAK-5797 issue now.
>> It's about the fact, that when user has opened browser with multiple
>> browser tabs, then after successful login in tab1 (clientA), he may be
>> redirected to the incorrect client (clientB, which was opened in tab2).
>>
>> The thing is, that authenticationSession was tracked by the cookie and
>> didn't support multiple clients. So both browser tabs "tab1" and "tab2"
>> used same authenticationSession, which can reference just one of the
>> clients, hence there could be the conflict and one of the tabs
>> redirected to incorrect client after authentication.
>>
>> I am working on a fix, that allow better support for multiple clients.
>> What I am doing is, that there is "RootAuthenticationSessionModel",
>> which is now referenced by the ID from the cookie. That root session can
>> reference more actual authentication sessions through the map like
>> "Map<String, AuthenticationSessionModel>" . The key is the client UUID.
>> In the Authentication SPI, there are no changes. Those still use the
>> AuthenticationSessionModel as before.
>>
>> This is easily possible as we have "client-id" parameter already
>> available during authentication flows in every tab. So every browser tab
>> can reference correct client and redirect to it.
>>
>> However even with the fix, there is another corner case about support
>> for multiple browser tabs with *same* client. This will be still an
>> issue, especially for the javascript clients. I've created another JIRA
>> https://issues.jboss.org/browse/KEYCLOAK-5938 with the example issue,
>> which can be simulated with our admin console. To properly support
>> multiple tabs of same client, the key will need to be like: "client-id +
>> state" instead of just "client-id"  The "state" will need to be either
>> the OIDC/SAML state or some randomly generated string (As in both the
>> OAuth2 and SAML, the state/relayState parameter is not mandatory AFAIK),
>> which will need to be added to the URL during authentication flows as
>> well.
>>
>> Fixing this will take me another few days of work (maybe 2?) as there
>> will need to be change in many files for adding the new parameter + some
>> more authenticationSession model changes etc. So I wonder if we want to:
>> 1) Fix this in 3.4.1 . Will likely mean to delay the release?
>> 2) Fix this in 3.4.2. It will affect many files and there is some chance
>> of regression (hopefully not big as we have lots of the tests for
>> various other corner cases)
>> 3) Fix this later in 4.X .
>>
>> My vote is 1 or 2. WDYT? Any other possibility?
>>
>> Marek
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
>
>

From bburke at redhat.com  Mon Dec 11 09:54:41 2017
From: bburke at redhat.com (Bill Burke)
Date: Mon, 11 Dec 2017 09:54:41 -0500
Subject: [keycloak-dev] Better support authenticationSessions in
 multiple browser tabs
In-Reply-To: <CAJgngAfzALbsmshoHZ4JtSRNuMpB9X0r2N-rgZDigj=ToAB1tw@mail.gmail.com>
References: <df2376a1-d9c4-1b41-237b-ffd7ee073e18@redhat.com>
	<CAJgngAd++v1+4wQr+O7AizTDgcfe3nYUJZ5WG+tv+r+d942rnw@mail.gmail.com>
	<7e6d1466-9634-c483-5750-a5c7d83c83f3@redhat.com>
	<CABRXCmz78dM=tdA+-wycHWLf476NQfsWJ20kexF5Lq=b82Qwhg@mail.gmail.com>
	<CAJgngAfzALbsmshoHZ4JtSRNuMpB9X0r2N-rgZDigj=ToAB1tw@mail.gmail.com>
Message-ID: <CABRXCmxNQ4z+JLtD6mk6Pt9XjwQ468va7VPi68mb_op9NR7taw@mail.gmail.com>

On Mon, Dec 4, 2017 at 2:56 AM, Stian Thorgersen <sthorger at redhat.com> wrote:
>
>
> On 1 December 2017 at 14:53, Bill Burke <bburke at redhat.com> wrote:
>>
>> On Wed, Nov 29, 2017 at 9:09 AM, Marek Posolda <mposolda at redhat.com>
>> wrote:
>> > On 29/11/17 14:44, Stian Thorgersen wrote:
>> >> I would target this to 3.4.2. I don't want to delay the 3.4.1 release
>> >> if we can help it.
>> >>
>> >> I'd also suggest some (short if possible) random key (or a counter?!)
>> >> rather than relying on protocol specific values. 'state' is not
>> >> actually required in OAuth right? It's just recommended.
>> > Yes, it's not required. And same for SAML. Was wondering about the same.
>> > Will use the random key or counter. Thinking if counter doesn't have
>> > some corner case issues (EG. If 2 tabs are opened concurrently after
>> > logout and will try to use same counter value as authSession update from
>> > tab2 won't be yet visible in tab1).
>> >
>>
>> the "state" parameter IS required.  Its how the client can figure out
>> that it initiated the login or not.
>
>
> https://tools.ietf.org/html/rfc6749#section-4.1.1
>
> It's RECOMMENDED
>

You don't remove a recommended aspect of a protocol just because its
inconvenient to you.

>>
>>
>> I don't understand your solution...BTW, going back to auth_session_id
>> within the URL instead of a cookie like we used to do would fix this
>> too :).  If you're already going to add a "client-id" query parameter,
>> why not just revert back to the old way of doing this?
>
>
> Cookie solves a lot of issues. Can't remember the details of all of them,
> but these have been discussed several times on the mailing list this year.
>

Yeah, I don't remember either and I'd have to dig through emails to
find it.  I do remember there were "back button" issues since we
changed the session id every request.


-- 
Bill Burke
Red Hat

From john.d.ament at gmail.com  Mon Dec 11 10:00:42 2017
From: john.d.ament at gmail.com (John D. Ament)
Date: Mon, 11 Dec 2017 15:00:42 +0000
Subject: [keycloak-dev] Keycloak Realm Count Upper Limit
Message-ID: <CAOqetn-zDmKQAx9-UmPVo+ZazSy=5e5100APu3cdp0qWZFPQBQ@mail.gmail.com>

We did some capacity and stress testing on keycloak recently.  One of the
tests was to identify a breaking point for the realm count that would
result in the system breaking.  We identified that once Keycloak hits 470
realms, regardless of scaling up the box and having caching enabled,
Keycloak simply becomes unusable.

Right now, this is a higher number than we need, but wanted to see if there
are any plans or enhancements to look at in newer versions to see if we
should test differently?  We're on Keycloak 3.2 presently.

John

From bburke at redhat.com  Mon Dec 11 10:18:17 2017
From: bburke at redhat.com (Bill Burke)
Date: Mon, 11 Dec 2017 10:18:17 -0500
Subject: [keycloak-dev] Better support authenticationSessions in
 multiple browser tabs
In-Reply-To: <f696d4a1-b1f0-bf74-7e8e-f048400f0217@redhat.com>
References: <df2376a1-d9c4-1b41-237b-ffd7ee073e18@redhat.com>
	<CAJgngAd++v1+4wQr+O7AizTDgcfe3nYUJZ5WG+tv+r+d942rnw@mail.gmail.com>
	<7e6d1466-9634-c483-5750-a5c7d83c83f3@redhat.com>
	<f696d4a1-b1f0-bf74-7e8e-f048400f0217@redhat.com>
Message-ID: <CABRXCmz0=+M7uvTfXJt5Z2JgbSWkUCrTvf9S4LzED82udmDWsA@mail.gmail.com>

I feel a bit better that state is no longer shared between tabs and
you're cleaning up auth sessions.

Still worried though as I still don't fully understand how it works.
I also worry that a lot of different areas of the codebase needed to
be touched to fix these problems.  This probably needs another
refactoring pass to consolidate code and create a better abstraction
so that if we need to change things its done in one place.  I know I'm
being vague here, by my intuition and experience is telling me things
need to be cleaned up....Unfortunately there's a lot of areas in our
codebase like this (many which originated from me), and we're
overloaded with work.  Hopefully one day we get back to this.

On Mon, Dec 11, 2017 at 7:27 AM, Marek Posolda <mposolda at redhat.com> wrote:
> So I've sent PR https://github.com/keycloak/keycloak/pull/4832 for this.
> Now there is support of authenticationSessions in multiple browser tabs.
> Summary of the changes in PR:
>
> - It adds the new parameter "tab_id" to the endpoints Authentication
> Flow endpoints (especially those in LoginActionsService and few in
> IdentityBrokerService).
>
> - AuthenticationSessionModel needs to be looked up by the ID from cookie
> (AUTH_SESSION_ID) together with tab_id and client.
>
> - When application redirects to Keycloak login screen through sending
> request to the OIDC AuthorizationEndpoint or corresponding SAML or
> DockerProtocol authentication endpoint (opening authz endpoint in new
> browser tab), the new Authentication session is always created with new
> tab_id. There is no join existing AuthenticationSessionModel. The cookie
> AUTH_SESSION_ID is still the same. At infinispan level, there is
> RootAuthenticationSessionModel, which represents whole browser and it
> contains list of AuthenticationSessionModel, where every
> authenticationSessionModel represents browser tab.
>
> - All the state of authentication (executions, authNotes, clientNotes)
> is still tracked in AuthenticationSessionModel. So the state is not
> shared among browser tabs.
>
> - The whole RootAuthenticationSession is cleared after login and also
> after logout (In case of logout, there is "helper" AuthenticationSession
> used just during logout to track the logout state of clients among
> multiple redirects from frontchannel-logout clients). The cookie
> AUTH_SESSION_ID is still kept, so sticky session is still preserved and
> the UserSessionModel created after authentication should be available
> locally during SSO logins (or also during backchannel requests from
> javascript clients as those participate in sticky session too).
>
> - The PR fixes those JIRAs and adds automated tests for them:
> https://issues.jboss.org/browse/KEYCLOAK-5938 - Support
> authenticationSession for login same client in multiple browser tabs
> https://issues.jboss.org/browse/KEYCLOAK-5936 - Use of Back button on
> "Create user from social provider account" leads to Exception
> https://issues.jboss.org/browse/KEYCLOAK-5466 - X.509 Auth - cannot
> login after an error
> https://issues.jboss.org/browse/KEYCLOAK-6001 - WARNING in the log when
> logout from admin console
> https://issues.jboss.org/browse/KEYCLOAK-6012 - Refresh after setting
> VERIFY_ACTION leads to Already authenticated . Thanks Hynek for adding
> automated tests!
>
> - It should also fix:
> https://issues.jboss.org/browse/KEYCLOAK-5982 - NPE when logout from
> wordpress OneLogin SAML SSO
> https://issues.jboss.org/browse/KEYCLOAK-5981 - Impersonate function not
> working after logout
>
> but need to add the automated tests for those. I hope to send separate
> PRs for it.
>
> WDYT?
>
> Marek
>
> On 29/11/17 15:09, Marek Posolda wrote:
>> On 29/11/17 14:44, Stian Thorgersen wrote:
>>> I would target this to 3.4.2. I don't want to delay the 3.4.1 release
>>> if we can help it.
>>>
>>> I'd also suggest some (short if possible) random key (or a counter?!)
>>> rather than relying on protocol specific values. 'state' is not
>>> actually required in OAuth right? It's just recommended.
>> Yes, it's not required. And same for SAML. Was wondering about the
>> same. Will use the random key or counter. Thinking if counter doesn't
>> have some corner case issues (EG. If 2 tabs are opened concurrently
>> after logout and will try to use same counter value as authSession
>> update from tab2 won't be yet visible in tab1).
>>
>> Marek
>>>
>>> On 29 November 2017 at 13:00, Marek Posolda <mposolda at redhat.com
>>> <mailto:mposolda at redhat.com>> wrote:
>>>
>>>     I am looking at https://issues.jboss.org/browse/KEYCLOAK-5797
>>>     <https://issues.jboss.org/browse/KEYCLOAK-5797> issue now.
>>>     It's about the fact, that when user has opened browser with multiple
>>>     browser tabs, then after successful login in tab1 (clientA), he
>>>     may be
>>>     redirected to the incorrect client (clientB, which was opened in
>>>     tab2).
>>>
>>>     The thing is, that authenticationSession was tracked by the
>>>     cookie and
>>>     didn't support multiple clients. So both browser tabs "tab1" and
>>>     "tab2"
>>>     used same authenticationSession, which can reference just one of the
>>>     clients, hence there could be the conflict and one of the tabs
>>>     redirected to incorrect client after authentication.
>>>
>>>     I am working on a fix, that allow better support for multiple
>>>     clients.
>>>     What I am doing is, that there is "RootAuthenticationSessionModel",
>>>     which is now referenced by the ID from the cookie. That root
>>>     session can
>>>     reference more actual authentication sessions through the map like
>>>     "Map<String, AuthenticationSessionModel>" . The key is the client
>>>     UUID.
>>>     In the Authentication SPI, there are no changes. Those still use the
>>>     AuthenticationSessionModel as before.
>>>
>>>     This is easily possible as we have "client-id" parameter already
>>>     available during authentication flows in every tab. So every
>>>     browser tab
>>>     can reference correct client and redirect to it.
>>>
>>>     However even with the fix, there is another corner case about support
>>>     for multiple browser tabs with *same* client. This will be still an
>>>     issue, especially for the javascript clients. I've created
>>>     another JIRA
>>>     https://issues.jboss.org/browse/KEYCLOAK-5938
>>>     <https://issues.jboss.org/browse/KEYCLOAK-5938> with the example
>>>     issue,
>>>     which can be simulated with our admin console. To properly support
>>>     multiple tabs of same client, the key will need to be like:
>>>     "client-id +
>>>     state" instead of just "client-id"  The "state" will need to be
>>>     either
>>>     the OIDC/SAML state or some randomly generated string (As in both the
>>>     OAuth2 and SAML, the state/relayState parameter is not mandatory
>>>     AFAIK),
>>>     which will need to be added to the URL during authentication
>>>     flows as well.
>>>
>>>     Fixing this will take me another few days of work (maybe 2?) as there
>>>     will need to be change in many files for adding the new parameter
>>>     + some
>>>     more authenticationSession model changes etc. So I wonder if we
>>>     want to:
>>>     1) Fix this in 3.4.1 . Will likely mean to delay the release?
>>>     2) Fix this in 3.4.2. It will affect many files and there is some
>>>     chance
>>>     of regression (hopefully not big as we have lots of the tests for
>>>     various other corner cases)
>>>     3) Fix this later in 4.X .
>>>
>>>     My vote is 1 or 2. WDYT? Any other possibility?
>>>
>>>     Marek
>>>
>>>     _______________________________________________
>>>     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  Mon Dec 11 10:22:46 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 11 Dec 2017 16:22:46 +0100
Subject: [keycloak-dev] Better support authenticationSessions in
 multiple browser tabs
In-Reply-To: <CABRXCmxNQ4z+JLtD6mk6Pt9XjwQ468va7VPi68mb_op9NR7taw@mail.gmail.com>
References: <df2376a1-d9c4-1b41-237b-ffd7ee073e18@redhat.com>
	<CAJgngAd++v1+4wQr+O7AizTDgcfe3nYUJZ5WG+tv+r+d942rnw@mail.gmail.com>
	<7e6d1466-9634-c483-5750-a5c7d83c83f3@redhat.com>
	<CABRXCmz78dM=tdA+-wycHWLf476NQfsWJ20kexF5Lq=b82Qwhg@mail.gmail.com>
	<CAJgngAfzALbsmshoHZ4JtSRNuMpB9X0r2N-rgZDigj=ToAB1tw@mail.gmail.com>
	<CABRXCmxNQ4z+JLtD6mk6Pt9XjwQ468va7VPi68mb_op9NR7taw@mail.gmail.com>
Message-ID: <0203aaad-2dd5-677c-9abe-888e3e5deb5d@redhat.com>

On 11/12/17 15:54, Bill Burke wrote:
> On Mon, Dec 4, 2017 at 2:56 AM, Stian Thorgersen <sthorger at redhat.com> wrote:
>>
>> On 1 December 2017 at 14:53, Bill Burke <bburke at redhat.com> wrote:
>>> On Wed, Nov 29, 2017 at 9:09 AM, Marek Posolda <mposolda at redhat.com>
>>> wrote:
>>>> On 29/11/17 14:44, Stian Thorgersen wrote:
>>>>> I would target this to 3.4.2. I don't want to delay the 3.4.1 release
>>>>> if we can help it.
>>>>>
>>>>> I'd also suggest some (short if possible) random key (or a counter?!)
>>>>> rather than relying on protocol specific values. 'state' is not
>>>>> actually required in OAuth right? It's just recommended.
>>>> Yes, it's not required. And same for SAML. Was wondering about the same.
>>>> Will use the random key or counter. Thinking if counter doesn't have
>>>> some corner case issues (EG. If 2 tabs are opened concurrently after
>>>> logout and will try to use same counter value as authSession update from
>>>> tab2 won't be yet visible in tab1).
>>>>
>>> the "state" parameter IS required.  Its how the client can figure out
>>> that it initiated the login or not.
>>
>> https://tools.ietf.org/html/rfc6749#section-4.1.1
>>
>> It's RECOMMENDED
>>
> You don't remove a recommended aspect of a protocol just because its
> inconvenient to you.

AFAIK Keycloak needs to integrate with 3rd party OIDC adapters and SAML 
adapters. For our own adapters, we control everything, so we can make 
sure that "state" parameter is always send by the adapter. But for 3rd 
party adapters, we can't rely on the fact that "state" parameter is 
available in initial OIDC AuthorizationEndpoint request due the fact 
that it's just RECOMMENDED. So we can't reliably use "state" as the 
identificator of the authenticationSession tab_id (or anything else on 
the server) as it would be null in some cases. So we rather generate 
some other random ID to reference authSession.

So this is not about removing any aspects of the protocol, but rather 
the opposite - make sure that things work regardless if "state" is or 
isn't available. Or did I just misunderstood what you meant?

Marek
>
>>>
>>> I don't understand your solution...BTW, going back to auth_session_id
>>> within the URL instead of a cookie like we used to do would fix this
>>> too :).  If you're already going to add a "client-id" query parameter,
>>> why not just revert back to the old way of doing this?
>>
>> Cookie solves a lot of issues. Can't remember the details of all of them,
>> but these have been discussed several times on the mailing list this year.
>>
> Yeah, I don't remember either and I'd have to dig through emails to
> find it.  I do remember there were "back button" issues since we
> changed the session id every request.
>
>


From bburke at redhat.com  Mon Dec 11 10:24:52 2017
From: bburke at redhat.com (Bill Burke)
Date: Mon, 11 Dec 2017 10:24:52 -0500
Subject: [keycloak-dev] Better support authenticationSessions in
 multiple browser tabs
In-Reply-To: <0203aaad-2dd5-677c-9abe-888e3e5deb5d@redhat.com>
References: <df2376a1-d9c4-1b41-237b-ffd7ee073e18@redhat.com>
	<CAJgngAd++v1+4wQr+O7AizTDgcfe3nYUJZ5WG+tv+r+d942rnw@mail.gmail.com>
	<7e6d1466-9634-c483-5750-a5c7d83c83f3@redhat.com>
	<CABRXCmz78dM=tdA+-wycHWLf476NQfsWJ20kexF5Lq=b82Qwhg@mail.gmail.com>
	<CAJgngAfzALbsmshoHZ4JtSRNuMpB9X0r2N-rgZDigj=ToAB1tw@mail.gmail.com>
	<CABRXCmxNQ4z+JLtD6mk6Pt9XjwQ468va7VPi68mb_op9NR7taw@mail.gmail.com>
	<0203aaad-2dd5-677c-9abe-888e3e5deb5d@redhat.com>
Message-ID: <CABRXCmxFv=JscgbBNTc0onXYAwx_dQXPT7=S2sZaSEYQ+3CSgg@mail.gmail.com>

On Mon, Dec 11, 2017 at 10:22 AM, Marek Posolda <mposolda at redhat.com> wrote:
> On 11/12/17 15:54, Bill Burke wrote:
>>
>> On Mon, Dec 4, 2017 at 2:56 AM, Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>>>
>>>
>>> On 1 December 2017 at 14:53, Bill Burke <bburke at redhat.com> wrote:
>>>>
>>>> On Wed, Nov 29, 2017 at 9:09 AM, Marek Posolda <mposolda at redhat.com>
>>>> wrote:
>>>>>
>>>>> On 29/11/17 14:44, Stian Thorgersen wrote:
>>>>>>
>>>>>> I would target this to 3.4.2. I don't want to delay the 3.4.1 release
>>>>>> if we can help it.
>>>>>>
>>>>>> I'd also suggest some (short if possible) random key (or a counter?!)
>>>>>> rather than relying on protocol specific values. 'state' is not
>>>>>> actually required in OAuth right? It's just recommended.
>>>>>
>>>>> Yes, it's not required. And same for SAML. Was wondering about the
>>>>> same.
>>>>> Will use the random key or counter. Thinking if counter doesn't have
>>>>> some corner case issues (EG. If 2 tabs are opened concurrently after
>>>>> logout and will try to use same counter value as authSession update
>>>>> from
>>>>> tab2 won't be yet visible in tab1).
>>>>>
>>>> the "state" parameter IS required.  Its how the client can figure out
>>>> that it initiated the login or not.
>>>
>>>
>>> https://tools.ietf.org/html/rfc6749#section-4.1.1
>>>
>>> It's RECOMMENDED
>>>
>> You don't remove a recommended aspect of a protocol just because its
>> inconvenient to you.
>
>
> AFAIK Keycloak needs to integrate with 3rd party OIDC adapters and SAML
> adapters. For our own adapters, we control everything, so we can make sure
> that "state" parameter is always send by the adapter. But for 3rd party
> adapters, we can't rely on the fact that "state" parameter is available in
> initial OIDC AuthorizationEndpoint request due the fact that it's just
> RECOMMENDED. So we can't reliably use "state" as the identificator of the
> authenticationSession tab_id (or anything else on the server) as it would be
> null in some cases. So we rather generate some other random ID to reference
> authSession.
>
> So this is not about removing any aspects of the protocol, but rather the
> opposite - make sure that things work regardless if "state" is or isn't
> available. Or did I just misunderstood what you meant?
>

I misunderstood before what was going on with State parameter.  I
thought you were talking about removing it.



-- 
Bill Burke
Red Hat

From mposolda at redhat.com  Mon Dec 11 10:42:11 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 11 Dec 2017 16:42:11 +0100
Subject: [keycloak-dev] Better support authenticationSessions in
 multiple browser tabs
In-Reply-To: <CABRXCmz0=+M7uvTfXJt5Z2JgbSWkUCrTvf9S4LzED82udmDWsA@mail.gmail.com>
References: <df2376a1-d9c4-1b41-237b-ffd7ee073e18@redhat.com>
	<CAJgngAd++v1+4wQr+O7AizTDgcfe3nYUJZ5WG+tv+r+d942rnw@mail.gmail.com>
	<7e6d1466-9634-c483-5750-a5c7d83c83f3@redhat.com>
	<f696d4a1-b1f0-bf74-7e8e-f048400f0217@redhat.com>
	<CABRXCmz0=+M7uvTfXJt5Z2JgbSWkUCrTvf9S4LzED82udmDWsA@mail.gmail.com>
Message-ID: <5fc76ef0-7250-0cab-1da5-c3c159aa1fa0@redhat.com>

On 11/12/17 16:18, Bill Burke wrote:
> I feel a bit better that state is no longer shared between tabs and
> you're cleaning up auth sessions.
>
> Still worried though as I still don't fully understand how it works.
> I also worry that a lot of different areas of the codebase needed to
> be touched to fix these problems.  This probably needs another
> refactoring pass to consolidate code and create a better abstraction
> so that if we need to change things its done in one place.  I know I'm
> being vague here, by my intuition and experience is telling me things
> need to be cleaned up....Unfortunately there's a lot of areas in our
> codebase like this (many which originated from me), and we're
> overloaded with work.  Hopefully one day we get back to this.
+1

For example, we have many endpoints on LoginActionsService for different 
flows. Maybe we can consolidate it into one method and just add 
"flow_id" or "flow_type" as parameter? In the end, most of the endpoints 
are processed in LoginActionsService.processFlow where is the 
authentication flow actually triggered. There are some specifics to each 
endpoint, but hopefully they can be abstractized somehow.

Due to the many different endpoints, we also have quite a lot of places 
where the URL for the flow needs to be build...

Good thing is, that we have lots of automated tests and we're adding new 
tests for bugfixes. So every refactoring minimizes risk of regression. 
Still the issue is, that not all tests are executed during PR, so there 
is a risk that regressions are found later. I hope this will be improved 
once we have CI triggered for every PR. Then also refactorings will be a 
bit safer then now. Hopefully... :)

Marek

>
> On Mon, Dec 11, 2017 at 7:27 AM, Marek Posolda <mposolda at redhat.com> wrote:
>> So I've sent PR https://github.com/keycloak/keycloak/pull/4832 for this.
>> Now there is support of authenticationSessions in multiple browser tabs.
>> Summary of the changes in PR:
>>
>> - It adds the new parameter "tab_id" to the endpoints Authentication
>> Flow endpoints (especially those in LoginActionsService and few in
>> IdentityBrokerService).
>>
>> - AuthenticationSessionModel needs to be looked up by the ID from cookie
>> (AUTH_SESSION_ID) together with tab_id and client.
>>
>> - When application redirects to Keycloak login screen through sending
>> request to the OIDC AuthorizationEndpoint or corresponding SAML or
>> DockerProtocol authentication endpoint (opening authz endpoint in new
>> browser tab), the new Authentication session is always created with new
>> tab_id. There is no join existing AuthenticationSessionModel. The cookie
>> AUTH_SESSION_ID is still the same. At infinispan level, there is
>> RootAuthenticationSessionModel, which represents whole browser and it
>> contains list of AuthenticationSessionModel, where every
>> authenticationSessionModel represents browser tab.
>>
>> - All the state of authentication (executions, authNotes, clientNotes)
>> is still tracked in AuthenticationSessionModel. So the state is not
>> shared among browser tabs.
>>
>> - The whole RootAuthenticationSession is cleared after login and also
>> after logout (In case of logout, there is "helper" AuthenticationSession
>> used just during logout to track the logout state of clients among
>> multiple redirects from frontchannel-logout clients). The cookie
>> AUTH_SESSION_ID is still kept, so sticky session is still preserved and
>> the UserSessionModel created after authentication should be available
>> locally during SSO logins (or also during backchannel requests from
>> javascript clients as those participate in sticky session too).
>>
>> - The PR fixes those JIRAs and adds automated tests for them:
>> https://issues.jboss.org/browse/KEYCLOAK-5938 - Support
>> authenticationSession for login same client in multiple browser tabs
>> https://issues.jboss.org/browse/KEYCLOAK-5936 - Use of Back button on
>> "Create user from social provider account" leads to Exception
>> https://issues.jboss.org/browse/KEYCLOAK-5466 - X.509 Auth - cannot
>> login after an error
>> https://issues.jboss.org/browse/KEYCLOAK-6001 - WARNING in the log when
>> logout from admin console
>> https://issues.jboss.org/browse/KEYCLOAK-6012 - Refresh after setting
>> VERIFY_ACTION leads to Already authenticated . Thanks Hynek for adding
>> automated tests!
>>
>> - It should also fix:
>> https://issues.jboss.org/browse/KEYCLOAK-5982 - NPE when logout from
>> wordpress OneLogin SAML SSO
>> https://issues.jboss.org/browse/KEYCLOAK-5981 - Impersonate function not
>> working after logout
>>
>> but need to add the automated tests for those. I hope to send separate
>> PRs for it.
>>
>> WDYT?
>>
>> Marek
>>
>> On 29/11/17 15:09, Marek Posolda wrote:
>>> On 29/11/17 14:44, Stian Thorgersen wrote:
>>>> I would target this to 3.4.2. I don't want to delay the 3.4.1 release
>>>> if we can help it.
>>>>
>>>> I'd also suggest some (short if possible) random key (or a counter?!)
>>>> rather than relying on protocol specific values. 'state' is not
>>>> actually required in OAuth right? It's just recommended.
>>> Yes, it's not required. And same for SAML. Was wondering about the
>>> same. Will use the random key or counter. Thinking if counter doesn't
>>> have some corner case issues (EG. If 2 tabs are opened concurrently
>>> after logout and will try to use same counter value as authSession
>>> update from tab2 won't be yet visible in tab1).
>>>
>>> Marek
>>>> On 29 November 2017 at 13:00, Marek Posolda <mposolda at redhat.com
>>>> <mailto:mposolda at redhat.com>> wrote:
>>>>
>>>>      I am looking at https://issues.jboss.org/browse/KEYCLOAK-5797
>>>>      <https://issues.jboss.org/browse/KEYCLOAK-5797> issue now.
>>>>      It's about the fact, that when user has opened browser with multiple
>>>>      browser tabs, then after successful login in tab1 (clientA), he
>>>>      may be
>>>>      redirected to the incorrect client (clientB, which was opened in
>>>>      tab2).
>>>>
>>>>      The thing is, that authenticationSession was tracked by the
>>>>      cookie and
>>>>      didn't support multiple clients. So both browser tabs "tab1" and
>>>>      "tab2"
>>>>      used same authenticationSession, which can reference just one of the
>>>>      clients, hence there could be the conflict and one of the tabs
>>>>      redirected to incorrect client after authentication.
>>>>
>>>>      I am working on a fix, that allow better support for multiple
>>>>      clients.
>>>>      What I am doing is, that there is "RootAuthenticationSessionModel",
>>>>      which is now referenced by the ID from the cookie. That root
>>>>      session can
>>>>      reference more actual authentication sessions through the map like
>>>>      "Map<String, AuthenticationSessionModel>" . The key is the client
>>>>      UUID.
>>>>      In the Authentication SPI, there are no changes. Those still use the
>>>>      AuthenticationSessionModel as before.
>>>>
>>>>      This is easily possible as we have "client-id" parameter already
>>>>      available during authentication flows in every tab. So every
>>>>      browser tab
>>>>      can reference correct client and redirect to it.
>>>>
>>>>      However even with the fix, there is another corner case about support
>>>>      for multiple browser tabs with *same* client. This will be still an
>>>>      issue, especially for the javascript clients. I've created
>>>>      another JIRA
>>>>      https://issues.jboss.org/browse/KEYCLOAK-5938
>>>>      <https://issues.jboss.org/browse/KEYCLOAK-5938> with the example
>>>>      issue,
>>>>      which can be simulated with our admin console. To properly support
>>>>      multiple tabs of same client, the key will need to be like:
>>>>      "client-id +
>>>>      state" instead of just "client-id"  The "state" will need to be
>>>>      either
>>>>      the OIDC/SAML state or some randomly generated string (As in both the
>>>>      OAuth2 and SAML, the state/relayState parameter is not mandatory
>>>>      AFAIK),
>>>>      which will need to be added to the URL during authentication
>>>>      flows as well.
>>>>
>>>>      Fixing this will take me another few days of work (maybe 2?) as there
>>>>      will need to be change in many files for adding the new parameter
>>>>      + some
>>>>      more authenticationSession model changes etc. So I wonder if we
>>>>      want to:
>>>>      1) Fix this in 3.4.1 . Will likely mean to delay the release?
>>>>      2) Fix this in 3.4.2. It will affect many files and there is some
>>>>      chance
>>>>      of regression (hopefully not big as we have lots of the tests for
>>>>      various other corner cases)
>>>>      3) Fix this later in 4.X .
>>>>
>>>>      My vote is 1 or 2. WDYT? Any other possibility?
>>>>
>>>>      Marek
>>>>
>>>>      _______________________________________________
>>>>      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  Mon Dec 11 13:35:50 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 11 Dec 2017 19:35:50 +0100
Subject: [keycloak-dev] Better support authenticationSessions in
 multiple browser tabs
In-Reply-To: <CABRXCmxNQ4z+JLtD6mk6Pt9XjwQ468va7VPi68mb_op9NR7taw@mail.gmail.com>
References: <df2376a1-d9c4-1b41-237b-ffd7ee073e18@redhat.com>
	<CAJgngAd++v1+4wQr+O7AizTDgcfe3nYUJZ5WG+tv+r+d942rnw@mail.gmail.com>
	<7e6d1466-9634-c483-5750-a5c7d83c83f3@redhat.com>
	<CABRXCmz78dM=tdA+-wycHWLf476NQfsWJ20kexF5Lq=b82Qwhg@mail.gmail.com>
	<CAJgngAfzALbsmshoHZ4JtSRNuMpB9X0r2N-rgZDigj=ToAB1tw@mail.gmail.com>
	<CABRXCmxNQ4z+JLtD6mk6Pt9XjwQ468va7VPi68mb_op9NR7taw@mail.gmail.com>
Message-ID: <CAJgngAd7cpn7S8ZpettmBk2eVmM9-5Hhpq5nDJpmTiAtRFGhzA@mail.gmail.com>

On 11 December 2017 at 15:54, Bill Burke <bburke at redhat.com> wrote:

> On Mon, Dec 4, 2017 at 2:56 AM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
> >
> >
> > On 1 December 2017 at 14:53, Bill Burke <bburke at redhat.com> wrote:
> >>
> >> On Wed, Nov 29, 2017 at 9:09 AM, Marek Posolda <mposolda at redhat.com>
> >> wrote:
> >> > On 29/11/17 14:44, Stian Thorgersen wrote:
> >> >> I would target this to 3.4.2. I don't want to delay the 3.4.1 release
> >> >> if we can help it.
> >> >>
> >> >> I'd also suggest some (short if possible) random key (or a counter?!)
> >> >> rather than relying on protocol specific values. 'state' is not
> >> >> actually required in OAuth right? It's just recommended.
> >> > Yes, it's not required. And same for SAML. Was wondering about the
> same.
> >> > Will use the random key or counter. Thinking if counter doesn't have
> >> > some corner case issues (EG. If 2 tabs are opened concurrently after
> >> > logout and will try to use same counter value as authSession update
> from
> >> > tab2 won't be yet visible in tab1).
> >> >
> >>
> >> the "state" parameter IS required.  Its how the client can figure out
> >> that it initiated the login or not.
> >
> >
> > https://tools.ietf.org/html/rfc6749#section-4.1.1
> >
> > It's RECOMMENDED
> >
>
> You don't remove a recommended aspect of a protocol just because its
> inconvenient to you.
>

I've got no clue what you're saying here. I was saying we can't use the
"state" variable as an unique identifier for a client session as per the
spec it is recommended, not required. Hence we don't know it's always there.


>
> >>
> >>
> >> I don't understand your solution...BTW, going back to auth_session_id
> >> within the URL instead of a cookie like we used to do would fix this
> >> too :).  If you're already going to add a "client-id" query parameter,
> >> why not just revert back to the old way of doing this?
> >
> >
> > Cookie solves a lot of issues. Can't remember the details of all of them,
> > but these have been discussed several times on the mailing list this
> year.
> >
>
> Yeah, I don't remember either and I'd have to dig through emails to
> find it.  I do remember there were "back button" issues since we
> changed the session id every request.
>
>
> --
> Bill Burke
> Red Hat
>

From davmarti at redhat.com  Tue Dec 12 05:24:15 2017
From: davmarti at redhat.com (David Martin)
Date: Tue, 12 Dec 2017 10:24:15 +0000
Subject: [keycloak-dev] Keycloak metrics with Prometheus
Message-ID: <CADvBQ46SM3KRLqytXpbJrT0e+_RU4=PeseJAO-cnSsdr_wqE3w@mail.gmail.com>

Hi,

We're working on an Ansible Playbook Bundle for Keycloak, for the Ansible
Service Broker [0].
As part of a cohesive Mobile backend solution on OpenShift, we're adding
prometheus metrics endpoints to our own (mobile specific) services, and
have had some success with adding a metrics endpoint to Keycloak.

However, we're not convinced the approach for adding the metrics endpoint
is the best approach.

The first approach used the jboss/keycloak-openshift image as a base image,
then added in the necessary parts (jar file & config), producing a new
image.
I'm not a fan of this approach as it means we'll have to maintain the new
image, keeping it up to date as the keycloak-openshift image gets updated.

The second approach (PR in [1]), also uses the jboss/keycloak-openshift
image, but copies the JAR file at APB provision time into a mounted
Persistent Volume in the keycloak-openshift running container.
This approach addresses the image maintenance issue, but feels a bit hacky.

A couple of questions:
* Do you have any thoughts on either of the appraoches so far
* Would it make sense for us to create a PR for keycloak upstream that adds
the necessary bits to expose a prometheus metrics endpoint. This would be
disabled by default, and enabled based on an env var.

Any thoughts or help are welcome.
Thanks

[0] https://github.com/feedhenry/keycloak-apb
[1] https://github.com/feedhenry/keycloak-apb/pull/35/files



-- 
David Martin
Red Hat Mobile
Twitter: @irldavem
IRC: @irldavem (feedhenry, mobile-internal)

From matzew at apache.org  Tue Dec 12 05:57:39 2017
From: matzew at apache.org (Matthias Wessendorf)
Date: Tue, 12 Dec 2017 11:57:39 +0100
Subject: [keycloak-dev] Keycloak metrics with Prometheus
In-Reply-To: <CADvBQ46SM3KRLqytXpbJrT0e+_RU4=PeseJAO-cnSsdr_wqE3w@mail.gmail.com>
References: <CADvBQ46SM3KRLqytXpbJrT0e+_RU4=PeseJAO-cnSsdr_wqE3w@mail.gmail.com>
Message-ID: <CAAg5f2TQSqzNCCu47qa4y-Qma_m-zeqcKC96qSHQhtPck2NZdg@mail.gmail.com>

On Tue, Dec 12, 2017 at 11:24 AM, David Martin <davmarti at redhat.com> wrote:

> Hi,
>
> We're working on an Ansible Playbook Bundle for Keycloak, for the Ansible
> Service Broker [0].
> As part of a cohesive Mobile backend solution on OpenShift, we're adding
> prometheus metrics endpoints to our own (mobile specific) services, and
> have had some success with adding a metrics endpoint to Keycloak.
>
> However, we're not convinced the approach for adding the metrics endpoint
> is the best approach.
>
> The first approach used the jboss/keycloak-openshift image as a base image,
> then added in the necessary parts (jar file & config), producing a new
> image.
> I'm not a fan of this approach as it means we'll have to maintain the new
> image, keeping it up to date as the keycloak-openshift image gets updated.
>

-1 on this approach


>
> The second approach (PR in [1]), also uses the jboss/keycloak-openshift
> image, but copies the JAR file at APB provision time into a mounted
> Persistent Volume in the keycloak-openshift running container.
> This approach addresses the image maintenance issue, but feels a bit hacky.
>
> A couple of questions:
> * Do you have any thoughts on either of the appraoches so far
> * Would it make sense for us to create a PR for keycloak upstream that adds
> the necessary bits to expose a prometheus metrics endpoint. This would be
> disabled by default, and enabled based on an env var.
>

I like the 'second' approach better, however it would be nice if Keycloak
on its own would offer some of these metrics, as a build-in feature.

Happy to create a JIRA for it :-)


>
> Any thoughts or help are welcome.
> Thanks
>
> [0] https://github.com/feedhenry/keycloak-apb
> [1] https://github.com/feedhenry/keycloak-apb/pull/35/files
>
>
>
> --
> David Martin
> Red Hat Mobile
> Twitter: @irldavem
> IRC: @irldavem (feedhenry, mobile-internal)
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
twitter: http://twitter.com/mwessendorf

From mposolda at redhat.com  Wed Dec 13 08:29:57 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 13 Dec 2017 14:29:57 +0100
Subject: [keycloak-dev] offlineSessions data in cache vs db
In-Reply-To: <5332a28b-72cb-7bc9-be6e-a449d46fdd9c@autonomic.ai>
References: <5332a28b-72cb-7bc9-be6e-a449d46fdd9c@autonomic.ai>
Message-ID: <92ddbcc6-8529-a266-cd2e-a90b2d599dcf@redhat.com>

On 27/11/17 19:53, Tonnis Wildeboer wrote:
> Hello Keycloak Devs,
>
> [I posted this to keycloak-user, but got no response.]
>
> Ultimately, what we want to do is migrate three nodes from one namespace
> to another within a Kubernetes cluster as follows:
> Start with three nodes in one Kubernetes namespace that define a
> cluster. Then add three more nodes to the cluster in a new namespace
> that shares the same subnet and database, then kill off the original
> three nodes, effectively migrating the cluster to the new namespace and
> we want to do all this without anyone being logged out. The namespace
> distinction is invisible to Keycloak, as far as I can tell.
>
> What we have tried:
> * Start with 3 standalone-ha mode instances clustered with
> JGroups/JDBC_PING.
> * Set the number of cache owners for sessions to 6.
> * Start the three new instances in the new Kubernetes namespace,
> configured exactly the same as the first three - that is, same db, same
> number of cache owners.
> * Kill -9 the original three (I know now that it should be a kill -3,
> but don't know if that matters in this case).
>
> But it seems this caused offlineSession tokens to be expired immediately.
>
> I found this in the online documentation
> (http://www.keycloak.org/docs/latest/server_installation/index.html#server-cache-configuration):
>
>
>   > The second type of cache handles managing user sessions, offline
> tokens, and keeping track of login failures... The data held in these
> caches is temporary, in memory only, but is possibly replicated across
> the cluster.
>
>   > The sessions, authenticationSessions, offlineSessions and
> loginFailures caches are the only caches that may perform replication.
> Entries are not replicated to every single node, but instead one or more
> nodes is chosen as an owner of that data. If a node is not the owner of
> a specific cache entry it queries the cluster to obtain it. What this
> means for failover is that if all the nodes that own a piece of data go
> down, that data is lost forever. By default, Keycloak only specifies one
> owner for data. So if that one node goes down that data is lost. This
> usually means that users will be logged out and will have to login again.
>
> It appears, based on these documentation comments and our experience,
> that the "source of truth" regarding offlineSessions is the data in the
> "owner" caches, is NOT the database, as I would have expected. It also
> seems to be the case that if a node joins the cluster (as defined by
> JGroups/JDBC_PING), it will NOT be able to populate its offlineSessions
> cache from the database, but must rely on replication from one of the
> owner nodes.
>
> Questions:
> 1. Is the above understanding regarding the db vs cache correct?
> 2. If so, please explain the design/reasoning behind this behavior.
> Otherwise, please correct my understanding.
> 3. Is there a way to perform this simple migration without losing any
> sessions?
Hi,

sorry for late response.

- Offline sessions are saved in infinispan and there is write to DB just 
during login and during remove of the offline session.

- We don't want to write to DB at every offline token refresh. Or even 
read from DB. That's for performance purpose.

- The cache is populated from DB just during startup of server (in case 
of singlenode, non-cluster environment), or during startup of cluster 
coordinator. In case that more cluster servers are started concurrently, 
the other nodes will "help" coordinator node to preload offline sessions 
from DB. We use Infinispan DistributedExecutionService for this.

- Once sessions are initialized from DB to infinispan after startup, the 
DB is not used anymore for reading sessions. It's just infinispan. DB is 
here just to ensure that sessions are not lost after server restart (or 
after restart of whole cluster in case of cluster). So yes, the 
Infinispan cache is "source of truth" where Keycloak reads data during 
refreshToken requests from users

- For your scenario, I think that if you kill the 3 nodes from the "old" 
cluster and then start 3 nodes in the new cluster, the new cluster will 
preload offlineSessions from DB, so offlineSessions should be visible.

- On the other hand, if you have "old" 3 nodes still running and you 
start "new" 3 nodes to join existing cluster, the preloading from DB 
won't happen. However things should still work though as long as you 
really have 6 owners set on *every* cluster node. When new node joins 
the cluster, there is a phase called "rebalance" when the cache of new 
node is going to be populated from the other cluster nodes (more details 
about this in infinispan docs). But the rebalance takes some time... 
It's also possible that you first need to "read" the cache on the newly 
joining cluster nodes (EG. send at least one refreshToken request to 
it). In any way, you should be able to monitor through JMX how many 
items are available in the cache on every node. So you can assume that 
node is initialized and "rebalance" is finished after there is correct 
count of records in the cache. There are also some messages in the 
server.log once rebalance is started and once it is finished. So make 
sure to not kill the "old" servers before rebalance is really finished 
on new servers.

Hope this helps,

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



From mposolda at redhat.com  Wed Dec 13 08:41:47 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 13 Dec 2017 14:41:47 +0100
Subject: [keycloak-dev] Skip updateAllTimeStamps of offline sessions on
 init
In-Reply-To: <b158d782d51644c691d84e56631492c6@DE36S004EXC1C.wp.corpintra.net>
References: <b158d782d51644c691d84e56631492c6@DE36S004EXC1C.wp.corpintra.net>
Message-ID: <1c21e6a2-454b-cfc8-7901-6163e7a48f48@redhat.com>

On 11/12/17 09:39, javier.roman-navarrete at daimler.com wrote:
> Upon startup, all offline sessions timestamps are updated (both in the client and user tables). This can be quite time consuming, and we are trying to find out the real purpose of it. There is even a comment on the source code
>
> // TODO: check if update of timestamps in persister can be skipped entirely
>
> That hints it might be superfluous. What would be the downside of avoiding this update?
I think it won't break anything. Feel free to create JIRA for this. 
Please also link it with the other JIRA: 
https://issues.jboss.org/browse/KEYCLOAK-5479, which is related.

Ideally both things might be fixed together, so that there is no need to 
update timestamp with currentTime at startup, as it has some other 
downsides mentioned in the KEYCLOAK-5479 JIRA (Besides the startup 
performance issue you just mentioned).

Marek


>
> Regards,
>
> Javier Rom?n Navarrete
>
>
>
> If you are not the addressee, please inform us immediately that you have received this e-mail by mistake, and delete it. We thank you for your support.
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



From sthorger at redhat.com  Thu Dec 14 04:54:01 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 14 Dec 2017 10:54:01 +0100
Subject: [keycloak-dev] Restricting access to admin console to separate port
	or IP address range
Message-ID: <CAJgngAep12H+qpuzdkgTQ9W9raoP-N4+24mpqcMUmMVwY0rLCg@mail.gmail.com>

Found out it's pretty simple to restrict access to the admin
console/endpoint to a separate port or to an IP address range. This can be
achieved with built-in filters in WildFly.

Documentation incoming, see
https://github.com/keycloak/keycloak-documentation/pull/267

From ssilvert at redhat.com  Thu Dec 14 07:31:26 2017
From: ssilvert at redhat.com (Stan Silvert)
Date: Thu, 14 Dec 2017 07:31:26 -0500
Subject: [keycloak-dev] Restricting access to admin console to separate
 port or IP address range
In-Reply-To: <CAJgngAep12H+qpuzdkgTQ9W9raoP-N4+24mpqcMUmMVwY0rLCg@mail.gmail.com>
References: <CAJgngAep12H+qpuzdkgTQ9W9raoP-N4+24mpqcMUmMVwY0rLCg@mail.gmail.com>
Message-ID: <23fb2d4e-2c09-239c-395c-b47e779308b8@redhat.com>

That's really nice.  I didn't know Undertow had added such powerful 
filtering without having to write code.

On 12/14/2017 4:54 AM, Stian Thorgersen wrote:
> Found out it's pretty simple to restrict access to the admin
> console/endpoint to a separate port or to an IP address range. This can be
> achieved with built-in filters in WildFly.
>
> Documentation incoming, see
> https://github.com/keycloak/keycloak-documentation/pull/267
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From davmarti at redhat.com  Thu Dec 14 07:55:26 2017
From: davmarti at redhat.com (David Martin)
Date: Thu, 14 Dec 2017 12:55:26 +0000
Subject: [keycloak-dev] Keycloak metrics with Prometheus
In-Reply-To: <CAAg5f2TQSqzNCCu47qa4y-Qma_m-zeqcKC96qSHQhtPck2NZdg@mail.gmail.com>
References: <CADvBQ46SM3KRLqytXpbJrT0e+_RU4=PeseJAO-cnSsdr_wqE3w@mail.gmail.com>
	<CAAg5f2TQSqzNCCu47qa4y-Qma_m-zeqcKC96qSHQhtPck2NZdg@mail.gmail.com>
Message-ID: <CADvBQ45aReuQjh-U+uwPu-VxhbEmX9AWAwkCF13F6o=ZX_6wVw@mail.gmail.com>

Is creating a JIRA the done thing for keycloak dev?
If so, then sure, lets create a JIRA.

Anyone on the keycload dev team have any thoughts on the proposal?

On 12 December 2017 at 10:57, Matthias Wessendorf <matzew at apache.org> wrote:

>
>
> On Tue, Dec 12, 2017 at 11:24 AM, David Martin <davmarti at redhat.com>
> wrote:
>
>> Hi,
>>
>> We're working on an Ansible Playbook Bundle for Keycloak, for the Ansible
>> Service Broker [0].
>> As part of a cohesive Mobile backend solution on OpenShift, we're adding
>> prometheus metrics endpoints to our own (mobile specific) services, and
>> have had some success with adding a metrics endpoint to Keycloak.
>>
>> However, we're not convinced the approach for adding the metrics endpoint
>> is the best approach.
>>
>> The first approach used the jboss/keycloak-openshift image as a base
>> image,
>> then added in the necessary parts (jar file & config), producing a new
>> image.
>> I'm not a fan of this approach as it means we'll have to maintain the new
>> image, keeping it up to date as the keycloak-openshift image gets updated.
>>
>
> -1 on this approach
>
>
>>
>> The second approach (PR in [1]), also uses the jboss/keycloak-openshift
>> image, but copies the JAR file at APB provision time into a mounted
>> Persistent Volume in the keycloak-openshift running container.
>> This approach addresses the image maintenance issue, but feels a bit
>> hacky.
>>
>> A couple of questions:
>> * Do you have any thoughts on either of the appraoches so far
>> * Would it make sense for us to create a PR for keycloak upstream that
>> adds
>> the necessary bits to expose a prometheus metrics endpoint. This would be
>> disabled by default, and enabled based on an env var.
>>
>
> I like the 'second' approach better, however it would be nice if Keycloak
> on its own would offer some of these metrics, as a build-in feature.
>
> Happy to create a JIRA for it :-)
>
>
>>
>> Any thoughts or help are welcome.
>> Thanks
>>
>> [0] https://github.com/feedhenry/keycloak-apb
>> [1] https://github.com/feedhenry/keycloak-apb/pull/35/files
>>
>>
>>
>> --
>> David Martin
>> Red Hat Mobile
>> Twitter: @irldavem
>> IRC: @irldavem (feedhenry, mobile-internal)
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> twitter: http://twitter.com/mwessendorf
>



-- 
David Martin
Red Hat Mobile
Twitter: @irldavem
IRC: @irldavem (feedhenry, mobile-internal)

From sthorger at redhat.com  Thu Dec 14 08:14:30 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 14 Dec 2017 14:14:30 +0100
Subject: [keycloak-dev] Keycloak Realm Count Upper Limit
In-Reply-To: <CAOqetn-zDmKQAx9-UmPVo+ZazSy=5e5100APu3cdp0qWZFPQBQ@mail.gmail.com>
References: <CAOqetn-zDmKQAx9-UmPVo+ZazSy=5e5100APu3cdp0qWZFPQBQ@mail.gmail.com>
Message-ID: <CAJgngAeq1Q_mDo=fe7LO4Zeqm9DW0BOPwQpQbE7X9T4+D+X5qQ@mail.gmail.com>

There's a plan to look at it, but it's not a high priority for us at the
moment.

On 11 December 2017 at 16:00, John D. Ament <john.d.ament at gmail.com> wrote:

> We did some capacity and stress testing on keycloak recently.  One of the
> tests was to identify a breaking point for the realm count that would
> result in the system breaking.  We identified that once Keycloak hits 470
> realms, regardless of scaling up the box and having caching enabled,
> Keycloak simply becomes unusable.
>
> Right now, this is a higher number than we need, but wanted to see if there
> are any plans or enhancements to look at in newer versions to see if we
> should test differently?  We're on Keycloak 3.2 presently.
>
> John
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From john.d.ament at gmail.com  Thu Dec 14 09:31:18 2017
From: john.d.ament at gmail.com (John D. Ament)
Date: Thu, 14 Dec 2017 14:31:18 +0000
Subject: [keycloak-dev] Keycloak Realm Count Upper Limit
In-Reply-To: <CAJgngAeq1Q_mDo=fe7LO4Zeqm9DW0BOPwQpQbE7X9T4+D+X5qQ@mail.gmail.com>
References: <CAOqetn-zDmKQAx9-UmPVo+ZazSy=5e5100APu3cdp0qWZFPQBQ@mail.gmail.com>
	<CAJgngAeq1Q_mDo=fe7LO4Zeqm9DW0BOPwQpQbE7X9T4+D+X5qQ@mail.gmail.com>
Message-ID: <CAOqetn-9w1JF=+rhebizDT4xiZMOsvKT3TE9sQr_26rqjs7wCg@mail.gmail.com>

Do you want me to create a ticket or you have one?  I'm not in any specific
rush for it, since its much higher than our current plans.

John

On Thu, Dec 14, 2017 at 8:14 AM Stian Thorgersen <sthorger at redhat.com>
wrote:

> There's a plan to look at it, but it's not a high priority for us at the
> moment.
>
> On 11 December 2017 at 16:00, John D. Ament <john.d.ament at gmail.com>
> wrote:
>
>> We did some capacity and stress testing on keycloak recently.  One of the
>> tests was to identify a breaking point for the realm count that would
>> result in the system breaking.  We identified that once Keycloak hits 470
>> realms, regardless of scaling up the box and having caching enabled,
>> Keycloak simply becomes unusable.
>>
>> Right now, this is a higher number than we need, but wanted to see if
>> there
>> are any plans or enhancements to look at in newer versions to see if we
>> should test differently?  We're on Keycloak 3.2 presently.
>>
>> John
>>
> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>

From john.d.ament at gmail.com  Thu Dec 14 09:38:18 2017
From: john.d.ament at gmail.com (John D. Ament)
Date: Thu, 14 Dec 2017 14:38:18 +0000
Subject: [keycloak-dev] KEYCLOAK-4853
Message-ID: <CAOqetn941+20n5sNX1a=CcwBV9ort9-y63MVm-MMxa-21FdkaQ@mail.gmail.com>

I'm planning to start to submit some PRs for
https://issues.jboss.org/browse/KEYCLOAK-4853 .  If I start to get them to
you in the next few days, what would release would they target.  Some of
the items I'm looking to immediately leverage are:

- Create User
- Create Group
- Create IDP

These are the important ones since fetching the data a second go around
requires that unique ID in the URL.

John

From sthorger at redhat.com  Thu Dec 14 09:56:53 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 14 Dec 2017 15:56:53 +0100
Subject: [keycloak-dev] Keycloak Realm Count Upper Limit
In-Reply-To: <CAOqetn-9w1JF=+rhebizDT4xiZMOsvKT3TE9sQr_26rqjs7wCg@mail.gmail.com>
References: <CAOqetn-zDmKQAx9-UmPVo+ZazSy=5e5100APu3cdp0qWZFPQBQ@mail.gmail.com>
	<CAJgngAeq1Q_mDo=fe7LO4Zeqm9DW0BOPwQpQbE7X9T4+D+X5qQ@mail.gmail.com>
	<CAOqetn-9w1JF=+rhebizDT4xiZMOsvKT3TE9sQr_26rqjs7wCg@mail.gmail.com>
Message-ID: <CAJgngAcG=7zb0csA8X6cSwChRLJnFHkju9eh1=bYq_MaFaVVMg@mail.gmail.com>

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

On 14 December 2017 at 15:31, John D. Ament <john.d.ament at gmail.com> wrote:

> Do you want me to create a ticket or you have one?  I'm not in any
> specific rush for it, since its much higher than our current plans.
>
> John
>
>
> On Thu, Dec 14, 2017 at 8:14 AM Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> There's a plan to look at it, but it's not a high priority for us at the
>> moment.
>>
>> On 11 December 2017 at 16:00, John D. Ament <john.d.ament at gmail.com>
>> wrote:
>>
>>> We did some capacity and stress testing on keycloak recently.  One of the
>>> tests was to identify a breaking point for the realm count that would
>>> result in the system breaking.  We identified that once Keycloak hits 470
>>> realms, regardless of scaling up the box and having caching enabled,
>>> Keycloak simply becomes unusable.
>>>
>>> Right now, this is a higher number than we need, but wanted to see if
>>> there
>>> are any plans or enhancements to look at in newer versions to see if we
>>> should test differently?  We're on Keycloak 3.2 presently.
>>>
>>> John
>>>
>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>>

From john.d.ament at gmail.com  Thu Dec 14 10:06:05 2017
From: john.d.ament at gmail.com (John D. Ament)
Date: Thu, 14 Dec 2017 15:06:05 +0000
Subject: [keycloak-dev] Keycloak Realm Count Upper Limit
In-Reply-To: <CAJgngAcG=7zb0csA8X6cSwChRLJnFHkju9eh1=bYq_MaFaVVMg@mail.gmail.com>
References: <CAOqetn-zDmKQAx9-UmPVo+ZazSy=5e5100APu3cdp0qWZFPQBQ@mail.gmail.com>
	<CAJgngAeq1Q_mDo=fe7LO4Zeqm9DW0BOPwQpQbE7X9T4+D+X5qQ@mail.gmail.com>
	<CAOqetn-9w1JF=+rhebizDT4xiZMOsvKT3TE9sQr_26rqjs7wCg@mail.gmail.com>
	<CAJgngAcG=7zb0csA8X6cSwChRLJnFHkju9eh1=bYq_MaFaVVMg@mail.gmail.com>
Message-ID: <CAOqetn89Cj9J+srWONy3Yh+g1oq_xE+VNrvvJCJTTs7EmxCdTA@mail.gmail.com>

Ok, thanks.  I just added a comment with my current findings.

On Thu, Dec 14, 2017 at 9:56 AM Stian Thorgersen <sthorger at redhat.com>
wrote:

> https://issues.jboss.org/browse/KEYCLOAK-4593
>
> On 14 December 2017 at 15:31, John D. Ament <john.d.ament at gmail.com>
> wrote:
>
>> Do you want me to create a ticket or you have one?  I'm not in any
>> specific rush for it, since its much higher than our current plans.
>>
>> John
>>
>>
>> On Thu, Dec 14, 2017 at 8:14 AM Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>>
>>> There's a plan to look at it, but it's not a high priority for us at the
>>> moment.
>>>
>>> On 11 December 2017 at 16:00, John D. Ament <john.d.ament at gmail.com>
>>> wrote:
>>>
>>>> We did some capacity and stress testing on keycloak recently.  One of
>>>> the
>>>> tests was to identify a breaking point for the realm count that would
>>>> result in the system breaking.  We identified that once Keycloak hits
>>>> 470
>>>> realms, regardless of scaling up the box and having caching enabled,
>>>> Keycloak simply becomes unusable.
>>>>
>>>> Right now, this is a higher number than we need, but wanted to see if
>>>> there
>>>> are any plans or enhancements to look at in newer versions to see if we
>>>> should test differently?  We're on Keycloak 3.2 presently.
>>>>
>>>> John
>>>>
>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>>
>>>
>

From dchrzascik at novomatic-tech.com  Fri Dec 15 05:33:59 2017
From: dchrzascik at novomatic-tech.com (Dariusz Chrzascik)
Date: Fri, 15 Dec 2017 11:33:59 +0100
Subject: [keycloak-dev] [Improvment Request] Add context for an
 permission requests
In-Reply-To: <CAFGTxA4qDNSfrtbc9HoKnq3YbEYPHxGZzkujwMdyLS3Wq_FT1g@mail.gmail.com>
References: <CAFGTxA4qDNSfrtbc9HoKnq3YbEYPHxGZzkujwMdyLS3Wq_FT1g@mail.gmail.com>
Message-ID: <5A33B3270200008600098789@gwia-internal01.atsisa.com>

Hi,

I'd like to join the discussion. What do you think about such
improvement? For me it seems to be a approach when domain can't be
modeled in a simple way through use of resources and scopes or if the
policies should be based on additional context that changes dynamically.

My main concern is that such "context" that is part of "permissions" in
JWT token isn't standard at all so we are extending the RPT token with
custom fields. Bottom line is that this isn't compatible with UMA
standard. Nonetheless, it seems to be useful. What do you think about
this approach?

Regards,
Dariusz Chrz??cik



>>> Tomek <thom.nocon at gmail.com> 12/07/17 5:35 PM >>>
Hello guys,

we would like to propose an improvment that can be added to the
*Entitlment
API*. This topic was already opened in this mail: link
<http://lists.jboss.org/pipermail/keycloak-user/2017-February/009391.html>.
The main purpose of this improvment is to add an optional contextual
data
for an permission requests.

Let's take into account an examle bussines case: evaluate permission to
orders in the context of specific shops. Those shops can be added to
the *Keycloak
*as a specific resources or scopes inside the *Order* resource. In our
point of view this is an overhead when we must synchronize all shops
from
DB with *Keycloak*.

We have prepared a simple improvment. Here is an example of entitlment
request:

*POST /auth/realms/{realmName}/authz/entitlement/{clientName}*
*{*
* "permissions": [*
* {*
* "resource_set_name": "Orders Resource",*
* "context": {*
* "shops": ["shop1", "shop2"]*
* }*
* },*
* {*
* "resource_set_name": "Shop Resource"*
* }*
* ]*
*}*

The *context* is a map: *Map<String, Collection<String>> *and it could
be
injected to the *Attributes* inside the *EvaluationContext* class before
policy evaluation.

The result of this request is an *RPT* token that also contains the
contextual data, so it can be later re-used. An example encoded *RPT*
token:

*{*
*.....*
* "authorization": {*
* "permissions": [*
* {*
* "resource_set_id": "76bb1db0-b3c3-47a1-9d06-8f3b98d2ba10",*
* "resource_set_name": "Default Resource",*
* "context": {*
* "shops": ["shop1", "shop2"]*
* }*
* }*
* ]*
* }*
*.....*
*}*

The reason for this improvement is the overhead that arises when we have
a
lot of resources to handle and they are added dynamically.

I have already implemented a working proof of concept, that is
accessible
in the following link
<https://github.com/nocotom/keycloak/tree/feature/permission-context>.
(the context in the returned *RPT *token is missing, but the input
context
is propagated to the policy evaluation)

Is this something *Keycloak *might have implemented?
What you think, guys?

Regards,
Tom Noco?
_______________________________________________
keycloak-dev mailing list
keycloak-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev




CONFIDENTIALITY NOTICE
------------------------------------
This E-mail is intended only to be read or used by the addressee. The information contained in this E-mail message may be confidential information. If you are not the intended recipient, any use, interference with, distribution, disclosure or copying of this material is unauthorized and prohibited. Confidentiality attached to this communication is not waived or lost by reason of the mistaken delivery to you.
If you have received this message in error, please delete it and notify us by return E-mail or telephone NOVOMATIC Technologies Poland S.A. +48 12 258 00 50. Any E-mail attachment may contain software viruses which could damage your own computer system. Whilst reasonable precaution has been taken to minimize this risk, we cannot accept liability for any damage which you sustain as a result of software viruses. You should therefore carry out your own virus checks before opening any attachments.
------------------------------------
NOVOMATIC Technologies Poland S.A., Poland, Krakowska 368, 32-080 Zabierz?w


From bburke at redhat.com  Sat Dec 16 13:15:31 2017
From: bburke at redhat.com (Bill Burke)
Date: Sat, 16 Dec 2017 13:15:31 -0500
Subject: [keycloak-dev] Is TestingResource token protected?
Message-ID: <CABRXCmxF8BMC3zA1i4LEMfdR-HmD-abBwhrwd-80W1__J0Nhvw@mail.gmail.com>

I'm getting a 401 error when invoking on the AssertEvents.clear()
method in one of my tests.  Make zero sense other than that I set the
time offset to sometime in the future before invoking it.  Is Testing
Resource protected by Keycloak?  Its the only reason I can think that
the token is expired or something.  I can't seem to find the
information anywhere.

This is driving me crazy because locally tests pass 100%, but I'm
getting this problem in the CI build.

-- 
Bill Burke
Red Hat

From mitya at cargosoft.ru  Sun Dec 17 16:43:38 2017
From: mitya at cargosoft.ru (Dmitry Telegin)
Date: Mon, 18 Dec 2017 00:43:38 +0300
Subject: [keycloak-dev] Global writable config
Message-ID: <1513547018.3385.1.camel@cargosoft.ru>

Hi,

While developing a KC extension, I've faced the requirement to
implement global writable persistent configuration. That means, 1) it
should not be bound to any particular realm, 2) it should be accessible
from providers, 3) it should be updatable from the Admin console and
via REST. Additionally, there exists an (independent) requirement to
process INI-style files. With all the above, introducing Apache Commons
Configuration as a dependency would be an obvious choice.

But before that, I wanted to know if there are any plans to introduce
the same on the Keycloak side? If so, I think we could save ourselves
some time.

>From the "business" side, most configuration in Keycloak is per-realm.
But if we take a look at the similar software, like Atlassian Crowd or
WSO2 Identity Server, we'll find most of them have some sort of global
settings, for example:
- auto-update settings;
- periodic tasks;
- scheduled backups;
- plugin-specific global settings.

At the moment, I don't think any of the above is of high priority for
Keycloak, but I'm pretty sure there's a good chance things will change
in the future.

>From the technical side, we currently have global config in
standalone.xml which is read-only, and a lot of per-realm stuff that is
persisted into the database (including e.g. components). We also have
org.keycloak.Config stuff that is also read-only and only supports
system properties; and trying to make it writable and persistent will
inevitably result in the reinvention of "ad-hoc, informally-specified,
bug-ridden, slow implementation of half of" Apache Commons
Configuration.

With the above, please let me know what do you think of the idea of
introducing unified global config service backed by (tentatively)
Commons Configuration, with the following features (here's what's most
important in the context):
- support for multiple config sources under single API, most
importantly system properties, XML and JDBC;
- automatically selecting writable backend (e.g. JDBC) when writing to
a combined/composite config;
- events and notification;
- synchronization & thread safety.

If this is not topical for Keycloak proper, I'd appreciate any ideas on
how to do it the right way on the extension side.

Thanks in advance,
Dmitry


From sthorger at redhat.com  Mon Dec 18 00:51:21 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 18 Dec 2017 06:51:21 +0100
Subject: [keycloak-dev] KEYCLOAK-4853
In-Reply-To: <CAOqetn941+20n5sNX1a=CcwBV9ort9-y63MVm-MMxa-21FdkaQ@mail.gmail.com>
References: <CAOqetn941+20n5sNX1a=CcwBV9ort9-y63MVm-MMxa-21FdkaQ@mail.gmail.com>
Message-ID: <CAJgngAc6HbHVVTKZwfyDfJP-bwx5MWwO1xyZRQqHL=6VWYNRpg@mail.gmail.com>

The unique ID is being returned as part of the Location header. This is a
standard way of doing things. I don't like your proposal of returning an ID
header as that's something custom that at least I've not seen done
elsewhere.

I appreciate the fact that the Location header has to be parsed, but adding
a new custom header isn't the solution IMO.

We would not consider this for 3.x so it wouldn't be merged until the new
year at the earliest. We'd also need an agreed pattern that should be
discussed on the mailing list prior to sending a PR. It would have to be
complete (all endpoints updated) and come with tests.

On 14 December 2017 at 15:38, John D. Ament <john.d.ament at gmail.com> wrote:

> I'm planning to start to submit some PRs for
> https://issues.jboss.org/browse/KEYCLOAK-4853 .  If I start to get them to
> you in the next few days, what would release would they target.  Some of
> the items I'm looking to immediately leverage are:
>
> - Create User
> - Create Group
> - Create IDP
>
> These are the important ones since fetching the data a second go around
> requires that unique ID in the URL.
>
> John
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From john.d.ament at gmail.com  Mon Dec 18 07:57:45 2017
From: john.d.ament at gmail.com (John D. Ament)
Date: Mon, 18 Dec 2017 12:57:45 +0000
Subject: [keycloak-dev] KEYCLOAK-4853
In-Reply-To: <CAJgngAc6HbHVVTKZwfyDfJP-bwx5MWwO1xyZRQqHL=6VWYNRpg@mail.gmail.com>
References: <CAOqetn941+20n5sNX1a=CcwBV9ort9-y63MVm-MMxa-21FdkaQ@mail.gmail.com>
	<CAJgngAc6HbHVVTKZwfyDfJP-bwx5MWwO1xyZRQqHL=6VWYNRpg@mail.gmail.com>
Message-ID: <CAOqetn_6bXa6RZzTd_hhYg9bY=niD4bjH5HA-DnAFiT21=fDPg@mail.gmail.com>

Stian,

On Mon, Dec 18, 2017 at 12:51 AM Stian Thorgersen <sthorger at redhat.com>
wrote:

> The unique ID is being returned as part of the Location header. This is a
> standard way of doing things. I don't like your proposal of returning an ID
> header as that's something custom that at least I've not seen done
> elsewhere.
>
> I appreciate the fact that the Location header has to be parsed, but
> adding a new custom header isn't the solution IMO.
>

Agreed.  I wanted to better understand where we're struggling.  Looking at
the code, would it make sense for Keycloak's Admin client to provide a
utility that can parse the header to retrieve the ID portion of the URL, so
that consumers don't need to parse it themselves?


>
> We would not consider this for 3.x so it wouldn't be merged until the new
> year at the earliest. We'd also need an agreed pattern that should be
> discussed on the mailing list prior to sending a PR. It would have to be
> complete (all endpoints updated) and come with tests.
>
> On 14 December 2017 at 15:38, John D. Ament <john.d.ament at gmail.com>
> wrote:
>
>> I'm planning to start to submit some PRs for
>> https://issues.jboss.org/browse/KEYCLOAK-4853 .  If I start to get them
>> to
>> you in the next few days, what would release would they target.  Some of
>> the items I'm looking to immediately leverage are:
>>
>> - Create User
>> - Create Group
>> - Create IDP
>>
>> These are the important ones since fetching the data a second go around
>> requires that unique ID in the URL.
>>
>> John
>>
> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>

From john.d.ament at gmail.com  Mon Dec 18 08:01:19 2017
From: john.d.ament at gmail.com (John D. Ament)
Date: Mon, 18 Dec 2017 13:01:19 +0000
Subject: [keycloak-dev] Ability to confirm that a realm was created
Message-ID: <CAOqetn-EsUCT0v7XBrQCFN-VNqdLar9vOxKtEQQYYD=msS8ZqA@mail.gmail.com>

I had raised a PR ( https://github.com/keycloak/keycloak/pull/4850 ) for
KEYCLOAK-4852. It seems like there may be some disagreement on whether this
is needed, but I was confused by the fact that the ticket was in the
"BacklogBacklog" without any comments, questions or concerns.

Here's the problem I face.  The resteasy proxy code only throws exceptions
for 4xx and higher responses.  I want to confirm on realm creation that I
received a 201 Created header back from keycloak.  The admin client doesn't
support this today.  To do that, and without breaking other consumers, I
introduced a new method that will return the response.  The void method
remains and doesn't change any behavior.  The new method allows me to read
the response status and location headers correctly.

John

From sthorger at redhat.com  Mon Dec 18 08:13:48 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 18 Dec 2017 14:13:48 +0100
Subject: [keycloak-dev] KEYCLOAK-4853
In-Reply-To: <CAOqetn_6bXa6RZzTd_hhYg9bY=niD4bjH5HA-DnAFiT21=fDPg@mail.gmail.com>
References: <CAOqetn941+20n5sNX1a=CcwBV9ort9-y63MVm-MMxa-21FdkaQ@mail.gmail.com>
	<CAJgngAc6HbHVVTKZwfyDfJP-bwx5MWwO1xyZRQqHL=6VWYNRpg@mail.gmail.com>
	<CAOqetn_6bXa6RZzTd_hhYg9bY=niD4bjH5HA-DnAFiT21=fDPg@mail.gmail.com>
Message-ID: <CAJgngAdU5baZBZemrAen5wsSEaiCXitNwyiidVtiiMzHmkZ6cQ@mail.gmail.com>

On 18 December 2017 at 13:57, John D. Ament <john.d.ament at gmail.com> wrote:

> Stian,
>
> On Mon, Dec 18, 2017 at 12:51 AM Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> The unique ID is being returned as part of the Location header. This is a
>> standard way of doing things. I don't like your proposal of returning an ID
>> header as that's something custom that at least I've not seen done
>> elsewhere.
>>
>> I appreciate the fact that the Location header has to be parsed, but
>> adding a new custom header isn't the solution IMO.
>>
>
> Agreed.  I wanted to better understand where we're struggling.  Looking at
> the code, would it make sense for Keycloak's Admin client to provide a
> utility that can parse the header to retrieve the ID portion of the URL, so
> that consumers don't need to parse it themselves?
>

That would probably be the simplest option. We already to this in the
testsuite with:

https://github.com/keycloak/keycloak/blob/master/testsuite/integration-arquillian/tests/base/src/test/java/org/keycloak/testsuite/admin/ApiUtil.java#L51

Could you extract the getCreatedId method to a new Util class within
admin-client


>
>
>>
>> We would not consider this for 3.x so it wouldn't be merged until the new
>> year at the earliest. We'd also need an agreed pattern that should be
>> discussed on the mailing list prior to sending a PR. It would have to be
>> complete (all endpoints updated) and come with tests.
>>
>> On 14 December 2017 at 15:38, John D. Ament <john.d.ament at gmail.com>
>> wrote:
>>
>>> I'm planning to start to submit some PRs for
>>> https://issues.jboss.org/browse/KEYCLOAK-4853 .  If I start to get them
>>> to
>>> you in the next few days, what would release would they target.  Some of
>>> the items I'm looking to immediately leverage are:
>>>
>>> - Create User
>>> - Create Group
>>> - Create IDP
>>>
>>> These are the important ones since fetching the data a second go around
>>> requires that unique ID in the URL.
>>>
>>> John
>>>
>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>>

From mstrukel at redhat.com  Mon Dec 18 08:38:26 2017
From: mstrukel at redhat.com (Marko Strukelj)
Date: Mon, 18 Dec 2017 14:38:26 +0100
Subject: [keycloak-dev] Is TestingResource token protected?
In-Reply-To: <CABRXCmxF8BMC3zA1i4LEMfdR-HmD-abBwhrwd-80W1__J0Nhvw@mail.gmail.com>
References: <CABRXCmxF8BMC3zA1i4LEMfdR-HmD-abBwhrwd-80W1__J0Nhvw@mail.gmail.com>
Message-ID: <CA+1OW+jio9Q5fA0Lh1WRQ9CsW_0En-8BKhJAzc9k6aaEvK4bKQ@mail.gmail.com>

Is there some stack trace on the server? TestingResource is not protected
so you should not be getting 401.

On Sat, Dec 16, 2017 at 7:15 PM, Bill Burke <bburke at redhat.com> wrote:

> I'm getting a 401 error when invoking on the AssertEvents.clear()
> method in one of my tests.  Make zero sense other than that I set the
> time offset to sometime in the future before invoking it.  Is Testing
> Resource protected by Keycloak?  Its the only reason I can think that
> the token is expired or something.  I can't seem to find the
> information anywhere.
>
> This is driving me crazy because locally tests pass 100%, but I'm
> getting this problem in the CI build.
>
> --
> Bill Burke
> Red Hat
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From btowles at cloudera.com  Tue Dec 19 21:24:20 2017
From: btowles at cloudera.com (Brian Towles)
Date: Wed, 20 Dec 2017 02:24:20 +0000
Subject: [keycloak-dev] Hot or Rolling upgrade
Message-ID: <CADXGKANjAv5PA=aV-q05tOEcS+dHnSCCf8=judg56L6wU5Z+sA@mail.gmail.com>

Howdy all,

I was wondering if there is any advice on how to do a rolling upgrade of
Keycloak, or any mechanism to maintain a running instance while upgrading?

Ive seen the docs here
(http://www.keycloak.org/docs/latest/upgrading/index.html) and they all ha
type installs say that "all instances must be upgraded at the same time."

Any hints or pointers would be great.

Thanks
-=Brian
-- 
*Brian Towles* | Software Engineer
t. (512) 415- <0000000000>8105 e. btowles at cloudera.com <jond at cloudera.com>
cloudera.com <http://www.cloudera.com/>

[image: Cloudera] <http://www.cloudera.com/>

[image: Cloudera on Twitter] <https://twitter.com/cloudera> [image:
Cloudera on Facebook] <https://www.facebook.com/cloudera> [image: Cloudera
on LinkedIn] <https://www.linkedin.com/company/cloudera>
------------------------------

From btowles at cloudera.com  Tue Dec 19 21:32:07 2017
From: btowles at cloudera.com (Brian Towles)
Date: Wed, 20 Dec 2017 02:32:07 +0000
Subject: [keycloak-dev] Hot or Rolling upgrade
In-Reply-To: <CADXGKANjAv5PA=aV-q05tOEcS+dHnSCCf8=judg56L6wU5Z+sA@mail.gmail.com>
References: <CADXGKANjAv5PA=aV-q05tOEcS+dHnSCCf8=judg56L6wU5Z+sA@mail.gmail.com>
Message-ID: <CADXGKANemXHZomrUDqhHwFQx8hUo70r9+ox_ePrO_zA2GvTXjA@mail.gmail.com>

Well just found
http://lists.jboss.org/pipermail/keycloak-user/2017-May/010776.html and the
jira for it.

Never mind for now. Thanks :)

On Tue, Dec 19, 2017 at 8:24 PM Brian Towles <btowles at cloudera.com> wrote:

> Howdy all,
>
> I was wondering if there is any advice on how to do a rolling upgrade of
> Keycloak, or any mechanism to maintain a running instance while upgrading?
>
> Ive seen the docs here
> (http://www.keycloak.org/docs/latest/upgrading/index.html) and they all
> ha type installs say that "all instances must be upgraded at the same time."
>
> Any hints or pointers would be great.
>
> Thanks
> -=Brian
> --
> *Brian Towles* | Software Engineer
> t. (512) 415- <0000000000>8105 e. btowles at cloudera.com <jond at cloudera.com>
> cloudera.com <http://www.cloudera.com/>
>
> [image: Cloudera] <http://www.cloudera.com/>
>
> [image: Cloudera on Twitter] <https://twitter.com/cloudera> [image:
> Cloudera on Facebook] <https://www.facebook.com/cloudera> [image:
> Cloudera on LinkedIn] <https://www.linkedin.com/company/cloudera>
> ------------------------------
>
-- 
*Brian Towles* | Software Engineer
t. (512) 415- <0000000000>8105 e. btowles at cloudera.com <jond at cloudera.com>
cloudera.com <http://www.cloudera.com/>

[image: Cloudera] <http://www.cloudera.com/>

[image: Cloudera on Twitter] <https://twitter.com/cloudera> [image:
Cloudera on Facebook] <https://www.facebook.com/cloudera> [image: Cloudera
on LinkedIn] <https://www.linkedin.com/company/cloudera>
------------------------------

From simonpayne58 at gmail.com  Wed Dec 20 13:14:26 2017
From: simonpayne58 at gmail.com (Simon Payne)
Date: Wed, 20 Dec 2017 18:14:26 +0000
Subject: [keycloak-dev] Hot or Rolling upgrade
In-Reply-To: <CADXGKANjAv5PA=aV-q05tOEcS+dHnSCCf8=judg56L6wU5Z+sA@mail.gmail.com>
References: <CADXGKANjAv5PA=aV-q05tOEcS+dHnSCCf8=judg56L6wU5Z+sA@mail.gmail.com>
Message-ID: <CAPZw1G7ijMQbPB5VtCoa-b_6VzjNRQFAafWG2D+VkSaVCMrQww@mail.gmail.com>

Hi, i'm also interested in this as we would ideally like to perform a zero
downtime release.

upgrading each instance will be relatively straightforward if taken out of
the cluster, however i believe the complexity will come if any release
includes breaking changes on either the db or remote cache.

i'm trying to understand this at the moment myself, so will be watching
this with interest.

Simon.


On Wed, Dec 20, 2017 at 2:24 AM, Brian Towles <btowles at cloudera.com> wrote:

> Howdy all,
>
> I was wondering if there is any advice on how to do a rolling upgrade of
> Keycloak, or any mechanism to maintain a running instance while upgrading?
>
> Ive seen the docs here
> (http://www.keycloak.org/docs/latest/upgrading/index.html) and they all ha
> type installs say that "all instances must be upgraded at the same time."
>
> Any hints or pointers would be great.
>
> Thanks
> -=Brian
> --
> *Brian Towles* | Software Engineer
> t. (512) 415- <0000000000>8105 e. btowles at cloudera.com <jond at cloudera.com>
> cloudera.com <http://www.cloudera.com/>
>
> [image: Cloudera] <http://www.cloudera.com/>
>
> [image: Cloudera on Twitter] <https://twitter.com/cloudera> [image:
> Cloudera on Facebook] <https://www.facebook.com/cloudera> [image: Cloudera
> on LinkedIn] <https://www.linkedin.com/company/cloudera>
> ------------------------------
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sthorger at redhat.com  Thu Dec 21 09:57:47 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 21 Dec 2017 15:57:47 +0100
Subject: [keycloak-dev] Keycloak 3.4.2.Final Released
Message-ID: <CAJgngAeiUU6Gq4Sbf845tUtgz2D+oGOio=KGoXY91S=Hxfpnyg@mail.gmail.com>

We've just released Keycloak 3.4.2.Final.

To download the release go to the Keycloak homepage
<http://www.keycloak.org/downloads>.

The full list of resolved issues is available in JIRA
<https://issues.jboss.org/issues/?jql=project%20%3D%20keycloak%20and%20fixVersion%20%3D%203.4.2.Final>
.

Before you upgrade remember to backup your database and check the upgrade
guide <http://www.keycloak.org/docs/latest/upgrading/index.html> for
anything that may have changed.

From psilva at redhat.com  Tue Dec 26 12:41:21 2017
From: psilva at redhat.com (Pedro Igor Silva)
Date: Tue, 26 Dec 2017 15:41:21 -0200
Subject: [keycloak-dev] Admin Fine Grained Permissions
Message-ID: <CAJrcDBegy2MkHy1Zi=YFY_HAUWw3+aXZLWxdu_aiH+VxP17a8A@mail.gmail.com>

Right now, when you enable fine-grained permissions to users you must grant
to a specific user the "manage-users" roles. Otherwise, you will not be
able to see the "Add User" button even though you have a permission
granting the "manage" scope. It is quite weird actually, because you can
delete users.

This is because in UI we are checking only for "manage-users" when deciding
if this button should be shown or not.

One thing we could do here is change admin console to query for current
user permissions using the Entitlement API and use the permissions returned
in the RPT to decide whether or not something in the UI should be displayed.

I did some tests here and this approach seems to work fine and I think it
will improve a lot how we are handling permissions in admin console.

Regards.
Pedro Igor