From sthorger at redhat.com  Mon Apr  1 03:52:07 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 1 Apr 2019 09:52:07 +0200
Subject: [keycloak-dev] translate keycloak
In-Reply-To: <a35e46cf-d7e5-7ac4-87e2-314add1492c3@netdava.com>
References: <81d32d1e-1fbd-8068-1c56-b04fbe5d8652@netdava.com>
	<9e245cd6-6865-c3dd-80f3-56fa0a226c4f@netdava.com>
	<CAJgngAc3GeJrRBQqAORCOPob=OUHGSH4dxu3EgpHa+9QsbrXUg@mail.gmail.com>
	<c5da360b-ebd0-3c40-47a8-808ec5b27e7d@netdava.com>
	<CAJgngAdMjfhOS3qBf=pKocpAPBxPZ0L_q+Uvw=w-WMxT0N4TfQ@mail.gmail.com>
	<0e632a6e-3c74-0392-75df-055bb7c8e54f@netdava.com>
	<CAJgngAfAOMnq03_gBvy_gtXhxa9wMaNY9P=f8ny7ZprV3s_doQ@mail.gmail.com>
	<a35e46cf-d7e5-7ac4-87e2-314add1492c3@netdava.com>
Message-ID: <CAJgngAc6ZN=V-RkbNf+FLCv=H2bMb9FrzRgaWzP+00tkeCaK6A@mail.gmail.com>

I'm travelling this week so won't be able to answer until next week. I have
some concerns around this though and am struggling to see how it would work.

It seems Weblate free hosting would allow anyone to contribute without a
proper review process. It would be impossible for us to review/merge a PR
that contains updates to multiple translations from unknown sources.

Further, we need to support both regular PR contribution as well as
contribution through Weblate. Weblate should be an optional tool to use for
contributors, not a requirement.

On Wed, 27 Mar 2019 at 15:28, Eugen Stan <ieugen at netdava.com> wrote:

> Hello Stian,
>
> I've added Michal in CC. @Michal: this discussion is for using Weblate
> to translate Keycloak .
>
> I did a bit of research and Weblate does support PR's .
>
>
> https://docs.weblate.org/en/latest/admin/continuous.html?highlight=continuous#pushing-changes-from-hosted-weblate
>
>
> We are also slowly migrating to use "git subtree"  to manage translation
> updates instead of the git submodule.
>
> https://www.atlassian.com/blog/git/alternatives-to-git-submodule-git-subtree
>
> We "git subtree add --prefix translations https://path-to-git-repo.git
> master --squash" and we get a single commit . I imagine that working
> with PR's will probably eliminate the need for a separate git sub-project.
>
>
> With these updates in mind, do you think keycloak can be migrated to use
> (a self hosted or the weblate.org hosted ) Weblate instance ?
>
> I would like to help out with this process and get involved with
> Keycloak devel this way.
>
> I think the first thing to do is establish some requirements - some of
> them have been allready set in this thread.
>
>
> Regards,
>
> Eugen
>
>
> La 06.02.2019 16:38, Stian Thorgersen a scris:
> > I think you forgot to add Michal in CC (or perhaps you did BCC?)
> >
> > Due to the way to review and merge changes to Keycloak we can not
> > accept direct commits to the repository. All changes have to be made
> > through PRs.
> >
> > What would be very cool is if Weblate would support GitHub flow that
> > enabled it to send PRs including comments and links to view the
> > reviews of the translations easily.
> >
> > I don't think we can expect all contributions to come through Weblate
> > and will still need to be able to accept translations coming directly
> > as a PR.
> >
> > With that in mind and also just the fact that it would be rather
> > awkward I don't like the idea of syncing the changes.
> >
> > The short term solution would be to setup Weblate with webhooks so it
> > receives automatic updates, but still require changes to be done by
> > sending a PR. Not sure if Weblate would support committing to a users
> > fork rather than to the upstream repo.
> >
> > A longer term solution may be to consider extracting the translations
> > completely into a separate repository and have separate releases for
> > translations that are installed into Keycloak rather than bundled with
> > Keycloak itself. One issue here though is that the English main
> > translation would have to remain in the Keycloak repository. Not
> > really sure about this approach either.
> >
> > On Tue, 5 Feb 2019 at 11:13, Eugen Stan <ieugen at netdava.com
> > <mailto:ieugen at netdava.com>> wrote:
> >
> >     Hi Stian,
> >
> >
> >     I've added Michal to CC (creator of Weblate) and I hope he can
> >     pitch in.
> >
> >     I think the best thing is to go through the very good documentation
> on
> >     continuous translation and translation workflows :
> >     https://docs.weblate.org/en/latest/admin/continuous.html and
> >     https://docs.weblate.org/en/latest/workflows.html
> >
> >     Weblate has some features that can help with batching: lazy commits
> >     (commit once a day) and has some customization options on how to
> >     interact with the repository.
> >
> >     I believe with the Review workflow, Weblate does not commit to git
> >     until
> >     the translation has been approved so this might work well. However it
> >     will require a translator and a reviewer.
> >
> >     From our experience working with translators on apps - they need
> >     context
> >     and they need to see the translations in the app for them to
> >     figure out
> >     the best translation.
> >
> >     So most of the time we ended up doing the translation - best effort +
> >     deploy + review in the app and update the texts.
> >
> >     It also helps to have a single or just a few translators or a
> glossary
> >     to keep the translation consistent. Like in code, there are multiple
> >     ways of translating a string and like developers, translators or end
> >     users don't always agree on the result.
> >
> >     To have an idea on how the translation commits look, please see here
> >     https://github.com/GreatPeopleInside/keycloak/commits/master .
> >
> >     You will see why we want to choose another git repo for this -
> >     which is
> >     still my recommendation - it works very well, and it is simple. We
> had
> >     commits every 24h.
> >
> >     Another option is to keep the translations in another git repo
> >     (working
> >     repo) and manually merge them in keycloak (source) - there you
> control
> >     the frequency and you can merge just one language. This requires a
> bit
> >     of manual work but if it is done once a month it is ok I guess.
> >
> >
> >     Regards,
> >
> >     La 05.02.2019 11:47, Stian Thorgersen a scris:
> >     > Can you briefly describe how it works?
> >     >
> >     > With regards to repository and commits we can't use anything that
> >     > commits directly to the repository. We need something where
> >     updates to
> >     > a single language can be batched and sent as a PR with a single
> >     commit.
> >     >
> >     > On Tue, 5 Feb 2019 at 09:46, Eugen Stan <ieugen at netdava.com
> >     <mailto:ieugen at netdava.com>
> >     > <mailto:ieugen at netdava.com <mailto:ieugen at netdava.com>>> wrote:
> >     >
> >     >     Hello Stian,
> >     >
> >     >
> >     >     Weblate can wrok with the respository as is but it can
> >     introduce a lot
> >     >     of noise for the commits related to translation. That is why we
> >     >     chose to
> >     >     split the translations into another module.
> >     >
> >     >     In our case we have quite a few languages and a lot of text
> >     to be
> >     >     translated so there is a lot of noise commming as git
> >     commits from
> >     >     translators.
> >     >
> >     >     In keycloak I believe this will not matter that much since
> >     it has less
> >     >     text to be translated.
> >     >
> >     >     Weblate has the feature to implement translators + reviewers
> >     >     processes.
> >     >     It can also work with offline translation.
> >     >
> >     >     We had a very good experience with it so far. Michal (the
> >     creator of
> >     >     weblate) has proven very responsive and helpful even when we
> did
> >     >     not pay
> >     >     for maintenance. In our case we ended up paying for maintenance
> >     >     because
> >     >     it is worth it.
> >     >
> >     >     For keycloak we have the following languages translated for all
> >     >     components (except Admin) with professional translators or
> local
> >     >     people:
> >     >     Arabic, Dutch, English Australia, English UK, Latvian,
> >     Lithuanian,
> >     >     Norwegian, Romanian, Russian, Spanish, Swedish, Vietnamese and
> >     >     more are
> >     >     comming.
> >     >
> >     >     I think the setup can be done in a day or so.
> >     >
> >     >     Regards,
> >     >
> >     >     La 05.02.2019 08:16, Stian Thorgersen a scris:
> >     >     > I'm afraid using sub modules is not an option for us.
> >     >     >
> >     >     > I'm open to a tool to aid with translation, but we would
> >     need to
> >     >     > review what tools are available before selecting one. The
> >     tool would
> >     >     > have to be free for Open Source projects and self-hosting
> >     is not an
> >     >     > option. It would also have to work with the repository as
> >     is and not
> >     >     > require changes to where and how the translations are
> >     maintained.
> >     >     >
> >     >     > On Mon, 4 Feb 2019 at 14:41, Eugen Stan
> >     <ieugen at netdava.com <mailto:ieugen at netdava.com>
> >     >     <mailto:ieugen at netdava.com <mailto:ieugen at netdava.com>>
> >     >     > <mailto:ieugen at netdava.com <mailto:ieugen at netdava.com>
> >     <mailto:ieugen at netdava.com <mailto:ieugen at netdava.com>>>> wrote:
> >     >     >
> >     >     >     Bump.
> >     >     >
> >     >     >     Hello again. We managed to translate some languages
> >     already
> >     >     and we
> >     >     >     would
> >     >     >     like to contribute the translations upstream and
> hopefully
> >     >     improve the
> >     >     >     translation process.
> >     >     >
> >     >     >     We have some feedback from our process. We use this
> >     process
> >     >     internally
> >     >     >     and the idea is to have it working for keycloak open
> >     source
> >     >     >
> >     >     >     Proposal for Keycloak
> >     >     >
> >     >     >     - We propose to move the community translations in a
> >     >     separate git
> >     >     >     project - just with the translations
> >     >     >
> >     >     >     - That repository is going to be used by Weblate as a
> >     source of
> >     >     >     translations ( use Free Hosted Weblate -
> >     >     >     https://hosted.weblate.org/  )
> >     >     >
> >     >     >     - The translations project can be added as a git sub
> >     module
> >     >     to the
> >     >     >     keycloak project
> >     >     >
> >     >     >     - during build the translations can be copied to the
> final
> >     >     artifact
> >     >     >
> >     >     >
> >     >     >     We do this allready and we can help with the code
> >     >     migrations. Having
> >     >     >     this setup will improve the contributions to translations
> >     >     and also the
> >     >     >     ability to change the translations easily.
> >     >     >
> >     >     >
> >     >     >     WDYT?
> >     >     >
> >     >     >
> >     >     >     Regards,
> >     >     >
> >     >     >     Eugen
> >     >     >
> >     >     >     La 01.12.2018 19:22, Eugen Stan a scris:
> >     >     >     > Hello,
> >     >     >     >
> >     >     >     > Where can we find the translation files for Keycloak
> and
> >     >     what is the
> >     >     >     > process for upstreaming them?
> >     >     >     >
> >     >     >     > We are planning to deploy Keycloak for
> >     authentication for our
> >     >     >     services.
> >     >     >     > We have users all accross the globe and we have
> >     >     translators that
> >     >     >     we can
> >     >     >     > ask to translate.
> >     >     >     >
> >     >     >     > I'm planning to push the translations upstream once
> >     they are
> >     >     >     done (need
> >     >     >     > to get approbal on this).
> >     >     >     >
> >     >     >     >
> >     >     >     > Regards,
> >     >     >     >
> >     >     >     > Eugen
> >     >     >     >
> >     >     >     >
> >     >     >     >
> >     >     >
> >     >     >     _______________________________________________
> >     >     >     keycloak-dev mailing list
> >     >     >     keycloak-dev at lists.jboss.org
> >     <mailto:keycloak-dev at lists.jboss.org>
> >     >     <mailto:keycloak-dev at lists.jboss.org
> >     <mailto:keycloak-dev at lists.jboss.org>>
> >     >     <mailto:keycloak-dev at lists.jboss.org
> >     <mailto:keycloak-dev at lists.jboss.org>
> >     >     <mailto:keycloak-dev at lists.jboss.org
> >     <mailto:keycloak-dev at lists.jboss.org>>>
> >     >     >     https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >     >     >
> >     >
> >
>
>

From maurodewit at gmail.com  Mon Apr  1 05:59:19 2019
From: maurodewit at gmail.com (Mauro de Wit)
Date: Mon, 1 Apr 2019 11:59:19 +0200
Subject: [keycloak-dev] Keycloak session limiting (KEYCLOAK-849) (BA-93)
In-Reply-To: <CACihWx1WDLS56OWvW7ppMVBPG8aiy0RhaL_N1K21ZZTLOkTCdA@mail.gmail.com>
References: <CACihWx2N0zfT2pTSgRxtQnwavwNa7CiQefQ9O=GVrwX=7YB3pQ@mail.gmail.com>
	<CACihWx2Leb4ZeuvXk778O1DLOstMexzrki=xgxmFwnN=2YJGgg@mail.gmail.com>
	<CAJgngAfsW2PoaAkZUa7V8_tZuTQW-7a7vFzSYW7f9UiP_LkqUw@mail.gmail.com>
	<CACihWx2NnqaBMUdoGuzgUBsEAR4Ltx1xNdc0Quvk-F67aHMW=Q@mail.gmail.com>
	<CACihWx1JAxGz_Zn=Q0xCsB=T9wvDiEBwn6oB=pcooV6TP7NZqw@mail.gmail.com>
	<CALO-DfAoZpdzweZyx1iBXK=nU3XGqDpjgE8202QDJOraTFaYJQ@mail.gmail.com>
	<CACihWx2SWcXqq=gy+X3U=Ct0o2E+zaVAKpH-ahJS88+E64AqRQ@mail.gmail.com>
	<CAJgngAfJ2pgUgLBu2gXnmxrdicFzigPgfG=G4yudsPgz82pcZg@mail.gmail.com>
	<CACihWx2fi+tpT57grJ85pRdrj36f0cuvsErwoQUdSkUQeVrJOQ@mail.gmail.com>
	<CAJgngAdOEEAb4yAn4j=0aXE2=4fnjB8yMck8Yw4=88+SqRzvRw@mail.gmail.com>
	<CACihWx3Pk+_1Nbi+9uzvH1VchZCbf3rJi5sMvcHnCGMnD6Y8DA@mail.gmail.com>
	<CAJgngAduexRmVouqoYnEnmD-Lba5quKAZ5gC4dO7cBFM9kChqA@mail.gmail.com>
	<8d3aaed6-f878-ac5e-0132-0ceae2934471@redhat.com>
	<CACihWx1WDLS56OWvW7ppMVBPG8aiy0RhaL_N1K21ZZTLOkTCdA@mail.gmail.com>
Message-ID: <CACihWx1_pE49_4L8thAvKoALRfs8p7nTkmc3YB0XDnSAXVZB=w@mail.gmail.com>

Ok, I've found some time to continue on the session limiting task. I've
created a fork of the Keycloak repository from which I eventually will make
a PR. But first I need to finalize my work (Still need to add event
logging).
Currently I am in the process of creating Integration tests for this
mechanism and have it partly working.

But I'm having trouble creating multiple sessions from a single test.
Browsing through the existing tests I've not found any example how this is
done.
Can anyone point me to an existing example or provide me with information
howto initiate multiple sessions?

Here are the tests I've written:
https://github.com/mfdewit/keycloak/tree/KEYCLOAK-849-configurable-session-limits/testsuite/integration-arquillian/tests/base/src/test/java/org/keycloak/testsuite/sessionlimits

Specifically, the UserSessionLimitsTest is requiring me to login multiple
times. The RealmSessionTest is already working correctly as far as I can
tell.
Any help would be appreciated.







On Wed, 20 Mar 2019 at 15:00, Mauro de Wit <maurodewit at gmail.com> wrote:

> Makes sense. Thanks for the input guys.
> I'm on the right track then :)
>
> On Wed, 20 Mar 2019 at 14:59, Marek Posolda <mposolda at redhat.com> wrote:
>
>> On 20/03/2019 12:50, Stian Thorgersen wrote:
>>
>> I wasn't even aware we had the 'Post Login Flow'.
>>
>> From the description I would think that Post Login Flow is being executed
>> before the user session is created, while there's an authentication
>> session. So should be fine.
>>
>> Marek - can you confirm?
>>
>> Yes, exactly. User session doesn't yet exists when "Post Login Flow" is
>> executed. This flow exists exactly because of use-cases like this - having
>> the ability to execute the hooks after broker authentication. For example
>> some people wanted to execute TOTP after the authentication with "facebook"
>> broker etc.
>>
>> Marek
>>
>>
>> On Wed, 20 Mar 2019 at 12:38, Mauro de Wit <maurodewit at gmail.com> wrote:
>>
>>> Isn't the 'Post login flow' in the IDP configuration the place for this?
>>> Or do we want to avoid this since this is triggered after authentication is
>>> complete and the session in created.
>>> If this is the case, can you point me in the right direction to create a
>>> hook into the redirect from the external broker?
>>>
>>> On Tue, 19 Mar 2019 at 10:59, Stian Thorgersen <sthorger at redhat.com>
>>> wrote:
>>>
>>>> You're right. In fact this should probably be split into two separate
>>>> authenticators. For realm limits it should be checked as a first part
>>>> (otherwise you have users authenticating and expensive password hashing
>>>> when it's already known the session won't be permitted).
>>>>
>>>> For regular sessions authenticator works well, but to be honest I
>>>> completely forgot about brokering. For realm limits it's fine as that
>>>> authenticator can happen prior to the redirect, but for users there's no
>>>> hook after the redirected back from the external broker today. There's the
>>>> first login flow, but that only happens on the first time.
>>>>
>>>> On Mon, 18 Mar 2019 at 10:59, Mauro de Wit <maurodewit at gmail.com>
>>>> wrote:
>>>>
>>>>> Ok, I'm missing some fundamental understanding here. Please help :)
>>>>>
>>>>> In case of the browser flow, the authentication flow is executed upon
>>>>> loading a page using the browser. At this time checks are being performed
>>>>> to see if the user is already logged on. If this is the case, no
>>>>> authentication has to be performed and the user is presented the requested
>>>>> page.
>>>>> But if the user is not yet logged on, the cookie authenticator can't
>>>>> do anything usefull resulting in the next authenticator to trigger.
>>>>> Eventually the 'browser forms' authenticator presents a login screen.
>>>>>
>>>>> Given the fact that we need to deny the user access in case a session
>>>>> already exists for his/her account on another machine, we need to know who
>>>>> this user is. How can we know which user we are dealing with at the start
>>>>> of the flow?
>>>>> I can see this working for limiting the number of sessions for each
>>>>> realm, but not for limiting sessions bound to individual user accounts.
>>>>>
>>>>>
>>>>>
>>>>> On Mon, 18 Mar 2019 at 09:19, Stian Thorgersen <sthorger at redhat.com>
>>>>> wrote:
>>>>>
>>>>>> The authenticator should be added after the cookie authenticator, not
>>>>>> at the end. That will make it take affect for IdP logins as well. So it's a
>>>>>> matter of configuring it in two flows browser and direct grant.
>>>>>>
>>>>>> I appreciate it may not be the best usability, but I don't want to
>>>>>> introduce something special/hard-coded for this feature. A later
>>>>>> improvement could be to improve on the authentication flows. To have
>>>>>> different elements in a flow and not just executions as well as potentially
>>>>>> having some pre-flow checks that are done in all flows. I'd say this
>>>>>> approach is good enough though at least for now.
>>>>>>
>>>>>> On Mon, 18 Mar 2019 at 09:00, Mauro de Wit <maurodewit at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> That is indeed one of the downsides of this approach.
>>>>>>> But can a misconfiguration of this functionality do any harm,
>>>>>>> besides some inconsistent behavior between authentication methods?
>>>>>>>
>>>>>>> @stian at redhat.com <stian at redhat.com> any thoughts?
>>>>>>>
>>>>>>> On Fri, 15 Mar 2019 at 15:23, Jared Blashka <jblashka at redhat.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> If this is done via an authenticator wouldn't you have to make sure
>>>>>>>> that this authenticator is present (and all the same settings are
>>>>>>>> maintained) in the browser flow as well as the direct access flow as well
>>>>>>>> as the login flows for all configured identity providers? It seems like it
>>>>>>>> would be quite easy to make a mistake in that process and misconfigure
>>>>>>>> something somewhere.
>>>>>>>>
>>>>>>>> On Fri, Mar 15, 2019 at 5:41 AM Mauro de Wit <maurodewit at gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> I've started to create a simple proof of concept and want to check
>>>>>>>>> if I
>>>>>>>>> have my facts straight.
>>>>>>>>> As previously discussed this functionality should be provided by a
>>>>>>>>> custom
>>>>>>>>> Authenticator that is configured in an authentication flow.
>>>>>>>>>
>>>>>>>>> What I've done so far is:
>>>>>>>>> - Created implementations for both the Authenticator and
>>>>>>>>> AuthenticatorFactory interfaces.
>>>>>>>>> - Added a set of ProviderConfigProperty instances that allow the
>>>>>>>>> desired
>>>>>>>>> configuration.
>>>>>>>>> - Perform the check if any session limits are exceeded inside the
>>>>>>>>> authenticate() method of the Authenticator class. (Any session
>>>>>>>>> invalidation
>>>>>>>>> will be performed here as well)
>>>>>>>>>
>>>>>>>>> Now, in order to use session limiting for regular
>>>>>>>>> username/password form
>>>>>>>>> logins, I have created a copy of the 'browser flow' and added this
>>>>>>>>> Authenticator as a 'required' execution at the end of the flow.
>>>>>>>>> In our case we allow IDP logins as well. And to use this
>>>>>>>>> functionality for
>>>>>>>>> these logins, I've created a new authentication flow containing
>>>>>>>>> just this
>>>>>>>>> Authenticator. Finally this flow is selected in the 'Post login
>>>>>>>>> flow' of
>>>>>>>>> the IDP configuration.
>>>>>>>>> For both scenarios the Authenticator seems to be triggered at the
>>>>>>>>> right
>>>>>>>>> time and I should be able to apply the session limiting rules.
>>>>>>>>>
>>>>>>>>> Any thoughts or comments so far?
>>>>>>>>>
>>>>>>>>> On Tue, 12 Mar 2019 at 14:53, Mauro de Wit <maurodewit at gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> > Ok, thanks for the clarification.
>>>>>>>>> >
>>>>>>>>> > On Tue, 12 Mar 2019 at 12:39, Stian Thorgersen <
>>>>>>>>> sthorger at redhat.com>
>>>>>>>>> > wrote:
>>>>>>>>> >
>>>>>>>>> >> It should be a pluggable part of the authentication flow and
>>>>>>>>> not a
>>>>>>>>> >> hardcoded element. There is no other way to plug in to the
>>>>>>>>> authentication
>>>>>>>>> >> flow other than creating an authenticator. An authenticator
>>>>>>>>> doesn't need to
>>>>>>>>> >> provide a challenge though so it can be used in this instance.
>>>>>>>>> >>
>>>>>>>>> >> On Tue, 12 Mar 2019 at 10:57, Mauro de Wit <
>>>>>>>>> maurodewit at gmail.com> wrote:
>>>>>>>>> >>
>>>>>>>>> >>> Hello,
>>>>>>>>> >>>
>>>>>>>>> >>> I am sending this e-mail because I have some questions
>>>>>>>>> regarding the
>>>>>>>>> >>> enhancement request that enables configurable session limiting
>>>>>>>>> in
>>>>>>>>> >>> Keycloak
>>>>>>>>> >>> as discussed here:
>>>>>>>>> >>> https://issues.jboss.org/browse/KEYCLOAK-849 (The developer
>>>>>>>>> that Marc
>>>>>>>>> >>> Wijma
>>>>>>>>> >>> referred to in his comment as being available for this task is
>>>>>>>>> me btw :))
>>>>>>>>> >>>
>>>>>>>>> >>> In the comments a solution is proposed that makes use of a
>>>>>>>>> custom
>>>>>>>>> >>> Authenticator that is dropped into the authentication flow
>>>>>>>>> where it can
>>>>>>>>> >>> be
>>>>>>>>> >>> configured. While I can see the benefit of leveraging the
>>>>>>>>> existing
>>>>>>>>> >>> components as much as possible (including the configuration
>>>>>>>>> options in
>>>>>>>>> >>> that
>>>>>>>>> >>> flow), I am wondering if this is the best solution. As far as
>>>>>>>>> I can tell,
>>>>>>>>> >>> this component is not performing any authentication at all.
>>>>>>>>> Moreover this
>>>>>>>>> >>> functionality operates 'above' the authentication mechanisms
>>>>>>>>> and should
>>>>>>>>> >>> apply to all of them.
>>>>>>>>> >>> So is an Authenticator really the desired place to implement
>>>>>>>>> this? Or is
>>>>>>>>> >>> this just the quickest route, while not being the most
>>>>>>>>> desirable option
>>>>>>>>> >>> for
>>>>>>>>> >>> the long term? What would be an alternative approach be? That
>>>>>>>>> would place
>>>>>>>>> >>> this implementation and configuration in the existing Session
>>>>>>>>> >>> configuration
>>>>>>>>> >>> code for instance.
>>>>>>>>> >>>
>>>>>>>>> >>> I just now started investigating this task and looking into
>>>>>>>>> the options
>>>>>>>>> >>> that would meet our requirements. Hope to hear from you.
>>>>>>>>> >>>
>>>>>>>>> >>> Regards
>>>>>>>>> >>>
>>>>>>>>> >>> Mauro
>>>>>>>>> >>>
>>>>>>>>> >>> >
>>>>>>>>> >>> _______________________________________________
>>>>>>>>> >>> keycloak-dev mailing list
>>>>>>>>> >>> keycloak-dev at lists.jboss.org
>>>>>>>>> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>>> >>>
>>>>>>>>> >>
>>>>>>>>> _______________________________________________
>>>>>>>>> keycloak-dev mailing list
>>>>>>>>> keycloak-dev at lists.jboss.org
>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>>>
>>>>>>>>
>>

From mposolda at redhat.com  Mon Apr  1 07:22:44 2019
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 1 Apr 2019 13:22:44 +0200
Subject: [keycloak-dev] Keycloak session limiting (KEYCLOAK-849) (BA-93)
In-Reply-To: <CACihWx1_pE49_4L8thAvKoALRfs8p7nTkmc3YB0XDnSAXVZB=w@mail.gmail.com>
References: <CACihWx2N0zfT2pTSgRxtQnwavwNa7CiQefQ9O=GVrwX=7YB3pQ@mail.gmail.com>
	<CAJgngAfsW2PoaAkZUa7V8_tZuTQW-7a7vFzSYW7f9UiP_LkqUw@mail.gmail.com>
	<CACihWx2NnqaBMUdoGuzgUBsEAR4Ltx1xNdc0Quvk-F67aHMW=Q@mail.gmail.com>
	<CACihWx1JAxGz_Zn=Q0xCsB=T9wvDiEBwn6oB=pcooV6TP7NZqw@mail.gmail.com>
	<CALO-DfAoZpdzweZyx1iBXK=nU3XGqDpjgE8202QDJOraTFaYJQ@mail.gmail.com>
	<CACihWx2SWcXqq=gy+X3U=Ct0o2E+zaVAKpH-ahJS88+E64AqRQ@mail.gmail.com>
	<CAJgngAfJ2pgUgLBu2gXnmxrdicFzigPgfG=G4yudsPgz82pcZg@mail.gmail.com>
	<CACihWx2fi+tpT57grJ85pRdrj36f0cuvsErwoQUdSkUQeVrJOQ@mail.gmail.com>
	<CAJgngAdOEEAb4yAn4j=0aXE2=4fnjB8yMck8Yw4=88+SqRzvRw@mail.gmail.com>
	<CACihWx3Pk+_1Nbi+9uzvH1VchZCbf3rJi5sMvcHnCGMnD6Y8DA@mail.gmail.com>
	<CAJgngAduexRmVouqoYnEnmD-Lba5quKAZ5gC4dO7cBFM9kChqA@mail.gmail.com>
	<8d3aaed6-f878-ac5e-0132-0ceae2934471@redhat.com>
	<CACihWx1WDLS56OWvW7ppMVBPG8aiy0RhaL_N1K21ZZTLOkTCdA@mail.gmail.com>
	<CACihWx1_pE49_4L8thAvKoALRfs8p7nTkmc3YB0XDnSAXVZB=w@mail.gmail.com>
Message-ID: <9c832dce-71b7-1877-c10f-ee4593beac04@redhat.com>

Maybe easiest is to login and then call :

driver.manage().deleteAllCookies();

This will delete all cookies, so you can login again within same browser (web driver) and the previous session is still valid (cookies were manually removed from browser, but session is still alive on
server-side as you did not logout). See for example LoginTest.loginExpiredCodeAndExpiredCookies() for some inspiration.

Marek

On 01/04/2019 11:59, Mauro de Wit wrote:
> Ok, I've found some time to continue on the session limiting task. 
> I've created a fork of the Keycloak repository from which I eventually 
> will make a PR. But first I need to finalize my work (Still need to 
> add event logging).
> Currently I am in the process of creating Integration tests for this 
> mechanism and have it partly working.
>
> But I'm having trouble creating multiple sessions from a single test. 
> Browsing through the existing tests I've not found any example how 
> this is done.
> Can anyone point me to an existing example or provide me with 
> information howto initiate multiple sessions?
>
> Here are the tests I've written:
> https://github.com/mfdewit/keycloak/tree/KEYCLOAK-849-configurable-session-limits/testsuite/integration-arquillian/tests/base/src/test/java/org/keycloak/testsuite/sessionlimits
>
> Specifically, the UserSessionLimitsTest is requiring me to login 
> multiple times. The RealmSessionTest is already working correctly as 
> far as I can tell.
> Any help would be appreciated.
>
>
>
>
>
>
>
> On Wed, 20 Mar 2019 at 15:00, Mauro de Wit <maurodewit at gmail.com 
> <mailto:maurodewit at gmail.com>> wrote:
>
>     Makes sense. Thanks for the input guys.
>     I'm on the right track then :)
>
>     On Wed, 20 Mar 2019 at 14:59, Marek Posolda <mposolda at redhat.com
>     <mailto:mposolda at redhat.com>> wrote:
>
>         On 20/03/2019 12:50, Stian Thorgersen wrote:
>>         I wasn't even aware we had the 'Post Login Flow'.
>>
>>         From the description I would think that Post Login Flow is
>>         being executed before the user session is created, while
>>         there's an authentication session. So should be fine.
>>
>>         Marek - can you confirm?
>
>         Yes, exactly. User session doesn't yet exists when "Post Login
>         Flow" is executed. This flow exists exactly because of
>         use-cases like this - having the ability to execute the hooks
>         after broker authentication. For example some people wanted to
>         execute TOTP after the authentication with "facebook" broker etc.
>
>         Marek
>
>>
>>         On Wed, 20 Mar 2019 at 12:38, Mauro de Wit
>>         <maurodewit at gmail.com <mailto:maurodewit at gmail.com>> wrote:
>>
>>             Isn't the 'Post login flow' in the IDP configuration the
>>             place for this? Or do we want to avoid this since this is
>>             triggered after authentication is complete and the
>>             session in created.
>>             If this is?the case, can you point me in the right
>>             direction to create a hook into the redirect from the
>>             external broker?
>>
>>             On Tue, 19 Mar 2019 at 10:59, Stian Thorgersen
>>             <sthorger at redhat.com <mailto:sthorger at redhat.com>> wrote:
>>
>>                 You're right. In fact this should probably be split
>>                 into two separate authenticators. For realm limits it
>>                 should be checked as a first part (otherwise you have
>>                 users authenticating and expensive password hashing
>>                 when it's already known the session won't be permitted).
>>
>>                 For regular sessions authenticator works well, but to
>>                 be honest I completely forgot about brokering. For
>>                 realm limits it's fine as that authenticator can
>>                 happen prior to the redirect, but for users there's
>>                 no hook after the redirected back from the external
>>                 broker today. There's the first login flow, but that
>>                 only happens on the first time.
>>
>>                 On Mon, 18 Mar 2019 at 10:59, Mauro de Wit
>>                 <maurodewit at gmail.com <mailto:maurodewit at gmail.com>>
>>                 wrote:
>>
>>                     Ok, I'm missing some fundamental understanding
>>                     here. Please help :)
>>
>>                     In case of the browser flow, the authentication
>>                     flow is executed upon loading a page using the
>>                     browser. At this time checks are being performed
>>                     to see if the user is already logged on. If this
>>                     is the case, no authentication has to be
>>                     performed and the user is presented the requested
>>                     page.
>>                     But if the user is not yet logged on, the cookie
>>                     authenticator can't do anything usefull resulting
>>                     in the next authenticator to trigger. Eventually
>>                     the 'browser forms' authenticator presents a
>>                     login screen.
>>
>>                     Given the fact that we need to deny the user
>>                     access in case a session already exists for
>>                     his/her account on another machine, we need to
>>                     know who this user is. How can we know which user
>>                     we are dealing with at the start of the flow?
>>                     I can see this working for limiting the number of
>>                     sessions for each realm, but not for limiting
>>                     sessions bound to individual user accounts.
>>
>>
>>
>>                     On Mon, 18 Mar 2019 at 09:19, Stian Thorgersen
>>                     <sthorger at redhat.com
>>                     <mailto:sthorger at redhat.com>> wrote:
>>
>>                         The authenticator should be added after the
>>                         cookie authenticator, not at the end. That
>>                         will make it take affect for IdP logins as
>>                         well. So it's a matter of configuring it in
>>                         two flows browser and direct grant.
>>
>>                         I appreciate it may not be the best
>>                         usability, but I don't want to introduce
>>                         something special/hard-coded for this
>>                         feature. A later improvement could be to
>>                         improve on the authentication flows. To have
>>                         different elements in a flow and not just
>>                         executions as well as potentially having some
>>                         pre-flow checks that are done in all flows.
>>                         I'd say this approach is good enough though
>>                         at least for now.
>>
>>                         On Mon, 18 Mar 2019 at 09:00, Mauro de Wit
>>                         <maurodewit at gmail.com
>>                         <mailto:maurodewit at gmail.com>> wrote:
>>
>>                             That is indeed one of the downsides of
>>                             this approach.
>>                             But can a misconfiguration of this
>>                             functionality do any harm, besides some
>>                             inconsistent behavior between
>>                             authentication methods?
>>
>>                             @stian at redhat.com
>>                             <mailto:stian at redhat.com> any thoughts?
>>
>>                             On Fri, 15 Mar 2019 at 15:23, Jared
>>                             Blashka <jblashka at redhat.com
>>                             <mailto:jblashka at redhat.com>> wrote:
>>
>>                                 If this is done via an authenticator
>>                                 wouldn't you have to make sure that
>>                                 this authenticator is present (and
>>                                 all the same settings are maintained)
>>                                 in the browser flow as well as the
>>                                 direct access flow as well as the
>>                                 login flows for all configured
>>                                 identity providers? It seems like it
>>                                 would be quite easy to make a mistake
>>                                 in that process and misconfigure
>>                                 something somewhere.
>>
>>                                 On Fri, Mar 15, 2019 at 5:41 AM Mauro
>>                                 de Wit <maurodewit at gmail.com
>>                                 <mailto:maurodewit at gmail.com>> wrote:
>>
>>                                     I've started to create a simple
>>                                     proof of concept and want to
>>                                     check if I
>>                                     have my facts straight.
>>                                     As previously discussed this
>>                                     functionality should be provided
>>                                     by a custom
>>                                     Authenticator that is configured
>>                                     in an authentication flow.
>>
>>                                     What I've done so far is:
>>                                     - Created implementations for
>>                                     both the Authenticator and
>>                                     AuthenticatorFactory interfaces.
>>                                     - Added a set of
>>                                     ProviderConfigProperty instances
>>                                     that allow the desired
>>                                     configuration.
>>                                     - Perform the check if any
>>                                     session limits are exceeded
>>                                     inside the
>>                                     authenticate() method of the
>>                                     Authenticator class. (Any session
>>                                     invalidation
>>                                     will be performed here as well)
>>
>>                                     Now, in order to use session
>>                                     limiting for regular
>>                                     username/password form
>>                                     logins, I have created a copy of
>>                                     the 'browser flow' and added this
>>                                     Authenticator as a 'required'
>>                                     execution at the end of the flow.
>>                                     In our case we allow IDP logins
>>                                     as well. And to use this
>>                                     functionality for
>>                                     these logins, I've created a new
>>                                     authentication flow containing
>>                                     just this
>>                                     Authenticator. Finally this flow
>>                                     is selected in the 'Post login
>>                                     flow' of
>>                                     the IDP configuration.
>>                                     For both scenarios the
>>                                     Authenticator seems to be
>>                                     triggered at the right
>>                                     time and I should be able to
>>                                     apply the session limiting rules.
>>
>>                                     Any thoughts or comments so far?
>>
>>                                     On Tue, 12 Mar 2019 at 14:53,
>>                                     Mauro de Wit
>>                                     <maurodewit at gmail.com
>>                                     <mailto:maurodewit at gmail.com>> wrote:
>>
>>                                     > Ok, thanks for the clarification.
>>                                     >
>>                                     > On Tue, 12 Mar 2019 at 12:39,
>>                                     Stian Thorgersen
>>                                     <sthorger at redhat.com
>>                                     <mailto:sthorger at redhat.com>>
>>                                     > wrote:
>>                                     >
>>                                     >> It should be a pluggable part
>>                                     of the authentication flow and not a
>>                                     >> hardcoded element. There is no
>>                                     other way to plug in to the
>>                                     authentication
>>                                     >> flow other than creating an
>>                                     authenticator. An authenticator
>>                                     doesn't need to
>>                                     >> provide a challenge though so
>>                                     it can be used in this instance.
>>                                     >>
>>                                     >> On Tue, 12 Mar 2019 at 10:57,
>>                                     Mauro de Wit
>>                                     <maurodewit at gmail.com
>>                                     <mailto:maurodewit at gmail.com>> wrote:
>>                                     >>
>>                                     >>> Hello,
>>                                     >>>
>>                                     >>> I am sending this e-mail
>>                                     because I have some questions
>>                                     regarding the
>>                                     >>> enhancement request that
>>                                     enables configurable session
>>                                     limiting in
>>                                     >>> Keycloak
>>                                     >>> as discussed here:
>>                                     >>>
>>                                     https://issues.jboss.org/browse/KEYCLOAK-849
>>                                     (The developer that Marc
>>                                     >>> Wijma
>>                                     >>> referred to in his comment as
>>                                     being available for this task is
>>                                     me btw :))
>>                                     >>>
>>                                     >>> In the comments a solution is
>>                                     proposed that makes use of a custom
>>                                     >>> Authenticator that is dropped
>>                                     into the authentication flow
>>                                     where it can
>>                                     >>> be
>>                                     >>> configured. While I can see
>>                                     the benefit of leveraging the
>>                                     existing
>>                                     >>> components as much as
>>                                     possible (including the
>>                                     configuration options in
>>                                     >>> that
>>                                     >>> flow), I am wondering if this
>>                                     is the best solution. As far as I
>>                                     can tell,
>>                                     >>> this component is not
>>                                     performing any authentication at
>>                                     all. Moreover this
>>                                     >>> functionality operates
>>                                     'above' the authentication
>>                                     mechanisms and should
>>                                     >>> apply to all of them.
>>                                     >>> So is an Authenticator really
>>                                     the desired place to implement
>>                                     this? Or is
>>                                     >>> this just the quickest route,
>>                                     while not being the most
>>                                     desirable option
>>                                     >>> for
>>                                     >>> the long term? What would be
>>                                     an alternative approach be? That
>>                                     would place
>>                                     >>> this implementation and
>>                                     configuration in the existing Session
>>                                     >>> configuration
>>                                     >>> code for instance.
>>                                     >>>
>>                                     >>> I just now started
>>                                     investigating this task and
>>                                     looking into the options
>>                                     >>> that would meet our
>>                                     requirements. Hope to hear from you.
>>                                     >>>
>>                                     >>> Regards
>>                                     >>>
>>                                     >>> Mauro
>>                                     >>>
>>                                     >>> >
>>                                     >>>
>>                                     _______________________________________________
>>                                     >>> keycloak-dev mailing list
>>                                     >>> keycloak-dev at lists.jboss.org
>>                                     <mailto:keycloak-dev at lists.jboss.org>
>>                                     >>>
>>                                     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>                                     >>>
>>                                     >>
>>                                     _______________________________________________
>>                                     keycloak-dev mailing list
>>                                     keycloak-dev at lists.jboss.org
>>                                     <mailto:keycloak-dev at lists.jboss.org>
>>                                     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>


From jerry.saravia at virginpulse.com  Mon Apr  1 08:53:05 2019
From: jerry.saravia at virginpulse.com (Jerry Saravia)
Date: Mon, 1 Apr 2019 12:53:05 +0000
Subject: [keycloak-dev] Override "native" Keycloak providers
In-Reply-To: <CAJgngAfm8ogwes79dPWwFL7WA2NBmiZg=_ZMA2fCz5wDfxwxgA@mail.gmail.com>
References: <1DDE98A1-431C-49BF-B20B-AB00C61CF763@contoso.com>
	<CAK-7U1hsOGjcZnv1BAf0GV1esEQ_Nyg3qdizoo9XT2kZTzX00A@mail.gmail.com>
	<CAJgngAfm8ogwes79dPWwFL7WA2NBmiZg=_ZMA2fCz5wDfxwxgA@mail.gmail.com>
Message-ID: <00696B28-1A74-43AC-9152-E044E235E03B@virginpulse.com>

Hey guys,

Thank you for commenting.

@Stian, the default-provider option works well enough for times where native keycloak code doesn?t use a specific ID to request the provider.

However, for cases like the SAML provider as Thomas highlighted, it doesn?t work. I too had to change some of the SAML behavior such as the template that is used for errors and the way that some of the errors are handled.

I?ll be trying Thomas? approach for now since it seems like it?ll help.


Jerry Saravia
Software Engineer
T(516) 603-6914
M516-603-6914
virginpulse.com
|virginpulse.com/global-challenge
492 Old Connecticut Path, Framingham, MA 01701, USA
Australia | Bosnia and Herzegovina | Brazil | Canada | Singapore | Switzerland | United Kingdom | USA
Confidentiality Notice: The information contained in this e-mail, including any attachment(s), is intended solely for use by the designated recipient(s). Unauthorized use, dissemination, distribution, or reproduction of this message by anyone other than the intended recipient(s), or a person designated as responsible for delivering such messages to the intended recipient, is strictly prohibited and may be unlawful. This e-mail may contain proprietary, confidential or privileged information. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Virgin Pulse, Inc. If you have received this message in error, or are not the named recipient(s), please immediately notify the sender and delete this e-mail message.
v2.50
From: Stian Thorgersen <sthorger at redhat.com>
Reply-To: "stian at redhat.com" <stian at redhat.com>
Date: Wednesday, March 27, 2019 at 20:35
To: Thomas Darimont <thomas.darimont at googlemail.com>
Cc: Jerry Saravia <jerry.saravia at virginpulse.com>, "keycloak-dev at lists.jboss.org" <keycloak-dev at lists.jboss.org>
Subject: Re: [keycloak-dev] Override "native" Keycloak providers

This email originates outside Virgin Pulse.

Instead of trying to deploy a custom provider with the same id as the default provider you can change the default provider for an SPI. In standalone.xml just set the default-provider for the SPI to your own. This will work when Keycloak doesn't specify directly what provider to get.

It was never supported to load a custom provider with same ID as the built-in providers. I believe that was a side-effect made possible when we introduced the ability to hot deploy providers.

On Wed, 27 Mar 2019 at 23:27, Thomas Darimont <thomas.darimont at googlemail.com<mailto:thomas.darimont at googlemail.com>> wrote:
Hello Jerry,

I encountered a similar problem with Keycloak 4.x when I needed to
implement my own SamlProtocolFactory to customize the SAML Message handling.
See: http://lists.jboss.org/pipermail/keycloak-dev/2019-February/011745.html<https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.jboss.org%2Fpipermail%2Fkeycloak-dev%2F2019-February%2F011745.html&data=02%7C01%7Cjerry.saravia%40virginpulse.com%7C29bb3f9e3749470e566e08d6b3154a33%7Cb123a16e892b4cf6a55a6f8c7606a035%7C0%7C0%7C636893301422983083&sdata=3K3gjAOMGUwncJ7qMQ%2F8t62AQ67atSu9POMe67Y5m8g%3D&reserved=0>
The only way I could get this to work was to add my custom extension jar to
the module.xml of the keycloak-services module,
see the link for details.

It's by far not the best solution, but at least it works.

Cheers,
Thomas

On Wed, 27 Mar 2019 at 22:28, Jerry Saravia <jerry.saravia at virginpulse.com<mailto:jerry.saravia at virginpulse.com>>
wrote:

> Hello,
>
>
>
> We?ve been using version 3.4.3 for a while now and are attempting to
> upgrade to 4.8 and we?ve run into some issues.
>
>
>
> Summary: We have created our own providers with the same PROVIDER_ID as
> some of the built in providers. For example, PasswordCredentialProvider has
> a provider id of ?keycloak-password? and we created our own with the same
> id that gets loaded after the native one. This worked because in 3.4.3
> providers that were using the same id would still have their factories
> added to the factory map.
>
>
>
> See this link here for 3.4.3 changes:
>
>
> https://github.com/keycloak/keycloak/blob/3.4.3.Final/services/src/main/java/org/keycloak/provider/ProviderManager.java#L96-L100<https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fkeycloak%2Fkeycloak%2Fblob%2F3.4.3.Final%2Fservices%2Fsrc%2Fmain%2Fjava%2Forg%2Fkeycloak%2Fprovider%2FProviderManager.java%23L96-L100&data=02%7C01%7Cjerry.saravia%40virginpulse.com%7C29bb3f9e3749470e566e08d6b3154a33%7Cb123a16e892b4cf6a55a6f8c7606a035%7C0%7C0%7C636893301422993096&sdata=6bOZewlq0eMb7L5jgGU8OcdJoj5CLkBKEGKscHXSC4M%3D&reserved=0>
>
>
>
> These are the 4.8 changes
>
>
> https://github.com/keycloak/keycloak/blob/4.8.3.Final/services/src/main/java/org/keycloak/provider/ProviderManager.java#L96-L99<https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fkeycloak%2Fkeycloak%2Fblob%2F4.8.3.Final%2Fservices%2Fsrc%2Fmain%2Fjava%2Forg%2Fkeycloak%2Fprovider%2FProviderManager.java%23L96-L99&data=02%7C01%7Cjerry.saravia%40virginpulse.com%7C29bb3f9e3749470e566e08d6b3154a33%7Cb123a16e892b4cf6a55a6f8c7606a035%7C0%7C0%7C636893301423003105&sdata=tOzksl43mTvHNFOpwDR2GVJdV1UcgpC5ASNq9FG4K0s%3D&reserved=0>
>
>
>
> In 4.8, the fully qualified class name (FQCN) is not longer used. Instead
> it uses the provider id and the spi name. I can no longer use the same
> PROVIDER_ID as the native providers to ?override? them, but sometimes there
> is code that gets the provider specifically by id. For example, in the
> UpdatePassword required action we have this:
>
>
>
> PasswordCredentialProvider passwordProvider =
> (PasswordCredentialProvider)context.getSession().getProvider(CredentialProvider.class,
> PasswordCredentialProviderFactory.PROVIDER_ID);
>
>
>
> In 3.4.3 because our provider was loaded we were able to inject into code
> that normally isn?t overridable. We did the same for the
> OIDCLoginProtocolFactory to alter some token endpoint behavior even the
> UpdatePassword required action itself rather than making a brand new
> required action that is a ?second rate? because it isn?t native to Keycloak.
>
>
>
> Is there a solution for this in 4.8.3? I see this change was made in
> 4.0.0.Beta1 according to some of the history.
>
>
>
> J
>
>
> Jerry Saravia
> Software Engineer
> T(516) 603-6914
> M516-603-6914
> virginpulse.com<https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fvirginpulse.com&data=02%7C01%7Cjerry.saravia%40virginpulse.com%7C29bb3f9e3749470e566e08d6b3154a33%7Cb123a16e892b4cf6a55a6f8c7606a035%7C0%7C0%7C636893301423003105&sdata=3yp0HaDcuQbZOFP1YvDNYLNzm%2Bo1hpAt8zRgVS7eJ8o%3D&reserved=0>
> |virginpulse.com/global-challenge<https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fvirginpulse.com%2Fglobal-challenge&data=02%7C01%7Cjerry.saravia%40virginpulse.com%7C29bb3f9e3749470e566e08d6b3154a33%7Cb123a16e892b4cf6a55a6f8c7606a035%7C0%7C0%7C636893301423013114&sdata=Vx2gyBFI0DaPSoAjof7PQmwqX59pnQ54jelBdf5sljU%3D&reserved=0>
> 492 Old Connecticut Path, Framingham, MA 01701, USA
> Australia | Bosnia and Herzegovina | Brazil | Canada | Singapore |
> Switzerland | United Kingdom | USA
> Confidentiality Notice: The information contained in this e-mail,
> including any attachment(s), is intended solely for use by the designated
> recipient(s). Unauthorized use, dissemination, distribution, or
> reproduction of this message by anyone other than the intended
> recipient(s), or a person designated as responsible for delivering such
> messages to the intended recipient, is strictly prohibited and may be
> unlawful. This e-mail may contain proprietary, confidential or privileged
> information. Any views or opinions expressed are solely those of the author
> and do not necessarily represent those of Virgin Pulse, Inc. If you have
> received this message in error, or are not the named recipient(s), please
> immediately notify the sender and delete this e-mail message.
> v2.48
> _______________________________________________
> 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://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.jboss.org%2Fmailman%2Flistinfo%2Fkeycloak-dev&data=02%7C01%7Cjerry.saravia%40virginpulse.com%7C29bb3f9e3749470e566e08d6b3154a33%7Cb123a16e892b4cf6a55a6f8c7606a035%7C0%7C0%7C636893301423013114&sdata=UqTmjXMSUeW2DRQjt%2Bkb2HJdYAgXNXuJcoJz8UNwmKg%3D&reserved=0>
_______________________________________________
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://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.jboss.org%2Fmailman%2Flistinfo%2Fkeycloak-dev&data=02%7C01%7Cjerry.saravia%40virginpulse.com%7C29bb3f9e3749470e566e08d6b3154a33%7Cb123a16e892b4cf6a55a6f8c7606a035%7C0%7C0%7C636893301423023127&sdata=5M2GH13u6bZDqnNscCfpdWlnvDWctdTR41wuWVpkcbE%3D&reserved=0>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image549556.png
Type: image/png
Size: 681 bytes
Desc: image549556.png
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20190401/7e1948cf/attachment-0003.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image164323.png
Type: image/png
Size: 687 bytes
Desc: image164323.png
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20190401/7e1948cf/attachment-0004.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image344808.png
Type: image/png
Size: 757 bytes
Desc: image344808.png
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20190401/7e1948cf/attachment-0005.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image241394.jpg
Type: image/jpeg
Size: 24939 bytes
Desc: image241394.jpg
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20190401/7e1948cf/attachment-0001.jpg 

From nikita.rousseau at gfi.fr  Mon Apr  1 11:47:13 2019
From: nikita.rousseau at gfi.fr (Rousseau Nikita)
Date: Mon, 1 Apr 2019 15:47:13 +0000
Subject: [keycloak-dev] Mixed tokens with an upstream application (change
	request proposal)
Message-ID: <DB6PR05MB46470B8A99F09D02447392428F550@DB6PR05MB4647.eurprd05.prod.outlook.com>

Hello everybody,



I'm contacting the dev community of Keycloak-Gatekeeper concerning the Keycloak access token lookup behavior.

A few links :

  *   The full story is here : https://issues.jboss.org/browse/KEYCLOAK-9885
  *   Associated PR : https://github.com/keycloak/keycloak-gatekeeper/pull/473

The long story made short :

I am deploying an application that has been configured to work behind a proxy. The proxy must set specific HTTP Headers (i.e. X-Auth-Username, X-Auth-Email) if the request is successfully authenticated and forwards the request to the upstream.
The application is working in "blind" mode : it looks only for HTTP headers sent by the proxy (the application does not have any Gatekeeper specific configuration).

However, in its authentication process, the application set a Bearer token. All queries that are targeting the application API are authenticated against this Bearer token.

For now, Keycloak Gatekeeper inspects the Authorization header first in order to verify the Keycloak access token. Since the Bearer token is not issued by Keycloak, but by the proxied application, the token is refused and the request redirected to the SSO. There are no fallback to the cookie if the Authorization header check fails.


I would like to propose more tuning about token inspection for an incoming request.


I see two approaches for this problem :

  *   Fallback to the cookie checkup if the authorization header is not valid/present
  *   Help the proxy by specifying where to look at the keycloak access token, for example force cookie lookup (my approach with this PR #473<https://github.com/keycloak/keycloak-gatekeeper/pull/473> )
I have chosen the second approach. The goal is to bring more behavior tuning to Keycloak-Gatekeeper :

  *   Being able to configure the Keycloak token lookup (for example force cookie lookup for the access token).
  *   Being able to forward Authorization header "as-is" to the upstream application (without altering it, transparent way).


What is your point of view ?

Let me know if this email is clear enough.


Thank you for your feedback and your kindness for new contributors,
Best Regards,

Gfi Informatique
Nikita Rousseau
Alternant DevOps
Infrastructures Services
nikita.rousseau at gfi.fr<mailto:>
Emerald Square, B?timent B, Avenue Evariste Galois
BP 199, 06904 Sophia Antipolis Cedex
T?l : +33 (0)6 25 44 01 37


From psilva at redhat.com  Mon Apr  1 12:54:21 2019
From: psilva at redhat.com (Pedro Igor Silva)
Date: Mon, 1 Apr 2019 13:54:21 -0300
Subject: [keycloak-dev] Application Initiated Actions Draft #2
In-Reply-To: <CAJgngAdDbTVEMXTp1ZaK6o0GqpBMy3M0HMMzJd605DoEofehOQ@mail.gmail.com>
References: <CAJgngAdDbTVEMXTp1ZaK6o0GqpBMy3M0HMMzJd605DoEofehOQ@mail.gmail.com>
Message-ID: <CAJrcDBe_4DyvyOrcwo78M79uTKdcHSnEDkkL4Zf-UPbhZi0RtQ@mail.gmail.com>

Hi Stian,

A few additional comments:

* "or alternatively the application can include an id_token_hint with the
request that proves the application does not need consent from the user"

I understand that ID Tokens should be short-lived, but aren't we setting
the exp of ID tokens with the value from access tokens? See
org.keycloak.protocol.oidc.TokenManager.AccessTokenResponseBuilder#generateIDToken.

In addition to that, I don't think that using a front-channel to pass
tokens is something we want to do given that there are a lot of
considerations around this approach. If we are really going this way, I
think we should at least consider some form of proof-of-possession.

For last, maybe you should explicitly mention the usage of TLS?

Regards.
Pedro Igor

On Wed, Mar 27, 2019 at 9:43 PM Stian Thorgersen <sthorger at redhat.com>
wrote:

> Based on feedback and also thinking about this a bit more I've now updated
> the proposal for Application Initiated Actions.
>
> Please read and comment on the update draft if you're interested.
>
>
> https://github.com/keycloak/keycloak-community/blob/master/design/application-initiated-actions.md
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sthorger at redhat.com  Mon Apr  1 14:44:07 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 1 Apr 2019 20:44:07 +0200
Subject: [keycloak-dev] Application Initiated Actions Draft #2
In-Reply-To: <CAJrcDBe_4DyvyOrcwo78M79uTKdcHSnEDkkL4Zf-UPbhZi0RtQ@mail.gmail.com>
References: <CAJgngAdDbTVEMXTp1ZaK6o0GqpBMy3M0HMMzJd605DoEofehOQ@mail.gmail.com>
	<CAJrcDBe_4DyvyOrcwo78M79uTKdcHSnEDkkL4Zf-UPbhZi0RtQ@mail.gmail.com>
Message-ID: <CAJgngAdCpi5JWigc204Wn6AjuMzFzXJtQwMfMQLrLPVSB=xVYw@mail.gmail.com>

On Mon, 1 Apr 2019, 18:54 Pedro Igor Silva, <psilva at redhat.com> wrote:

> Hi Stian,
>
> A few additional comments:
>
> * "or alternatively the application can include an id_token_hint with the
> request that proves the application does not need consent from the user"
>
> I understand that ID Tokens should be short-lived, but aren't we setting
> the exp of ID tokens with the value from access tokens? See
> org.keycloak.protocol.oidc.TokenManager.AccessTokenResponseBuilder#generateIDToken.
>

On my phone so can't look at that. ID tokens have some expiration as access
tokens surely?


> In addition to that, I don't think that using a front-channel to pass
> tokens is something we want to do given that there are a lot of
> considerations around this approach. If we are really going this way, I
> think we should at least consider some form of proof-of-possession.
>

I'm not 100% convinced about id_token_hint either, but OIDC spec already
uses id_token_hint several places. It's in the auth endpoint already (not
something we're adding) also used in logout specs. I also struggle to see
how it can be missused even if obtained.

Proof of possession is a nice idea, but not sure how that could be done
without storing additional things at the server side.


> For last, maybe you should explicitly mention the usage of TLS?
>

I do believe that is already implied? Oauth/OIDC/tokens are completely
insecure without TLS.


> Regards.
> Pedro Igor
>
> On Wed, Mar 27, 2019 at 9:43 PM Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> Based on feedback and also thinking about this a bit more I've now updated
>> the proposal for Application Initiated Actions.
>>
>> Please read and comment on the update draft if you're interested.
>>
>>
>> https://github.com/keycloak/keycloak-community/blob/master/design/application-initiated-actions.md
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>

From psilva at redhat.com  Mon Apr  1 15:43:32 2019
From: psilva at redhat.com (Pedro Igor Silva)
Date: Mon, 1 Apr 2019 16:43:32 -0300
Subject: [keycloak-dev] Application Initiated Actions Draft #2
In-Reply-To: <CAJgngAdCpi5JWigc204Wn6AjuMzFzXJtQwMfMQLrLPVSB=xVYw@mail.gmail.com>
References: <CAJgngAdDbTVEMXTp1ZaK6o0GqpBMy3M0HMMzJd605DoEofehOQ@mail.gmail.com>
	<CAJrcDBe_4DyvyOrcwo78M79uTKdcHSnEDkkL4Zf-UPbhZi0RtQ@mail.gmail.com>
	<CAJgngAdCpi5JWigc204Wn6AjuMzFzXJtQwMfMQLrLPVSB=xVYw@mail.gmail.com>
Message-ID: <CAJrcDBeOWvhexi2k_pqEedZRFUp_3oC6HyhTOuzHFDpsb51Nvg@mail.gmail.com>

On Mon, Apr 1, 2019 at 3:44 PM Stian Thorgersen <sthorger at redhat.com> wrote:

>
>
> On Mon, 1 Apr 2019, 18:54 Pedro Igor Silva, <psilva at redhat.com> wrote:
>
>> Hi Stian,
>>
>> A few additional comments:
>>
>> * "or alternatively the application can include an id_token_hint with the
>> request that proves the application does not need consent from the user"
>>
>> I understand that ID Tokens should be short-lived, but aren't we setting
>> the exp of ID tokens with the value from access tokens? See
>> org.keycloak.protocol.oidc.TokenManager.AccessTokenResponseBuilder#generateIDToken.
>>
>
> On my phone so can't look at that. ID tokens have some expiration as
> access tokens surely?
>

It seems so
https://github.com/keycloak/keycloak/blob/061693a8c981987216d37658c7937dd3ca613b50/services/src/main/java/org/keycloak/protocol/oidc/TokenManager.java#L741.
I did run some tests to make sure I'm not missing anything ... Hope I'm
wrong :)


>
>
>> In addition to that, I don't think that using a front-channel to pass
>> tokens is something we want to do given that there are a lot of
>> considerations around this approach. If we are really going this way, I
>> think we should at least consider some form of proof-of-possession.
>>
>
> I'm not 100% convinced about id_token_hint either, but OIDC spec already
> uses id_token_hint several places. It's in the auth endpoint already (not
> something we're adding) also used in logout specs. I also struggle to see
> how it can be missused even if obtained.
>
> Proof of possession is a nice idea, but not sure how that could be done
> without storing additional things at the server side.
>

I can look at that if you want and see if we can apply here some PoP
technique.

I missed this parameter in OIDC spec. So maybe we are cool then and should
just use it? Kind of interesting this, you see a lot of warnings in OAuth
2.0 about using front-channel to deliver tokens (e.g.: implicit) and in
OIDC I did not find anything ... Well, we are backed by the spec then to
keep this simple...

Of course, this is different than sending tokens to a client which you
don't control. But still, suffer some of the same vulnerabilities ...


>
>
>> For last, maybe you should explicitly mention the usage of TLS?
>>
>
> I do believe that is already implied? Oauth/OIDC/tokens are completely
> insecure without TLS.
>

Yeah, I just wanted to highlight this based on the list of considerations
you added into "Notes on id_token hint". You pointed out some that could be
considered to be an implied concern.


>
>
>> Regards.
>> Pedro Igor
>>
>> On Wed, Mar 27, 2019 at 9:43 PM Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>>
>>> Based on feedback and also thinking about this a bit more I've now
>>> updated
>>> the proposal for Application Initiated Actions.
>>>
>>> Please read and comment on the update draft if you're interested.
>>>
>>>
>>> https://github.com/keycloak/keycloak-community/blob/master/design/application-initiated-actions.md
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>

From sthorger at redhat.com  Tue Apr  2 02:47:13 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 2 Apr 2019 08:47:13 +0200
Subject: [keycloak-dev] Application Initiated Actions Draft #2
In-Reply-To: <CAJrcDBeOWvhexi2k_pqEedZRFUp_3oC6HyhTOuzHFDpsb51Nvg@mail.gmail.com>
References: <CAJgngAdDbTVEMXTp1ZaK6o0GqpBMy3M0HMMzJd605DoEofehOQ@mail.gmail.com>
	<CAJrcDBe_4DyvyOrcwo78M79uTKdcHSnEDkkL4Zf-UPbhZi0RtQ@mail.gmail.com>
	<CAJgngAdCpi5JWigc204Wn6AjuMzFzXJtQwMfMQLrLPVSB=xVYw@mail.gmail.com>
	<CAJrcDBeOWvhexi2k_pqEedZRFUp_3oC6HyhTOuzHFDpsb51Nvg@mail.gmail.com>
Message-ID: <CAJgngAcynb2b9sohGrP2vDM=1hkBtH02TpXpGgCX34JwFtH7=w@mail.gmail.com>

On Mon, 1 Apr 2019 at 21:43, Pedro Igor Silva <psilva at redhat.com> wrote:

>
>
> On Mon, Apr 1, 2019 at 3:44 PM Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>>
>>
>> On Mon, 1 Apr 2019, 18:54 Pedro Igor Silva, <psilva at redhat.com> wrote:
>>
>>> Hi Stian,
>>>
>>> A few additional comments:
>>>
>>> * "or alternatively the application can include an id_token_hint with
>>> the request that proves the application does not need consent from the user"
>>>
>>> I understand that ID Tokens should be short-lived, but aren't we setting
>>> the exp of ID tokens with the value from access tokens? See
>>> org.keycloak.protocol.oidc.TokenManager.AccessTokenResponseBuilder#generateIDToken.
>>>
>>
>> On my phone so can't look at that. ID tokens have some expiration as
>> access tokens surely?
>>
>
> It seems so
> https://github.com/keycloak/keycloak/blob/061693a8c981987216d37658c7937dd3ca613b50/services/src/main/java/org/keycloak/protocol/oidc/TokenManager.java#L741.
> I did run some tests to make sure I'm not missing anything ... Hope I'm
> wrong :)
>

They should have the same expiration surely?


>
>
>>
>>
>>> In addition to that, I don't think that using a front-channel to pass
>>> tokens is something we want to do given that there are a lot of
>>> considerations around this approach. If we are really going this way, I
>>> think we should at least consider some form of proof-of-possession.
>>>
>>
>> I'm not 100% convinced about id_token_hint either, but OIDC spec already
>> uses id_token_hint several places. It's in the auth endpoint already (not
>> something we're adding) also used in logout specs. I also struggle to see
>> how it can be missused even if obtained.
>>
>> Proof of possession is a nice idea, but not sure how that could be done
>> without storing additional things at the server side.
>>
>
> I can look at that if you want and see if we can apply here some PoP
> technique.
>

Sure - we could potentially support both id_token_hint and a PoP technique
(if we can do the latter in a nice way)


>
> I missed this parameter in OIDC spec. So maybe we are cool then and should
> just use it? Kind of interesting this, you see a lot of warnings in OAuth
> 2.0 about using front-channel to deliver tokens (e.g.: implicit) and in
> OIDC I did not find anything ... Well, we are backed by the spec then to
> keep this simple...
>

There's a difference in leaking a refresh token and access token to leaking
a ID token IMO. From thinking about it I can't see how you would use a
leaked ID token as apps don't accept them in the same way as services
accept access tokens.


>
> Of course, this is different than sending tokens to a client which you
> don't control. But still, suffer some of the same vulnerabilities ...
>
>
>>
>>
>>> For last, maybe you should explicitly mention the usage of TLS?
>>>
>>
>> I do believe that is already implied? Oauth/OIDC/tokens are completely
>> insecure without TLS.
>>
>
> Yeah, I just wanted to highlight this based on the list of considerations
> you added into "Notes on id_token hint". You pointed out some that could be
> considered to be an implied concern.
>
>
>>
>>
>>> Regards.
>>> Pedro Igor
>>>
>>> On Wed, Mar 27, 2019 at 9:43 PM Stian Thorgersen <sthorger at redhat.com>
>>> wrote:
>>>
>>>> Based on feedback and also thinking about this a bit more I've now
>>>> updated
>>>> the proposal for Application Initiated Actions.
>>>>
>>>> Please read and comment on the update draft if you're interested.
>>>>
>>>>
>>>> https://github.com/keycloak/keycloak-community/blob/master/design/application-initiated-actions.md
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>>

From maurodewit at gmail.com  Tue Apr  2 05:15:25 2019
From: maurodewit at gmail.com (Mauro de Wit)
Date: Tue, 2 Apr 2019 11:15:25 +0200
Subject: [keycloak-dev] Keycloak session limiting (KEYCLOAK-849) (BA-93)
In-Reply-To: <9c832dce-71b7-1877-c10f-ee4593beac04@redhat.com>
References: <CACihWx2N0zfT2pTSgRxtQnwavwNa7CiQefQ9O=GVrwX=7YB3pQ@mail.gmail.com>
	<CAJgngAfsW2PoaAkZUa7V8_tZuTQW-7a7vFzSYW7f9UiP_LkqUw@mail.gmail.com>
	<CACihWx2NnqaBMUdoGuzgUBsEAR4Ltx1xNdc0Quvk-F67aHMW=Q@mail.gmail.com>
	<CACihWx1JAxGz_Zn=Q0xCsB=T9wvDiEBwn6oB=pcooV6TP7NZqw@mail.gmail.com>
	<CALO-DfAoZpdzweZyx1iBXK=nU3XGqDpjgE8202QDJOraTFaYJQ@mail.gmail.com>
	<CACihWx2SWcXqq=gy+X3U=Ct0o2E+zaVAKpH-ahJS88+E64AqRQ@mail.gmail.com>
	<CAJgngAfJ2pgUgLBu2gXnmxrdicFzigPgfG=G4yudsPgz82pcZg@mail.gmail.com>
	<CACihWx2fi+tpT57grJ85pRdrj36f0cuvsErwoQUdSkUQeVrJOQ@mail.gmail.com>
	<CAJgngAdOEEAb4yAn4j=0aXE2=4fnjB8yMck8Yw4=88+SqRzvRw@mail.gmail.com>
	<CACihWx3Pk+_1Nbi+9uzvH1VchZCbf3rJi5sMvcHnCGMnD6Y8DA@mail.gmail.com>
	<CAJgngAduexRmVouqoYnEnmD-Lba5quKAZ5gC4dO7cBFM9kChqA@mail.gmail.com>
	<8d3aaed6-f878-ac5e-0132-0ceae2934471@redhat.com>
	<CACihWx1WDLS56OWvW7ppMVBPG8aiy0RhaL_N1K21ZZTLOkTCdA@mail.gmail.com>
	<CACihWx1_pE49_4L8thAvKoALRfs8p7nTkmc3YB0XDnSAXVZB=w@mail.gmail.com>
	<9c832dce-71b7-1877-c10f-ee4593beac04@redhat.com>
Message-ID: <CACihWx2tKZ9fToQRL-GkfuaDUmYMSjnmbh=fQa3srFEvjO9iVw@mail.gmail.com>

Unfortunately this doesn't work. Deleting the cookies works, but still no
new session is created. Had to navigate to the login page again though to
delete the cookies, otherwise the URL didn't match and no cookies were
deleted.
Will give it a try now using the JAX RS or Oauth client now.

On Mon, 1 Apr 2019 at 13:22, Marek Posolda <mposolda at redhat.com> wrote:

> Maybe easiest is to login and then call :
>
> driver.manage().deleteAllCookies();
>
> This will delete all cookies, so you can login again within same browser (web driver) and the previous session is still valid (cookies were manually removed from browser, but session is still alive on
> server-side as you did not logout). See for example LoginTest.loginExpiredCodeAndExpiredCookies() for some inspiration.
>
> Marek
>
> On 01/04/2019 11:59, Mauro de Wit wrote:
>
> Ok, I've found some time to continue on the session limiting task. I've
> created a fork of the Keycloak repository from which I eventually will make
> a PR. But first I need to finalize my work (Still need to add event
> logging).
> Currently I am in the process of creating Integration tests for this
> mechanism and have it partly working.
>
> But I'm having trouble creating multiple sessions from a single test.
> Browsing through the existing tests I've not found any example how this is
> done.
> Can anyone point me to an existing example or provide me with information
> howto initiate multiple sessions?
>
> Here are the tests I've written:
>
> https://github.com/mfdewit/keycloak/tree/KEYCLOAK-849-configurable-session-limits/testsuite/integration-arquillian/tests/base/src/test/java/org/keycloak/testsuite/sessionlimits
>
> Specifically, the UserSessionLimitsTest is requiring me to login multiple
> times. The RealmSessionTest is already working correctly as far as I can
> tell.
> Any help would be appreciated.
>
>
>
>
>
>
>
> On Wed, 20 Mar 2019 at 15:00, Mauro de Wit <maurodewit at gmail.com> wrote:
>
>> Makes sense. Thanks for the input guys.
>> I'm on the right track then :)
>>
>> On Wed, 20 Mar 2019 at 14:59, Marek Posolda <mposolda at redhat.com> wrote:
>>
>>> On 20/03/2019 12:50, Stian Thorgersen wrote:
>>>
>>> I wasn't even aware we had the 'Post Login Flow'.
>>>
>>> From the description I would think that Post Login Flow is being
>>> executed before the user session is created, while there's an
>>> authentication session. So should be fine.
>>>
>>> Marek - can you confirm?
>>>
>>> Yes, exactly. User session doesn't yet exists when "Post Login Flow" is
>>> executed. This flow exists exactly because of use-cases like this - having
>>> the ability to execute the hooks after broker authentication. For example
>>> some people wanted to execute TOTP after the authentication with "facebook"
>>> broker etc.
>>>
>>> Marek
>>>
>>>
>>> On Wed, 20 Mar 2019 at 12:38, Mauro de Wit <maurodewit at gmail.com> wrote:
>>>
>>>> Isn't the 'Post login flow' in the IDP configuration the place for
>>>> this? Or do we want to avoid this since this is triggered after
>>>> authentication is complete and the session in created.
>>>> If this is the case, can you point me in the right direction to create
>>>> a hook into the redirect from the external broker?
>>>>
>>>> On Tue, 19 Mar 2019 at 10:59, Stian Thorgersen <sthorger at redhat.com>
>>>> wrote:
>>>>
>>>>> You're right. In fact this should probably be split into two separate
>>>>> authenticators. For realm limits it should be checked as a first part
>>>>> (otherwise you have users authenticating and expensive password hashing
>>>>> when it's already known the session won't be permitted).
>>>>>
>>>>> For regular sessions authenticator works well, but to be honest I
>>>>> completely forgot about brokering. For realm limits it's fine as that
>>>>> authenticator can happen prior to the redirect, but for users there's no
>>>>> hook after the redirected back from the external broker today. There's the
>>>>> first login flow, but that only happens on the first time.
>>>>>
>>>>> On Mon, 18 Mar 2019 at 10:59, Mauro de Wit <maurodewit at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Ok, I'm missing some fundamental understanding here. Please help :)
>>>>>>
>>>>>> In case of the browser flow, the authentication flow is executed upon
>>>>>> loading a page using the browser. At this time checks are being performed
>>>>>> to see if the user is already logged on. If this is the case, no
>>>>>> authentication has to be performed and the user is presented the requested
>>>>>> page.
>>>>>> But if the user is not yet logged on, the cookie authenticator can't
>>>>>> do anything usefull resulting in the next authenticator to trigger.
>>>>>> Eventually the 'browser forms' authenticator presents a login screen.
>>>>>>
>>>>>> Given the fact that we need to deny the user access in case a session
>>>>>> already exists for his/her account on another machine, we need to know who
>>>>>> this user is. How can we know which user we are dealing with at the start
>>>>>> of the flow?
>>>>>> I can see this working for limiting the number of sessions for each
>>>>>> realm, but not for limiting sessions bound to individual user accounts.
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, 18 Mar 2019 at 09:19, Stian Thorgersen <sthorger at redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>>> The authenticator should be added after the cookie authenticator,
>>>>>>> not at the end. That will make it take affect for IdP logins as well. So
>>>>>>> it's a matter of configuring it in two flows browser and direct grant.
>>>>>>>
>>>>>>> I appreciate it may not be the best usability, but I don't want to
>>>>>>> introduce something special/hard-coded for this feature. A later
>>>>>>> improvement could be to improve on the authentication flows. To have
>>>>>>> different elements in a flow and not just executions as well as potentially
>>>>>>> having some pre-flow checks that are done in all flows. I'd say this
>>>>>>> approach is good enough though at least for now.
>>>>>>>
>>>>>>> On Mon, 18 Mar 2019 at 09:00, Mauro de Wit <maurodewit at gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> That is indeed one of the downsides of this approach.
>>>>>>>> But can a misconfiguration of this functionality do any harm,
>>>>>>>> besides some inconsistent behavior between authentication methods?
>>>>>>>>
>>>>>>>> @stian at redhat.com <stian at redhat.com> any thoughts?
>>>>>>>>
>>>>>>>> On Fri, 15 Mar 2019 at 15:23, Jared Blashka <jblashka at redhat.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> If this is done via an authenticator wouldn't you have to make
>>>>>>>>> sure that this authenticator is present (and all the same settings are
>>>>>>>>> maintained) in the browser flow as well as the direct access flow as well
>>>>>>>>> as the login flows for all configured identity providers? It seems like it
>>>>>>>>> would be quite easy to make a mistake in that process and misconfigure
>>>>>>>>> something somewhere.
>>>>>>>>>
>>>>>>>>> On Fri, Mar 15, 2019 at 5:41 AM Mauro de Wit <maurodewit at gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> I've started to create a simple proof of concept and want to
>>>>>>>>>> check if I
>>>>>>>>>> have my facts straight.
>>>>>>>>>> As previously discussed this functionality should be provided by
>>>>>>>>>> a custom
>>>>>>>>>> Authenticator that is configured in an authentication flow.
>>>>>>>>>>
>>>>>>>>>> What I've done so far is:
>>>>>>>>>> - Created implementations for both the Authenticator and
>>>>>>>>>> AuthenticatorFactory interfaces.
>>>>>>>>>> - Added a set of ProviderConfigProperty instances that allow the
>>>>>>>>>> desired
>>>>>>>>>> configuration.
>>>>>>>>>> - Perform the check if any session limits are exceeded inside the
>>>>>>>>>> authenticate() method of the Authenticator class. (Any session
>>>>>>>>>> invalidation
>>>>>>>>>> will be performed here as well)
>>>>>>>>>>
>>>>>>>>>> Now, in order to use session limiting for regular
>>>>>>>>>> username/password form
>>>>>>>>>> logins, I have created a copy of the 'browser flow' and added this
>>>>>>>>>> Authenticator as a 'required' execution at the end of the flow.
>>>>>>>>>> In our case we allow IDP logins as well. And to use this
>>>>>>>>>> functionality for
>>>>>>>>>> these logins, I've created a new authentication flow containing
>>>>>>>>>> just this
>>>>>>>>>> Authenticator. Finally this flow is selected in the 'Post login
>>>>>>>>>> flow' of
>>>>>>>>>> the IDP configuration.
>>>>>>>>>> For both scenarios the Authenticator seems to be triggered at the
>>>>>>>>>> right
>>>>>>>>>> time and I should be able to apply the session limiting rules.
>>>>>>>>>>
>>>>>>>>>> Any thoughts or comments so far?
>>>>>>>>>>
>>>>>>>>>> On Tue, 12 Mar 2019 at 14:53, Mauro de Wit <maurodewit at gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> > Ok, thanks for the clarification.
>>>>>>>>>> >
>>>>>>>>>> > On Tue, 12 Mar 2019 at 12:39, Stian Thorgersen <
>>>>>>>>>> sthorger at redhat.com>
>>>>>>>>>> > wrote:
>>>>>>>>>> >
>>>>>>>>>> >> It should be a pluggable part of the authentication flow and
>>>>>>>>>> not a
>>>>>>>>>> >> hardcoded element. There is no other way to plug in to the
>>>>>>>>>> authentication
>>>>>>>>>> >> flow other than creating an authenticator. An authenticator
>>>>>>>>>> doesn't need to
>>>>>>>>>> >> provide a challenge though so it can be used in this instance.
>>>>>>>>>> >>
>>>>>>>>>> >> On Tue, 12 Mar 2019 at 10:57, Mauro de Wit <
>>>>>>>>>> maurodewit at gmail.com> wrote:
>>>>>>>>>> >>
>>>>>>>>>> >>> Hello,
>>>>>>>>>> >>>
>>>>>>>>>> >>> I am sending this e-mail because I have some questions
>>>>>>>>>> regarding the
>>>>>>>>>> >>> enhancement request that enables configurable session
>>>>>>>>>> limiting in
>>>>>>>>>> >>> Keycloak
>>>>>>>>>> >>> as discussed here:
>>>>>>>>>> >>> https://issues.jboss.org/browse/KEYCLOAK-849 (The developer
>>>>>>>>>> that Marc
>>>>>>>>>> >>> Wijma
>>>>>>>>>> >>> referred to in his comment as being available for this task
>>>>>>>>>> is me btw :))
>>>>>>>>>> >>>
>>>>>>>>>> >>> In the comments a solution is proposed that makes use of a
>>>>>>>>>> custom
>>>>>>>>>> >>> Authenticator that is dropped into the authentication flow
>>>>>>>>>> where it can
>>>>>>>>>> >>> be
>>>>>>>>>> >>> configured. While I can see the benefit of leveraging the
>>>>>>>>>> existing
>>>>>>>>>> >>> components as much as possible (including the configuration
>>>>>>>>>> options in
>>>>>>>>>> >>> that
>>>>>>>>>> >>> flow), I am wondering if this is the best solution. As far as
>>>>>>>>>> I can tell,
>>>>>>>>>> >>> this component is not performing any authentication at all.
>>>>>>>>>> Moreover this
>>>>>>>>>> >>> functionality operates 'above' the authentication mechanisms
>>>>>>>>>> and should
>>>>>>>>>> >>> apply to all of them.
>>>>>>>>>> >>> So is an Authenticator really the desired place to implement
>>>>>>>>>> this? Or is
>>>>>>>>>> >>> this just the quickest route, while not being the most
>>>>>>>>>> desirable option
>>>>>>>>>> >>> for
>>>>>>>>>> >>> the long term? What would be an alternative approach be? That
>>>>>>>>>> would place
>>>>>>>>>> >>> this implementation and configuration in the existing Session
>>>>>>>>>> >>> configuration
>>>>>>>>>> >>> code for instance.
>>>>>>>>>> >>>
>>>>>>>>>> >>> I just now started investigating this task and looking into
>>>>>>>>>> the options
>>>>>>>>>> >>> that would meet our requirements. Hope to hear from you.
>>>>>>>>>> >>>
>>>>>>>>>> >>> Regards
>>>>>>>>>> >>>
>>>>>>>>>> >>> Mauro
>>>>>>>>>> >>>
>>>>>>>>>> >>> >
>>>>>>>>>> >>> _______________________________________________
>>>>>>>>>> >>> keycloak-dev mailing list
>>>>>>>>>> >>> keycloak-dev at lists.jboss.org
>>>>>>>>>> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>>>> >>>
>>>>>>>>>> >>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> keycloak-dev mailing list
>>>>>>>>>> keycloak-dev at lists.jboss.org
>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>>>>
>>>>>>>>>
>>>
>

From maurodewit at gmail.com  Tue Apr  2 05:31:16 2019
From: maurodewit at gmail.com (Mauro de Wit)
Date: Tue, 2 Apr 2019 11:31:16 +0200
Subject: [keycloak-dev] Keycloak session limiting (KEYCLOAK-849) (BA-93)
In-Reply-To: <CACihWx2tKZ9fToQRL-GkfuaDUmYMSjnmbh=fQa3srFEvjO9iVw@mail.gmail.com>
References: <CACihWx2N0zfT2pTSgRxtQnwavwNa7CiQefQ9O=GVrwX=7YB3pQ@mail.gmail.com>
	<CAJgngAfsW2PoaAkZUa7V8_tZuTQW-7a7vFzSYW7f9UiP_LkqUw@mail.gmail.com>
	<CACihWx2NnqaBMUdoGuzgUBsEAR4Ltx1xNdc0Quvk-F67aHMW=Q@mail.gmail.com>
	<CACihWx1JAxGz_Zn=Q0xCsB=T9wvDiEBwn6oB=pcooV6TP7NZqw@mail.gmail.com>
	<CALO-DfAoZpdzweZyx1iBXK=nU3XGqDpjgE8202QDJOraTFaYJQ@mail.gmail.com>
	<CACihWx2SWcXqq=gy+X3U=Ct0o2E+zaVAKpH-ahJS88+E64AqRQ@mail.gmail.com>
	<CAJgngAfJ2pgUgLBu2gXnmxrdicFzigPgfG=G4yudsPgz82pcZg@mail.gmail.com>
	<CACihWx2fi+tpT57grJ85pRdrj36f0cuvsErwoQUdSkUQeVrJOQ@mail.gmail.com>
	<CAJgngAdOEEAb4yAn4j=0aXE2=4fnjB8yMck8Yw4=88+SqRzvRw@mail.gmail.com>
	<CACihWx3Pk+_1Nbi+9uzvH1VchZCbf3rJi5sMvcHnCGMnD6Y8DA@mail.gmail.com>
	<CAJgngAduexRmVouqoYnEnmD-Lba5quKAZ5gC4dO7cBFM9kChqA@mail.gmail.com>
	<8d3aaed6-f878-ac5e-0132-0ceae2934471@redhat.com>
	<CACihWx1WDLS56OWvW7ppMVBPG8aiy0RhaL_N1K21ZZTLOkTCdA@mail.gmail.com>
	<CACihWx1_pE49_4L8thAvKoALRfs8p7nTkmc3YB0XDnSAXVZB=w@mail.gmail.com>
	<9c832dce-71b7-1877-c10f-ee4593beac04@redhat.com>
	<CACihWx2tKZ9fToQRL-GkfuaDUmYMSjnmbh=fQa3srFEvjO9iVw@mail.gmail.com>
Message-ID: <CACihWx0oRyZ+uCq7OwSJn8mfaCSJcOMav__AUP77Qyf3C0kvmQ@mail.gmail.com>

Using the Oauth client to create mutliple sessions works :)
based my code on org.keycloak.testsuite.oauth.LogoutTest and this is
exactly what I need!

On Tue, 2 Apr 2019 at 11:15, Mauro de Wit <maurodewit at gmail.com> wrote:

> Unfortunately this doesn't work. Deleting the cookies works, but still no
> new session is created. Had to navigate to the login page again though to
> delete the cookies, otherwise the URL didn't match and no cookies were
> deleted.
> Will give it a try now using the JAX RS or Oauth client now.
>
> On Mon, 1 Apr 2019 at 13:22, Marek Posolda <mposolda at redhat.com> wrote:
>
>> Maybe easiest is to login and then call :
>>
>> driver.manage().deleteAllCookies();
>>
>> This will delete all cookies, so you can login again within same browser (web driver) and the previous session is still valid (cookies were manually removed from browser, but session is still alive on
>> server-side as you did not logout). See for example LoginTest.loginExpiredCodeAndExpiredCookies() for some inspiration.
>>
>> Marek
>>
>> On 01/04/2019 11:59, Mauro de Wit wrote:
>>
>> Ok, I've found some time to continue on the session limiting task. I've
>> created a fork of the Keycloak repository from which I eventually will make
>> a PR. But first I need to finalize my work (Still need to add event
>> logging).
>> Currently I am in the process of creating Integration tests for this
>> mechanism and have it partly working.
>>
>> But I'm having trouble creating multiple sessions from a single test.
>> Browsing through the existing tests I've not found any example how this is
>> done.
>> Can anyone point me to an existing example or provide me with information
>> howto initiate multiple sessions?
>>
>> Here are the tests I've written:
>>
>> https://github.com/mfdewit/keycloak/tree/KEYCLOAK-849-configurable-session-limits/testsuite/integration-arquillian/tests/base/src/test/java/org/keycloak/testsuite/sessionlimits
>>
>> Specifically, the UserSessionLimitsTest is requiring me to login multiple
>> times. The RealmSessionTest is already working correctly as far as I can
>> tell.
>> Any help would be appreciated.
>>
>>
>>
>>
>>
>>
>>
>> On Wed, 20 Mar 2019 at 15:00, Mauro de Wit <maurodewit at gmail.com> wrote:
>>
>>> Makes sense. Thanks for the input guys.
>>> I'm on the right track then :)
>>>
>>> On Wed, 20 Mar 2019 at 14:59, Marek Posolda <mposolda at redhat.com> wrote:
>>>
>>>> On 20/03/2019 12:50, Stian Thorgersen wrote:
>>>>
>>>> I wasn't even aware we had the 'Post Login Flow'.
>>>>
>>>> From the description I would think that Post Login Flow is being
>>>> executed before the user session is created, while there's an
>>>> authentication session. So should be fine.
>>>>
>>>> Marek - can you confirm?
>>>>
>>>> Yes, exactly. User session doesn't yet exists when "Post Login Flow" is
>>>> executed. This flow exists exactly because of use-cases like this - having
>>>> the ability to execute the hooks after broker authentication. For example
>>>> some people wanted to execute TOTP after the authentication with "facebook"
>>>> broker etc.
>>>>
>>>> Marek
>>>>
>>>>
>>>> On Wed, 20 Mar 2019 at 12:38, Mauro de Wit <maurodewit at gmail.com>
>>>> wrote:
>>>>
>>>>> Isn't the 'Post login flow' in the IDP configuration the place for
>>>>> this? Or do we want to avoid this since this is triggered after
>>>>> authentication is complete and the session in created.
>>>>> If this is the case, can you point me in the right direction to create
>>>>> a hook into the redirect from the external broker?
>>>>>
>>>>> On Tue, 19 Mar 2019 at 10:59, Stian Thorgersen <sthorger at redhat.com>
>>>>> wrote:
>>>>>
>>>>>> You're right. In fact this should probably be split into two separate
>>>>>> authenticators. For realm limits it should be checked as a first part
>>>>>> (otherwise you have users authenticating and expensive password hashing
>>>>>> when it's already known the session won't be permitted).
>>>>>>
>>>>>> For regular sessions authenticator works well, but to be honest I
>>>>>> completely forgot about brokering. For realm limits it's fine as that
>>>>>> authenticator can happen prior to the redirect, but for users there's no
>>>>>> hook after the redirected back from the external broker today. There's the
>>>>>> first login flow, but that only happens on the first time.
>>>>>>
>>>>>> On Mon, 18 Mar 2019 at 10:59, Mauro de Wit <maurodewit at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Ok, I'm missing some fundamental understanding here. Please help :)
>>>>>>>
>>>>>>> In case of the browser flow, the authentication flow is executed
>>>>>>> upon loading a page using the browser. At this time checks are being
>>>>>>> performed to see if the user is already logged on. If this is the case, no
>>>>>>> authentication has to be performed and the user is presented the requested
>>>>>>> page.
>>>>>>> But if the user is not yet logged on, the cookie authenticator can't
>>>>>>> do anything usefull resulting in the next authenticator to trigger.
>>>>>>> Eventually the 'browser forms' authenticator presents a login screen.
>>>>>>>
>>>>>>> Given the fact that we need to deny the user access in case a
>>>>>>> session already exists for his/her account on another machine, we need to
>>>>>>> know who this user is. How can we know which user we are dealing with at
>>>>>>> the start of the flow?
>>>>>>> I can see this working for limiting the number of sessions for each
>>>>>>> realm, but not for limiting sessions bound to individual user accounts.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Mon, 18 Mar 2019 at 09:19, Stian Thorgersen <sthorger at redhat.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> The authenticator should be added after the cookie authenticator,
>>>>>>>> not at the end. That will make it take affect for IdP logins as well. So
>>>>>>>> it's a matter of configuring it in two flows browser and direct grant.
>>>>>>>>
>>>>>>>> I appreciate it may not be the best usability, but I don't want to
>>>>>>>> introduce something special/hard-coded for this feature. A later
>>>>>>>> improvement could be to improve on the authentication flows. To have
>>>>>>>> different elements in a flow and not just executions as well as potentially
>>>>>>>> having some pre-flow checks that are done in all flows. I'd say this
>>>>>>>> approach is good enough though at least for now.
>>>>>>>>
>>>>>>>> On Mon, 18 Mar 2019 at 09:00, Mauro de Wit <maurodewit at gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> That is indeed one of the downsides of this approach.
>>>>>>>>> But can a misconfiguration of this functionality do any harm,
>>>>>>>>> besides some inconsistent behavior between authentication methods?
>>>>>>>>>
>>>>>>>>> @stian at redhat.com <stian at redhat.com> any thoughts?
>>>>>>>>>
>>>>>>>>> On Fri, 15 Mar 2019 at 15:23, Jared Blashka <jblashka at redhat.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> If this is done via an authenticator wouldn't you have to make
>>>>>>>>>> sure that this authenticator is present (and all the same settings are
>>>>>>>>>> maintained) in the browser flow as well as the direct access flow as well
>>>>>>>>>> as the login flows for all configured identity providers? It seems like it
>>>>>>>>>> would be quite easy to make a mistake in that process and misconfigure
>>>>>>>>>> something somewhere.
>>>>>>>>>>
>>>>>>>>>> On Fri, Mar 15, 2019 at 5:41 AM Mauro de Wit <
>>>>>>>>>> maurodewit at gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> I've started to create a simple proof of concept and want to
>>>>>>>>>>> check if I
>>>>>>>>>>> have my facts straight.
>>>>>>>>>>> As previously discussed this functionality should be provided by
>>>>>>>>>>> a custom
>>>>>>>>>>> Authenticator that is configured in an authentication flow.
>>>>>>>>>>>
>>>>>>>>>>> What I've done so far is:
>>>>>>>>>>> - Created implementations for both the Authenticator and
>>>>>>>>>>> AuthenticatorFactory interfaces.
>>>>>>>>>>> - Added a set of ProviderConfigProperty instances that allow the
>>>>>>>>>>> desired
>>>>>>>>>>> configuration.
>>>>>>>>>>> - Perform the check if any session limits are exceeded inside the
>>>>>>>>>>> authenticate() method of the Authenticator class. (Any session
>>>>>>>>>>> invalidation
>>>>>>>>>>> will be performed here as well)
>>>>>>>>>>>
>>>>>>>>>>> Now, in order to use session limiting for regular
>>>>>>>>>>> username/password form
>>>>>>>>>>> logins, I have created a copy of the 'browser flow' and added
>>>>>>>>>>> this
>>>>>>>>>>> Authenticator as a 'required' execution at the end of the flow.
>>>>>>>>>>> In our case we allow IDP logins as well. And to use this
>>>>>>>>>>> functionality for
>>>>>>>>>>> these logins, I've created a new authentication flow containing
>>>>>>>>>>> just this
>>>>>>>>>>> Authenticator. Finally this flow is selected in the 'Post login
>>>>>>>>>>> flow' of
>>>>>>>>>>> the IDP configuration.
>>>>>>>>>>> For both scenarios the Authenticator seems to be triggered at
>>>>>>>>>>> the right
>>>>>>>>>>> time and I should be able to apply the session limiting rules.
>>>>>>>>>>>
>>>>>>>>>>> Any thoughts or comments so far?
>>>>>>>>>>>
>>>>>>>>>>> On Tue, 12 Mar 2019 at 14:53, Mauro de Wit <maurodewit at gmail.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> > Ok, thanks for the clarification.
>>>>>>>>>>> >
>>>>>>>>>>> > On Tue, 12 Mar 2019 at 12:39, Stian Thorgersen <
>>>>>>>>>>> sthorger at redhat.com>
>>>>>>>>>>> > wrote:
>>>>>>>>>>> >
>>>>>>>>>>> >> It should be a pluggable part of the authentication flow and
>>>>>>>>>>> not a
>>>>>>>>>>> >> hardcoded element. There is no other way to plug in to the
>>>>>>>>>>> authentication
>>>>>>>>>>> >> flow other than creating an authenticator. An authenticator
>>>>>>>>>>> doesn't need to
>>>>>>>>>>> >> provide a challenge though so it can be used in this instance.
>>>>>>>>>>> >>
>>>>>>>>>>> >> On Tue, 12 Mar 2019 at 10:57, Mauro de Wit <
>>>>>>>>>>> maurodewit at gmail.com> wrote:
>>>>>>>>>>> >>
>>>>>>>>>>> >>> Hello,
>>>>>>>>>>> >>>
>>>>>>>>>>> >>> I am sending this e-mail because I have some questions
>>>>>>>>>>> regarding the
>>>>>>>>>>> >>> enhancement request that enables configurable session
>>>>>>>>>>> limiting in
>>>>>>>>>>> >>> Keycloak
>>>>>>>>>>> >>> as discussed here:
>>>>>>>>>>> >>> https://issues.jboss.org/browse/KEYCLOAK-849 (The developer
>>>>>>>>>>> that Marc
>>>>>>>>>>> >>> Wijma
>>>>>>>>>>> >>> referred to in his comment as being available for this task
>>>>>>>>>>> is me btw :))
>>>>>>>>>>> >>>
>>>>>>>>>>> >>> In the comments a solution is proposed that makes use of a
>>>>>>>>>>> custom
>>>>>>>>>>> >>> Authenticator that is dropped into the authentication flow
>>>>>>>>>>> where it can
>>>>>>>>>>> >>> be
>>>>>>>>>>> >>> configured. While I can see the benefit of leveraging the
>>>>>>>>>>> existing
>>>>>>>>>>> >>> components as much as possible (including the configuration
>>>>>>>>>>> options in
>>>>>>>>>>> >>> that
>>>>>>>>>>> >>> flow), I am wondering if this is the best solution. As far
>>>>>>>>>>> as I can tell,
>>>>>>>>>>> >>> this component is not performing any authentication at all.
>>>>>>>>>>> Moreover this
>>>>>>>>>>> >>> functionality operates 'above' the authentication mechanisms
>>>>>>>>>>> and should
>>>>>>>>>>> >>> apply to all of them.
>>>>>>>>>>> >>> So is an Authenticator really the desired place to implement
>>>>>>>>>>> this? Or is
>>>>>>>>>>> >>> this just the quickest route, while not being the most
>>>>>>>>>>> desirable option
>>>>>>>>>>> >>> for
>>>>>>>>>>> >>> the long term? What would be an alternative approach be?
>>>>>>>>>>> That would place
>>>>>>>>>>> >>> this implementation and configuration in the existing Session
>>>>>>>>>>> >>> configuration
>>>>>>>>>>> >>> code for instance.
>>>>>>>>>>> >>>
>>>>>>>>>>> >>> I just now started investigating this task and looking into
>>>>>>>>>>> the options
>>>>>>>>>>> >>> that would meet our requirements. Hope to hear from you.
>>>>>>>>>>> >>>
>>>>>>>>>>> >>> Regards
>>>>>>>>>>> >>>
>>>>>>>>>>> >>> Mauro
>>>>>>>>>>> >>>
>>>>>>>>>>> >>> >
>>>>>>>>>>> >>> _______________________________________________
>>>>>>>>>>> >>> keycloak-dev mailing list
>>>>>>>>>>> >>> keycloak-dev at lists.jboss.org
>>>>>>>>>>> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>>>>> >>>
>>>>>>>>>>> >>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> keycloak-dev mailing list
>>>>>>>>>>> keycloak-dev at lists.jboss.org
>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>>>>>
>>>>>>>>>>
>>>>
>>

From sthorger at redhat.com  Tue Apr  2 05:54:53 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 2 Apr 2019 11:54:53 +0200
Subject: [keycloak-dev] Keycloak session limiting (KEYCLOAK-849) (BA-93)
In-Reply-To: <CACihWx0oRyZ+uCq7OwSJn8mfaCSJcOMav__AUP77Qyf3C0kvmQ@mail.gmail.com>
References: <CACihWx2N0zfT2pTSgRxtQnwavwNa7CiQefQ9O=GVrwX=7YB3pQ@mail.gmail.com>
	<CAJgngAfsW2PoaAkZUa7V8_tZuTQW-7a7vFzSYW7f9UiP_LkqUw@mail.gmail.com>
	<CACihWx2NnqaBMUdoGuzgUBsEAR4Ltx1xNdc0Quvk-F67aHMW=Q@mail.gmail.com>
	<CACihWx1JAxGz_Zn=Q0xCsB=T9wvDiEBwn6oB=pcooV6TP7NZqw@mail.gmail.com>
	<CALO-DfAoZpdzweZyx1iBXK=nU3XGqDpjgE8202QDJOraTFaYJQ@mail.gmail.com>
	<CACihWx2SWcXqq=gy+X3U=Ct0o2E+zaVAKpH-ahJS88+E64AqRQ@mail.gmail.com>
	<CAJgngAfJ2pgUgLBu2gXnmxrdicFzigPgfG=G4yudsPgz82pcZg@mail.gmail.com>
	<CACihWx2fi+tpT57grJ85pRdrj36f0cuvsErwoQUdSkUQeVrJOQ@mail.gmail.com>
	<CAJgngAdOEEAb4yAn4j=0aXE2=4fnjB8yMck8Yw4=88+SqRzvRw@mail.gmail.com>
	<CACihWx3Pk+_1Nbi+9uzvH1VchZCbf3rJi5sMvcHnCGMnD6Y8DA@mail.gmail.com>
	<CAJgngAduexRmVouqoYnEnmD-Lba5quKAZ5gC4dO7cBFM9kChqA@mail.gmail.com>
	<8d3aaed6-f878-ac5e-0132-0ceae2934471@redhat.com>
	<CACihWx1WDLS56OWvW7ppMVBPG8aiy0RhaL_N1K21ZZTLOkTCdA@mail.gmail.com>
	<CACihWx1_pE49_4L8thAvKoALRfs8p7nTkmc3YB0XDnSAXVZB=w@mail.gmail.com>
	<9c832dce-71b7-1877-c10f-ee4593beac04@redhat.com>
	<CACihWx2tKZ9fToQRL-GkfuaDUmYMSjnmbh=fQa3srFEvjO9iVw@mail.gmail.com>
	<CACihWx0oRyZ+uCq7OwSJn8mfaCSJcOMav__AUP77Qyf3C0kvmQ@mail.gmail.com>
Message-ID: <CAJgngAfp2E+004Y5LH6mkN5APsBk2f-0D8EJkywPEC-BPgy2hA@mail.gmail.com>

Oauth client uses the direct grant flow though. We'll need tests for both
flows. Deleting cookies should work, you may also be able to use a new
webdriver instance with custom/different cookie store to allow controlling
it

On Tue, 2 Apr 2019, 10:31 Mauro de Wit, <maurodewit at gmail.com> wrote:

> Using the Oauth client to create mutliple sessions works :)
> based my code on org.keycloak.testsuite.oauth.LogoutTest and this is
> exactly what I need!
>
> On Tue, 2 Apr 2019 at 11:15, Mauro de Wit <maurodewit at gmail.com> wrote:
>
>> Unfortunately this doesn't work. Deleting the cookies works, but still no
>> new session is created. Had to navigate to the login page again though to
>> delete the cookies, otherwise the URL didn't match and no cookies were
>> deleted.
>> Will give it a try now using the JAX RS or Oauth client now.
>>
>> On Mon, 1 Apr 2019 at 13:22, Marek Posolda <mposolda at redhat.com> wrote:
>>
>>> Maybe easiest is to login and then call :
>>>
>>> driver.manage().deleteAllCookies();
>>>
>>> This will delete all cookies, so you can login again within same browser (web driver) and the previous session is still valid (cookies were manually removed from browser, but session is still alive on
>>> server-side as you did not logout). See for example LoginTest.loginExpiredCodeAndExpiredCookies() for some inspiration.
>>>
>>> Marek
>>>
>>> On 01/04/2019 11:59, Mauro de Wit wrote:
>>>
>>> Ok, I've found some time to continue on the session limiting task. I've
>>> created a fork of the Keycloak repository from which I eventually will make
>>> a PR. But first I need to finalize my work (Still need to add event
>>> logging).
>>> Currently I am in the process of creating Integration tests for this
>>> mechanism and have it partly working.
>>>
>>> But I'm having trouble creating multiple sessions from a single test.
>>> Browsing through the existing tests I've not found any example how this is
>>> done.
>>> Can anyone point me to an existing example or provide me with
>>> information howto initiate multiple sessions?
>>>
>>> Here are the tests I've written:
>>>
>>> https://github.com/mfdewit/keycloak/tree/KEYCLOAK-849-configurable-session-limits/testsuite/integration-arquillian/tests/base/src/test/java/org/keycloak/testsuite/sessionlimits
>>>
>>> Specifically, the UserSessionLimitsTest is requiring me to login
>>> multiple times. The RealmSessionTest is already working correctly as far as
>>> I can tell.
>>> Any help would be appreciated.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Wed, 20 Mar 2019 at 15:00, Mauro de Wit <maurodewit at gmail.com> wrote:
>>>
>>>> Makes sense. Thanks for the input guys.
>>>> I'm on the right track then :)
>>>>
>>>> On Wed, 20 Mar 2019 at 14:59, Marek Posolda <mposolda at redhat.com>
>>>> wrote:
>>>>
>>>>> On 20/03/2019 12:50, Stian Thorgersen wrote:
>>>>>
>>>>> I wasn't even aware we had the 'Post Login Flow'.
>>>>>
>>>>> From the description I would think that Post Login Flow is being
>>>>> executed before the user session is created, while there's an
>>>>> authentication session. So should be fine.
>>>>>
>>>>> Marek - can you confirm?
>>>>>
>>>>> Yes, exactly. User session doesn't yet exists when "Post Login Flow"
>>>>> is executed. This flow exists exactly because of use-cases like this -
>>>>> having the ability to execute the hooks after broker authentication. For
>>>>> example some people wanted to execute TOTP after the authentication with
>>>>> "facebook" broker etc.
>>>>>
>>>>> Marek
>>>>>
>>>>>
>>>>> On Wed, 20 Mar 2019 at 12:38, Mauro de Wit <maurodewit at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Isn't the 'Post login flow' in the IDP configuration the place for
>>>>>> this? Or do we want to avoid this since this is triggered after
>>>>>> authentication is complete and the session in created.
>>>>>> If this is the case, can you point me in the right direction to
>>>>>> create a hook into the redirect from the external broker?
>>>>>>
>>>>>> On Tue, 19 Mar 2019 at 10:59, Stian Thorgersen <sthorger at redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>>> You're right. In fact this should probably be split into two
>>>>>>> separate authenticators. For realm limits it should be checked as a first
>>>>>>> part (otherwise you have users authenticating and expensive password
>>>>>>> hashing when it's already known the session won't be permitted).
>>>>>>>
>>>>>>> For regular sessions authenticator works well, but to be honest I
>>>>>>> completely forgot about brokering. For realm limits it's fine as that
>>>>>>> authenticator can happen prior to the redirect, but for users there's no
>>>>>>> hook after the redirected back from the external broker today. There's the
>>>>>>> first login flow, but that only happens on the first time.
>>>>>>>
>>>>>>> On Mon, 18 Mar 2019 at 10:59, Mauro de Wit <maurodewit at gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Ok, I'm missing some fundamental understanding here. Please help :)
>>>>>>>>
>>>>>>>> In case of the browser flow, the authentication flow is executed
>>>>>>>> upon loading a page using the browser. At this time checks are being
>>>>>>>> performed to see if the user is already logged on. If this is the case, no
>>>>>>>> authentication has to be performed and the user is presented the requested
>>>>>>>> page.
>>>>>>>> But if the user is not yet logged on, the cookie authenticator
>>>>>>>> can't do anything usefull resulting in the next authenticator to trigger.
>>>>>>>> Eventually the 'browser forms' authenticator presents a login screen.
>>>>>>>>
>>>>>>>> Given the fact that we need to deny the user access in case a
>>>>>>>> session already exists for his/her account on another machine, we need to
>>>>>>>> know who this user is. How can we know which user we are dealing with at
>>>>>>>> the start of the flow?
>>>>>>>> I can see this working for limiting the number of sessions for each
>>>>>>>> realm, but not for limiting sessions bound to individual user accounts.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, 18 Mar 2019 at 09:19, Stian Thorgersen <sthorger at redhat.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> The authenticator should be added after the cookie authenticator,
>>>>>>>>> not at the end. That will make it take affect for IdP logins as well. So
>>>>>>>>> it's a matter of configuring it in two flows browser and direct grant.
>>>>>>>>>
>>>>>>>>> I appreciate it may not be the best usability, but I don't want to
>>>>>>>>> introduce something special/hard-coded for this feature. A later
>>>>>>>>> improvement could be to improve on the authentication flows. To have
>>>>>>>>> different elements in a flow and not just executions as well as potentially
>>>>>>>>> having some pre-flow checks that are done in all flows. I'd say this
>>>>>>>>> approach is good enough though at least for now.
>>>>>>>>>
>>>>>>>>> On Mon, 18 Mar 2019 at 09:00, Mauro de Wit <maurodewit at gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> That is indeed one of the downsides of this approach.
>>>>>>>>>> But can a misconfiguration of this functionality do any harm,
>>>>>>>>>> besides some inconsistent behavior between authentication methods?
>>>>>>>>>>
>>>>>>>>>> @stian at redhat.com <stian at redhat.com> any thoughts?
>>>>>>>>>>
>>>>>>>>>> On Fri, 15 Mar 2019 at 15:23, Jared Blashka <jblashka at redhat.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> If this is done via an authenticator wouldn't you have to make
>>>>>>>>>>> sure that this authenticator is present (and all the same settings are
>>>>>>>>>>> maintained) in the browser flow as well as the direct access flow as well
>>>>>>>>>>> as the login flows for all configured identity providers? It seems like it
>>>>>>>>>>> would be quite easy to make a mistake in that process and misconfigure
>>>>>>>>>>> something somewhere.
>>>>>>>>>>>
>>>>>>>>>>> On Fri, Mar 15, 2019 at 5:41 AM Mauro de Wit <
>>>>>>>>>>> maurodewit at gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> I've started to create a simple proof of concept and want to
>>>>>>>>>>>> check if I
>>>>>>>>>>>> have my facts straight.
>>>>>>>>>>>> As previously discussed this functionality should be provided
>>>>>>>>>>>> by a custom
>>>>>>>>>>>> Authenticator that is configured in an authentication flow.
>>>>>>>>>>>>
>>>>>>>>>>>> What I've done so far is:
>>>>>>>>>>>> - Created implementations for both the Authenticator and
>>>>>>>>>>>> AuthenticatorFactory interfaces.
>>>>>>>>>>>> - Added a set of ProviderConfigProperty instances that allow
>>>>>>>>>>>> the desired
>>>>>>>>>>>> configuration.
>>>>>>>>>>>> - Perform the check if any session limits are exceeded inside
>>>>>>>>>>>> the
>>>>>>>>>>>> authenticate() method of the Authenticator class. (Any session
>>>>>>>>>>>> invalidation
>>>>>>>>>>>> will be performed here as well)
>>>>>>>>>>>>
>>>>>>>>>>>> Now, in order to use session limiting for regular
>>>>>>>>>>>> username/password form
>>>>>>>>>>>> logins, I have created a copy of the 'browser flow' and added
>>>>>>>>>>>> this
>>>>>>>>>>>> Authenticator as a 'required' execution at the end of the flow.
>>>>>>>>>>>> In our case we allow IDP logins as well. And to use this
>>>>>>>>>>>> functionality for
>>>>>>>>>>>> these logins, I've created a new authentication flow containing
>>>>>>>>>>>> just this
>>>>>>>>>>>> Authenticator. Finally this flow is selected in the 'Post login
>>>>>>>>>>>> flow' of
>>>>>>>>>>>> the IDP configuration.
>>>>>>>>>>>> For both scenarios the Authenticator seems to be triggered at
>>>>>>>>>>>> the right
>>>>>>>>>>>> time and I should be able to apply the session limiting rules.
>>>>>>>>>>>>
>>>>>>>>>>>> Any thoughts or comments so far?
>>>>>>>>>>>>
>>>>>>>>>>>> On Tue, 12 Mar 2019 at 14:53, Mauro de Wit <
>>>>>>>>>>>> maurodewit at gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> > Ok, thanks for the clarification.
>>>>>>>>>>>> >
>>>>>>>>>>>> > On Tue, 12 Mar 2019 at 12:39, Stian Thorgersen <
>>>>>>>>>>>> sthorger at redhat.com>
>>>>>>>>>>>> > wrote:
>>>>>>>>>>>> >
>>>>>>>>>>>> >> It should be a pluggable part of the authentication flow and
>>>>>>>>>>>> not a
>>>>>>>>>>>> >> hardcoded element. There is no other way to plug in to the
>>>>>>>>>>>> authentication
>>>>>>>>>>>> >> flow other than creating an authenticator. An authenticator
>>>>>>>>>>>> doesn't need to
>>>>>>>>>>>> >> provide a challenge though so it can be used in this
>>>>>>>>>>>> instance.
>>>>>>>>>>>> >>
>>>>>>>>>>>> >> On Tue, 12 Mar 2019 at 10:57, Mauro de Wit <
>>>>>>>>>>>> maurodewit at gmail.com> wrote:
>>>>>>>>>>>> >>
>>>>>>>>>>>> >>> Hello,
>>>>>>>>>>>> >>>
>>>>>>>>>>>> >>> I am sending this e-mail because I have some questions
>>>>>>>>>>>> regarding the
>>>>>>>>>>>> >>> enhancement request that enables configurable session
>>>>>>>>>>>> limiting in
>>>>>>>>>>>> >>> Keycloak
>>>>>>>>>>>> >>> as discussed here:
>>>>>>>>>>>> >>> https://issues.jboss.org/browse/KEYCLOAK-849 (The
>>>>>>>>>>>> developer that Marc
>>>>>>>>>>>> >>> Wijma
>>>>>>>>>>>> >>> referred to in his comment as being available for this task
>>>>>>>>>>>> is me btw :))
>>>>>>>>>>>> >>>
>>>>>>>>>>>> >>> In the comments a solution is proposed that makes use of a
>>>>>>>>>>>> custom
>>>>>>>>>>>> >>> Authenticator that is dropped into the authentication flow
>>>>>>>>>>>> where it can
>>>>>>>>>>>> >>> be
>>>>>>>>>>>> >>> configured. While I can see the benefit of leveraging the
>>>>>>>>>>>> existing
>>>>>>>>>>>> >>> components as much as possible (including the configuration
>>>>>>>>>>>> options in
>>>>>>>>>>>> >>> that
>>>>>>>>>>>> >>> flow), I am wondering if this is the best solution. As far
>>>>>>>>>>>> as I can tell,
>>>>>>>>>>>> >>> this component is not performing any authentication at all.
>>>>>>>>>>>> Moreover this
>>>>>>>>>>>> >>> functionality operates 'above' the authentication
>>>>>>>>>>>> mechanisms and should
>>>>>>>>>>>> >>> apply to all of them.
>>>>>>>>>>>> >>> So is an Authenticator really the desired place to
>>>>>>>>>>>> implement this? Or is
>>>>>>>>>>>> >>> this just the quickest route, while not being the most
>>>>>>>>>>>> desirable option
>>>>>>>>>>>> >>> for
>>>>>>>>>>>> >>> the long term? What would be an alternative approach be?
>>>>>>>>>>>> That would place
>>>>>>>>>>>> >>> this implementation and configuration in the existing
>>>>>>>>>>>> Session
>>>>>>>>>>>> >>> configuration
>>>>>>>>>>>> >>> code for instance.
>>>>>>>>>>>> >>>
>>>>>>>>>>>> >>> I just now started investigating this task and looking into
>>>>>>>>>>>> the options
>>>>>>>>>>>> >>> that would meet our requirements. Hope to hear from you.
>>>>>>>>>>>> >>>
>>>>>>>>>>>> >>> Regards
>>>>>>>>>>>> >>>
>>>>>>>>>>>> >>> Mauro
>>>>>>>>>>>> >>>
>>>>>>>>>>>> >>> >
>>>>>>>>>>>> >>> _______________________________________________
>>>>>>>>>>>> >>> keycloak-dev mailing list
>>>>>>>>>>>> >>> keycloak-dev at lists.jboss.org
>>>>>>>>>>>> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>>>>>> >>>
>>>>>>>>>>>> >>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> keycloak-dev mailing list
>>>>>>>>>>>> keycloak-dev at lists.jboss.org
>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>
>>>

From maurodewit at gmail.com  Tue Apr  2 08:31:12 2019
From: maurodewit at gmail.com (Mauro de Wit)
Date: Tue, 2 Apr 2019 14:31:12 +0200
Subject: [keycloak-dev] Keycloak session limiting (KEYCLOAK-849) (BA-93)
In-Reply-To: <CAJgngAfp2E+004Y5LH6mkN5APsBk2f-0D8EJkywPEC-BPgy2hA@mail.gmail.com>
References: <CACihWx2N0zfT2pTSgRxtQnwavwNa7CiQefQ9O=GVrwX=7YB3pQ@mail.gmail.com>
	<CAJgngAfsW2PoaAkZUa7V8_tZuTQW-7a7vFzSYW7f9UiP_LkqUw@mail.gmail.com>
	<CACihWx2NnqaBMUdoGuzgUBsEAR4Ltx1xNdc0Quvk-F67aHMW=Q@mail.gmail.com>
	<CACihWx1JAxGz_Zn=Q0xCsB=T9wvDiEBwn6oB=pcooV6TP7NZqw@mail.gmail.com>
	<CALO-DfAoZpdzweZyx1iBXK=nU3XGqDpjgE8202QDJOraTFaYJQ@mail.gmail.com>
	<CACihWx2SWcXqq=gy+X3U=Ct0o2E+zaVAKpH-ahJS88+E64AqRQ@mail.gmail.com>
	<CAJgngAfJ2pgUgLBu2gXnmxrdicFzigPgfG=G4yudsPgz82pcZg@mail.gmail.com>
	<CACihWx2fi+tpT57grJ85pRdrj36f0cuvsErwoQUdSkUQeVrJOQ@mail.gmail.com>
	<CAJgngAdOEEAb4yAn4j=0aXE2=4fnjB8yMck8Yw4=88+SqRzvRw@mail.gmail.com>
	<CACihWx3Pk+_1Nbi+9uzvH1VchZCbf3rJi5sMvcHnCGMnD6Y8DA@mail.gmail.com>
	<CAJgngAduexRmVouqoYnEnmD-Lba5quKAZ5gC4dO7cBFM9kChqA@mail.gmail.com>
	<8d3aaed6-f878-ac5e-0132-0ceae2934471@redhat.com>
	<CACihWx1WDLS56OWvW7ppMVBPG8aiy0RhaL_N1K21ZZTLOkTCdA@mail.gmail.com>
	<CACihWx1_pE49_4L8thAvKoALRfs8p7nTkmc3YB0XDnSAXVZB=w@mail.gmail.com>
	<9c832dce-71b7-1877-c10f-ee4593beac04@redhat.com>
	<CACihWx2tKZ9fToQRL-GkfuaDUmYMSjnmbh=fQa3srFEvjO9iVw@mail.gmail.com>
	<CACihWx0oRyZ+uCq7OwSJn8mfaCSJcOMav__AUP77Qyf3C0kvmQ@mail.gmail.com>
	<CAJgngAfp2E+004Y5LH6mkN5APsBk2f-0D8EJkywPEC-BPgy2hA@mail.gmail.com>
Message-ID: <CACihWx2nRzFewDz7zRwFkxNWG5Y+C1P=xSBfzo9q092uMObkew@mail.gmail.com>

I think there is some confusion here (at least for me :)) about using the
Oauth-client. Looking at the sources I see that the Oauth client uses the
regular login screen as well. The Oauth client I am referring to:
org.keycloak.testsuite.util.OAuthClient.
Seems like I am doing a regular browser login using this client since the
browser-flow is triggered. Interesting why it worked though (doesn't store
cookies maybe).

I'll test again with deleting cookies using the regular method. I'll keep
you posted.

On Tue, 2 Apr 2019 at 11:55, Stian Thorgersen <sthorger at redhat.com> wrote:

> Oauth client uses the direct grant flow though. We'll need tests for both
> flows. Deleting cookies should work, you may also be able to use a new
> webdriver instance with custom/different cookie store to allow controlling
> it
>
> On Tue, 2 Apr 2019, 10:31 Mauro de Wit, <maurodewit at gmail.com> wrote:
>
>> Using the Oauth client to create mutliple sessions works :)
>> based my code on org.keycloak.testsuite.oauth.LogoutTest and this is
>> exactly what I need!
>>
>> On Tue, 2 Apr 2019 at 11:15, Mauro de Wit <maurodewit at gmail.com> wrote:
>>
>>> Unfortunately this doesn't work. Deleting the cookies works, but still
>>> no new session is created. Had to navigate to the login page again though
>>> to delete the cookies, otherwise the URL didn't match and no cookies were
>>> deleted.
>>> Will give it a try now using the JAX RS or Oauth client now.
>>>
>>> On Mon, 1 Apr 2019 at 13:22, Marek Posolda <mposolda at redhat.com> wrote:
>>>
>>>> Maybe easiest is to login and then call :
>>>>
>>>> driver.manage().deleteAllCookies();
>>>>
>>>> This will delete all cookies, so you can login again within same browser (web driver) and the previous session is still valid (cookies were manually removed from browser, but session is still alive on
>>>> server-side as you did not logout). See for example LoginTest.loginExpiredCodeAndExpiredCookies() for some inspiration.
>>>>
>>>> Marek
>>>>
>>>> On 01/04/2019 11:59, Mauro de Wit wrote:
>>>>
>>>> Ok, I've found some time to continue on the session limiting task. I've
>>>> created a fork of the Keycloak repository from which I eventually will make
>>>> a PR. But first I need to finalize my work (Still need to add event
>>>> logging).
>>>> Currently I am in the process of creating Integration tests for this
>>>> mechanism and have it partly working.
>>>>
>>>> But I'm having trouble creating multiple sessions from a single test.
>>>> Browsing through the existing tests I've not found any example how this is
>>>> done.
>>>> Can anyone point me to an existing example or provide me with
>>>> information howto initiate multiple sessions?
>>>>
>>>> Here are the tests I've written:
>>>>
>>>> https://github.com/mfdewit/keycloak/tree/KEYCLOAK-849-configurable-session-limits/testsuite/integration-arquillian/tests/base/src/test/java/org/keycloak/testsuite/sessionlimits
>>>>
>>>> Specifically, the UserSessionLimitsTest is requiring me to login
>>>> multiple times. The RealmSessionTest is already working correctly as far as
>>>> I can tell.
>>>> Any help would be appreciated.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Wed, 20 Mar 2019 at 15:00, Mauro de Wit <maurodewit at gmail.com>
>>>> wrote:
>>>>
>>>>> Makes sense. Thanks for the input guys.
>>>>> I'm on the right track then :)
>>>>>
>>>>> On Wed, 20 Mar 2019 at 14:59, Marek Posolda <mposolda at redhat.com>
>>>>> wrote:
>>>>>
>>>>>> On 20/03/2019 12:50, Stian Thorgersen wrote:
>>>>>>
>>>>>> I wasn't even aware we had the 'Post Login Flow'.
>>>>>>
>>>>>> From the description I would think that Post Login Flow is being
>>>>>> executed before the user session is created, while there's an
>>>>>> authentication session. So should be fine.
>>>>>>
>>>>>> Marek - can you confirm?
>>>>>>
>>>>>> Yes, exactly. User session doesn't yet exists when "Post Login Flow"
>>>>>> is executed. This flow exists exactly because of use-cases like this -
>>>>>> having the ability to execute the hooks after broker authentication. For
>>>>>> example some people wanted to execute TOTP after the authentication with
>>>>>> "facebook" broker etc.
>>>>>>
>>>>>> Marek
>>>>>>
>>>>>>
>>>>>> On Wed, 20 Mar 2019 at 12:38, Mauro de Wit <maurodewit at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Isn't the 'Post login flow' in the IDP configuration the place for
>>>>>>> this? Or do we want to avoid this since this is triggered after
>>>>>>> authentication is complete and the session in created.
>>>>>>> If this is the case, can you point me in the right direction to
>>>>>>> create a hook into the redirect from the external broker?
>>>>>>>
>>>>>>> On Tue, 19 Mar 2019 at 10:59, Stian Thorgersen <sthorger at redhat.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> You're right. In fact this should probably be split into two
>>>>>>>> separate authenticators. For realm limits it should be checked as a first
>>>>>>>> part (otherwise you have users authenticating and expensive password
>>>>>>>> hashing when it's already known the session won't be permitted).
>>>>>>>>
>>>>>>>> For regular sessions authenticator works well, but to be honest I
>>>>>>>> completely forgot about brokering. For realm limits it's fine as that
>>>>>>>> authenticator can happen prior to the redirect, but for users there's no
>>>>>>>> hook after the redirected back from the external broker today. There's the
>>>>>>>> first login flow, but that only happens on the first time.
>>>>>>>>
>>>>>>>> On Mon, 18 Mar 2019 at 10:59, Mauro de Wit <maurodewit at gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Ok, I'm missing some fundamental understanding here. Please help :)
>>>>>>>>>
>>>>>>>>> In case of the browser flow, the authentication flow is executed
>>>>>>>>> upon loading a page using the browser. At this time checks are being
>>>>>>>>> performed to see if the user is already logged on. If this is the case, no
>>>>>>>>> authentication has to be performed and the user is presented the requested
>>>>>>>>> page.
>>>>>>>>> But if the user is not yet logged on, the cookie authenticator
>>>>>>>>> can't do anything usefull resulting in the next authenticator to trigger.
>>>>>>>>> Eventually the 'browser forms' authenticator presents a login screen.
>>>>>>>>>
>>>>>>>>> Given the fact that we need to deny the user access in case a
>>>>>>>>> session already exists for his/her account on another machine, we need to
>>>>>>>>> know who this user is. How can we know which user we are dealing with at
>>>>>>>>> the start of the flow?
>>>>>>>>> I can see this working for limiting the number of sessions for
>>>>>>>>> each realm, but not for limiting sessions bound to individual user accounts.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Mon, 18 Mar 2019 at 09:19, Stian Thorgersen <
>>>>>>>>> sthorger at redhat.com> wrote:
>>>>>>>>>
>>>>>>>>>> The authenticator should be added after the cookie authenticator,
>>>>>>>>>> not at the end. That will make it take affect for IdP logins as well. So
>>>>>>>>>> it's a matter of configuring it in two flows browser and direct grant.
>>>>>>>>>>
>>>>>>>>>> I appreciate it may not be the best usability, but I don't want
>>>>>>>>>> to introduce something special/hard-coded for this feature. A later
>>>>>>>>>> improvement could be to improve on the authentication flows. To have
>>>>>>>>>> different elements in a flow and not just executions as well as potentially
>>>>>>>>>> having some pre-flow checks that are done in all flows. I'd say this
>>>>>>>>>> approach is good enough though at least for now.
>>>>>>>>>>
>>>>>>>>>> On Mon, 18 Mar 2019 at 09:00, Mauro de Wit <maurodewit at gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> That is indeed one of the downsides of this approach.
>>>>>>>>>>> But can a misconfiguration of this functionality do any harm,
>>>>>>>>>>> besides some inconsistent behavior between authentication methods?
>>>>>>>>>>>
>>>>>>>>>>> @stian at redhat.com <stian at redhat.com> any thoughts?
>>>>>>>>>>>
>>>>>>>>>>> On Fri, 15 Mar 2019 at 15:23, Jared Blashka <jblashka at redhat.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> If this is done via an authenticator wouldn't you have to make
>>>>>>>>>>>> sure that this authenticator is present (and all the same settings are
>>>>>>>>>>>> maintained) in the browser flow as well as the direct access flow as well
>>>>>>>>>>>> as the login flows for all configured identity providers? It seems like it
>>>>>>>>>>>> would be quite easy to make a mistake in that process and misconfigure
>>>>>>>>>>>> something somewhere.
>>>>>>>>>>>>
>>>>>>>>>>>> On Fri, Mar 15, 2019 at 5:41 AM Mauro de Wit <
>>>>>>>>>>>> maurodewit at gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> I've started to create a simple proof of concept and want to
>>>>>>>>>>>>> check if I
>>>>>>>>>>>>> have my facts straight.
>>>>>>>>>>>>> As previously discussed this functionality should be provided
>>>>>>>>>>>>> by a custom
>>>>>>>>>>>>> Authenticator that is configured in an authentication flow.
>>>>>>>>>>>>>
>>>>>>>>>>>>> What I've done so far is:
>>>>>>>>>>>>> - Created implementations for both the Authenticator and
>>>>>>>>>>>>> AuthenticatorFactory interfaces.
>>>>>>>>>>>>> - Added a set of ProviderConfigProperty instances that allow
>>>>>>>>>>>>> the desired
>>>>>>>>>>>>> configuration.
>>>>>>>>>>>>> - Perform the check if any session limits are exceeded inside
>>>>>>>>>>>>> the
>>>>>>>>>>>>> authenticate() method of the Authenticator class. (Any session
>>>>>>>>>>>>> invalidation
>>>>>>>>>>>>> will be performed here as well)
>>>>>>>>>>>>>
>>>>>>>>>>>>> Now, in order to use session limiting for regular
>>>>>>>>>>>>> username/password form
>>>>>>>>>>>>> logins, I have created a copy of the 'browser flow' and added
>>>>>>>>>>>>> this
>>>>>>>>>>>>> Authenticator as a 'required' execution at the end of the flow.
>>>>>>>>>>>>> In our case we allow IDP logins as well. And to use this
>>>>>>>>>>>>> functionality for
>>>>>>>>>>>>> these logins, I've created a new authentication flow
>>>>>>>>>>>>> containing just this
>>>>>>>>>>>>> Authenticator. Finally this flow is selected in the 'Post
>>>>>>>>>>>>> login flow' of
>>>>>>>>>>>>> the IDP configuration.
>>>>>>>>>>>>> For both scenarios the Authenticator seems to be triggered at
>>>>>>>>>>>>> the right
>>>>>>>>>>>>> time and I should be able to apply the session limiting rules.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Any thoughts or comments so far?
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Tue, 12 Mar 2019 at 14:53, Mauro de Wit <
>>>>>>>>>>>>> maurodewit at gmail.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> > Ok, thanks for the clarification.
>>>>>>>>>>>>> >
>>>>>>>>>>>>> > On Tue, 12 Mar 2019 at 12:39, Stian Thorgersen <
>>>>>>>>>>>>> sthorger at redhat.com>
>>>>>>>>>>>>> > wrote:
>>>>>>>>>>>>> >
>>>>>>>>>>>>> >> It should be a pluggable part of the authentication flow
>>>>>>>>>>>>> and not a
>>>>>>>>>>>>> >> hardcoded element. There is no other way to plug in to the
>>>>>>>>>>>>> authentication
>>>>>>>>>>>>> >> flow other than creating an authenticator. An authenticator
>>>>>>>>>>>>> doesn't need to
>>>>>>>>>>>>> >> provide a challenge though so it can be used in this
>>>>>>>>>>>>> instance.
>>>>>>>>>>>>> >>
>>>>>>>>>>>>> >> On Tue, 12 Mar 2019 at 10:57, Mauro de Wit <
>>>>>>>>>>>>> maurodewit at gmail.com> wrote:
>>>>>>>>>>>>> >>
>>>>>>>>>>>>> >>> Hello,
>>>>>>>>>>>>> >>>
>>>>>>>>>>>>> >>> I am sending this e-mail because I have some questions
>>>>>>>>>>>>> regarding the
>>>>>>>>>>>>> >>> enhancement request that enables configurable session
>>>>>>>>>>>>> limiting in
>>>>>>>>>>>>> >>> Keycloak
>>>>>>>>>>>>> >>> as discussed here:
>>>>>>>>>>>>> >>> https://issues.jboss.org/browse/KEYCLOAK-849 (The
>>>>>>>>>>>>> developer that Marc
>>>>>>>>>>>>> >>> Wijma
>>>>>>>>>>>>> >>> referred to in his comment as being available for this
>>>>>>>>>>>>> task is me btw :))
>>>>>>>>>>>>> >>>
>>>>>>>>>>>>> >>> In the comments a solution is proposed that makes use of a
>>>>>>>>>>>>> custom
>>>>>>>>>>>>> >>> Authenticator that is dropped into the authentication flow
>>>>>>>>>>>>> where it can
>>>>>>>>>>>>> >>> be
>>>>>>>>>>>>> >>> configured. While I can see the benefit of leveraging the
>>>>>>>>>>>>> existing
>>>>>>>>>>>>> >>> components as much as possible (including the
>>>>>>>>>>>>> configuration options in
>>>>>>>>>>>>> >>> that
>>>>>>>>>>>>> >>> flow), I am wondering if this is the best solution. As far
>>>>>>>>>>>>> as I can tell,
>>>>>>>>>>>>> >>> this component is not performing any authentication at
>>>>>>>>>>>>> all. Moreover this
>>>>>>>>>>>>> >>> functionality operates 'above' the authentication
>>>>>>>>>>>>> mechanisms and should
>>>>>>>>>>>>> >>> apply to all of them.
>>>>>>>>>>>>> >>> So is an Authenticator really the desired place to
>>>>>>>>>>>>> implement this? Or is
>>>>>>>>>>>>> >>> this just the quickest route, while not being the most
>>>>>>>>>>>>> desirable option
>>>>>>>>>>>>> >>> for
>>>>>>>>>>>>> >>> the long term? What would be an alternative approach be?
>>>>>>>>>>>>> That would place
>>>>>>>>>>>>> >>> this implementation and configuration in the existing
>>>>>>>>>>>>> Session
>>>>>>>>>>>>> >>> configuration
>>>>>>>>>>>>> >>> code for instance.
>>>>>>>>>>>>> >>>
>>>>>>>>>>>>> >>> I just now started investigating this task and looking
>>>>>>>>>>>>> into the options
>>>>>>>>>>>>> >>> that would meet our requirements. Hope to hear from you.
>>>>>>>>>>>>> >>>
>>>>>>>>>>>>> >>> Regards
>>>>>>>>>>>>> >>>
>>>>>>>>>>>>> >>> Mauro
>>>>>>>>>>>>> >>>
>>>>>>>>>>>>> >>> >
>>>>>>>>>>>>> >>> _______________________________________________
>>>>>>>>>>>>> >>> keycloak-dev mailing list
>>>>>>>>>>>>> >>> keycloak-dev at lists.jboss.org
>>>>>>>>>>>>> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>>>>>>> >>>
>>>>>>>>>>>>> >>
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> keycloak-dev mailing list
>>>>>>>>>>>>> keycloak-dev at lists.jboss.org
>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>
>>>>

From mposolda at redhat.com  Tue Apr  2 09:12:30 2019
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 2 Apr 2019 15:12:30 +0200
Subject: [keycloak-dev] Application Initiated Actions Draft #2
In-Reply-To: <CAJgngAcynb2b9sohGrP2vDM=1hkBtH02TpXpGgCX34JwFtH7=w@mail.gmail.com>
References: <CAJgngAdDbTVEMXTp1ZaK6o0GqpBMy3M0HMMzJd605DoEofehOQ@mail.gmail.com>
	<CAJrcDBe_4DyvyOrcwo78M79uTKdcHSnEDkkL4Zf-UPbhZi0RtQ@mail.gmail.com>
	<CAJgngAdCpi5JWigc204Wn6AjuMzFzXJtQwMfMQLrLPVSB=xVYw@mail.gmail.com>
	<CAJrcDBeOWvhexi2k_pqEedZRFUp_3oC6HyhTOuzHFDpsb51Nvg@mail.gmail.com>
	<CAJgngAcynb2b9sohGrP2vDM=1hkBtH02TpXpGgCX34JwFtH7=w@mail.gmail.com>
Message-ID: <5d021dae-dcfc-c29f-00c9-cac5b8d085e0@redhat.com>

On 02/04/2019 08:47, Stian Thorgersen wrote:
> On Mon, 1 Apr 2019 at 21:43, Pedro Igor Silva <psilva at redhat.com> wrote:
>
>>
>> On Mon, Apr 1, 2019 at 3:44 PM Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>>
>>>
>>> On Mon, 1 Apr 2019, 18:54 Pedro Igor Silva, <psilva at redhat.com> wrote:
>>>
>>>> Hi Stian,
>>>>
>>>> A few additional comments:
>>>>
>>>> * "or alternatively the application can include an id_token_hint with
>>>> the request that proves the application does not need consent from the user"
>>>>
>>>> I understand that ID Tokens should be short-lived, but aren't we setting
>>>> the exp of ID tokens with the value from access tokens? See
>>>> org.keycloak.protocol.oidc.TokenManager.AccessTokenResponseBuilder#generateIDToken.
>>>>
>>> On my phone so can't look at that. ID tokens have some expiration as
>>> access tokens surely?
>>>
>> It seems so
>> https://github.com/keycloak/keycloak/blob/061693a8c981987216d37658c7937dd3ca613b50/services/src/main/java/org/keycloak/protocol/oidc/TokenManager.java#L741.
>> I did run some tests to make sure I'm not missing anything ... Hope I'm
>> wrong :)
>>
> They should have the same expiration surely?
Yes, they have same expiration.
>
>
>>
>>>
>>>> In addition to that, I don't think that using a front-channel to pass
>>>> tokens is something we want to do given that there are a lot of
>>>> considerations around this approach. If we are really going this way, I
>>>> think we should at least consider some form of proof-of-possession.
>>>>
>>> I'm not 100% convinced about id_token_hint either, but OIDC spec already
>>> uses id_token_hint several places. It's in the auth endpoint already (not
>>> something we're adding) also used in logout specs. I also struggle to see
>>> how it can be missused even if obtained.
>>>
>>> Proof of possession is a nice idea, but not sure how that could be done
>>> without storing additional things at the server side.
>>>
>> I can look at that if you want and see if we can apply here some PoP
>> technique.
>>
> Sure - we could potentially support both id_token_hint and a PoP technique
> (if we can do the latter in a nice way)
>
>
>> I missed this parameter in OIDC spec. So maybe we are cool then and should
>> just use it? Kind of interesting this, you see a lot of warnings in OAuth
>> 2.0 about using front-channel to deliver tokens (e.g.: implicit) and in
>> OIDC I did not find anything ... Well, we are backed by the spec then to
>> keep this simple...
>>
> There's a difference in leaking a refresh token and access token to leaking
> a ID token IMO. From thinking about it I can't see how you would use a
> leaked ID token as apps don't accept them in the same way as services
> accept access tokens.

Hopefully yes, but even if ID Token is leaked, it is not ideal. In the 
past, we had issues with the fact that IDToken could be used as 
accessToken. This shouldn't be an issue in our adapters, where we test 
the "typ" and audience in the tokens. But some 3rd party service can be 
buggy and still accept ID Token as access token due some missing checks. 
Hopefully this is not big issue in reality...

Marek

>
>
>> Of course, this is different than sending tokens to a client which you
>> don't control. But still, suffer some of the same vulnerabilities ...
>>
>>
>>>
>>>> For last, maybe you should explicitly mention the usage of TLS?
>>>>
>>> I do believe that is already implied? Oauth/OIDC/tokens are completely
>>> insecure without TLS.
>>>
>> Yeah, I just wanted to highlight this based on the list of considerations
>> you added into "Notes on id_token hint". You pointed out some that could be
>> considered to be an implied concern.
>>
>>
>>>
>>>> Regards.
>>>> Pedro Igor
>>>>
>>>> On Wed, Mar 27, 2019 at 9:43 PM Stian Thorgersen <sthorger at redhat.com>
>>>> wrote:
>>>>
>>>>> Based on feedback and also thinking about this a bit more I've now
>>>>> updated
>>>>> the proposal for Application Initiated Actions.
>>>>>
>>>>> Please read and comment on the update draft if you're interested.
>>>>>
>>>>>
>>>>> https://github.com/keycloak/keycloak-community/blob/master/design/application-initiated-actions.md
>>>>> _______________________________________________
>>>>> keycloak-dev mailing list
>>>>> keycloak-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



From psilva at redhat.com  Tue Apr  2 09:19:24 2019
From: psilva at redhat.com (Pedro Igor Silva)
Date: Tue, 2 Apr 2019 10:19:24 -0300
Subject: [keycloak-dev] Application Initiated Actions Draft #2
In-Reply-To: <CAJgngAcynb2b9sohGrP2vDM=1hkBtH02TpXpGgCX34JwFtH7=w@mail.gmail.com>
References: <CAJgngAdDbTVEMXTp1ZaK6o0GqpBMy3M0HMMzJd605DoEofehOQ@mail.gmail.com>
	<CAJrcDBe_4DyvyOrcwo78M79uTKdcHSnEDkkL4Zf-UPbhZi0RtQ@mail.gmail.com>
	<CAJgngAdCpi5JWigc204Wn6AjuMzFzXJtQwMfMQLrLPVSB=xVYw@mail.gmail.com>
	<CAJrcDBeOWvhexi2k_pqEedZRFUp_3oC6HyhTOuzHFDpsb51Nvg@mail.gmail.com>
	<CAJgngAcynb2b9sohGrP2vDM=1hkBtH02TpXpGgCX34JwFtH7=w@mail.gmail.com>
Message-ID: <CAJrcDBeUaejze1X60j4uXQ5MvVLa2pyt5yahHZ-uUYynOKs6qQ@mail.gmail.com>

On Tue, Apr 2, 2019 at 3:47 AM Stian Thorgersen <sthorger at redhat.com> wrote:

>
>
> On Mon, 1 Apr 2019 at 21:43, Pedro Igor Silva <psilva at redhat.com> wrote:
>
>>
>>
>> On Mon, Apr 1, 2019 at 3:44 PM Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>>
>>>
>>>
>>> On Mon, 1 Apr 2019, 18:54 Pedro Igor Silva, <psilva at redhat.com> wrote:
>>>
>>>> Hi Stian,
>>>>
>>>> A few additional comments:
>>>>
>>>> * "or alternatively the application can include an id_token_hint with
>>>> the request that proves the application does not need consent from the user"
>>>>
>>>> I understand that ID Tokens should be short-lived, but aren't we
>>>> setting the exp of ID tokens with the value from access tokens? See
>>>> org.keycloak.protocol.oidc.TokenManager.AccessTokenResponseBuilder#generateIDToken.
>>>>
>>>
>>> On my phone so can't look at that. ID tokens have some expiration as
>>> access tokens surely?
>>>
>>
>> It seems so
>> https://github.com/keycloak/keycloak/blob/061693a8c981987216d37658c7937dd3ca613b50/services/src/main/java/org/keycloak/protocol/oidc/TokenManager.java#L741.
>> I did run some tests to make sure I'm not missing anything ... Hope I'm
>> wrong :)
>>
>
> They should have the same expiration surely?
>

I'm not sure. As you said already, ID Tokens is all about authentication
while the AT is about authorization. Given their natures, I think they
should not have the same expiration? Or we should at least make this
configurable so people can define ID Token life time accordingly with their
requirements.

ID Token lifetime should be enough to authenticate the user to a client.
Which can differ from the lifetime of AT/authorization.


>
>
>>
>>
>>>
>>>
>>>> In addition to that, I don't think that using a front-channel to pass
>>>> tokens is something we want to do given that there are a lot of
>>>> considerations around this approach. If we are really going this way, I
>>>> think we should at least consider some form of proof-of-possession.
>>>>
>>>
>>> I'm not 100% convinced about id_token_hint either, but OIDC spec already
>>> uses id_token_hint several places. It's in the auth endpoint already (not
>>> something we're adding) also used in logout specs. I also struggle to see
>>> how it can be missused even if obtained.
>>>
>>> Proof of possession is a nice idea, but not sure how that could be done
>>> without storing additional things at the server side.
>>>
>>
>> I can look at that if you want and see if we can apply here some PoP
>> technique.
>>
>
> Sure - we could potentially support both id_token_hint and a PoP technique
> (if we can do the latter in a nice way)
>
>
>>
>> I missed this parameter in OIDC spec. So maybe we are cool then and
>> should just use it? Kind of interesting this, you see a lot of warnings in
>> OAuth 2.0 about using front-channel to deliver tokens (e.g.: implicit) and
>> in OIDC I did not find anything ... Well, we are backed by the spec then to
>> keep this simple...
>>
>
> There's a difference in leaking a refresh token and access token to
> leaking a ID token IMO. From thinking about it I can't see how you would
> use a leaked ID token as apps don't accept them in the same way as services
> accept access tokens.
>

I agree, AT and RT leakage is much worse. But for ID Tokens the concern
should be how these services are accepting bearer tokens and all the
constraints they are imposing to accept them. For instance, audience
checks, etc.


>
>
>>
>> Of course, this is different than sending tokens to a client which you
>> don't control. But still, suffer some of the same vulnerabilities ...
>>
>>
>>>
>>>
>>>> For last, maybe you should explicitly mention the usage of TLS?
>>>>
>>>
>>> I do believe that is already implied? Oauth/OIDC/tokens are completely
>>> insecure without TLS.
>>>
>>
>> Yeah, I just wanted to highlight this based on the list of considerations
>> you added into "Notes on id_token hint". You pointed out some that could be
>> considered to be an implied concern.
>>
>>
>>>
>>>
>>>> Regards.
>>>> Pedro Igor
>>>>
>>>> On Wed, Mar 27, 2019 at 9:43 PM Stian Thorgersen <sthorger at redhat.com>
>>>> wrote:
>>>>
>>>>> Based on feedback and also thinking about this a bit more I've now
>>>>> updated
>>>>> the proposal for Application Initiated Actions.
>>>>>
>>>>> Please read and comment on the update draft if you're interested.
>>>>>
>>>>>
>>>>> https://github.com/keycloak/keycloak-community/blob/master/design/application-initiated-actions.md
>>>>> _______________________________________________
>>>>> keycloak-dev mailing list
>>>>> keycloak-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>
>>>>

From mposolda at redhat.com  Tue Apr  2 09:21:48 2019
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 2 Apr 2019 15:21:48 +0200
Subject: [keycloak-dev] Proposal: Improvements to IdpUsernamePasswordForm
In-Reply-To: <1553789204.3600.7.camel@carretti.pro>
References: <1553789204.3600.7.camel@carretti.pro>
Message-ID: <664811e2-cad4-9b62-c168-39de1981afc3@redhat.com>

On 28/03/2019 17:06, Dmitry Telegin wrote:
> Hi,
>
> I'm currently working to implement the following requirements:
> - users are managed externally via LDAP, self-registrations disabled;
> - there is an external IdP;
> - generally, there is no way to automatically match IdP identity with Keycloak's one, so IdP linking will always be performed by the user manually;
> - in order to do that, the user should click the IdP icon in the login screen, authenticate with the IdP, get back to Keycloak and "claim" his/her Keycloak account by entering correct username and password.
>
> Currently, the closest thing in Keycloak is o.k.authentication.authenticators.broker.IdpUsernamePasswordForm (aka "idp-username-password-form", aka "Username Password Form for identity provider reauthentication").
> However, it 1) prefills username field and makes it non-editable, 2) depends on the preceding IdpCreateUserIfUniqueAuthenticator execution to provide existing user model (EXISTING_USER_INFO auth note).
>
> My proposal is to improve IdpUsernamePasswordForm by allowing its execution even without the preceding IdpCreateUserIfUniqueAuthenticator. In the absence of EXISTING_USER_INFO, IdpUsernamePasswordForm should allow the user to manually enter username.

I wonder if you can't already achieve something like this with the OOTB 
authenticator implementations, but just correctly configure them? For 
example in the "First Broker Login" flow used for your identity 
provider, you can just directly use the default browser-based 
authenticator ( UsernamePasswordForm ) instead of the 
IdpUsernamePasswordForm. That way, the username+password form will be 
always shown for "First Broker Login" and once user authenticates, his 
account will be linked with IdP account.

Marek

>
> Please let me know if you think it's worth having this in Keycloak. Regards,
> Dmitry
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



From psilva at redhat.com  Tue Apr  2 09:24:05 2019
From: psilva at redhat.com (Pedro Igor Silva)
Date: Tue, 2 Apr 2019 10:24:05 -0300
Subject: [keycloak-dev] Application Initiated Actions Draft #2
In-Reply-To: <5d021dae-dcfc-c29f-00c9-cac5b8d085e0@redhat.com>
References: <CAJgngAdDbTVEMXTp1ZaK6o0GqpBMy3M0HMMzJd605DoEofehOQ@mail.gmail.com>
	<CAJrcDBe_4DyvyOrcwo78M79uTKdcHSnEDkkL4Zf-UPbhZi0RtQ@mail.gmail.com>
	<CAJgngAdCpi5JWigc204Wn6AjuMzFzXJtQwMfMQLrLPVSB=xVYw@mail.gmail.com>
	<CAJrcDBeOWvhexi2k_pqEedZRFUp_3oC6HyhTOuzHFDpsb51Nvg@mail.gmail.com>
	<CAJgngAcynb2b9sohGrP2vDM=1hkBtH02TpXpGgCX34JwFtH7=w@mail.gmail.com>
	<5d021dae-dcfc-c29f-00c9-cac5b8d085e0@redhat.com>
Message-ID: <CAJrcDBefLAO8OT18BJqCBs4Ntt7wN=7iAURnFaTPQ8kde+NoUg@mail.gmail.com>

On Tue, Apr 2, 2019 at 10:12 AM Marek Posolda <mposolda at redhat.com> wrote:

> > There's a difference in leaking a refresh token and access token to
> leaking
> > a ID token IMO. From thinking about it I can't see how you would use a
> > leaked ID token as apps don't accept them in the same way as services
> > accept access tokens.
>
> Hopefully yes, but even if ID Token is leaked, it is not ideal. In the
> past, we had issues with the fact that IDToken could be used as
> accessToken. This shouldn't be an issue in our adapters, where we test
> the "typ" and audience in the tokens. But some 3rd party service can be
> buggy and still accept ID Token as access token due some missing checks.
> Hopefully this is not big issue in reality...
>

+1. But audience check is still false by default, right?

From mposolda at redhat.com  Tue Apr  2 09:39:30 2019
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 2 Apr 2019 15:39:30 +0200
Subject: [keycloak-dev] Application Initiated Actions Draft #2
In-Reply-To: <CAJrcDBefLAO8OT18BJqCBs4Ntt7wN=7iAURnFaTPQ8kde+NoUg@mail.gmail.com>
References: <CAJgngAdDbTVEMXTp1ZaK6o0GqpBMy3M0HMMzJd605DoEofehOQ@mail.gmail.com>
	<CAJrcDBe_4DyvyOrcwo78M79uTKdcHSnEDkkL4Zf-UPbhZi0RtQ@mail.gmail.com>
	<CAJgngAdCpi5JWigc204Wn6AjuMzFzXJtQwMfMQLrLPVSB=xVYw@mail.gmail.com>
	<CAJrcDBeOWvhexi2k_pqEedZRFUp_3oC6HyhTOuzHFDpsb51Nvg@mail.gmail.com>
	<CAJgngAcynb2b9sohGrP2vDM=1hkBtH02TpXpGgCX34JwFtH7=w@mail.gmail.com>
	<5d021dae-dcfc-c29f-00c9-cac5b8d085e0@redhat.com>
	<CAJrcDBefLAO8OT18BJqCBs4Ntt7wN=7iAURnFaTPQ8kde+NoUg@mail.gmail.com>
Message-ID: <b960d404-45e4-bbbd-9633-b1dd6d2e0690@redhat.com>

On 02/04/2019 15:24, Pedro Igor Silva wrote:
>
>
> On Tue, Apr 2, 2019 at 10:12 AM Marek Posolda <mposolda at redhat.com 
> <mailto:mposolda at redhat.com>> wrote:
>
>     > There's a difference in leaking a refresh token and access token
>     to leaking
>     > a ID token IMO. From thinking about it I can't see how you would
>     use a
>     > leaked ID token as apps don't accept them in the same way as
>     services
>     > accept access tokens.
>
>     Hopefully yes, but even if ID Token is leaked, it is not ideal. In
>     the
>     past, we had issues with the fact that IDToken could be used as
>     accessToken. This shouldn't be an issue in our adapters, where we
>     test
>     the "typ" and audience in the tokens. But some 3rd party service
>     can be
>     buggy and still accept ID Token as access token due some missing
>     checks.
>     Hopefully this is not big issue in reality...
>
>
> +1. But audience?check is still false by default, right?

Yes. But the "typ" is checked in our adapters, so you won't be able to 
use ID token as access token. I think the issue could be just for 3rd 
party adapters, which may not check all the necessary things.

Marek


From demetrio at carretti.pro  Wed Apr  3 18:45:37 2019
From: demetrio at carretti.pro (Dmitry Telegin)
Date: Thu, 04 Apr 2019 01:45:37 +0300
Subject: [keycloak-dev] Proposal: Improvements to IdpUsernamePasswordForm
In-Reply-To: <664811e2-cad4-9b62-c168-39de1981afc3@redhat.com>
References: <1553789204.3600.7.camel@carretti.pro>
	<664811e2-cad4-9b62-c168-39de1981afc3@redhat.com>
Message-ID: <1554331537.4647.3.camel@carretti.pro>

Hi Marek,

You absolutely right, UsernamePasswordForm does the trick. However, the login screen rendered by?UsernamePasswordForm is different from that of IdpUsernamePasswordForm in the following aspects:
- IdpUsernamePasswordForm doesn't display the block with IdP/social buttons;
- IdpUsernamePasswordForm renders the message relevant to IdP-linking-by-reauthentication, which is this:

federatedIdentityConfirmReauthenticateMessage=Authenticate as {0} to link your account with {1}

So, my requirement is to implement the appearance of IdpUsernamePasswordForm + behavior of UsernamePasswordForm. I think this could be done either by augmenting the former, or by merging the two authenticators into a unified one, that would exhibit different behavior depending on the context (normal login vs. reauthentication for IdP linking).

Please let me know which way seems better for you, with the idea in mind of having this contributed to upstream.

Thanks!
Dmitry

On Tue, 2019-04-02 at 15:21 +0200, Marek Posolda wrote:
> On 28/03/2019 17:06, Dmitry Telegin wrote:
> > Hi,
> > 
> > I'm currently working to implement the following requirements:
> > - users are managed externally via LDAP, self-registrations disabled;
> > - there is an external IdP;
> > - generally, there is no way to automatically match IdP identity with Keycloak's one, so IdP linking will always be performed by the user manually;
> > - in order to do that, the user should click the IdP icon in the login screen, authenticate with the IdP, get back to Keycloak and "claim" his/her Keycloak account by entering correct username and password.
> > 
> > Currently, the closest thing in Keycloak is o.k.authentication.authenticators.broker.IdpUsernamePasswordForm (aka "idp-username-password-form", aka "Username Password Form for identity provider reauthentication").
> > However, it 1) prefills username field and makes it non-editable, 2) depends on the preceding IdpCreateUserIfUniqueAuthenticator execution to provide existing user model (EXISTING_USER_INFO auth note).
> > 
> > My proposal is to improve IdpUsernamePasswordForm by allowing its execution even without the preceding IdpCreateUserIfUniqueAuthenticator. In the absence of EXISTING_USER_INFO, IdpUsernamePasswordForm should allow the user to manually enter username.
> 
> I wonder if you can't already achieve something like this with the OOTB?
> authenticator implementations, but just correctly configure them? For?
> example in the "First Broker Login" flow used for your identity?
> provider, you can just directly use the default browser-based?
> authenticator ( UsernamePasswordForm ) instead of the?
> IdpUsernamePasswordForm. That way, the username+password form will be?
> always shown for "First Broker Login" and once user authenticates, his?
> account will be linked with IdP account.
> 
> Marek
> 
> > 
> > Please let me know if you think it's worth having this in Keycloak. Regards,
> > Dmitry
> > 
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 
> 

From mposolda at redhat.com  Thu Apr  4 03:14:59 2019
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 4 Apr 2019 09:14:59 +0200
Subject: [keycloak-dev] Proposal: Improvements to IdpUsernamePasswordForm
In-Reply-To: <1554331537.4647.3.camel@carretti.pro>
References: <1553789204.3600.7.camel@carretti.pro>
	<664811e2-cad4-9b62-c168-39de1981afc3@redhat.com>
	<1554331537.4647.3.camel@carretti.pro>
Message-ID: <d0e98de7-7825-68b2-3da6-f4cee56155ad@redhat.com>

Hi Dmitry,

On 04/04/2019 00:45, Dmitry Telegin wrote:
> Hi Marek,
>
> You absolutely right, UsernamePasswordForm does the trick. However, the login screen rendered by?UsernamePasswordForm is different from that of IdpUsernamePasswordForm in the following aspects:
> - IdpUsernamePasswordForm doesn't display the block with IdP/social buttons

You're right. Small addition: The IdpUsernamePasswordForm displays 
social buttons, but just of those identity providers, which are already 
linked to specified user. In other words, if you want to link your 
account to broker-A and your account is already linked to broker-B, then 
broker-B is displayed on the form. This way, you have possibility to 
re-authenticate not just with your password, but alternatively by login 
to already linked broker-B, which is already linked to your account and 
hence "trusted" to be used for prove your identity.

It seems that with your proposal in case that username is unknown, we 
won't display any brokers on the screen and hence it will be mandatory 
to do re-authentication by username+password?

> - IdpUsernamePasswordForm renders the message relevant to IdP-linking-by-reauthentication, which is this:
>
> federatedIdentityConfirmReauthenticateMessage=Authenticate as {0} to link your account with {1}
>
> So, my requirement is to implement the appearance of IdpUsernamePasswordForm + behavior of UsernamePasswordForm. I think this could be done either by augmenting the former, or by merging the two authenticators into a unified one, that would exhibit different behavior depending on the context (normal login vs. reauthentication for IdP linking).

I suggest to update IdpUsernamePasswordForm authenticator. In case that 
EXISTING_USER_INFO is not there, we can do the behaviour like:

- User will need to provide both username+password. Hence username field 
will need to be enabled
- Social buttons won't be displayed on the login screen
- Message will be bit different. For example just: Authenticate to link 
your account with {1}

For the case when EXISTING_USER_INFO is available, I would like to keep 
the same behaviour as currently is.

WDYT?

Marek

>
> Please let me know which way seems better for you, with the idea in mind of having this contributed to upstream.
>
> Thanks!
> Dmitry
>
> On Tue, 2019-04-02 at 15:21 +0200, Marek Posolda wrote:
>> On 28/03/2019 17:06, Dmitry Telegin wrote:
>>> Hi,
>>>
>>> I'm currently working to implement the following requirements:
>>> - users are managed externally via LDAP, self-registrations disabled;
>>> - there is an external IdP;
>>> - generally, there is no way to automatically match IdP identity with Keycloak's one, so IdP linking will always be performed by the user manually;
>>> - in order to do that, the user should click the IdP icon in the login screen, authenticate with the IdP, get back to Keycloak and "claim" his/her Keycloak account by entering correct username and password.
>>>
>>> Currently, the closest thing in Keycloak is o.k.authentication.authenticators.broker.IdpUsernamePasswordForm (aka "idp-username-password-form", aka "Username Password Form for identity provider reauthentication").
>>> However, it 1) prefills username field and makes it non-editable, 2) depends on the preceding IdpCreateUserIfUniqueAuthenticator execution to provide existing user model (EXISTING_USER_INFO auth note).
>>>
>>> My proposal is to improve IdpUsernamePasswordForm by allowing its execution even without the preceding IdpCreateUserIfUniqueAuthenticator. In the absence of EXISTING_USER_INFO, IdpUsernamePasswordForm should allow the user to manually enter username.
>> I wonder if you can't already achieve something like this with the OOTB
>> authenticator implementations, but just correctly configure them? For
>> example in the "First Broker Login" flow used for your identity
>> provider, you can just directly use the default browser-based
>> authenticator ( UsernamePasswordForm ) instead of the
>> IdpUsernamePasswordForm. That way, the username+password form will be
>> always shown for "First Broker Login" and once user authenticates, his
>> account will be linked with IdP account.
>>
>> Marek
>>
>>> Please let me know if you think it's worth having this in Keycloak. Regards,
>>> Dmitry
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>


From micha.preusser at netknights.it  Thu Apr  4 05:02:19 2019
From: micha.preusser at netknights.it (Micha =?ISO-8859-1?Q?Preu=DFer?=)
Date: Thu, 04 Apr 2019 11:02:19 +0200
Subject: [keycloak-dev] Keycloak demo
Message-ID: <21cdb5d73422e5ad27905533fe1f69cf15e8b462.camel@netknights.it>

Hey there,

this is not really a development question (not yet), but I think
somebody can help me out here.

In the latest (5.0.0) documentation for server development, you
have the topic 8.3. Authenticator SPI Walk Through. There you can find
an example for third auth plugins, but the latest "demo distribution",
which contains this example, could I found for the version 4.3.0.

Is there any newer version, I didn't found or how can I go on to take a
look at this example and deploy it?

Thanks a lot.
Micha Preu?er


From mposolda at redhat.com  Thu Apr  4 15:35:58 2019
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 4 Apr 2019 21:35:58 +0200
Subject: [keycloak-dev] Keycloak demo
In-Reply-To: <21cdb5d73422e5ad27905533fe1f69cf15e8b462.camel@netknights.it>
References: <21cdb5d73422e5ad27905533fe1f69cf15e8b462.camel@netknights.it>
Message-ID: <2a348061-4edb-96ad-98be-21d96cb5b79c@redhat.com>

Hi,

You can take a look at our quickstarts. For example 
https://github.com/keycloak/keycloak-quickstarts/tree/latest/action-token-authenticator

Marek

On 04/04/2019 11:02, Micha Preu?er wrote:
> Hey there,
>
> this is not really a development question (not yet), but I think
> somebody can help me out here.
>
> In the latest (5.0.0) documentation for server development, you
> have the topic 8.3. Authenticator SPI Walk Through. There you can find
> an example for third auth plugins, but the latest "demo distribution",
> which contains this example, could I found for the version 4.3.0.
>
> Is there any newer version, I didn't found or how can I go on to take a
> look at this example and deploy it?
>
> Thanks a lot.
> Micha Preu?er
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



From demetrio at carretti.pro  Thu Apr  4 17:59:55 2019
From: demetrio at carretti.pro (Dmitry Telegin)
Date: Fri, 05 Apr 2019 00:59:55 +0300
Subject: [keycloak-dev] Proposal: Improvements to IdpUsernamePasswordForm
In-Reply-To: <d0e98de7-7825-68b2-3da6-f4cee56155ad@redhat.com>
References: <1553789204.3600.7.camel@carretti.pro>
	<664811e2-cad4-9b62-c168-39de1981afc3@redhat.com>
	<1554331537.4647.3.camel@carretti.pro>
	<d0e98de7-7825-68b2-3da6-f4cee56155ad@redhat.com>
Message-ID: <1554415195.6328.1.camel@carretti.pro>

Hi Marek,

On Thu, 2019-04-04 at 09:14 +0200, Marek Posolda wrote:
> Hi Dmitry,
> 
> On 04/04/2019 00:45, Dmitry Telegin wrote:
> > Hi Marek,
> > 
> > You absolutely right, UsernamePasswordForm does the trick. However, the login screen rendered by?UsernamePasswordForm is different from that of IdpUsernamePasswordForm in the following aspects:
> > - IdpUsernamePasswordForm doesn't display the block with IdP/social buttons
> 
> You're right. Small addition: The IdpUsernamePasswordForm displays?
> social buttons, but just of those identity providers, which are already?
> linked to specified user. In other words, if you want to link your?
> account to broker-A and your account is already linked to broker-B, then?
> broker-B is displayed on the form. This way, you have possibility to?
> re-authenticate not just with your password, but alternatively by login?
> to already linked broker-B, which is already linked to your account and?
> hence "trusted" to be used for prove your identity.
> 
> It seems that with your proposal in case that username is unknown, we?
> won't display any brokers on the screen and hence it will be mandatory?
> to do re-authentication by username+password?

Yes, that's correct. 

> 
> > - IdpUsernamePasswordForm renders the message relevant to IdP-linking-by-reauthentication, which is this:
> > 
> > federatedIdentityConfirmReauthenticateMessage=Authenticate as {0} to link your account with {1}
> > 
> > So, my requirement is to implement the appearance of IdpUsernamePasswordForm + behavior of UsernamePasswordForm. I think this could be done either by augmenting the former, or by merging the two authenticators into a unified one, that would exhibit different behavior depending on the context (normal login vs. reauthentication for IdP linking).
> 
> I suggest to update IdpUsernamePasswordForm authenticator. In case that?
> EXISTING_USER_INFO is not there, we can do the behaviour like:
> 
> - User will need to provide both username+password. Hence username field?
> will need to be enabled
> - Social buttons won't be displayed on the login screen
> - Message will be bit different. For example just: Authenticate to link?
> your account with {1}
> 
> For the case when EXISTING_USER_INFO is available, I would like to keep?
> the same behaviour as currently is.
> 
> WDYT?

This is exactly how I was planning to do it myself :) so if you greenlight this, I'll proceed with JIRA/PR.

Just FYI, I'm also planning to publish a "standalone" version of the authenticator to be used with Keycloak <= 5.0.0.

Dmitry

> 
> Marek
> 
> > 
> > Please let me know which way seems better for you, with the idea in mind of having this contributed to upstream.
> > 
> > Thanks!
> > Dmitry
> > 
> > On Tue, 2019-04-02 at 15:21 +0200, Marek Posolda wrote:
> > > On 28/03/2019 17:06, Dmitry Telegin wrote:
> > > > Hi,
> > > > 
> > > > I'm currently working to implement the following requirements:
> > > > - users are managed externally via LDAP, self-registrations disabled;
> > > > - there is an external IdP;
> > > > - generally, there is no way to automatically match IdP identity with Keycloak's one, so IdP linking will always be performed by the user manually;
> > > > - in order to do that, the user should click the IdP icon in the login screen, authenticate with the IdP, get back to Keycloak and "claim" his/her Keycloak account by entering correct username and password.
> > > > 
> > > > Currently, the closest thing in Keycloak is o.k.authentication.authenticators.broker.IdpUsernamePasswordForm (aka "idp-username-password-form", aka "Username Password Form for identity provider reauthentication").
> > > > However, it 1) prefills username field and makes it non-editable, 2) depends on the preceding IdpCreateUserIfUniqueAuthenticator execution to provide existing user model (EXISTING_USER_INFO auth note).
> > > > 
> > > > My proposal is to improve IdpUsernamePasswordForm by allowing its execution even without the preceding IdpCreateUserIfUniqueAuthenticator. In the absence of EXISTING_USER_INFO, IdpUsernamePasswordForm should allow the user to manually enter username.
> > > 
> > > I wonder if you can't already achieve something like this with the OOTB
> > > authenticator implementations, but just correctly configure them? For
> > > example in the "First Broker Login" flow used for your identity
> > > provider, you can just directly use the default browser-based
> > > authenticator ( UsernamePasswordForm ) instead of the
> > > IdpUsernamePasswordForm. That way, the username+password form will be
> > > always shown for "First Broker Login" and once user authenticates, his
> > > account will be linked with IdP account.
> > > 
> > > Marek
> > > 
> > > > Please let me know if you think it's worth having this in Keycloak. Regards,
> > > > Dmitry
> > > > 
> > > > _______________________________________________
> > > > keycloak-dev mailing list
> > > > keycloak-dev at lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 
> 

From mposolda at redhat.com  Fri Apr  5 02:07:14 2019
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 5 Apr 2019 08:07:14 +0200
Subject: [keycloak-dev] Proposal: Improvements to IdpUsernamePasswordForm
In-Reply-To: <1554415195.6328.1.camel@carretti.pro>
References: <1553789204.3600.7.camel@carretti.pro>
	<664811e2-cad4-9b62-c168-39de1981afc3@redhat.com>
	<1554331537.4647.3.camel@carretti.pro>
	<d0e98de7-7825-68b2-3da6-f4cee56155ad@redhat.com>
	<1554415195.6328.1.camel@carretti.pro>
Message-ID: <2567518c-b341-27c9-b30d-8dd5fd5757a1@redhat.com>

On 04/04/2019 23:59, Dmitry Telegin wrote:
> Hi Marek,
>
> On Thu, 2019-04-04 at 09:14 +0200, Marek Posolda wrote:
>> Hi Dmitry,
>>
>> On 04/04/2019 00:45, Dmitry Telegin wrote:
>>> Hi Marek,
>>>
>>> You absolutely right, UsernamePasswordForm does the trick. However, the login screen rendered by?UsernamePasswordForm is different from that of IdpUsernamePasswordForm in the following aspects:
>>> - IdpUsernamePasswordForm doesn't display the block with IdP/social buttons
>> You're right. Small addition: The IdpUsernamePasswordForm displays
>> social buttons, but just of those identity providers, which are already
>> linked to specified user. In other words, if you want to link your
>> account to broker-A and your account is already linked to broker-B, then
>> broker-B is displayed on the form. This way, you have possibility to
>> re-authenticate not just with your password, but alternatively by login
>> to already linked broker-B, which is already linked to your account and
>> hence "trusted" to be used for prove your identity.
>>
>> It seems that with your proposal in case that username is unknown, we
>> won't display any brokers on the screen and hence it will be mandatory
>> to do re-authentication by username+password?
> Yes, that's correct.
>
>>> - IdpUsernamePasswordForm renders the message relevant to IdP-linking-by-reauthentication, which is this:
>>>
>>> federatedIdentityConfirmReauthenticateMessage=Authenticate as {0} to link your account with {1}
>>>
>>> So, my requirement is to implement the appearance of IdpUsernamePasswordForm + behavior of UsernamePasswordForm. I think this could be done either by augmenting the former, or by merging the two authenticators into a unified one, that would exhibit different behavior depending on the context (normal login vs. reauthentication for IdP linking).
>> I suggest to update IdpUsernamePasswordForm authenticator. In case that
>> EXISTING_USER_INFO is not there, we can do the behaviour like:
>>
>> - User will need to provide both username+password. Hence username field
>> will need to be enabled
>> - Social buttons won't be displayed on the login screen
>> - Message will be bit different. For example just: Authenticate to link
>> your account with {1}
>>
>> For the case when EXISTING_USER_INFO is available, I would like to keep
>> the same behaviour as currently is.
>>
>> WDYT?
> This is exactly how I was planning to do it myself :) so if you greenlight this, I'll proceed with JIRA/PR.

+1

Marek

>
> Just FYI, I'm also planning to publish a "standalone" version of the authenticator to be used with Keycloak <= 5.0.0.
>
> Dmitry
>
>> Marek
>>
>>> Please let me know which way seems better for you, with the idea in mind of having this contributed to upstream.
>>>
>>> Thanks!
>>> Dmitry
>>>
>>> On Tue, 2019-04-02 at 15:21 +0200, Marek Posolda wrote:
>>>> On 28/03/2019 17:06, Dmitry Telegin wrote:
>>>>> Hi,
>>>>>
>>>>> I'm currently working to implement the following requirements:
>>>>> - users are managed externally via LDAP, self-registrations disabled;
>>>>> - there is an external IdP;
>>>>> - generally, there is no way to automatically match IdP identity with Keycloak's one, so IdP linking will always be performed by the user manually;
>>>>> - in order to do that, the user should click the IdP icon in the login screen, authenticate with the IdP, get back to Keycloak and "claim" his/her Keycloak account by entering correct username and password.
>>>>>
>>>>> Currently, the closest thing in Keycloak is o.k.authentication.authenticators.broker.IdpUsernamePasswordForm (aka "idp-username-password-form", aka "Username Password Form for identity provider reauthentication").
>>>>> However, it 1) prefills username field and makes it non-editable, 2) depends on the preceding IdpCreateUserIfUniqueAuthenticator execution to provide existing user model (EXISTING_USER_INFO auth note).
>>>>>
>>>>> My proposal is to improve IdpUsernamePasswordForm by allowing its execution even without the preceding IdpCreateUserIfUniqueAuthenticator. In the absence of EXISTING_USER_INFO, IdpUsernamePasswordForm should allow the user to manually enter username.
>>>> I wonder if you can't already achieve something like this with the OOTB
>>>> authenticator implementations, but just correctly configure them? For
>>>> example in the "First Broker Login" flow used for your identity
>>>> provider, you can just directly use the default browser-based
>>>> authenticator ( UsernamePasswordForm ) instead of the
>>>> IdpUsernamePasswordForm. That way, the username+password form will be
>>>> always shown for "First Broker Login" and once user authenticates, his
>>>> account will be linked with IdP account.
>>>>
>>>> Marek
>>>>
>>>>> Please let me know if you think it's worth having this in Keycloak. Regards,
>>>>> Dmitry
>>>>>
>>>>> _______________________________________________
>>>>> keycloak-dev mailing list
>>>>> keycloak-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>


From shiva.prasad.thagadur.prakash at ericsson.com  Fri Apr  5 04:21:10 2019
From: shiva.prasad.thagadur.prakash at ericsson.com (Shiva Prasad Thagadur Prakash)
Date: Fri, 5 Apr 2019 08:21:10 +0000
Subject: [keycloak-dev] Few Admin events not getting raised
Message-ID: <1554452469.17045.16.camel@ericsson.com>

Hi Guys,

We see that few admin events are not getting logged to syslog/logfile.
Creating scope, Creating New policy for a client and Creating new
permission for a client. COuld anyone please help us?

Steps to reproduce:
New permisson event
? ? 1. Create new client f.i. in master realm
? ? 2. Set "Authorization Enabled"
? ? 3. Go to clients->clientName->Authorization ->Permissions - Scope
based
? ? 4. Create New permission

Failed Symptoms: No any events generated.

? ? 1. Create new client f.i. in master realm
? ? 2. Set "Authorization Enabled"
????Go to clients->clientName->Authorization ->Policies - Create
POlicy??-> Role
? ? 3. Create New policy

Failed Symptoms: No any events generated.


? ? 1. Create new client f.i. in master realm
? ? 2. Set "Authorization Enabled"
? ? 3. Go to clients->clientName->Authorization ->Authorization Scopes
? ? 4. Create New scope event_scope
Failed Symptoms:?No any events generated.

Thanks & regards,
Shiva


From shiva.prasad.thagadur.prakash at ericsson.com  Fri Apr  5 04:22:39 2019
From: shiva.prasad.thagadur.prakash at ericsson.com (Shiva Prasad Thagadur Prakash)
Date: Fri, 5 Apr 2019 08:22:39 +0000
Subject: [keycloak-dev] Few Admin events not getting raised
Message-ID: <1554452559.17045.17.camel@ericsson.com>

Hi Guys,

We see that few admin events are not getting logged to syslog/logfile.
Creating scope, Creating New policy for a client and Creating new
permission for a client. COuld anyone please help us?

Steps to reproduce:
New permisson event
? ? 1. Create new client f.i. in master realm
? ? 2. Set "Authorization Enabled"
? ? 3. Go to clients->clientName->Authorization ->Permissions - Scope
based
? ? 4. Create New permission

Failed Symptoms: No any events generated.

? ? 1. Create new client f.i. in master realm
? ? 2. Set "Authorization Enabled"
????Go to clients->clientName->Authorization ->Policies - Create
POlicy??-> Role
? ? 3. Create New policy

Failed Symptoms: No any events generated.


? ? 1. Create new client f.i. in master realm
? ? 2. Set "Authorization Enabled"
? ? 3. Go to clients->clientName->Authorization ->Authorization Scopes
? ? 4. Create New scope event_scope
Failed Symptoms:?No any events generated.

Thanks & regards,
Shiva


From vmuzikar at redhat.com  Fri Apr  5 06:19:19 2019
From: vmuzikar at redhat.com (=?UTF-8?B?VsOhY2xhdiBNdXppa8OhxZk=?=)
Date: Fri, 5 Apr 2019 12:19:19 +0200
Subject: [keycloak-dev] Proposal: Approvals System
Message-ID: <CAMQSZygL8LGB80Won27vrGUh8s7MT0JjJWR-dfbjXifsR3mQ=w@mail.gmail.com>

Hello,

I've been working on an Approvals System for Keycloak and I'd like to
discuss the design proposal.

In short, it's a system that is responsible for audit, interception and
approving/rejection of configuration changes in Keycloak. Even though it's
designed as general as possible (i.e. able to intercept just about any
config change), the initial scope will be probably focused on users
operations.

It's currently in a PoC state with a formalized design proposal available:
https://github.com/keycloak/keycloak-community/blob/master/design/approvals-system.md

Please let me know your thoughts.

Thank you.

Regards,
V?clav Muzik??

-- 
V?clav Muzik??
Senior Quality Engineer
Keycloak / Red Hat Single Sign-On
Red Hat Czech s.r.o.

From mposolda at redhat.com  Fri Apr  5 09:55:49 2019
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 5 Apr 2019 15:55:49 +0200
Subject: [keycloak-dev] Few Admin events not getting raised
In-Reply-To: <1554452559.17045.17.camel@ericsson.com>
References: <1554452559.17045.17.camel@ericsson.com>
Message-ID: <7745f1a9-cd9c-489d-169b-cfabe5697db4@redhat.com>

Looks like a bug. Feel free to create JIRA. If you're able to send PR 
with the fix, it will be even better and will cause that bug will be 
fixed faster :)

Thanks,
Marek

On 05/04/2019 10:22, Shiva Prasad Thagadur Prakash wrote:
> Hi Guys,
>
> We see that few admin events are not getting logged to syslog/logfile.
> Creating scope, Creating New policy for a client and Creating new
> permission for a client. COuld anyone please help us?
>
> Steps to reproduce:
> New permisson event
>  ? ? 1. Create new client f.i. in master realm
>  ? ? 2. Set "Authorization Enabled"
>  ? ? 3. Go to clients->clientName->Authorization ->Permissions - Scope
> based
>  ? ? 4. Create New permission
>
> Failed Symptoms: No any events generated.
>
>  ? ? 1. Create new client f.i. in master realm
>  ? ? 2. Set "Authorization Enabled"
>  ????Go to clients->clientName->Authorization ->Policies - Create
> POlicy??-> Role
>  ? ? 3. Create New policy
>
> Failed Symptoms: No any events generated.
>
>
>  ? ? 1. Create new client f.i. in master realm
>  ? ? 2. Set "Authorization Enabled"
>  ? ? 3. Go to clients->clientName->Authorization ->Authorization Scopes
>  ? ? 4. Create New scope event_scope
> Failed Symptoms:?No any events generated.
>
> Thanks & regards,
> Shiva
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



From bruno at abstractj.org  Fri Apr  5 10:12:52 2019
From: bruno at abstractj.org (Bruno Oliveira)
Date: Fri, 5 Apr 2019 11:12:52 -0300
Subject: [keycloak-dev] Few Admin events not getting raised
In-Reply-To: <1554452559.17045.17.camel@ericsson.com>
References: <1554452559.17045.17.camel@ericsson.com>
Message-ID: <20190405141252.GA4276@abstractj.org>

For questions, please, ask on keycloak-users mailing list. This mailing list is used
exclusively for design and implementation discussions. 

On 2019-04-05, Shiva Prasad Thagadur Prakash wrote:
> Hi Guys,
> 
> We see that few admin events are not getting logged to syslog/logfile.
> Creating scope, Creating New policy for a client and Creating new
> permission for a client. COuld anyone please help us?
> 
> Steps to reproduce:
> New permisson event
> ? ? 1. Create new client f.i. in master realm
> ? ? 2. Set "Authorization Enabled"
> ? ? 3. Go to clients->clientName->Authorization ->Permissions - Scope
> based
> ? ? 4. Create New permission
> 
> Failed Symptoms: No any events generated.
> 
> ? ? 1. Create new client f.i. in master realm
> ? ? 2. Set "Authorization Enabled"
> ????Go to clients->clientName->Authorization ->Policies - Create
> POlicy??-> Role
> ? ? 3. Create New policy
> 
> Failed Symptoms: No any events generated.
> 
> 
> ? ? 1. Create new client f.i. in master realm
> ? ? 2. Set "Authorization Enabled"
> ? ? 3. Go to clients->clientName->Authorization ->Authorization Scopes
> ? ? 4. Create New scope event_scope
> Failed Symptoms:?No any events generated.
> 
> Thanks & regards,
> Shiva
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

-- 

abstractj

From yormen1 at gmail.com  Fri Apr  5 16:49:56 2019
From: yormen1 at gmail.com (yormen1 at gmail.com)
Date: Fri, 5 Apr 2019 20:49:56 +0000
Subject: [keycloak-dev] Session management UI improvement
In-Reply-To: <mailman.3581.1554472677.4590.keycloak-dev@lists.jboss.org>
References: <mailman.3581.1554472677.4590.keycloak-dev@lists.jboss.org>
Message-ID: <BDDFF2FA-8051-49C2-B7D2-67FC1239F2AE@gmail.com>

I don't know if something could be done about multiple selection when you want to logout a group of session out from keycloak at the same time.



> On Apr 5, 2019, at 1:57 PM, keycloak-dev-request at lists.jboss.org wrote:
> 
> Send keycloak-dev mailing list submissions to
>    keycloak-dev at lists.jboss.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>    https://lists.jboss.org/mailman/listinfo/keycloak-dev
> or, via email, send a message with subject or body 'help' to
>    keycloak-dev-request at lists.jboss.org
> 
> You can reach the person managing the list at
>    keycloak-dev-owner at lists.jboss.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of keycloak-dev digest..."
> 
> 
> Today's Topics:
> 
>   1. Re: Proposal: Improvements to IdpUsernamePasswordForm
>      (Dmitry Telegin)
>   2. Re: Proposal: Improvements to IdpUsernamePasswordForm
>      (Marek Posolda)
>   3. Few Admin events not getting raised
>      (Shiva Prasad Thagadur Prakash)
>   4. Few Admin events not getting raised
>      (Shiva Prasad Thagadur Prakash)
>   5. Proposal: Approvals System (V?clav Muzik??)
>   6. Re: Few Admin events not getting raised (Marek Posolda)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Fri, 05 Apr 2019 00:59:55 +0300
> From: Dmitry Telegin <demetrio at carretti.pro>
> Subject: Re: [keycloak-dev] Proposal: Improvements to
>    IdpUsernamePasswordForm
> To: Marek Posolda <mposolda at redhat.com>, keycloak-dev
>    <keycloak-dev at lists.jboss.org>
> Message-ID: <1554415195.6328.1.camel at carretti.pro>
> Content-Type: text/plain; charset="UTF-8"
> 
> Hi Marek,
> 
>> On Thu, 2019-04-04 at 09:14 +0200, Marek Posolda wrote:
>> Hi Dmitry,
>> 
>>> On 04/04/2019 00:45, Dmitry Telegin wrote:
>>> Hi Marek,
>>> 
>>> You absolutely right, UsernamePasswordForm does the trick. However, the login screen rendered by?UsernamePasswordForm is different from that of IdpUsernamePasswordForm in the following aspects:
>>> - IdpUsernamePasswordForm doesn't display the block with IdP/social buttons
>> 
>> You're right. Small addition: The IdpUsernamePasswordForm displays?
>> social buttons, but just of those identity providers, which are already?
>> linked to specified user. In other words, if you want to link your?
>> account to broker-A and your account is already linked to broker-B, then?
>> broker-B is displayed on the form. This way, you have possibility to?
>> re-authenticate not just with your password, but alternatively by login?
>> to already linked broker-B, which is already linked to your account and?
>> hence "trusted" to be used for prove your identity.
>> 
>> It seems that with your proposal in case that username is unknown, we?
>> won't display any brokers on the screen and hence it will be mandatory?
>> to do re-authentication by username+password?
> 
> Yes, that's correct. 
> 
>> 
>>> - IdpUsernamePasswordForm renders the message relevant to IdP-linking-by-reauthentication, which is this:
>>> 
>>> federatedIdentityConfirmReauthenticateMessage=Authenticate as {0} to link your account with {1}
>>> 
>>> So, my requirement is to implement the appearance of IdpUsernamePasswordForm + behavior of UsernamePasswordForm. I think this could be done either by augmenting the former, or by merging the two authenticators into a unified one, that would exhibit different behavior depending on the context (normal login vs. reauthentication for IdP linking).
>> 
>> I suggest to update IdpUsernamePasswordForm authenticator. In case that?
>> EXISTING_USER_INFO is not there, we can do the behaviour like:
>> 
>> - User will need to provide both username+password. Hence username field?
>> will need to be enabled
>> - Social buttons won't be displayed on the login screen
>> - Message will be bit different. For example just: Authenticate to link?
>> your account with {1}
>> 
>> For the case when EXISTING_USER_INFO is available, I would like to keep?
>> the same behaviour as currently is.
>> 
>> WDYT?
> 
> This is exactly how I was planning to do it myself :) so if you greenlight this, I'll proceed with JIRA/PR.
> 
> Just FYI, I'm also planning to publish a "standalone" version of the authenticator to be used with Keycloak <= 5.0.0.
> 
> Dmitry
> 
>> 
>> Marek
>> 
>>> 
>>> Please let me know which way seems better for you, with the idea in mind of having this contributed to upstream.
>>> 
>>> Thanks!
>>> Dmitry
>>> 
>>>> On Tue, 2019-04-02 at 15:21 +0200, Marek Posolda wrote:
>>>>> On 28/03/2019 17:06, Dmitry Telegin wrote:
>>>>> Hi,
>>>>> 
>>>>> I'm currently working to implement the following requirements:
>>>>> - users are managed externally via LDAP, self-registrations disabled;
>>>>> - there is an external IdP;
>>>>> - generally, there is no way to automatically match IdP identity with Keycloak's one, so IdP linking will always be performed by the user manually;
>>>>> - in order to do that, the user should click the IdP icon in the login screen, authenticate with the IdP, get back to Keycloak and "claim" his/her Keycloak account by entering correct username and password.
>>>>> 
>>>>> Currently, the closest thing in Keycloak is o.k.authentication.authenticators.broker.IdpUsernamePasswordForm (aka "idp-username-password-form", aka "Username Password Form for identity provider reauthentication").
>>>>> However, it 1) prefills username field and makes it non-editable, 2) depends on the preceding IdpCreateUserIfUniqueAuthenticator execution to provide existing user model (EXISTING_USER_INFO auth note).
>>>>> 
>>>>> My proposal is to improve IdpUsernamePasswordForm by allowing its execution even without the preceding IdpCreateUserIfUniqueAuthenticator. In the absence of EXISTING_USER_INFO, IdpUsernamePasswordForm should allow the user to manually enter username.
>>>> 
>>>> I wonder if you can't already achieve something like this with the OOTB
>>>> authenticator implementations, but just correctly configure them? For
>>>> example in the "First Broker Login" flow used for your identity
>>>> provider, you can just directly use the default browser-based
>>>> authenticator ( UsernamePasswordForm ) instead of the
>>>> IdpUsernamePasswordForm. That way, the username+password form will be
>>>> always shown for "First Broker Login" and once user authenticates, his
>>>> account will be linked with IdP account.
>>>> 
>>>> Marek
>>>> 
>>>>> Please let me know if you think it's worth having this in Keycloak. Regards,
>>>>> Dmitry
>>>>> 
>>>>> _______________________________________________
>>>>> keycloak-dev mailing list
>>>>> keycloak-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 
> 
> ------------------------------
> 
> Message: 2
> Date: Fri, 5 Apr 2019 08:07:14 +0200
> From: Marek Posolda <mposolda at redhat.com>
> Subject: Re: [keycloak-dev] Proposal: Improvements to
>    IdpUsernamePasswordForm
> To: Dmitry Telegin <demetrio at carretti.pro>,    keycloak-dev
>    <keycloak-dev at lists.jboss.org>
> Message-ID: <2567518c-b341-27c9-b30d-8dd5fd5757a1 at redhat.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
> 
>> On 04/04/2019 23:59, Dmitry Telegin wrote:
>> Hi Marek,
>> 
>>> On Thu, 2019-04-04 at 09:14 +0200, Marek Posolda wrote:
>>> Hi Dmitry,
>>> 
>>>> On 04/04/2019 00:45, Dmitry Telegin wrote:
>>>> Hi Marek,
>>>> 
>>>> You absolutely right, UsernamePasswordForm does the trick. However, the login screen rendered by?UsernamePasswordForm is different from that of IdpUsernamePasswordForm in the following aspects:
>>>> - IdpUsernamePasswordForm doesn't display the block with IdP/social buttons
>>> You're right. Small addition: The IdpUsernamePasswordForm displays
>>> social buttons, but just of those identity providers, which are already
>>> linked to specified user. In other words, if you want to link your
>>> account to broker-A and your account is already linked to broker-B, then
>>> broker-B is displayed on the form. This way, you have possibility to
>>> re-authenticate not just with your password, but alternatively by login
>>> to already linked broker-B, which is already linked to your account and
>>> hence "trusted" to be used for prove your identity.
>>> 
>>> It seems that with your proposal in case that username is unknown, we
>>> won't display any brokers on the screen and hence it will be mandatory
>>> to do re-authentication by username+password?
>> Yes, that's correct.
>> 
>>>> - IdpUsernamePasswordForm renders the message relevant to IdP-linking-by-reauthentication, which is this:
>>>> 
>>>> federatedIdentityConfirmReauthenticateMessage=Authenticate as {0} to link your account with {1}
>>>> 
>>>> So, my requirement is to implement the appearance of IdpUsernamePasswordForm + behavior of UsernamePasswordForm. I think this could be done either by augmenting the former, or by merging the two authenticators into a unified one, that would exhibit different behavior depending on the context (normal login vs. reauthentication for IdP linking).
>>> I suggest to update IdpUsernamePasswordForm authenticator. In case that
>>> EXISTING_USER_INFO is not there, we can do the behaviour like:
>>> 
>>> - User will need to provide both username+password. Hence username field
>>> will need to be enabled
>>> - Social buttons won't be displayed on the login screen
>>> - Message will be bit different. For example just: Authenticate to link
>>> your account with {1}
>>> 
>>> For the case when EXISTING_USER_INFO is available, I would like to keep
>>> the same behaviour as currently is.
>>> 
>>> WDYT?
>> This is exactly how I was planning to do it myself :) so if you greenlight this, I'll proceed with JIRA/PR.
> 
> +1
> 
> Marek
> 
>> 
>> Just FYI, I'm also planning to publish a "standalone" version of the authenticator to be used with Keycloak <= 5.0.0.
>> 
>> Dmitry
>> 
>>> Marek
>>> 
>>>> Please let me know which way seems better for you, with the idea in mind of having this contributed to upstream.
>>>> 
>>>> Thanks!
>>>> Dmitry
>>>> 
>>>>> On Tue, 2019-04-02 at 15:21 +0200, Marek Posolda wrote:
>>>>>> On 28/03/2019 17:06, Dmitry Telegin wrote:
>>>>>> Hi,
>>>>>> 
>>>>>> I'm currently working to implement the following requirements:
>>>>>> - users are managed externally via LDAP, self-registrations disabled;
>>>>>> - there is an external IdP;
>>>>>> - generally, there is no way to automatically match IdP identity with Keycloak's one, so IdP linking will always be performed by the user manually;
>>>>>> - in order to do that, the user should click the IdP icon in the login screen, authenticate with the IdP, get back to Keycloak and "claim" his/her Keycloak account by entering correct username and password.
>>>>>> 
>>>>>> Currently, the closest thing in Keycloak is o.k.authentication.authenticators.broker.IdpUsernamePasswordForm (aka "idp-username-password-form", aka "Username Password Form for identity provider reauthentication").
>>>>>> However, it 1) prefills username field and makes it non-editable, 2) depends on the preceding IdpCreateUserIfUniqueAuthenticator execution to provide existing user model (EXISTING_USER_INFO auth note).
>>>>>> 
>>>>>> My proposal is to improve IdpUsernamePasswordForm by allowing its execution even without the preceding IdpCreateUserIfUniqueAuthenticator. In the absence of EXISTING_USER_INFO, IdpUsernamePasswordForm should allow the user to manually enter username.
>>>>> I wonder if you can't already achieve something like this with the OOTB
>>>>> authenticator implementations, but just correctly configure them? For
>>>>> example in the "First Broker Login" flow used for your identity
>>>>> provider, you can just directly use the default browser-based
>>>>> authenticator ( UsernamePasswordForm ) instead of the
>>>>> IdpUsernamePasswordForm. That way, the username+password form will be
>>>>> always shown for "First Broker Login" and once user authenticates, his
>>>>> account will be linked with IdP account.
>>>>> 
>>>>> Marek
>>>>> 
>>>>>> Please let me know if you think it's worth having this in Keycloak. Regards,
>>>>>> Dmitry
>>>>>> 
>>>>>> _______________________________________________
>>>>>> keycloak-dev mailing list
>>>>>> keycloak-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 
> 
> 
> ------------------------------
> 
> Message: 3
> Date: Fri, 5 Apr 2019 08:21:10 +0000
> From: Shiva Prasad Thagadur Prakash
>    <shiva.prasad.thagadur.prakash at ericsson.com>
> Subject: [keycloak-dev] Few Admin events not getting raised
> To: "keycloak-dev at lists.jboss.org" <keycloak-dev at lists.jboss.org>
> Message-ID: <1554452469.17045.16.camel at ericsson.com>
> Content-Type: text/plain; charset="utf-8"
> 
> Hi Guys,
> 
> We see that few admin events are not getting logged to syslog/logfile.
> Creating scope, Creating New policy for a client and Creating new
> permission for a client. COuld anyone please help us?
> 
> Steps to reproduce:
> New permisson event
> ? ? 1. Create new client f.i. in master realm
> ? ? 2. Set "Authorization Enabled"
> ? ? 3. Go to clients->clientName->Authorization ->Permissions - Scope
> based
> ? ? 4. Create New permission
> 
> Failed Symptoms: No any events generated.
> 
> ? ? 1. Create new client f.i. in master realm
> ? ? 2. Set "Authorization Enabled"
> ????Go to clients->clientName->Authorization ->Policies - Create
> POlicy??-> Role
> ? ? 3. Create New policy
> 
> Failed Symptoms: No any events generated.
> 
> 
> ? ? 1. Create new client f.i. in master realm
> ? ? 2. Set "Authorization Enabled"
> ? ? 3. Go to clients->clientName->Authorization ->Authorization Scopes
> ? ? 4. Create New scope event_scope
> Failed Symptoms:?No any events generated.
> 
> Thanks & regards,
> Shiva
> 
> 
> 
> ------------------------------
> 
> Message: 4
> Date: Fri, 5 Apr 2019 08:22:39 +0000
> From: Shiva Prasad Thagadur Prakash
>    <shiva.prasad.thagadur.prakash at ericsson.com>
> Subject: [keycloak-dev] Few Admin events not getting raised
> To: "keycloak-dev at lists.jboss.org" <keycloak-dev at lists.jboss.org>
> Message-ID: <1554452559.17045.17.camel at ericsson.com>
> Content-Type: text/plain; charset="utf-8"
> 
> Hi Guys,
> 
> We see that few admin events are not getting logged to syslog/logfile.
> Creating scope, Creating New policy for a client and Creating new
> permission for a client. COuld anyone please help us?
> 
> Steps to reproduce:
> New permisson event
> ? ? 1. Create new client f.i. in master realm
> ? ? 2. Set "Authorization Enabled"
> ? ? 3. Go to clients->clientName->Authorization ->Permissions - Scope
> based
> ? ? 4. Create New permission
> 
> Failed Symptoms: No any events generated.
> 
> ? ? 1. Create new client f.i. in master realm
> ? ? 2. Set "Authorization Enabled"
> ????Go to clients->clientName->Authorization ->Policies - Create
> POlicy??-> Role
> ? ? 3. Create New policy
> 
> Failed Symptoms: No any events generated.
> 
> 
> ? ? 1. Create new client f.i. in master realm
> ? ? 2. Set "Authorization Enabled"
> ? ? 3. Go to clients->clientName->Authorization ->Authorization Scopes
> ? ? 4. Create New scope event_scope
> Failed Symptoms:?No any events generated.
> 
> Thanks & regards,
> Shiva
> 
> 
> 
> ------------------------------
> 
> Message: 5
> Date: Fri, 5 Apr 2019 12:19:19 +0200
> From: V?clav Muzik?? <vmuzikar at redhat.com>
> Subject: [keycloak-dev] Proposal: Approvals System
> To: keycloak-dev <keycloak-dev at lists.jboss.org>
> Message-ID:
>    <CAMQSZygL8LGB80Won27vrGUh8s7MT0JjJWR-dfbjXifsR3mQ=w at mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
> 
> Hello,
> 
> I've been working on an Approvals System for Keycloak and I'd like to
> discuss the design proposal.
> 
> In short, it's a system that is responsible for audit, interception and
> approving/rejection of configuration changes in Keycloak. Even though it's
> designed as general as possible (i.e. able to intercept just about any
> config change), the initial scope will be probably focused on users
> operations.
> 
> It's currently in a PoC state with a formalized design proposal available:
> https://github.com/keycloak/keycloak-community/blob/master/design/approvals-system.md
> 
> Please let me know your thoughts.
> 
> Thank you.
> 
> Regards,
> V?clav Muzik??
> 
> -- 
> V?clav Muzik??
> Senior Quality Engineer
> Keycloak / Red Hat Single Sign-On
> Red Hat Czech s.r.o.
> 
> 
> ------------------------------
> 
> Message: 6
> Date: Fri, 5 Apr 2019 15:55:49 +0200
> From: Marek Posolda <mposolda at redhat.com>
> Subject: Re: [keycloak-dev] Few Admin events not getting raised
> To: Shiva Prasad Thagadur Prakash
>    <shiva.prasad.thagadur.prakash at ericsson.com>,
>    "keycloak-dev at lists.jboss.org" <keycloak-dev at lists.jboss.org>
> Message-ID: <7745f1a9-cd9c-489d-169b-cfabe5697db4 at redhat.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
> 
> Looks like a bug. Feel free to create JIRA. If you're able to send PR 
> with the fix, it will be even better and will cause that bug will be 
> fixed faster :)
> 
> Thanks,
> Marek
> 
>> On 05/04/2019 10:22, Shiva Prasad Thagadur Prakash wrote:
>> Hi Guys,
>> 
>> We see that few admin events are not getting logged to syslog/logfile.
>> Creating scope, Creating New policy for a client and Creating new
>> permission for a client. COuld anyone please help us?
>> 
>> Steps to reproduce:
>> New permisson event
>> ? ? 1. Create new client f.i. in master realm
>> ? ? 2. Set "Authorization Enabled"
>> ? ? 3. Go to clients->clientName->Authorization ->Permissions - Scope
>> based
>> ? ? 4. Create New permission
>> 
>> Failed Symptoms: No any events generated.
>> 
>> ? ? 1. Create new client f.i. in master realm
>> ? ? 2. Set "Authorization Enabled"
>> ????Go to clients->clientName->Authorization ->Policies - Create
>> POlicy??-> Role
>> ? ? 3. Create New policy
>> 
>> Failed Symptoms: No any events generated.
>> 
>> 
>> ? ? 1. Create new client f.i. in master realm
>> ? ? 2. Set "Authorization Enabled"
>> ? ? 3. Go to clients->clientName->Authorization ->Authorization Scopes
>> ? ? 4. Create New scope event_scope
>> Failed Symptoms:?No any events generated.
>> 
>> Thanks & regards,
>> Shiva
>> 
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 
> 
> 
> 
> ------------------------------
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 
> End of keycloak-dev Digest, Vol 70, Issue 8
> *******************************************


From yormen1 at gmail.com  Fri Apr  5 16:52:33 2019
From: yormen1 at gmail.com (yormen1 at gmail.com)
Date: Fri, 5 Apr 2019 20:52:33 +0000
Subject: [keycloak-dev] Session management improvement
Message-ID: <D2D053FE-4D6C-4C98-BC31-C3FC166E2590@gmail.com>

I don't know if something could be done about multiple selection when you want to logout a group of session out from keycloak at the same time.

I apologies for the mistake earlier.

From thomas.darimont at googlemail.com  Sat Apr  6 07:09:42 2019
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Sat, 6 Apr 2019 13:09:42 +0200
Subject: [keycloak-dev] Smaller RefreshTokens?
Message-ID: <CAK-7U1jQyM_Di3Njc-dVkbr6DmmJGwTdjhUTPnrn7MZvascypQ@mail.gmail.com>

Hello,

the refresh tokens which are currently issued by Keycloak contain standard
JWT claims and references to the Keycloak session. Additionally they also
contain realm roles and client role information together with the used
scope.

I'm wondering whether roles and scope information is required for refresh
tokens or could even be removed?

Cheers,
Thomas

From mposolda at redhat.com  Mon Apr  8 04:33:48 2019
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 8 Apr 2019 10:33:48 +0200
Subject: [keycloak-dev] Smaller RefreshTokens?
In-Reply-To: <CAK-7U1jQyM_Di3Njc-dVkbr6DmmJGwTdjhUTPnrn7MZvascypQ@mail.gmail.com>
References: <CAK-7U1jQyM_Di3Njc-dVkbr6DmmJGwTdjhUTPnrn7MZvascypQ@mail.gmail.com>
Message-ID: <cefd0fc2-27bc-1395-ce69-19e1f11d09c8@redhat.com>

Hi Thomas,

yes roles can be removed from the refresh tokens and maybe JIRA already 
exists for this, but not 100% sure...

Client scopes can't actually be removed as you can have more refresh 
tokens corresponding to same client in same user session and we want the 
information about used client scopes to be tracked in the refresh token 
itself (tracking that on server-side in the session has some other 
disadvantages for various reasons...). I think this is not so big issue 
as scopes in the tokens is not so huge as the roles?

Marek

On 06/04/2019 13:09, Thomas Darimont wrote:
> Hello,
>
> the refresh tokens which are currently issued by Keycloak contain standard
> JWT claims and references to the Keycloak session. Additionally they also
> contain realm roles and client role information together with the used
> scope.
>
> I'm wondering whether roles and scope information is required for refresh
> tokens or could even be removed?
>
> Cheers,
> Thomas
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



From mhajas at redhat.com  Tue Apr  9 03:21:10 2019
From: mhajas at redhat.com (Michal Hajas)
Date: Tue, 9 Apr 2019 09:21:10 +0200
Subject: [keycloak-dev] Token's issuedAt value is the same as value of
	NotBeforePolicy
Message-ID: <CACv4bCQed2ch4==L1gH2oYVzUCRazEq5Dem7OiW6Ax_KYjc7vg@mail.gmail.com>

Hi,

I found out that when you do logout-all (in this step realm.notBefore value
is set) and subsequent login very quickly it may happen that Keycloak
returns tokens with an issuedAt value which is the same as the value of the
NotBeforePolicy.

Such tokens are considered invalid in adapter due to this check [1].

My question is, should we prevent such state? If yes what is correct
behavior?

1. Do not generate tokens with the same issuedAt value as NotBefore policy.
For example, in TokenManager [2] check NotBefore value and change
issuedAt for all tokens to (NotBefore + 1) in case they are same.

or

2. Change condition [2]:
.... && this.token.getIssuedAt() > deployment.getNotBefore();
to:
.... && this.token.getIssuedAt() >= deployment.getNotBefore();

The later will probably require to also check other non-java adapters
whether such check is present or not.

Best regards,
Michal

[1]
https://github.com/keycloak/keycloak/blob/master/adapters/oidc/adapter-core/src/main/java/org/keycloak/adapters/RefreshableKeycloakSecurityContext.java#L79

[2]
https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/protocol/oidc/TokenManager.java#L796

From mposolda at redhat.com  Tue Apr  9 07:47:58 2019
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 9 Apr 2019 13:47:58 +0200
Subject: [keycloak-dev] Token's issuedAt value is the same as value of
 NotBeforePolicy
In-Reply-To: <CACv4bCQed2ch4==L1gH2oYVzUCRazEq5Dem7OiW6Ax_KYjc7vg@mail.gmail.com>
References: <CACv4bCQed2ch4==L1gH2oYVzUCRazEq5Dem7OiW6Ax_KYjc7vg@mail.gmail.com>
Message-ID: <8becc9a6-aabb-8bf1-c6ce-a9530a742c58@redhat.com>

My vote is to go with (2). It may turn to be more work as it needs to 
check all the adapters (node.js, maybe also gatekeeper etc).

But strictly said, if not-before is set for example to 10:0000, then my 
understanding of not-before semantics is to check that: token is valid 
if it was issued not before 10:00:00 .
Which translates to: token is valid if it was wasn't issued before 
10:00:00 .

In other words, if not-before is 10:00:00 then token issued at 9:59:59 
shouldn't be valid, but token issued at 10:00:00 should be valid IMO.

Marek

On 09/04/2019 09:21, Michal Hajas wrote:
> Hi,
>
> I found out that when you do logout-all (in this step realm.notBefore value
> is set) and subsequent login very quickly it may happen that Keycloak
> returns tokens with an issuedAt value which is the same as the value of the
> NotBeforePolicy.
>
> Such tokens are considered invalid in adapter due to this check [1].
>
> My question is, should we prevent such state? If yes what is correct
> behavior?
>
> 1. Do not generate tokens with the same issuedAt value as NotBefore policy.
> For example, in TokenManager [2] check NotBefore value and change
> issuedAt for all tokens to (NotBefore + 1) in case they are same.
>
> or
>
> 2. Change condition [2]:
> .... && this.token.getIssuedAt() > deployment.getNotBefore();
> to:
> .... && this.token.getIssuedAt() >= deployment.getNotBefore();
>
> The later will probably require to also check other non-java adapters
> whether such check is present or not.
>
> Best regards,
> Michal
>
> [1]
> https://github.com/keycloak/keycloak/blob/master/adapters/oidc/adapter-core/src/main/java/org/keycloak/adapters/RefreshableKeycloakSecurityContext.java#L79
>
> [2]
> https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/protocol/oidc/TokenManager.java#L796
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



From mposolda at redhat.com  Tue Apr  9 07:50:48 2019
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 9 Apr 2019 13:50:48 +0200
Subject: [keycloak-dev] Token's issuedAt value is the same as value of
 NotBeforePolicy
In-Reply-To: <8becc9a6-aabb-8bf1-c6ce-a9530a742c58@redhat.com>
References: <CACv4bCQed2ch4==L1gH2oYVzUCRazEq5Dem7OiW6Ax_KYjc7vg@mail.gmail.com>
	<8becc9a6-aabb-8bf1-c6ce-a9530a742c58@redhat.com>
Message-ID: <2391fc8d-080a-ec4d-0cd5-ffb0989441ae@redhat.com>

On 09/04/2019 13:47, Marek Posolda wrote:
> My vote is to go with (2). It may turn to be more work as it needs to 
> check all the adapters (node.js, maybe also gatekeeper etc).
>
> But strictly said, if not-before is set for example to 10:0000, then 
> my understanding of not-before semantics is to check that: token is 
> valid if it was issued not before 10:00:00 .
> Which translates to: token is valid if it was wasn't issued before 
> 10:00:00 .
Sorry, that sentence should be: token is valid if it wasn't issued 
before 10:00:00 :)
>
> In other words, if not-before is 10:00:00 then token issued at 9:59:59 
> shouldn't be valid, but token issued at 10:00:00 should be valid IMO.
>
> Marek
>
> On 09/04/2019 09:21, Michal Hajas wrote:
>> Hi,
>>
>> I found out that when you do logout-all (in this step realm.notBefore 
>> value
>> is set) and subsequent login very quickly it may happen that Keycloak
>> returns tokens with an issuedAt value which is the same as the value 
>> of the
>> NotBeforePolicy.
>>
>> Such tokens are considered invalid in adapter due to this check [1].
>>
>> My question is, should we prevent such state? If yes what is correct
>> behavior?
>>
>> 1. Do not generate tokens with the same issuedAt value as NotBefore 
>> policy.
>> For example, in TokenManager [2] check NotBefore value and change
>> issuedAt for all tokens to (NotBefore + 1) in case they are same.
>>
>> or
>>
>> 2. Change condition [2]:
>> .... && this.token.getIssuedAt() > deployment.getNotBefore();
>> to:
>> .... && this.token.getIssuedAt() >= deployment.getNotBefore();
>>
>> The later will probably require to also check other non-java adapters
>> whether such check is present or not.
>>
>> Best regards,
>> Michal
>>
>> [1]
>> https://github.com/keycloak/keycloak/blob/master/adapters/oidc/adapter-core/src/main/java/org/keycloak/adapters/RefreshableKeycloakSecurityContext.java#L79 
>>
>>
>> [2]
>> https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/protocol/oidc/TokenManager.java#L796 
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>


From sthorger at redhat.com  Tue Apr  9 07:53:48 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 9 Apr 2019 13:53:48 +0200
Subject: [keycloak-dev] Token's issuedAt value is the same as value of
	NotBeforePolicy
In-Reply-To: <8becc9a6-aabb-8bf1-c6ce-a9530a742c58@redhat.com>
References: <CACv4bCQed2ch4==L1gH2oYVzUCRazEq5Dem7OiW6Ax_KYjc7vg@mail.gmail.com>
	<8becc9a6-aabb-8bf1-c6ce-a9530a742c58@redhat.com>
Message-ID: <CAJgngAdQiY2s0RkSjar+8bmVLwKh5S54Q+g0bX91+cixrXbMMQ@mail.gmail.com>

Not before should be reject tokens before that time, so changing to the
following as suggested would be the correct behaviour:

this.token.getIssuedAt() >= deployment.getNotBefore

Further, all adapters should allow a configurable allowed time sync here.
We should introduce a new property allowedTimeSkew with default set to 1
second. The above would then be changed to:

this.token.getIssuedAt() >= deployment.getNotBefore() -
deployment.getAllowedTimeSkew()

On Tue, 9 Apr 2019 at 13:50, Marek Posolda <mposolda at redhat.com> wrote:

> My vote is to go with (2). It may turn to be more work as it needs to
> check all the adapters (node.js, maybe also gatekeeper etc).
>
> But strictly said, if not-before is set for example to 10:0000, then my
> understanding of not-before semantics is to check that: token is valid
> if it was issued not before 10:00:00 .
> Which translates to: token is valid if it was wasn't issued before
> 10:00:00 .
>
> In other words, if not-before is 10:00:00 then token issued at 9:59:59
> shouldn't be valid, but token issued at 10:00:00 should be valid IMO.
>
> Marek
>
> On 09/04/2019 09:21, Michal Hajas wrote:
> > Hi,
> >
> > I found out that when you do logout-all (in this step realm.notBefore
> value
> > is set) and subsequent login very quickly it may happen that Keycloak
> > returns tokens with an issuedAt value which is the same as the value of
> the
> > NotBeforePolicy.
> >
> > Such tokens are considered invalid in adapter due to this check [1].
> >
> > My question is, should we prevent such state? If yes what is correct
> > behavior?
> >
> > 1. Do not generate tokens with the same issuedAt value as NotBefore
> policy.
> > For example, in TokenManager [2] check NotBefore value and change
> > issuedAt for all tokens to (NotBefore + 1) in case they are same.
> >
> > or
> >
> > 2. Change condition [2]:
> > .... && this.token.getIssuedAt() > deployment.getNotBefore();
> > to:
> > .... && this.token.getIssuedAt() >= deployment.getNotBefore();
> >
> > The later will probably require to also check other non-java adapters
> > whether such check is present or not.
> >
> > Best regards,
> > Michal
> >
> > [1]
> >
> https://github.com/keycloak/keycloak/blob/master/adapters/oidc/adapter-core/src/main/java/org/keycloak/adapters/RefreshableKeycloakSecurityContext.java#L79
> >
> > [2]
> >
> https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/protocol/oidc/TokenManager.java#L796
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From mposolda at redhat.com  Tue Apr  9 09:16:46 2019
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 9 Apr 2019 15:16:46 +0200
Subject: [keycloak-dev] Token's issuedAt value is the same as value of
 NotBeforePolicy
In-Reply-To: <CAJgngAdQiY2s0RkSjar+8bmVLwKh5S54Q+g0bX91+cixrXbMMQ@mail.gmail.com>
References: <CACv4bCQed2ch4==L1gH2oYVzUCRazEq5Dem7OiW6Ax_KYjc7vg@mail.gmail.com>
	<8becc9a6-aabb-8bf1-c6ce-a9530a742c58@redhat.com>
	<CAJgngAdQiY2s0RkSjar+8bmVLwKh5S54Q+g0bX91+cixrXbMMQ@mail.gmail.com>
Message-ID: <ee1c799c-a2a0-672b-5b14-e6204aab5e12@redhat.com>

On 09/04/2019 13:53, Stian Thorgersen wrote:
> Not before should be reject tokens before that time, so changing to 
> the following as suggested would be the correct behaviour:
>
> this.token.getIssuedAt() >= deployment.getNotBefore
>
> Further, all adapters should allow a configurable allowed time sync 
> here. We should introduce a new property allowedTimeSkew with default 
> set to 1 second. The above would then be changed to:
>
> this.token.getIssuedAt() >= deployment.getNotBefore() - 
> deployment.getAllowedTimeSkew()

That's the question whether we need another configuration option? Can't 
recall if someone asks for this? And we have lots of switches already :)

I see the point in having clock skew in keycloak.js, which is executed 
on user's machines and there is quite high chance of having time 
slightly out of sync. On the other hand, java adapter is mostly executed 
on servers where apps are deployed and server administrators usually pay 
attention to have time in sync to avoid various issues?

Marek

>
> On Tue, 9 Apr 2019 at 13:50, Marek Posolda <mposolda at redhat.com 
> <mailto:mposolda at redhat.com>> wrote:
>
>     My vote is to go with (2). It may turn to be more work as it needs to
>     check all the adapters (node.js, maybe also gatekeeper etc).
>
>     But strictly said, if not-before is set for example to 10:0000,
>     then my
>     understanding of not-before semantics is to check that: token is
>     valid
>     if it was issued not before 10:00:00 .
>     Which translates to: token is valid if it was wasn't issued before
>     10:00:00 .
>
>     In other words, if not-before is 10:00:00 then token issued at
>     9:59:59
>     shouldn't be valid, but token issued at 10:00:00 should be valid IMO.
>
>     Marek
>
>     On 09/04/2019 09:21, Michal Hajas wrote:
>     > Hi,
>     >
>     > I found out that when you do logout-all (in this step
>     realm.notBefore value
>     > is set) and subsequent login very quickly it may happen that
>     Keycloak
>     > returns tokens with an issuedAt value which is the same as the
>     value of the
>     > NotBeforePolicy.
>     >
>     > Such tokens are considered invalid in adapter due to this check [1].
>     >
>     > My question is, should we prevent such state? If yes what is correct
>     > behavior?
>     >
>     > 1. Do not generate tokens with the same issuedAt value as
>     NotBefore policy.
>     > For example, in TokenManager [2] check NotBefore value and change
>     > issuedAt for all tokens to (NotBefore + 1) in case they are same.
>     >
>     > or
>     >
>     > 2. Change condition [2]:
>     > .... && this.token.getIssuedAt() > deployment.getNotBefore();
>     > to:
>     > .... && this.token.getIssuedAt() >= deployment.getNotBefore();
>     >
>     > The later will probably require to also check other non-java
>     adapters
>     > whether such check is present or not.
>     >
>     > Best regards,
>     > Michal
>     >
>     > [1]
>     >
>     https://github.com/keycloak/keycloak/blob/master/adapters/oidc/adapter-core/src/main/java/org/keycloak/adapters/RefreshableKeycloakSecurityContext.java#L79
>     >
>     > [2]
>     >
>     https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/protocol/oidc/TokenManager.java#L796
>     > _______________________________________________
>     > keycloak-dev mailing list
>     > keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>     _______________________________________________
>     keycloak-dev mailing list
>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>


From hmlnarik at redhat.com  Tue Apr  9 09:38:00 2019
From: hmlnarik at redhat.com (Hynek Mlnarik)
Date: Tue, 9 Apr 2019 15:38:00 +0200
Subject: [keycloak-dev] Token's issuedAt value is the same as value of
	NotBeforePolicy
In-Reply-To: <ee1c799c-a2a0-672b-5b14-e6204aab5e12@redhat.com>
References: <CACv4bCQed2ch4==L1gH2oYVzUCRazEq5Dem7OiW6Ax_KYjc7vg@mail.gmail.com>
	<8becc9a6-aabb-8bf1-c6ce-a9530a742c58@redhat.com>
	<CAJgngAdQiY2s0RkSjar+8bmVLwKh5S54Q+g0bX91+cixrXbMMQ@mail.gmail.com>
	<ee1c799c-a2a0-672b-5b14-e6204aab5e12@redhat.com>
Message-ID: <CAMvXD=H08BZuthGNo3od=F2b6ssfUurDZKV8+L4eM1NE4H5PXA@mail.gmail.com>

Clock time skew was asked for in SAML adapter [1] (number of watchers is
6), mostly because inability to sync the clocks up to millisecond precision

I am in favor of including this option. We should support the configuration
both in adapters and in identity provider configuration (these bits can be
provided separately).

[1] https://issues.jboss.org/browse/KEYCLOAK-8104

On Tue, Apr 9, 2019 at 3:31 PM Marek Posolda <mposolda at redhat.com> wrote:

> On 09/04/2019 13:53, Stian Thorgersen wrote:
> > Not before should be reject tokens before that time, so changing to
> > the following as suggested would be the correct behaviour:
> >
> > this.token.getIssuedAt() >= deployment.getNotBefore
> >
> > Further, all adapters should allow a configurable allowed time sync
> > here. We should introduce a new property allowedTimeSkew with default
> > set to 1 second. The above would then be changed to:
> >
> > this.token.getIssuedAt() >= deployment.getNotBefore() -
> > deployment.getAllowedTimeSkew()
>
> That's the question whether we need another configuration option? Can't
> recall if someone asks for this? And we have lots of switches already :)
>
> I see the point in having clock skew in keycloak.js, which is executed
> on user's machines and there is quite high chance of having time
> slightly out of sync. On the other hand, java adapter is mostly executed
> on servers where apps are deployed and server administrators usually pay
> attention to have time in sync to avoid various issues?
>
> Marek
>
> >
> > On Tue, 9 Apr 2019 at 13:50, Marek Posolda <mposolda at redhat.com
> > <mailto:mposolda at redhat.com>> wrote:
> >
> >     My vote is to go with (2). It may turn to be more work as it needs to
> >     check all the adapters (node.js, maybe also gatekeeper etc).
> >
> >     But strictly said, if not-before is set for example to 10:0000,
> >     then my
> >     understanding of not-before semantics is to check that: token is
> >     valid
> >     if it was issued not before 10:00:00 .
> >     Which translates to: token is valid if it was wasn't issued before
> >     10:00:00 .
> >
> >     In other words, if not-before is 10:00:00 then token issued at
> >     9:59:59
> >     shouldn't be valid, but token issued at 10:00:00 should be valid IMO.
> >
> >     Marek
> >
> >     On 09/04/2019 09:21, Michal Hajas wrote:
> >     > Hi,
> >     >
> >     > I found out that when you do logout-all (in this step
> >     realm.notBefore value
> >     > is set) and subsequent login very quickly it may happen that
> >     Keycloak
> >     > returns tokens with an issuedAt value which is the same as the
> >     value of the
> >     > NotBeforePolicy.
> >     >
> >     > Such tokens are considered invalid in adapter due to this check
> [1].
> >     >
> >     > My question is, should we prevent such state? If yes what is
> correct
> >     > behavior?
> >     >
> >     > 1. Do not generate tokens with the same issuedAt value as
> >     NotBefore policy.
> >     > For example, in TokenManager [2] check NotBefore value and change
> >     > issuedAt for all tokens to (NotBefore + 1) in case they are same.
> >     >
> >     > or
> >     >
> >     > 2. Change condition [2]:
> >     > .... && this.token.getIssuedAt() > deployment.getNotBefore();
> >     > to:
> >     > .... && this.token.getIssuedAt() >= deployment.getNotBefore();
> >     >
> >     > The later will probably require to also check other non-java
> >     adapters
> >     > whether such check is present or not.
> >     >
> >     > Best regards,
> >     > Michal
> >     >
> >     > [1]
> >     >
> >
> https://github.com/keycloak/keycloak/blob/master/adapters/oidc/adapter-core/src/main/java/org/keycloak/adapters/RefreshableKeycloakSecurityContext.java#L79
> >     >
> >     > [2]
> >     >
> >
> https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/protocol/oidc/TokenManager.java#L796
> >     > _______________________________________________
> >     > keycloak-dev mailing list
> >     > keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
> >     > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> >
> >     _______________________________________________
> >     keycloak-dev mailing list
> >     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
> >     https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From mposolda at redhat.com  Tue Apr  9 09:42:35 2019
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 9 Apr 2019 15:42:35 +0200
Subject: [keycloak-dev] Token's issuedAt value is the same as value of
 NotBeforePolicy
In-Reply-To: <CAMvXD=H08BZuthGNo3od=F2b6ssfUurDZKV8+L4eM1NE4H5PXA@mail.gmail.com>
References: <CACv4bCQed2ch4==L1gH2oYVzUCRazEq5Dem7OiW6Ax_KYjc7vg@mail.gmail.com>
	<8becc9a6-aabb-8bf1-c6ce-a9530a742c58@redhat.com>
	<CAJgngAdQiY2s0RkSjar+8bmVLwKh5S54Q+g0bX91+cixrXbMMQ@mail.gmail.com>
	<ee1c799c-a2a0-672b-5b14-e6204aab5e12@redhat.com>
	<CAMvXD=H08BZuthGNo3od=F2b6ssfUurDZKV8+L4eM1NE4H5PXA@mail.gmail.com>
Message-ID: <939c2710-c281-37db-1a03-605688650c3b@redhat.com>

Ah, ok. Forgot that we already added such option to identity providers, 
so seems that people really have issues on servers too. +1 for add the 
option then.

Thanks,
Marek


On 09/04/2019 15:38, Hynek Mlnarik wrote:
> Clock time skew was asked for in SAML adapter [1] (number of watchers 
> is 6), mostly because inability to sync the clocks up to millisecond 
> precision
>
> I am in favor of including this option. We should support the 
> configuration both in adapters and in identity provider configuration 
> (these bits can be provided separately).
>
> [1] https://issues.jboss.org/browse/KEYCLOAK-8104
>
> On Tue, Apr 9, 2019 at 3:31 PM Marek Posolda <mposolda at redhat.com 
> <mailto:mposolda at redhat.com>> wrote:
>
>     On 09/04/2019 13:53, Stian Thorgersen wrote:
>     > Not before should be reject tokens before that time, so changing to
>     > the following as suggested would be the correct behaviour:
>     >
>     > this.token.getIssuedAt() >= deployment.getNotBefore
>     >
>     > Further, all adapters should allow a configurable allowed time sync
>     > here. We should introduce a new property allowedTimeSkew with
>     default
>     > set to 1 second. The above would then be changed to:
>     >
>     > this.token.getIssuedAt() >= deployment.getNotBefore() -
>     > deployment.getAllowedTimeSkew()
>
>     That's the question whether we need another configuration option?
>     Can't
>     recall if someone asks for this? And we have lots of switches
>     already :)
>
>     I see the point in having clock skew in keycloak.js, which is
>     executed
>     on user's machines and there is quite high chance of having time
>     slightly out of sync. On the other hand, java adapter is mostly
>     executed
>     on servers where apps are deployed and server administrators
>     usually pay
>     attention to have time in sync to avoid various issues?
>
>     Marek
>
>     >
>     > On Tue, 9 Apr 2019 at 13:50, Marek Posolda <mposolda at redhat.com
>     <mailto:mposolda at redhat.com>
>     > <mailto:mposolda at redhat.com <mailto:mposolda at redhat.com>>> wrote:
>     >
>     >? ? ?My vote is to go with (2). It may turn to be more work as it
>     needs to
>     >? ? ?check all the adapters (node.js, maybe also gatekeeper etc).
>     >
>     >? ? ?But strictly said, if not-before is set for example to 10:0000,
>     >? ? ?then my
>     >? ? ?understanding of not-before semantics is to check that: token is
>     >? ? ?valid
>     >? ? ?if it was issued not before 10:00:00 .
>     >? ? ?Which translates to: token is valid if it was wasn't issued
>     before
>     >? ? ?10:00:00 .
>     >
>     >? ? ?In other words, if not-before is 10:00:00 then token issued at
>     >? ? ?9:59:59
>     >? ? ?shouldn't be valid, but token issued at 10:00:00 should be
>     valid IMO.
>     >
>     >? ? ?Marek
>     >
>     >? ? ?On 09/04/2019 09:21, Michal Hajas wrote:
>     >? ? ?> Hi,
>     >? ? ?>
>     >? ? ?> I found out that when you do logout-all (in this step
>     >? ? ?realm.notBefore value
>     >? ? ?> is set) and subsequent login very quickly it may happen that
>     >? ? ?Keycloak
>     >? ? ?> returns tokens with an issuedAt value which is the same as the
>     >? ? ?value of the
>     >? ? ?> NotBeforePolicy.
>     >? ? ?>
>     >? ? ?> Such tokens are considered invalid in adapter due to this
>     check [1].
>     >? ? ?>
>     >? ? ?> My question is, should we prevent such state? If yes what
>     is correct
>     >? ? ?> behavior?
>     >? ? ?>
>     >? ? ?> 1. Do not generate tokens with the same issuedAt value as
>     >? ? ?NotBefore policy.
>     >? ? ?> For example, in TokenManager [2] check NotBefore value and
>     change
>     >? ? ?> issuedAt for all tokens to (NotBefore + 1) in case they
>     are same.
>     >? ? ?>
>     >? ? ?> or
>     >? ? ?>
>     >? ? ?> 2. Change condition [2]:
>     >? ? ?> .... && this.token.getIssuedAt() > deployment.getNotBefore();
>     >? ? ?> to:
>     >? ? ?> .... && this.token.getIssuedAt() >= deployment.getNotBefore();
>     >? ? ?>
>     >? ? ?> The later will probably require to also check other non-java
>     >? ? ?adapters
>     >? ? ?> whether such check is present or not.
>     >? ? ?>
>     >? ? ?> Best regards,
>     >? ? ?> Michal
>     >? ? ?>
>     >? ? ?> [1]
>     >? ? ?>
>     >
>     https://github.com/keycloak/keycloak/blob/master/adapters/oidc/adapter-core/src/main/java/org/keycloak/adapters/RefreshableKeycloakSecurityContext.java#L79
>     >? ? ?>
>     >? ? ?> [2]
>     >? ? ?>
>     >
>     https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/protocol/oidc/TokenManager.java#L796
>     >? ? ?> _______________________________________________
>     >? ? ?> keycloak-dev mailing list
>     >? ? ?> keycloak-dev at lists.jboss.org
>     <mailto:keycloak-dev at lists.jboss.org>
>     <mailto:keycloak-dev at lists.jboss.org
>     <mailto:keycloak-dev at lists.jboss.org>>
>     >? ? ?> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>     >
>     >
>     >? ? ?_______________________________________________
>     >? ? ?keycloak-dev mailing list
>     > keycloak-dev at lists.jboss.org
>     <mailto:keycloak-dev at lists.jboss.org>
>     <mailto:keycloak-dev at lists.jboss.org
>     <mailto:keycloak-dev at lists.jboss.org>>
>     > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>     >
>
>     _______________________________________________
>     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
>


From sthorger at redhat.com  Tue Apr  9 10:14:21 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 9 Apr 2019 16:14:21 +0200
Subject: [keycloak-dev] Token's issuedAt value is the same as value of
	NotBeforePolicy
In-Reply-To: <939c2710-c281-37db-1a03-605688650c3b@redhat.com>
References: <CACv4bCQed2ch4==L1gH2oYVzUCRazEq5Dem7OiW6Ax_KYjc7vg@mail.gmail.com>
	<8becc9a6-aabb-8bf1-c6ce-a9530a742c58@redhat.com>
	<CAJgngAdQiY2s0RkSjar+8bmVLwKh5S54Q+g0bX91+cixrXbMMQ@mail.gmail.com>
	<ee1c799c-a2a0-672b-5b14-e6204aab5e12@redhat.com>
	<CAMvXD=H08BZuthGNo3od=F2b6ssfUurDZKV8+L4eM1NE4H5PXA@mail.gmail.com>
	<939c2710-c281-37db-1a03-605688650c3b@redhat.com>
Message-ID: <CAJgngAc-6hPiwTRm1__LQ9HM7n48JZwLvKEcSvAPGE=wkEGvGg@mail.gmail.com>

I wonder if we could just set it to 1 sec and not make it configurable?

On Tue, 9 Apr 2019 at 15:42, Marek Posolda <mposolda at redhat.com> wrote:

> Ah, ok. Forgot that we already added such option to identity providers, so
> seems that people really have issues on servers too. +1 for add the option
> then.
>
> Thanks,
> Marek
>
>
> On 09/04/2019 15:38, Hynek Mlnarik wrote:
>
> Clock time skew was asked for in SAML adapter [1] (number of watchers is
> 6), mostly because inability to sync the clocks up to millisecond precision
>
> I am in favor of including this option. We should support the
> configuration both in adapters and in identity provider configuration
> (these bits can be provided separately).
>
> [1] https://issues.jboss.org/browse/KEYCLOAK-8104
>
> On Tue, Apr 9, 2019 at 3:31 PM Marek Posolda <mposolda at redhat.com> wrote:
>
>> On 09/04/2019 13:53, Stian Thorgersen wrote:
>> > Not before should be reject tokens before that time, so changing to
>> > the following as suggested would be the correct behaviour:
>> >
>> > this.token.getIssuedAt() >= deployment.getNotBefore
>> >
>> > Further, all adapters should allow a configurable allowed time sync
>> > here. We should introduce a new property allowedTimeSkew with default
>> > set to 1 second. The above would then be changed to:
>> >
>> > this.token.getIssuedAt() >= deployment.getNotBefore() -
>> > deployment.getAllowedTimeSkew()
>>
>> That's the question whether we need another configuration option? Can't
>> recall if someone asks for this? And we have lots of switches already :)
>>
>> I see the point in having clock skew in keycloak.js, which is executed
>> on user's machines and there is quite high chance of having time
>> slightly out of sync. On the other hand, java adapter is mostly executed
>> on servers where apps are deployed and server administrators usually pay
>> attention to have time in sync to avoid various issues?
>>
>> Marek
>>
>> >
>> > On Tue, 9 Apr 2019 at 13:50, Marek Posolda <mposolda at redhat.com
>> > <mailto:mposolda at redhat.com>> wrote:
>> >
>> >     My vote is to go with (2). It may turn to be more work as it needs
>> to
>> >     check all the adapters (node.js, maybe also gatekeeper etc).
>> >
>> >     But strictly said, if not-before is set for example to 10:0000,
>> >     then my
>> >     understanding of not-before semantics is to check that: token is
>> >     valid
>> >     if it was issued not before 10:00:00 .
>> >     Which translates to: token is valid if it was wasn't issued before
>> >     10:00:00 .
>> >
>> >     In other words, if not-before is 10:00:00 then token issued at
>> >     9:59:59
>> >     shouldn't be valid, but token issued at 10:00:00 should be valid
>> IMO.
>> >
>> >     Marek
>> >
>> >     On 09/04/2019 09:21, Michal Hajas wrote:
>> >     > Hi,
>> >     >
>> >     > I found out that when you do logout-all (in this step
>> >     realm.notBefore value
>> >     > is set) and subsequent login very quickly it may happen that
>> >     Keycloak
>> >     > returns tokens with an issuedAt value which is the same as the
>> >     value of the
>> >     > NotBeforePolicy.
>> >     >
>> >     > Such tokens are considered invalid in adapter due to this check
>> [1].
>> >     >
>> >     > My question is, should we prevent such state? If yes what is
>> correct
>> >     > behavior?
>> >     >
>> >     > 1. Do not generate tokens with the same issuedAt value as
>> >     NotBefore policy.
>> >     > For example, in TokenManager [2] check NotBefore value and change
>> >     > issuedAt for all tokens to (NotBefore + 1) in case they are same.
>> >     >
>> >     > or
>> >     >
>> >     > 2. Change condition [2]:
>> >     > .... && this.token.getIssuedAt() > deployment.getNotBefore();
>> >     > to:
>> >     > .... && this.token.getIssuedAt() >= deployment.getNotBefore();
>> >     >
>> >     > The later will probably require to also check other non-java
>> >     adapters
>> >     > whether such check is present or not.
>> >     >
>> >     > Best regards,
>> >     > Michal
>> >     >
>> >     > [1]
>> >     >
>> >
>> https://github.com/keycloak/keycloak/blob/master/adapters/oidc/adapter-core/src/main/java/org/keycloak/adapters/RefreshableKeycloakSecurityContext.java#L79
>> >     >
>> >     > [2]
>> >     >
>> >
>> https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/protocol/oidc/TokenManager.java#L796
>> >     > _______________________________________________
>> >     > keycloak-dev mailing list
>> >     > keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org
>> >
>> >     > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> >
>> >
>> >     _______________________________________________
>> >     keycloak-dev mailing list
>> >     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>> >     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> >
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>

From mposolda at redhat.com  Tue Apr  9 10:38:02 2019
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 9 Apr 2019 16:38:02 +0200
Subject: [keycloak-dev] Token's issuedAt value is the same as value of
 NotBeforePolicy
In-Reply-To: <CAJgngAc-6hPiwTRm1__LQ9HM7n48JZwLvKEcSvAPGE=wkEGvGg@mail.gmail.com>
References: <CACv4bCQed2ch4==L1gH2oYVzUCRazEq5Dem7OiW6Ax_KYjc7vg@mail.gmail.com>
	<8becc9a6-aabb-8bf1-c6ce-a9530a742c58@redhat.com>
	<CAJgngAdQiY2s0RkSjar+8bmVLwKh5S54Q+g0bX91+cixrXbMMQ@mail.gmail.com>
	<ee1c799c-a2a0-672b-5b14-e6204aab5e12@redhat.com>
	<CAMvXD=H08BZuthGNo3od=F2b6ssfUurDZKV8+L4eM1NE4H5PXA@mail.gmail.com>
	<939c2710-c281-37db-1a03-605688650c3b@redhat.com>
	<CAJgngAc-6hPiwTRm1__LQ9HM7n48JZwLvKEcSvAPGE=wkEGvGg@mail.gmail.com>
Message-ID: <3bc91c26-c7bc-2ded-feb3-a1d57fffc96b@redhat.com>

+1

We can revisit later if more fine-grained clock skew configuration is 
needed.

Marek

On 09/04/2019 16:14, Stian Thorgersen wrote:
> I wonder if we could just set it to 1 sec and not make it configurable?
>
> On Tue, 9 Apr 2019 at 15:42, Marek Posolda <mposolda at redhat.com 
> <mailto:mposolda at redhat.com>> wrote:
>
>     Ah, ok. Forgot that we already added such option to identity
>     providers, so seems that people really have issues on servers too.
>     +1 for add the option then.
>
>     Thanks,
>     Marek
>
>
>     On 09/04/2019 15:38, Hynek Mlnarik wrote:
>>     Clock time skew was asked for in SAML adapter [1] (number of
>>     watchers is 6), mostly because inability to sync the clocks up to
>>     millisecond precision
>>
>>     I am in favor of including this option. We should support the
>>     configuration both in adapters and in identity provider
>>     configuration (these bits can be provided separately).
>>
>>     [1] https://issues.jboss.org/browse/KEYCLOAK-8104
>>
>>     On Tue, Apr 9, 2019 at 3:31 PM Marek Posolda <mposolda at redhat.com
>>     <mailto:mposolda at redhat.com>> wrote:
>>
>>         On 09/04/2019 13:53, Stian Thorgersen wrote:
>>         > Not before should be reject tokens before that time, so
>>         changing to
>>         > the following as suggested would be the correct behaviour:
>>         >
>>         > this.token.getIssuedAt() >= deployment.getNotBefore
>>         >
>>         > Further, all adapters should allow a configurable allowed
>>         time sync
>>         > here. We should introduce a new property allowedTimeSkew
>>         with default
>>         > set to 1 second. The above would then be changed to:
>>         >
>>         > this.token.getIssuedAt() >= deployment.getNotBefore() -
>>         > deployment.getAllowedTimeSkew()
>>
>>         That's the question whether we need another configuration
>>         option? Can't
>>         recall if someone asks for this? And we have lots of switches
>>         already :)
>>
>>         I see the point in having clock skew in keycloak.js, which is
>>         executed
>>         on user's machines and there is quite high chance of having time
>>         slightly out of sync. On the other hand, java adapter is
>>         mostly executed
>>         on servers where apps are deployed and server administrators
>>         usually pay
>>         attention to have time in sync to avoid various issues?
>>
>>         Marek
>>
>>         >
>>         > On Tue, 9 Apr 2019 at 13:50, Marek Posolda
>>         <mposolda at redhat.com <mailto:mposolda at redhat.com>
>>         > <mailto:mposolda at redhat.com <mailto:mposolda at redhat.com>>>
>>         wrote:
>>         >
>>         >? ? ?My vote is to go with (2). It may turn to be more work
>>         as it needs to
>>         >? ? ?check all the adapters (node.js, maybe also gatekeeper
>>         etc).
>>         >
>>         >? ? ?But strictly said, if not-before is set for example to
>>         10:0000,
>>         >? ? ?then my
>>         >? ? ?understanding of not-before semantics is to check that:
>>         token is
>>         >? ? ?valid
>>         >? ? ?if it was issued not before 10:00:00 .
>>         >? ? ?Which translates to: token is valid if it was wasn't
>>         issued before
>>         >? ? ?10:00:00 .
>>         >
>>         >? ? ?In other words, if not-before is 10:00:00 then token
>>         issued at
>>         >? ? ?9:59:59
>>         >? ? ?shouldn't be valid, but token issued at 10:00:00 should
>>         be valid IMO.
>>         >
>>         >? ? ?Marek
>>         >
>>         >? ? ?On 09/04/2019 09:21, Michal Hajas wrote:
>>         >? ? ?> Hi,
>>         >? ? ?>
>>         >? ? ?> I found out that when you do logout-all (in this step
>>         >? ? ?realm.notBefore value
>>         >? ? ?> is set) and subsequent login very quickly it may
>>         happen that
>>         >? ? ?Keycloak
>>         >? ? ?> returns tokens with an issuedAt value which is the
>>         same as the
>>         >? ? ?value of the
>>         >? ? ?> NotBeforePolicy.
>>         >? ? ?>
>>         >? ? ?> Such tokens are considered invalid in adapter due to
>>         this check [1].
>>         >? ? ?>
>>         >? ? ?> My question is, should we prevent such state? If yes
>>         what is correct
>>         >? ? ?> behavior?
>>         >? ? ?>
>>         >? ? ?> 1. Do not generate tokens with the same issuedAt value as
>>         >? ? ?NotBefore policy.
>>         >? ? ?> For example, in TokenManager [2] check NotBefore
>>         value and change
>>         >? ? ?> issuedAt for all tokens to (NotBefore + 1) in case
>>         they are same.
>>         >? ? ?>
>>         >? ? ?> or
>>         >? ? ?>
>>         >? ? ?> 2. Change condition [2]:
>>         >? ? ?> .... && this.token.getIssuedAt() >
>>         deployment.getNotBefore();
>>         >? ? ?> to:
>>         >? ? ?> .... && this.token.getIssuedAt() >=
>>         deployment.getNotBefore();
>>         >? ? ?>
>>         >? ? ?> The later will probably require to also check other
>>         non-java
>>         >? ? ?adapters
>>         >? ? ?> whether such check is present or not.
>>         >? ? ?>
>>         >? ? ?> Best regards,
>>         >? ? ?> Michal
>>         >? ? ?>
>>         >? ? ?> [1]
>>         >? ? ?>
>>         >
>>         https://github.com/keycloak/keycloak/blob/master/adapters/oidc/adapter-core/src/main/java/org/keycloak/adapters/RefreshableKeycloakSecurityContext.java#L79
>>         >? ? ?>
>>         >? ? ?> [2]
>>         >? ? ?>
>>         >
>>         https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/protocol/oidc/TokenManager.java#L796
>>         >? ? ?> _______________________________________________
>>         >? ? ?> keycloak-dev mailing list
>>         >? ? ?> keycloak-dev at lists.jboss.org
>>         <mailto:keycloak-dev at lists.jboss.org>
>>         <mailto:keycloak-dev at lists.jboss.org
>>         <mailto:keycloak-dev at lists.jboss.org>>
>>         >? ? ?> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>         >
>>         >
>>         > ?_______________________________________________
>>         >? ? ?keycloak-dev mailing list
>>         > keycloak-dev at lists.jboss.org
>>         <mailto:keycloak-dev at lists.jboss.org>
>>         <mailto:keycloak-dev at lists.jboss.org
>>         <mailto:keycloak-dev at lists.jboss.org>>
>>         > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>         >
>>
>>         _______________________________________________
>>         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
>>
>


From hmlnarik at redhat.com  Tue Apr  9 11:31:55 2019
From: hmlnarik at redhat.com (Hynek Mlnarik)
Date: Tue, 9 Apr 2019 17:31:55 +0200
Subject: [keycloak-dev] Token's issuedAt value is the same as value of
	NotBeforePolicy
In-Reply-To: <3bc91c26-c7bc-2ded-feb3-a1d57fffc96b@redhat.com>
References: <CACv4bCQed2ch4==L1gH2oYVzUCRazEq5Dem7OiW6Ax_KYjc7vg@mail.gmail.com>
	<8becc9a6-aabb-8bf1-c6ce-a9530a742c58@redhat.com>
	<CAJgngAdQiY2s0RkSjar+8bmVLwKh5S54Q+g0bX91+cixrXbMMQ@mail.gmail.com>
	<ee1c799c-a2a0-672b-5b14-e6204aab5e12@redhat.com>
	<CAMvXD=H08BZuthGNo3od=F2b6ssfUurDZKV8+L4eM1NE4H5PXA@mail.gmail.com>
	<939c2710-c281-37db-1a03-605688650c3b@redhat.com>
	<CAJgngAc-6hPiwTRm1__LQ9HM7n48JZwLvKEcSvAPGE=wkEGvGg@mail.gmail.com>
	<3bc91c26-c7bc-2ded-feb3-a1d57fffc96b@redhat.com>
Message-ID: <CAMvXD=Hh+XvUc1EGmmVHG005G-RuQ6c2EgN2_7-YdRMO1ztt1g@mail.gmail.com>

-1

This should be administrator's known decision, based on their knowledge of
how much precise they need.

See e.g. [1]: "Tolerances of 3?5 minutes are a reasonable default, but
allowing for configurability is a suggested practice."

We can add a default of 1 second (not convinced about that either, IMO the
default should be 0 since it already works for the most deployments in the
wild) but the value has to be configurable, even if in a fine-grained
configuration.

[1]
https://docs.kantarainitiative.org/fi/rec-saml2-implementation-profile-for-fedinterop.html

On Tue, Apr 9, 2019 at 4:38 PM Marek Posolda <mposolda at redhat.com> wrote:

> +1
>
> We can revisit later if more fine-grained clock skew configuration is
> needed.
>
> Marek
>
> On 09/04/2019 16:14, Stian Thorgersen wrote:
>
> I wonder if we could just set it to 1 sec and not make it configurable?
>
> On Tue, 9 Apr 2019 at 15:42, Marek Posolda <mposolda at redhat.com> wrote:
>
>> Ah, ok. Forgot that we already added such option to identity providers,
>> so seems that people really have issues on servers too. +1 for add the
>> option then.
>>
>> Thanks,
>> Marek
>>
>>
>> On 09/04/2019 15:38, Hynek Mlnarik wrote:
>>
>> Clock time skew was asked for in SAML adapter [1] (number of watchers is
>> 6), mostly because inability to sync the clocks up to millisecond precision
>>
>> I am in favor of including this option. We should support the
>> configuration both in adapters and in identity provider configuration
>> (these bits can be provided separately).
>>
>> [1] https://issues.jboss.org/browse/KEYCLOAK-8104
>>
>> On Tue, Apr 9, 2019 at 3:31 PM Marek Posolda <mposolda at redhat.com> wrote:
>>
>>> On 09/04/2019 13:53, Stian Thorgersen wrote:
>>> > Not before should be reject tokens before that time, so changing to
>>> > the following as suggested would be the correct behaviour:
>>> >
>>> > this.token.getIssuedAt() >= deployment.getNotBefore
>>> >
>>> > Further, all adapters should allow a configurable allowed time sync
>>> > here. We should introduce a new property allowedTimeSkew with default
>>> > set to 1 second. The above would then be changed to:
>>> >
>>> > this.token.getIssuedAt() >= deployment.getNotBefore() -
>>> > deployment.getAllowedTimeSkew()
>>>
>>> That's the question whether we need another configuration option? Can't
>>> recall if someone asks for this? And we have lots of switches already :)
>>>
>>> I see the point in having clock skew in keycloak.js, which is executed
>>> on user's machines and there is quite high chance of having time
>>> slightly out of sync. On the other hand, java adapter is mostly executed
>>> on servers where apps are deployed and server administrators usually pay
>>> attention to have time in sync to avoid various issues?
>>>
>>> Marek
>>>
>>> >
>>> > On Tue, 9 Apr 2019 at 13:50, Marek Posolda <mposolda at redhat.com
>>> > <mailto:mposolda at redhat.com>> wrote:
>>> >
>>> >     My vote is to go with (2). It may turn to be more work as it needs
>>> to
>>> >     check all the adapters (node.js, maybe also gatekeeper etc).
>>> >
>>> >     But strictly said, if not-before is set for example to 10:0000,
>>> >     then my
>>> >     understanding of not-before semantics is to check that: token is
>>> >     valid
>>> >     if it was issued not before 10:00:00 .
>>> >     Which translates to: token is valid if it was wasn't issued before
>>> >     10:00:00 .
>>> >
>>> >     In other words, if not-before is 10:00:00 then token issued at
>>> >     9:59:59
>>> >     shouldn't be valid, but token issued at 10:00:00 should be valid
>>> IMO.
>>> >
>>> >     Marek
>>> >
>>> >     On 09/04/2019 09:21, Michal Hajas wrote:
>>> >     > Hi,
>>> >     >
>>> >     > I found out that when you do logout-all (in this step
>>> >     realm.notBefore value
>>> >     > is set) and subsequent login very quickly it may happen that
>>> >     Keycloak
>>> >     > returns tokens with an issuedAt value which is the same as the
>>> >     value of the
>>> >     > NotBeforePolicy.
>>> >     >
>>> >     > Such tokens are considered invalid in adapter due to this check
>>> [1].
>>> >     >
>>> >     > My question is, should we prevent such state? If yes what is
>>> correct
>>> >     > behavior?
>>> >     >
>>> >     > 1. Do not generate tokens with the same issuedAt value as
>>> >     NotBefore policy.
>>> >     > For example, in TokenManager [2] check NotBefore value and change
>>> >     > issuedAt for all tokens to (NotBefore + 1) in case they are same.
>>> >     >
>>> >     > or
>>> >     >
>>> >     > 2. Change condition [2]:
>>> >     > .... && this.token.getIssuedAt() > deployment.getNotBefore();
>>> >     > to:
>>> >     > .... && this.token.getIssuedAt() >= deployment.getNotBefore();
>>> >     >
>>> >     > The later will probably require to also check other non-java
>>> >     adapters
>>> >     > whether such check is present or not.
>>> >     >
>>> >     > Best regards,
>>> >     > Michal
>>> >     >
>>> >     > [1]
>>> >     >
>>> >
>>> https://github.com/keycloak/keycloak/blob/master/adapters/oidc/adapter-core/src/main/java/org/keycloak/adapters/RefreshableKeycloakSecurityContext.java#L79
>>> >     >
>>> >     > [2]
>>> >     >
>>> >
>>> https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/protocol/oidc/TokenManager.java#L796
>>> >     > _______________________________________________
>>> >     > keycloak-dev mailing list
>>> >     > keycloak-dev at lists.jboss.org <mailto:
>>> keycloak-dev at lists.jboss.org>
>>> >     > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>> >
>>> >
>>> >     _______________________________________________
>>> >     keycloak-dev mailing list
>>> >     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>>> >     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>> >
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>>
>

From sguilhen at redhat.com  Tue Apr  9 13:18:04 2019
From: sguilhen at redhat.com (Stefan Guilhen)
Date: Tue, 9 Apr 2019 14:18:04 -0300
Subject: [keycloak-dev] Token's issuedAt value is the same as value of
	NotBeforePolicy
In-Reply-To: <CAMvXD=Hh+XvUc1EGmmVHG005G-RuQ6c2EgN2_7-YdRMO1ztt1g@mail.gmail.com>
References: <CACv4bCQed2ch4==L1gH2oYVzUCRazEq5Dem7OiW6Ax_KYjc7vg@mail.gmail.com>
	<8becc9a6-aabb-8bf1-c6ce-a9530a742c58@redhat.com>
	<CAJgngAdQiY2s0RkSjar+8bmVLwKh5S54Q+g0bX91+cixrXbMMQ@mail.gmail.com>
	<ee1c799c-a2a0-672b-5b14-e6204aab5e12@redhat.com>
	<CAMvXD=H08BZuthGNo3od=F2b6ssfUurDZKV8+L4eM1NE4H5PXA@mail.gmail.com>
	<939c2710-c281-37db-1a03-605688650c3b@redhat.com>
	<CAJgngAc-6hPiwTRm1__LQ9HM7n48JZwLvKEcSvAPGE=wkEGvGg@mail.gmail.com>
	<3bc91c26-c7bc-2ded-feb3-a1d57fffc96b@redhat.com>
	<CAMvXD=Hh+XvUc1EGmmVHG005G-RuQ6c2EgN2_7-YdRMO1ztt1g@mail.gmail.com>
Message-ID: <CA+7ohfmvWNEbT=AzJDxKFG-8g6M_1DeJ+igA+iA2bdmuH7NjNg@mail.gmail.com>

Agree with Hynek on this one. I'm also not convinced about the default
value of 1 and I really believe the skew should be configurable.

On Tue, Apr 9, 2019 at 1:08 PM Hynek Mlnarik <hmlnarik at redhat.com> wrote:

> -1
>
> This should be administrator's known decision, based on their knowledge of
> how much precise they need.
>
> See e.g. [1]: "Tolerances of 3?5 minutes are a reasonable default, but
> allowing for configurability is a suggested practice."
>
> We can add a default of 1 second (not convinced about that either, IMO the
> default should be 0 since it already works for the most deployments in the
> wild) but the value has to be configurable, even if in a fine-grained
> configuration.
>
> [1]
>
> https://docs.kantarainitiative.org/fi/rec-saml2-implementation-profile-for-fedinterop.html
>
> On Tue, Apr 9, 2019 at 4:38 PM Marek Posolda <mposolda at redhat.com> wrote:
>
> > +1
> >
> > We can revisit later if more fine-grained clock skew configuration is
> > needed.
> >
> > Marek
> >
> > On 09/04/2019 16:14, Stian Thorgersen wrote:
> >
> > I wonder if we could just set it to 1 sec and not make it configurable?
> >
> > On Tue, 9 Apr 2019 at 15:42, Marek Posolda <mposolda at redhat.com> wrote:
> >
> >> Ah, ok. Forgot that we already added such option to identity providers,
> >> so seems that people really have issues on servers too. +1 for add the
> >> option then.
> >>
> >> Thanks,
> >> Marek
> >>
> >>
> >> On 09/04/2019 15:38, Hynek Mlnarik wrote:
> >>
> >> Clock time skew was asked for in SAML adapter [1] (number of watchers is
> >> 6), mostly because inability to sync the clocks up to millisecond
> precision
> >>
> >> I am in favor of including this option. We should support the
> >> configuration both in adapters and in identity provider configuration
> >> (these bits can be provided separately).
> >>
> >> [1] https://issues.jboss.org/browse/KEYCLOAK-8104
> >>
> >> On Tue, Apr 9, 2019 at 3:31 PM Marek Posolda <mposolda at redhat.com>
> wrote:
> >>
> >>> On 09/04/2019 13:53, Stian Thorgersen wrote:
> >>> > Not before should be reject tokens before that time, so changing to
> >>> > the following as suggested would be the correct behaviour:
> >>> >
> >>> > this.token.getIssuedAt() >= deployment.getNotBefore
> >>> >
> >>> > Further, all adapters should allow a configurable allowed time sync
> >>> > here. We should introduce a new property allowedTimeSkew with default
> >>> > set to 1 second. The above would then be changed to:
> >>> >
> >>> > this.token.getIssuedAt() >= deployment.getNotBefore() -
> >>> > deployment.getAllowedTimeSkew()
> >>>
> >>> That's the question whether we need another configuration option? Can't
> >>> recall if someone asks for this? And we have lots of switches already
> :)
> >>>
> >>> I see the point in having clock skew in keycloak.js, which is executed
> >>> on user's machines and there is quite high chance of having time
> >>> slightly out of sync. On the other hand, java adapter is mostly
> executed
> >>> on servers where apps are deployed and server administrators usually
> pay
> >>> attention to have time in sync to avoid various issues?
> >>>
> >>> Marek
> >>>
> >>> >
> >>> > On Tue, 9 Apr 2019 at 13:50, Marek Posolda <mposolda at redhat.com
> >>> > <mailto:mposolda at redhat.com>> wrote:
> >>> >
> >>> >     My vote is to go with (2). It may turn to be more work as it
> needs
> >>> to
> >>> >     check all the adapters (node.js, maybe also gatekeeper etc).
> >>> >
> >>> >     But strictly said, if not-before is set for example to 10:0000,
> >>> >     then my
> >>> >     understanding of not-before semantics is to check that: token is
> >>> >     valid
> >>> >     if it was issued not before 10:00:00 .
> >>> >     Which translates to: token is valid if it was wasn't issued
> before
> >>> >     10:00:00 .
> >>> >
> >>> >     In other words, if not-before is 10:00:00 then token issued at
> >>> >     9:59:59
> >>> >     shouldn't be valid, but token issued at 10:00:00 should be valid
> >>> IMO.
> >>> >
> >>> >     Marek
> >>> >
> >>> >     On 09/04/2019 09:21, Michal Hajas wrote:
> >>> >     > Hi,
> >>> >     >
> >>> >     > I found out that when you do logout-all (in this step
> >>> >     realm.notBefore value
> >>> >     > is set) and subsequent login very quickly it may happen that
> >>> >     Keycloak
> >>> >     > returns tokens with an issuedAt value which is the same as the
> >>> >     value of the
> >>> >     > NotBeforePolicy.
> >>> >     >
> >>> >     > Such tokens are considered invalid in adapter due to this check
> >>> [1].
> >>> >     >
> >>> >     > My question is, should we prevent such state? If yes what is
> >>> correct
> >>> >     > behavior?
> >>> >     >
> >>> >     > 1. Do not generate tokens with the same issuedAt value as
> >>> >     NotBefore policy.
> >>> >     > For example, in TokenManager [2] check NotBefore value and
> change
> >>> >     > issuedAt for all tokens to (NotBefore + 1) in case they are
> same.
> >>> >     >
> >>> >     > or
> >>> >     >
> >>> >     > 2. Change condition [2]:
> >>> >     > .... && this.token.getIssuedAt() > deployment.getNotBefore();
> >>> >     > to:
> >>> >     > .... && this.token.getIssuedAt() >= deployment.getNotBefore();
> >>> >     >
> >>> >     > The later will probably require to also check other non-java
> >>> >     adapters
> >>> >     > whether such check is present or not.
> >>> >     >
> >>> >     > Best regards,
> >>> >     > Michal
> >>> >     >
> >>> >     > [1]
> >>> >     >
> >>> >
> >>>
> https://github.com/keycloak/keycloak/blob/master/adapters/oidc/adapter-core/src/main/java/org/keycloak/adapters/RefreshableKeycloakSecurityContext.java#L79
> >>> >     >
> >>> >     > [2]
> >>> >     >
> >>> >
> >>>
> https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/protocol/oidc/TokenManager.java#L796
> >>> >     > _______________________________________________
> >>> >     > keycloak-dev mailing list
> >>> >     > keycloak-dev at lists.jboss.org <mailto:
> >>> keycloak-dev at lists.jboss.org>
> >>> >     > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>> >
> >>> >
> >>> >     _______________________________________________
> >>> >     keycloak-dev mailing list
> >>> >     keycloak-dev at lists.jboss.org <mailto:
> keycloak-dev at lists.jboss.org>
> >>> >     https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>> >
> >>>
> >>> _______________________________________________
> >>> keycloak-dev mailing list
> >>> keycloak-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>
> >>
> >>
> >
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



-- 

STEFAN GUILHEN

PRINCIPAL SOFTWARE ENGINEER

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

sguilhen at redhat.com    M: +55-11-98117-7332
<https://red.ht/sig>
@RedHat <https://twitter.com/redhat>   Red Hat
<https://www.linkedin.com/company/red-hat>   Red Hat
<https://www.facebook.com/RedHatInc>

From mhajas at redhat.com  Wed Apr 10 03:53:17 2019
From: mhajas at redhat.com (Michal Hajas)
Date: Wed, 10 Apr 2019 09:53:17 +0200
Subject: [keycloak-dev] Token's issuedAt value is the same as value of
	NotBeforePolicy
In-Reply-To: <CA+7ohfmvWNEbT=AzJDxKFG-8g6M_1DeJ+igA+iA2bdmuH7NjNg@mail.gmail.com>
References: <CACv4bCQed2ch4==L1gH2oYVzUCRazEq5Dem7OiW6Ax_KYjc7vg@mail.gmail.com>
	<8becc9a6-aabb-8bf1-c6ce-a9530a742c58@redhat.com>
	<CAJgngAdQiY2s0RkSjar+8bmVLwKh5S54Q+g0bX91+cixrXbMMQ@mail.gmail.com>
	<ee1c799c-a2a0-672b-5b14-e6204aab5e12@redhat.com>
	<CAMvXD=H08BZuthGNo3od=F2b6ssfUurDZKV8+L4eM1NE4H5PXA@mail.gmail.com>
	<939c2710-c281-37db-1a03-605688650c3b@redhat.com>
	<CAJgngAc-6hPiwTRm1__LQ9HM7n48JZwLvKEcSvAPGE=wkEGvGg@mail.gmail.com>
	<3bc91c26-c7bc-2ded-feb3-a1d57fffc96b@redhat.com>
	<CAMvXD=Hh+XvUc1EGmmVHG005G-RuQ6c2EgN2_7-YdRMO1ztt1g@mail.gmail.com>
	<CA+7ohfmvWNEbT=AzJDxKFG-8g6M_1DeJ+igA+iA2bdmuH7NjNg@mail.gmail.com>
Message-ID: <CACv4bCR=+69v36LmzmKKNam-SXg==Fa=q3Dvzb24i+aVJqL3WQ@mail.gmail.com>

I agree with Hynek too, I think it is not a big effort to make it
configurable (defaulting to 0/1), however, it makes sense for an
administrator to have this possibility.

I introduced an issue for this:
https://issues.jboss.org/browse/KEYCLOAK-10021 feel free to update or
comment.

FYI: I introduced also https://issues.jboss.org/browse/KEYCLOAK-10013 which
will be fixed ASAP as I am blocked by this with stabilization of Spring
Boot tests.

Michal

On Tue, Apr 9, 2019 at 7:23 PM Stefan Guilhen <sguilhen at redhat.com> wrote:

> Agree with Hynek on this one. I'm also not convinced about the default
> value of 1 and I really believe the skew should be configurable.
>
> On Tue, Apr 9, 2019 at 1:08 PM Hynek Mlnarik <hmlnarik at redhat.com> wrote:
>
> > -1
> >
> > This should be administrator's known decision, based on their knowledge
> of
> > how much precise they need.
> >
> > See e.g. [1]: "Tolerances of 3?5 minutes are a reasonable default, but
> > allowing for configurability is a suggested practice."
> >
> > We can add a default of 1 second (not convinced about that either, IMO
> the
> > default should be 0 since it already works for the most deployments in
> the
> > wild) but the value has to be configurable, even if in a fine-grained
> > configuration.
> >
> > [1]
> >
> >
> https://docs.kantarainitiative.org/fi/rec-saml2-implementation-profile-for-fedinterop.html
> >
> > On Tue, Apr 9, 2019 at 4:38 PM Marek Posolda <mposolda at redhat.com>
> wrote:
> >
> > > +1
> > >
> > > We can revisit later if more fine-grained clock skew configuration is
> > > needed.
> > >
> > > Marek
> > >
> > > On 09/04/2019 16:14, Stian Thorgersen wrote:
> > >
> > > I wonder if we could just set it to 1 sec and not make it configurable?
> > >
> > > On Tue, 9 Apr 2019 at 15:42, Marek Posolda <mposolda at redhat.com>
> wrote:
> > >
> > >> Ah, ok. Forgot that we already added such option to identity
> providers,
> > >> so seems that people really have issues on servers too. +1 for add the
> > >> option then.
> > >>
> > >> Thanks,
> > >> Marek
> > >>
> > >>
> > >> On 09/04/2019 15:38, Hynek Mlnarik wrote:
> > >>
> > >> Clock time skew was asked for in SAML adapter [1] (number of watchers
> is
> > >> 6), mostly because inability to sync the clocks up to millisecond
> > precision
> > >>
> > >> I am in favor of including this option. We should support the
> > >> configuration both in adapters and in identity provider configuration
> > >> (these bits can be provided separately).
> > >>
> > >> [1] https://issues.jboss.org/browse/KEYCLOAK-8104
> > >>
> > >> On Tue, Apr 9, 2019 at 3:31 PM Marek Posolda <mposolda at redhat.com>
> > wrote:
> > >>
> > >>> On 09/04/2019 13:53, Stian Thorgersen wrote:
> > >>> > Not before should be reject tokens before that time, so changing to
> > >>> > the following as suggested would be the correct behaviour:
> > >>> >
> > >>> > this.token.getIssuedAt() >= deployment.getNotBefore
> > >>> >
> > >>> > Further, all adapters should allow a configurable allowed time sync
> > >>> > here. We should introduce a new property allowedTimeSkew with
> default
> > >>> > set to 1 second. The above would then be changed to:
> > >>> >
> > >>> > this.token.getIssuedAt() >= deployment.getNotBefore() -
> > >>> > deployment.getAllowedTimeSkew()
> > >>>
> > >>> That's the question whether we need another configuration option?
> Can't
> > >>> recall if someone asks for this? And we have lots of switches already
> > :)
> > >>>
> > >>> I see the point in having clock skew in keycloak.js, which is
> executed
> > >>> on user's machines and there is quite high chance of having time
> > >>> slightly out of sync. On the other hand, java adapter is mostly
> > executed
> > >>> on servers where apps are deployed and server administrators usually
> > pay
> > >>> attention to have time in sync to avoid various issues?
> > >>>
> > >>> Marek
> > >>>
> > >>> >
> > >>> > On Tue, 9 Apr 2019 at 13:50, Marek Posolda <mposolda at redhat.com
> > >>> > <mailto:mposolda at redhat.com>> wrote:
> > >>> >
> > >>> >     My vote is to go with (2). It may turn to be more work as it
> > needs
> > >>> to
> > >>> >     check all the adapters (node.js, maybe also gatekeeper etc).
> > >>> >
> > >>> >     But strictly said, if not-before is set for example to 10:0000,
> > >>> >     then my
> > >>> >     understanding of not-before semantics is to check that: token
> is
> > >>> >     valid
> > >>> >     if it was issued not before 10:00:00 .
> > >>> >     Which translates to: token is valid if it was wasn't issued
> > before
> > >>> >     10:00:00 .
> > >>> >
> > >>> >     In other words, if not-before is 10:00:00 then token issued at
> > >>> >     9:59:59
> > >>> >     shouldn't be valid, but token issued at 10:00:00 should be
> valid
> > >>> IMO.
> > >>> >
> > >>> >     Marek
> > >>> >
> > >>> >     On 09/04/2019 09:21, Michal Hajas wrote:
> > >>> >     > Hi,
> > >>> >     >
> > >>> >     > I found out that when you do logout-all (in this step
> > >>> >     realm.notBefore value
> > >>> >     > is set) and subsequent login very quickly it may happen that
> > >>> >     Keycloak
> > >>> >     > returns tokens with an issuedAt value which is the same as
> the
> > >>> >     value of the
> > >>> >     > NotBeforePolicy.
> > >>> >     >
> > >>> >     > Such tokens are considered invalid in adapter due to this
> check
> > >>> [1].
> > >>> >     >
> > >>> >     > My question is, should we prevent such state? If yes what is
> > >>> correct
> > >>> >     > behavior?
> > >>> >     >
> > >>> >     > 1. Do not generate tokens with the same issuedAt value as
> > >>> >     NotBefore policy.
> > >>> >     > For example, in TokenManager [2] check NotBefore value and
> > change
> > >>> >     > issuedAt for all tokens to (NotBefore + 1) in case they are
> > same.
> > >>> >     >
> > >>> >     > or
> > >>> >     >
> > >>> >     > 2. Change condition [2]:
> > >>> >     > .... && this.token.getIssuedAt() > deployment.getNotBefore();
> > >>> >     > to:
> > >>> >     > .... && this.token.getIssuedAt() >=
> deployment.getNotBefore();
> > >>> >     >
> > >>> >     > The later will probably require to also check other non-java
> > >>> >     adapters
> > >>> >     > whether such check is present or not.
> > >>> >     >
> > >>> >     > Best regards,
> > >>> >     > Michal
> > >>> >     >
> > >>> >     > [1]
> > >>> >     >
> > >>> >
> > >>>
> >
> https://github.com/keycloak/keycloak/blob/master/adapters/oidc/adapter-core/src/main/java/org/keycloak/adapters/RefreshableKeycloakSecurityContext.java#L79
> > >>> >     >
> > >>> >     > [2]
> > >>> >     >
> > >>> >
> > >>>
> >
> https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/protocol/oidc/TokenManager.java#L796
> > >>> >     > _______________________________________________
> > >>> >     > keycloak-dev mailing list
> > >>> >     > keycloak-dev at lists.jboss.org <mailto:
> > >>> keycloak-dev at lists.jboss.org>
> > >>> >     > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > >>> >
> > >>> >
> > >>> >     _______________________________________________
> > >>> >     keycloak-dev mailing list
> > >>> >     keycloak-dev at lists.jboss.org <mailto:
> > keycloak-dev at lists.jboss.org>
> > >>> >     https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > >>> >
> > >>>
> > >>> _______________________________________________
> > >>> keycloak-dev mailing list
> > >>> keycloak-dev at lists.jboss.org
> > >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > >>>
> > >>
> > >>
> > >
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
> --
>
> STEFAN GUILHEN
>
> PRINCIPAL SOFTWARE ENGINEER
>
> Red Hat <https://www.redhat.com/>
>
> sguilhen at redhat.com    M: +55-11-98117-7332
> <https://red.ht/sig>
> @RedHat <https://twitter.com/redhat>   Red Hat
> <https://www.linkedin.com/company/red-hat>   Red Hat
> <https://www.facebook.com/RedHatInc>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From yuichi.nakamura.fe at hitachi.com  Wed Apr 10 23:55:54 2019
From: yuichi.nakamura.fe at hitachi.com (=?utf-8?B?5Lit5p2R6ZuE5LiAIC8gTkFLQU1VUkHvvIxZVVVJQ0hJ?=)
Date: Thu, 11 Apr 2019 03:55:54 +0000
Subject: [keycloak-dev] Request for someone to contribute an WebAuthn4j
 extension
Message-ID: <TYAPR01MB2447049C0687F3EFE4AE4244C92F0@TYAPR01MB2447.jpnprd01.prod.outlook.com>

Hi, 

We've updated the webauthn authenticator prototype based on webauthn4j : 
https://github.com/webauthn4j/keycloak-webauthn-authenticator/tree/demo-completed

We've confirmed that this demo worked well under the following environments:
* U2F with Resident Key Not supported Authenticator Scenario
OS : Windows 10
Browser : Google Chrome (ver 73), Mozilla FireFox (ver 66)
Authenticator : Yubico Security Key
Server(RP) : keycloak-5.0.0

* U2F with Resident Key supported Authenticator Scenario
OS : Windows 10
Browser : Microsoft Edge (ver 44)
Authenticator : Internal Fingerprint Authentication Device
Server(RP) : keycloak-5.0.0

* UAF with Resident Key supported Authenticator Scenario
OS : Windows 10
Browser : Microsoft Edge (ver 44)
Authenticator : Internal Fingerprint Authentication Device
Server(RP) : keycloak-5.0.0

We will continue to improve the prototype, so feedback is welcomed.

Regards,
Yuichi Nakamura

-----Original Message-----
From: keycloak-dev-bounces at lists.jboss.org <keycloak-dev-bounces at lists.jboss.org> On Behalf Of ???? / NAKAMURA?YUUICHI
Sent: Tuesday, March 19, 2019 4:32 PM
To: stian at redhat.com
Cc: keycloak-dev <keycloak-dev at lists.jboss.org>
Subject: [!]Re: [keycloak-dev] Request for someone to contribute an WebAuthn4j extension

Hi,

Sorry, we have implemented only for Edge now.
Please wait for other browsers.

> One comment is that it shouldn't create a new table, but rather just serialize the value to the existing credential table in the same way as the FIDO U2F example does [1].
Thank you, we will fix.

Regards,
Yuichi Nakamura


From: Stian Thorgersen <sthorger at redhat.com>
Sent: Monday, March 18, 2019 5:49 PM
To: ???? / NAKAMURA?YUUICHI <yuichi.nakamura.fe at hitachi.com>
Cc: keycloak-dev <keycloak-dev at lists.jboss.org>; ???? / NORIMATSU?TAKASHI <takashi.norimatsu.ws at hitachi.com>; ???? / MOGI?TAKASHI <takashi.mogi.ep at hitachi.com>; Yoshikazu Nojima <mail at ynojima.net>
Subject: [!]Re: [keycloak-dev] Request for someone to contribute an WebAuthn4j extension

Tried this out today and it didn't work for me. I was getting some JS error both on Chrome and Firefox when trying to register authenticator.?

One comment is that it shouldn't create a new table, but rather just serialize the value to the existing credential table in the same way as the FIDO U2F example does [1].?

[1]?https://clicktime.symantec.com/3XYorxFfnwRutc8N4z3Ubc77Vc?u=https%3A%2F%2Fgithub.com%2Fstianst%2Fkeycloak-experimental%2Ftree%2Fmaster%2Ffido-u2f

On Fri, 15 Mar 2019 at 08:13, ???? / NAKAMURA?YUUICHI <mailto:yuichi.nakamura.fe at hitachi.com> wrote:
Hi, 

We?ve uploaded the initial prototype of webauthn authenticator below: https://clicktime.symantec.com/37NWG7BAMWtR42Swt5VUTw77Vc?u=https%3A%2F%2Fgithub.com%2Fwebauthn4j%2Fkeycloak-webauthn-authenticator

Feedback is welcomed.

From: Stian Thorgersen <mailto:sthorger at redhat.com>
Sent: Thursday, February 28, 2019 6:53 PM
To: ???? / NAKAMURA?YUUICHI <mailto:yuichi.nakamura.fe at hitachi.com>
Cc: keycloak-dev <mailto:keycloak-dev at lists.jboss.org>
Subject: [!]Re: [keycloak-dev] Request for someone to contribute an WebAuthn4j extension

That's great, thanks.

Do you have an idea on roughly when you can have a prototype ready?

On Thu, 28 Feb 2019 at 00:32, ???? / NAKAMURA?YUUICHI <mailto:mailto:yuichi.nakamura.fe at hitachi.com> wrote:
Hi,

My team has begun to help webauthn4j project, and is going to develop prototype of authenticator for keycloak.
We'd like to take this.

Regards,
Yuichi Nakamura
Hitachi, Ltd.

-----Original Message-----
From: mailto:mailto:keycloak-dev-bounces at lists.jboss.org <mailto:mailto:keycloak-dev-bounces at lists.jboss.org> On Behalf Of Stian Thorgersen
Sent: Thursday, February 28, 2019 12:26 AM
To: keycloak-dev <mailto:mailto:keycloak-dev at lists.jboss.org>
Subject: [!][keycloak-dev] Request for someone to contribute an WebAuthn4j extension

A while back I created an experimental extension to Keycloak for FIDO U2F.
It would be great if someone could adapt this to WebAuthn by leveraging webauthn4j library [1].

Any takers? It shouldn't be hard ;)

[1] https://clicktime.symantec.com/3DJdi8ZVRTPPRjKw5d1qT287Vc?u=https%3A%2F%2Fgithub.com%2Fwebauthn4j%2Fwebauthn4j
_______________________________________________
keycloak-dev mailing list
mailto:mailto:keycloak-dev at lists.jboss.org
https://clicktime.symantec.com/35NVx3Bd41ZVjjssocqwjpK7Vc?u=https%3A%2F%2Flists.jboss.org%2Fmailman%2Flistinfo%2Fkeycloak-dev

_______________________________________________
keycloak-dev mailing list
keycloak-dev at lists.jboss.org
https://clicktime.symantec.com/3K7AmDtC5f54UYS4NNrH1wo7Vc?u=https%3A%2F%2Flists.jboss.org%2Fmailman%2Flistinfo%2Fkeycloak-dev


From sthorger at redhat.com  Thu Apr 11 01:11:31 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 11 Apr 2019 07:11:31 +0200
Subject: [keycloak-dev] Token's issuedAt value is the same as value of
	NotBeforePolicy
In-Reply-To: <CACv4bCR=+69v36LmzmKKNam-SXg==Fa=q3Dvzb24i+aVJqL3WQ@mail.gmail.com>
References: <CACv4bCQed2ch4==L1gH2oYVzUCRazEq5Dem7OiW6Ax_KYjc7vg@mail.gmail.com>
	<8becc9a6-aabb-8bf1-c6ce-a9530a742c58@redhat.com>
	<CAJgngAdQiY2s0RkSjar+8bmVLwKh5S54Q+g0bX91+cixrXbMMQ@mail.gmail.com>
	<ee1c799c-a2a0-672b-5b14-e6204aab5e12@redhat.com>
	<CAMvXD=H08BZuthGNo3od=F2b6ssfUurDZKV8+L4eM1NE4H5PXA@mail.gmail.com>
	<939c2710-c281-37db-1a03-605688650c3b@redhat.com>
	<CAJgngAc-6hPiwTRm1__LQ9HM7n48JZwLvKEcSvAPGE=wkEGvGg@mail.gmail.com>
	<3bc91c26-c7bc-2ded-feb3-a1d57fffc96b@redhat.com>
	<CAMvXD=Hh+XvUc1EGmmVHG005G-RuQ6c2EgN2_7-YdRMO1ztt1g@mail.gmail.com>
	<CA+7ohfmvWNEbT=AzJDxKFG-8g6M_1DeJ+igA+iA2bdmuH7NjNg@mail.gmail.com>
	<CACv4bCR=+69v36LmzmKKNam-SXg==Fa=q3Dvzb24i+aVJqL3WQ@mail.gmail.com>
Message-ID: <CAJgngAc8Da5nobRsoBvs_oBtNHudtdH_J40K+DUhUdC=eMSydA@mail.gmail.com>

I was mostly throwing the idea out there as an attempt to reduce amount of
manual configuration and problem solving if someone experiences problems.

I'm mostly onboard with going for 0 and making it configurable, but still
wonder if there's some safe default other than 0 that would make this
mostly a non-issue. I can see people having some confusing afternoons
trying to debug this if they do have some small time sync issues.

On Wed, 10 Apr 2019 at 09:53, Michal Hajas <mhajas at redhat.com> wrote:

> I agree with Hynek too, I think it is not a big effort to make it
> configurable (defaulting to 0/1), however, it makes sense for an
> administrator to have this possibility.
>
> I introduced an issue for this:
> https://issues.jboss.org/browse/KEYCLOAK-10021 feel free to update or
> comment.
>
> FYI: I introduced also https://issues.jboss.org/browse/KEYCLOAK-10013 which
> will be fixed ASAP as I am blocked by this with stabilization of Spring
> Boot tests.
>
> Michal
>
> On Tue, Apr 9, 2019 at 7:23 PM Stefan Guilhen <sguilhen at redhat.com> wrote:
>
>> Agree with Hynek on this one. I'm also not convinced about the default
>> value of 1 and I really believe the skew should be configurable.
>>
>> On Tue, Apr 9, 2019 at 1:08 PM Hynek Mlnarik <hmlnarik at redhat.com> wrote:
>>
>> > -1
>> >
>> > This should be administrator's known decision, based on their knowledge
>> of
>> > how much precise they need.
>> >
>> > See e.g. [1]: "Tolerances of 3?5 minutes are a reasonable default, but
>> > allowing for configurability is a suggested practice."
>> >
>> > We can add a default of 1 second (not convinced about that either, IMO
>> the
>> > default should be 0 since it already works for the most deployments in
>> the
>> > wild) but the value has to be configurable, even if in a fine-grained
>> > configuration.
>> >
>> > [1]
>> >
>> >
>> https://docs.kantarainitiative.org/fi/rec-saml2-implementation-profile-for-fedinterop.html
>> >
>> > On Tue, Apr 9, 2019 at 4:38 PM Marek Posolda <mposolda at redhat.com>
>> wrote:
>> >
>> > > +1
>> > >
>> > > We can revisit later if more fine-grained clock skew configuration is
>> > > needed.
>> > >
>> > > Marek
>> > >
>> > > On 09/04/2019 16:14, Stian Thorgersen wrote:
>> > >
>> > > I wonder if we could just set it to 1 sec and not make it
>> configurable?
>> > >
>> > > On Tue, 9 Apr 2019 at 15:42, Marek Posolda <mposolda at redhat.com>
>> wrote:
>> > >
>> > >> Ah, ok. Forgot that we already added such option to identity
>> providers,
>> > >> so seems that people really have issues on servers too. +1 for add
>> the
>> > >> option then.
>> > >>
>> > >> Thanks,
>> > >> Marek
>> > >>
>> > >>
>> > >> On 09/04/2019 15:38, Hynek Mlnarik wrote:
>> > >>
>> > >> Clock time skew was asked for in SAML adapter [1] (number of
>> watchers is
>> > >> 6), mostly because inability to sync the clocks up to millisecond
>> > precision
>> > >>
>> > >> I am in favor of including this option. We should support the
>> > >> configuration both in adapters and in identity provider configuration
>> > >> (these bits can be provided separately).
>> > >>
>> > >> [1] https://issues.jboss.org/browse/KEYCLOAK-8104
>> > >>
>> > >> On Tue, Apr 9, 2019 at 3:31 PM Marek Posolda <mposolda at redhat.com>
>> > wrote:
>> > >>
>> > >>> On 09/04/2019 13:53, Stian Thorgersen wrote:
>> > >>> > Not before should be reject tokens before that time, so changing
>> to
>> > >>> > the following as suggested would be the correct behaviour:
>> > >>> >
>> > >>> > this.token.getIssuedAt() >= deployment.getNotBefore
>> > >>> >
>> > >>> > Further, all adapters should allow a configurable allowed time
>> sync
>> > >>> > here. We should introduce a new property allowedTimeSkew with
>> default
>> > >>> > set to 1 second. The above would then be changed to:
>> > >>> >
>> > >>> > this.token.getIssuedAt() >= deployment.getNotBefore() -
>> > >>> > deployment.getAllowedTimeSkew()
>> > >>>
>> > >>> That's the question whether we need another configuration option?
>> Can't
>> > >>> recall if someone asks for this? And we have lots of switches
>> already
>> > :)
>> > >>>
>> > >>> I see the point in having clock skew in keycloak.js, which is
>> executed
>> > >>> on user's machines and there is quite high chance of having time
>> > >>> slightly out of sync. On the other hand, java adapter is mostly
>> > executed
>> > >>> on servers where apps are deployed and server administrators usually
>> > pay
>> > >>> attention to have time in sync to avoid various issues?
>> > >>>
>> > >>> Marek
>> > >>>
>> > >>> >
>> > >>> > On Tue, 9 Apr 2019 at 13:50, Marek Posolda <mposolda at redhat.com
>> > >>> > <mailto:mposolda at redhat.com>> wrote:
>> > >>> >
>> > >>> >     My vote is to go with (2). It may turn to be more work as it
>> > needs
>> > >>> to
>> > >>> >     check all the adapters (node.js, maybe also gatekeeper etc).
>> > >>> >
>> > >>> >     But strictly said, if not-before is set for example to
>> 10:0000,
>> > >>> >     then my
>> > >>> >     understanding of not-before semantics is to check that: token
>> is
>> > >>> >     valid
>> > >>> >     if it was issued not before 10:00:00 .
>> > >>> >     Which translates to: token is valid if it was wasn't issued
>> > before
>> > >>> >     10:00:00 .
>> > >>> >
>> > >>> >     In other words, if not-before is 10:00:00 then token issued at
>> > >>> >     9:59:59
>> > >>> >     shouldn't be valid, but token issued at 10:00:00 should be
>> valid
>> > >>> IMO.
>> > >>> >
>> > >>> >     Marek
>> > >>> >
>> > >>> >     On 09/04/2019 09:21, Michal Hajas wrote:
>> > >>> >     > Hi,
>> > >>> >     >
>> > >>> >     > I found out that when you do logout-all (in this step
>> > >>> >     realm.notBefore value
>> > >>> >     > is set) and subsequent login very quickly it may happen that
>> > >>> >     Keycloak
>> > >>> >     > returns tokens with an issuedAt value which is the same as
>> the
>> > >>> >     value of the
>> > >>> >     > NotBeforePolicy.
>> > >>> >     >
>> > >>> >     > Such tokens are considered invalid in adapter due to this
>> check
>> > >>> [1].
>> > >>> >     >
>> > >>> >     > My question is, should we prevent such state? If yes what is
>> > >>> correct
>> > >>> >     > behavior?
>> > >>> >     >
>> > >>> >     > 1. Do not generate tokens with the same issuedAt value as
>> > >>> >     NotBefore policy.
>> > >>> >     > For example, in TokenManager [2] check NotBefore value and
>> > change
>> > >>> >     > issuedAt for all tokens to (NotBefore + 1) in case they are
>> > same.
>> > >>> >     >
>> > >>> >     > or
>> > >>> >     >
>> > >>> >     > 2. Change condition [2]:
>> > >>> >     > .... && this.token.getIssuedAt() >
>> deployment.getNotBefore();
>> > >>> >     > to:
>> > >>> >     > .... && this.token.getIssuedAt() >=
>> deployment.getNotBefore();
>> > >>> >     >
>> > >>> >     > The later will probably require to also check other non-java
>> > >>> >     adapters
>> > >>> >     > whether such check is present or not.
>> > >>> >     >
>> > >>> >     > Best regards,
>> > >>> >     > Michal
>> > >>> >     >
>> > >>> >     > [1]
>> > >>> >     >
>> > >>> >
>> > >>>
>> >
>> https://github.com/keycloak/keycloak/blob/master/adapters/oidc/adapter-core/src/main/java/org/keycloak/adapters/RefreshableKeycloakSecurityContext.java#L79
>> > >>> >     >
>> > >>> >     > [2]
>> > >>> >     >
>> > >>> >
>> > >>>
>> >
>> https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/protocol/oidc/TokenManager.java#L796
>> > >>> >     > _______________________________________________
>> > >>> >     > keycloak-dev mailing list
>> > >>> >     > keycloak-dev at lists.jboss.org <mailto:
>> > >>> keycloak-dev at lists.jboss.org>
>> > >>> >     > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> > >>> >
>> > >>> >
>> > >>> >     _______________________________________________
>> > >>> >     keycloak-dev mailing list
>> > >>> >     keycloak-dev at lists.jboss.org <mailto:
>> > keycloak-dev at lists.jboss.org>
>> > >>> >     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> > >>> >
>> > >>>
>> > >>> _______________________________________________
>> > >>> keycloak-dev mailing list
>> > >>> keycloak-dev at lists.jboss.org
>> > >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> > >>>
>> > >>
>> > >>
>> > >
>> > _______________________________________________
>> > keycloak-dev mailing list
>> > keycloak-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>>
>> --
>>
>> STEFAN GUILHEN
>>
>> PRINCIPAL SOFTWARE ENGINEER
>>
>> Red Hat <https://www.redhat.com/>
>>
>> sguilhen at redhat.com    M: +55-11-98117-7332
>> <https://red.ht/sig>
>> @RedHat <https://twitter.com/redhat>   Red Hat
>> <https://www.linkedin.com/company/red-hat>   Red Hat
>> <https://www.facebook.com/RedHatInc>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>

From slaskawi at redhat.com  Thu Apr 11 04:01:47 2019
From: slaskawi at redhat.com (Sebastian Laskawiec)
Date: Thu, 11 Apr 2019 10:01:47 +0200
Subject: [keycloak-dev] TCP for JGroups and bind options
Message-ID: <CAA9R9O648R6kZ=cLAeTVYqK7ziuGDFbKAihyq3eHW701CzLYKA@mail.gmail.com>

Hey,

I've been working on JGroups bind settings for Keycloak Container Image
recently and we had a discussion with Stian about changing both binding
options and transport for JGroups.

As you probably know, we use standalone-ha.xml as a default configuration
for our image. This means, that Infinispan boots up in clustered mode. At
the moment, we use the default transport from the configuration, which is
UDP (with PING as discovery).

Even though UDP transport is a bit faster for larger clusters, it often
doesn't work out of the box in cloud environments (like AWS for the
instance). Of course, the JGroups stack can easily be changed by using the
`-Djboss.default.jgroups.stack=tcp` switch.

I'm planning to revise this piece and change the default transport to TCP
(probably by adding `-Djboss.default.jgroups.stack=tcp` switch to the
default options).

I also proposed, and would like to ask you to try it out, changing the bind
parameters to match IPv4 [1]. Previously, JGroups tried to bind to wrong
interfaces, including `fe80::5003:8eff:fefa:3e53%tap0` exposed by Podman.

Please have a look at the Pull Request [1], check if it works for you and
let me know what you think about using TCP as default transport for JGroups.

Thanks,
Sebastian

[1] https://github.com/jboss-dockerfiles/keycloak/pull/186

From Sebastian.Schuster at bosch-si.com  Thu Apr 11 06:53:24 2019
From: Sebastian.Schuster at bosch-si.com (Schuster Sebastian (INST-CSS/BSV-OS2))
Date: Thu, 11 Apr 2019 10:53:24 +0000
Subject: [keycloak-dev] TCP for JGroups and bind options
In-Reply-To: <CAA9R9O648R6kZ=cLAeTVYqK7ziuGDFbKAihyq3eHW701CzLYKA@mail.gmail.com>
References: <CAA9R9O648R6kZ=cLAeTVYqK7ziuGDFbKAihyq3eHW701CzLYKA@mail.gmail.com>
Message-ID: <04337e00eaf044e089630c6ef4d5a5e2@bosch-si.com>

Hi Sebastian,

I think going with TCP is fine. Looking at the PR, I am not sure using hostname -i to find the local IP address is a good idea. Looking at the man page:
       -i, --ip-address
              Display the network address(es) of the host name. Note that this works only if the host name can be resolved. Avoid using this option; use hostname --all-ip-addresses instead.
while:
       -I, --all-ip-addresses
              Display all network addresses of the host. This option enumerates all configured addresses on all network interfaces. The loopback interface and IPv6 link-local addresses are omitted. Contrary to option -i, this
              option does not depend on name resolution. Do not make any assumptions about the order of the output.

I can imagine the second option might be more suitable, since it does not depend on DNS and you want to exclude loopback interfaces anyways?

Best regards,
Sebastian

Mit freundlichen Gr??en / Best regards

Dr.-Ing. Sebastian Schuster

Open Source Services (INST-CSS/BSV-OS2) 
Bosch?Software Innovations?GmbH | Ullsteinstr. 128 | 12109 Berlin | GERMANY | www.bosch-si.com
Tel. +49 30 726112-485 | Mobil +49 152 02177668 | Fax +49 30 726112-100 | Sebastian.Schuster at bosch-si.com

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




-----Urspr?ngliche Nachricht-----
Von: keycloak-dev-bounces at lists.jboss.org <keycloak-dev-bounces at lists.jboss.org> Im Auftrag von Sebastian Laskawiec
Gesendet: Donnerstag, 11. April 2019 10:02
An: keycloak-dev <keycloak-dev at lists.jboss.org>
Betreff: [keycloak-dev] TCP for JGroups and bind options

Hey,

I've been working on JGroups bind settings for Keycloak Container Image recently and we had a discussion with Stian about changing both binding options and transport for JGroups.

As you probably know, we use standalone-ha.xml as a default configuration for our image. This means, that Infinispan boots up in clustered mode. At the moment, we use the default transport from the configuration, which is UDP (with PING as discovery).

Even though UDP transport is a bit faster for larger clusters, it often doesn't work out of the box in cloud environments (like AWS for the instance). Of course, the JGroups stack can easily be changed by using the `-Djboss.default.jgroups.stack=tcp` switch.

I'm planning to revise this piece and change the default transport to TCP (probably by adding `-Djboss.default.jgroups.stack=tcp` switch to the default options).

I also proposed, and would like to ask you to try it out, changing the bind parameters to match IPv4 [1]. Previously, JGroups tried to bind to wrong interfaces, including `fe80::5003:8eff:fefa:3e53%tap0` exposed by Podman.

Please have a look at the Pull Request [1], check if it works for you and let me know what you think about using TCP as default transport for JGroups.

Thanks,
Sebastian

[1] https://github.com/jboss-dockerfiles/keycloak/pull/186
_______________________________________________
keycloak-dev mailing list
keycloak-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev


From slaskawi at redhat.com  Thu Apr 11 07:55:07 2019
From: slaskawi at redhat.com (Sebastian Laskawiec)
Date: Thu, 11 Apr 2019 13:55:07 +0200
Subject: [keycloak-dev] TCP for JGroups and bind options
In-Reply-To: <04337e00eaf044e089630c6ef4d5a5e2@bosch-si.com>
References: <CAA9R9O648R6kZ=cLAeTVYqK7ziuGDFbKAihyq3eHW701CzLYKA@mail.gmail.com>
	<04337e00eaf044e089630c6ef4d5a5e2@bosch-si.com>
Message-ID: <CAA9R9O7ug5FoXAAcS1GcxAUMoT6q=r_2rCszVBrzaKxJ6bBCZw@mail.gmail.com>

Hey Sebastian,

That's a very good idea actually!

I managed to test it out on Podman and here are the results:
$ hostname --all-ip-addresses
10.0.2.100 <-- This is exactly what we want!
$ hostname -i
fe80::2471:fff:fe12:682c%tap0 10.0.2.100 <-- This one requires filtering

Let me test it a bit more, but I guess, that's a step in good direction
(and this will simplify some code too). Thank you Sebastian!

Thanks,
Sebastian



On Thu, Apr 11, 2019 at 12:53 PM Schuster Sebastian (INST-CSS/BSV-OS2) <
Sebastian.Schuster at bosch-si.com> wrote:

> Hi Sebastian,
>
> I think going with TCP is fine. Looking at the PR, I am not sure using
> hostname -i to find the local IP address is a good idea. Looking at the man
> page:
>        -i, --ip-address
>               Display the network address(es) of the host name. Note that
> this works only if the host name can be resolved. Avoid using this option;
> use hostname --all-ip-addresses instead.
> while:
>        -I, --all-ip-addresses
>               Display all network addresses of the host. This option
> enumerates all configured addresses on all network interfaces. The loopback
> interface and IPv6 link-local addresses are omitted. Contrary to option -i,
> this
>               option does not depend on name resolution. Do not make any
> assumptions about the order of the output.
>
> I can imagine the second option might be more suitable, since it does not
> depend on DNS and you want to exclude loopback interfaces anyways?
>
> Best regards,
> Sebastian
>
> Mit freundlichen Gr??en / Best regards
>
> Dr.-Ing. Sebastian Schuster
>
> Open Source Services (INST-CSS/BSV-OS2)
> Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin |
> GERMANY | www.bosch-si.com
> Tel. +49 30 726112-485 | Mobil +49 152 02177668 | Fax +49 30 726112-100 |
> Sebastian.Schuster at bosch-si.com
>
> Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
> Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten L?cke; Gesch?ftsf?hrung: Dr.
> Stefan Ferber, Michael Hahn, Dr. Aleksandar Mitrovic
>
>
>
>
> -----Urspr?ngliche Nachricht-----
> Von: keycloak-dev-bounces at lists.jboss.org <
> keycloak-dev-bounces at lists.jboss.org> Im Auftrag von Sebastian Laskawiec
> Gesendet: Donnerstag, 11. April 2019 10:02
> An: keycloak-dev <keycloak-dev at lists.jboss.org>
> Betreff: [keycloak-dev] TCP for JGroups and bind options
>
> Hey,
>
> I've been working on JGroups bind settings for Keycloak Container Image
> recently and we had a discussion with Stian about changing both binding
> options and transport for JGroups.
>
> As you probably know, we use standalone-ha.xml as a default configuration
> for our image. This means, that Infinispan boots up in clustered mode. At
> the moment, we use the default transport from the configuration, which is
> UDP (with PING as discovery).
>
> Even though UDP transport is a bit faster for larger clusters, it often
> doesn't work out of the box in cloud environments (like AWS for the
> instance). Of course, the JGroups stack can easily be changed by using the
> `-Djboss.default.jgroups.stack=tcp` switch.
>
> I'm planning to revise this piece and change the default transport to TCP
> (probably by adding `-Djboss.default.jgroups.stack=tcp` switch to the
> default options).
>
> I also proposed, and would like to ask you to try it out, changing the
> bind parameters to match IPv4 [1]. Previously, JGroups tried to bind to
> wrong interfaces, including `fe80::5003:8eff:fefa:3e53%tap0` exposed by
> Podman.
>
> Please have a look at the Pull Request [1], check if it works for you and
> let me know what you think about using TCP as default transport for JGroups.
>
> Thanks,
> Sebastian
>
> [1] https://github.com/jboss-dockerfiles/keycloak/pull/186
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From adurot.pro at gmail.com  Thu Apr 11 13:15:31 2019
From: adurot.pro at gmail.com (Anthony Durot)
Date: Thu, 11 Apr 2019 19:15:31 +0200
Subject: [keycloak-dev] Connect Keycloak to Galera cluster with Docker
Message-ID: <CAG764zRmq-oqYFvVRf1ThKTK+EV2ZSNj1Hy4Sw5yNvK68fKFVg@mail.gmail.com>

Hi everyone,

I need to connect a Keycloak container to a MariaDB Galera cluster for a
project.
Currently, with the Docker image you can set up environment variables such
as DB_VENDOR, DB_ADDR, DB_PORT, and so on..., and these environment
variables will be added to the connection string of mariaDB.

This is done in [1]:

/subsystem=datasources/data-source=KeycloakDS:
add(jndi-name=java:jboss/datasources/KeycloakDS,enabled=true,use-java-context=true,use-ccm=true,
connection-url=jdbc:mariadb://*${env.DB_ADDR:mariadb}*:*${env.DB_PORT:3306}*
/*${env.DB_DATABASE:keycloak}${env.JDBC_PARAMS:*}, driver-name=mariadb)

As you can see, we put environment variables for the address, port,
database, and so on... But what if I want to connect Keycloak to a cluster
for exemple ?
MariaDB provides a JDBC with this connection string :
jdbc:(mysql|mariadb):[replication:|failover:|sequential:|aurora:]//<hostDescription>[,<hostDescription>...]/[database][?<key1>=<value1>[&<key2>=<value2>]

As you can see, we need to put multiple hostDescription, and currently
it's impossible because we only have a single env.DB_ADDR.
Moreover, when you want to be connected to a cluster, you need to
specify *[replication:|failover:|sequential:|aurora:] *and it's also
currently impossible to do it.

I suggest that maybe we can change [1]
... /subsystem=datasources/data-source=KeycloakDS:add(jndi-name=java:jboss/datasources/KeycloakDS,enabled=true,use-java-context=true,use-ccm=true,
    connection-url=jdbc:mariadb://*${env.DB_ADDR:mariadb}*:*${env.DB_PORT:3306}*/*${env.DB_DATABASE:keycloak}${env.JDBC_PARAMS:*},
driver-name=mariadb)

to:

... /subsystem=datasources/data-source=KeycloakDS:add(jndi-name=java:jboss/datasources/KeycloakDS,enabled=true,use-java-context=true,use-ccm=true,
    connection-url=jdbc:mariadb:*${env.DB_CONNECTION_TYPE:}*//${env.DB_ADDR:mariadb}:${env.DB_PORT:3306}/${env.DB_DATABASE:keycloak}${env.JDBC_PARAMS:},
driver-name=mariadb)


As for the list of host connection, I admit that I don't have any
clever ideas, do you have any suggestion ?

Thank you all for your time

Best regards,
Anthony


[1]
https://github.com/jboss-dockerfiles/keycloak/tree/master/server/tools/cli/databases/mariadb

From shiva.prasad.thagadur.prakash at ericsson.com  Fri Apr 12 02:59:57 2019
From: shiva.prasad.thagadur.prakash at ericsson.com (Shiva Prasad Thagadur Prakash)
Date: Fri, 12 Apr 2019 06:59:57 +0000
Subject: [keycloak-dev] Few Admin events not getting raised
Message-ID: <1554452424.17045.13.camel@ericsson.com>

Hi Guys,

We see that few admin events are not getting logged to syslog/logfile.
Creating scope, Creating New policy for a client and Creating new
permission for a client. COuld anyone please help us?

Steps to reproduce:
New permisson event
? ? 1. Create new client f.i. in master realm
? ? 2. Set "Authorization Enabled"
? ? 3. Go to clients->clientName->Authorization ->Permissions - Scope
based
? ? 4. Create New permission

Failed Symptoms: No any events generated.

? ? 1. Create new client f.i. in master realm
? ? 2. Set "Authorization Enabled"
????Go to clients->clientName->Authorization ->Policies - Create
POlicy??-> Role
? ? 3. Create New policy

Failed Symptoms: No any events generated.


? ? 1. Create new client f.i. in master realm
? ? 2. Set "Authorization Enabled"
? ? 3. Go to clients->clientName->Authorization ->Authorization Scopes
? ? 4. Create New scope event_scope
Failed Symptoms:?No any events generated.

Thanks & regards,
Shiva


From mposolda at redhat.com  Fri Apr 12 03:59:15 2019
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 12 Apr 2019 09:59:15 +0200
Subject: [keycloak-dev] Few Admin events not getting raised
In-Reply-To: <1554452424.17045.13.camel@ericsson.com>
References: <1554452424.17045.13.camel@ericsson.com>
Message-ID: <56726752-7533-d460-e3dd-83760fc557c9@redhat.com>

Someone recently mentioned this issue already. Looks lilke a bug to me.

As first step, I suggest to check if there is existing JIRA. If not, 
feel free to create one. Contribution and PR will be good as I am not 
sure we have time to fix this in near future by ourselves.

Marek

On 12/04/2019 08:59, Shiva Prasad Thagadur Prakash wrote:
> Hi Guys,
>
> We see that few admin events are not getting logged to syslog/logfile.
> Creating scope, Creating New policy for a client and Creating new
> permission for a client. COuld anyone please help us?
>
> Steps to reproduce:
> New permisson event
>  ? ? 1. Create new client f.i. in master realm
>  ? ? 2. Set "Authorization Enabled"
>  ? ? 3. Go to clients->clientName->Authorization ->Permissions - Scope
> based
>  ? ? 4. Create New permission
>
> Failed Symptoms: No any events generated.
>
>  ? ? 1. Create new client f.i. in master realm
>  ? ? 2. Set "Authorization Enabled"
>  ????Go to clients->clientName->Authorization ->Policies - Create
> POlicy??-> Role
>  ? ? 3. Create New policy
>
> Failed Symptoms: No any events generated.
>
>
>  ? ? 1. Create new client f.i. in master realm
>  ? ? 2. Set "Authorization Enabled"
>  ? ? 3. Go to clients->clientName->Authorization ->Authorization Scopes
>  ? ? 4. Create New scope event_scope
> Failed Symptoms:?No any events generated.
>
> Thanks & regards,
> Shiva
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



From abhi.raghav007 at gmail.com  Fri Apr 12 04:20:48 2019
From: abhi.raghav007 at gmail.com (abhishek raghav)
Date: Fri, 12 Apr 2019 13:50:48 +0530
Subject: [keycloak-dev] Custom account provider not working after upgrading
	to 4.8.3.Final
Message-ID: <CAJmz6fvUigkOygUb0XsHtfVJXbe6vxz4dY6AjfAJLoLbKvwKFQ@mail.gmail.com>

Hi -

We have implemented a custom account provider which
implements AccountProviderFactory and the implementation class
extends FreeMarkerAccountProvider. It is packaged and deployed as a
provider with a service definition file.

This used to be work in keycloak 3.4.3.Final but not after we upgrade to
keycloak 4.8.3.Final.

We also identified that the provider is not even registering/initialized
during boot time of keycloak. Could somebody please tell - whether keycloak
has removed support of extending Account provider SPI. Or there is any
other way to extend the account provider in keycloak 4.8.3.Final.

Any help is greatly appreciated.

Thanks
-Abhishek

From ssilvert at redhat.com  Fri Apr 12 08:05:51 2019
From: ssilvert at redhat.com (Stan Silvert)
Date: Fri, 12 Apr 2019 08:05:51 -0400
Subject: [keycloak-dev] F2F Van from Brno to Vienna?
Message-ID: <14dfce50-d747-af7c-2be6-11d10e7b623c@redhat.com>

It sounds like several of us will be flying in and out of Vienna for the 
F2F.

It's really not very convenient to take the bus on Thursday evening to 
Vienna.? We would need to wrap up a little early at the office and then 
make the trip down to the bus stop.

Would it make sense to hire a van to take us all to the hotel at the 
Vienna airport on Thursday night?? Then we could leave directly from the 
office whenever we want.

Is that practical and how many would be interested?

Stan


From ssilvert at redhat.com  Fri Apr 12 08:06:38 2019
From: ssilvert at redhat.com (Stan Silvert)
Date: Fri, 12 Apr 2019 08:06:38 -0400
Subject: [keycloak-dev] F2F Van from Brno to Vienna?
In-Reply-To: <14dfce50-d747-af7c-2be6-11d10e7b623c@redhat.com>
References: <14dfce50-d747-af7c-2be6-11d10e7b623c@redhat.com>
Message-ID: <c327d9d3-f89d-f8cb-ef4d-87d53ae7b8bd@redhat.com>

On 4/12/2019 8:05 AM, Stan Silvert wrote:
> It sounds like several of us will be flying in and out of Vienna for 
> the F2F.
>
> It's really not very convenient to take the bus on Thursday evening to 
> Vienna.? We would need to wrap up a little early at the office and 
> then make the trip down to the bus stop.
>
> Would it make sense to hire a van to take us all to the hotel at the 
> Vienna airport on Thursday night?? Then we could leave directly from 
> the office whenever we want.
>
> Is that practical and how many would be interested?
>
> Stan 

Sent to wrong list.? Please ignore.


From me at serl.it  Sat Apr 13 06:18:45 2019
From: me at serl.it (Sergio Livi)
Date: Sat, 13 Apr 2019 12:18:45 +0200
Subject: [keycloak-dev] JavaScript client adapter - minValidity
Message-ID: <CAA3gSCyNFZ2FoC9kgOGmtgg=AWAKznqN4JDSDssQY7J6uzGgsw@mail.gmail.com>

Hello,
I've had a little issue while using the updateToken function[1]. In
particular, I was accidentally passing a string not containing a number as
minValidity.

Totally my fault, but the result is that no error is thrown and everything
seems to work, but the token will be never renewed.
This is the end of the function isTokenExpired, called from updateToken:

if (minValidity) {
    expiresIn -= minValidity;
    // expiresIn becomes NaN, as minValidity is not "cast-able" to a number
}
return expiresIn < 0; // NaN < 0 is false, so the token will be never
refreshed

I think there should be a check somewhere to either:
- throw an error, or
- display a warning on the console, ignore the buggy minValidity and carry
on.

If you wish, I could prepare a PR with a fix for this, just tell me which
option you prefer.

Thanks!


[1] this one: <
https://github.com/keycloak/keycloak/blob/e7deb77725a1c777902096e1880911c10f580d50/adapters/oidc/js/src/main/resources/keycloak.js#L439
>

From bruno at abstractj.org  Sat Apr 13 21:02:31 2019
From: bruno at abstractj.org (Bruno Oliveira)
Date: Sat, 13 Apr 2019 22:02:31 -0300
Subject: [keycloak-dev] JavaScript client adapter - minValidity
In-Reply-To: <CAA3gSCyNFZ2FoC9kgOGmtgg=AWAKznqN4JDSDssQY7J6uzGgsw@mail.gmail.com>
References: <CAA3gSCyNFZ2FoC9kgOGmtgg=AWAKznqN4JDSDssQY7J6uzGgsw@mail.gmail.com>
Message-ID: <CAM5SUC4BwCRPy0=X8kaN43zosej8AO55riwnhnNMsp9oVMwjbw@mail.gmail.com>

Hi Sergio, could you please file a Jira with the steps to reproduce the
problem?

Also, feel free to attach the PR into the comments.

Thank you

On Sat, Apr 13, 2019, 7:19 AM Sergio Livi <me at serl.it> wrote:

> Hello,
> I've had a little issue while using the updateToken function[1]. In
> particular, I was accidentally passing a string not containing a number as
> minValidity.
>
> Totally my fault, but the result is that no error is thrown and everything
> seems to work, but the token will be never renewed.
> This is the end of the function isTokenExpired, called from updateToken:
>
> if (minValidity) {
>     expiresIn -= minValidity;
>     // expiresIn becomes NaN, as minValidity is not "cast-able" to a number
> }
> return expiresIn < 0; // NaN < 0 is false, so the token will be never
> refreshed
>
> I think there should be a check somewhere to either:
> - throw an error, or
> - display a warning on the console, ignore the buggy minValidity and carry
> on.
>
> If you wish, I could prepare a PR with a fix for this, just tell me which
> option you prefer.
>
> Thanks!
>
>
> [1] this one: <
>
> https://github.com/keycloak/keycloak/blob/e7deb77725a1c777902096e1880911c10f580d50/adapters/oidc/js/src/main/resources/keycloak.js#L439
> >
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From luke at code-house.org  Mon Apr 15 03:54:53 2019
From: luke at code-house.org (luke at code-house.org)
Date: Mon, 15 Apr 2019 09:54:53 +0200
Subject: [keycloak-dev] Custom account provider not working after
 upgrading to 4.8.3.Final
In-Reply-To: <CAJmz6fvUigkOygUb0XsHtfVJXbe6vxz4dY6AjfAJLoLbKvwKFQ@mail.gmail.com>
References: <CAJmz6fvUigkOygUb0XsHtfVJXbe6vxz4dY6AjfAJLoLbKvwKFQ@mail.gmail.com>
Message-ID: <A515A35F-B215-456C-B2EA-4A654E5F7A70@code-house.org>

How did you package your extension - as jboss module or regular JAR with jboss-deployment-descriptor.xml ?

I did lately similar exercise with 4.8.3 and login forms. You need to modify standalone.xml and set your provider as primary one while disabling default one:

            <spi name=?account">
                <default-provider>my-custom-provider</default-provider>
                <provider name="my-custom-provider" enabled="true"/>
                <provider name="freemarker" enabled="false"/>
            </spi>

My extension is packaged as JBoss module and registered via providers configuration:
        <subsystem xmlns="urn:jboss:domain:keycloak-server:1.1">
            <web-context>ROOT</web-context>
            <providers>
                <provider>
                    module:org.code-house.keycloak.login
                </provider>
               <!-- .... etc -->


You can also try to drop your JAR (if not packaged as module) to ${keycloak.home}/providers directory.

Kind regards,
?ukasz
?
Code-House
http://code-house.org <http://code-house.org/>

> On 12 Apr 2019, at 10:20, abhishek raghav <abhi.raghav007 at gmail.com> wrote:
> 
> Hi -
> 
> We have implemented a custom account provider which
> implements AccountProviderFactory and the implementation class
> extends FreeMarkerAccountProvider. It is packaged and deployed as a
> provider with a service definition file.
> 
> This used to be work in keycloak 3.4.3.Final but not after we upgrade to
> keycloak 4.8.3.Final.
> 
> We also identified that the provider is not even registering/initialized
> during boot time of keycloak. Could somebody please tell - whether keycloak
> has removed support of extending Account provider SPI. Or there is any
> other way to extend the account provider in keycloak 4.8.3.Final.
> 
> Any help is greatly appreciated.
> 
> Thanks
> -Abhishek
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From me at serl.it  Mon Apr 15 08:03:22 2019
From: me at serl.it (Sergio Livi)
Date: Mon, 15 Apr 2019 14:03:22 +0200
Subject: [keycloak-dev] JavaScript client adapter - minValidity
In-Reply-To: <CAM5SUC4BwCRPy0=X8kaN43zosej8AO55riwnhnNMsp9oVMwjbw@mail.gmail.com>
References: <CAA3gSCyNFZ2FoC9kgOGmtgg=AWAKznqN4JDSDssQY7J6uzGgsw@mail.gmail.com>
	<CAM5SUC4BwCRPy0=X8kaN43zosej8AO55riwnhnNMsp9oVMwjbw@mail.gmail.com>
Message-ID: <CAA3gSCwCF3fUXZ0D+2qANQNrG8PLZvfAQdQFhPgxAni3CEGCGQ@mail.gmail.com>

Done: KEYCLOAK-10071!
Let me know if I missed anything.

Thanks!


On Sun, Apr 14, 2019 at 3:02 AM Bruno Oliveira <bruno at abstractj.org> wrote:

> Hi Sergio, could you please file a Jira with the steps to reproduce the
> problem?
>
> Also, feel free to attach the PR into the comments.
>
> Thank you
>
> On Sat, Apr 13, 2019, 7:19 AM Sergio Livi <me at serl.it> wrote:
>
>> Hello,
>> I've had a little issue while using the updateToken function[1]. In
>> particular, I was accidentally passing a string not containing a number as
>> minValidity.
>>
>> Totally my fault, but the result is that no error is thrown and everything
>> seems to work, but the token will be never renewed.
>> This is the end of the function isTokenExpired, called from updateToken:
>>
>> if (minValidity) {
>>     expiresIn -= minValidity;
>>     // expiresIn becomes NaN, as minValidity is not "cast-able" to a
>> number
>> }
>> return expiresIn < 0; // NaN < 0 is false, so the token will be never
>> refreshed
>>
>> I think there should be a check somewhere to either:
>> - throw an error, or
>> - display a warning on the console, ignore the buggy minValidity and carry
>> on.
>>
>> If you wish, I could prepare a PR with a fix for this, just tell me which
>> option you prefer.
>>
>> Thanks!
>>
>>
>> [1] this one: <
>>
>> https://github.com/keycloak/keycloak/blob/e7deb77725a1c777902096e1880911c10f580d50/adapters/oidc/js/src/main/resources/keycloak.js#L439
>> >
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>

From abhi.raghav007 at gmail.com  Mon Apr 15 08:21:03 2019
From: abhi.raghav007 at gmail.com (abhishek raghav)
Date: Mon, 15 Apr 2019 17:51:03 +0530
Subject: [keycloak-dev] Custom account provider not working after
 upgrading to 4.8.3.Final
In-Reply-To: <A515A35F-B215-456C-B2EA-4A654E5F7A70@code-house.org>
References: <CAJmz6fvUigkOygUb0XsHtfVJXbe6vxz4dY6AjfAJLoLbKvwKFQ@mail.gmail.com>
	<A515A35F-B215-456C-B2EA-4A654E5F7A70@code-house.org>
Message-ID: <CAJmz6fvXy7bHZd+twgozxPOfKszbCh1zZ9ugBmKegFaDkT7tmQ@mail.gmail.com>

Hi ?ukasz,

Wow, you just saved me a lot of time. On point answer.

We are packaging the provider as a regular jar and dropping it in
${keycloak.home}/providers directory. I tried your way of modifying
standalone.xml file just as you suggested and it worked like charm.

Now we are able to see all the overridden features in the account section.

Thank you so much. :)

*Regards*
Abhishek








On Mon, Apr 15, 2019 at 1:24 PM <luke at code-house.org> wrote:

> How did you package your extension - as jboss module or regular JAR with
> jboss-deployment-descriptor.xml ?
>
> I did lately similar exercise with 4.8.3 and login forms. You need to
> modify standalone.xml and set your provider as primary one while disabling
> default one:
>
>             <spi name=?account">
>                 <default-provider>my-custom-provider</default-provider>
>                 <provider name="my-custom-provider" enabled="true"/>
>                 <provider name="freemarker" enabled="false"/>
>             </spi>
>
> My extension is packaged as JBoss module and registered via providers
> configuration:
>         <subsystem xmlns="urn:jboss:domain:keycloak-server:1.1">
>             <web-context>ROOT</web-context>
>             <providers>
>                 <provider>
>                     module:org.code-house.keycloak.login
>                 </provider>
>                <!-- .... etc -->
>
>
> You can also try to drop your JAR (if not packaged as module) to
> ${keycloak.home}/providers directory.
>
> Kind regards,
> ?ukasz
> ?
> Code-House
> http://code-house.org
>
>
> On 12 Apr 2019, at 10:20, abhishek raghav <abhi.raghav007 at gmail.com>
> wrote:
>
> Hi -
>
> We have implemented a custom account provider which
> implements AccountProviderFactory and the implementation class
> extends FreeMarkerAccountProvider. It is packaged and deployed as a
> provider with a service definition file.
>
> This used to be work in keycloak 3.4.3.Final but not after we upgrade to
> keycloak 4.8.3.Final.
>
> We also identified that the provider is not even registering/initialized
> during boot time of keycloak. Could somebody please tell - whether keycloak
> has removed support of extending Account provider SPI. Or there is any
> other way to extend the account provider in keycloak 4.8.3.Final.
>
> Any help is greatly appreciated.
>
> Thanks
> -Abhishek
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>

From jerry.saravia at virginpulse.com  Mon Apr 15 09:12:10 2019
From: jerry.saravia at virginpulse.com (Jerry Saravia)
Date: Mon, 15 Apr 2019 13:12:10 +0000
Subject: [keycloak-dev] Override "native" Keycloak providers
In-Reply-To: <CAK-7U1hsOGjcZnv1BAf0GV1esEQ_Nyg3qdizoo9XT2kZTzX00A@mail.gmail.com>
References: <1DDE98A1-431C-49BF-B20B-AB00C61CF763@contoso.com>
	<CAK-7U1hsOGjcZnv1BAf0GV1esEQ_Nyg3qdizoo9XT2kZTzX00A@mail.gmail.com>
Message-ID: <67B38388-64A5-4800-A89E-55D3C9547724@virginpulse.com>

Thanks Thomas,

This worked!!!


Jerry Saravia
Software Engineer
T(516) 603-6914
M516-603-6914
virginpulse.com
|virginpulse.com/global-challenge
492 Old Connecticut Path, Framingham, MA 01701, USA
Australia | Bosnia and Herzegovina | Brazil | Canada | Singapore | Switzerland | United Kingdom | USA
Confidentiality Notice: The information contained in this e-mail, including any attachment(s), is intended solely for use by the designated recipient(s). Unauthorized use, dissemination, distribution, or reproduction of this message by anyone other than the intended recipient(s), or a person designated as responsible for delivering such messages to the intended recipient, is strictly prohibited and may be unlawful. This e-mail may contain proprietary, confidential or privileged information. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Virgin Pulse, Inc. If you have received this message in error, or are not the named recipient(s), please immediately notify the sender and delete this e-mail message.
v2.52
From: Thomas Darimont <thomas.darimont at googlemail.com>
Date: Wednesday, March 27, 2019 at 18:23
To: Jerry Saravia <jerry.saravia at virginpulse.com>
Cc: "keycloak-dev at lists.jboss.org" <keycloak-dev at lists.jboss.org>
Subject: Re: [keycloak-dev] Override "native" Keycloak providers

This email originates outside Virgin Pulse.

Hello Jerry,

I encountered a similar problem with Keycloak 4.x when I needed to implement my own SamlProtocolFactory to customize the SAML Message handling.
See: http://lists.jboss.org/pipermail/keycloak-dev/2019-February/011745.html<https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.jboss.org%2Fpipermail%2Fkeycloak-dev%2F2019-February%2F011745.html&data=02%7C01%7Cjerry.saravia%40virginpulse.com%7C40d6fd71af6b4998c21a08d6b302ceed%7Cb123a16e892b4cf6a55a6f8c7606a035%7C0%7C0%7C636893221988678776&sdata=JRszK70Y260c5Lvbra19Qp4E%2B9FswzPwPMJRQb8t5G4%3D&reserved=0>
The only way I could get this to work was to add my custom extension jar to the module.xml of the keycloak-services module,
see the link for details.

It's by far not the best solution, but at least it works.

Cheers,
Thomas

On Wed, 27 Mar 2019 at 22:28, Jerry Saravia <jerry.saravia at virginpulse.com<mailto:jerry.saravia at virginpulse.com>> wrote:
Hello,



We?ve been using version 3.4.3 for a while now and are attempting to upgrade to 4.8 and we?ve run into some issues.



Summary: We have created our own providers with the same PROVIDER_ID as some of the built in providers. For example, PasswordCredentialProvider has a provider id of ?keycloak-password? and we created our own with the same id that gets loaded after the native one. This worked because in 3.4.3 providers that were using the same id would still have their factories added to the factory map.



See this link here for 3.4.3 changes:

https://github.com/keycloak/keycloak/blob/3.4.3.Final/services/src/main/java/org/keycloak/provider/ProviderManager.java#L96-L100<https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fkeycloak%2Fkeycloak%2Fblob%2F3.4.3.Final%2Fservices%2Fsrc%2Fmain%2Fjava%2Forg%2Fkeycloak%2Fprovider%2FProviderManager.java%23L96-L100&data=02%7C01%7Cjerry.saravia%40virginpulse.com%7C40d6fd71af6b4998c21a08d6b302ceed%7Cb123a16e892b4cf6a55a6f8c7606a035%7C0%7C0%7C636893221988678776&sdata=0pjRiO7IuJLBc7XxS%2F2UOwZKDDL4RGbu3yHPJO%2FFG5U%3D&reserved=0>



These are the 4.8 changes

https://github.com/keycloak/keycloak/blob/4.8.3.Final/services/src/main/java/org/keycloak/provider/ProviderManager.java#L96-L99<https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fkeycloak%2Fkeycloak%2Fblob%2F4.8.3.Final%2Fservices%2Fsrc%2Fmain%2Fjava%2Forg%2Fkeycloak%2Fprovider%2FProviderManager.java%23L96-L99&data=02%7C01%7Cjerry.saravia%40virginpulse.com%7C40d6fd71af6b4998c21a08d6b302ceed%7Cb123a16e892b4cf6a55a6f8c7606a035%7C0%7C0%7C636893221988688789&sdata=I5hMBZLoQsSFqEakuWb6uSTtuAGOAUSfeQ%2B4CIOwPZY%3D&reserved=0>



In 4.8, the fully qualified class name (FQCN) is not longer used. Instead it uses the provider id and the spi name. I can no longer use the same PROVIDER_ID as the native providers to ?override? them, but sometimes there is code that gets the provider specifically by id. For example, in the UpdatePassword required action we have this:



PasswordCredentialProvider passwordProvider = (PasswordCredentialProvider)context.getSession().getProvider(CredentialProvider.class, PasswordCredentialProviderFactory.PROVIDER_ID);



In 3.4.3 because our provider was loaded we were able to inject into code that normally isn?t overridable. We did the same for the OIDCLoginProtocolFactory to alter some token endpoint behavior even the UpdatePassword required action itself rather than making a brand new required action that is a ?second rate? because it isn?t native to Keycloak.



Is there a solution for this in 4.8.3? I see this change was made in 4.0.0.Beta1 according to some of the history.



J


Jerry Saravia
Software Engineer
T(516) 603-6914
M516-603-6914
virginpulse.com<https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fvirginpulse.com&data=02%7C01%7Cjerry.saravia%40virginpulse.com%7C40d6fd71af6b4998c21a08d6b302ceed%7Cb123a16e892b4cf6a55a6f8c7606a035%7C0%7C0%7C636893221988688789&sdata=wFxdGkMhleh%2F9flNW3Kf%2FLs38Sead7L07IvapwyQPY4%3D&reserved=0>
|virginpulse.com/global-challenge<https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fvirginpulse.com%2Fglobal-challenge&data=02%7C01%7Cjerry.saravia%40virginpulse.com%7C40d6fd71af6b4998c21a08d6b302ceed%7Cb123a16e892b4cf6a55a6f8c7606a035%7C0%7C0%7C636893221988698793&sdata=2LvPxrCOKkzZnCzkNOLGCHj4Jpq74Z70Iy4CNDJCbRw%3D&reserved=0>
492 Old Connecticut Path, Framingham, MA 01701, USA
Australia | Bosnia and Herzegovina | Brazil | Canada | Singapore | Switzerland | United Kingdom | USA
Confidentiality Notice: The information contained in this e-mail, including any attachment(s), is intended solely for use by the designated recipient(s). Unauthorized use, dissemination, distribution, or reproduction of this message by anyone other than the intended recipient(s), or a person designated as responsible for delivering such messages to the intended recipient, is strictly prohibited and may be unlawful. This e-mail may contain proprietary, confidential or privileged information. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Virgin Pulse, Inc. If you have received this message in error, or are not the named recipient(s), please immediately notify the sender and delete this e-mail message.
v2.48
_______________________________________________
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://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.jboss.org%2Fmailman%2Flistinfo%2Fkeycloak-dev&data=02%7C01%7Cjerry.saravia%40virginpulse.com%7C40d6fd71af6b4998c21a08d6b302ceed%7Cb123a16e892b4cf6a55a6f8c7606a035%7C0%7C0%7C636893221988708801&sdata=6IayjP%2Bvxtn2C7pH9%2FQQK8rE4zrXRX4%2BWEmXu9ReeMI%3D&reserved=0>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image242052.png
Type: image/png
Size: 681 bytes
Desc: image242052.png
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20190415/724be68d/attachment-0003.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image314870.png
Type: image/png
Size: 687 bytes
Desc: image314870.png
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20190415/724be68d/attachment-0004.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image648907.png
Type: image/png
Size: 757 bytes
Desc: image648907.png
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20190415/724be68d/attachment-0005.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image192883.jpg
Type: image/jpeg
Size: 26637 bytes
Desc: image192883.jpg
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20190415/724be68d/attachment-0001.jpg 

From sven-torben.janus at conciso.de  Mon Apr 15 14:16:12 2019
From: sven-torben.janus at conciso.de (Sven-Torben Janus)
Date: Mon, 15 Apr 2019 18:16:12 +0000
Subject: [keycloak-dev] X.509 User Identity Extractor - multiple values
In-Reply-To: <91fcedac-ccdb-6633-e48c-69cbd6bf9b8d@redhat.com>
References: <DB3PR0502MB399356CAE4CC1C6DC230632CCF420@DB3PR0502MB3993.eurprd05.prod.outlook.com>
	<885bb636-39ac-a77b-799a-6554ba5d74c6@redhat.com>
	<DB3PR0502MB399363166DF589D4DB161904CF420@DB3PR0502MB3993.eurprd05.prod.outlook.com>
	<ee42e442-78c0-3304-0f5d-8fec4c2e3180@redhat.com>
	<AM0PR0502MB39871046FD435ADC4D213A62CF430@AM0PR0502MB3987.eurprd05.prod.outlook.com>
	<91fcedac-ccdb-6633-e48c-69cbd6bf9b8d@redhat.com>
Message-ID: <AM0PR0502MB3987DC5615616573600EF504CF2B0@AM0PR0502MB3987.eurprd05.prod.outlook.com>

Hey Marek,

I need to follow up on this.
I have made a first draft of the implementation. However, it seems that certificates are much longer than currently supported by the value field in the user_attribute table. 
Increasing filed length has been discussed in https://issues.jboss.org/browse/KEYCLOAK-2382, but I could not really figure out what the current status is? It does not seem to be implemented. Do you see a chance for increasing the field length?

Regards
Sven-Torben

-----Urspr?ngliche Nachricht-----
Von: Marek Posolda <mposolda at redhat.com> 
Gesendet: Montag, 25. M?rz 2019 12:25
An: Sven-Torben Janus <sven-torben.janus at conciso.de>; keycloak-dev at lists.jboss.org
Betreff: Re: AW: AW: [keycloak-dev] X.509 User Identity Extractor - multiple values

On 22/03/2019 11:43, Sven-Torben Janus wrote:
> Hey Marek,
>
> as far as I know, RFC 2587 specifies the usercertificate attribute for exactly that purpose. Active Directory also knows something similar (see https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-ada3/f9e923d6-c512-4beb-b963-afd695cea8ac).
Thanks for pointing this. It seems it may be useful to have OOTB UserIdentityExtractor, which will work with the MSAD "userCertificate" 
attribute. So if you have a chance to contribute this, I think it will be fine.
> IMHO matching the certificate against a custom LDAP attribute should also be ok. At least that is what the custom attribute mapper for the existing "user mapping method" is doing anyways for all the other user identity sources (like subjectDN, common name etc.), right?

Maybe it is thin line, but in general, I see that having OOTB extractors, which are able to pair users based on subjectDN or commonName looks natural and will probably work for most of the people. 
Having something very specific like "issuer;serialNumber" is IMO not generally useful, so I would rather avoid to have the UserIdentityExtractor in Keycloak OOTB.

Marek
>
> Regards
> Sven-Torben
>
> -----Urspr?ngliche Nachricht-----
> Von: Marek Posolda <mposolda at redhat.com>
> Gesendet: Freitag, 22. M?rz 2019 10:20
> An: Sven-Torben Janus <sven-torben.janus at conciso.de>; 
> keycloak-dev at lists.jboss.org
> Betreff: Re: AW: [keycloak-dev] X.509 User Identity Extractor - 
> multiple values
>
> Thanks for the clarification
>
> TBH It seems to me that probably even (b) won't be very generally useful. Unless for example some LDAP servers store the certificate PEM in some standard LDAP attribute of the user? But if it's customization of LDAP schema specific to your environment to be able to save the certificate PEM in the LDAP attribute, then my vote is to not add it.
>
> Marek
>
> On 21/03/2019 17:18, Sven-Torben Janus wrote:
>> Hi Marek,
>>
>> I agree to your thoughts on solution a). That's basically why I wanted to discuss it here, before starting an implementation.
>> Regarding, solution b), yes that is what I thought about (with or without the initial/final lines).
>>
>> Sven-Torben
>>
>> -----Urspr?ngliche Nachricht-----
>> Von: Marek Posolda <mposolda at redhat.com>
>> Gesendet: Donnerstag, 21. M?rz 2019 10:54
>> An: Sven-Torben Janus <sven-torben.janus at conciso.de>; 
>> keycloak-dev at lists.jboss.org
>> Betreff: Re: [keycloak-dev] X.509 User Identity Extractor - multiple 
>> values
>>
>> Hi,
>>
>> The solution (a) looks quite specific to the environment and I don't think that it will be useful to have this as a generic feature in Keycloak.. Solution (b) looks like bit more generally useful, but still not 100% sure about adding it to Keycloak... For the solution (b), are you talking about the PEM String representation of the X509 certificate, which just excludes the initial and final lines (Those with "BEGIN CERTIFICATE" and "END CERTIFICATE" )?
>>
>> Marek
>>
>> On 21/03/2019 07:48, Sven-Torben Janus wrote:
>>> Hey all!
>>>
>>> I am currently facing a situation with a customer who wants to implement mutual SSL / client cert authentication. As I understand from the UserIdentityExtractor[1] implementations, currently only returning a single value is allowed, because the UserIdentityToModelMapper[2] calls toString on the actual userIdentity object.
>>>
>>> Now my customer uses the serial number from the certificate to identify users. However, this is only unique in combination with the issuer of the certificate, since my customer supports multiple CAs. The combination of both exists in their LDAP as a single attribute where both parts are separated by a special separator character.
>>> In addition to that, the whole certificate of the user is also available in another LDAP attribute.
>>>
>>> I currently see the following options to implement a solution for this:
>>> 1) Writing a custom Authenticator to handle that specific situation.
>>> This one would look very similar to the ootb X509 authenticator, but 
>>> implements either a) or b) (see below)
>>> 2) Making a contribution to Keycloak and extend the list of available UserIdentitiyExtractors.
>>>
>>> For both approaches two different implementations come to my mind:
>>>
>>> a) Adding an additional UserIdentitiyExtractor which combines the issuer and the serial number into a single string and use that as an identity.
>>> b) Adding an additional UserIdentitiyExtractor which returns the whole certificate as the user's identity.
>>>
>>> We would prefer contributing to Keycloak, if such a contribution is welcome and meaningful.
>>>
>>> Do you have any advice on which way to go here?
>>>
>>> [1]https://github.com/keycloak/keycloak/blob/master/services/src/mai
>>> n 
>>> /java/org/keycloak/authentication/authenticators/x509/UserIdentityEx
>>> t
>>> ractor.java
>>> [2]https://github.com/keycloak/keycloak/blob/master/services/src/mai
>>> n 
>>> /java/org/keycloak/authentication/authenticators/x509/UserIdentityTo
>>> M
>>> odelMapper.java#L57
>>>
>>> Regards
>>> Sven-Torben
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev




From mposolda at redhat.com  Mon Apr 15 14:42:37 2019
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 15 Apr 2019 20:42:37 +0200
Subject: [keycloak-dev] X.509 User Identity Extractor - multiple values
In-Reply-To: <AM0PR0502MB3987DC5615616573600EF504CF2B0@AM0PR0502MB3987.eurprd05.prod.outlook.com>
References: <DB3PR0502MB399356CAE4CC1C6DC230632CCF420@DB3PR0502MB3993.eurprd05.prod.outlook.com>
	<885bb636-39ac-a77b-799a-6554ba5d74c6@redhat.com>
	<DB3PR0502MB399363166DF589D4DB161904CF420@DB3PR0502MB3993.eurprd05.prod.outlook.com>
	<ee42e442-78c0-3304-0f5d-8fec4c2e3180@redhat.com>
	<AM0PR0502MB39871046FD435ADC4D213A62CF430@AM0PR0502MB3987.eurprd05.prod.outlook.com>
	<91fcedac-ccdb-6633-e48c-69cbd6bf9b8d@redhat.com>
	<AM0PR0502MB3987DC5615616573600EF504CF2B0@AM0PR0502MB3987.eurprd05.prod.outlook.com>
Message-ID: <ab1c7e1a-19fd-1ec3-fc3f-2ac8a45f16e9@redhat.com>

Hi Sven-Torben,

I think that if you mark attribute as "read-only" and maybe also as 
"binary attribute" with the LDAP attribute mapper, then it won't be 
saved to the Keycloak DB at all. Then you don't need to care about the 
length of the field in user_attribute table. Something similar is used 
to save the picture in the LDAP example, which is part of 
keycloak-examples distribution (the deprecated one).

This will work just with the LDAP, not with Keycloak DB-only setup. But 
isn't it what you wanted to use anyway?

Marek

On 15/04/2019 20:16, Sven-Torben Janus wrote:
> Hey Marek,
>
> I need to follow up on this.
> I have made a first draft of the implementation. However, it seems that certificates are much longer than currently supported by the value field in the user_attribute table.
> Increasing filed length has been discussed in https://issues.jboss.org/browse/KEYCLOAK-2382, but I could not really figure out what the current status is? It does not seem to be implemented. Do you see a chance for increasing the field length?
>
> Regards
> Sven-Torben
>
> -----Urspr?ngliche Nachricht-----
> Von: Marek Posolda <mposolda at redhat.com>
> Gesendet: Montag, 25. M?rz 2019 12:25
> An: Sven-Torben Janus <sven-torben.janus at conciso.de>; keycloak-dev at lists.jboss.org
> Betreff: Re: AW: AW: [keycloak-dev] X.509 User Identity Extractor - multiple values
>
> On 22/03/2019 11:43, Sven-Torben Janus wrote:
>> Hey Marek,
>>
>> as far as I know, RFC 2587 specifies the usercertificate attribute for exactly that purpose. Active Directory also knows something similar (see https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-ada3/f9e923d6-c512-4beb-b963-afd695cea8ac).
> Thanks for pointing this. It seems it may be useful to have OOTB UserIdentityExtractor, which will work with the MSAD "userCertificate"
> attribute. So if you have a chance to contribute this, I think it will be fine.
>> IMHO matching the certificate against a custom LDAP attribute should also be ok. At least that is what the custom attribute mapper for the existing "user mapping method" is doing anyways for all the other user identity sources (like subjectDN, common name etc.), right?
> Maybe it is thin line, but in general, I see that having OOTB extractors, which are able to pair users based on subjectDN or commonName looks natural and will probably work for most of the people.
> Having something very specific like "issuer;serialNumber" is IMO not generally useful, so I would rather avoid to have the UserIdentityExtractor in Keycloak OOTB.
>
> Marek
>> Regards
>> Sven-Torben
>>
>> -----Urspr?ngliche Nachricht-----
>> Von: Marek Posolda <mposolda at redhat.com>
>> Gesendet: Freitag, 22. M?rz 2019 10:20
>> An: Sven-Torben Janus <sven-torben.janus at conciso.de>;
>> keycloak-dev at lists.jboss.org
>> Betreff: Re: AW: [keycloak-dev] X.509 User Identity Extractor -
>> multiple values
>>
>> Thanks for the clarification
>>
>> TBH It seems to me that probably even (b) won't be very generally useful. Unless for example some LDAP servers store the certificate PEM in some standard LDAP attribute of the user? But if it's customization of LDAP schema specific to your environment to be able to save the certificate PEM in the LDAP attribute, then my vote is to not add it.
>>
>> Marek
>>
>> On 21/03/2019 17:18, Sven-Torben Janus wrote:
>>> Hi Marek,
>>>
>>> I agree to your thoughts on solution a). That's basically why I wanted to discuss it here, before starting an implementation.
>>> Regarding, solution b), yes that is what I thought about (with or without the initial/final lines).
>>>
>>> Sven-Torben
>>>
>>> -----Urspr?ngliche Nachricht-----
>>> Von: Marek Posolda <mposolda at redhat.com>
>>> Gesendet: Donnerstag, 21. M?rz 2019 10:54
>>> An: Sven-Torben Janus <sven-torben.janus at conciso.de>;
>>> keycloak-dev at lists.jboss.org
>>> Betreff: Re: [keycloak-dev] X.509 User Identity Extractor - multiple
>>> values
>>>
>>> Hi,
>>>
>>> The solution (a) looks quite specific to the environment and I don't think that it will be useful to have this as a generic feature in Keycloak.. Solution (b) looks like bit more generally useful, but still not 100% sure about adding it to Keycloak... For the solution (b), are you talking about the PEM String representation of the X509 certificate, which just excludes the initial and final lines (Those with "BEGIN CERTIFICATE" and "END CERTIFICATE" )?
>>>
>>> Marek
>>>
>>> On 21/03/2019 07:48, Sven-Torben Janus wrote:
>>>> Hey all!
>>>>
>>>> I am currently facing a situation with a customer who wants to implement mutual SSL / client cert authentication. As I understand from the UserIdentityExtractor[1] implementations, currently only returning a single value is allowed, because the UserIdentityToModelMapper[2] calls toString on the actual userIdentity object.
>>>>
>>>> Now my customer uses the serial number from the certificate to identify users. However, this is only unique in combination with the issuer of the certificate, since my customer supports multiple CAs. The combination of both exists in their LDAP as a single attribute where both parts are separated by a special separator character.
>>>> In addition to that, the whole certificate of the user is also available in another LDAP attribute.
>>>>
>>>> I currently see the following options to implement a solution for this:
>>>> 1) Writing a custom Authenticator to handle that specific situation.
>>>> This one would look very similar to the ootb X509 authenticator, but
>>>> implements either a) or b) (see below)
>>>> 2) Making a contribution to Keycloak and extend the list of available UserIdentitiyExtractors.
>>>>
>>>> For both approaches two different implementations come to my mind:
>>>>
>>>> a) Adding an additional UserIdentitiyExtractor which combines the issuer and the serial number into a single string and use that as an identity.
>>>> b) Adding an additional UserIdentitiyExtractor which returns the whole certificate as the user's identity.
>>>>
>>>> We would prefer contributing to Keycloak, if such a contribution is welcome and meaningful.
>>>>
>>>> Do you have any advice on which way to go here?
>>>>
>>>> [1]https://github.com/keycloak/keycloak/blob/master/services/src/mai
>>>> n
>>>> /java/org/keycloak/authentication/authenticators/x509/UserIdentityEx
>>>> t
>>>> ractor.java
>>>> [2]https://github.com/keycloak/keycloak/blob/master/services/src/mai
>>>> n
>>>> /java/org/keycloak/authentication/authenticators/x509/UserIdentityTo
>>>> M
>>>> odelMapper.java#L57
>>>>
>>>> Regards
>>>> Sven-Torben
>>>>
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>


From thomas.darimont at googlemail.com  Mon Apr 15 15:26:06 2019
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Mon, 15 Apr 2019 21:26:06 +0200
Subject: [keycloak-dev] X.509 User Identity Extractor - multiple values
In-Reply-To: <ab1c7e1a-19fd-1ec3-fc3f-2ac8a45f16e9@redhat.com>
References: <DB3PR0502MB399356CAE4CC1C6DC230632CCF420@DB3PR0502MB3993.eurprd05.prod.outlook.com>
	<885bb636-39ac-a77b-799a-6554ba5d74c6@redhat.com>
	<DB3PR0502MB399363166DF589D4DB161904CF420@DB3PR0502MB3993.eurprd05.prod.outlook.com>
	<ee42e442-78c0-3304-0f5d-8fec4c2e3180@redhat.com>
	<AM0PR0502MB39871046FD435ADC4D213A62CF430@AM0PR0502MB3987.eurprd05.prod.outlook.com>
	<91fcedac-ccdb-6633-e48c-69cbd6bf9b8d@redhat.com>
	<AM0PR0502MB3987DC5615616573600EF504CF2B0@AM0PR0502MB3987.eurprd05.prod.outlook.com>
	<ab1c7e1a-19fd-1ec3-fc3f-2ac8a45f16e9@redhat.com>
Message-ID: <CAK-7U1i17=eeCprhPL+r0Myg2d0KVR-vzW=8ic_4ntxq5mofWg@mail.gmail.com>

Hello,

another option could be to store user specific certificates as a custom
user credential (UserCredentialModel).

Cheers,
Thomas

On Mon, 15 Apr 2019 at 21:16, Marek Posolda <mposolda at redhat.com> wrote:

> Hi Sven-Torben,
>
> I think that if you mark attribute as "read-only" and maybe also as
> "binary attribute" with the LDAP attribute mapper, then it won't be
> saved to the Keycloak DB at all. Then you don't need to care about the
> length of the field in user_attribute table. Something similar is used
> to save the picture in the LDAP example, which is part of
> keycloak-examples distribution (the deprecated one).
>
> This will work just with the LDAP, not with Keycloak DB-only setup. But
> isn't it what you wanted to use anyway?
>
> Marek
>
> On 15/04/2019 20:16, Sven-Torben Janus wrote:
> > Hey Marek,
> >
> > I need to follow up on this.
> > I have made a first draft of the implementation. However, it seems that
> certificates are much longer than currently supported by the value field in
> the user_attribute table.
> > Increasing filed length has been discussed in
> https://issues.jboss.org/browse/KEYCLOAK-2382, but I could not really
> figure out what the current status is? It does not seem to be implemented.
> Do you see a chance for increasing the field length?
> >
> > Regards
> > Sven-Torben
> >
> > -----Urspr?ngliche Nachricht-----
> > Von: Marek Posolda <mposolda at redhat.com>
> > Gesendet: Montag, 25. M?rz 2019 12:25
> > An: Sven-Torben Janus <sven-torben.janus at conciso.de>;
> keycloak-dev at lists.jboss.org
> > Betreff: Re: AW: AW: [keycloak-dev] X.509 User Identity Extractor -
> multiple values
> >
> > On 22/03/2019 11:43, Sven-Torben Janus wrote:
> >> Hey Marek,
> >>
> >> as far as I know, RFC 2587 specifies the usercertificate attribute for
> exactly that purpose. Active Directory also knows something similar (see
> https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-ada3/f9e923d6-c512-4beb-b963-afd695cea8ac
> ).
> > Thanks for pointing this. It seems it may be useful to have OOTB
> UserIdentityExtractor, which will work with the MSAD "userCertificate"
> > attribute. So if you have a chance to contribute this, I think it will
> be fine.
> >> IMHO matching the certificate against a custom LDAP attribute should
> also be ok. At least that is what the custom attribute mapper for the
> existing "user mapping method" is doing anyways for all the other user
> identity sources (like subjectDN, common name etc.), right?
> > Maybe it is thin line, but in general, I see that having OOTB
> extractors, which are able to pair users based on subjectDN or commonName
> looks natural and will probably work for most of the people.
> > Having something very specific like "issuer;serialNumber" is IMO not
> generally useful, so I would rather avoid to have the UserIdentityExtractor
> in Keycloak OOTB.
> >
> > Marek
> >> Regards
> >> Sven-Torben
> >>
> >> -----Urspr?ngliche Nachricht-----
> >> Von: Marek Posolda <mposolda at redhat.com>
> >> Gesendet: Freitag, 22. M?rz 2019 10:20
> >> An: Sven-Torben Janus <sven-torben.janus at conciso.de>;
> >> keycloak-dev at lists.jboss.org
> >> Betreff: Re: AW: [keycloak-dev] X.509 User Identity Extractor -
> >> multiple values
> >>
> >> Thanks for the clarification
> >>
> >> TBH It seems to me that probably even (b) won't be very generally
> useful. Unless for example some LDAP servers store the certificate PEM in
> some standard LDAP attribute of the user? But if it's customization of LDAP
> schema specific to your environment to be able to save the certificate PEM
> in the LDAP attribute, then my vote is to not add it.
> >>
> >> Marek
> >>
> >> On 21/03/2019 17:18, Sven-Torben Janus wrote:
> >>> Hi Marek,
> >>>
> >>> I agree to your thoughts on solution a). That's basically why I wanted
> to discuss it here, before starting an implementation.
> >>> Regarding, solution b), yes that is what I thought about (with or
> without the initial/final lines).
> >>>
> >>> Sven-Torben
> >>>
> >>> -----Urspr?ngliche Nachricht-----
> >>> Von: Marek Posolda <mposolda at redhat.com>
> >>> Gesendet: Donnerstag, 21. M?rz 2019 10:54
> >>> An: Sven-Torben Janus <sven-torben.janus at conciso.de>;
> >>> keycloak-dev at lists.jboss.org
> >>> Betreff: Re: [keycloak-dev] X.509 User Identity Extractor - multiple
> >>> values
> >>>
> >>> Hi,
> >>>
> >>> The solution (a) looks quite specific to the environment and I don't
> think that it will be useful to have this as a generic feature in
> Keycloak.. Solution (b) looks like bit more generally useful, but still not
> 100% sure about adding it to Keycloak... For the solution (b), are you
> talking about the PEM String representation of the X509 certificate, which
> just excludes the initial and final lines (Those with "BEGIN CERTIFICATE"
> and "END CERTIFICATE" )?
> >>>
> >>> Marek
> >>>
> >>> On 21/03/2019 07:48, Sven-Torben Janus wrote:
> >>>> Hey all!
> >>>>
> >>>> I am currently facing a situation with a customer who wants to
> implement mutual SSL / client cert authentication. As I understand from the
> UserIdentityExtractor[1] implementations, currently only returning a single
> value is allowed, because the UserIdentityToModelMapper[2] calls toString
> on the actual userIdentity object.
> >>>>
> >>>> Now my customer uses the serial number from the certificate to
> identify users. However, this is only unique in combination with the issuer
> of the certificate, since my customer supports multiple CAs. The
> combination of both exists in their LDAP as a single attribute where both
> parts are separated by a special separator character.
> >>>> In addition to that, the whole certificate of the user is also
> available in another LDAP attribute.
> >>>>
> >>>> I currently see the following options to implement a solution for
> this:
> >>>> 1) Writing a custom Authenticator to handle that specific situation.
> >>>> This one would look very similar to the ootb X509 authenticator, but
> >>>> implements either a) or b) (see below)
> >>>> 2) Making a contribution to Keycloak and extend the list of available
> UserIdentitiyExtractors.
> >>>>
> >>>> For both approaches two different implementations come to my mind:
> >>>>
> >>>> a) Adding an additional UserIdentitiyExtractor which combines the
> issuer and the serial number into a single string and use that as an
> identity.
> >>>> b) Adding an additional UserIdentitiyExtractor which returns the
> whole certificate as the user's identity.
> >>>>
> >>>> We would prefer contributing to Keycloak, if such a contribution is
> welcome and meaningful.
> >>>>
> >>>> Do you have any advice on which way to go here?
> >>>>
> >>>> [1]https://github.com/keycloak/keycloak/blob/master/services/src/mai
> >>>> n
> >>>> /java/org/keycloak/authentication/authenticators/x509/UserIdentityEx
> >>>> t
> >>>> ractor.java
> >>>> [2]https://github.com/keycloak/keycloak/blob/master/services/src/mai
> >>>> n
> >>>> /java/org/keycloak/authentication/authenticators/x509/UserIdentityTo
> >>>> M
> >>>> odelMapper.java#L57
> >>>>
> >>>> Regards
> >>>> Sven-Torben
> >>>>
> >>>> _______________________________________________
> >>>> keycloak-dev mailing list
> >>>> keycloak-dev at lists.jboss.org
> >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From Sebastian.Schuster at bosch-si.com  Tue Apr 16 02:03:49 2019
From: Sebastian.Schuster at bosch-si.com (Schuster Sebastian (INST-CSS/BSV-OS2))
Date: Tue, 16 Apr 2019 06:03:49 +0000
Subject: [keycloak-dev] Versioning Scheme for Keycloak
Message-ID: <67f0cab3a7824d70b2aa2fc2a3ffc0e4@bosch-si.com>

Hi everybody,

I noticed the versioning scheme was changed lately. There are no more x.Final versions anymore. Also, after releasing 5.0.0 the next version was switched to 6.0.0-Snapshot.
Are these changes purely cosmetical? Will there be no more minor/patch releases according to semantic versioning? Is there a relation to a changed release schedule for Red Hat SSO?

Can anybody shed some light on what these changes mean?

Thanks and best regards,
Sebastian


Mit freundlichen Gr??en / Best regards

Dr.-Ing. Sebastian Schuster

Open Source Services (INST-CSS/BSV-OS2)
Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin | GERMANY | www.bosch-si.com<http://www.bosch-si.com>
Tel. +49 30 726112-485 | Mobil +49 152 02177668 | Fax +49 30 726112-100 | Sebastian.Schuster at bosch-si.com<mailto:Sebastian.Schuster at bosch-si.com>

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




From alistair.doswald at elca.ch  Tue Apr 16 04:51:54 2019
From: alistair.doswald at elca.ch (Doswald Alistair)
Date: Tue, 16 Apr 2019 08:51:54 +0000
Subject: [keycloak-dev] W3C Web Authentication - Two-Factor,
 implementing JIRAs
In-Reply-To: <CAJgngAeRE3ExFY469n_PURpHEnduVgiBuuNGmMOHP0SYYunVPA@mail.gmail.com>
References: <24cbd52475494e4a95f9282a280d8fde@elca.ch>
	<CAJgngAcWrTfp7-w_CX7GooohArQe62xp78+58oGCQozPmjojXw@mail.gmail.com>
	<111481de90e245cabb85e75fa4f72c70@elca.ch>
	<CAJgngAeqsgQGRnHwS38SLhtxJKgn+ADRktZ1243GAD7KtjB+Dg@mail.gmail.com>
	<685b12117e024c449ae6e1a4e221cac8@elca.ch>
	<CAJgngAeRE3ExFY469n_PURpHEnduVgiBuuNGmMOHP0SYYunVPA@mail.gmail.com>
Message-ID: <09f9c666bee742a090160ab1c0655752@elca.ch>

I?ve made a PR for the design document on keycloak-community. Compared to the initial mail, I?ve made some changes to the multi-factor part to take into account our discussions and some comments from my colleagues. I?ve also added a section for the design of step-up authentication.

From: Stian Thorgersen <sthorger at redhat.com>
Sent: mercredi 20 mars 2019 13:01
To: Doswald Alistair <alistair.doswald at elca.ch>
Cc: keycloak-dev <keycloak-dev at lists.jboss.org>
Subject: Re: [keycloak-dev] W3C Web Authentication - Two-Factor, implementing JIRAs



On Mon, 18 Mar 2019 at 10:51, Doswald Alistair <alistair.doswald at elca.ch<mailto:alistair.doswald at elca.ch>> wrote:
* I can move the design proposal to https://github.com/keycloak/keycloak-community/tree/master/design. For this I simply format in Markdown and do a pull request?

Yes


* I?d also be in favour of a face to face meeting. I?m in the CET timezone (currently GMT+1 and GMT+2 from the 31st of march). This week I?d be available Tuesday, Thursday and Friday, and I also have availabilities next week (except Monday). I?m not sure of the logistics however? We use skype for business internally, but maybe you have a preferred platform? Also, would you mind if one of my colleagues who could work on the JIRAs joins the meeting call?

I've had issues with Skype in the past. We can use BlueJeans if that works for you? Tuesday at 12?

* Since I?m answering anyway, I?ll answer a few of your comments (the rest can be discussed later as I think that they are more technical):

- I believe that you?re correct to say that we should consider the step-up (and one of my colleagues actually had the same comment upon reading my proposal). I may have some ideas on how this would work with the proposed 2 factor, but I?d like to read up on what was already discussed/proposed first. Has there been more discussed than what?s at https://issues.jboss.org/browse/KEYCLOAK-847, http://lists.jboss.org/pipermail/keycloak-user/2016-November/008311.html, http://lists.jboss.org/pipermail/keycloak-dev/2016-May/007150.html and http://lists.jboss.org/pipermail/keycloak-dev/2017-April/009245.html?

Had a long discussion with some folks from the team a while back around step-up, but of course we didn't write it down ;)

In summary the plans where to add markers into the flows that would be used to set the authentication levels, then allow the authentication processor to skip as well as fast forward as needed.


- For the users setting their own default authenticator I agree (and intended to describe that in the text, though upon re-reading that part of the description is fragmented), as long as the admin has enabled the authentication category in a flow. However, it is true that between the default flow and custom/per-client flows it may be difficult to determine how the user sees/selects his preferred authenticator for an authentication step (not to mention what would happen when an admin changes the configuration). This should definitely be further detailed. I?m not sure yet if some extra data structures are necessary though, maybe some custom functions to get the required information is sufficient.

We need a group that means "one of these" ;)



- I think that having a built in flow that follows the proposed logic isn?t too difficult. There?d be the ?Authenticated on?,
?Authentication factor 1? and ?Authentication factor 2? executions with some default authenticator categories. The admin would be able to set enabled and disabled for the built-in authenticator categories, but be able to add and remove in custom flows. That way a newbie admin wouldn?t be able to do too much damage, while a more experienced one would be able to customize as he wants. Some extra documentation within the admin console may help with this.


From: Stian Thorgersen <sthorger at redhat.com<mailto:sthorger at redhat.com>>
Sent: vendredi 15 mars 2019 09:25
To: Doswald Alistair <alistair.doswald at elca.ch<mailto:alistair.doswald at elca.ch>>
Cc: keycloak-dev <keycloak-dev at lists.jboss.org<mailto:keycloak-dev at lists.jboss.org>>
Subject: Re: [keycloak-dev] W3C Web Authentication - Two-Factor, implementing JIRAs

* Would be worth moving this to a design proposal on https://github.com/keycloak/keycloak-community/tree/master/design. Would be easier to work collectively on a design proposal there than to have an endless thread on a ML ;). I'd also be open to join you on a call to have a discussion "face to face"

* I was thinking to limit to two factor for now, but you're probably right here with regards to consider the bigger picture now as it may be difficult to get it right otherwise

* Need to consider how this fits into step-up authentication

* Admins should be able to select level of authentication required, but users should be able to choose from available options

* Users should be able to select from available mechanisms when configuring. Users should be able to set their own default. This means the account console/rest needs metadata to discover available mechanisms. I wonder if there's a need for something outside of flows and authenticators to capture metadata about supported credential types which is used by account and admin consoles to manage credentials.

* I was aiming a simpler setup where admin doesn't need to create custom flow unless they want to add custom authenticators. That means authenticators should be enabled/disabled in the flow rather than added/removed

Some more comments inline below

On Thu, 14 Mar 2019 at 14:02, Doswald Alistair <alistair.doswald at elca.ch<mailto:alistair.doswald at elca.ch>> wrote:

This is OK for me. I propose starting with initial proposals for the fundamentals in this email, and once there's an agreement on those, separating the discussion between the two JIRAs to refine the concepts for each one. Once the work to be done is clearer, it can be supplemented with screen mockups and/or prototypes.





1) Scope of the modifications



- For JIRA KEYCLOAK-9693<https://issues.jboss.org/browse/KEYCLOAK-9693>, I believe that the description in the JIRA is not general enough to cover the description in web-authn-two-factor.md<https://github.com/keycloak/keycloak-community/blob/master/design/web-authn-two-factor.md>. Modifications to the authentication flows should support single factor, as well as 2nd factor and allow both authentication factor levels to select the alternative types of authenticator to be used. This allows a single factor authentication to use for example a FIDO2 dongle for passwordless authentication, or even let the user choose between the dongle and a password during the login.  Modifications for this JIRA include: changes to the authentication logic, changes to the authentication part of the admin console, changes to the authentication screens that the user sees during login, changes to the REST API, and possibly some changes to the database.

In the first round we are focusing on two factor. Follow-up later is passwordless flows for web-authn. Passwordless is more tricky as it requires identity first login flow, ability for users to somehow define how they authenticate, rather than just what the second factor is, ability for admins to define authentication optoins rather than just two factor options.

As I mentioned above though it is probably all to linked to consider only one at the design phase. So perhaps we need to work together on a design proposal that will include everything including step-up authentication.




- For JIRA KEYCLOAK-9694<https://issues.jboss.org/browse/KEYCLOAK-9694>, changes are to the "users > credentials" part of the administration console and to the REST API.





2) Design proposal for KEYCLOAK-9693<https://issues.jboss.org/browse/KEYCLOAK-9693>



a) Authentication logic



The current authentication flow system should be kept, but perhaps simplified. For a start I think that actual authenticators categories - that is elements that provide identity (e.g. password, cookie, kerberos, otp, fido, ...) - should be separate from other executions like "reset password".



Thus, instead of directly adding "cookie" or "password" as alternatives in the authentication flow, the user can add the execution "authentication factor", and under authentication factor he can add only the valid authenticator categories. Each of the authenticator categories under the authentication factor are considered valid alternatives, and are evaluated in order. The authentication stops being automatically evaluated at the first authenticator that requires user input (alternative: all non-user input authenticators are evaluated before the first user-input authenticator).



Adding a 2nd "authentication factor" execution sets the 2nd factor, and it must then have authenticators assigned. To have an authenticator category be valid for both authentication factors it must be set under both 1st and 2nd authentication factor. For example, kerberos could be set for both 1st and 2nd factor, which would mean that the user skips both factors if he's registered with kerberos, but it could also be just set for the first factor, in which case he'd still have to input the 2nd factor. To handle optional 2nd factors there could either be a "optional authentication factor type" or have an "optional" flag in the options of the "authentication factor".



Potentially, this system could also allow a company that's really security conscientious/paranoiac to set N factors.



Authentication factors are treated as a bloc in the evaluation of alternatives. That is, if in a flow there's "Identity provider redirector", "authentication factor 1", "authentication factor 2", entering the authentication factor 1 flow will automatically cause "authentication factor 2" to be executed after.



To make things perhaps a little more clear, the current default "Browser" authentication would become for example:



Auth type

------------------------------------------------------------

Identity Provider Redirector

Authentication factor (1)

  |- Cookie

  |- Kerberos

  |- Username Password Form

Authentication factor (2) [OPTIONAL]

  |- Cookie

  |- Kerberos

  |- OTP Form



And if we wanted to have an mandatory 2nd factor, with either OTP or a FIDO2 configured:



Auth type

------------------------------------------------------------

Identity Provider Redirector

Authentication factor (1)

  |- Cookie

  |- Kerberos

  |- Username Password Form

Authentication factor (2)

  |- Cookie

  |- Kerberos

  |- OTP Form

  |- FIDO-2



Potentially we could also introduce another type of authentication execution, we could call it "Authenticated on", to simplify the authenticators that bypass the authentication factors. We could then have:



Auth type

------------------------------------------------------------

Identity Provider Redirector

Authenticated on

  |- Cookie

  |- Kerberos

Authentication factor (1)

  |- Username Password Form

Authentication factor (2)

  |- OTP Form

  |- FIDO-2

I like this in general. Devil is in the detail here though and need to think about this some more, especially how it fits into step-up-authentication.




b) Authentication section in the admin console



The schema described in a) would be implemented in the Authentication > flows. Bindings and Required Actions don't need any change I think. For policies I believe the password policy for the realm should remain, but the OTP policy should disappear, as a user could have several alternative OTP devices with different settings. As such, the information about the OTP settings should probably move to information associated with the credential.

+1 I also think this is limited to the flow itself. Bear in mind I want to have a built-in flow that can be configured rather than requiring creating new flows. For example if we have OTP and WebAuthn authenticators an admin should be able to just enabled WebAuthn, not have to create a new flow to add it. Obviously a new custom flow would be required if the flow or custom authenticators are added. Moving OTP policy from realm to authenticator is already planned work, it was only added to the realm in the first place as it was done before we had configurable authenticators.




c) Authentication screens for the user



When the user logs in, unless he has something like a cookie he will see by default the first configuration interface configured in the current Authentication factor. If there are many different factors configured, he can access a list of any valid authenticator to use. If the user fails with the selected authenticator, he may choose another configured authenticator to validate the step.

When it comes to default that is the users choice. So as a user if I have chosen webauthn as my default that should be shown first to me, even if the realm has the OTP as the first/default. It's also not when the user fails with the selected authenticator, but rather allow the user to choose a different authenticator.




d) REST API



There's no major change here, aside from updating the scheme to support the separation between authenticator categories and executions, and adding instructions to edit which authenticator categories are assigned to an authentication factor.



e) database modifications



Authenticator categories could be separated from executions either by having a new dedicated table, or by introducing a field in the authentication_execution table

Realm config is responsible for most of the mess in the tables today. It's just plain daft to save this as separate tables/columns as it's always fetched as one blog and never queried. So I wonder if we could take a first start at this by simply storing the whole authentication flow including authenticator config as a single JSON blob in the DB.






3) Design proposal for KEYCLOAK-9694<https://issues.jboss.org/browse/KEYCLOAK-9694>



a) Changes to the users > Credential menu



Instead of manage Password we have "manage credentials", with a list of credentials for a user. The credentials grouped by type, and should indicate by which authentication factor they are valid for (1st factor, 2nd factor, unconfigured). The administrator should be able to edit / remove a credential.



- For editing the administrator should be able to visualise the data of the credential (except the secret and the salt) and edit metadata about a device. Data would be any data in the fields of the credential that describe immutable data about the credential, and metadata would be for example label that a user can see and edit to name his device and a label that only the administrator could see and edit. The administrator (and user) should be able to set a "preferred credential" for each authentication factor level, which will override the factor shown by default during the login.



- For deleting, I think that this should be linked to the authentication factors and authenticator categories of the realm, for example:

   + For a realm with a single factor configured of types password and FIDO2, the credentials can be removed until ONE remains, and that last one cannot be removed.

   + For a realm with a two factors configured, the first with password and FIDO2, and the second with OTP and FIDO UAF (I know, this is not a very good example from a security point of view), then it must be impossible to remove the last credential for the first factor, and to remove the last credential for the second factor.



A note for passwords: Unlike other credentials I don't think that there should be more than one password that can be configured. Also, among its edition option it should be possible to reset (temporarily or not) as is currently the case.



If the administrator and user can remove credentials, I do not know if the possibility to disable credentials is still useful. I don't see any problems with the feature either though, so if it?s still deemed useful it would keep its current behaviour.

Credentials needs to have some metadata associated with them. Does it support a user to have mutiple (passwords is a single, webauthn is multiple). Can the admin update the value (passwords admin can update, webauthn only users can and that's through application initiated actions which account console will use). The thinking with regards to adding/updating credentials is that users do it through actions (required or application initiated), while admins do it directly in the console (in which case we need to have a dynamic way to specify the values, something like how component model works).




b) Modifications to the REST API



Currently there's no way to get credentials with the REST API. This should change with these modifications to reflect the new options for the administrator. The API should function in the same manner as the admin console: Credentials can be exposed (except for secret and hash values), the metadata edited and the credentials deleted with the same restrictions as described in section 3a

We just need to be very careful here that secrets are never returned on a REST endpoint, but otherwise yes we need an endpoint that can list a users credentials.




c) Database modifications



I do not believe that this modification entails any database modifications. The current system with credential and credential attributes should be sufficient for the handling of multiple authenticators.







That's it. Comments, questions and criticism are all welcome.

________________________________
From: Stian Thorgersen <sthorger at redhat.com<mailto:sthorger at redhat.com>>
Sent: 08 March 2019 13:17
To: Doswald Alistair
Cc: keycloak-dev
Subject: Re: [keycloak-dev] W3C Web Authentication - Two-Factor, implementing JIRAs

No one is working on the admin part at the moment, so contributions here would be very welcome. It's not a straightforward task though and would need a fair bit of design/prototyping/discussions to get this right.

On Fri, 8 Mar 2019 at 11:14, Doswald Alistair <alistair.doswald at elca.ch<mailto:alistair.doswald at elca.ch>> wrote:
Hello,


I've been following the thread about the implementation of WebAuthn in Keycloak, and saw that there are some related JIRAs in the following design document https://github.com/keycloak/keycloak-community/blob/master/design/web-authn-two-factor.md.


Is anyone  already working on JIRAs https://issues.jboss.org/browse/KEYCLOAK-9693 and https://issues.jboss.org/browse/KEYCLOAK-9694 for managing multiple 2nd factor authenticators? If not, with my colleagues we could implement them relatively quickly as we have use cases for these functionalities.


Best regards,


Alistair Doswald
_______________________________________________
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

From sven-torben.janus at conciso.de  Wed Apr 17 01:40:12 2019
From: sven-torben.janus at conciso.de (Sven-Torben Janus)
Date: Wed, 17 Apr 2019 05:40:12 +0000
Subject: [keycloak-dev] X.509 User Identity Extractor - multiple values
In-Reply-To: <ab1c7e1a-19fd-1ec3-fc3f-2ac8a45f16e9@redhat.com>
References: <DB3PR0502MB399356CAE4CC1C6DC230632CCF420@DB3PR0502MB3993.eurprd05.prod.outlook.com>
	<885bb636-39ac-a77b-799a-6554ba5d74c6@redhat.com>
	<DB3PR0502MB399363166DF589D4DB161904CF420@DB3PR0502MB3993.eurprd05.prod.outlook.com>
	<ee42e442-78c0-3304-0f5d-8fec4c2e3180@redhat.com>
	<AM0PR0502MB39871046FD435ADC4D213A62CF430@AM0PR0502MB3987.eurprd05.prod.outlook.com>
	<91fcedac-ccdb-6633-e48c-69cbd6bf9b8d@redhat.com>
	<AM0PR0502MB3987DC5615616573600EF504CF2B0@AM0PR0502MB3987.eurprd05.prod.outlook.com>
	<ab1c7e1a-19fd-1ec3-fc3f-2ac8a45f16e9@redhat.com>
Message-ID: <AM0PR0502MB398770AEDCD7FF0DD96DF8FECF250@AM0PR0502MB3987.eurprd05.prod.outlook.com>

Hi Marek,

yes, that is what I wanted.
I fiddled around with these options a little, but the behavior is quite strange.

case 1) mark the attribute in the LDAP mapper read-only, "always read from ldap" and binary:
I can see that the attribute will not be saved to the Keycloak DB. 
>From the OpenLDAP debug output I can also see that Keycloak queries my LDAP with a correct query. OpenLDAP finds the user and returns it. However, Keycloak logs a warning and fails authentication.

	04:27:42,449 WARN  [org.keycloak.events] (default task-62) type=LOGIN_ERROR, realmId=test2, clientId=test, userId=null, ipAddress=192.168.80.1, error=user_not_found, auth_method=openid-connect,  auth_type=code, response_type=code, redirect_uri=https://localhost/test/, code_id=68fda0bd-d523-4301-9e39-ad1d9a737b1c, response_mode=fragment, username=MIIETzC<cert truncated for readability>WXI8

case 2a) mark the attribute in the LDAP mapper read-only, "always read from ldap" and NOT binary:
Result same as in case 1.

case 2b) same as case2a, but explicitly importing users
When explicitly importing the users, Keycloak fails saving the attribute to the database because of the length limitation. 
Result same as in case 1.

case 3a) same as case 2a, but modified the table column to be of type TEXT instead of VARCHAR(255)
Result same as in case 1.

case 3b) same as case3a, but explicitly importing users
When explicitly importing the users, Keycloak saves the attribute to the database table user_attribute.
>From the OpenLDAP debug output I can also see that Keycloak queries my LDAP with a correct query. OpenLDAP finds the user and returns it. Authentication works as expected.

I digged a little through the code and to me this boils down to the UserStorageManager class which seems to find user with a custom attribute only when the attribute is available in Keycloaks DB and not within LDAP. 
Do you think so too and if yes, do you think that is a bug or by design?

Regards,
Sven-Torben

-----Urspr?ngliche Nachricht-----
Von: Marek Posolda <mposolda at redhat.com> 
Gesendet: Montag, 15. April 2019 20:43
An: Sven-Torben Janus <sven-torben.janus at conciso.de>; keycloak-dev at lists.jboss.org
Betreff: Re: AW: AW: AW: [keycloak-dev] X.509 User Identity Extractor - multiple values

Hi Sven-Torben,

I think that if you mark attribute as "read-only" and maybe also as "binary attribute" with the LDAP attribute mapper, then it won't be saved to the Keycloak DB at all. Then you don't need to care about the length of the field in user_attribute table. Something similar is used to save the picture in the LDAP example, which is part of keycloak-examples distribution (the deprecated one).

This will work just with the LDAP, not with Keycloak DB-only setup. But isn't it what you wanted to use anyway?

Marek

On 15/04/2019 20:16, Sven-Torben Janus wrote:
> Hey Marek,
>
> I need to follow up on this.
> I have made a first draft of the implementation. However, it seems that certificates are much longer than currently supported by the value field in the user_attribute table.
> Increasing filed length has been discussed in https://issues.jboss.org/browse/KEYCLOAK-2382, but I could not really figure out what the current status is? It does not seem to be implemented. Do you see a chance for increasing the field length?
>
> Regards
> Sven-Torben
>
> -----Urspr?ngliche Nachricht-----
> Von: Marek Posolda <mposolda at redhat.com>
> Gesendet: Montag, 25. M?rz 2019 12:25
> An: Sven-Torben Janus <sven-torben.janus at conciso.de>; 
> keycloak-dev at lists.jboss.org
> Betreff: Re: AW: AW: [keycloak-dev] X.509 User Identity Extractor - 
> multiple values
>
> On 22/03/2019 11:43, Sven-Torben Janus wrote:
>> Hey Marek,
>>
>> as far as I know, RFC 2587 specifies the usercertificate attribute for exactly that purpose. Active Directory also knows something similar (see https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-ada3/f9e923d6-c512-4beb-b963-afd695cea8ac).
> Thanks for pointing this. It seems it may be useful to have OOTB UserIdentityExtractor, which will work with the MSAD "userCertificate"
> attribute. So if you have a chance to contribute this, I think it will be fine.
>> IMHO matching the certificate against a custom LDAP attribute should also be ok. At least that is what the custom attribute mapper for the existing "user mapping method" is doing anyways for all the other user identity sources (like subjectDN, common name etc.), right?
> Maybe it is thin line, but in general, I see that having OOTB extractors, which are able to pair users based on subjectDN or commonName looks natural and will probably work for most of the people.
> Having something very specific like "issuer;serialNumber" is IMO not generally useful, so I would rather avoid to have the UserIdentityExtractor in Keycloak OOTB.
>
> Marek
>> Regards
>> Sven-Torben
>>
>> -----Urspr?ngliche Nachricht-----
>> Von: Marek Posolda <mposolda at redhat.com>
>> Gesendet: Freitag, 22. M?rz 2019 10:20
>> An: Sven-Torben Janus <sven-torben.janus at conciso.de>; 
>> keycloak-dev at lists.jboss.org
>> Betreff: Re: AW: [keycloak-dev] X.509 User Identity Extractor - 
>> multiple values
>>
>> Thanks for the clarification
>>
>> TBH It seems to me that probably even (b) won't be very generally useful. Unless for example some LDAP servers store the certificate PEM in some standard LDAP attribute of the user? But if it's customization of LDAP schema specific to your environment to be able to save the certificate PEM in the LDAP attribute, then my vote is to not add it.
>>
>> Marek
>>
>> On 21/03/2019 17:18, Sven-Torben Janus wrote:
>>> Hi Marek,
>>>
>>> I agree to your thoughts on solution a). That's basically why I wanted to discuss it here, before starting an implementation.
>>> Regarding, solution b), yes that is what I thought about (with or without the initial/final lines).
>>>
>>> Sven-Torben
>>>
>>> -----Urspr?ngliche Nachricht-----
>>> Von: Marek Posolda <mposolda at redhat.com>
>>> Gesendet: Donnerstag, 21. M?rz 2019 10:54
>>> An: Sven-Torben Janus <sven-torben.janus at conciso.de>; 
>>> keycloak-dev at lists.jboss.org
>>> Betreff: Re: [keycloak-dev] X.509 User Identity Extractor - multiple 
>>> values
>>>
>>> Hi,
>>>
>>> The solution (a) looks quite specific to the environment and I don't think that it will be useful to have this as a generic feature in Keycloak.. Solution (b) looks like bit more generally useful, but still not 100% sure about adding it to Keycloak... For the solution (b), are you talking about the PEM String representation of the X509 certificate, which just excludes the initial and final lines (Those with "BEGIN CERTIFICATE" and "END CERTIFICATE" )?
>>>
>>> Marek
>>>
>>> On 21/03/2019 07:48, Sven-Torben Janus wrote:
>>>> Hey all!
>>>>
>>>> I am currently facing a situation with a customer who wants to implement mutual SSL / client cert authentication. As I understand from the UserIdentityExtractor[1] implementations, currently only returning a single value is allowed, because the UserIdentityToModelMapper[2] calls toString on the actual userIdentity object.
>>>>
>>>> Now my customer uses the serial number from the certificate to identify users. However, this is only unique in combination with the issuer of the certificate, since my customer supports multiple CAs. The combination of both exists in their LDAP as a single attribute where both parts are separated by a special separator character.
>>>> In addition to that, the whole certificate of the user is also available in another LDAP attribute.
>>>>
>>>> I currently see the following options to implement a solution for this:
>>>> 1) Writing a custom Authenticator to handle that specific situation.
>>>> This one would look very similar to the ootb X509 authenticator, 
>>>> but implements either a) or b) (see below)
>>>> 2) Making a contribution to Keycloak and extend the list of available UserIdentitiyExtractors.
>>>>
>>>> For both approaches two different implementations come to my mind:
>>>>
>>>> a) Adding an additional UserIdentitiyExtractor which combines the issuer and the serial number into a single string and use that as an identity.
>>>> b) Adding an additional UserIdentitiyExtractor which returns the whole certificate as the user's identity.
>>>>
>>>> We would prefer contributing to Keycloak, if such a contribution is welcome and meaningful.
>>>>
>>>> Do you have any advice on which way to go here?
>>>>
>>>> [1]https://github.com/keycloak/keycloak/blob/master/services/src/ma
>>>> i
>>>> n
>>>> /java/org/keycloak/authentication/authenticators/x509/UserIdentityE
>>>> x
>>>> t
>>>> ractor.java
>>>> [2]https://github.com/keycloak/keycloak/blob/master/services/src/ma
>>>> i
>>>> n
>>>> /java/org/keycloak/authentication/authenticators/x509/UserIdentityT
>>>> o
>>>> M
>>>> odelMapper.java#L57
>>>>
>>>> Regards
>>>> Sven-Torben
>>>>
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>



From alan.balbo at fairandsmart.com  Wed Apr 17 05:44:27 2019
From: alan.balbo at fairandsmart.com (Alan Balbo)
Date: Wed, 17 Apr 2019 11:44:27 +0200
Subject: [keycloak-dev] Javascript adapter: cordova implementation is broken
Message-ID: <CAL=sXf34g_W5o5Q4ndSXamfNc=01MeQv5KPvDuj-0P-NZ+iK7A@mail.gmail.com>

Hi,

I found an issue in the javascript adapter (
*adapters/oidc/js/src/main/resources/keycloak.js*) : the "*cordova*"
implementation is broken, and is also inconsistent with the other
implementations provided (both "*default*" and "*cordova-native*"):

1) The *register* method (l. *1324*) does not take an "*options*"
parameter, even though it uses it two lines below. It causes the execution
to stop and throw an error, breaking the authentication process. This is an
error induced by commit *f6125a25* (KEYCLOAK-6655)
2) If we look at other implementations of the same method (l. *1171* and l.
*1389*), both return a promise. But the cordova implementation does not,
resulting in an inconsistency that I find weird. This is a big issue when
writing typescript services on top of it (e.g. keycloak-angular).

I would suggest a fix for those issues, as it makes the cordova
implementation unusable. First and foremost it should take an "options "
parameter and the function could be rewritten to be consistent with the
other implementations, i.e. making it return a promise and parsing the
callback properly.

Let me know what you think. Maybe it should be two distinct issues (one for
the bug and one for the promise).

Regards,
Alan

From bruno at abstractj.org  Wed Apr 17 16:36:44 2019
From: bruno at abstractj.org (Bruno Oliveira)
Date: Wed, 17 Apr 2019 17:36:44 -0300
Subject: [keycloak-dev] Javascript adapter: cordova implementation is
 broken
In-Reply-To: <CAL=sXf34g_W5o5Q4ndSXamfNc=01MeQv5KPvDuj-0P-NZ+iK7A@mail.gmail.com>
References: <CAL=sXf34g_W5o5Q4ndSXamfNc=01MeQv5KPvDuj-0P-NZ+iK7A@mail.gmail.com>
Message-ID: <20190417203644.GA31383@abstractj.org>

Hi Alan, could you please file a bug reporting the affected version and
also all the steps the reproduce? If you have a PR for that, feel free
to attach in the same Jira.

Thank you.

On 2019-04-17, Alan Balbo wrote:
> Hi,
> 
> I found an issue in the javascript adapter (
> *adapters/oidc/js/src/main/resources/keycloak.js*) : the "*cordova*"
> implementation is broken, and is also inconsistent with the other
> implementations provided (both "*default*" and "*cordova-native*"):
> 
> 1) The *register* method (l. *1324*) does not take an "*options*"
> parameter, even though it uses it two lines below. It causes the execution
> to stop and throw an error, breaking the authentication process. This is an
> error induced by commit *f6125a25* (KEYCLOAK-6655)
> 2) If we look at other implementations of the same method (l. *1171* and l.
> *1389*), both return a promise. But the cordova implementation does not,
> resulting in an inconsistency that I find weird. This is a big issue when
> writing typescript services on top of it (e.g. keycloak-angular).
> 
> I would suggest a fix for those issues, as it makes the cordova
> implementation unusable. First and foremost it should take an "options "
> parameter and the function could be rewritten to be consistent with the
> other implementations, i.e. making it return a promise and parsing the
> callback properly.
> 
> Let me know what you think. Maybe it should be two distinct issues (one for
> the bug and one for the promise).
> 
> Regards,
> Alan
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

-- 

abstractj

From guillaume.houdmon at ariadnext.com  Thu Apr 18 03:11:57 2019
From: guillaume.houdmon at ariadnext.com (Guillaume HOUDMON)
Date: Thu, 18 Apr 2019 09:11:57 +0200
Subject: [keycloak-dev] JWE support
Message-ID: <CAJPL6N5XD+Lvu=wPCLdpYhAq+A3LbbOxvwUT4qGc6yPmtXR=Nw@mail.gmail.com>

Hi,

We are currently studying how to encrypt tokens with JWE. There is the JIRA
KEYCLOAK-6768 that addresses this topic. But it does not seem that there
was any work to start on it.

A beginning of support has already been done to encrypt the code (see
KEYCLOAK-5288).

Inspired by what is done for the signature, I plan to add a section in the
client page "Encryption Tokens Configuration" to select the algorithms by
types of tokens, and set the encryption key (paste or jwks url).
We would add 2 SPIs: jwe-key-encryption and jwe-content-encryption.

With my colleagues, we would complete the algorithms (RSA-OAEP,
RSA-OAEP-256 and A128GCM, A192GCM, A256GCM).

In a second step, we could also contribute for the support in Java adapters.

Does this approach seem relevant to you?
Should we go through a design proposal?

Regards,
Guillaume Houdmon

From demetrio at carretti.pro  Thu Apr 18 19:18:46 2019
From: demetrio at carretti.pro (Dmitry Telegin)
Date: Fri, 19 Apr 2019 02:18:46 +0300
Subject: [keycloak-dev] Proposal: more flexible brokered identity with SAML
	IdP
Message-ID: <1555629526.8282.2.camel@carretti.pro>

Background
==========

Consider the problem: we are preparing a Keycloak deployment with the
following properties:
- users come from LDAP/AD, self-registration disabled;
- vast majority of the users will be authenticating via a 3rd party
SAML IdP that shares user DB with our Keycloak.

To make onboarding easier, we want to free the users from the need to
manually link their accounts with the IdP, by mass pre-creating the
links programmatically using Admin REST API.

In theory, this should be doable by issuing a POST to
users/{id}/federated-identity/saml, passing IdP's userId and userName,
which should create and persist a FederatedIdentity instance.

In practice, we're hitting a roadblock because of how SAML brokered
identities are implemented in Keycloak.

Problem
=======

Currently, it is hardcoded [1] that FederatedIdentity's userId and
userName should be taken verbatim from SAML assertion's NameID value
(via intermediary BrokeredIdentityContext). The problem is that most
SAML IdPs provide meaningless NameIDs, like hashes or purely random
strings. In general, SAML NameID is not predictable. To make things
worse, NameID can be different for SPs, so we can't simply peek it in
another application already integrated with the IdP.

OTOH, incoming assertion is guaranteed to contain other attributes that
are well-known to us and uniquely identify the user, like e.g. mobile
phone number.

[1] https://github.com/keycloak/keycloak/blob/master/services/src/main/
java/org/keycloak/broker/saml/SAMLEndpoint.java#L398?

Solution
========

The problem could be solved by introducing a configurable (and thus
more flexible) mechanism to map SAML assertions to FederatedIdentities.
With that, we could instruct Keycloak to take userId and userName from
arbitrary assertion attributes, or even complex expression, similar to
what we have in UsernameTemplateMapper.

Questions are:
1. From what I've learned, this should be doable with the help of a
custom IdP mapper, using preprocessFederatedIdentity() method. Is that
correct?
2. Regardless of the answer to 1, would Keycloak team welcome this
contribution?

Some thoughts not directly related to this particular problem; from my
3+ years experience with Keycloak and its corporate users, I can surely
tell that SAML under no circumstances should be considered either
legacy or obsolete. It is *very* actively used in the areas like
fintech, education and healthcare. I'd myself be happy to see Keycloak
become 1st class SAML IdP/broker, and going to do my best to make it
happen. I'm particularly interested in improving SAML/OIDC
interoperability in terms of IdP-initiated SSO and token exchange.

Best regards,
Dmitry


From demetrio at carretti.pro  Thu Apr 18 19:32:55 2019
From: demetrio at carretti.pro (Dmitry Telegin)
Date: Fri, 19 Apr 2019 02:32:55 +0300
Subject: [keycloak-dev] Keycloak at JavaZone'2019
Message-ID: <1555630375.8282.4.camel@carretti.pro>

Hi all,

I'm planning to do a talk at JavaZone'2019 in Oslo. Just wanted to know if anybody from the team/community is also going to participate, and, if so, to make sure our topics do not clash.

I'm about to submit a talk tentatively titled "Mastering Keycloak-fu", in which I'd like to summarize a dozen of interesting and non-standard cases from my own practice. I'll be also applying for a workshop, in which we'll be either securing a sample application, or developing a Keycloak extension, depending on the audience's interest and demand.

Just FYI: call for speakers remains open until April 22nd.

Cheers,
Dmitry


From cedric at couralet.eu  Fri Apr 19 07:21:15 2019
From: cedric at couralet.eu (=?UTF-8?Q?C=C3=A9dric_Couralet?=)
Date: Fri, 19 Apr 2019 13:21:15 +0200
Subject: [keycloak-dev] Keycloak 6.0.0 docker image
Message-ID: <b06f03f1fa4038c3ec55cc68853a6821@couralet.eu>

Hi all,

I saw the 6.0.0 was released on your website, but I don't see the tag on 
dockerhub or quay.io.
Is there an estimated time for it to be available?

Regards,
C?dric Couralet

From chris.smith at cmfirstgroup.com  Tue Apr 23 02:50:22 2019
From: chris.smith at cmfirstgroup.com (Chris Smith)
Date: Tue, 23 Apr 2019 06:50:22 +0000
Subject: [keycloak-dev] Setup Eclipse and workspace for Keycloak development
Message-ID: <CY4PR22MB0248DF52400C4E69DB341B0098230@CY4PR22MB0248.namprd22.prod.outlook.com>

I have a new JEE Eclipse 2019-06 with Redhat and Spring installed from the marketplace

I check out from Github into a new workspace

I have a large list of errors

46 JPA problem errors
36 JSP problem errors
68 Java build path errors
42 Java errors
426 Maven Problems

I thought Maven was supposed to prevent this?
I could not find any directions to setup Eclipse and the workspace.  Did I miss it?

How do the Redhat developers have their IDE and workspace setup?



From Jo0815 at gmx.de  Tue Apr 23 03:19:30 2019
From: Jo0815 at gmx.de (the john)
Date: Tue, 23 Apr 2019 09:19:30 +0200
Subject: [keycloak-dev] Themes: Browser cache not used for static resources
	(img, css, js)
Message-ID: <trinity-506dc7cf-8b06-4da0-b80c-e7314048f49f-1556003970291@3c-app-gmx-bs36>


From sblanc at redhat.com  Tue Apr 23 09:08:18 2019
From: sblanc at redhat.com (Sebastien Blanc)
Date: Tue, 23 Apr 2019 15:08:18 +0200
Subject: [keycloak-dev] Keycloak at JavaZone'2019
In-Reply-To: <1555630375.8282.4.camel@carretti.pro>
References: <1555630375.8282.4.camel@carretti.pro>
Message-ID: <CAMZCGg81cVvZhetsLF_Q8kCb1vhLfRX4ePPUnU7pcn1Fqo6Weg@mail.gmail.com>

I submitted a talk "Easily secure your microservices with Keycloak"

On Fri, Apr 19, 2019 at 1:34 AM Dmitry Telegin <demetrio at carretti.pro>
wrote:

> Hi all,
>
> I'm planning to do a talk at JavaZone'2019 in Oslo. Just wanted to know if
> anybody from the team/community is also going to participate, and, if so,
> to make sure our topics do not clash.
>
> I'm about to submit a talk tentatively titled "Mastering Keycloak-fu", in
> which I'd like to summarize a dozen of interesting and non-standard cases
> from my own practice. I'll be also applying for a workshop, in which we'll
> be either securing a sample application, or developing a Keycloak
> extension, depending on the audience's interest and demand.
>
> Just FYI: call for speakers remains open until April 22nd.
>
> Cheers,
> Dmitry
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From chris.smith at cmfirstgroup.com  Tue Apr 23 12:08:03 2019
From: chris.smith at cmfirstgroup.com (Chris Smith)
Date: Tue, 23 Apr 2019 16:08:03 +0000
Subject: [keycloak-dev] mvn install fails
Message-ID: <CY4PR22MB0248D34B6173C3724ACBD94A98230@CY4PR22MB0248.namprd22.prod.outlook.com>

A fresh clone from Github and mvn install fails to complete.
Any reason why?

Tests run: 2860, Failures: 0, Errors: 22, Skipped: 211

[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary for Keycloak 7.0.0-SNAPSHOT:
[INFO]
[INFO] Keycloak BOM Parent ................................ SUCCESS [ 11.402 s]
[INFO] Keycloak BOM for adapters .......................... SUCCESS [  0.111 s]
[INFO] Keycloak BOM for server extensions ................. SUCCESS [  0.105 s]
[INFO] Keycloak BOM utilities for the quickstarts ......... SUCCESS [  0.098 s]
[INFO] Keycloak ........................................... SUCCESS [  1.655 s]
[INFO] Keycloak Common .................................... SUCCESS [ 15.064 s]
[INFO] Keycloak Core ...................................... SUCCESS [ 12.195 s]
[INFO] Keycloak Dependencies Parent ....................... SUCCESS [  0.130 s]
[INFO] Keycloak Drools BOM ................................ SUCCESS [  0.129 s]
[INFO] Keycloak Server SPI ................................ SUCCESS [  3.287 s]
[INFO] Keycloak Server Private SPI ........................ SUCCESS [  8.419 s]
[INFO] Keycloak Kerberos Federation ....................... SUCCESS [  0.910 s]
[INFO] Keycloak LDAP UserStoreProvider .................... SUCCESS [  7.065 s]
[INFO] Keycloak SAML Core Public API ...................... SUCCESS [  2.849 s]
[INFO] Keycloak SAML Core ................................. SUCCESS [  9.528 s]
[INFO] Keycloak REST Services ............................. SUCCESS [ 25.199 s]
[INFO] Keycloak JS Integration ............................ SUCCESS [  5.176 s]
[INFO] Keycloak Themes .................................... SUCCESS [  9.625 s]
[INFO] Keycloak Dependencies Server Min ................... SUCCESS [  0.139 s]
[INFO] Keycloak Model Parent .............................. SUCCESS [  0.139 s]
[INFO] Keycloak Model JPA ................................. SUCCESS [  7.185 s]
[INFO] Keycloak Model Infinispan .......................... SUCCESS [ 13.296 s]
[INFO] Keycloak SSSD Federation ........................... SUCCESS [  5.565 s]
[INFO] KeyCloak Authz: Parent ............................. SUCCESS [  0.222 s]
[INFO] KeyCloak AuthZ: Provider Parent .................... SUCCESS [  0.182 s]
[INFO] KeyCloak AuthZ: Common Policy Providers ............ SUCCESS [  2.537 s]
[INFO] KeyCloak AuthZ: Drools Policy Provider ............. SUCCESS [  1.934 s]
[INFO] Keycloak Dependencies Server All ................... SUCCESS [  0.195 s]
[INFO] Keycloak Federation ................................ SUCCESS [  0.220 s]
[INFO] Keycloak Util Embedded LDAP ........................ SUCCESS [  3.089 s]
[INFO] Keycloak Util Parent ............................... SUCCESS [  0.209 s]
[INFO] Keycloak WildFly Integration ....................... SUCCESS [  0.184 s]
[INFO] Keycloak WildFly Add User Script ................... SUCCESS [  1.151 s]
[INFO] Keycloak WildFly Extensions ........................ SUCCESS [  1.184 s]
[INFO] Keycloak WildFly Server Subsystem .................. SUCCESS [  8.763 s]
[INFO] Keycloak Integration ............................... SUCCESS [  0.133 s]
[INFO] Keycloak Admin REST Client ......................... SUCCESS [  1.111 s]
[INFO] Keycloak Client Registration API ................... SUCCESS [  0.736 s]
[INFO] Keycloak Client CLI ................................ SUCCESS [  0.133 s]
[INFO] Keycloak Client Registration CLI ................... SUCCESS [  6.737 s]
[INFO] Keycloak Admin CLI ................................. SUCCESS [  5.972 s]
[INFO] Keycloak Client CLI Distribution ................... SUCCESS [  3.475 s]
[INFO] Keycloak Adapter SPI ............................... SUCCESS [  0.939 s]
[INFO] Keycloak Tomcat Adapter SPI ........................ SUCCESS [  0.822 s]
[INFO] Keycloak Undertow Integration SPI .................. SUCCESS [  1.166 s]
[INFO] Keycloak Servlet Integration ....................... SUCCESS [  0.828 s]
[INFO] Common JBoss/Wildfly Core Classes .................. SUCCESS [  0.591 s]
[INFO] Keycloak Jetty Adapter SPI ......................... SUCCESS [  0.928 s]
[INFO] Keycloak Client Adapter SPI Modules ................ SUCCESS [  0.163 s]
[INFO] Keycloak SAML Client Adapter Public API ............ SUCCESS [  0.621 s]
[INFO] Keycloak SAML Client Adapter Core .................. SUCCESS [  5.196 s]
[INFO] Keycloak Undertow SAML Adapter ..................... SUCCESS [  1.009 s]
[INFO] Keycloak SAML Tomcat Integration ................... SUCCESS [  0.165 s]
[INFO] Keycloak Tomcat Core SAML Integration .............. SUCCESS [  0.839 s]
[INFO] Keycloak Tomcat 8 SAML Integration ................. SUCCESS [  0.743 s]
[INFO] Keycloak Tomcat 6 Saml Integration ................. SUCCESS [  0.617 s]
[INFO] Keycloak Tomcat 7 SAML Integration ................. SUCCESS [  0.625 s]
[INFO] Keycloak Wildfly SAML Adapter ...................... SUCCESS [  0.999 s]
[INFO] KeyCloak Authz: Client API ......................... SUCCESS [  1.963 s]
[INFO] Keycloak Adapter Core .............................. SUCCESS [  6.558 s]
[INFO] Keycloak WildFly Elytron SAML Adapter .............. SUCCESS [  1.130 s]
[INFO] Keycloak Wildfly SAML Adapter Subsystem ............ SUCCESS [  7.527 s]
[INFO] Keycloak SAML Wildfly Integration .................. SUCCESS [  0.146 s]
[INFO] Keycloak AS7 / JBoss EAP 6 Integration ............. SUCCESS [  0.183 s]
[INFO] Keycloak AS7 SPI ................................... SUCCESS [  3.170 s]
[INFO] Keycloak SAML EAP Integration ...................... SUCCESS [  0.130 s]
[INFO] Keycloak SAML AS7 Integration ...................... SUCCESS [  1.062 s]
[INFO] Keycloak SAML AS7 Subsystem ........................ SUCCESS [  5.323 s]
[INFO] Keycloak SAML Servlet Filter ....................... SUCCESS [  0.804 s]
[INFO] Keycloak Jetty Core SAML Integration ............... SUCCESS [  0.865 s]
[INFO] Keycloak Jetty 9.2.x SAML Integration .............. SUCCESS [  0.820 s]
[INFO] Keycloak Jetty 9.3.x SAML Integration .............. SUCCESS [  0.894 s]
[INFO] Keycloak Jetty 9.4.x SAML Integration .............. SUCCESS [  1.066 s]
[INFO] Keycloak SAML Jetty Integration .................... SUCCESS [  0.144 s]
[INFO] Keycloak SAML Client Adapter Modules ............... SUCCESS [  0.132 s]
[INFO] Keycloak Tomcat Integration ........................ SUCCESS [  0.140 s]
[INFO] Keycloak Tomcat Core Integration ................... SUCCESS [  0.758 s]
[INFO] Keycloak AS7 Integration ........................... SUCCESS [  0.906 s]
[INFO] Keycloak AS7 Subsystem ............................. SUCCESS [  4.368 s]
[INFO] Keycloak Installed Application ..................... SUCCESS [  1.609 s]
[INFO] Keycloak Undertow Integration ...................... SUCCESS [  2.295 s]
[INFO] Keycloak Fuse 7.0 Integration ...................... SUCCESS [  0.161 s]
[INFO] Keycloak Fuse 7.0 Adapter - Camel + Undertow ....... SUCCESS [  1.773 s]
[INFO] Keycloak OSGI Adapter .............................. SUCCESS [  3.531 s]
[INFO] Keycloak Fuse 7.0 Adapter - Undertow ............... SUCCESS [  1.514 s]
[INFO] Keycloak Jetty Core Integration .................... SUCCESS [  1.175 s]
[INFO] Keycloak Jetty 9.4.x Integration ................... SUCCESS [  0.945 s]
[INFO] Keycloak Fuse 7.0 Adapter - Jetty 9.4 .............. SUCCESS [  1.345 s]
[INFO] Keycloak Tomcat 8 Integration ...................... SUCCESS [  0.767 s]
[INFO] Keycloak Fuse 7.0 Adapter - Tomcat 8 ............... SUCCESS [  1.105 s]
[INFO] Keycloak CLI SSO Framework ......................... SUCCESS [  4.620 s]
[INFO] Keycloak JAX-RS OAuth Client ....................... SUCCESS [  1.314 s]
[INFO] Keycloak Jetty 9.2.x Integration ................... SUCCESS [  1.142 s]
[INFO] Keycloak Jetty 9.3.x Integration ................... SUCCESS [  1.144 s]
[INFO] Keycloak Jetty Integration ......................... SUCCESS [  0.173 s]
[INFO] Keycloak Servlet Filter Adapter Integration ........ SUCCESS [  1.061 s]
[INFO] Keycloak Servlet OAuth Client ...................... SUCCESS [  4.150 s]
[INFO] spring-boot-container-bundle ....................... SUCCESS [  1.761 s]
[INFO] Keycloak Spring Security Integration ............... SUCCESS [  8.449 s]
[INFO] Keycloak Spring Boot Adapter Core .................. SUCCESS [  1.759 s]
[INFO] Keycloak Spring Boot Integration ................... SUCCESS [  4.437 s]
[INFO] Keycloak Spring Boot 2 Integration ................. SUCCESS [  4.172 s]
[INFO] Keycloak Tomcat 6 Integration ...................... SUCCESS [  0.689 s]
[INFO] Keycloak Tomcat 7 Integration ...................... SUCCESS [  0.761 s]
[INFO] Keycloak Wildfly Integration ....................... SUCCESS [  0.998 s]
[INFO] Keycloak Wildfly Elytron OIDC Adapter .............. SUCCESS [  1.763 s]
[INFO] Keycloak Wildfly Adapter Subsystem ................. SUCCESS [  8.862 s]
[INFO] Keycloak Wildfly 8 Adapter Subsystem ............... SUCCESS [  5.703 s]
[INFO] Keycloak WildFly Integration ....................... SUCCESS [  0.138 s]
[INFO] Keycloak OIDC Client Adapter Modules ............... SUCCESS [  0.124 s]
[INFO] Keycloak Adapters .................................. SUCCESS [  0.130 s]
[INFO] Keycloak Misc ...................................... SUCCESS [  0.138 s]
[INFO] Keycloak :: Spring :: Boot ......................... SUCCESS [  0.148 s]
[INFO] Keycloak :: Spring :: Boot :: Default ::  Starter .. SUCCESS [  0.371 s]
[INFO] Keycloak :: Spring :: Boot ......................... SUCCESS [  0.139 s]
[INFO] Keycloak :: Legacy :: Spring :: Boot :: Default ::  Starter SUCCESS [  0.388 s]
[INFO] keycloak-test-helper ............................... SUCCESS [  0.937 s]
[INFO] Keycloak TestSuite ................................. SUCCESS [  0.128 s]
[INFO] DB Allocator Plugin ................................ SUCCESS [ 14.444 s]
[INFO] Keycloak Arquillian Integration TestSuite .......... SUCCESS [  0.212 s]
[INFO] Test apps .......................................... SUCCESS [  0.144 s]
[INFO] Test apps distribution ............................. SUCCESS [  7.201 s]
[INFO] Keycloak Authz: PhotoZ  Test Parent ................ SUCCESS [  0.145 s]
[INFO] Keycloak Authz Test: Photoz RESTful API ............ SUCCESS [  1.871 s]
[INFO] Keycloak Authz Tests: Photoz HTML5 Client .......... SUCCESS [  1.330 s]
[INFO] Keycloak Authz Tests: Photoz Authz Rule-based Policy SUCCESS [  0.442 s]
[INFO] Keycloak Authz Tests: Hello World Example .......... SUCCESS [  0.406 s]
[INFO] Keycloak Authz: Servlet Authorization Test ......... SUCCESS [  0.577 s]
[INFO] Keycloak Authz: Simple Servlet App with Policy Enforcer SUCCESS [  0.393 s]
[INFO] integration-arquillian-test-apps-servlets .......... SUCCESS [  1.327 s]
[INFO] Keycloak Test App Profile JEE ...................... SUCCESS [  0.638 s]
[INFO] integration-arquillian-test-apps-cors-parent ....... SUCCESS [  0.144 s]
[INFO] Angular Product Portal JS .......................... SUCCESS [  2.995 s]
[INFO] JAX-RS Database Service Using OAuth Bearer Tokens .. SUCCESS [  0.728 s]
[INFO] Fuse Test Applications ............................. SUCCESS [  0.139 s]
[INFO] Customer Portal - Secured in Karaf/Fuse ............ SUCCESS [  1.778 s]
[INFO] CXF JAXRS Example - Secured in Karaf/Fuse .......... SUCCESS [  2.099 s]
[INFO] CXF JAXRS Example - Secured in Karaf/Fuse 7.0 on Undertow SUCCESS [  0.798 s]
[INFO] CXF JAXWS Example - Secured in Karaf/Fuse .......... SUCCESS [  1.012 s]
[INFO] CXF JAXWS Example - Secured in Karaf/Fuse 7.0 on Undertow SUCCESS [  0.830 s]
[INFO] Product Portal - Secured in Karaf/Fuse ............. SUCCESS [  0.960 s]
[INFO] Product Portal - Secured in Karaf/Fuse 7.0 on Undertow SUCCESS [  1.012 s]
[INFO] Camel endpoint example - Secured in Karaf/Fuse ..... SUCCESS [  0.779 s]
[INFO] Camel endpoint example - Secured in Karaf/Fuse 7.0 on Undertow SUCCESS [  0.879 s]
[INFO] Keycloak Fuse Example - Features ................... SUCCESS [  0.670 s]
[INFO] Keycloak Examples - External Config ................ SUCCESS [  0.776 s]
[INFO] spring-boot-adapter ................................ SUCCESS [  1.358 s]
[INFO] spring-boot-adapter-2 .............................. SUCCESS [  1.571 s]
[INFO] spring-boot-adapter-21 ............................. SUCCESS [  1.435 s]
[INFO] Servers ............................................ SUCCESS [  0.152 s]
[INFO] Auth Server ........................................ SUCCESS [  0.127 s]
[INFO] Auth Server Services ............................... SUCCESS [  0.129 s]
[INFO] Auth Server Services - Testsuite Providers ......... SUCCESS [  5.076 s]
[INFO] Auth Server - JBoss ................................ SUCCESS [  0.131 s]
[INFO] Keycloak TestSuite Utils ........................... SUCCESS [  2.794 s]
[INFO] Test Util .......................................... SUCCESS [  1.798 s]
[INFO] Auth Server - Undertow ............................. SUCCESS [  2.305 s]
[INFO] App Server ......................................... SUCCESS [  0.137 s]
[INFO] App Server - SPI ................................... SUCCESS [  0.541 s]
[INFO] App Server - JBoss ................................. SUCCESS [  0.132 s]
[INFO] App Server - Karaf ................................. SUCCESS [  0.127 s]
[INFO] App Server - Tomcat ................................ SUCCESS [  0.130 s]
[INFO] App Server - Undertow .............................. SUCCESS [  1.122 s]
[INFO] App Server - Jetty Parent .......................... SUCCESS [  0.151 s]
[INFO] Cache Server ....................................... SUCCESS [  0.119 s]
[INFO] Cache Server - JBoss Family ........................ SUCCESS [  0.124 s]
[INFO] Tests .............................................. SUCCESS [  0.493 s]
[INFO] Base TestSuite ..................................... FAILURE [  01:45 h]
[INFO] Other Tests Modules ................................ SKIPPED
[INFO] Adapter Tests ...................................... SKIPPED
[INFO] Adapter Tests - JBoss .............................. SKIPPED
[INFO] Adapter Tests - Karaf .............................. SKIPPED
[INFO] Adapter Tests - WAS ................................ SKIPPED
[INFO] Adapter Tests - WLS ................................ SKIPPED
[INFO] SSSD tests ......................................... SKIPPED
[INFO] integration-arquillian-tests-springboot ............ SKIPPED
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  01:51 h
[INFO] Finished at: 2019-04-23T19:51:55+08:00
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test (default-test) on project integration-arquillian-tests-base: There are test failures.
[ERROR]
[ERROR] Please refer to C:\Users\christopher.smith\Documents\keycloak\workspace\keycloak-parent\testsuite\integration-arquillian\tests\base\target\surefire-reports for the individual test results.
[ERROR] -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
[ERROR]
[ERROR] After correcting the problems, you can resume the build with the command
[ERROR]   mvn <goals> -rf :integration-arquillian-tests-base

C:\Users\christopher.smith\Documents\keycloak\workspace\keycloak-parent>

From sblanc at redhat.com  Tue Apr 23 12:12:08 2019
From: sblanc at redhat.com (Sebastien Blanc)
Date: Tue, 23 Apr 2019 18:12:08 +0200
Subject: [keycloak-dev] Keycloak 6.0.0 docker image
In-Reply-To: <b06f03f1fa4038c3ec55cc68853a6821@couralet.eu>
References: <b06f03f1fa4038c3ec55cc68853a6821@couralet.eu>
Message-ID: <CAMZCGg_8VfoGpg-p7TewHgG2v5n1fpq9YJcVeM4+4ROAg9FrXg@mail.gmail.com>

Hi C?dric !

Images should be there now.

Seb


On Fri, Apr 19, 2019 at 1:25 PM C?dric Couralet <cedric at couralet.eu> wrote:

> Hi all,
>
> I saw the 6.0.0 was released on your website, but I don't see the tag on
> dockerhub or quay.io.
> Is there an estimated time for it to be available?
>
> Regards,
> C?dric Couralet
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From jo0815 at gmx.de  Tue Apr 23 14:09:35 2019
From: jo0815 at gmx.de (jo0815)
Date: Tue, 23 Apr 2019 20:09:35 +0200
Subject: [keycloak-dev] Themes: Browser cache not used for static resources
	(img, css, js)
Message-ID: <06df942d-fa75-3395-f1f6-1edc2e8d2dfa@gmx.de>

Hello,

I've been deveoping custom keycloak themes which is pretty straight
forward thanks to the provided documentation.
I am using version 4.8.3.Final.

Regarding caching I only see options for freemarker templates caching in
standalon.xml, theme section.
Opening the network view in Firefox I notice that no caching headers are
uses for statice resouces (img, css, js).
Thus every visit of the login page reloads all linked static resources
from the server.

So my question is:
How can I provide client side caching of static resources (perhaps by
etags with file content hash)?


Thanks
Jonathan Strampp



From cedric at couralet.eu  Tue Apr 23 15:12:48 2019
From: cedric at couralet.eu (=?utf-8?q?cedric=40couralet=2Eeu?=)
Date: Tue, 23 Apr 2019 21:12:48 +0200
Subject: [keycloak-dev] =?utf-8?q?Keycloak_6=2E0=2E0_docker_image?=
In-Reply-To: <CAMZCGg_8VfoGpg-p7TewHgG2v5n1fpq9YJcVeM4+4ROAg9FrXg@mail.gmail.com>
Message-ID: <5156-5cbf6380-15-67de400@150806237>

yes, thank you !

C?dric


Le Mardi, Avril 23, 2019 18:12 CEST, Sebastien Blanc <sblanc at redhat.com> a ?crit: 
 
> Hi C?dric !
> 
> Images should be there now.
> 
> Seb
> 
> 
> On Fri, Apr 19, 2019 at 1:25 PM C?dric Couralet <cedric at couralet.eu> wrote:
> 
> > Hi all,
> >
> > I saw the 6.0.0 was released on your website, but I don't see the tag on
> > dockerhub or quay.io.
> > Is there an estimated time for it to be available?
> >
> > Regards,
> > C?dric Couralet
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev



From liqiang at fit2cloud.com  Wed Apr 24 03:19:44 2019
From: liqiang at fit2cloud.com (=?UTF-8?B?5byg56uL5by6?=)
Date: Wed, 24 Apr 2019 15:19:44 +0800
Subject: [keycloak-dev] Keycloak Cluster Setup And Configuration
In-Reply-To: <CAOHSYr74xNmg=au6w-9Oc_N+f3SM-eDF+jPAW=j=bWMfDkP+jg@mail.gmail.com>
References: <CAOHSYr5-jHbUc8YUiun=GLVaQFCSdny=S50wWrXkoOUQ4C3jUg@mail.gmail.com>
	<CAOHSYr74xNmg=au6w-9Oc_N+f3SM-eDF+jPAW=j=bWMfDkP+jg@mail.gmail.com>
Message-ID: <CAOHSYr4oN2CdKUa_p5OuVm1kFLRW2LZ3sjgbd5Kr_NLjvqQy1Q@mail.gmail.com>

Hi there,

I am writing this mail just for knowledge sharing, through lots of efforts
we achieved keycloak cluster setting in some scenes, maybe you guys have
done this by some solutions but hope this can help you anyway.
We are using 4.8.3.Final docker image in our deployment, using this version
because RH-SSO 7.3.0.GA is derived from 4.8.3.Final(please refer to
https://www.keycloak.org/support.html) and we believe this is a rather
stable build.
Also we did some extensions(custom theme, custom user federation, but the
two cli script files is the most important matter for this mail, attached
you can find the two files) base on the official docker image
<https://hub.docker.com/r/jboss/keycloak/>.
[image: QQ20190424-151432 (1).jpg]

First of all we have to know that for a keycloak cluster, all keycloak
instances should use same database and this is very simple, another thing
is about cache(generally there are two kinds of cache in keycloak, 1st is
persistent data cache read from database aim to improve performance like
realm/client/user, 2nd is the non-persistent data cache like
sessions/clientSessions, the 2nd is very important for a cluster) which is
a little bit complex to configure, we have to make sure the consistent of
cache data in a cluster view.
Totally we have 3 solutions for clustering, and all of the solutions are
base on the discovery protocols of JGroups <http://jgroups.org/>, as
keycloak use a distributed cache called Infinispan <http://infinispan.org/>
and the Infinispan use JGroups to discover nodes.

1. PING
PING <http://jgroups.org/manual/#PING> is the default enabled clustering
solution of keycloak using UDP protocol, and you don't need to do any
configuration for this.
But this solution is only available when multicast network is enabled and
port 55200 should be exposed, e.g. bare metals, VMs, docker containers in
same host.
[image: image.png]
We tested this by two keycloak containers in same host.
[image: QQ20190424-150949 (1).jpg]

As you see from logs, after started the two keycloak instances discovered
each other and clustered.

2. TCPPING
TCPPING <http://jgroups.org/manual/#TCPPING_Prot> use TCP protocol and 7600
port should be exposed.
This solution can be used when multicast is not available, e.g. deployments
cross DC, containers cross host.
We tested this by two keycloak containers cross host.
[image: image.png]
And for our own solution we need to set three below environment variables
for containers.
*#IP address of this host*
*JGROUPS_DISCOVERY_EXTERNAL_IP=172.21.48.39*
*#protocol*
*JGROUPS_DISCOVERY_PROTOCOL=TCPPING*
*#IP and Port of all host*
*JGROUPS_DISCOVERY_PROPERTIES=initial_hosts="172.21.48.4[7600],172.21.48.39[7600]"*
After started we can see the keycloak instances discovered each other and
clustered.
[image: QQ20190424-150720 (1).jpg]

3. JDBC_PING
JDBC_PING <http://jgroups.org/manual/#_jdbc_ping> use TCP protocol and 7600
port should be expose which is similar as TCPPING, but the difference
between them is, TCPPING require you configure the IP and port of all
instances,  for JDBC_PING you just need to configure the IP and port of
current instance, this is because in JDBC_PING solution each instance
insert its own information into database and the instances discover peers
by the ping data which is from database.
We tested this by two keycloak containers cross host.
[image: image.png]
And for our own solution we need to set two below environment variables for
containers.
*#IP address of this host*
*JGROUPS_DISCOVERY_EXTERNAL_IP=172.21.48.39*
*#protocol*
*JGROUPS_DISCOVERY_PROTOCOL=JDBC_PING*
After started the ping data of all instances haven been saved in database,
and from logs we can see the keycloak instances discovered each other and
clustered.
[image: image.png]
[image: QQ20190424-151128 (1).jpg]

-----
I believe the above solutions is available for most scenes, but for some
scene this is enough, e.g. kubernetes.
In kubernetes, multicast is available only for the containers in same node,
for the pods cross node multicast is not working, furthermore for a pod
there is no static ip that you can use to configure TCPPING or JDBC_PING.
But that's ok because we can use KUBE_PING
<http://jgroups.org/manual/#_kube_ping> in kubernetes. And also don't
worry, KUBE_PING is not the only choice, actually JDBC_PING is another
option. In the attached JDBC_PING.cli we have handled this,  if you don't
set the JGROUPS_DISCOVERY_EXTERNAL_IP environment variable, the pod ip will
be used, that means in kubernetes you can just set
JGROUPS_DISCOVERY_PROTOCOL=JDBC_PING then your keycloak cluster is ok.


----MAIL END----

???

?????, FIT2CLOUD


????????????????????? ??? ? ??? ? ???
-------------- next part --------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 18324 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20190424/90daf0c2/attachment-0003.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 8762 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20190424/90daf0c2/attachment-0004.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 39242 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20190424/90daf0c2/attachment-0005.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: QQ20190424-150720 (1).jpg
Type: image/jpeg
Size: 154243 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20190424/90daf0c2/attachment-0004.jpg 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: QQ20190424-150949 (1).jpg
Type: image/jpeg
Size: 150139 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20190424/90daf0c2/attachment-0005.jpg 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: QQ20190424-151128 (1).jpg
Type: image/jpeg
Size: 138614 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20190424/90daf0c2/attachment-0006.jpg 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: QQ20190424-151432 (1).jpg
Type: image/jpeg
Size: 47830 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20190424/90daf0c2/attachment-0007.jpg 

From sthorger at redhat.com  Wed Apr 24 04:12:59 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 24 Apr 2019 10:12:59 +0200
Subject: [keycloak-dev] Versioning Scheme for Keycloak
In-Reply-To: <67f0cab3a7824d70b2aa2fc2a3ffc0e4@bosch-si.com>
References: <67f0cab3a7824d70b2aa2fc2a3ffc0e4@bosch-si.com>
Message-ID: <CAJgngAdBc3E_otZzGJp78MxOnHmaA8yQoOzP+VqBqm-R3+OuOQ@mail.gmail.com>

Will explain this soon through a blog post.

On Tue, 16 Apr 2019 at 09:11, Schuster Sebastian (INST-CSS/BSV-OS2) <
Sebastian.Schuster at bosch-si.com> wrote:

> Hi everybody,
>
> I noticed the versioning scheme was changed lately. There are no more
> x.Final versions anymore. Also, after releasing 5.0.0 the next version was
> switched to 6.0.0-Snapshot.
> Are these changes purely cosmetical? Will there be no more minor/patch
> releases according to semantic versioning? Is there a relation to a changed
> release schedule for Red Hat SSO?
>
> Can anybody shed some light on what these changes mean?
>
> Thanks and best regards,
> Sebastian
>
>
> Mit freundlichen Gr??en / Best regards
>
> Dr.-Ing. Sebastian Schuster
>
> Open Source Services (INST-CSS/BSV-OS2)
> Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin |
> GERMANY | www.bosch-si.com<http://www.bosch-si.com>
> Tel. +49 30 726112-485 | Mobil +49 152 02177668 | Fax +49 30 726112-100 |
> Sebastian.Schuster at bosch-si.com<mailto:Sebastian.Schuster at bosch-si.com>
>
> Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
> Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten L?cke; Gesch?ftsf?hrung: Dr.
> Stefan Ferber, Michael Hahn, Dr. Aleksandar Mitrovic
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From sthorger at redhat.com  Wed Apr 24 04:17:30 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 24 Apr 2019 10:17:30 +0200
Subject: [keycloak-dev] Themes: Browser cache not used for static
 resources (img, css, js)
In-Reply-To: <06df942d-fa75-3395-f1f6-1edc2e8d2dfa@gmx.de>
References: <06df942d-fa75-3395-f1f6-1edc2e8d2dfa@gmx.de>
Message-ID: <CAJgngAco3SypiUBKWsLBVOKYT-zrxAOKbLNor_s+_5NG+TdEdQ@mail.gmail.com>

Not sure why you are saying resources are not cached as they are. Just look
at resources loaded by the default theme.

On Tue, 23 Apr 2019 at 20:29, jo0815 <jo0815 at gmx.de> wrote:

> Hello,
>
> I've been deveoping custom keycloak themes which is pretty straight
> forward thanks to the provided documentation.
> I am using version 4.8.3.Final.
>
> Regarding caching I only see options for freemarker templates caching in
> standalon.xml, theme section.
> Opening the network view in Firefox I notice that no caching headers are
> uses for statice resouces (img, css, js).
> Thus every visit of the login page reloads all linked static resources
> from the server.
>
> So my question is:
> How can I provide client side caching of static resources (perhaps by
> etags with file content hash)?
>
>
> Thanks
> Jonathan Strampp
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sthorger at redhat.com  Wed Apr 24 04:18:24 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 24 Apr 2019 10:18:24 +0200
Subject: [keycloak-dev] mvn install fails
In-Reply-To: <CY4PR22MB0248D34B6173C3724ACBD94A98230@CY4PR22MB0248.namprd22.prod.outlook.com>
References: <CY4PR22MB0248D34B6173C3724ACBD94A98230@CY4PR22MB0248.namprd22.prod.outlook.com>
Message-ID: <CAJgngAd+8scfeMsKg6bdfwqd+RwK7Uw4yC1gDLd4NpcDtOnBOg@mail.gmail.com>

Looks like some test is failing, but you've not included the relevant part
of the log that shows details of what test is failing.

On Tue, 23 Apr 2019 at 18:46, Chris Smith <chris.smith at cmfirstgroup.com>
wrote:

> A fresh clone from Github and mvn install fails to complete.
> Any reason why?
>
> Tests run: 2860, Failures: 0, Errors: 22, Skipped: 211
>
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Reactor Summary for Keycloak 7.0.0-SNAPSHOT:
> [INFO]
> [INFO] Keycloak BOM Parent ................................ SUCCESS [
> 11.402 s]
> [INFO] Keycloak BOM for adapters .......................... SUCCESS [
> 0.111 s]
> [INFO] Keycloak BOM for server extensions ................. SUCCESS [
> 0.105 s]
> [INFO] Keycloak BOM utilities for the quickstarts ......... SUCCESS [
> 0.098 s]
> [INFO] Keycloak ........................................... SUCCESS [
> 1.655 s]
> [INFO] Keycloak Common .................................... SUCCESS [
> 15.064 s]
> [INFO] Keycloak Core ...................................... SUCCESS [
> 12.195 s]
> [INFO] Keycloak Dependencies Parent ....................... SUCCESS [
> 0.130 s]
> [INFO] Keycloak Drools BOM ................................ SUCCESS [
> 0.129 s]
> [INFO] Keycloak Server SPI ................................ SUCCESS [
> 3.287 s]
> [INFO] Keycloak Server Private SPI ........................ SUCCESS [
> 8.419 s]
> [INFO] Keycloak Kerberos Federation ....................... SUCCESS [
> 0.910 s]
> [INFO] Keycloak LDAP UserStoreProvider .................... SUCCESS [
> 7.065 s]
> [INFO] Keycloak SAML Core Public API ...................... SUCCESS [
> 2.849 s]
> [INFO] Keycloak SAML Core ................................. SUCCESS [
> 9.528 s]
> [INFO] Keycloak REST Services ............................. SUCCESS [
> 25.199 s]
> [INFO] Keycloak JS Integration ............................ SUCCESS [
> 5.176 s]
> [INFO] Keycloak Themes .................................... SUCCESS [
> 9.625 s]
> [INFO] Keycloak Dependencies Server Min ................... SUCCESS [
> 0.139 s]
> [INFO] Keycloak Model Parent .............................. SUCCESS [
> 0.139 s]
> [INFO] Keycloak Model JPA ................................. SUCCESS [
> 7.185 s]
> [INFO] Keycloak Model Infinispan .......................... SUCCESS [
> 13.296 s]
> [INFO] Keycloak SSSD Federation ........................... SUCCESS [
> 5.565 s]
> [INFO] KeyCloak Authz: Parent ............................. SUCCESS [
> 0.222 s]
> [INFO] KeyCloak AuthZ: Provider Parent .................... SUCCESS [
> 0.182 s]
> [INFO] KeyCloak AuthZ: Common Policy Providers ............ SUCCESS [
> 2.537 s]
> [INFO] KeyCloak AuthZ: Drools Policy Provider ............. SUCCESS [
> 1.934 s]
> [INFO] Keycloak Dependencies Server All ................... SUCCESS [
> 0.195 s]
> [INFO] Keycloak Federation ................................ SUCCESS [
> 0.220 s]
> [INFO] Keycloak Util Embedded LDAP ........................ SUCCESS [
> 3.089 s]
> [INFO] Keycloak Util Parent ............................... SUCCESS [
> 0.209 s]
> [INFO] Keycloak WildFly Integration ....................... SUCCESS [
> 0.184 s]
> [INFO] Keycloak WildFly Add User Script ................... SUCCESS [
> 1.151 s]
> [INFO] Keycloak WildFly Extensions ........................ SUCCESS [
> 1.184 s]
> [INFO] Keycloak WildFly Server Subsystem .................. SUCCESS [
> 8.763 s]
> [INFO] Keycloak Integration ............................... SUCCESS [
> 0.133 s]
> [INFO] Keycloak Admin REST Client ......................... SUCCESS [
> 1.111 s]
> [INFO] Keycloak Client Registration API ................... SUCCESS [
> 0.736 s]
> [INFO] Keycloak Client CLI ................................ SUCCESS [
> 0.133 s]
> [INFO] Keycloak Client Registration CLI ................... SUCCESS [
> 6.737 s]
> [INFO] Keycloak Admin CLI ................................. SUCCESS [
> 5.972 s]
> [INFO] Keycloak Client CLI Distribution ................... SUCCESS [
> 3.475 s]
> [INFO] Keycloak Adapter SPI ............................... SUCCESS [
> 0.939 s]
> [INFO] Keycloak Tomcat Adapter SPI ........................ SUCCESS [
> 0.822 s]
> [INFO] Keycloak Undertow Integration SPI .................. SUCCESS [
> 1.166 s]
> [INFO] Keycloak Servlet Integration ....................... SUCCESS [
> 0.828 s]
> [INFO] Common JBoss/Wildfly Core Classes .................. SUCCESS [
> 0.591 s]
> [INFO] Keycloak Jetty Adapter SPI ......................... SUCCESS [
> 0.928 s]
> [INFO] Keycloak Client Adapter SPI Modules ................ SUCCESS [
> 0.163 s]
> [INFO] Keycloak SAML Client Adapter Public API ............ SUCCESS [
> 0.621 s]
> [INFO] Keycloak SAML Client Adapter Core .................. SUCCESS [
> 5.196 s]
> [INFO] Keycloak Undertow SAML Adapter ..................... SUCCESS [
> 1.009 s]
> [INFO] Keycloak SAML Tomcat Integration ................... SUCCESS [
> 0.165 s]
> [INFO] Keycloak Tomcat Core SAML Integration .............. SUCCESS [
> 0.839 s]
> [INFO] Keycloak Tomcat 8 SAML Integration ................. SUCCESS [
> 0.743 s]
> [INFO] Keycloak Tomcat 6 Saml Integration ................. SUCCESS [
> 0.617 s]
> [INFO] Keycloak Tomcat 7 SAML Integration ................. SUCCESS [
> 0.625 s]
> [INFO] Keycloak Wildfly SAML Adapter ...................... SUCCESS [
> 0.999 s]
> [INFO] KeyCloak Authz: Client API ......................... SUCCESS [
> 1.963 s]
> [INFO] Keycloak Adapter Core .............................. SUCCESS [
> 6.558 s]
> [INFO] Keycloak WildFly Elytron SAML Adapter .............. SUCCESS [
> 1.130 s]
> [INFO] Keycloak Wildfly SAML Adapter Subsystem ............ SUCCESS [
> 7.527 s]
> [INFO] Keycloak SAML Wildfly Integration .................. SUCCESS [
> 0.146 s]
> [INFO] Keycloak AS7 / JBoss EAP 6 Integration ............. SUCCESS [
> 0.183 s]
> [INFO] Keycloak AS7 SPI ................................... SUCCESS [
> 3.170 s]
> [INFO] Keycloak SAML EAP Integration ...................... SUCCESS [
> 0.130 s]
> [INFO] Keycloak SAML AS7 Integration ...................... SUCCESS [
> 1.062 s]
> [INFO] Keycloak SAML AS7 Subsystem ........................ SUCCESS [
> 5.323 s]
> [INFO] Keycloak SAML Servlet Filter ....................... SUCCESS [
> 0.804 s]
> [INFO] Keycloak Jetty Core SAML Integration ............... SUCCESS [
> 0.865 s]
> [INFO] Keycloak Jetty 9.2.x SAML Integration .............. SUCCESS [
> 0.820 s]
> [INFO] Keycloak Jetty 9.3.x SAML Integration .............. SUCCESS [
> 0.894 s]
> [INFO] Keycloak Jetty 9.4.x SAML Integration .............. SUCCESS [
> 1.066 s]
> [INFO] Keycloak SAML Jetty Integration .................... SUCCESS [
> 0.144 s]
> [INFO] Keycloak SAML Client Adapter Modules ............... SUCCESS [
> 0.132 s]
> [INFO] Keycloak Tomcat Integration ........................ SUCCESS [
> 0.140 s]
> [INFO] Keycloak Tomcat Core Integration ................... SUCCESS [
> 0.758 s]
> [INFO] Keycloak AS7 Integration ........................... SUCCESS [
> 0.906 s]
> [INFO] Keycloak AS7 Subsystem ............................. SUCCESS [
> 4.368 s]
> [INFO] Keycloak Installed Application ..................... SUCCESS [
> 1.609 s]
> [INFO] Keycloak Undertow Integration ...................... SUCCESS [
> 2.295 s]
> [INFO] Keycloak Fuse 7.0 Integration ...................... SUCCESS [
> 0.161 s]
> [INFO] Keycloak Fuse 7.0 Adapter - Camel + Undertow ....... SUCCESS [
> 1.773 s]
> [INFO] Keycloak OSGI Adapter .............................. SUCCESS [
> 3.531 s]
> [INFO] Keycloak Fuse 7.0 Adapter - Undertow ............... SUCCESS [
> 1.514 s]
> [INFO] Keycloak Jetty Core Integration .................... SUCCESS [
> 1.175 s]
> [INFO] Keycloak Jetty 9.4.x Integration ................... SUCCESS [
> 0.945 s]
> [INFO] Keycloak Fuse 7.0 Adapter - Jetty 9.4 .............. SUCCESS [
> 1.345 s]
> [INFO] Keycloak Tomcat 8 Integration ...................... SUCCESS [
> 0.767 s]
> [INFO] Keycloak Fuse 7.0 Adapter - Tomcat 8 ............... SUCCESS [
> 1.105 s]
> [INFO] Keycloak CLI SSO Framework ......................... SUCCESS [
> 4.620 s]
> [INFO] Keycloak JAX-RS OAuth Client ....................... SUCCESS [
> 1.314 s]
> [INFO] Keycloak Jetty 9.2.x Integration ................... SUCCESS [
> 1.142 s]
> [INFO] Keycloak Jetty 9.3.x Integration ................... SUCCESS [
> 1.144 s]
> [INFO] Keycloak Jetty Integration ......................... SUCCESS [
> 0.173 s]
> [INFO] Keycloak Servlet Filter Adapter Integration ........ SUCCESS [
> 1.061 s]
> [INFO] Keycloak Servlet OAuth Client ...................... SUCCESS [
> 4.150 s]
> [INFO] spring-boot-container-bundle ....................... SUCCESS [
> 1.761 s]
> [INFO] Keycloak Spring Security Integration ............... SUCCESS [
> 8.449 s]
> [INFO] Keycloak Spring Boot Adapter Core .................. SUCCESS [
> 1.759 s]
> [INFO] Keycloak Spring Boot Integration ................... SUCCESS [
> 4.437 s]
> [INFO] Keycloak Spring Boot 2 Integration ................. SUCCESS [
> 4.172 s]
> [INFO] Keycloak Tomcat 6 Integration ...................... SUCCESS [
> 0.689 s]
> [INFO] Keycloak Tomcat 7 Integration ...................... SUCCESS [
> 0.761 s]
> [INFO] Keycloak Wildfly Integration ....................... SUCCESS [
> 0.998 s]
> [INFO] Keycloak Wildfly Elytron OIDC Adapter .............. SUCCESS [
> 1.763 s]
> [INFO] Keycloak Wildfly Adapter Subsystem ................. SUCCESS [
> 8.862 s]
> [INFO] Keycloak Wildfly 8 Adapter Subsystem ............... SUCCESS [
> 5.703 s]
> [INFO] Keycloak WildFly Integration ....................... SUCCESS [
> 0.138 s]
> [INFO] Keycloak OIDC Client Adapter Modules ............... SUCCESS [
> 0.124 s]
> [INFO] Keycloak Adapters .................................. SUCCESS [
> 0.130 s]
> [INFO] Keycloak Misc ...................................... SUCCESS [
> 0.138 s]
> [INFO] Keycloak :: Spring :: Boot ......................... SUCCESS [
> 0.148 s]
> [INFO] Keycloak :: Spring :: Boot :: Default ::  Starter .. SUCCESS [
> 0.371 s]
> [INFO] Keycloak :: Spring :: Boot ......................... SUCCESS [
> 0.139 s]
> [INFO] Keycloak :: Legacy :: Spring :: Boot :: Default ::  Starter SUCCESS
> [  0.388 s]
> [INFO] keycloak-test-helper ............................... SUCCESS [
> 0.937 s]
> [INFO] Keycloak TestSuite ................................. SUCCESS [
> 0.128 s]
> [INFO] DB Allocator Plugin ................................ SUCCESS [
> 14.444 s]
> [INFO] Keycloak Arquillian Integration TestSuite .......... SUCCESS [
> 0.212 s]
> [INFO] Test apps .......................................... SUCCESS [
> 0.144 s]
> [INFO] Test apps distribution ............................. SUCCESS [
> 7.201 s]
> [INFO] Keycloak Authz: PhotoZ  Test Parent ................ SUCCESS [
> 0.145 s]
> [INFO] Keycloak Authz Test: Photoz RESTful API ............ SUCCESS [
> 1.871 s]
> [INFO] Keycloak Authz Tests: Photoz HTML5 Client .......... SUCCESS [
> 1.330 s]
> [INFO] Keycloak Authz Tests: Photoz Authz Rule-based Policy SUCCESS [
> 0.442 s]
> [INFO] Keycloak Authz Tests: Hello World Example .......... SUCCESS [
> 0.406 s]
> [INFO] Keycloak Authz: Servlet Authorization Test ......... SUCCESS [
> 0.577 s]
> [INFO] Keycloak Authz: Simple Servlet App with Policy Enforcer SUCCESS [
> 0.393 s]
> [INFO] integration-arquillian-test-apps-servlets .......... SUCCESS [
> 1.327 s]
> [INFO] Keycloak Test App Profile JEE ...................... SUCCESS [
> 0.638 s]
> [INFO] integration-arquillian-test-apps-cors-parent ....... SUCCESS [
> 0.144 s]
> [INFO] Angular Product Portal JS .......................... SUCCESS [
> 2.995 s]
> [INFO] JAX-RS Database Service Using OAuth Bearer Tokens .. SUCCESS [
> 0.728 s]
> [INFO] Fuse Test Applications ............................. SUCCESS [
> 0.139 s]
> [INFO] Customer Portal - Secured in Karaf/Fuse ............ SUCCESS [
> 1.778 s]
> [INFO] CXF JAXRS Example - Secured in Karaf/Fuse .......... SUCCESS [
> 2.099 s]
> [INFO] CXF JAXRS Example - Secured in Karaf/Fuse 7.0 on Undertow SUCCESS
> [  0.798 s]
> [INFO] CXF JAXWS Example - Secured in Karaf/Fuse .......... SUCCESS [
> 1.012 s]
> [INFO] CXF JAXWS Example - Secured in Karaf/Fuse 7.0 on Undertow SUCCESS
> [  0.830 s]
> [INFO] Product Portal - Secured in Karaf/Fuse ............. SUCCESS [
> 0.960 s]
> [INFO] Product Portal - Secured in Karaf/Fuse 7.0 on Undertow SUCCESS [
> 1.012 s]
> [INFO] Camel endpoint example - Secured in Karaf/Fuse ..... SUCCESS [
> 0.779 s]
> [INFO] Camel endpoint example - Secured in Karaf/Fuse 7.0 on Undertow
> SUCCESS [  0.879 s]
> [INFO] Keycloak Fuse Example - Features ................... SUCCESS [
> 0.670 s]
> [INFO] Keycloak Examples - External Config ................ SUCCESS [
> 0.776 s]
> [INFO] spring-boot-adapter ................................ SUCCESS [
> 1.358 s]
> [INFO] spring-boot-adapter-2 .............................. SUCCESS [
> 1.571 s]
> [INFO] spring-boot-adapter-21 ............................. SUCCESS [
> 1.435 s]
> [INFO] Servers ............................................ SUCCESS [
> 0.152 s]
> [INFO] Auth Server ........................................ SUCCESS [
> 0.127 s]
> [INFO] Auth Server Services ............................... SUCCESS [
> 0.129 s]
> [INFO] Auth Server Services - Testsuite Providers ......... SUCCESS [
> 5.076 s]
> [INFO] Auth Server - JBoss ................................ SUCCESS [
> 0.131 s]
> [INFO] Keycloak TestSuite Utils ........................... SUCCESS [
> 2.794 s]
> [INFO] Test Util .......................................... SUCCESS [
> 1.798 s]
> [INFO] Auth Server - Undertow ............................. SUCCESS [
> 2.305 s]
> [INFO] App Server ......................................... SUCCESS [
> 0.137 s]
> [INFO] App Server - SPI ................................... SUCCESS [
> 0.541 s]
> [INFO] App Server - JBoss ................................. SUCCESS [
> 0.132 s]
> [INFO] App Server - Karaf ................................. SUCCESS [
> 0.127 s]
> [INFO] App Server - Tomcat ................................ SUCCESS [
> 0.130 s]
> [INFO] App Server - Undertow .............................. SUCCESS [
> 1.122 s]
> [INFO] App Server - Jetty Parent .......................... SUCCESS [
> 0.151 s]
> [INFO] Cache Server ....................................... SUCCESS [
> 0.119 s]
> [INFO] Cache Server - JBoss Family ........................ SUCCESS [
> 0.124 s]
> [INFO] Tests .............................................. SUCCESS [
> 0.493 s]
> [INFO] Base TestSuite ..................................... FAILURE [
> 01:45 h]
> [INFO] Other Tests Modules ................................ SKIPPED
> [INFO] Adapter Tests ...................................... SKIPPED
> [INFO] Adapter Tests - JBoss .............................. SKIPPED
> [INFO] Adapter Tests - Karaf .............................. SKIPPED
> [INFO] Adapter Tests - WAS ................................ SKIPPED
> [INFO] Adapter Tests - WLS ................................ SKIPPED
> [INFO] SSSD tests ......................................... SKIPPED
> [INFO] integration-arquillian-tests-springboot ............ SKIPPED
> [INFO]
> ------------------------------------------------------------------------
> [INFO] BUILD FAILURE
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Total time:  01:51 h
> [INFO] Finished at: 2019-04-23T19:51:55+08:00
> [INFO]
> ------------------------------------------------------------------------
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test (default-test)
> on project integration-arquillian-tests-base: There are test failures.
> [ERROR]
> [ERROR] Please refer to
> C:\Users\christopher.smith\Documents\keycloak\workspace\keycloak-parent\testsuite\integration-arquillian\tests\base\target\surefire-reports
> for the individual test results.
> [ERROR] -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the
> -e switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions,
> please read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
> [ERROR]
> [ERROR] After correcting the problems, you can resume the build with the
> command
> [ERROR]   mvn <goals> -rf :integration-arquillian-tests-base
>
> C:\Users\christopher.smith\Documents\keycloak\workspace\keycloak-parent>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From liqiang at fit2cloud.com  Wed Apr 24 05:40:22 2019
From: liqiang at fit2cloud.com (=?UTF-8?B?5byg56uL5by6?=)
Date: Wed, 24 Apr 2019 17:40:22 +0800
Subject: [keycloak-dev] Keycloak Cluster Setup And Configuration
Message-ID: <CAOHSYr4r=QOczXEasPjvwQahsS4idncp34kgneTjFM4SHohk9A@mail.gmail.com>

Hi there,

Due to the mail size and attachment limits, I post the details to a github
repo.
https://github.com/zhangliqiang/keycloak-cluster-setup-and-configuration

FYI.

???

FIT2CLOUD

From Jo0815 at gmx.de  Wed Apr 24 08:23:20 2019
From: Jo0815 at gmx.de (the john)
Date: Wed, 24 Apr 2019 14:23:20 +0200
Subject: [keycloak-dev] Themes: Browser cache not used for static
 resources (img, css, js)
In-Reply-To: <CAJgngAco3SypiUBKWsLBVOKYT-zrxAOKbLNor_s+_5NG+TdEdQ@mail.gmail.com>
References: <06df942d-fa75-3395-f1f6-1edc2e8d2dfa@gmx.de>
	<CAJgngAco3SypiUBKWsLBVOKYT-zrxAOKbLNor_s+_5NG+TdEdQ@mail.gmail.com>
Message-ID: <trinity-3cf97a52-d404-4bbf-91cc-93ef4329691e-1556108600861@3c-app-gmx-bs69>


From sthorger at redhat.com  Wed Apr 24 08:25:43 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 24 Apr 2019 14:25:43 +0200
Subject: [keycloak-dev] JWE support
In-Reply-To: <CAJPL6N5XD+Lvu=wPCLdpYhAq+A3LbbOxvwUT4qGc6yPmtXR=Nw@mail.gmail.com>
References: <CAJPL6N5XD+Lvu=wPCLdpYhAq+A3LbbOxvwUT4qGc6yPmtXR=Nw@mail.gmail.com>
Message-ID: <CAJgngAd_nZxpwKCjCyXCN=YNFLEK_HDrzBsy47K4pX-B8Zp=bw@mail.gmail.com>

There is already a PR open for KEYCLOAK-6768:
https://github.com/keycloak/keycloak/pull/5779. Feedback on this PR would
be welcome.

On Thu, 18 Apr 2019 at 09:13, Guillaume HOUDMON <
guillaume.houdmon at ariadnext.com> wrote:

> Hi,
>
> We are currently studying how to encrypt tokens with JWE. There is the JIRA
> KEYCLOAK-6768 that addresses this topic. But it does not seem that there
> was any work to start on it.
>
> A beginning of support has already been done to encrypt the code (see
> KEYCLOAK-5288).
>
> Inspired by what is done for the signature, I plan to add a section in the
> client page "Encryption Tokens Configuration" to select the algorithms by
> types of tokens, and set the encryption key (paste or jwks url).
> We would add 2 SPIs: jwe-key-encryption and jwe-content-encryption.
>
> With my colleagues, we would complete the algorithms (RSA-OAEP,
> RSA-OAEP-256 and A128GCM, A192GCM, A256GCM).
>
> In a second step, we could also contribute for the support in Java
> adapters.
>
> Does this approach seem relevant to you?
> Should we go through a design proposal?
>
> Regards,
> Guillaume Houdmon
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sthorger at redhat.com  Wed Apr 24 08:37:16 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 24 Apr 2019 14:37:16 +0200
Subject: [keycloak-dev] Proposal: more flexible brokered identity with
 SAML IdP
In-Reply-To: <1555629526.8282.2.camel@carretti.pro>
References: <1555629526.8282.2.camel@carretti.pro>
Message-ID: <CAJgngAf0juDW9EEV-9sWNy=LH8YLCvZ9uTafkXiJVZkiyeZS9w@mail.gmail.com>

To clarify. Do you have to user storage providers? One AD and one custom
DB? With the SAML IdP using the custom DB?

If Keycloak already has access to the users directly, why redirect to the
SAML IdP at all? Couldn't Keycloak just authenticate directly? Or
alternatively not load the same users at all directly in Keycloak, but only
through the external SAML IdP? I'm not following the rational around this
approach.

That being said isn't a custom first broker login flow what you want? There
you can link users automatically in the way you want.

On Fri, 19 Apr 2019 at 01:20, Dmitry Telegin <demetrio at carretti.pro> wrote:

> Background
> ==========
>
> Consider the problem: we are preparing a Keycloak deployment with the
> following properties:
> - users come from LDAP/AD, self-registration disabled;
> - vast majority of the users will be authenticating via a 3rd party
> SAML IdP that shares user DB with our Keycloak.
>
> To make onboarding easier, we want to free the users from the need to
> manually link their accounts with the IdP, by mass pre-creating the
> links programmatically using Admin REST API.
>
> In theory, this should be doable by issuing a POST to
> users/{id}/federated-identity/saml, passing IdP's userId and userName,
> which should create and persist a FederatedIdentity instance.
>
> In practice, we're hitting a roadblock because of how SAML brokered
> identities are implemented in Keycloak.
>
> Problem
> =======
>
> Currently, it is hardcoded [1] that FederatedIdentity's userId and
> userName should be taken verbatim from SAML assertion's NameID value
> (via intermediary BrokeredIdentityContext). The problem is that most
> SAML IdPs provide meaningless NameIDs, like hashes or purely random
> strings. In general, SAML NameID is not predictable. To make things
> worse, NameID can be different for SPs, so we can't simply peek it in
> another application already integrated with the IdP.
>
> OTOH, incoming assertion is guaranteed to contain other attributes that
> are well-known to us and uniquely identify the user, like e.g. mobile
> phone number.
>
> [1] https://github.com/keycloak/keycloak/blob/master/services/src/main/
> java/org/keycloak/broker/saml/SAMLEndpoint.java#L398
> <https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/broker/saml/SAMLEndpoint.java#L398>
>
>
> Solution
> ========
>
> The problem could be solved by introducing a configurable (and thus
> more flexible) mechanism to map SAML assertions to FederatedIdentities.
> With that, we could instruct Keycloak to take userId and userName from
> arbitrary assertion attributes, or even complex expression, similar to
> what we have in UsernameTemplateMapper.
>
> Questions are:
> 1. From what I've learned, this should be doable with the help of a
> custom IdP mapper, using preprocessFederatedIdentity() method. Is that
> correct?
> 2. Regardless of the answer to 1, would Keycloak team welcome this
> contribution?
>
> Some thoughts not directly related to this particular problem; from my
> 3+ years experience with Keycloak and its corporate users, I can surely
> tell that SAML under no circumstances should be considered either
> legacy or obsolete. It is *very* actively used in the areas like
> fintech, education and healthcare. I'd myself be happy to see Keycloak
> become 1st class SAML IdP/broker, and going to do my best to make it
> happen. I'm particularly interested in improving SAML/OIDC
> interoperability in terms of IdP-initiated SSO and token exchange.
>
> Best regards,
> Dmitry
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From psilva at redhat.com  Wed Apr 24 09:03:48 2019
From: psilva at redhat.com (Pedro Igor Silva)
Date: Wed, 24 Apr 2019 10:03:48 -0300
Subject: [keycloak-dev] [keycloak-user] Keycloak Cluster Setup And
	Configuration
In-Reply-To: <CAOHSYr4r=QOczXEasPjvwQahsS4idncp34kgneTjFM4SHohk9A@mail.gmail.com>
References: <CAOHSYr4r=QOczXEasPjvwQahsS4idncp34kgneTjFM4SHohk9A@mail.gmail.com>
Message-ID: <CAJrcDBeR4F=Uq=M6rDAY-VUaoh_kR=OrcLYj2=RPmkQ=xih=iw@mail.gmail.com>

Hi,

I think this is a great writeup and you could probably send a PR with a
blog to the website?

Regards.
Pedro Igor

On Wed, Apr 24, 2019 at 6:42 AM ??? <liqiang at fit2cloud.com> wrote:

> Hi there,
>
> Due to the mail size and attachment limits, I post the details to a github
> repo.
> https://github.com/zhangliqiang/keycloak-cluster-setup-and-configuration
>
> FYI.
>
> ???
>
> FIT2CLOUD
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user

From sblanc at redhat.com  Wed Apr 24 09:14:14 2019
From: sblanc at redhat.com (Sebastien Blanc)
Date: Wed, 24 Apr 2019 15:14:14 +0200
Subject: [keycloak-dev] [keycloak-user] Keycloak Cluster Setup And
	Configuration
In-Reply-To: <CAJrcDBeR4F=Uq=M6rDAY-VUaoh_kR=OrcLYj2=RPmkQ=xih=iw@mail.gmail.com>
References: <CAOHSYr4r=QOczXEasPjvwQahsS4idncp34kgneTjFM4SHohk9A@mail.gmail.com>
	<CAJrcDBeR4F=Uq=M6rDAY-VUaoh_kR=OrcLYj2=RPmkQ=xih=iw@mail.gmail.com>
Message-ID: <CAMZCGg_TO-Gtr6E---86tVGZ2cG6JhDLG1E=W0HTfPNLnMw6EA@mail.gmail.com>

+1 that's funny I was writing more or less the same answer as you when I
saw your answer appearing ;)
Blog Post is a good start and we are still figuring out how we could
regroup all these knowledge is an easily searchable way.

Thanks ??? for sharing this.



On Wed, Apr 24, 2019 at 3:05 PM Pedro Igor Silva <psilva at redhat.com> wrote:

> Hi,
>
> I think this is a great writeup and you could probably send a PR with a
> blog to the website?
>
> Regards.
> Pedro Igor
>
> On Wed, Apr 24, 2019 at 6:42 AM ??? <liqiang at fit2cloud.com> wrote:
>
> > Hi there,
> >
> > Due to the mail size and attachment limits, I post the details to a
> github
> > repo.
> > https://github.com/zhangliqiang/keycloak-cluster-setup-and-configuration
> >
> > FYI.
> >
> > ???
> >
> > FIT2CLOUD
> > _______________________________________________
> > keycloak-user mailing list
> > keycloak-user at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-user
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user

From sthorger at redhat.com  Wed Apr 24 09:34:46 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 24 Apr 2019 15:34:46 +0200
Subject: [keycloak-dev] W3C Web Authentication - Two-Factor,
	implementing JIRAs
In-Reply-To: <09f9c666bee742a090160ab1c0655752@elca.ch>
References: <24cbd52475494e4a95f9282a280d8fde@elca.ch>
	<CAJgngAcWrTfp7-w_CX7GooohArQe62xp78+58oGCQozPmjojXw@mail.gmail.com>
	<111481de90e245cabb85e75fa4f72c70@elca.ch>
	<CAJgngAeqsgQGRnHwS38SLhtxJKgn+ADRktZ1243GAD7KtjB+Dg@mail.gmail.com>
	<685b12117e024c449ae6e1a4e221cac8@elca.ch>
	<CAJgngAeRE3ExFY469n_PURpHEnduVgiBuuNGmMOHP0SYYunVPA@mail.gmail.com>
	<09f9c666bee742a090160ab1c0655752@elca.ch>
Message-ID: <CAJgngAeTUsfeTVVkPk6z2PO9+_Zjxt60O7fj-H7xdvpxSvqxkQ@mail.gmail.com>

Great, I plan to review this tomorrow and give you some feedback.

Sorry for the late reply, I've been on PTO and just catching up ;)

On Tue, 16 Apr 2019 at 10:52, Doswald Alistair <alistair.doswald at elca.ch>
wrote:

> I?ve made a PR for the design document on keycloak-community. Compared to
> the initial mail, I?ve made some changes to the multi-factor part to take
> into account our discussions and some comments from my colleagues. I?ve
> also added a section for the design of step-up authentication.
>
>
>
> *From:* Stian Thorgersen <sthorger at redhat.com>
> *Sent:* mercredi 20 mars 2019 13:01
> *To:* Doswald Alistair <alistair.doswald at elca.ch>
> *Cc:* keycloak-dev <keycloak-dev at lists.jboss.org>
> *Subject:* Re: [keycloak-dev] W3C Web Authentication - Two-Factor,
> implementing JIRAs
>
>
>
>
>
>
>
> On Mon, 18 Mar 2019 at 10:51, Doswald Alistair <alistair.doswald at elca.ch>
> wrote:
>
> * I can move the design proposal to
> https://github.com/keycloak/keycloak-community/tree/master/design. For
> this I simply format in Markdown and do a pull request?
>
>
>
> Yes
>
>
>
>
>
> * I?d also be in favour of a face to face meeting. I?m in the CET timezone
> (currently GMT+1 and GMT+2 from the 31st of march). This week I?d be
> available Tuesday, Thursday and Friday, and I also have availabilities next
> week (except Monday). I?m not sure of the logistics however? We use skype
> for business internally, but maybe you have a preferred platform? Also,
> would you mind if one of my colleagues who could work on the JIRAs joins
> the meeting call?
>
>
>
> I've had issues with Skype in the past. We can use BlueJeans if that works
> for you? Tuesday at 12?
>
>
>
> * Since I?m answering anyway, I?ll answer a few of your comments (the rest
> can be discussed later as I think that they are more technical):
>
>
>
> - I believe that you?re correct to say that we should consider the step-up
> (and one of my colleagues actually had the same comment upon reading my
> proposal). I may have some ideas on how this would work with the proposed 2
> factor, but I?d like to read up on what was already discussed/proposed
> first. Has there been more discussed than what?s at
> https://issues.jboss.org/browse/KEYCLOAK-847,
> http://lists.jboss.org/pipermail/keycloak-user/2016-November/008311.html,
> http://lists.jboss.org/pipermail/keycloak-dev/2016-May/007150.html and
> http://lists.jboss.org/pipermail/keycloak-dev/2017-April/009245.html?
>
>
>
> Had a long discussion with some folks from the team a while back around
> step-up, but of course we didn't write it down ;)
>
>
>
> In summary the plans where to add markers into the flows that would be
> used to set the authentication levels, then allow the authentication
> processor to skip as well as fast forward as needed.
>
>
>
>
>
> - For the users setting their own default authenticator I agree (and
> intended to describe that in the text, though upon re-reading that part of
> the description is fragmented), as long as the admin has enabled the
> authentication category in a flow. However, it is true that between the
> default flow and custom/per-client flows it may be difficult to determine
> how the user sees/selects his preferred authenticator for an authentication
> step (not to mention what would happen when an admin changes the
> configuration). This should definitely be further detailed. I?m not sure
> yet if some extra data structures are necessary though, maybe some custom
> functions to get the required information is sufficient.
>
>
>
> We need a group that means "one of these" ;)
>
>
>
>
>
> - I think that having a built in flow that follows the proposed logic
> isn?t too difficult. There?d be the ?Authenticated on?,
>
> ?Authentication factor 1? and ?Authentication factor 2? executions with
> some default authenticator categories. The admin would be able to set
> enabled and disabled for the built-in authenticator categories, but be able
> to add and remove in custom flows. That way a newbie admin wouldn?t be able
> to do too much damage, while a more experienced one would be able to
> customize as he wants. Some extra documentation within the admin console
> may help with this.
>
>
>
>
>
> *From:* Stian Thorgersen <sthorger at redhat.com>
> *Sent:* vendredi 15 mars 2019 09:25
> *To:* Doswald Alistair <alistair.doswald at elca.ch>
> *Cc:* keycloak-dev <keycloak-dev at lists.jboss.org>
> *Subject:* Re: [keycloak-dev] W3C Web Authentication - Two-Factor,
> implementing JIRAs
>
>
>
> * Would be worth moving this to a design proposal on
> https://github.com/keycloak/keycloak-community/tree/master/design. Would
> be easier to work collectively on a design proposal there than to have an
> endless thread on a ML ;). I'd also be open to join you on a call to have a
> discussion "face to face"
>
>
>
> * I was thinking to limit to two factor for now, but you're probably right
> here with regards to consider the bigger picture now as it may be difficult
> to get it right otherwise
>
>
>
> * Need to consider how this fits into step-up authentication
>
>
>
> * Admins should be able to select level of authentication required, but
> users should be able to choose from available options
>
>
>
> * Users should be able to select from available mechanisms when
> configuring. Users should be able to set their own default. This means the
> account console/rest needs metadata to discover available mechanisms. I
> wonder if there's a need for something outside of flows and authenticators
> to capture metadata about supported credential types which is used by
> account and admin consoles to manage credentials.
>
>
>
> * I was aiming a simpler setup where admin doesn't need to create custom
> flow unless they want to add custom authenticators. That means
> authenticators should be enabled/disabled in the flow rather than
> added/removed
>
>
>
> Some more comments inline below
>
>
>
> On Thu, 14 Mar 2019 at 14:02, Doswald Alistair <alistair.doswald at elca.ch>
> wrote:
>
> This is OK for me. I propose starting with initial proposals for the
> fundamentals in this email, and once there's an agreement on those,
> separating the discussion between the two JIRAs to refine the concepts for
> each one. Once the work to be done is clearer, it can be supplemented with
> screen mockups and/or prototypes.
>
>
>
>
>
> 1) Scope of the modifications
>
>
>
> - For JIRA KEYCLOAK-9693 <https://issues.jboss.org/browse/KEYCLOAK-9693>,
> I believe that the description in the JIRA is not general enough to cover
> the description in web-authn-two-factor.md
> <https://github.com/keycloak/keycloak-community/blob/master/design/web-authn-two-factor.md>
> . Modifications to the authentication flows should support single factor,
> as well as 2nd factor and allow both authentication factor levels to select
> the alternative types of authenticator to be used. This allows a single
> factor authentication to use for example a FIDO2 dongle for passwordless
> authentication, or even let the user choose between the dongle and a
> password during the login.  Modifications for this JIRA include: changes to
> the authentication logic, changes to the authentication part of the admin
> console, changes to the authentication screens that the user sees during
> login, changes to the REST API, and possibly some changes to the database.
>
>
>
> In the first round we are focusing on two factor. Follow-up later is
> passwordless flows for web-authn. Passwordless is more tricky as it
> requires identity first login flow, ability for users to somehow define how
> they authenticate, rather than just what the second factor is, ability for
> admins to define authentication optoins rather than just two factor options.
>
>
>
> As I mentioned above though it is probably all to linked to consider only
> one at the design phase. So perhaps we need to work together on a design
> proposal that will include everything including step-up authentication.
>
>
>
>
>
> - For JIRA KEYCLOAK-9694 <https://issues.jboss.org/browse/KEYCLOAK-9694>,
> changes are to the "users > credentials" part of the administration console
> and to the REST API.
>
>
>
>
>
> 2) Design proposal for KEYCLOAK-9693
> <https://issues.jboss.org/browse/KEYCLOAK-9693>
>
>
>
> a) Authentication logic
>
>
>
> The current authentication flow system should be kept, but perhaps
> simplified. For a start I think that actual authenticators categories -
> that is elements that provide identity (e.g. password, cookie, kerberos,
> otp, fido, ...) - should be separate from other executions like "reset
> password".
>
>
>
> Thus, instead of directly adding "cookie" or "password" as alternatives in
> the authentication flow, the user can add the execution "authentication
> factor", and under authentication factor he can add only the valid
> authenticator categories. Each of the authenticator categories under the
> authentication factor are considered valid alternatives, and are evaluated
> in order. The authentication stops being automatically evaluated at the
> first authenticator that requires user input (alternative: all non-user
> input authenticators are evaluated before the first user-input
> authenticator).
>
>
>
> Adding a 2nd "authentication factor" execution sets the 2nd factor, and it
> must then have authenticators assigned. To have an authenticator category
> be valid for both authentication factors it must be set under both 1st and
> 2nd authentication factor. For example, kerberos could be set for both 1st
> and 2nd factor, which would mean that the user skips both factors if he's
> registered with kerberos, but it could also be just set for the first
> factor, in which case he'd still have to input the 2nd factor. To handle
> optional 2nd factors there could either be a "optional authentication
> factor type" or have an "optional" flag in the options of the
> "authentication factor".
>
>
>
> Potentially, this system could also allow a company that's really security
> conscientious/paranoiac to set N factors.
>
>
>
> Authentication factors are treated as a bloc in the evaluation of
> alternatives. That is, if in a flow there's "Identity provider redirector",
> "authentication factor 1", "authentication factor 2", entering the
> authentication factor 1 flow will automatically cause "authentication
> factor 2" to be executed after.
>
>
>
> To make things perhaps a little more clear, the current default "Browser"
> authentication would become for example:
>
>
>
> Auth type
>
> ------------------------------------------------------------
>
> Identity Provider Redirector
>
> Authentication factor (1)
>
>   |- Cookie
>
>   |- Kerberos
>
>   |- Username Password Form
>
> Authentication factor (2) [OPTIONAL]
>
>   |- Cookie
>
>   |- Kerberos
>
>   |- OTP Form
>
>
>
> And if we wanted to have an mandatory 2nd factor, with either OTP or a
> FIDO2 configured:
>
>
>
> Auth type
>
> ------------------------------------------------------------
>
> Identity Provider Redirector
>
> Authentication factor (1)
>
>   |- Cookie
>
>   |- Kerberos
>
>   |- Username Password Form
>
> Authentication factor (2)
>
>   |- Cookie
>
>   |- Kerberos
>
>   |- OTP Form
>
>   |- FIDO-2
>
>
>
> Potentially we could also introduce another type of authentication
> execution, we could call it "Authenticated on", to simplify the
> authenticators that bypass the authentication factors. We could then have:
>
>
>
> Auth type
>
> ------------------------------------------------------------
>
> Identity Provider Redirector
>
> Authenticated on
>
>   |- Cookie
>
>   |- Kerberos
>
> Authentication factor (1)
>
>   |- Username Password Form
>
> Authentication factor (2)
>
>   |- OTP Form
>
>   |- FIDO-2
>
>
>
> I like this in general. Devil is in the detail here though and need to
> think about this some more, especially how it fits into
> step-up-authentication.
>
>
>
>
>
> b) Authentication section in the admin console
>
>
>
> The schema described in a) would be implemented in the Authentication >
> flows. Bindings and Required Actions don't need any change I think. For
> policies I believe the password policy for the realm should remain, but the
> OTP policy should disappear, as a user could have several alternative OTP
> devices with different settings. As such, the information about the OTP
> settings should probably move to information associated with the credential.
>
>
>
> +1 I also think this is limited to the flow itself. Bear in mind I want to
> have a built-in flow that can be configured rather than requiring creating
> new flows. For example if we have OTP and WebAuthn authenticators an admin
> should be able to just enabled WebAuthn, not have to create a new flow to
> add it. Obviously a new custom flow would be required if the flow or custom
> authenticators are added. Moving OTP policy from realm to authenticator is
> already planned work, it was only added to the realm in the first place as
> it was done before we had configurable authenticators.
>
>
>
>
>
> c) Authentication screens for the user
>
>
>
> When the user logs in, unless he has something like a cookie he will see
> by default the first configuration interface configured in the current
> Authentication factor. If there are many different factors configured, he
> can access a list of any valid authenticator to use. If the user fails with
> the selected authenticator, he may choose another configured authenticator
> to validate the step.
>
>
>
> When it comes to default that is the users choice. So as a user if I have
> chosen webauthn as my default that should be shown first to me, even if the
> realm has the OTP as the first/default. It's also not when the user fails
> with the selected authenticator, but rather allow the user to choose a
> different authenticator.
>
>
>
>
>
> d) REST API
>
>
>
> There's no major change here, aside from updating the scheme to support
> the separation between authenticator categories and executions, and adding
> instructions to edit which authenticator categories are assigned to an
> authentication factor.
>
>
>
> e) database modifications
>
>
>
> Authenticator categories could be separated from executions either by
> having a new dedicated table, or by introducing a field in the
> authentication_execution table
>
>
>
> Realm config is responsible for most of the mess in the tables today. It's
> just plain daft to save this as separate tables/columns as it's always
> fetched as one blog and never queried. So I wonder if we could take a first
> start at this by simply storing the whole authentication flow including
> authenticator config as a single JSON blob in the DB.
>
>
>
>
>
>
>
> 3) Design proposal for KEYCLOAK-9694
> <https://issues.jboss.org/browse/KEYCLOAK-9694>
>
>
>
> a) Changes to the users > Credential menu
>
>
>
> Instead of manage Password we have "manage credentials", with a list of
> credentials for a user. The credentials grouped by type, and should
> indicate by which authentication factor they are valid for (1st factor, 2nd
> factor, unconfigured). The administrator should be able to edit / remove a
> credential.
>
>
>
> - For editing the administrator should be able to visualise the data of
> the credential (except the secret and the salt) and edit metadata about a
> device. Data would be any data in the fields of the credential that
> describe immutable data about the credential, and metadata would be for
> example label that a user can see and edit to name his device and a label
> that only the administrator could see and edit. The administrator (and
> user) should be able to set a "preferred credential" for each
> authentication factor level, which will override the factor shown by
> default during the login.
>
>
>
> - For deleting, I think that this should be linked to the authentication
> factors and authenticator categories of the realm, for example:
>
>    + For a realm with a single factor configured of types password and
> FIDO2, the credentials can be removed until ONE remains, and that last one
> cannot be removed.
>
>    + For a realm with a two factors configured, the first with password
> and FIDO2, and the second with OTP and FIDO UAF (I know, this is not a very
> good example from a security point of view), then it must be impossible to
> remove the last credential for the first factor, and to remove the last
> credential for the second factor.
>
>
>
> A note for passwords: Unlike other credentials I don't think that there
> should be more than one password that can be configured. Also, among its
> edition option it should be possible to reset (temporarily or not) as is
> currently the case.
>
>
>
> If the administrator and user can remove credentials, I do not know if the
> possibility to disable credentials is still useful. I don't see any
> problems with the feature either though, so if it?s still deemed useful it
> would keep its current behaviour.
>
>
>
> Credentials needs to have some metadata associated with them. Does it
> support a user to have mutiple (passwords is a single, webauthn is
> multiple). Can the admin update the value (passwords admin can update,
> webauthn only users can and that's through application initiated actions
> which account console will use). The thinking with regards to
> adding/updating credentials is that users do it through actions (required
> or application initiated), while admins do it directly in the console (in
> which case we need to have a dynamic way to specify the values, something
> like how component model works).
>
>
>
>
>
> b) Modifications to the REST API
>
>
>
> Currently there's no way to get credentials with the REST API. This should
> change with these modifications to reflect the new options for the
> administrator. The API should function in the same manner as the admin
> console: Credentials can be exposed (except for secret and hash values),
> the metadata edited and the credentials deleted with the same restrictions
> as described in section 3a
>
>
>
> We just need to be very careful here that secrets are never returned on a
> REST endpoint, but otherwise yes we need an endpoint that can list a users
> credentials.
>
>
>
>
>
> c) Database modifications
>
>
>
> I do not believe that this modification entails any database
> modifications. The current system with credential and credential attributes
> should be sufficient for the handling of multiple authenticators.
>
>
>
>
>
>
>
> That's it. Comments, questions and criticism are all welcome.
> ------------------------------
>
> *From:* Stian Thorgersen <sthorger at redhat.com>
> *Sent:* 08 March 2019 13:17
> *To:* Doswald Alistair
> *Cc:* keycloak-dev
> *Subject:* Re: [keycloak-dev] W3C Web Authentication - Two-Factor,
> implementing JIRAs
>
>
>
> No one is working on the admin part at the moment, so contributions here
> would be very welcome. It's not a straightforward task though and would
> need a fair bit of design/prototyping/discussions to get this right.
>
>
>
> On Fri, 8 Mar 2019 at 11:14, Doswald Alistair <alistair.doswald at elca.ch>
> wrote:
>
> Hello,
>
>
> I've been following the thread about the implementation of WebAuthn in
> Keycloak, and saw that there are some related JIRAs in the following design
> document
> https://github.com/keycloak/keycloak-community/blob/master/design/web-authn-two-factor.md
> .
>
>
> Is anyone  already working on JIRAs
> https://issues.jboss.org/browse/KEYCLOAK-9693 and
> https://issues.jboss.org/browse/KEYCLOAK-9694 for managing multiple 2nd
> factor authenticators? If not, with my colleagues we could implement them
> relatively quickly as we have use cases for these functionalities.
>
>
> Best regards,
>
>
> Alistair Doswald
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>

From liqiang at fit2cloud.com  Wed Apr 24 12:35:21 2019
From: liqiang at fit2cloud.com (=?UTF-8?B?5byg56uL5by6?=)
Date: Thu, 25 Apr 2019 00:35:21 +0800
Subject: [keycloak-dev] [keycloak-user] Keycloak Cluster Setup And
	Configuration
In-Reply-To: <CAMZCGg_TO-Gtr6E---86tVGZ2cG6JhDLG1E=W0HTfPNLnMw6EA@mail.gmail.com>
References: <CAOHSYr4r=QOczXEasPjvwQahsS4idncp34kgneTjFM4SHohk9A@mail.gmail.com>
	<CAJrcDBeR4F=Uq=M6rDAY-VUaoh_kR=OrcLYj2=RPmkQ=xih=iw@mail.gmail.com>
	<CAMZCGg_TO-Gtr6E---86tVGZ2cG6JhDLG1E=W0HTfPNLnMw6EA@mail.gmail.com>
Message-ID: <CAOHSYr5vOvafRBbLBiyzzRNNWmohE_YUzCXG74bo3EPffYEWWw@mail.gmail.com>

Hi,

Good to know it's useful :)
I will send a PR to the blog.


Sebastien Blanc <sblanc at redhat.com>?2019?4?24? ????9:14???

> +1 that's funny I was writing more or less the same answer as you when I
> saw your answer appearing ;)
> Blog Post is a good start and we are still figuring out how we could
> regroup all these knowledge is an easily searchable way.
>
> Thanks ??? for sharing this.
>
>
>
> On Wed, Apr 24, 2019 at 3:05 PM Pedro Igor Silva <psilva at redhat.com>
> wrote:
>
>> Hi,
>>
>> I think this is a great writeup and you could probably send a PR with a
>> blog to the website?
>>
>> Regards.
>> Pedro Igor
>>
>> On Wed, Apr 24, 2019 at 6:42 AM ??? <liqiang at fit2cloud.com> wrote:
>>
>> > Hi there,
>> >
>> > Due to the mail size and attachment limits, I post the details to a
>> github
>> > repo.
>> >
>> https://github.com/zhangliqiang/keycloak-cluster-setup-and-configuration
>> >
>> > FYI.
>> >
>> > ???
>> >
>> > FIT2CLOUD
>> > _______________________________________________
>> > keycloak-user mailing list
>> > keycloak-user at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/keycloak-user
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
> --
???

?????, FIT2CLOUD

http://fit2cloud.com | Mobile +86-18701062478 <%2B86-17710309880>

???????????7????????A?715?


????????????????????? ??? ? ??? ? ???

From jo0815 at gmx.de  Wed Apr 24 13:39:08 2019
From: jo0815 at gmx.de (jo0815)
Date: Wed, 24 Apr 2019 19:39:08 +0200
Subject: [keycloak-dev] Themes: Browser cache not used for static
 resources (img, css, js)
In-Reply-To: <CAJgngAco3SypiUBKWsLBVOKYT-zrxAOKbLNor_s+_5NG+TdEdQ@mail.gmail.com>
References: <06df942d-fa75-3395-f1f6-1edc2e8d2dfa@gmx.de>
	<CAJgngAco3SypiUBKWsLBVOKYT-zrxAOKbLNor_s+_5NG+TdEdQ@mail.gmail.com>
Message-ID: <60868038-c76c-b609-8ca1-9e73b0b0a654@gmx.de>

Hello Stian,

thanks for your quick response.
Your're right. The cache-controll-Header is set with the configured
theme/staticMaxAge (CacheControlUtil.java).

I was confused since reloading (pressing F5) triggers bypassing the
cache, which is described (for Chrome) here:
https://stackoverflow.com/questions/11245767/is-chrome-ignoring-cache-control-max-age
<https://deref-gmx.net/mail/client/5rKf3nAN78g/dereferrer/?redirectUrl=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F11245767%2Fis-chrome-ignoring-cache-control-max-age>

But selecting the location bar and hitting 'enter' shows the desired
behaviour: The local browser cache is used.


Thanks
Jonathan Strampp


Am 24.04.19 um 10:17 schrieb Stian Thorgersen:
> Not sure why you are saying resources are not cached as they are. Just
> look at resources loaded by the default theme.
>
> On Tue, 23 Apr 2019 at 20:29, jo0815 <jo0815 at gmx.de
> <mailto:jo0815 at gmx.de>> wrote:
>
>     Hello,
>
>     I've been deveoping custom keycloak themes which is pretty straight
>     forward thanks to the provided documentation.
>     I am using version 4.8.3.Final.
>
>     Regarding caching I only see options for freemarker templates
>     caching in
>     standalon.xml, theme section.
>     Opening the network view in Firefox I notice that no caching
>     headers are
>     uses for statice resouces (img, css, js).
>     Thus every visit of the login page reloads all linked static resources
>     from the server.
>
>     So my question is:
>     How can I provide client side caching of static resources (perhaps by
>     etags with file content hash)?
>
>
>     Thanks
>     Jonathan Strampp
>
>
>     _______________________________________________
>     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
>


From liqiang at fit2cloud.com  Thu Apr 25 00:52:56 2019
From: liqiang at fit2cloud.com (=?UTF-8?B?5byg56uL5by6?=)
Date: Thu, 25 Apr 2019 12:52:56 +0800
Subject: [keycloak-dev] [keycloak-user] Keycloak Cluster Setup And
	Configuration
In-Reply-To: <CAOHSYr5vOvafRBbLBiyzzRNNWmohE_YUzCXG74bo3EPffYEWWw@mail.gmail.com>
References: <CAOHSYr4r=QOczXEasPjvwQahsS4idncp34kgneTjFM4SHohk9A@mail.gmail.com>
	<CAJrcDBeR4F=Uq=M6rDAY-VUaoh_kR=OrcLYj2=RPmkQ=xih=iw@mail.gmail.com>
	<CAMZCGg_TO-Gtr6E---86tVGZ2cG6JhDLG1E=W0HTfPNLnMw6EA@mail.gmail.com>
	<CAOHSYr5vOvafRBbLBiyzzRNNWmohE_YUzCXG74bo3EPffYEWWw@mail.gmail.com>
Message-ID: <CAOHSYr7fVzwubpVzndy0WJL4X0XhhZVYNTdKH2M427WDOV5uvw@mail.gmail.com>

Hi,

The PR has been sent, please review and approve if it's ok.
https://github.com/keycloak/keycloak-web/pull/58


???

FIT2CLOUD


??? <liqiang at fit2cloud.com> ?2019?4?25??? ??12:35???

> Hi,
>
> Good to know it's useful :)
> I will send a PR to the blog.
>
>
> Sebastien Blanc <sblanc at redhat.com>?2019?4?24? ????9:14???
>
>> +1 that's funny I was writing more or less the same answer as you when I
>> saw your answer appearing ;)
>> Blog Post is a good start and we are still figuring out how we could
>> regroup all these knowledge is an easily searchable way.
>>
>> Thanks ??? for sharing this.
>>
>>
>>
>> On Wed, Apr 24, 2019 at 3:05 PM Pedro Igor Silva <psilva at redhat.com>
>> wrote:
>>
>>> Hi,
>>>
>>> I think this is a great writeup and you could probably send a PR with a
>>> blog to the website?
>>>
>>> Regards.
>>> Pedro Igor
>>>
>>> On Wed, Apr 24, 2019 at 6:42 AM ??? <liqiang at fit2cloud.com> wrote:
>>>
>>> > Hi there,
>>> >
>>> > Due to the mail size and attachment limits, I post the details to a
>>> github
>>> > repo.
>>> >
>>> https://github.com/zhangliqiang/keycloak-cluster-setup-and-configuration
>>> >
>>> > FYI.
>>> >
>>> > ???
>>> >
>>> > FIT2CLOUD
>>> > _______________________________________________
>>> > keycloak-user mailing list
>>> > keycloak-user at lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/keycloak-user
>>> _______________________________________________
>>> keycloak-user mailing list
>>> keycloak-user at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>> --
> ???
>
> ?????, FIT2CLOUD
>
> http://fit2cloud.com | Mobile +86-18701062478 <%2B86-17710309880>
>
> ???????????7????????A?715?
>
>
> ????????????????????? ??? ? ??? ? ???
>

From michael_furman at hotmail.com  Thu Apr 25 01:26:41 2019
From: michael_furman at hotmail.com (Michael Furman)
Date: Thu, 25 Apr 2019 05:26:41 +0000
Subject: [keycloak-dev] Is CVE-2019-3868 affecting regular Keycloak
	distributions?
Message-ID: <AM6P193MB0455C8AC3AEC47AF19A5A99EF43D0@AM6P193MB0455.EURP193.PROD.OUTLOOK.COM>

Hi,

Is CVE-2019-3868 affecting regular Keycloak distributions?

https://access.redhat.com/security/cve/cve-2019-3868

if yes, when it will be fixed?
Or maybe it is fixed already?

Thank you in advance for your help,

Best regards,

   Michael


From Lars.Wilhelmsen at thales.no  Thu Apr 25 02:19:32 2019
From: Lars.Wilhelmsen at thales.no (Lars Wilhelmsen)
Date: Thu, 25 Apr 2019 06:19:32 +0000
Subject: [keycloak-dev] Is CVE-2019-3868 affecting regular
	Keycloak	distributions?
In-Reply-To: <AM6P193MB0455C8AC3AEC47AF19A5A99EF43D0@AM6P193MB0455.EURP193.PROD.OUTLOOK.COM>
References: <AM6P193MB0455C8AC3AEC47AF19A5A99EF43D0@AM6P193MB0455.EURP193.PROD.OUTLOOK.COM>
Message-ID: <18223d2ecbbd418496aeac5cafa85c8b@Thales.no>

Hi,

 I'm guessing this is the commit that resolves the issue:
 https://github.com/keycloak/keycloak/commit/65326ce16af0901824ebd5635b1f6e9acbea1e66

 Regards,

 Lars Wilhelmsen

-----Original Message-----
From: keycloak-dev-bounces at lists.jboss.org <keycloak-dev-bounces at lists.jboss.org> On Behalf Of Michael Furman
Sent: torsdag 25. april 2019 07:27
To: keycloak-dev at lists.jboss.org
Subject: [keycloak-dev] Is CVE-2019-3868 affecting regular Keycloak distributions?

Hi,

Is CVE-2019-3868 affecting regular Keycloak distributions?

https://access.redhat.com/security/cve/cve-2019-3868

if yes, when it will be fixed?
Or maybe it is fixed already?

Thank you in advance for your help,

Best regards,

   Michael

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


From sthorger at redhat.com  Thu Apr 25 03:27:03 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 25 Apr 2019 09:27:03 +0200
Subject: [keycloak-dev] Keycloak 6.0.1 released
Message-ID: <CAJgngAfT4-_Zb54VnqXhXHZm_FEF3hobb4iW2FwhRoVyEvqRYw@mail.gmail.com>

https://www.keycloak.org/2019/04/keycloak-601-released.html

From sthorger at redhat.com  Thu Apr 25 07:22:56 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 25 Apr 2019 13:22:56 +0200
Subject: [keycloak-dev] Is CVE-2019-3868 affecting regular Keycloak
	distributions?
In-Reply-To: <18223d2ecbbd418496aeac5cafa85c8b@Thales.no>
References: <AM6P193MB0455C8AC3AEC47AF19A5A99EF43D0@AM6P193MB0455.EURP193.PROD.OUTLOOK.COM>
	<18223d2ecbbd418496aeac5cafa85c8b@Thales.no>
Message-ID: <CAJgngAffN0_ftQrAnn20ayP2P8V5CM5aSxuvMui3f9C+BxJpjQ@mail.gmail.com>

Yes, this is fixed in 6.0.1

On Thu, 25 Apr 2019 at 08:21, Lars Wilhelmsen <Lars.Wilhelmsen at thales.no>
wrote:

> Hi,
>
>  I'm guessing this is the commit that resolves the issue:
>
> https://github.com/keycloak/keycloak/commit/65326ce16af0901824ebd5635b1f6e9acbea1e66
>
>  Regards,
>
>  Lars Wilhelmsen
>
> -----Original Message-----
> From: keycloak-dev-bounces at lists.jboss.org <
> keycloak-dev-bounces at lists.jboss.org> On Behalf Of Michael Furman
> Sent: torsdag 25. april 2019 07:27
> To: keycloak-dev at lists.jboss.org
> Subject: [keycloak-dev] Is CVE-2019-3868 affecting regular Keycloak
> distributions?
>
> Hi,
>
> Is CVE-2019-3868 affecting regular Keycloak distributions?
>
> https://access.redhat.com/security/cve/cve-2019-3868
>
> if yes, when it will be fixed?
> Or maybe it is fixed already?
>
> Thank you in advance for your help,
>
> Best regards,
>
>    Michael
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From demetrio at carretti.pro  Thu Apr 25 09:05:05 2019
From: demetrio at carretti.pro (Dmitry Telegin)
Date: Thu, 25 Apr 2019 16:05:05 +0300
Subject: [keycloak-dev] Proposal: more flexible brokered identity with
 SAML IdP
In-Reply-To: <CAJgngAf0juDW9EEV-9sWNy=LH8YLCvZ9uTafkXiJVZkiyeZS9w@mail.gmail.com>
References: <1555629526.8282.2.camel@carretti.pro>
	<CAJgngAf0juDW9EEV-9sWNy=LH8YLCvZ9uTafkXiJVZkiyeZS9w@mail.gmail.com>
Message-ID: <1556197505.3603.3.camel@carretti.pro>

Hi Stian,
Turns out we already have a JIRA issue: https://issues.jboss.org/browse
/KEYCLOAK-7969
Per Kantara Initiative recommendations,
> SPs MUST NOT require the presence of a <saml:NameID>?element and MUST
> NOT rely on the content of this element for long term?identification
> of subjects; <saml:Attribute> elements MUST be used?for this purpose
> in the manner detailed below.

This issue is in the core of the overall problem we're trying to solve,
so probably we don't need to dive deep into the details of our
particular setup. Nevertheless, I've answered your questions below.
On Wed, 2019-04-24 at 14:37 +0200, Stian Thorgersen wrote:
> To clarify. Do you have to user storage providers? One AD and one
> custom DB? With the SAML IdP using the custom DB?

Sorry for confusion - there's no custom DB, LDAP is shared between
Keycloak and SAML IdP. We can even simplify this by assuming that
there's no LDAP at all, and Keycloak user DB is somehow synchronized
with the IdP. So Keycloak and IdP have the same view of users, and we
only need to pre-create brokered identity links. This is currently not
possible because Keycloak requires the knowledge of SAML NameID in
order to do that, and NameIDs are random / non-predictable.

> If Keycloak already has access to the users directly, why redirect to
> the SAML IdP at all? Couldn't Keycloak just authenticate directly??

This is the requirement. SAML IdP might use different authentication
infrastructure (OTP, smartcards, Kerberos) that our Keycloak has no
access to.
> Or alternatively not load the same users at all directly in Keycloak,
> but only through the external SAML IdP? I'm not following the
> rational around this approach.

This is also the business requirement. The list of users in Keycloak
should be complete from the start, and not being populated gradually as
the users log in.
> That being said isn't a custom first broker login flow what you want?
> There you can link users automatically in the way you want.

It could have been, but we need to perform linking based on SAML
attributes, and currently SAML context is not exposed to the
authenticators, which is another known issue:https://issues.jboss.org/b
rowse/KEYCLOAK-9936http://lists.jboss.org/pipermail/keycloak-dev/2019-
January/011514.html
Regards,Dmitry
> On Fri, 19 Apr 2019 at 01:20, Dmitry Telegin <demetrio at carretti.pro>
> wrote:
> > Background
> > 
> > ==========
> > 
> > 
> > 
> > Consider the problem: we are preparing a Keycloak deployment with
> > the
> > 
> > following properties:
> > 
> > - users come from LDAP/AD, self-registration disabled;
> > 
> > - vast majority of the users will be authenticating via a 3rd party
> > 
> > SAML IdP that shares user DB with our Keycloak.
> > 
> > 
> > 
> > To make onboarding easier, we want to free the users from the need
> > to
> > 
> > manually link their accounts with the IdP, by mass pre-creating the
> > 
> > links programmatically using Admin REST API.
> > 
> > 
> > 
> > In theory, this should be doable by issuing a POST to
> > 
> > users/{id}/federated-identity/saml, passing IdP's userId and
> > userName,
> > 
> > which should create and persist a FederatedIdentity instance.
> > 
> > 
> > 
> > In practice, we're hitting a roadblock because of how SAML brokered
> > 
> > identities are implemented in Keycloak.
> > 
> > 
> > 
> > Problem
> > 
> > =======
> > 
> > 
> > 
> > Currently, it is hardcoded [1] that FederatedIdentity's userId and
> > 
> > userName should be taken verbatim from SAML assertion's NameID
> > value
> > 
> > (via intermediary BrokeredIdentityContext). The problem is that
> > most
> > 
> > SAML IdPs provide meaningless NameIDs, like hashes or purely random
> > 
> > strings. In general, SAML NameID is not predictable. To make things
> > 
> > worse, NameID can be different for SPs, so we can't simply peek it
> > in
> > 
> > another application already integrated with the IdP.
> > 
> > 
> > 
> > OTOH, incoming assertion is guaranteed to contain other attributes
> > that
> > 
> > are well-known to us and uniquely identify the user, like e.g.
> > mobile
> > 
> > phone number.
> > 
> > 
> > 
> > [1] https://github.com/keycloak/keycloak/blob/master/services/src/m
> > ain/
> > 
> > java/org/keycloak/broker/saml/SAMLEndpoint.java#L398?
> > 
> > 
> > 
> > Solution
> > 
> > ========
> > 
> > 
> > 
> > The problem could be solved by introducing a configurable (and thus
> > 
> > more flexible) mechanism to map SAML assertions to
> > FederatedIdentities.
> > 
> > With that, we could instruct Keycloak to take userId and userName
> > from
> > 
> > arbitrary assertion attributes, or even complex expression, similar
> > to
> > 
> > what we have in UsernameTemplateMapper.
> > 
> > 
> > 
> > Questions are:
> > 
> > 1. From what I've learned, this should be doable with the help of a
> > 
> > custom IdP mapper, using preprocessFederatedIdentity() method. Is
> > that
> > 
> > correct?
> > 
> > 2. Regardless of the answer to 1, would Keycloak team welcome this
> > 
> > contribution?
> > 
> > 
> > 
> > Some thoughts not directly related to this particular problem; from
> > my
> > 
> > 3+ years experience with Keycloak and its corporate users, I can
> > surely
> > 
> > tell that SAML under no circumstances should be considered either
> > 
> > legacy or obsolete. It is *very* actively used in the areas like
> > 
> > fintech, education and healthcare. I'd myself be happy to see
> > Keycloak
> > 
> > become 1st class SAML IdP/broker, and going to do my best to make
> > it
> > 
> > happen. I'm particularly interested in improving SAML/OIDC
> > 
> > interoperability in terms of IdP-initiated SSO and token exchange.
> > 
> > 
> > 
> > Best regards,
> > 
> > Dmitry
> > 
> > 
> > 
> > _______________________________________________
> > 
> > keycloak-dev mailing list
> > 
> > keycloak-dev at lists.jboss.org
> > 
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev

From jdennis at redhat.com  Thu Apr 25 09:26:37 2019
From: jdennis at redhat.com (John Dennis)
Date: Thu, 25 Apr 2019 09:26:37 -0400
Subject: [keycloak-dev] Proposal: more flexible brokered identity with
 SAML IdP
In-Reply-To: <1555629526.8282.2.camel@carretti.pro>
References: <1555629526.8282.2.camel@carretti.pro>
Message-ID: <3e95cf59-cf98-77d9-8613-78d25a7683da@redhat.com>

On 4/18/19 7:18 PM, Dmitry Telegin wrote:
> Currently, it is hardcoded [1] that FederatedIdentity's userId and
> userName should be taken verbatim from SAML assertion's NameID value
> (via intermediary BrokeredIdentityContext). The problem is that most
> SAML IdPs provide meaningless NameIDs, like hashes or purely random
> strings. In general, SAML NameID is not predictable.

Predictable NameID's are possible with SAML but to get them you must 
specify the desired NameIDPolicy in the request and the IdP must be 
capable of honoring that request. Have you determined the IdP's being 
utilized are incapable of honoring a NameIDPolicy of your choice?

-- 
John Dennis

From demetrio at carretti.pro  Thu Apr 25 09:35:09 2019
From: demetrio at carretti.pro (Dmitry Telegin)
Date: Thu, 25 Apr 2019 16:35:09 +0300
Subject: [keycloak-dev] Proposal: more flexible brokered identity with
 SAML IdP
In-Reply-To: <3e95cf59-cf98-77d9-8613-78d25a7683da@redhat.com>
References: <1555629526.8282.2.camel@carretti.pro>
	<3e95cf59-cf98-77d9-8613-78d25a7683da@redhat.com>
Message-ID: <1556199309.3603.7.camel@carretti.pro>

Hi John,

Yes, we have tried all the possible NameID policies. They are honored by the IdP, but none of them result in predictable NameID.

Moreover, identifying users by NameID is against Kantara recommendations, and we even have an issue in JIRA for that, please see my recent reply for the details.

Regards,
Dmitry

On Thu, 2019-04-25 at 09:26 -0400, John Dennis wrote:
> On 4/18/19 7:18 PM, Dmitry Telegin wrote:
> > Currently, it is hardcoded [1] that FederatedIdentity's userId and
> > userName should be taken verbatim from SAML assertion's NameID value
> > (via intermediary BrokeredIdentityContext). The problem is that most
> > SAML IdPs provide meaningless NameIDs, like hashes or purely random
> > strings. In general, SAML NameID is not predictable.
> 
> Predictable NameID's are possible with SAML but to get them you must?
> specify the desired NameIDPolicy in the request and the IdP must be?
> capable of honoring that request. Have you determined the IdP's being?
> utilized are incapable of honoring a NameIDPolicy of your choice?
> 

From orivat at janua.fr  Thu Apr 25 12:15:51 2019
From: orivat at janua.fr (Olivier Rivat)
Date: Thu, 25 Apr 2019 18:15:51 +0200
Subject: [keycloak-dev] docker quickstart example compilation is failing
 (keycloak 6.0.1) in photoz example
Message-ID: <73797a4a-fe75-49dc-77b9-9fca300ed143@janua.fr>

Hi,


Keyclaok 6.01 docker quickstart compilation is failing with error
java.lang.RuntimeException: Could not obtain configuration from server 
[http://localhost:8180/auth/realms/photoz/.well-known/uma-configuration

The instructions are taken from
https://hub.docker.com/r/abstractj/keycloak-quickstarts?ref=login

The endpoint 
http://localhost:8180/auth/realms/photoz/.well-known/uma-configuration 
deos not exist.
The (real) endpoint is 
http://localhost:8180/auth/realms/photoz/.well-known/uma2-configuration

This has to be fixed in the docker? quickstart example



Regards,

Olivier Rivat

--------------------------------------------------------------------------------------------------------------------


DEBUG] No <id> element was found in the POM - Getting credentials from 
CLI entry
[DEBUG] No <id> element was found in the POM - Getting credentials from 
CLI entry
[DEBUG] Executing deployment
[INFO] 
------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] 
------------------------------------------------------------------------
[INFO] Total time: 3.474 s
[INFO] Finished at: 2019-04-25T15:49:30+00:00
[INFO] Final Memory: 30M/366M
[INFO] 
------------------------------------------------------------------------
[ERROR] Failed to execute goal 
org.wildfly.plugins:wildfly-maven-plugin:1.2.0.Final:deploy 
(default-cli) on project photoz-uma-restful-api: Failed to execute goal 
deploy: {"WFLYCTL0062: Composite operatio
n failed and was rolled back. Steps that failed:" => {"Operation step-1" 
=> {"WFLYCTL0080: Failed services" => 
{"jboss.deployment.unit.\"photoz-uma-restful-api.war\".undertow-deployment" 
=> "java.lang.Run
timeException: Could not obtain configuration from server 
[http://localhost:8180/auth/realms/photoz/.well-known/uma-configuration].
[ERROR] Caused by: java.lang.RuntimeException: Could not obtain 
configuration from server 
[http://localhost:8180/auth/realms/photoz/.well-known/uma-configuration].
[ERROR] Caused by: java.lang.RuntimeException: Error executing http 
method [org.apache.http.client.methods.RequestBuilder at 2c0b0edc]. 
Response : null
[ERROR] Caused by: java.net.ConnectException: Connection refused 
(Connection refused)"}}}}
[ERROR] -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to 
execute goal org.wildfly.plugins:wildfly-maven-plugin:1.2.0.Final:deploy 
(default-cli) on project photoz-uma-restful-api: Failed to execut
e goal deploy: {"WFLYCTL0062: Composite operation failed and was rolled 
back. Steps that failed:" => {"Operation step-1" => {"WFLYCTL0080: 
Failed services" => {"jboss.deployment.unit.\"photoz-uma-restful-
api.war\".undertow-deployment" => "java.lang.RuntimeException: Could not 
obtain configuration from server 
[http://localhost:8180/auth/realms/photoz/.well-known/uma-configuration].
 ??? Caused by: java.lang.RuntimeException: Could not obtain 
configuration from server 
[http://localhost:8180/auth/realms/photoz/.well-known/uma-configuration].
 ??? Caused by: java.lang.RuntimeException: Error executing http method 
[org.apache.http.client.methods.RequestBuilder at 2c0b0edc]. Response : null
 ??? Caused by: java.net.ConnectException: Connection refused 
(Connection refused)"}}}}
 ??? at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)
 ??? at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
 ??? at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
 ??? at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
 ??? at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
 ??? at 
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)


------------------------------------------------------------------------------------------------------------------





From abhi.raghav007 at gmail.com  Thu Apr 25 12:23:55 2019
From: abhi.raghav007 at gmail.com (abhishek raghav)
Date: Thu, 25 Apr 2019 21:53:55 +0530
Subject: [keycloak-dev] HA mode with JDBC_PING shows warning in the logs
 after migration to 4.8.3 from 3.4.3
Message-ID: <CAJmz6fvZdvj5ted0xtgnrHR4kW0Yay7SUkqO5q_FG6BQ5yxLOw@mail.gmail.com>

Hi

After the migration of keycloak HA configurations from 3.4.3.Final to
4.8.3.Final, I am seeing some WARNINGS on one of the nodes of keycloak
immediately after the keycloak is started with 2 nodes. This occurs after
every time when the cluster is scaled up or whenever infinispan is trying
to update the cluster member list.
I am using JDBC_PING to achieve clustering in keycloak.

Below is the stacktrace -

2019-04-24 12:20:43,687 WARN
>> [org.infinispan.topology.ClusterTopologyManagerImpl]
>> (transport-thread--p18-t2) [dcidqdcosagent08] KEYCLOAK DEV 1.5.RC
>> ISPN000197: Error updating cluster member list:
>> org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out
>> waiting for responses for request 1 from dcidqdcosagent02
>
>                   at
>> org.infinispan.remoting.transport.impl.MultiTargetRequest.onTimeout(MultiTargetRequest.java:167)
>
>                   at
>> org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:87)
>
>                   at
>> org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:22)
>
>                   at
>> java.util.concurrent.FutureTask.run(FutureTask.java:266)
>
>                   at
>> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
>
>                   at
>> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
>
>                   at
>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>
>                   at
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>
>                   at java.lang.Thread.run(Thread.java:748)
>
>                   Suppressed: org.infinispan.util.logging.TraceException
>
>                                     at
>> org.infinispan.remoting.transport.Transport.invokeRemotely(Transport.java:75)
>
>                                     at
>> org.infinispan.topology.ClusterTopologyManagerImpl.confirmMembersAvailable(ClusterTopologyManagerImpl.java:525)
>
>                                     at
>> org.infinispan.topology.ClusterTopologyManagerImpl.updateCacheMembers(ClusterTopologyManagerImpl.java:508)
>
>

Now after I searched, I really did not see anyone reported such error on
keycloak but there is similar bug reported in WILDLFY 14 and is categorized
as a blocker in WILDLFY 14.This bug is already fixed in WILDLFY 15.
https://issues.jboss.org/browse/WFLY-10736?attachmentViewMode=list

Now since keycloak 4.8 is also based on WILDLFY 14, these WARNINGS could be
because of this blocker in WILDFLY 14.

What should I do to get rid this error. Is this really a problem in
keycloak 4.8.3.Final. Did anyone notice any such issue while running
keycloak 4.8.3 in HA mode.
Is there a workaround to fix this.


One more thing we noticed is - It is regarding a property in JDBC_PING
protocol we are using in our 3.4.3 setup i.e. "clear_table_on_view_change"
but it is no more supported in 4.8 version. and thus the JGROUPSPING table
is filled up with lot of stale entries. Is there a workaround to clear the
table after view change in 4.8 also.

Thanks
Abhishek

From bruno at abstractj.org  Thu Apr 25 15:32:52 2019
From: bruno at abstractj.org (Bruno Oliveira)
Date: Thu, 25 Apr 2019 16:32:52 -0300
Subject: [keycloak-dev] docker quickstart example compilation is failing
 (keycloak 6.0.1) in photoz example
In-Reply-To: <73797a4a-fe75-49dc-77b9-9fca300ed143@janua.fr>
References: <73797a4a-fe75-49dc-77b9-9fca300ed143@janua.fr>
Message-ID: <20190425193252.GB753@abstractj.org>

Hi Olivier, as far as I can tell, at the moment there's no official
Keycloak Docker quickstart example. The link you provided came from my
repository and honestly, that's very dated, from 6 months ago.

If you're looking for the most recent version of the quickstarts, please
take a look here https://github.com/keycloak/keycloak-quickstarts.


On 2019-04-25, Olivier Rivat wrote:
> Hi,
> 
> 
> Keyclaok 6.01 docker quickstart compilation is failing with error
> java.lang.RuntimeException: Could not obtain configuration from server 
> [http://localhost:8180/auth/realms/photoz/.well-known/uma-configuration
> 
> The instructions are taken from
> https://hub.docker.com/r/abstractj/keycloak-quickstarts?ref=login
> 
> The endpoint 
> http://localhost:8180/auth/realms/photoz/.well-known/uma-configuration 
> deos not exist.
> The (real) endpoint is 
> http://localhost:8180/auth/realms/photoz/.well-known/uma2-configuration
> 
> This has to be fixed in the docker? quickstart example
> 
> 
> 
> Regards,
> 
> Olivier Rivat
> 
> --------------------------------------------------------------------------------------------------------------------
> 
> 
> DEBUG] No <id> element was found in the POM - Getting credentials from 
> CLI entry
> [DEBUG] No <id> element was found in the POM - Getting credentials from 
> CLI entry
> [DEBUG] Executing deployment
> [INFO] 
> ------------------------------------------------------------------------
> [INFO] BUILD FAILURE
> [INFO] 
> ------------------------------------------------------------------------
> [INFO] Total time: 3.474 s
> [INFO] Finished at: 2019-04-25T15:49:30+00:00
> [INFO] Final Memory: 30M/366M
> [INFO] 
> ------------------------------------------------------------------------
> [ERROR] Failed to execute goal 
> org.wildfly.plugins:wildfly-maven-plugin:1.2.0.Final:deploy 
> (default-cli) on project photoz-uma-restful-api: Failed to execute goal 
> deploy: {"WFLYCTL0062: Composite operatio
> n failed and was rolled back. Steps that failed:" => {"Operation step-1" 
> => {"WFLYCTL0080: Failed services" => 
> {"jboss.deployment.unit.\"photoz-uma-restful-api.war\".undertow-deployment" 
> => "java.lang.Run
> timeException: Could not obtain configuration from server 
> [http://localhost:8180/auth/realms/photoz/.well-known/uma-configuration].
> [ERROR] Caused by: java.lang.RuntimeException: Could not obtain 
> configuration from server 
> [http://localhost:8180/auth/realms/photoz/.well-known/uma-configuration].
> [ERROR] Caused by: java.lang.RuntimeException: Error executing http 
> method [org.apache.http.client.methods.RequestBuilder at 2c0b0edc]. 
> Response : null
> [ERROR] Caused by: java.net.ConnectException: Connection refused 
> (Connection refused)"}}}}
> [ERROR] -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to 
> execute goal org.wildfly.plugins:wildfly-maven-plugin:1.2.0.Final:deploy 
> (default-cli) on project photoz-uma-restful-api: Failed to execut
> e goal deploy: {"WFLYCTL0062: Composite operation failed and was rolled 
> back. Steps that failed:" => {"Operation step-1" => {"WFLYCTL0080: 
> Failed services" => {"jboss.deployment.unit.\"photoz-uma-restful-
> api.war\".undertow-deployment" => "java.lang.RuntimeException: Could not 
> obtain configuration from server 
> [http://localhost:8180/auth/realms/photoz/.well-known/uma-configuration].
>  ??? Caused by: java.lang.RuntimeException: Could not obtain 
> configuration from server 
> [http://localhost:8180/auth/realms/photoz/.well-known/uma-configuration].
>  ??? Caused by: java.lang.RuntimeException: Error executing http method 
> [org.apache.http.client.methods.RequestBuilder at 2c0b0edc]. Response : null
>  ??? Caused by: java.net.ConnectException: Connection refused 
> (Connection refused)"}}}}
>  ??? at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)
>  ??? at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
>  ??? at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
>  ??? at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
>  ??? at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
>  ??? at 
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> 
> 
> ------------------------------------------------------------------------------------------------------------------
> 
> 
> 
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

-- 

abstractj

From slaskawi at redhat.com  Fri Apr 26 08:41:11 2019
From: slaskawi at redhat.com (Sebastian Laskawiec)
Date: Fri, 26 Apr 2019 14:41:11 +0200
Subject: [keycloak-dev] HA mode with JDBC_PING shows warning in the logs
 after migration to 4.8.3 from 3.4.3
In-Reply-To: <CAJmz6fvZdvj5ted0xtgnrHR4kW0Yay7SUkqO5q_FG6BQ5yxLOw@mail.gmail.com>
References: <CAJmz6fvZdvj5ted0xtgnrHR4kW0Yay7SUkqO5q_FG6BQ5yxLOw@mail.gmail.com>
Message-ID: <CAA9R9O5jCWQDCj3Ruf9w-kRwS9E_vK1x=dx6aLbeB5-7wESJjQ@mail.gmail.com>

There was a bunch of fixed to JGroups a while ago, including changes in
JDBC_PING.

Could you please rerun your setup with Keycloak >= 5.0.0? I believe some of
the issues (or maybe even all of them) should be fixed.

On Thu, Apr 25, 2019 at 7:19 PM abhishek raghav <abhi.raghav007 at gmail.com>
wrote:

> Hi
>
> After the migration of keycloak HA configurations from 3.4.3.Final to
> 4.8.3.Final, I am seeing some WARNINGS on one of the nodes of keycloak
> immediately after the keycloak is started with 2 nodes. This occurs after
> every time when the cluster is scaled up or whenever infinispan is trying
> to update the cluster member list.
> I am using JDBC_PING to achieve clustering in keycloak.
>
> Below is the stacktrace -
>
> 2019-04-24 12:20:43,687 WARN
> >> [org.infinispan.topology.ClusterTopologyManagerImpl]
> >> (transport-thread--p18-t2) [dcidqdcosagent08] KEYCLOAK DEV 1.5.RC
> >> ISPN000197: Error updating cluster member list:
> >> org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out
> >> waiting for responses for request 1 from dcidqdcosagent02
> >
> >                   at
> >>
> org.infinispan.remoting.transport.impl.MultiTargetRequest.onTimeout(MultiTargetRequest.java:167)
> >
> >                   at
> >>
> org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:87)
> >
> >                   at
> >>
> org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:22)
> >
> >                   at
> >> java.util.concurrent.FutureTask.run(FutureTask.java:266)
> >
> >                   at
> >>
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> >
> >                   at
> >>
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> >
> >                   at
> >>
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> >
> >                   at
> >>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> >
> >                   at java.lang.Thread.run(Thread.java:748)
> >
> >                   Suppressed: org.infinispan.util.logging.TraceException
> >
> >                                     at
> >>
> org.infinispan.remoting.transport.Transport.invokeRemotely(Transport.java:75)
> >
> >                                     at
> >>
> org.infinispan.topology.ClusterTopologyManagerImpl.confirmMembersAvailable(ClusterTopologyManagerImpl.java:525)
> >
> >                                     at
> >>
> org.infinispan.topology.ClusterTopologyManagerImpl.updateCacheMembers(ClusterTopologyManagerImpl.java:508)
> >
> >
>
> Now after I searched, I really did not see anyone reported such error on
> keycloak but there is similar bug reported in WILDLFY 14 and is categorized
> as a blocker in WILDLFY 14.This bug is already fixed in WILDLFY 15.
> https://issues.jboss.org/browse/WFLY-10736?attachmentViewMode=list
>
> Now since keycloak 4.8 is also based on WILDLFY 14, these WARNINGS could be
> because of this blocker in WILDFLY 14.
>
> What should I do to get rid this error. Is this really a problem in
> keycloak 4.8.3.Final. Did anyone notice any such issue while running
> keycloak 4.8.3 in HA mode.
> Is there a workaround to fix this.
>
>
> One more thing we noticed is - It is regarding a property in JDBC_PING
> protocol we are using in our 3.4.3 setup i.e. "clear_table_on_view_change"
> but it is no more supported in 4.8 version. and thus the JGROUPSPING table
> is filled up with lot of stale entries. Is there a workaround to clear the
> table after view change in 4.8 also.
>
> Thanks
> Abhishek
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From chris.smith at cmfirstgroup.com  Fri Apr 26 23:48:47 2019
From: chris.smith at cmfirstgroup.com (Chris Smith)
Date: Sat, 27 Apr 2019 03:48:47 +0000
Subject: [keycloak-dev] What m2e Eclipse plugins are required for developing
 keycloak in eclipse?
Message-ID: <CY4PR22MB0248475718D519F67DFD0935983F0@CY4PR22MB0248.namprd22.prod.outlook.com>

I'm guessing that all of the Eclipse problems I have when I check out keycloak from Github are from missing maven plugins in Eclipse support for maven
Is there a set of m2e connectors I should install?

From chris.smith at cmfirstgroup.com  Sat Apr 27 04:21:20 2019
From: chris.smith at cmfirstgroup.com (Chris Smith)
Date: Sat, 27 Apr 2019 08:21:20 +0000
Subject: [keycloak-dev] mvn install fails
In-Reply-To: <CAJgngAd+8scfeMsKg6bdfwqd+RwK7Uw4yC1gDLd4NpcDtOnBOg@mail.gmail.com>
References: <CY4PR22MB0248D34B6173C3724ACBD94A98230@CY4PR22MB0248.namprd22.prod.outlook.com>
	<CAJgngAd+8scfeMsKg6bdfwqd+RwK7Uw4yC1gDLd4NpcDtOnBOg@mail.gmail.com>
Message-ID: <BN6PR22MB0244CA2B6E4107A8A581DB87983F0@BN6PR22MB0244.namprd22.prod.outlook.com>

Here is a full build log https://gist.github.com/smitopher/72b75e362fa6f8856b8ea1808809e918



From: Stian Thorgersen <sthorger at redhat.com>
Sent: Wednesday, April 24, 2019 4:18 PM
To: Chris Smith <chris.smith at cmfirstgroup.com>
Cc: keycloak-dev at lists.jboss.org
Subject: Re: [keycloak-dev] mvn install fails

Looks like some test is failing, but you've not included the relevant part of the log that shows details of what test is failing.

On Tue, 23 Apr 2019 at 18:46, Chris Smith <chris.smith at cmfirstgroup.com<mailto:chris.smith at cmfirstgroup.com>> wrote:
A fresh clone from Github and mvn install fails to complete.
Any reason why?

Tests run: 2860, Failures: 0, Errors: 22, Skipped: 211

[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary for Keycloak 7.0.0-SNAPSHOT:
[INFO]
[INFO] Keycloak BOM Parent ................................ SUCCESS [ 11.402 s]
[INFO] Keycloak BOM for adapters .......................... SUCCESS [  0.111 s]
[INFO] Keycloak BOM for server extensions ................. SUCCESS [  0.105 s]
[INFO] Keycloak BOM utilities for the quickstarts ......... SUCCESS [  0.098 s]
[INFO] Keycloak ........................................... SUCCESS [  1.655 s]
[INFO] Keycloak Common .................................... SUCCESS [ 15.064 s]
[INFO] Keycloak Core ...................................... SUCCESS [ 12.195 s]
[INFO] Keycloak Dependencies Parent ....................... SUCCESS [  0.130 s]
[INFO] Keycloak Drools BOM ................................ SUCCESS [  0.129 s]
[INFO] Keycloak Server SPI ................................ SUCCESS [  3.287 s]
[INFO] Keycloak Server Private SPI ........................ SUCCESS [  8.419 s]
[INFO] Keycloak Kerberos Federation ....................... SUCCESS [  0.910 s]
[INFO] Keycloak LDAP UserStoreProvider .................... SUCCESS [  7.065 s]
[INFO] Keycloak SAML Core Public API ...................... SUCCESS [  2.849 s]
[INFO] Keycloak SAML Core ................................. SUCCESS [  9.528 s]
[INFO] Keycloak REST Services ............................. SUCCESS [ 25.199 s]
[INFO] Keycloak JS Integration ............................ SUCCESS [  5.176 s]
[INFO] Keycloak Themes .................................... SUCCESS [  9.625 s]
[INFO] Keycloak Dependencies Server Min ................... SUCCESS [  0.139 s]
[INFO] Keycloak Model Parent .............................. SUCCESS [  0.139 s]
[INFO] Keycloak Model JPA ................................. SUCCESS [  7.185 s]
[INFO] Keycloak Model Infinispan .......................... SUCCESS [ 13.296 s]
[INFO] Keycloak SSSD Federation ........................... SUCCESS [  5.565 s]
[INFO] KeyCloak Authz: Parent ............................. SUCCESS [  0.222 s]
[INFO] KeyCloak AuthZ: Provider Parent .................... SUCCESS [  0.182 s]
[INFO] KeyCloak AuthZ: Common Policy Providers ............ SUCCESS [  2.537 s]
[INFO] KeyCloak AuthZ: Drools Policy Provider ............. SUCCESS [  1.934 s]
[INFO] Keycloak Dependencies Server All ................... SUCCESS [  0.195 s]
[INFO] Keycloak Federation ................................ SUCCESS [  0.220 s]
[INFO] Keycloak Util Embedded LDAP ........................ SUCCESS [  3.089 s]
[INFO] Keycloak Util Parent ............................... SUCCESS [  0.209 s]
[INFO] Keycloak WildFly Integration ....................... SUCCESS [  0.184 s]
[INFO] Keycloak WildFly Add User Script ................... SUCCESS [  1.151 s]
[INFO] Keycloak WildFly Extensions ........................ SUCCESS [  1.184 s]
[INFO] Keycloak WildFly Server Subsystem .................. SUCCESS [  8.763 s]
[INFO] Keycloak Integration ............................... SUCCESS [  0.133 s]
[INFO] Keycloak Admin REST Client ......................... SUCCESS [  1.111 s]
[INFO] Keycloak Client Registration API ................... SUCCESS [  0.736 s]
[INFO] Keycloak Client CLI ................................ SUCCESS [  0.133 s]
[INFO] Keycloak Client Registration CLI ................... SUCCESS [  6.737 s]
[INFO] Keycloak Admin CLI ................................. SUCCESS [  5.972 s]
[INFO] Keycloak Client CLI Distribution ................... SUCCESS [  3.475 s]
[INFO] Keycloak Adapter SPI ............................... SUCCESS [  0.939 s]
[INFO] Keycloak Tomcat Adapter SPI ........................ SUCCESS [  0.822 s]
[INFO] Keycloak Undertow Integration SPI .................. SUCCESS [  1.166 s]
[INFO] Keycloak Servlet Integration ....................... SUCCESS [  0.828 s]
[INFO] Common JBoss/Wildfly Core Classes .................. SUCCESS [  0.591 s]
[INFO] Keycloak Jetty Adapter SPI ......................... SUCCESS [  0.928 s]
[INFO] Keycloak Client Adapter SPI Modules ................ SUCCESS [  0.163 s]
[INFO] Keycloak SAML Client Adapter Public API ............ SUCCESS [  0.621 s]
[INFO] Keycloak SAML Client Adapter Core .................. SUCCESS [  5.196 s]
[INFO] Keycloak Undertow SAML Adapter ..................... SUCCESS [  1.009 s]
[INFO] Keycloak SAML Tomcat Integration ................... SUCCESS [  0.165 s]
[INFO] Keycloak Tomcat Core SAML Integration .............. SUCCESS [  0.839 s]
[INFO] Keycloak Tomcat 8 SAML Integration ................. SUCCESS [  0.743 s]
[INFO] Keycloak Tomcat 6 Saml Integration ................. SUCCESS [  0.617 s]
[INFO] Keycloak Tomcat 7 SAML Integration ................. SUCCESS [  0.625 s]
[INFO] Keycloak Wildfly SAML Adapter ...................... SUCCESS [  0.999 s]
[INFO] KeyCloak Authz: Client API ......................... SUCCESS [  1.963 s]
[INFO] Keycloak Adapter Core .............................. SUCCESS [  6.558 s]
[INFO] Keycloak WildFly Elytron SAML Adapter .............. SUCCESS [  1.130 s]
[INFO] Keycloak Wildfly SAML Adapter Subsystem ............ SUCCESS [  7.527 s]
[INFO] Keycloak SAML Wildfly Integration .................. SUCCESS [  0.146 s]
[INFO] Keycloak AS7 / JBoss EAP 6 Integration ............. SUCCESS [  0.183 s]
[INFO] Keycloak AS7 SPI ................................... SUCCESS [  3.170 s]
[INFO] Keycloak SAML EAP Integration ...................... SUCCESS [  0.130 s]
[INFO] Keycloak SAML AS7 Integration ...................... SUCCESS [  1.062 s]
[INFO] Keycloak SAML AS7 Subsystem ........................ SUCCESS [  5.323 s]
[INFO] Keycloak SAML Servlet Filter ....................... SUCCESS [  0.804 s]
[INFO] Keycloak Jetty Core SAML Integration ............... SUCCESS [  0.865 s]
[INFO] Keycloak Jetty 9.2.x SAML Integration .............. SUCCESS [  0.820 s]
[INFO] Keycloak Jetty 9.3.x SAML Integration .............. SUCCESS [  0.894 s]
[INFO] Keycloak Jetty 9.4.x SAML Integration .............. SUCCESS [  1.066 s]
[INFO] Keycloak SAML Jetty Integration .................... SUCCESS [  0.144 s]
[INFO] Keycloak SAML Client Adapter Modules ............... SUCCESS [  0.132 s]
[INFO] Keycloak Tomcat Integration ........................ SUCCESS [  0.140 s]
[INFO] Keycloak Tomcat Core Integration ................... SUCCESS [  0.758 s]
[INFO] Keycloak AS7 Integration ........................... SUCCESS [  0.906 s]
[INFO] Keycloak AS7 Subsystem ............................. SUCCESS [  4.368 s]
[INFO] Keycloak Installed Application ..................... SUCCESS [  1.609 s]
[INFO] Keycloak Undertow Integration ...................... SUCCESS [  2.295 s]
[INFO] Keycloak Fuse 7.0 Integration ...................... SUCCESS [  0.161 s]
[INFO] Keycloak Fuse 7.0 Adapter - Camel + Undertow ....... SUCCESS [  1.773 s]
[INFO] Keycloak OSGI Adapter .............................. SUCCESS [  3.531 s]
[INFO] Keycloak Fuse 7.0 Adapter - Undertow ............... SUCCESS [  1.514 s]
[INFO] Keycloak Jetty Core Integration .................... SUCCESS [  1.175 s]
[INFO] Keycloak Jetty 9.4.x Integration ................... SUCCESS [  0.945 s]
[INFO] Keycloak Fuse 7.0 Adapter - Jetty 9.4 .............. SUCCESS [  1.345 s]
[INFO] Keycloak Tomcat 8 Integration ...................... SUCCESS [  0.767 s]
[INFO] Keycloak Fuse 7.0 Adapter - Tomcat 8 ............... SUCCESS [  1.105 s]
[INFO] Keycloak CLI SSO Framework ......................... SUCCESS [  4.620 s]
[INFO] Keycloak JAX-RS OAuth Client ....................... SUCCESS [  1.314 s]
[INFO] Keycloak Jetty 9.2.x Integration ................... SUCCESS [  1.142 s]
[INFO] Keycloak Jetty 9.3.x Integration ................... SUCCESS [  1.144 s]
[INFO] Keycloak Jetty Integration ......................... SUCCESS [  0.173 s]
[INFO] Keycloak Servlet Filter Adapter Integration ........ SUCCESS [  1.061 s]
[INFO] Keycloak Servlet OAuth Client ...................... SUCCESS [  4.150 s]
[INFO] spring-boot-container-bundle ....................... SUCCESS [  1.761 s]
[INFO] Keycloak Spring Security Integration ............... SUCCESS [  8.449 s]
[INFO] Keycloak Spring Boot Adapter Core .................. SUCCESS [  1.759 s]
[INFO] Keycloak Spring Boot Integration ................... SUCCESS [  4.437 s]
[INFO] Keycloak Spring Boot 2 Integration ................. SUCCESS [  4.172 s]
[INFO] Keycloak Tomcat 6 Integration ...................... SUCCESS [  0.689 s]
[INFO] Keycloak Tomcat 7 Integration ...................... SUCCESS [  0.761 s]
[INFO] Keycloak Wildfly Integration ....................... SUCCESS [  0.998 s]
[INFO] Keycloak Wildfly Elytron OIDC Adapter .............. SUCCESS [  1.763 s]
[INFO] Keycloak Wildfly Adapter Subsystem ................. SUCCESS [  8.862 s]
[INFO] Keycloak Wildfly 8 Adapter Subsystem ............... SUCCESS [  5.703 s]
[INFO] Keycloak WildFly Integration ....................... SUCCESS [  0.138 s]
[INFO] Keycloak OIDC Client Adapter Modules ............... SUCCESS [  0.124 s]
[INFO] Keycloak Adapters .................................. SUCCESS [  0.130 s]
[INFO] Keycloak Misc ...................................... SUCCESS [  0.138 s]
[INFO] Keycloak :: Spring :: Boot ......................... SUCCESS [  0.148 s]
[INFO] Keycloak :: Spring :: Boot :: Default ::  Starter .. SUCCESS [  0.371 s]
[INFO] Keycloak :: Spring :: Boot ......................... SUCCESS [  0.139 s]
[INFO] Keycloak :: Legacy :: Spring :: Boot :: Default ::  Starter SUCCESS [  0.388 s]
[INFO] keycloak-test-helper ............................... SUCCESS [  0.937 s]
[INFO] Keycloak TestSuite ................................. SUCCESS [  0.128 s]
[INFO] DB Allocator Plugin ................................ SUCCESS [ 14.444 s]
[INFO] Keycloak Arquillian Integration TestSuite .......... SUCCESS [  0.212 s]
[INFO] Test apps .......................................... SUCCESS [  0.144 s]
[INFO] Test apps distribution ............................. SUCCESS [  7.201 s]
[INFO] Keycloak Authz: PhotoZ  Test Parent ................ SUCCESS [  0.145 s]
[INFO] Keycloak Authz Test: Photoz RESTful API ............ SUCCESS [  1.871 s]
[INFO] Keycloak Authz Tests: Photoz HTML5 Client .......... SUCCESS [  1.330 s]
[INFO] Keycloak Authz Tests: Photoz Authz Rule-based Policy SUCCESS [  0.442 s]
[INFO] Keycloak Authz Tests: Hello World Example .......... SUCCESS [  0.406 s]
[INFO] Keycloak Authz: Servlet Authorization Test ......... SUCCESS [  0.577 s]
[INFO] Keycloak Authz: Simple Servlet App with Policy Enforcer SUCCESS [  0.393 s]
[INFO] integration-arquillian-test-apps-servlets .......... SUCCESS [  1.327 s]
[INFO] Keycloak Test App Profile JEE ...................... SUCCESS [  0.638 s]
[INFO] integration-arquillian-test-apps-cors-parent ....... SUCCESS [  0.144 s]
[INFO] Angular Product Portal JS .......................... SUCCESS [  2.995 s]
[INFO] JAX-RS Database Service Using OAuth Bearer Tokens .. SUCCESS [  0.728 s]
[INFO] Fuse Test Applications ............................. SUCCESS [  0.139 s]
[INFO] Customer Portal - Secured in Karaf/Fuse ............ SUCCESS [  1.778 s]
[INFO] CXF JAXRS Example - Secured in Karaf/Fuse .......... SUCCESS [  2.099 s]
[INFO] CXF JAXRS Example - Secured in Karaf/Fuse 7.0 on Undertow SUCCESS [  0.798 s]
[INFO] CXF JAXWS Example - Secured in Karaf/Fuse .......... SUCCESS [  1.012 s]
[INFO] CXF JAXWS Example - Secured in Karaf/Fuse 7.0 on Undertow SUCCESS [  0.830 s]
[INFO] Product Portal - Secured in Karaf/Fuse ............. SUCCESS [  0.960 s]
[INFO] Product Portal - Secured in Karaf/Fuse 7.0 on Undertow SUCCESS [  1.012 s]
[INFO] Camel endpoint example - Secured in Karaf/Fuse ..... SUCCESS [  0.779 s]
[INFO] Camel endpoint example - Secured in Karaf/Fuse 7.0 on Undertow SUCCESS [  0.879 s]
[INFO] Keycloak Fuse Example - Features ................... SUCCESS [  0.670 s]
[INFO] Keycloak Examples - External Config ................ SUCCESS [  0.776 s]
[INFO] spring-boot-adapter ................................ SUCCESS [  1.358 s]
[INFO] spring-boot-adapter-2 .............................. SUCCESS [  1.571 s]
[INFO] spring-boot-adapter-21 ............................. SUCCESS [  1.435 s]
[INFO] Servers ............................................ SUCCESS [  0.152 s]
[INFO] Auth Server ........................................ SUCCESS [  0.127 s]
[INFO] Auth Server Services ............................... SUCCESS [  0.129 s]
[INFO] Auth Server Services - Testsuite Providers ......... SUCCESS [  5.076 s]
[INFO] Auth Server - JBoss ................................ SUCCESS [  0.131 s]
[INFO] Keycloak TestSuite Utils ........................... SUCCESS [  2.794 s]
[INFO] Test Util .......................................... SUCCESS [  1.798 s]
[INFO] Auth Server - Undertow ............................. SUCCESS [  2.305 s]
[INFO] App Server ......................................... SUCCESS [  0.137 s]
[INFO] App Server - SPI ................................... SUCCESS [  0.541 s]
[INFO] App Server - JBoss ................................. SUCCESS [  0.132 s]
[INFO] App Server - Karaf ................................. SUCCESS [  0.127 s]
[INFO] App Server - Tomcat ................................ SUCCESS [  0.130 s]
[INFO] App Server - Undertow .............................. SUCCESS [  1.122 s]
[INFO] App Server - Jetty Parent .......................... SUCCESS [  0.151 s]
[INFO] Cache Server ....................................... SUCCESS [  0.119 s]
[INFO] Cache Server - JBoss Family ........................ SUCCESS [  0.124 s]
[INFO] Tests .............................................. SUCCESS [  0.493 s]
[INFO] Base TestSuite ..................................... FAILURE [  01:45 h]
[INFO] Other Tests Modules ................................ SKIPPED
[INFO] Adapter Tests ...................................... SKIPPED
[INFO] Adapter Tests - JBoss .............................. SKIPPED
[INFO] Adapter Tests - Karaf .............................. SKIPPED
[INFO] Adapter Tests - WAS ................................ SKIPPED
[INFO] Adapter Tests - WLS ................................ SKIPPED
[INFO] SSSD tests ......................................... SKIPPED
[INFO] integration-arquillian-tests-springboot ............ SKIPPED
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  01:51 h
[INFO] Finished at: 2019-04-23T19:51:55+08:00
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test (default-test) on project integration-arquillian-tests-base: There are test failures.
[ERROR]
[ERROR] Please refer to C:\Users\christopher.smith\Documents\keycloak\workspace\keycloak-parent\testsuite\integration-arquillian\tests\base\target\surefire-reports for the individual test results.
[ERROR] -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
[ERROR]
[ERROR] After correcting the problems, you can resume the build with the command
[ERROR]   mvn <goals> -rf :integration-arquillian-tests-base

C:\Users\christopher.smith\Documents\keycloak\workspace\keycloak-parent>
_______________________________________________
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

From vramik at redhat.com  Sun Apr 28 05:36:00 2019
From: vramik at redhat.com (Vlasta Ramik)
Date: Sun, 28 Apr 2019 11:36:00 +0200
Subject: [keycloak-dev] mvn install fails
In-Reply-To: <BN6PR22MB0244CA2B6E4107A8A581DB87983F0@BN6PR22MB0244.namprd22.prod.outlook.com>
References: <CY4PR22MB0248D34B6173C3724ACBD94A98230@CY4PR22MB0248.namprd22.prod.outlook.com>
	<CAJgngAd+8scfeMsKg6bdfwqd+RwK7Uw4yC1gDLd4NpcDtOnBOg@mail.gmail.com>
	<BN6PR22MB0244CA2B6E4107A8A581DB87983F0@BN6PR22MB0244.namprd22.prod.outlook.com>
Message-ID: <6592fef9-212c-ba25-4927-e7bb0bb80a75@redhat.com>

 From quick look at the log, the first failed test is 
ClaimInformationPointProviderTest. The test fails when tries to start 
undertow on localhost:8989 [1] and the address is already used. Pls make 
sure there is nothing running on that port at you env and try to run it 
again.

V.

[1] 
https://github.com/keycloak/keycloak/blob/master/testsuite/integration-arquillian/tests/base/src/test/java/org/keycloak/testsuite/admin/client/authorization/ClaimInformationPointProviderTest.java#L79

On 4/27/19 10:21 AM, Chris Smith wrote:
> Here is a full build log https://gist.github.com/smitopher/72b75e362fa6f8856b8ea1808809e918
>
>
>
> From: Stian Thorgersen <sthorger at redhat.com>
> Sent: Wednesday, April 24, 2019 4:18 PM
> To: Chris Smith <chris.smith at cmfirstgroup.com>
> Cc: keycloak-dev at lists.jboss.org
> Subject: Re: [keycloak-dev] mvn install fails
>
> Looks like some test is failing, but you've not included the relevant part of the log that shows details of what test is failing.
>
> On Tue, 23 Apr 2019 at 18:46, Chris Smith <chris.smith at cmfirstgroup.com<mailto:chris.smith at cmfirstgroup.com>> wrote:
> A fresh clone from Github and mvn install fails to complete.
> Any reason why?
>
> Tests run: 2860, Failures: 0, Errors: 22, Skipped: 211
>
> [INFO] ------------------------------------------------------------------------
> [INFO] Reactor Summary for Keycloak 7.0.0-SNAPSHOT:
> [INFO]
> [INFO] Keycloak BOM Parent ................................ SUCCESS [ 11.402 s]
> [INFO] Keycloak BOM for adapters .......................... SUCCESS [  0.111 s]
> [INFO] Keycloak BOM for server extensions ................. SUCCESS [  0.105 s]
> [INFO] Keycloak BOM utilities for the quickstarts ......... SUCCESS [  0.098 s]
> [INFO] Keycloak ........................................... SUCCESS [  1.655 s]
> [INFO] Keycloak Common .................................... SUCCESS [ 15.064 s]
> [INFO] Keycloak Core ...................................... SUCCESS [ 12.195 s]
> [INFO] Keycloak Dependencies Parent ....................... SUCCESS [  0.130 s]
> [INFO] Keycloak Drools BOM ................................ SUCCESS [  0.129 s]
> [INFO] Keycloak Server SPI ................................ SUCCESS [  3.287 s]
> [INFO] Keycloak Server Private SPI ........................ SUCCESS [  8.419 s]
> [INFO] Keycloak Kerberos Federation ....................... SUCCESS [  0.910 s]
> [INFO] Keycloak LDAP UserStoreProvider .................... SUCCESS [  7.065 s]
> [INFO] Keycloak SAML Core Public API ...................... SUCCESS [  2.849 s]
> [INFO] Keycloak SAML Core ................................. SUCCESS [  9.528 s]
> [INFO] Keycloak REST Services ............................. SUCCESS [ 25.199 s]
> [INFO] Keycloak JS Integration ............................ SUCCESS [  5.176 s]
> [INFO] Keycloak Themes .................................... SUCCESS [  9.625 s]
> [INFO] Keycloak Dependencies Server Min ................... SUCCESS [  0.139 s]
> [INFO] Keycloak Model Parent .............................. SUCCESS [  0.139 s]
> [INFO] Keycloak Model JPA ................................. SUCCESS [  7.185 s]
> [INFO] Keycloak Model Infinispan .......................... SUCCESS [ 13.296 s]
> [INFO] Keycloak SSSD Federation ........................... SUCCESS [  5.565 s]
> [INFO] KeyCloak Authz: Parent ............................. SUCCESS [  0.222 s]
> [INFO] KeyCloak AuthZ: Provider Parent .................... SUCCESS [  0.182 s]
> [INFO] KeyCloak AuthZ: Common Policy Providers ............ SUCCESS [  2.537 s]
> [INFO] KeyCloak AuthZ: Drools Policy Provider ............. SUCCESS [  1.934 s]
> [INFO] Keycloak Dependencies Server All ................... SUCCESS [  0.195 s]
> [INFO] Keycloak Federation ................................ SUCCESS [  0.220 s]
> [INFO] Keycloak Util Embedded LDAP ........................ SUCCESS [  3.089 s]
> [INFO] Keycloak Util Parent ............................... SUCCESS [  0.209 s]
> [INFO] Keycloak WildFly Integration ....................... SUCCESS [  0.184 s]
> [INFO] Keycloak WildFly Add User Script ................... SUCCESS [  1.151 s]
> [INFO] Keycloak WildFly Extensions ........................ SUCCESS [  1.184 s]
> [INFO] Keycloak WildFly Server Subsystem .................. SUCCESS [  8.763 s]
> [INFO] Keycloak Integration ............................... SUCCESS [  0.133 s]
> [INFO] Keycloak Admin REST Client ......................... SUCCESS [  1.111 s]
> [INFO] Keycloak Client Registration API ................... SUCCESS [  0.736 s]
> [INFO] Keycloak Client CLI ................................ SUCCESS [  0.133 s]
> [INFO] Keycloak Client Registration CLI ................... SUCCESS [  6.737 s]
> [INFO] Keycloak Admin CLI ................................. SUCCESS [  5.972 s]
> [INFO] Keycloak Client CLI Distribution ................... SUCCESS [  3.475 s]
> [INFO] Keycloak Adapter SPI ............................... SUCCESS [  0.939 s]
> [INFO] Keycloak Tomcat Adapter SPI ........................ SUCCESS [  0.822 s]
> [INFO] Keycloak Undertow Integration SPI .................. SUCCESS [  1.166 s]
> [INFO] Keycloak Servlet Integration ....................... SUCCESS [  0.828 s]
> [INFO] Common JBoss/Wildfly Core Classes .................. SUCCESS [  0.591 s]
> [INFO] Keycloak Jetty Adapter SPI ......................... SUCCESS [  0.928 s]
> [INFO] Keycloak Client Adapter SPI Modules ................ SUCCESS [  0.163 s]
> [INFO] Keycloak SAML Client Adapter Public API ............ SUCCESS [  0.621 s]
> [INFO] Keycloak SAML Client Adapter Core .................. SUCCESS [  5.196 s]
> [INFO] Keycloak Undertow SAML Adapter ..................... SUCCESS [  1.009 s]
> [INFO] Keycloak SAML Tomcat Integration ................... SUCCESS [  0.165 s]
> [INFO] Keycloak Tomcat Core SAML Integration .............. SUCCESS [  0.839 s]
> [INFO] Keycloak Tomcat 8 SAML Integration ................. SUCCESS [  0.743 s]
> [INFO] Keycloak Tomcat 6 Saml Integration ................. SUCCESS [  0.617 s]
> [INFO] Keycloak Tomcat 7 SAML Integration ................. SUCCESS [  0.625 s]
> [INFO] Keycloak Wildfly SAML Adapter ...................... SUCCESS [  0.999 s]
> [INFO] KeyCloak Authz: Client API ......................... SUCCESS [  1.963 s]
> [INFO] Keycloak Adapter Core .............................. SUCCESS [  6.558 s]
> [INFO] Keycloak WildFly Elytron SAML Adapter .............. SUCCESS [  1.130 s]
> [INFO] Keycloak Wildfly SAML Adapter Subsystem ............ SUCCESS [  7.527 s]
> [INFO] Keycloak SAML Wildfly Integration .................. SUCCESS [  0.146 s]
> [INFO] Keycloak AS7 / JBoss EAP 6 Integration ............. SUCCESS [  0.183 s]
> [INFO] Keycloak AS7 SPI ................................... SUCCESS [  3.170 s]
> [INFO] Keycloak SAML EAP Integration ...................... SUCCESS [  0.130 s]
> [INFO] Keycloak SAML AS7 Integration ...................... SUCCESS [  1.062 s]
> [INFO] Keycloak SAML AS7 Subsystem ........................ SUCCESS [  5.323 s]
> [INFO] Keycloak SAML Servlet Filter ....................... SUCCESS [  0.804 s]
> [INFO] Keycloak Jetty Core SAML Integration ............... SUCCESS [  0.865 s]
> [INFO] Keycloak Jetty 9.2.x SAML Integration .............. SUCCESS [  0.820 s]
> [INFO] Keycloak Jetty 9.3.x SAML Integration .............. SUCCESS [  0.894 s]
> [INFO] Keycloak Jetty 9.4.x SAML Integration .............. SUCCESS [  1.066 s]
> [INFO] Keycloak SAML Jetty Integration .................... SUCCESS [  0.144 s]
> [INFO] Keycloak SAML Client Adapter Modules ............... SUCCESS [  0.132 s]
> [INFO] Keycloak Tomcat Integration ........................ SUCCESS [  0.140 s]
> [INFO] Keycloak Tomcat Core Integration ................... SUCCESS [  0.758 s]
> [INFO] Keycloak AS7 Integration ........................... SUCCESS [  0.906 s]
> [INFO] Keycloak AS7 Subsystem ............................. SUCCESS [  4.368 s]
> [INFO] Keycloak Installed Application ..................... SUCCESS [  1.609 s]
> [INFO] Keycloak Undertow Integration ...................... SUCCESS [  2.295 s]
> [INFO] Keycloak Fuse 7.0 Integration ...................... SUCCESS [  0.161 s]
> [INFO] Keycloak Fuse 7.0 Adapter - Camel + Undertow ....... SUCCESS [  1.773 s]
> [INFO] Keycloak OSGI Adapter .............................. SUCCESS [  3.531 s]
> [INFO] Keycloak Fuse 7.0 Adapter - Undertow ............... SUCCESS [  1.514 s]
> [INFO] Keycloak Jetty Core Integration .................... SUCCESS [  1.175 s]
> [INFO] Keycloak Jetty 9.4.x Integration ................... SUCCESS [  0.945 s]
> [INFO] Keycloak Fuse 7.0 Adapter - Jetty 9.4 .............. SUCCESS [  1.345 s]
> [INFO] Keycloak Tomcat 8 Integration ...................... SUCCESS [  0.767 s]
> [INFO] Keycloak Fuse 7.0 Adapter - Tomcat 8 ............... SUCCESS [  1.105 s]
> [INFO] Keycloak CLI SSO Framework ......................... SUCCESS [  4.620 s]
> [INFO] Keycloak JAX-RS OAuth Client ....................... SUCCESS [  1.314 s]
> [INFO] Keycloak Jetty 9.2.x Integration ................... SUCCESS [  1.142 s]
> [INFO] Keycloak Jetty 9.3.x Integration ................... SUCCESS [  1.144 s]
> [INFO] Keycloak Jetty Integration ......................... SUCCESS [  0.173 s]
> [INFO] Keycloak Servlet Filter Adapter Integration ........ SUCCESS [  1.061 s]
> [INFO] Keycloak Servlet OAuth Client ...................... SUCCESS [  4.150 s]
> [INFO] spring-boot-container-bundle ....................... SUCCESS [  1.761 s]
> [INFO] Keycloak Spring Security Integration ............... SUCCESS [  8.449 s]
> [INFO] Keycloak Spring Boot Adapter Core .................. SUCCESS [  1.759 s]
> [INFO] Keycloak Spring Boot Integration ................... SUCCESS [  4.437 s]
> [INFO] Keycloak Spring Boot 2 Integration ................. SUCCESS [  4.172 s]
> [INFO] Keycloak Tomcat 6 Integration ...................... SUCCESS [  0.689 s]
> [INFO] Keycloak Tomcat 7 Integration ...................... SUCCESS [  0.761 s]
> [INFO] Keycloak Wildfly Integration ....................... SUCCESS [  0.998 s]
> [INFO] Keycloak Wildfly Elytron OIDC Adapter .............. SUCCESS [  1.763 s]
> [INFO] Keycloak Wildfly Adapter Subsystem ................. SUCCESS [  8.862 s]
> [INFO] Keycloak Wildfly 8 Adapter Subsystem ............... SUCCESS [  5.703 s]
> [INFO] Keycloak WildFly Integration ....................... SUCCESS [  0.138 s]
> [INFO] Keycloak OIDC Client Adapter Modules ............... SUCCESS [  0.124 s]
> [INFO] Keycloak Adapters .................................. SUCCESS [  0.130 s]
> [INFO] Keycloak Misc ...................................... SUCCESS [  0.138 s]
> [INFO] Keycloak :: Spring :: Boot ......................... SUCCESS [  0.148 s]
> [INFO] Keycloak :: Spring :: Boot :: Default ::  Starter .. SUCCESS [  0.371 s]
> [INFO] Keycloak :: Spring :: Boot ......................... SUCCESS [  0.139 s]
> [INFO] Keycloak :: Legacy :: Spring :: Boot :: Default ::  Starter SUCCESS [  0.388 s]
> [INFO] keycloak-test-helper ............................... SUCCESS [  0.937 s]
> [INFO] Keycloak TestSuite ................................. SUCCESS [  0.128 s]
> [INFO] DB Allocator Plugin ................................ SUCCESS [ 14.444 s]
> [INFO] Keycloak Arquillian Integration TestSuite .......... SUCCESS [  0.212 s]
> [INFO] Test apps .......................................... SUCCESS [  0.144 s]
> [INFO] Test apps distribution ............................. SUCCESS [  7.201 s]
> [INFO] Keycloak Authz: PhotoZ  Test Parent ................ SUCCESS [  0.145 s]
> [INFO] Keycloak Authz Test: Photoz RESTful API ............ SUCCESS [  1.871 s]
> [INFO] Keycloak Authz Tests: Photoz HTML5 Client .......... SUCCESS [  1.330 s]
> [INFO] Keycloak Authz Tests: Photoz Authz Rule-based Policy SUCCESS [  0.442 s]
> [INFO] Keycloak Authz Tests: Hello World Example .......... SUCCESS [  0.406 s]
> [INFO] Keycloak Authz: Servlet Authorization Test ......... SUCCESS [  0.577 s]
> [INFO] Keycloak Authz: Simple Servlet App with Policy Enforcer SUCCESS [  0.393 s]
> [INFO] integration-arquillian-test-apps-servlets .......... SUCCESS [  1.327 s]
> [INFO] Keycloak Test App Profile JEE ...................... SUCCESS [  0.638 s]
> [INFO] integration-arquillian-test-apps-cors-parent ....... SUCCESS [  0.144 s]
> [INFO] Angular Product Portal JS .......................... SUCCESS [  2.995 s]
> [INFO] JAX-RS Database Service Using OAuth Bearer Tokens .. SUCCESS [  0.728 s]
> [INFO] Fuse Test Applications ............................. SUCCESS [  0.139 s]
> [INFO] Customer Portal - Secured in Karaf/Fuse ............ SUCCESS [  1.778 s]
> [INFO] CXF JAXRS Example - Secured in Karaf/Fuse .......... SUCCESS [  2.099 s]
> [INFO] CXF JAXRS Example - Secured in Karaf/Fuse 7.0 on Undertow SUCCESS [  0.798 s]
> [INFO] CXF JAXWS Example - Secured in Karaf/Fuse .......... SUCCESS [  1.012 s]
> [INFO] CXF JAXWS Example - Secured in Karaf/Fuse 7.0 on Undertow SUCCESS [  0.830 s]
> [INFO] Product Portal - Secured in Karaf/Fuse ............. SUCCESS [  0.960 s]
> [INFO] Product Portal - Secured in Karaf/Fuse 7.0 on Undertow SUCCESS [  1.012 s]
> [INFO] Camel endpoint example - Secured in Karaf/Fuse ..... SUCCESS [  0.779 s]
> [INFO] Camel endpoint example - Secured in Karaf/Fuse 7.0 on Undertow SUCCESS [  0.879 s]
> [INFO] Keycloak Fuse Example - Features ................... SUCCESS [  0.670 s]
> [INFO] Keycloak Examples - External Config ................ SUCCESS [  0.776 s]
> [INFO] spring-boot-adapter ................................ SUCCESS [  1.358 s]
> [INFO] spring-boot-adapter-2 .............................. SUCCESS [  1.571 s]
> [INFO] spring-boot-adapter-21 ............................. SUCCESS [  1.435 s]
> [INFO] Servers ............................................ SUCCESS [  0.152 s]
> [INFO] Auth Server ........................................ SUCCESS [  0.127 s]
> [INFO] Auth Server Services ............................... SUCCESS [  0.129 s]
> [INFO] Auth Server Services - Testsuite Providers ......... SUCCESS [  5.076 s]
> [INFO] Auth Server - JBoss ................................ SUCCESS [  0.131 s]
> [INFO] Keycloak TestSuite Utils ........................... SUCCESS [  2.794 s]
> [INFO] Test Util .......................................... SUCCESS [  1.798 s]
> [INFO] Auth Server - Undertow ............................. SUCCESS [  2.305 s]
> [INFO] App Server ......................................... SUCCESS [  0.137 s]
> [INFO] App Server - SPI ................................... SUCCESS [  0.541 s]
> [INFO] App Server - JBoss ................................. SUCCESS [  0.132 s]
> [INFO] App Server - Karaf ................................. SUCCESS [  0.127 s]
> [INFO] App Server - Tomcat ................................ SUCCESS [  0.130 s]
> [INFO] App Server - Undertow .............................. SUCCESS [  1.122 s]
> [INFO] App Server - Jetty Parent .......................... SUCCESS [  0.151 s]
> [INFO] Cache Server ....................................... SUCCESS [  0.119 s]
> [INFO] Cache Server - JBoss Family ........................ SUCCESS [  0.124 s]
> [INFO] Tests .............................................. SUCCESS [  0.493 s]
> [INFO] Base TestSuite ..................................... FAILURE [  01:45 h]
> [INFO] Other Tests Modules ................................ SKIPPED
> [INFO] Adapter Tests ...................................... SKIPPED
> [INFO] Adapter Tests - JBoss .............................. SKIPPED
> [INFO] Adapter Tests - Karaf .............................. SKIPPED
> [INFO] Adapter Tests - WAS ................................ SKIPPED
> [INFO] Adapter Tests - WLS ................................ SKIPPED
> [INFO] SSSD tests ......................................... SKIPPED
> [INFO] integration-arquillian-tests-springboot ............ SKIPPED
> [INFO] ------------------------------------------------------------------------
> [INFO] BUILD FAILURE
> [INFO] ------------------------------------------------------------------------
> [INFO] Total time:  01:51 h
> [INFO] Finished at: 2019-04-23T19:51:55+08:00
> [INFO] ------------------------------------------------------------------------
> [ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test (default-test) on project integration-arquillian-tests-base: There are test failures.
> [ERROR]
> [ERROR] Please refer to C:\Users\christopher.smith\Documents\keycloak\workspace\keycloak-parent\testsuite\integration-arquillian\tests\base\target\surefire-reports for the individual test results.
> [ERROR] -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please read the following articles:
> [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
> [ERROR]
> [ERROR] After correcting the problems, you can resume the build with the command
> [ERROR]   mvn <goals> -rf :integration-arquillian-tests-base
>
> C:\Users\christopher.smith\Documents\keycloak\workspace\keycloak-parent>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org<mailto:keycloak-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From abhi.raghav007 at gmail.com  Mon Apr 29 03:43:49 2019
From: abhi.raghav007 at gmail.com (abhishek raghav)
Date: Mon, 29 Apr 2019 13:13:49 +0530
Subject: [keycloak-dev] HA mode with JDBC_PING shows warning in the logs
 after migration to 4.8.3 from 3.4.3
In-Reply-To: <CAA9R9O5jCWQDCj3Ruf9w-kRwS9E_vK1x=dx6aLbeB5-7wESJjQ@mail.gmail.com>
References: <CAJmz6fvZdvj5ted0xtgnrHR4kW0Yay7SUkqO5q_FG6BQ5yxLOw@mail.gmail.com>
	<CAA9R9O5jCWQDCj3Ruf9w-kRwS9E_vK1x=dx6aLbeB5-7wESJjQ@mail.gmail.com>
Message-ID: <CAJmz6fsi1HO=-MS=CuTtAj-8W_Mafw2kjHN2RS1K-r-tpoQTkg@mail.gmail.com>

Thanks Sebastian.

I tried running the same setup with 5.0.0 of keycloak, I did not see any
such errors which I reported in my first email. This was definitely a
Wildfly issue and not keycloak.

Regarding my 2nd question - i.e. support of "clear_table_on_view_change"
property. I see that jgroups has removed support of this property. So lets
say if JGROUPSPING table has lot stale entries, while keycloak starts
booting up - each time keycloak node will try to JOIN with all the entries
already present in the JGROUPSPING table and thus time taken for the
service to start will be more. If that timeline is more than 300s, keycloak
does not start and reports timeout error.
This scenario is highly possible in cloud scenarios, since there the
keycloak nodes can start on any available host/IP since no of nodes are not
fixed.

Can you suggest any workaround to fix this.

*- Best Regards*
   Abhishek Raghav








On Fri, Apr 26, 2019 at 6:11 PM Sebastian Laskawiec <slaskawi at redhat.com>
wrote:

> There was a bunch of fixed to JGroups a while ago, including changes in
> JDBC_PING.
>
> Could you please rerun your setup with Keycloak >= 5.0.0? I believe some
> of the issues (or maybe even all of them) should be fixed.
>
> On Thu, Apr 25, 2019 at 7:19 PM abhishek raghav <abhi.raghav007 at gmail.com>
> wrote:
>
>> Hi
>>
>> After the migration of keycloak HA configurations from 3.4.3.Final to
>> 4.8.3.Final, I am seeing some WARNINGS on one of the nodes of keycloak
>> immediately after the keycloak is started with 2 nodes. This occurs after
>> every time when the cluster is scaled up or whenever infinispan is trying
>> to update the cluster member list.
>> I am using JDBC_PING to achieve clustering in keycloak.
>>
>> Below is the stacktrace -
>>
>> 2019-04-24 12:20:43,687 WARN
>> >> [org.infinispan.topology.ClusterTopologyManagerImpl]
>> >> (transport-thread--p18-t2) [dcidqdcosagent08] KEYCLOAK DEV 1.5.RC
>> >> ISPN000197: Error updating cluster member list:
>> >> org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out
>> >> waiting for responses for request 1 from dcidqdcosagent02
>> >
>> >                   at
>> >>
>> org.infinispan.remoting.transport.impl.MultiTargetRequest.onTimeout(MultiTargetRequest.java:167)
>> >
>> >                   at
>> >>
>> org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:87)
>> >
>> >                   at
>> >>
>> org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:22)
>> >
>> >                   at
>> >> java.util.concurrent.FutureTask.run(FutureTask.java:266)
>> >
>> >                   at
>> >>
>> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
>> >
>> >                   at
>> >>
>> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
>> >
>> >                   at
>> >>
>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>> >
>> >                   at
>> >>
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>> >
>> >                   at java.lang.Thread.run(Thread.java:748)
>> >
>> >                   Suppressed: org.infinispan.util.logging.TraceException
>> >
>> >                                     at
>> >>
>> org.infinispan.remoting.transport.Transport.invokeRemotely(Transport.java:75)
>> >
>> >                                     at
>> >>
>> org.infinispan.topology.ClusterTopologyManagerImpl.confirmMembersAvailable(ClusterTopologyManagerImpl.java:525)
>> >
>> >                                     at
>> >>
>> org.infinispan.topology.ClusterTopologyManagerImpl.updateCacheMembers(ClusterTopologyManagerImpl.java:508)
>> >
>> >
>>
>> Now after I searched, I really did not see anyone reported such error on
>> keycloak but there is similar bug reported in WILDLFY 14 and is
>> categorized
>> as a blocker in WILDLFY 14.This bug is already fixed in WILDLFY 15.
>> https://issues.jboss.org/browse/WFLY-10736?attachmentViewMode=list
>>
>> Now since keycloak 4.8 is also based on WILDLFY 14, these WARNINGS could
>> be
>> because of this blocker in WILDFLY 14.
>>
>> What should I do to get rid this error. Is this really a problem in
>> keycloak 4.8.3.Final. Did anyone notice any such issue while running
>> keycloak 4.8.3 in HA mode.
>> Is there a workaround to fix this.
>>
>>
>> One more thing we noticed is - It is regarding a property in JDBC_PING
>> protocol we are using in our 3.4.3 setup i.e. "clear_table_on_view_change"
>> but it is no more supported in 4.8 version. and thus the JGROUPSPING table
>> is filled up with lot of stale entries. Is there a workaround to clear the
>> table after view change in 4.8 also.
>>
>> Thanks
>> Abhishek
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>

From sthorger at redhat.com  Mon Apr 29 07:08:16 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 29 Apr 2019 13:08:16 +0200
Subject: [keycloak-dev] Request for someone to contribute an WebAuthn4j
	extension
In-Reply-To: <TYAPR01MB2447049C0687F3EFE4AE4244C92F0@TYAPR01MB2447.jpnprd01.prod.outlook.com>
References: <TYAPR01MB2447049C0687F3EFE4AE4244C92F0@TYAPR01MB2447.jpnprd01.prod.outlook.com>
Message-ID: <CAJgngAfL6u=Z9AY5cVftZAvK=bgMa-w2QO24Pf5+yeWv4XEaqQ@mail.gmail.com>

Sorry for late reply. Finally found some time to try this out. It works
pretty well for me, but here's a few discussion points:

* Don't require clicking "Authenticate" button, it's confusing and should
happen automatically
* Use a required action for registration, not an authenticator and custom
registration flow. This fits better with the future plans of application
initiated actions, and also allows users not self-registered.
* Don't use custom table for credentials. I see it's marked as an open
issue, but just wanted to mention it again. Custom entities are not
supported, this has issues with hot-deployment and I don't want to have to
add additional tables for each credential type.
* Problems on re-build/deploy as mentioned in open issues is related to two
things I think. Firstly, the above with regards to custom entities.
Secondly, we have an issue that theme resources are not re-loaded on
re-load (see https://issues.jboss.org/browse/KEYCLOAK-8044).

With regards to testing have you done any research into possibility of
functional testing? I know we've discussed this in the past, but not sure
if any progress has been made here.



On Thu, 11 Apr 2019 at 05:56, ???? / NAKAMURA?YUUICHI <
yuichi.nakamura.fe at hitachi.com> wrote:

> Hi,
>
> We've updated the webauthn authenticator prototype based on webauthn4j :
>
> https://github.com/webauthn4j/keycloak-webauthn-authenticator/tree/demo-completed
>
> We've confirmed that this demo worked well under the following
> environments:
> * U2F with Resident Key Not supported Authenticator Scenario
> OS : Windows 10
> Browser : Google Chrome (ver 73), Mozilla FireFox (ver 66)
> Authenticator : Yubico Security Key
> Server(RP) : keycloak-5.0.0
>
> * U2F with Resident Key supported Authenticator Scenario
> OS : Windows 10
> Browser : Microsoft Edge (ver 44)
> Authenticator : Internal Fingerprint Authentication Device
> Server(RP) : keycloak-5.0.0
>
> * UAF with Resident Key supported Authenticator Scenario
> OS : Windows 10
> Browser : Microsoft Edge (ver 44)
> Authenticator : Internal Fingerprint Authentication Device
> Server(RP) : keycloak-5.0.0
>
> We will continue to improve the prototype, so feedback is welcomed.
>
> Regards,
> Yuichi Nakamura
>
> -----Original Message-----
> From: keycloak-dev-bounces at lists.jboss.org <
> keycloak-dev-bounces at lists.jboss.org> On Behalf Of ???? / NAKAMURA?YUUICHI
> Sent: Tuesday, March 19, 2019 4:32 PM
> To: stian at redhat.com
> Cc: keycloak-dev <keycloak-dev at lists.jboss.org>
> Subject: [!]Re: [keycloak-dev] Request for someone to contribute an
> WebAuthn4j extension
>
> Hi,
>
> Sorry, we have implemented only for Edge now.
> Please wait for other browsers.
>
> > One comment is that it shouldn't create a new table, but rather just
> serialize the value to the existing credential table in the same way as the
> FIDO U2F example does [1].
> Thank you, we will fix.
>
> Regards,
> Yuichi Nakamura
>
>
> From: Stian Thorgersen <sthorger at redhat.com>
> Sent: Monday, March 18, 2019 5:49 PM
> To: ???? / NAKAMURA?YUUICHI <yuichi.nakamura.fe at hitachi.com>
> Cc: keycloak-dev <keycloak-dev at lists.jboss.org>; ???? / NORIMATSU?TAKASHI
> <takashi.norimatsu.ws at hitachi.com>; ???? / MOGI?TAKASHI <
> takashi.mogi.ep at hitachi.com>; Yoshikazu Nojima <mail at ynojima.net>
> Subject: [!]Re: [keycloak-dev] Request for someone to contribute an
> WebAuthn4j extension
>
> Tried this out today and it didn't work for me. I was getting some JS
> error both on Chrome and Firefox when trying to register authenticator.
>
> One comment is that it shouldn't create a new table, but rather just
> serialize the value to the existing credential table in the same way as the
> FIDO U2F example does [1].
>
> [1]
> https://clicktime.symantec.com/3XYorxFfnwRutc8N4z3Ubc77Vc?u=https%3A%2F%2Fgithub.com%2Fstianst%2Fkeycloak-experimental%2Ftree%2Fmaster%2Ffido-u2f
>
> On Fri, 15 Mar 2019 at 08:13, ???? / NAKAMURA?YUUICHI <mailto:
> yuichi.nakamura.fe at hitachi.com> wrote:
> Hi,
>
> We?ve uploaded the initial prototype of webauthn authenticator below:
> https://clicktime.symantec.com/37NWG7BAMWtR42Swt5VUTw77Vc?u=https%3A%2F%2Fgithub.com%2Fwebauthn4j%2Fkeycloak-webauthn-authenticator
>
> Feedback is welcomed.
>
> From: Stian Thorgersen <mailto:sthorger at redhat.com>
> Sent: Thursday, February 28, 2019 6:53 PM
> To: ???? / NAKAMURA?YUUICHI <mailto:yuichi.nakamura.fe at hitachi.com>
> Cc: keycloak-dev <mailto:keycloak-dev at lists.jboss.org>
> Subject: [!]Re: [keycloak-dev] Request for someone to contribute an
> WebAuthn4j extension
>
> That's great, thanks.
>
> Do you have an idea on roughly when you can have a prototype ready?
>
> On Thu, 28 Feb 2019 at 00:32, ???? / NAKAMURA?YUUICHI <mailto:mailto:
> yuichi.nakamura.fe at hitachi.com> wrote:
> Hi,
>
> My team has begun to help webauthn4j project, and is going to develop
> prototype of authenticator for keycloak.
> We'd like to take this.
>
> Regards,
> Yuichi Nakamura
> Hitachi, Ltd.
>
> -----Original Message-----
> From: mailto:mailto:keycloak-dev-bounces at lists.jboss.org <mailto:mailto:
> keycloak-dev-bounces at lists.jboss.org> On Behalf Of Stian Thorgersen
> Sent: Thursday, February 28, 2019 12:26 AM
> To: keycloak-dev <mailto:mailto:keycloak-dev at lists.jboss.org>
> Subject: [!][keycloak-dev] Request for someone to contribute an WebAuthn4j
> extension
>
> A while back I created an experimental extension to Keycloak for FIDO U2F.
> It would be great if someone could adapt this to WebAuthn by leveraging
> webauthn4j library [1].
>
> Any takers? It shouldn't be hard ;)
>
> [1]
> https://clicktime.symantec.com/3DJdi8ZVRTPPRjKw5d1qT287Vc?u=https%3A%2F%2Fgithub.com%2Fwebauthn4j%2Fwebauthn4j
> _______________________________________________
> keycloak-dev mailing list
> mailto:mailto:keycloak-dev at lists.jboss.org
>
> https://clicktime.symantec.com/35NVx3Bd41ZVjjssocqwjpK7Vc?u=https%3A%2F%2Flists.jboss.org%2Fmailman%2Flistinfo%2Fkeycloak-dev
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
>
> https://clicktime.symantec.com/3K7AmDtC5f54UYS4NNrH1wo7Vc?u=https%3A%2F%2Flists.jboss.org%2Fmailman%2Flistinfo%2Fkeycloak-dev
>

From sthorger at redhat.com  Mon Apr 29 07:56:00 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 29 Apr 2019 13:56:00 +0200
Subject: [keycloak-dev] Design proposal - Multi-factor and step-up
	authentication
Message-ID: <CAJgngAeMdpqmgEfptUcYCtQEbonEw0mG8BR0Fn_8Psj6aUyHeA@mail.gmail.com>

Anyone interested in improved multi-factor, WebAuth, step-up, etc. should
take a look at the following design proposal:

https://github.com/keycloak/keycloak-community/pull/5