From dt at acutus.pro  Fri Feb  1 02:52:06 2019
From: dt at acutus.pro (Dmitry Telegin)
Date: Fri, 01 Feb 2019 10:52:06 +0300
Subject: [keycloak-dev] Authz services feedback
In-Reply-To: <CAJrcDBecMn3uhta7T4sBFs19Y25qWOqe+Ge-iH5fhjXGTCsvdg@mail.gmail.com>
References: <eb9f0892-df6f-204a-ea3a-520590cc34b2@redhat.com>
	<CAJrcDBft7awbeby96aJdTOQpVJJaaYTCuxeBF72_3kJHMUVVFQ@mail.gmail.com>
	<1548928788.3759.3.camel@acutus.pro>
	<CAJrcDBdR6MzY6nvp6DBcWsWMYMzkketdxOWOGz9wOiTf3h2kWQ@mail.gmail.com>
	<1548941308.3759.10.camel@acutus.pro>
	<CAJrcDBecMn3uhta7T4sBFs19Y25qWOqe+Ge-iH5fhjXGTCsvdg@mail.gmail.com>
Message-ID: <1549007526.3673.1.camel@acutus.pro>

Hi Pedro,

I can confirm that everything works with global PERMISSIVE + per-path DISABLED + no security constraint. The correct body is returned with 200 OK. I clearly remember I've tried this approach before, but most likely that time I've put double quotes around the path value, and that's why it didn't work.

Thanks a lot!
Dmitry

On Thu, 2019-01-31 at 13:39 -0200, Pedro Igor Silva wrote:
> Now I see the issue. You should be able to DISABLE policy enforcement for a specific path and request sent to this path will return successfully (KEYCLOAK-8142). However, if the path is public (no security constraint) and set with ENFORCING mode, then you get 403?+ body.
> 
> I'll create a JIRA for this and submit a fix.
> 
> > On Thu, Jan 31, 2019 at 11:28 AM Dmitry Telegin <dt at acutus.pro> wrote:
> > Hi, just a quick update,
> > 
> > On Thu, 2019-01-31 at 10:19 -0200, Pedro Igor Silva wrote:
> > > > 1. It may sound crazy, but seems that?with enforcer enabled there is no way to have public endpoints, i.e. those that are not protected by the? adapter security constraints. I've tried every possible combination of global and per-path enforcement-mode, tried creating the corresponding resource in Keycloak, but the enforcer would always deny access. The only scenario that worked was setting global enforcement-mode to DISABLED, which is obviously not an option.?
> > > > I'm not sure if it's Spring Boot specific or not; I'm planning to test the same setup with other adapters too and report the result.
> > > 
> > > AFAIK, we fixed this already. I think in 4.4.0. Could you check?https://issues.jboss.org/browse/KEYCLOAK-8142.
> > 
> > I'm experiencing exactly the same, the correct body is returned together with HTTP 403. Keycloak Spring Boot Adapter is 4.8.3.
> > 
> > Dmitry
> > 
> > 

From dt at acutus.pro  Sat Feb  2 15:46:18 2019
From: dt at acutus.pro (Dmitry Telegin)
Date: Sat, 02 Feb 2019 23:46:18 +0300
Subject: [keycloak-dev] Improve search by a specific user in the admin
 console
In-Reply-To: <c7809c72-348b-b984-f3e9-8c8714e4c31d@redhat.com>
References: <CA+H6wMw6o3rYTbSDfOqOq4QzOy4pdjSOopruWRdYsDKWxs4tbg@mail.gmail.com>
	<c7809c72-348b-b984-f3e9-8c8714e4c31d@redhat.com>
Message-ID: <1549140378.3647.2.camel@acutus.pro>

Hi Stan,

On Thu, 2019-01-31 at 07:46 -0500, Stan Silvert wrote:
> This has always been a sore spot.? I expect that we will address it when?
> we rewrite the admin console, which is in the plan but we don't have a?
> timeline yet.

By the way, have you already picked any particular technology for the rewrite? Will it be Angular 2+ or React, like for account2?

Also my hopes are that the Admin Console becomes truly pluggable/extensible one day. At the moment, if you have two GUI extensions from different authors, you have to hop between the themes, which I myself consider a substantial flaw.

Thanks,
Dmitry

> 
> Another approach for now would be to write a standalone java app that?
> uses the keycloak-admin-client to find the user id.? Then it opens that?
> user in the browser.? This way, you could use it with any keycloak server.
> 
> On 1/31/2019 7:21 AM, Alexis Almeida wrote:
> > Considering an instalation of Keycloak where there are 2mi (or more) of
> > users on user_entity table, search for a specific user on the console is a
> > stressing task if you do it several times a day. I think it should be
> > possible to do "direct" search by username.
> > 
> > Today it is possible to search for a specific user by ID, by typing
> > id:xxxxxx in the search field in the console. IMO this feature could be
> > expanded, so someone could search for a specific user by username or by
> > email, like this: username:xxxxx or email:xxxxxx.
> > 
> > I made this change on my local machine and the result was ok.
> > 
> > private static final String SEARCH_USERNAME_PARAMETER = "username:";
> > private static final String SEARCH_EMAIL_PARAMETER = "email:";
> > .
> > .
> > .
> > } else if (search.startsWith(SEARCH_USERNAME_PARAMETER)) {
> > ?????UserModel userModel =
> > session.users().getUserByUsername(search.substring(SEARCH_USERNAME_PARAMETER.length()).trim(),
> > realm);
> > ?????if (userModel != null) {
> > ?????????userModels = Arrays.asList(userModel);
> > ?????}
> > } else if (search.startsWith(SEARCH_EMAIL_PARAMETER)) {
> > ?????UserModel userModel =
> > session.users().getUserByEmail(search.substring(SEARCH_EMAIL_PARAMETER.length()).trim(),
> > realm);
> > ?????if (userModel != null) {
> > ????????userModels = Arrays.asList(userModel);
> > ?????}
> > } else {
> > _______________________________________________
> > 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 alexis.almeida at gmail.com  Sun Feb  3 11:34:38 2019
From: alexis.almeida at gmail.com (Alexis Almeida)
Date: Sun, 3 Feb 2019 14:34:38 -0200
Subject: [keycloak-dev] Improve search for a specific user in the admin
	console
In-Reply-To: <mailman.169532.1548940500.4500.keycloak-dev@lists.jboss.org>
References: <mailman.169532.1548940500.4500.keycloak-dev@lists.jboss.org>
Message-ID: <CA+H6wMzc+FqJLtaHp=xvtjn8J1-ON0FLm2zsMMHUfp5Lc5vozA@mail.gmail.com>

Hi, Stan!

> Another approach for now would be to write a standalone java app that
> uses the keycloak-admin-client to find the user id.? Then it opens that
> user in the browser.? This way, you could use it with any keycloak server.

Thanks for your answer and your sugestion. I just think it is not
interesting to use two tools to operate the solution: the console itself
and another application just to get the user id.

Anyway, your suggestion gave me another idea and I got a workaround for the
problem by just changing the Admin Theme. I implemented the same filter
idea in the "admin/resources/js/controllers/users.js" file. It really is a
workaround but it makes me comfortable to wait for the new version of the
console.

Thanks

Al?xis

Date: Thu, 31 Jan 2019 07:46:43 -0500
> From: Stan Silvert <ssilvert at redhat.com>
> Subject: Re: [keycloak-dev] Improve search by a specific user in the
>         admin console
> To: keycloak-dev at lists.jboss.org
> Message-ID: <c7809c72-348b-b984-f3e9-8c8714e4c31d at redhat.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> This has always been a sore spot.? I expect that we will address it when
> we rewrite the admin console, which is in the plan but we don't have a
> timeline yet.
>
> Another approach for now would be to write a standalone java app that
> uses the keycloak-admin-client to find the user id.? Then it opens that
> user in the browser.? This way, you could use it with any keycloak server.
>
> On 1/31/2019 7:21 AM, Alexis Almeida wrote:
> > Considering an instalation of Keycloak where there are 2mi (or more) of
> > users on user_entity table, search for a specific user on the console is
> a
> > stressing task if you do it several times a day. I think it should be
> > possible to do "direct" search by username.
> >
> > Today it is possible to search for a specific user by ID, by typing
> > id:xxxxxx in the search field in the console. IMO this feature could be
> > expanded, so someone could search for a specific user by username or by
> > email, like this: username:xxxxx or email:xxxxxx.
> >
> > I made this change on my local machine and the result was ok.
> >
> > private static final String SEARCH_USERNAME_PARAMETER = "username:";
> > private static final String SEARCH_EMAIL_PARAMETER = "email:";
> > .
> > .
> > .
> > } else if (search.startsWith(SEARCH_USERNAME_PARAMETER)) {
> >      UserModel userModel =
> >
> session.users().getUserByUsername(search.substring(SEARCH_USERNAME_PARAMETER.length()).trim(),
> > realm);
> >      if (userModel != null) {
> >          userModels = Arrays.asList(userModel);
> >      }
> > } else if (search.startsWith(SEARCH_EMAIL_PARAMETER)) {
> >      UserModel userModel =
> >
> session.users().getUserByEmail(search.substring(SEARCH_EMAIL_PARAMETER.length()).trim(),
> > realm);
> >      if (userModel != null) {
> >         userModels = Arrays.asList(userModel);
> >      }
> > } else {
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
>
>

From pa at pauloangelo.com  Sun Feb  3 12:17:39 2019
From: pa at pauloangelo.com (Paulo Angelo)
Date: Sun, 3 Feb 2019 15:17:39 -0200
Subject: [keycloak-dev] Integration with GuardianKey
Message-ID: <CAFjP4XTv=yupw4jZAf275q37JNJZj5jh9tr+BTH0A+0EeNSQMw@mail.gmail.com>

Hi all,

We are trying to integrate KeyCloak with GuardianKey. However, we have
doubts related to the best way to do this and the best point in the
KeyCloak?s code for this integration.

GuardianKey is a service to protect systems against authentication attacks.
It uses Machine Learning and analyses the user's behavior, threat
intelligence and psychometrics (or behavioral biometrics). The protected
system (in the concrete case, KeyCloak) must send an event via REST for the
GuardianKey on each login attempt. More info at https://guardiankey.io .

The best way to integrate would be on having a hook in the procedure that
process the user credentials submission in KeyCloak (the script that
receives the POST), something such as:

if(<POST IN AUTH FORM>) {

 boolean loginFailed =  checkLoginInKeyCloak();

 GuardianKeyEvent event = createEventForGuardianKey(username,loginFailed);

 boolean GuardianKeyValidation = checkGuardianKeyViaREST(event);

 if(GuardianKeyValidation){

    // Allow access

 } else {

    // Deny access

 }

}

Where is the best place to create this integration? Is there a way to
create a hook for this purpose? Should we create an extension?

Any help is welcome.

Thank you in advance.

Best regards,

Paulo Angelo

From alexis.almeida at gmail.com  Sun Feb  3 14:46:55 2019
From: alexis.almeida at gmail.com (Alexis Almeida)
Date: Sun, 3 Feb 2019 17:46:55 -0200
Subject: [keycloak-dev] Integration with GuardianKey
In-Reply-To: <CAFjP4XTv=yupw4jZAf275q37JNJZj5jh9tr+BTH0A+0EeNSQMw@mail.gmail.com>
References: <CAFjP4XTv=yupw4jZAf275q37JNJZj5jh9tr+BTH0A+0EeNSQMw@mail.gmail.com>
Message-ID: <CA+H6wMzRFPSf2mkqa4vizP1SaSn6pbbqsFoP+YtwOF4aDvKboA@mail.gmail.com>

Hi Paulo,

IMO the simplest way to do this is with an Authenticator Provider. Please
see here:

https://www.keycloak.org/docs/latest/server_development/index.html#implementing-an-authenticator
.

In the authenticate method you can call the GuardianKey and, depending on
the result, you call a context.success () or context.failure ().

Like this:

public void authenticate(AuthenticationFlowContext context) {
...
if(!GuardianKeyValidation){
   Response challenge = context.form()
                .setError("something")
                .createForm("error_page.ftl");

 context.failureChallenge(AuthenticationFlowError.INVALID_CREDENTIALS,
challenge);
   return;
}
...
context.success();
}

Al?xis


Em dom, 3 de fev de 2019 ?s 15:38, Paulo Angelo <pa at pauloangelo.com>
escreveu:

> Hi all,
>
> We are trying to integrate KeyCloak with GuardianKey. However, we have
> doubts related to the best way to do this and the best point in the
> KeyCloak?s code for this integration.
>
> GuardianKey is a service to protect systems against authentication attacks.
> It uses Machine Learning and analyses the user's behavior, threat
> intelligence and psychometrics (or behavioral biometrics). The protected
> system (in the concrete case, KeyCloak) must send an event via REST for the
> GuardianKey on each login attempt. More info at https://guardiankey.io .
>
> The best way to integrate would be on having a hook in the procedure that
> process the user credentials submission in KeyCloak (the script that
> receives the POST), something such as:
>
> if(<POST IN AUTH FORM>) {
>
>  boolean loginFailed =  checkLoginInKeyCloak();
>
>  GuardianKeyEvent event = createEventForGuardianKey(username,loginFailed);
>
>  boolean GuardianKeyValidation = checkGuardianKeyViaREST(event);
>
>  if(GuardianKeyValidation){
>
>     // Allow access
>
>  } else {
>
>     // Deny access
>
>  }
>
> }
>
> Where is the best place to create this integration? Is there a way to
> create a hook for this purpose? Should we create an extension?
>
> Any help is welcome.
>
> Thank you in advance.
>
> Best regards,
>
> Paulo Angelo
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From dt at acutus.pro  Sun Feb  3 16:21:06 2019
From: dt at acutus.pro (Dmitry Telegin)
Date: Mon, 04 Feb 2019 00:21:06 +0300
Subject: [keycloak-dev] Integration with GuardianKey
In-Reply-To: <CA+H6wMzRFPSf2mkqa4vizP1SaSn6pbbqsFoP+YtwOF4aDvKboA@mail.gmail.com>
References: <CAFjP4XTv=yupw4jZAf275q37JNJZj5jh9tr+BTH0A+0EeNSQMw@mail.gmail.com>
	<CA+H6wMzRFPSf2mkqa4vizP1SaSn6pbbqsFoP+YtwOF4aDvKboA@mail.gmail.com>
Message-ID: <1549228866.7030.6.camel@acutus.pro>

Hello Paulo,

To add to Alexis's reply, you can use Script authenticator [1]. It's especially good for prototyping since you don't have to create and deploy the whole provider module.

Also, you'll need an HttpClient instance to be able to perform external HTTP requests, see [2] for that.

[1] https://www.keycloak.org/docs/latest/server_admin/#executions
[2] http://lists.jboss.org/pipermail/keycloak-user/2018-November/016456.html

Good luck,
Dmitry Telegin
CTO, Acutus s.r.o.
Keycloak Consulting and Training

Pod lipami street 339/52, 130 00 Prague 3, Czech Republic
+42 (022) 888-30-71
E-mail: info at acutus.pro

On Sun, 2019-02-03 at 17:46 -0200, Alexis Almeida wrote:
> Hi Paulo,
> 
> IMO the simplest way to do this is with an Authenticator Provider. Please
> see here:
> 
> https://www.keycloak.org/docs/latest/server_development/index.html#implementing-an-authenticator
> .
> 
> In the authenticate method you can call the GuardianKey and, depending on
> the result, you call a context.success () or context.failure ().
> 
> Like this:
> 
> public void authenticate(AuthenticationFlowContext context) {
> ...
> if(!GuardianKeyValidation){
> ???Response challenge = context.form()
> ????????????????.setError("something")
> ????????????????.createForm("error_page.ftl");
> 
> ?context.failureChallenge(AuthenticationFlowError.INVALID_CREDENTIALS,
> challenge);
> ???return;
> }
> ...
> context.success();
> }
> 
> Al?xis
> 
> 
> > Em dom, 3 de fev de 2019 ?s 15:38, Paulo Angelo <pa at pauloangelo.com>
> escreveu:
> 
> > Hi all,
> > 
> > We are trying to integrate KeyCloak with GuardianKey. However, we have
> > doubts related to the best way to do this and the best point in the
> > KeyCloak?s code for this integration.
> > 
> > GuardianKey is a service to protect systems against authentication attacks.
> > It uses Machine Learning and analyses the user's behavior, threat
> > intelligence and psychometrics (or behavioral biometrics). The protected
> > system (in the concrete case, KeyCloak) must send an event via REST for the
> > GuardianKey on each login attempt. More info at https://guardiankey.io .
> > 
> > The best way to integrate would be on having a hook in the procedure that
> > process the user credentials submission in KeyCloak (the script that
> > receives the POST), something such as:
> > 
> > if(<POST IN AUTH FORM>) {
> > 
> > ?boolean loginFailed =??checkLoginInKeyCloak();
> > 
> > ?GuardianKeyEvent event = createEventForGuardianKey(username,loginFailed);
> > 
> > ?boolean GuardianKeyValidation = checkGuardianKeyViaREST(event);
> > 
> > ?if(GuardianKeyValidation){
> > 
> > ????// Allow access
> > 
> > ?} else {
> > 
> > ????// Deny access
> > 
> > ?}
> > 
> > }
> > 
> > Where is the best place to create this integration? Is there a way to
> > create a hook for this purpose? Should we create an extension?
> > 
> > Any help is welcome.
> > 
> > Thank you in advance.
> > 
> > Best regards,
> > 
> > Paulo Angelo
> > _______________________________________________
> > 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 pa at pauloangelo.com  Sun Feb  3 19:21:46 2019
From: pa at pauloangelo.com (Paulo Angelo)
Date: Sun, 3 Feb 2019 22:21:46 -0200
Subject: [keycloak-dev] Integration with GuardianKey
In-Reply-To: <1549228866.7030.6.camel@acutus.pro>
References: <CAFjP4XTv=yupw4jZAf275q37JNJZj5jh9tr+BTH0A+0EeNSQMw@mail.gmail.com>
	<CA+H6wMzRFPSf2mkqa4vizP1SaSn6pbbqsFoP+YtwOF4aDvKboA@mail.gmail.com>
	<1549228866.7030.6.camel@acutus.pro>
Message-ID: <CAFjP4XQvSgNr2fB9oqDBrq2PJ5fuN=_CLEgU6E7Vo9KKRg_b2Q@mail.gmail.com>

Dmitry and Al?xis,

Thank you very much for the directions. We are going to work on it.

regards,

Paulo Angelo

On Sun, Feb 3, 2019 at 8:06 PM Dmitry Telegin <dt at acutus.pro> wrote:

> Hello Paulo,
>
> To add to Alexis's reply, you can use Script authenticator [1]. It's
> especially good for prototyping since you don't have to create and deploy
> the whole provider module.
>
> Also, you'll need an HttpClient instance to be able to perform external
> HTTP requests, see [2] for that.
>
> [1] https://www.keycloak.org/docs/latest/server_admin/#executions
> [2]
> http://lists.jboss.org/pipermail/keycloak-user/2018-November/016456.html
>
> Good luck,
> Dmitry Telegin
> CTO, Acutus s.r.o.
> Keycloak Consulting and Training
>
> Pod lipami street 339/52, 130 00 Prague 3, Czech Republic
> +42 (022) 888-30-71
> E-mail: info at acutus.pro
>
> On Sun, 2019-02-03 at 17:46 -0200, Alexis Almeida wrote:
> > Hi Paulo,
> >
> > IMO the simplest way to do this is with an Authenticator Provider. Please
> > see here:
> >
> >
> https://www.keycloak.org/docs/latest/server_development/index.html#implementing-an-authenticator
> > .
> >
> > In the authenticate method you can call the GuardianKey and, depending on
> > the result, you call a context.success () or context.failure ().
> >
> > Like this:
> >
> > public void authenticate(AuthenticationFlowContext context) {
> > ...
> > if(!GuardianKeyValidation){
> >    Response challenge = context.form()
> >                 .setError("something")
> >                 .createForm("error_page.ftl");
> >
> >  context.failureChallenge(AuthenticationFlowError.INVALID_CREDENTIALS,
> > challenge);
> >    return;
> > }
> > ...
> > context.success();
> > }
> >
> > Al?xis
> >
> >
> > > Em dom, 3 de fev de 2019 ?s 15:38, Paulo Angelo <pa at pauloangelo.com>
> > escreveu:
> >
> > > Hi all,
> > >
> > > We are trying to integrate KeyCloak with GuardianKey. However, we have
> > > doubts related to the best way to do this and the best point in the
> > > KeyCloak?s code for this integration.
> > >
> > > GuardianKey is a service to protect systems against authentication
> attacks.
> > > It uses Machine Learning and analyses the user's behavior, threat
> > > intelligence and psychometrics (or behavioral biometrics). The
> protected
> > > system (in the concrete case, KeyCloak) must send an event via REST
> for the
> > > GuardianKey on each login attempt. More info at https://guardiankey.io
> .
> > >
> > > The best way to integrate would be on having a hook in the procedure
> that
> > > process the user credentials submission in KeyCloak (the script that
> > > receives the POST), something such as:
> > >
> > > if(<POST IN AUTH FORM>) {
> > >
> > >  boolean loginFailed =  checkLoginInKeyCloak();
> > >
> > >  GuardianKeyEvent event =
> createEventForGuardianKey(username,loginFailed);
> > >
> > >  boolean GuardianKeyValidation = checkGuardianKeyViaREST(event);
> > >
> > >  if(GuardianKeyValidation){
> > >
> > >     // Allow access
> > >
> > >  } else {
> > >
> > >     // Deny access
> > >
> > >  }
> > >
> > > }
> > >
> > > Where is the best place to create this integration? Is there a way to
> > > create a hook for this purpose? Should we create an extension?
> > >
> > > Any help is welcome.
> > >
> > > Thank you in advance.
> > >
> > > Best regards,
> > >
> > > Paulo Angelo
> > > _______________________________________________
> > > keycloak-dev mailing list
> > > keycloak-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



-- 

Att,

Paulo Angelo

From james.p.campbell at gmail.com  Sun Feb  3 23:14:34 2019
From: james.p.campbell at gmail.com (James Campbell)
Date: Sun, 3 Feb 2019 23:14:34 -0500
Subject: [keycloak-dev] OIDC Discovery-enabled IdentityProvider
In-Reply-To: <CA+AQu3yuSeN+pOFRwuDR-2CdNvNVPjoHv=xEmTNS5pHHv1qR8Q@mail.gmail.com>
References: <00aa01d4ac7b$a7767460$f6635d20$@gmail.com>
	<1914838141.50603473.1547562353763.JavaMail.zimbra@redhat.com>
	<38415268.50625497.1547566301029.JavaMail.zimbra@redhat.com>
	<CA+AQu3yKjkTU2XCaiE1-xbfyn3idiswk5OWSsLxNnZRKsMFJWA@mail.gmail.com>
	<CAJgngAccFbcFOE4Dt4v=R-WXky9mdmGPZqzDvwi3AthrBLOjvQ@mail.gmail.com>
	<CA+AQu3waQr+Zdm1kA_PwoghNfcDzzhttc56saxTEhhxRXwy7Eg@mail.gmail.com>
	<CAJgngAeJn1jSQRk-7yZzaYfDTYE_Ww5pE9MgyumPCkSfYa4tQw@mail.gmail.com>
	<CA+AQu3yuSeN+pOFRwuDR-2CdNvNVPjoHv=xEmTNS5pHHv1qR8Q@mail.gmail.com>
Message-ID: <CA+AQu3z4JTTSCQU0g9m5VV5SFYUk92-sA1hqT-AedPZRotmcCw@mail.gmail.com>

All--

Thanks to Stian's recommendations for similar features in the codebase,
I've developed a proposal for how to implement this feature, and sketched
out an initial implementation. As he suggested, I'd like to get feedback
before opening up a PR.

1. We introduce a new subclass of the OIDCIdentityProvider / Factory called
OIDCDiscoveryIdentityProvider. The new class adds a discoverConfig method
that can be used to discover and set all relevant endpoints in a
configuration except the issuer. Issuer then becomes the sole required
element of the config. (So the GoogleIdentityProvider, for example, will
then just call discoverConfig with its hard-coded issuer).
   -> During the parseConfig call, the Factory will raise a
RuntimeException if the config cannot be obtained, since if the config can
never be obtained there is no way to have a valid configuration at all.
   -> During the discoverConfig call, we return the cached value, and
optionally refresh it based on when we last obtained the configuration.
   -> In the event of a failure in the *refresh* I'm imagining the best
behavior is to log a warning but then return the cached config (last known
good config).

2. We introduce an SPI and interface called
OIDCDiscoveryRepresentationProvider / Factory and implementations called
Infinispan... which obtains OIDCConfigurationRepresentations using the
/.well-known/openid-configuration endpoint on the issuer.

I have a couple questions:

1. I began an implementation of this, but the @JsonProperty annotations on
the existing OIDCCOnfigurationRepresentation class seem to be ignored when
I try to have it read from the openid-configuration docuement, e.g.:
  - OIDCConfigurationRepresentation rep = SimpleHttp.doGet(issuer +
"/.well-known/openid-configuration",
session).asJson(OIDCConfigurationRepresentation.class); // FAILS with
"Unrecognized field ..." Perhaps a mismatch of the jackson annotation
version in the keycloak-model-infinispan submodule?

2. Assuming the design above makes sense, what is the right way to plug
this into the testing framework? Is one of the core developers interested
in tackling that aspect if I push a PR with the above features implemented?

James

On Sun, Jan 27, 2019 at 11:15 AM James Campbell <james.p.campbell at gmail.com>
wrote:

> Got it; I checked that code out and it does look like a pretty direct
> model for the refreshing feature. I'll begin working on a PR.
>
> On Mon, Jan 21, 2019 at 3:25 AM Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> JWKs used by identity brokering and client authentication.
>>
>> On Sat, 19 Jan 2019 at 23:29, James Campbell <james.p.campbell at gmail.com>
>> wrote:
>>
>>> Stian--
>>>
>>> Thanks for confirming. Which keys are you referring to--I'll take a look
>>> at that in the code and try to follow that pattern closely.
>>>
>>> James
>>>
>>> On Wed, Jan 16, 2019 at 1:52 AM Stian Thorgersen <sthorger at redhat.com>
>>> wrote:
>>>
>>>> It would be good to get these changes included. We do something similar
>>>> for the keys today and they are cached in an Infinispan local cache. Could
>>>> do something similar for the OIDC discovery/config.
>>>>
>>>> On Tue, 15 Jan 2019 at 17:44, James Campbell <
>>>> james.p.campbell at gmail.com> wrote:
>>>>
>>>>> Tomas--
>>>>>
>>>>> Thanks--it certainly seems close, you're right! It looks, however like
>>>>> an
>>>>> OIDC provider still uses a static configuration even though it loads it
>>>>> from the discovery URL--that is, once it's loaded at configuraiton
>>>>> time, it
>>>>> doesn't discover new changes, and there isn't an option to
>>>>> refresh/store
>>>>> that discovery endpoint outside of configuration.
>>>>>
>>>>> It's not clear to me how important that feature is--on one hand, it
>>>>> seems
>>>>> unlikely that we should expect frequent changes; on the other, in the
>>>>> short
>>>>> time since I started exploring this setup, I have encountered three
>>>>> changes
>>>>> in google's OIDC endpoints between what was hard-coded into keycloak,
>>>>> what
>>>>> is in their documentation, and what their current discovery endpoint
>>>>> provides. (And, the google docs specifically suggest refreshing from
>>>>> the
>>>>> endpoint periodically).
>>>>>
>>>>> Thoughts?
>>>>>
>>>>> James
>>>>>
>>>>>
>>>>> On Tue, Jan 15, 2019 at 10:31 AM Tomas Kyjovsky <tkyjovsk at redhat.com>
>>>>> wrote:
>>>>>
>>>>> > Please disregard my previous message.
>>>>> >
>>>>> > Looking at the docs [1] and the Admin Console UI this should be
>>>>> already
>>>>> > possible with the OIDC identity provider.
>>>>> > When creating a OIDC identity provider in the Admin Console there is
>>>>> an
>>>>> > option at the bottom of the page to import OIDC configuration
>>>>> metadata from
>>>>> > URL.
>>>>> >
>>>>> > Does this cover your use case?
>>>>> >
>>>>> >
>>>>> > Regards,
>>>>> > Tomas
>>>>> >
>>>>> > [1]
>>>>> >
>>>>> https://www.keycloak.org/docs/latest/server_admin/index.html#openid-connect-v1-0-identity-providers
>>>>> >
>>>>> >
>>>>> > ----- Original Message -----
>>>>> > > Hello James,
>>>>> > >
>>>>> > > See my 2 cents inline..
>>>>> > >
>>>>> > > ----- Original Message -----
>>>>> > > > All--
>>>>> > > >
>>>>> > > >
>>>>> > > >
>>>>> > > > After observing that the Google Social Identity Provider in
>>>>> Keycloak
>>>>> > was
>>>>> > > > using a deprecated userprofile endpoint [
>>>>> > > > <https://issues.jboss.org/projects/KEYCLOAK/issues/KEYCLOAK-9179
>>>>> >
>>>>> > > > Keycloak-9179,  <https://issues.jboss.org/browse/KEYCLOAK-9169>
>>>>> > > > Keycloak-9169], I wanted to propose the creation of an
>>>>> IdentityProvider
>>>>> > > > that
>>>>> > > > will use the OIDC Discovery mechanism to dynamically build a
>>>>> config [
>>>>> > > > <https://issues.jboss.org/browse/KEYCLOAK-9194> Keycloak-9194].
>>>>> > > >
>>>>> > > >
>>>>> > > >
>>>>> > > > I see a few decision points along the way that I wanted to ask
>>>>> about
>>>>> > before
>>>>> > > > an implementation, since I'm very new to keycloak and just
>>>>> starting to
>>>>> > > > understand the codebase. In particular, I wondered if this group
>>>>> could
>>>>> > > > share
>>>>> > > > insight into these couple issues so I can make a more informed
>>>>> design:
>>>>> > > >
>>>>> > > >
>>>>> > > >
>>>>> > > > 1.    It looks to me like the actual IdentityProviders are
>>>>> instantiated
>>>>> > > > just
>>>>> > > > as they're being used, but that the models are persisted in the
>>>>> > RealmModel.
>>>>> > > > It's not clear to me where the separation of concerns is
>>>>> supposed to be
>>>>> > > > between the IdentityProvider and the IdentityProviderModel-in
>>>>> > particular
>>>>> > > > since the GoogeIdentityProvider, say, immediately sets endpoints
>>>>> in its
>>>>> > > > constructor. Normatively, where *should* social identity
>>>>> providers'
>>>>> > model
>>>>> > > > configuration be set (and, e.g., where are the models first
>>>>> added to
>>>>> > the
>>>>> > > > RealmModel)?
>>>>> > >
>>>>> > > Provider classes are being instantiated per transaction by their
>>>>> > > corresponding ProviderFactories and then left to be
>>>>> garbage-collected
>>>>> > after
>>>>> > > Provider.close() is called.
>>>>> > > The Provider class is given its configuration
>>>>> (IdentityProviderModel in
>>>>> > this
>>>>> > > case) by its factory which I believe loads it from cache/jpa
>>>>> layer. Any
>>>>> > > class extending AbstractIdentityProvider should then be able to
>>>>> access
>>>>> > its
>>>>> > > config via getConfig() method but I don't think it will be able to
>>>>> > > update/persist it back. The provider configuration/model itself is
>>>>> > managed
>>>>> > > by the IdentityProviderResource (REST endpoint accessible via REST
>>>>> or
>>>>> > admin
>>>>> > > console UI) in the keycloak/services module so I think the
>>>>> > > auto-configuration logic would have to be placed somewhere there.
>>>>> > >
>>>>> > > >
>>>>> > > >
>>>>> > > >
>>>>> > > > 2.    I see that there is logic to parse OIDC Discovery
>>>>> configuration
>>>>> > as
>>>>> > > > part of configuring Keycloak itself as an OIDC provider /
>>>>> implementer
>>>>> > of
>>>>> > > > OIDC protocol (including building and parsing the .well-known
>>>>> config
>>>>> > > > elements), but that logic seems not to be used in any setting
>>>>> > currently as
>>>>> > > > a
>>>>> > > > client. Should I plan to reuse, say, the
>>>>> > OIDCConfigurationRepresentation
>>>>> > > > and
>>>>> > > > OIDCWellKnownProvider classes for their logic in handling such
>>>>> configs?
>>>>> > > >
>>>>> > > >
>>>>> > > >
>>>>> > > >
>>>>> > > >
>>>>> > > > Currently, I'm imagining something along the lines of extending
>>>>> > > > OIDCIdentityProvider with a new OIDCDiscoveryIdentityProvider
>>>>> that
>>>>> > adds a
>>>>> > > > discoverConfig method which can be used by an implementing class
>>>>> (such
>>>>> > as
>>>>> > > > GoogleIdentityProvider) to discover and cache endpoints such
>>>>> that they
>>>>> > are
>>>>> > > > not hard-coded into the implementing class. Each implementing
>>>>> class
>>>>> > would
>>>>> > > > then have a public static final DISCOVERY_URL that it passes to
>>>>> > > > discoverConfig.
>>>>> > > >
>>>>> > > >
>>>>> > > >
>>>>> > > > My main hangup, as suggested above, is that to implement the
>>>>> caching, I
>>>>> > > > want
>>>>> > > > to ensure that the model configuration is stored/set in the right
>>>>> > place.
>>>>> > > >
>>>>> > > >
>>>>> > > >
>>>>> > > > Thanks for bearing with me as I come up to speed on this!
>>>>> > > >
>>>>> > > >
>>>>> > > >
>>>>> > > > James
>>>>> > > >
>>>>> > > > _______________________________________________
>>>>> > > > keycloak-dev mailing list
>>>>> > > > keycloak-dev at lists.jboss.org
>>>>> > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>> > > >
>>>>> > >
>>>>> > >
>>>>> > > Regards,
>>>>> > > Tomas
>>>>> > >
>>>>> >
>>>>>
>>>>>
>>>>> --
>>>>> -... . / - .-. ..- . .-.-.- / -... . / .--. .-. . ... . -. - .-.-.- /
>>>>> -...
>>>>> . / ..-. .. -
>>>>> 07:d0:2d:0b:d6:9d:27:c6:a7:c1:ec:e3:b1:65:f4:70
>>>>> _______________________________________________
>>>>> keycloak-dev mailing list
>>>>> keycloak-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>
>>>>
>>>
>>> --
>>> -... . / - .-. ..- . .-.-.- / -... . / .--. .-. . ... . -. - .-.-.- /
>>> -... . / ..-. .. -
>>> 07:d0:2d:0b:d6:9d:27:c6:a7:c1:ec:e3:b1:65:f4:70
>>>
>>
>
> --
> -... . / - .-. ..- . .-.-.- / -... . / .--. .-. . ... . -. - .-.-.- / -...
> . / ..-. .. -
> 07:d0:2d:0b:d6:9d:27:c6:a7:c1:ec:e3:b1:65:f4:70
>


-- 
-... . / - .-. ..- . .-.-.- / -... . / .--. .-. . ... . -. - .-.-.- / -...
. / ..-. .. -
07:d0:2d:0b:d6:9d:27:c6:a7:c1:ec:e3:b1:65:f4:70

From Patrice.Amiel at gemalto.com  Mon Feb  4 03:49:25 2019
From: Patrice.Amiel at gemalto.com (AMIEL Patrice)
Date: Mon, 4 Feb 2019 08:49:25 +0000
Subject: [keycloak-dev] Defining several Password Policies within a Realm
In-Reply-To: <CAJgngAd-zWz+sgwCe7QW2DGNtnYCFMRVGC5xYwzjsgdPi82qhQ@mail.gmail.com>
References: <PR1PR01MB4939AE7E0BE3C820C1360755F68A0@PR1PR01MB4939.eurprd01.prod.exchangelabs.com>
	<CAJgngAftS+U3kn1yr89LwaQK6BqoAydLGKY=LYTtO3Eja9q7DQ@mail.gmail.com>
	<PR1PR01MB49396153A2F07E00B26E0A44F6820@PR1PR01MB4939.eurprd01.prod.exchangelabs.com>
	<CAJgngAe8nb-6iib40q1LuOVk_kJcCnCHdqGRQi_u1h0C+ezp0g@mail.gmail.com>
	<1547849203.13934.6.camel@acutus.pro>
	<CAJgngAd-zWz+sgwCe7QW2DGNtnYCFMRVGC5xYwzjsgdPi82qhQ@mail.gmail.com>
Message-ID: <PR1PR01MB493916F2D4E8E0A457600262F66D0@PR1PR01MB4939.eurprd01.prod.exchangelabs.com>

Hi,

I?ve been reading the SPI documentation during the past days, but to be honest, I?m not 100% comfortable with your proposal. Can you please clarify what you have in mind for this?
Indeed, I don?t really see who would create the SPI interface (and why an ?appliesTo? function?), who would implement it, and who would call it (and when)! (you see how foggy it is for the moment in my mind :P )

Thanks for your help !

Best regards,
Patrice

From: Stian Thorgersen [mailto:sthorger at redhat.com]
Sent: lundi 21 janvier 2019 09:21
To: Dmitry Telegin <dt at acutus.pro>
Cc: AMIEL Patrice <Patrice.Amiel at gemalto.com>; keycloak-dev at lists.jboss.org
Subject: Re: [keycloak-dev] Defining several Password Policies within a Realm

Not sure I fully understand, but sounds a bit overkill.

Here's a simple way do to it:

Introduce a Password Policy Condition SPI that leverages component model. The provider can have a simple method:

* boolean appliesTo(UserModel user)

That allows creating implementations of it that can be dynamically configured. So pretty simple to implement a group, role, etc. condition. Most of the screens is in the admin console today as component model provides this. We already have role selects and I think there is a group selector as well.

On Fri, 18 Jan 2019 at 23:06, Dmitry Telegin <dt at acutus.pro<mailto:dt at acutus.pro>> wrote:
Just my 2?, this looks very similar to authorization policies that we
already have - the same user/group/role/time/rules/JS stuff; maybe
time-based *password* policies don't make much sense, but everything
else does. The only difference is that authorization policies do simple
grant/deny, and here the result should be a list of password policies
to activate. Maybe we can reuse portions of existing authz code and/or
GUI for that.

Cheers,
Dmitry

On Fri, 2019-01-18 at 09:09 +0100, Stian Thorgersen wrote:
> Implementation wise it will be more flexible to have multiple password
> policies defined in a realm and have some logic defined on how to select
> the correct password policy for a user. It sounds like are proposing to
> have a password policy associated directly with a group, but I believe this
> is a more complex, less flexible and harder to manage approach.
>
> I can imagine the following use-cases to select password policy for a
> specific user:
>
> * Based on a group the user belongs to
> * Based on a role the user has
> * Based on which user federation provider the user comes from
> * Based on identity provider links
>
> If a password policy is something that has:
>
> * The string representation of the policy (as we have today)
> * A priority
> * A condition that matches it against users
>
> Note: There also needs to be a way to define the default policy for the
> realm
>
> That means we can support all mentioned use-cases above. I'm happy to
> accept a contribution that only has supports to match on groups, but it has
> to be implemented in a way where additional matching can easily be added,
> so there should be an SPI to allow adding matchers.
>
> On Wed, 16 Jan 2019 at 17:00, AMIEL Patrice <Patrice.Amiel at gemalto.com<mailto:Patrice.Amiel at gemalto.com>>
> wrote:
>
> > Hi Stian,
> >
> >
> >
> > Thanks for your reply. I?m glad to see that you would welcome a PR on the
> > topic !
> >
> >
> >
> > To be sure that my understanding of your proposal is correct, let me
> > rephrase what it could be:
> >
> > -          Several ?Password policies groups? might be defined within a
> > single ?Realm?, each of them having their own set of ?Password Policies?
> > with their own configuration values. In addition to that, you propose to
> > add another information to each of the ?Password policies groups?: a
> > priority.
> >
> > -          Contrary to my proposal, application of a ?Password policy
> > group? would not be on a per-User basis. Instead, a ?Password policy group?
> > would be applied to the ?Groups?, meaning that a ?Group? would now be able
> > to gather Attributes, Roles and (new !) Password Policies for all the
> > members of the ?Group?.
> >
> > -          Then, when a ?User? needs to login or to change its password
> > (i.e. to access to its password policies), then KeyCloak would get the list
> > of ?Groups? the user is member of, and then select the Group?s ?Password
> > policies group? that has the highest priority: this is the one to be
> > applied for password policy.
> >
> >
> >
> > Is my understanding correct?
> >
> >
> >
> > I also understand that not everyone is using Groups, but if so, I don?t
> > understand what you mean by ?it may be useful to also add support for a
> > role?. Do you want also to be able to attach a ?Password policies group?
> > to individual roles, and thus apply the same election of the ?policy to be
> > used? thanks to the priority, taking into account not only the ?Password
> > policies groups? attached to the ?Groups? the ?User? is member of, but also
> > the ?Password policies groups? attached to the ?Roles? the ?User? is
> > granted to?
> >
> > I like the fact that ?Password policies groups? are attached to ?Groups?
> > instead of ?Users?? but the priority mechanism looks to me a bit complex to
> > understand for Realm administrators? and it becomes quite odd when having
> > ?Password policies groups? attached to ?Roles?, don?t you think so?
> >
> >
> >
> > Best regards,
> >
> > Patrice
> >
> >
> >
> > > > *From:* Stian Thorgersen [mailto:sthorger at redhat.com<mailto:sthorger at redhat.com>]
> > *Sent:* lundi 14 janvier 2019 08:51
> > > > *To:* AMIEL Patrice <Patrice.Amiel at gemalto.com<mailto:Patrice.Amiel at gemalto.com>>
> > *Cc:* keycloak-dev at lists.jboss.org<mailto:keycloak-dev at lists.jboss.org>
> > *Subject:* Re: [keycloak-dev] Defining several Password Policies within a
> > Realm
> >
> >
> >
> > Hi,
> >
> >
> >
> > This is a feature that have had a few requests for it so we would welcome
> > a PR.
> >
> >
> >
> > Assigning password policy groups to individual users is not the way to go.
> > I'd suggest adding a priority to the password policy group where the
> > password policy group with highest priority that applies to a user is used.
> > This would allow adding different matching conditions for a policy.
> > Initially it would be sufficient to match on a group of users, but it may
> > be useful to also add support for a role as not everyone use groups at all.
> >
> >
> > ------------------------------
> > This message and any attachments are intended solely for the addressees
> > and may contain confidential information. Any unauthorized use or
> > disclosure, either whole or partial, is prohibited.
> > E-mails are susceptible to alteration. Our company shall not be liable for
> > the message if altered, changed or falsified. If you are not the intended
> > recipient of this message, please delete it and notify the sender.
> > Although all reasonable efforts have been made to keep this transmission
> > free from viruses, the sender will not be liable for damages caused by a
> > transmitted virus.
> >
>
> _______________________________________________
> 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://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.jboss.org%2Fmailman%2Flistinfo%2Fkeycloak-dev&data=02%7C01%7CPatrice.Amiel%40gemalto.com%7C3ebd7fdb6e414b62c9b208d67f796a27%7C37d0a9db7c464096bfe31add5b495d6d%7C0%7C0%7C636836556799505604&sdata=E5IH7EaIOvUEckEd5KxXw1V5crFaUhK3msyYt8ZC3iw%3D&reserved=0>
________________________________
This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited.
E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender.
Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus.

From chris.smith at cmfirstgroup.com  Mon Feb  4 06:26:52 2019
From: chris.smith at cmfirstgroup.com (Chris Smith)
Date: Mon, 4 Feb 2019 11:26:52 +0000
Subject: [keycloak-dev] Link to guide for setting up an Eclipse Workspace?
Message-ID: <CY4PR22MB02481A016339051A9F09FA20986D0@CY4PR22MB0248.namprd22.prod.outlook.com>

I am embarking on a custom extension.  I've cloned the Git repository and setup the upstream.

I'd like to be sure I'm following project standards in my workspace

From chris.smith at cmfirstgroup.com  Mon Feb  4 06:40:50 2019
From: chris.smith at cmfirstgroup.com (Chris Smith)
Date: Mon, 4 Feb 2019 11:40:50 +0000
Subject: [keycloak-dev] Adding GSSCrential as a claim when user browser is
 not running on the Active Directory domain
Message-ID: <CY4PR22MB0248F1A4D977048DAF951DA0986D0@CY4PR22MB0248.namprd22.prod.outlook.com>

I have a requirement for getting a GSS Credential that will be generated from the Kerberos Server implemented by Windows Active Directory will be used to connect to an IBM host using IBM EIM (Enterprise Identity Mapping).
So I have GSS Credential delegation working when the user browser is running on a workstation in the AD domain.
I get the GSS Credential from other claims and it works to connect the user to the IBM host

My problem is 99.9% of the users workstations will not be members of the AD domain.

I can thank my misunderstanding of SPNEGO and GSS Credential delegation for this unfortunate mess.

So I'm guessing that I will have to create a new SPI that extends the Kerberos User/Password validation that I already have working.
I'm further guessing that I can, when the browser workstation is not in the AD Domain, I can add the credential in other claims

Any guidance?

From ssilvert at redhat.com  Mon Feb  4 07:54:24 2019
From: ssilvert at redhat.com (Stan Silvert)
Date: Mon, 4 Feb 2019 07:54:24 -0500
Subject: [keycloak-dev] Improve search by a specific user in the admin
 console
In-Reply-To: <1549140378.3647.2.camel@acutus.pro>
References: <CA+H6wMw6o3rYTbSDfOqOq4QzOy4pdjSOopruWRdYsDKWxs4tbg@mail.gmail.com>
	<c7809c72-348b-b984-f3e9-8c8714e4c31d@redhat.com>
	<1549140378.3647.2.camel@acutus.pro>
Message-ID: <2eaa7b8a-9d35-4523-233c-1a499851f591@redhat.com>

On 2/2/2019 3:46 PM, Dmitry Telegin wrote:
> Hi Stan,
>
> On Thu, 2019-01-31 at 07:46 -0500, Stan Silvert wrote:
>> This has always been a sore spot.? I expect that we will address it when
>> we rewrite the admin console, which is in the plan but we don't have a
>> timeline yet.
> By the way, have you already picked any particular technology for the rewrite? Will it be Angular 2+ or React, like for account2?
As of now, the plan is to use React.? But I've learned the hard way that 
things can change quickly.
>
> Also my hopes are that the Admin Console becomes truly pluggable/extensible one day. At the moment, if you have two GUI extensions from different authors, you have to hop between the themes, which I myself consider a substantial flaw.
The new account management will be extensible.? I've done a POC for this 
and it works out well.? I expect that we will use the same techniques 
for admin console.
>
> Thanks,
> Dmitry
>
>> Another approach for now would be to write a standalone java app that
>> uses the keycloak-admin-client to find the user id.? Then it opens that
>> user in the browser.? This way, you could use it with any keycloak server.
>>
>> On 1/31/2019 7:21 AM, Alexis Almeida wrote:
>>> Considering an instalation of Keycloak where there are 2mi (or more) of
>>> users on user_entity table, search for a specific user on the console is a
>>> stressing task if you do it several times a day. I think it should be
>>> possible to do "direct" search by username.
>>>
>>> Today it is possible to search for a specific user by ID, by typing
>>> id:xxxxxx in the search field in the console. IMO this feature could be
>>> expanded, so someone could search for a specific user by username or by
>>> email, like this: username:xxxxx or email:xxxxxx.
>>>
>>> I made this change on my local machine and the result was ok.
>>>
>>> private static final String SEARCH_USERNAME_PARAMETER = "username:";
>>> private static final String SEARCH_EMAIL_PARAMETER = "email:";
>>> .
>>> .
>>> .
>>> } else if (search.startsWith(SEARCH_USERNAME_PARAMETER)) {
>>>  ?????UserModel userModel =
>>> session.users().getUserByUsername(search.substring(SEARCH_USERNAME_PARAMETER.length()).trim(),
>>> realm);
>>>  ?????if (userModel != null) {
>>>  ?????????userModels = Arrays.asList(userModel);
>>>  ?????}
>>> } else if (search.startsWith(SEARCH_EMAIL_PARAMETER)) {
>>>  ?????UserModel userModel =
>>> session.users().getUserByEmail(search.substring(SEARCH_EMAIL_PARAMETER.length()).trim(),
>>> realm);
>>>  ?????if (userModel != null) {
>>>  ????????userModels = Arrays.asList(userModel);
>>>  ?????}
>>> } else {
>>> _______________________________________________
>>> 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 ieugen at netdava.com  Mon Feb  4 08:39:09 2019
From: ieugen at netdava.com (Eugen Stan)
Date: Mon, 4 Feb 2019 15:39:09 +0200
Subject: [keycloak-dev] translate keycloak
In-Reply-To: <81d32d1e-1fbd-8068-1c56-b04fbe5d8652@netdava.com>
References: <81d32d1e-1fbd-8068-1c56-b04fbe5d8652@netdava.com>
Message-ID: <9e245cd6-6865-c3dd-80f3-56fa0a226c4f@netdava.com>

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
>
>
>


From thomas.darimont at googlemail.com  Mon Feb  4 11:13:12 2019
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Mon, 4 Feb 2019 17:13:12 +0100
Subject: [keycloak-dev] RH-SSO 7.3 missing on Commercial Support page?
Message-ID: <CAK-7U1iddNTW1rn_zVDZ8JzD13v4V-crJAVdE7dWqTA5DefEEA@mail.gmail.com>

Hello,

just noticed that RH-SSO 7.3 (based on Keycloak 4.8.3) was released in
January.
https://access.redhat.com/documentation/en-us/red_hat_single_sign-on/7.3/html/release_notes/

I think this info is missing on:
https://www.keycloak.org/support.html

Cheers,
Thomas

From sthorger at redhat.com  Tue Feb  5 01:16:13 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 5 Feb 2019 07:16:13 +0100
Subject: [keycloak-dev] translate keycloak
In-Reply-To: <9e245cd6-6865-c3dd-80f3-56fa0a226c4f@netdava.com>
References: <81d32d1e-1fbd-8068-1c56-b04fbe5d8652@netdava.com>
	<9e245cd6-6865-c3dd-80f3-56fa0a226c4f@netdava.com>
Message-ID: <CAJgngAc3GeJrRBQqAORCOPob=OUHGSH4dxu3EgpHa+9QsbrXUg@mail.gmail.com>

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> 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
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From sthorger at redhat.com  Tue Feb  5 01:18:59 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 5 Feb 2019 07:18:59 +0100
Subject: [keycloak-dev] RH-SSO 7.3 missing on Commercial Support page?
In-Reply-To: <CAK-7U1iddNTW1rn_zVDZ8JzD13v4V-crJAVdE7dWqTA5DefEEA@mail.gmail.com>
References: <CAK-7U1iddNTW1rn_zVDZ8JzD13v4V-crJAVdE7dWqTA5DefEEA@mail.gmail.com>
Message-ID: <CAJgngAcmyzVoRG_vg6fE55STUy5kLtdsTo-YgZ+vp3o+a2A52Q@mail.gmail.com>

Fixed. Will be updated in an hour or so when GitHub pages have done its job.

On Mon, 4 Feb 2019 at 17:25, Thomas Darimont <thomas.darimont at googlemail.com>
wrote:

> Hello,
>
> just noticed that RH-SSO 7.3 (based on Keycloak 4.8.3) was released in
> January.
>
> https://access.redhat.com/documentation/en-us/red_hat_single_sign-on/7.3/html/release_notes/
>
> I think this info is missing on:
> https://www.keycloak.org/support.html
>
> Cheers,
> Thomas
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sthorger at redhat.com  Tue Feb  5 01:20:39 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 5 Feb 2019 07:20:39 +0100
Subject: [keycloak-dev] [keycloak-user] Switching to Native JavaScript
	promise by default
In-Reply-To: <1548656273.19952.1.camel@acutus.pro>
References: <CAJgngAekhwKAa24cNgEY_vgq2HZsbM3tUog0z0FnvkSmTa35KA@mail.gmail.com>
	<1548656273.19952.1.camel@acutus.pro>
Message-ID: <CAJgngAfARAQbb7+wJzY9QQHOrbsFNfhy3v1sSrXRXWfhvtkCHg@mail.gmail.com>

The switch will most likely be done in Keycloak 6, which is a while from
now. So we should fix any issues in the meantime. Can you report a bug for
this issue please?

On Mon, 28 Jan 2019 at 07:18, Dmitry Telegin <dt at acutus.pro> wrote:

> Hi, are there any particular plans for it?
>
> I think I've found a promise-related bug in JS adapter, but not sure if it
> makes any sense fixing it, since the whole thing is going to be
> transitioned to native promises.
>
> The bug is that the success()/error() functions are expected in doLogin()
> (keycloak.js:145), but the corresponding createPromise() is called without
> explicit true arg (line 1163), so if { promiseType: 'native' } is used,
> doLogin() will barf with "TypeError: kc.login(...).success is not a
> function".
>
> Cheers,
> Dmitry
>
> On Thu, 2019-01-17 at 08:55 +0100, Stian Thorgersen wrote:
> > I would like to switch the JavaScript adapter to use Native promises by
> > default and deprecate the legacy promise with the aim to remove it in the
> > future.
> >
> > This would result in users that want to continue to use the legacy
> promise
> > having to explicitly enable this in the config.
> >
> > I see this as the best path to eventually remove the legacy promises.
> > _______________________________________________
> > keycloak-user mailing list
> > keycloak-user at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-user
>

From sthorger at redhat.com  Tue Feb  5 01:27:28 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 5 Feb 2019 07:27:28 +0100
Subject: [keycloak-dev] Defining several Password Policies within a Realm
In-Reply-To: <PR1PR01MB493916F2D4E8E0A457600262F66D0@PR1PR01MB4939.eurprd01.prod.exchangelabs.com>
References: <PR1PR01MB4939AE7E0BE3C820C1360755F68A0@PR1PR01MB4939.eurprd01.prod.exchangelabs.com>
	<CAJgngAftS+U3kn1yr89LwaQK6BqoAydLGKY=LYTtO3Eja9q7DQ@mail.gmail.com>
	<PR1PR01MB49396153A2F07E00B26E0A44F6820@PR1PR01MB4939.eurprd01.prod.exchangelabs.com>
	<CAJgngAe8nb-6iib40q1LuOVk_kJcCnCHdqGRQi_u1h0C+ezp0g@mail.gmail.com>
	<1547849203.13934.6.camel@acutus.pro>
	<CAJgngAd-zWz+sgwCe7QW2DGNtnYCFMRVGC5xYwzjsgdPi82qhQ@mail.gmail.com>
	<PR1PR01MB493916F2D4E8E0A457600262F66D0@PR1PR01MB4939.eurprd01.prod.exchangelabs.com>
Message-ID: <CAJgngAcJdd38L17gVY+KRU1nQhj1r_mrmGmXKk7Uh0fX5aks8g@mail.gmail.com>

What is needed is to create a new PasswordPolicyConditionSPI that leverages
the component model. This allows adding a configured
PasswordPolicyConditionProvider to a specific password policy. The
component model has support for various built-in configuration types like
picking a role or group.

The password policy could even still be stored as a single string, would
just have something like "conditionProvider(<id>)" which would allow
creating an instance of the policy linked to the configured
PasswordPolicyConditionProvider instance.

When looking up the correct password policy for a user we'd simply loop
through the registered password policies calling the appliesTo method until
it returns true.

On Mon, 4 Feb 2019 at 09:49, AMIEL Patrice <Patrice.Amiel at gemalto.com>
wrote:

> Hi,
>
>
>
> I?ve been reading the SPI documentation during the past days, but to be
> honest, I?m not 100% comfortable with your proposal. Can you please clarify
> what you have in mind for this?
>
> Indeed, I don?t really see who would create the SPI interface (and why an ?
> appliesTo? function?), who would implement it, and who would call it (and
> when)! (you see how foggy it is for the moment in my mind :P )
>
>
>
> Thanks for your help !
>
>
>
> Best regards,
>
> Patrice
>
>
>
> *From:* Stian Thorgersen [mailto:sthorger at redhat.com]
> *Sent:* lundi 21 janvier 2019 09:21
> *To:* Dmitry Telegin <dt at acutus.pro>
> *Cc:* AMIEL Patrice <Patrice.Amiel at gemalto.com>;
> keycloak-dev at lists.jboss.org
> *Subject:* Re: [keycloak-dev] Defining several Password Policies within a
> Realm
>
>
>
> Not sure I fully understand, but sounds a bit overkill.
>
>
>
> Here's a simple way do to it:
>
>
>
> Introduce a Password Policy Condition SPI that leverages component model.
> The provider can have a simple method:
>
>
>
> * boolean appliesTo(UserModel user)
>
>
>
> That allows creating implementations of it that can be dynamically
> configured. So pretty simple to implement a group, role, etc. condition.
> Most of the screens is in the admin console today as component model
> provides this. We already have role selects and I think there is a group
> selector as well.
>
>
>
> On Fri, 18 Jan 2019 at 23:06, Dmitry Telegin <dt at acutus.pro> wrote:
>
> Just my 2?, this looks very similar to authorization policies that we
> already have - the same user/group/role/time/rules/JS stuff; maybe
> time-based *password* policies don't make much sense, but everything
> else does. The only difference is that authorization policies do simple
> grant/deny, and here the result should be a list of password policies
> to activate. Maybe we can reuse portions of existing authz code and/or
> GUI for that.
>
> Cheers,
> Dmitry
>
> On Fri, 2019-01-18 at 09:09 +0100, Stian Thorgersen wrote:
> > Implementation wise it will be more flexible to have multiple password
> > policies defined in a realm and have some logic defined on how to select
> > the correct password policy for a user. It sounds like are proposing to
> > have a password policy associated directly with a group, but I believe
> this
> > is a more complex, less flexible and harder to manage approach.
> >
> > I can imagine the following use-cases to select password policy for a
> > specific user:
> >
> > * Based on a group the user belongs to
> > * Based on a role the user has
> > * Based on which user federation provider the user comes from
> > * Based on identity provider links
> >
> > If a password policy is something that has:
> >
> > * The string representation of the policy (as we have today)
> > * A priority
> > * A condition that matches it against users
> >
> > Note: There also needs to be a way to define the default policy for the
> > realm
> >
> > That means we can support all mentioned use-cases above. I'm happy to
> > accept a contribution that only has supports to match on groups, but it
> has
> > to be implemented in a way where additional matching can easily be added,
> > so there should be an SPI to allow adding matchers.
> >
> > On Wed, 16 Jan 2019 at 17:00, AMIEL Patrice <Patrice.Amiel at gemalto.com>
> > wrote:
> >
> > > Hi Stian,
> > >
> > >
> > >
> > > Thanks for your reply. I?m glad to see that you would welcome a PR on
> the
> > > topic !
> > >
> > >
> > >
> > > To be sure that my understanding of your proposal is correct, let me
> > > rephrase what it could be:
> > >
> > > -          Several ?Password policies groups? might be defined within a
> > > single ?Realm?, each of them having their own set of ?Password
> Policies?
> > > with their own configuration values. In addition to that, you propose
> to
> > > add another information to each of the ?Password policies groups?: a
> > > priority.
> > >
> > > -          Contrary to my proposal, application of a ?Password policy
> > > group? would not be on a per-User basis. Instead, a ?Password policy
> group?
> > > would be applied to the ?Groups?, meaning that a ?Group? would now be
> able
> > > to gather Attributes, Roles and (new !) Password Policies for all the
> > > members of the ?Group?.
> > >
> > > -          Then, when a ?User? needs to login or to change its password
> > > (i.e. to access to its password policies), then KeyCloak would get the
> list
> > > of ?Groups? the user is member of, and then select the Group?s
> ?Password
> > > policies group? that has the highest priority: this is the one to be
> > > applied for password policy.
> > >
> > >
> > >
> > > Is my understanding correct?
> > >
> > >
> > >
> > > I also understand that not everyone is using Groups, but if so, I don?t
> > > understand what you mean by ?it may be useful to also add support for a
> > > role?. Do you want also to be able to attach a ?Password policies
> group?
> > > to individual roles, and thus apply the same election of the ?policy
> to be
> > > used? thanks to the priority, taking into account not only the
> ?Password
> > > policies groups? attached to the ?Groups? the ?User? is member of, but
> also
> > > the ?Password policies groups? attached to the ?Roles? the ?User? is
> > > granted to?
> > >
> > > I like the fact that ?Password policies groups? are attached to
> ?Groups?
> > > instead of ?Users?? but the priority mechanism looks to me a bit
> complex to
> > > understand for Realm administrators? and it becomes quite odd when
> having
> > > ?Password policies groups? attached to ?Roles?, don?t you think so?
> > >
> > >
> > >
> > > Best regards,
> > >
> > > Patrice
> > >
> > >
> > >
> > > > > *From:* Stian Thorgersen [mailto:sthorger at redhat.com]
> > > *Sent:* lundi 14 janvier 2019 08:51
> > > > > *To:* AMIEL Patrice <Patrice.Amiel at gemalto.com>
> > > *Cc:* keycloak-dev at lists.jboss.org
> > > *Subject:* Re: [keycloak-dev] Defining several Password Policies
> within a
> > > Realm
> > >
> > >
> > >
> > > Hi,
> > >
> > >
> > >
> > > This is a feature that have had a few requests for it so we would
> welcome
> > > a PR.
> > >
> > >
> > >
> > > Assigning password policy groups to individual users is not the way to
> go.
> > > I'd suggest adding a priority to the password policy group where the
> > > password policy group with highest priority that applies to a user is
> used.
> > > This would allow adding different matching conditions for a policy.
> > > Initially it would be sufficient to match on a group of users, but it
> may
> > > be useful to also add support for a role as not everyone use groups at
> all.
> > >
> > >
> > > ------------------------------
> > > This message and any attachments are intended solely for the addressees
> > > and may contain confidential information. Any unauthorized use or
> > > disclosure, either whole or partial, is prohibited.
> > > E-mails are susceptible to alteration. Our company shall not be liable
> for
> > > the message if altered, changed or falsified. If you are not the
> intended
> > > recipient of this message, please delete it and notify the sender.
> > > Although all reasonable efforts have been made to keep this
> transmission
> > > free from viruses, the sender will not be liable for damages caused by
> a
> > > transmitted virus.
> > >
> >
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> <https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.jboss.org%2Fmailman%2Flistinfo%2Fkeycloak-dev&data=02%7C01%7CPatrice.Amiel%40gemalto.com%7C3ebd7fdb6e414b62c9b208d67f796a27%7C37d0a9db7c464096bfe31add5b495d6d%7C0%7C0%7C636836556799505604&sdata=E5IH7EaIOvUEckEd5KxXw1V5crFaUhK3msyYt8ZC3iw%3D&reserved=0>
>
> ------------------------------
> This message and any attachments are intended solely for the addressees
> and may contain confidential information. Any unauthorized use or
> disclosure, either whole or partial, is prohibited.
> E-mails are susceptible to alteration. Our company shall not be liable for
> the message if altered, changed or falsified. If you are not the intended
> recipient of this message, please delete it and notify the sender.
> Although all reasonable efforts have been made to keep this transmission
> free from viruses, the sender will not be liable for damages caused by a
> transmitted virus.
>

From sthorger at redhat.com  Tue Feb  5 01:30:05 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 5 Feb 2019 07:30:05 +0100
Subject: [keycloak-dev] Integration with GuardianKey
In-Reply-To: <CAFjP4XQvSgNr2fB9oqDBrq2PJ5fuN=_CLEgU6E7Vo9KKRg_b2Q@mail.gmail.com>
References: <CAFjP4XTv=yupw4jZAf275q37JNJZj5jh9tr+BTH0A+0EeNSQMw@mail.gmail.com>
	<CA+H6wMzRFPSf2mkqa4vizP1SaSn6pbbqsFoP+YtwOF4aDvKboA@mail.gmail.com>
	<1549228866.7030.6.camel@acutus.pro>
	<CAFjP4XQvSgNr2fB9oqDBrq2PJ5fuN=_CLEgU6E7Vo9KKRg_b2Q@mail.gmail.com>
Message-ID: <CAJgngAfDxevzbj82LkeUMFxoUDzy8LNDL=j5EOt_kvv-bqFE7w@mail.gmail.com>

Authenticator is probably the only way to do it right now. Ideally this
should be done through the event listener mechanism, but that doesn't
currently support interrupting the event.

In the future I'd like to introduce a new event SPI for user related events
that is able to interrupt events. It could be used for logins,
registrations, profile updates, etc..

On Mon, 4 Feb 2019 at 01:34, Paulo Angelo <pa at pauloangelo.com> wrote:

> Dmitry and Al?xis,
>
> Thank you very much for the directions. We are going to work on it.
>
> regards,
>
> Paulo Angelo
>
> On Sun, Feb 3, 2019 at 8:06 PM Dmitry Telegin <dt at acutus.pro> wrote:
>
> > Hello Paulo,
> >
> > To add to Alexis's reply, you can use Script authenticator [1]. It's
> > especially good for prototyping since you don't have to create and deploy
> > the whole provider module.
> >
> > Also, you'll need an HttpClient instance to be able to perform external
> > HTTP requests, see [2] for that.
> >
> > [1] https://www.keycloak.org/docs/latest/server_admin/#executions
> > [2]
> > http://lists.jboss.org/pipermail/keycloak-user/2018-November/016456.html
> >
> > Good luck,
> > Dmitry Telegin
> > CTO, Acutus s.r.o.
> > Keycloak Consulting and Training
> >
> > Pod lipami street 339/52, 130 00 Prague 3, Czech Republic
> > +42 (022) 888-30-71
> > E-mail: info at acutus.pro
> >
> > On Sun, 2019-02-03 at 17:46 -0200, Alexis Almeida wrote:
> > > Hi Paulo,
> > >
> > > IMO the simplest way to do this is with an Authenticator Provider.
> Please
> > > see here:
> > >
> > >
> >
> https://www.keycloak.org/docs/latest/server_development/index.html#implementing-an-authenticator
> > > .
> > >
> > > In the authenticate method you can call the GuardianKey and, depending
> on
> > > the result, you call a context.success () or context.failure ().
> > >
> > > Like this:
> > >
> > > public void authenticate(AuthenticationFlowContext context) {
> > > ...
> > > if(!GuardianKeyValidation){
> > >    Response challenge = context.form()
> > >                 .setError("something")
> > >                 .createForm("error_page.ftl");
> > >
> > >  context.failureChallenge(AuthenticationFlowError.INVALID_CREDENTIALS,
> > > challenge);
> > >    return;
> > > }
> > > ...
> > > context.success();
> > > }
> > >
> > > Al?xis
> > >
> > >
> > > > Em dom, 3 de fev de 2019 ?s 15:38, Paulo Angelo <pa at pauloangelo.com>
> > > escreveu:
> > >
> > > > Hi all,
> > > >
> > > > We are trying to integrate KeyCloak with GuardianKey. However, we
> have
> > > > doubts related to the best way to do this and the best point in the
> > > > KeyCloak?s code for this integration.
> > > >
> > > > GuardianKey is a service to protect systems against authentication
> > attacks.
> > > > It uses Machine Learning and analyses the user's behavior, threat
> > > > intelligence and psychometrics (or behavioral biometrics). The
> > protected
> > > > system (in the concrete case, KeyCloak) must send an event via REST
> > for the
> > > > GuardianKey on each login attempt. More info at
> https://guardiankey.io
> > .
> > > >
> > > > The best way to integrate would be on having a hook in the procedure
> > that
> > > > process the user credentials submission in KeyCloak (the script that
> > > > receives the POST), something such as:
> > > >
> > > > if(<POST IN AUTH FORM>) {
> > > >
> > > >  boolean loginFailed =  checkLoginInKeyCloak();
> > > >
> > > >  GuardianKeyEvent event =
> > createEventForGuardianKey(username,loginFailed);
> > > >
> > > >  boolean GuardianKeyValidation = checkGuardianKeyViaREST(event);
> > > >
> > > >  if(GuardianKeyValidation){
> > > >
> > > >     // Allow access
> > > >
> > > >  } else {
> > > >
> > > >     // Deny access
> > > >
> > > >  }
> > > >
> > > > }
> > > >
> > > > Where is the best place to create this integration? Is there a way to
> > > > create a hook for this purpose? Should we create an extension?
> > > >
> > > > Any help is welcome.
> > > >
> > > > Thank you in advance.
> > > >
> > > > Best regards,
> > > >
> > > > Paulo Angelo
> > > > _______________________________________________
> > > > keycloak-dev mailing list
> > > > keycloak-dev at lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > >
> > > _______________________________________________
> > > keycloak-dev mailing list
> > > keycloak-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
> --
>
> Att,
>
> Paulo Angelo
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From mkanis at redhat.com  Tue Feb  5 02:40:42 2019
From: mkanis at redhat.com (Martin Kanis)
Date: Tue, 5 Feb 2019 08:40:42 +0100
Subject: [keycloak-dev] RH-SSO 7.3 missing on Commercial Support page?
In-Reply-To: <CAJgngAcmyzVoRG_vg6fE55STUy5kLtdsTo-YgZ+vp3o+a2A52Q@mail.gmail.com>
References: <CAK-7U1iddNTW1rn_zVDZ8JzD13v4V-crJAVdE7dWqTA5DefEEA@mail.gmail.com>
	<CAJgngAcmyzVoRG_vg6fE55STUy5kLtdsTo-YgZ+vp3o+a2A52Q@mail.gmail.com>
Message-ID: <CAAskycSjgB8Cd23xZJPLLxh=oKq3JrpiuDJcmuj-A4uu8r88Hg@mail.gmail.com>

Stian,

one more related thing. Is the "Buying support" paragraph still accurate? I
think it should refer to Red Hat Application Runtimes bundle.

Martin

On Tue, Feb 5, 2019 at 7:20 AM Stian Thorgersen <sthorger at redhat.com> wrote:

> Fixed. Will be updated in an hour or so when GitHub pages have done its
> job.
>
> On Mon, 4 Feb 2019 at 17:25, Thomas Darimont <
> thomas.darimont at googlemail.com>
> wrote:
>
> > Hello,
> >
> > just noticed that RH-SSO 7.3 (based on Keycloak 4.8.3) was released in
> > January.
> >
> >
> https://access.redhat.com/documentation/en-us/red_hat_single_sign-on/7.3/html/release_notes/
> >
> > I think this info is missing on:
> > https://www.keycloak.org/support.html
> >
> > Cheers,
> > Thomas
> > _______________________________________________
> > 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 Feb  5 03:12:10 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 5 Feb 2019 09:12:10 +0100
Subject: [keycloak-dev] More robust datasource configuration in Keycloak
 docker images
In-Reply-To: <CAK-7U1hRECsxJG1MLxGaVcoo+NEBgQazmcWeJM1bCiGgQMcOiQ@mail.gmail.com>
References: <CAK-7U1hRECsxJG1MLxGaVcoo+NEBgQazmcWeJM1bCiGgQMcOiQ@mail.gmail.com>
Message-ID: <CAJgngAcJ3g=8VyDMkaNsT3nq00Z1FQqsEyz9KVyDBgqQyN8jJw@mail.gmail.com>

Sorry for late reply, but at least I'm replying ;)

On Thu, 24 Jan 2019 at 17:00, Thomas Darimont <
thomas.darimont at googlemail.com> wrote:

> Hello Keycloak developers,
>
> The current Keycloak server docker image comes with some default
> configuration (listed below) for the supported databases (mysql, postgres,
> mariadb), which work quite well so far.
>
> However, in HA database production environments, we encountered some issues
> with the default configuration. We were able to mitigate those issues with
> the following general, and in our case PostgreSQL specific, settings.
>
> I'd like to propose adding those settings to the "change-database.cli"
> scripts of the default Keycloak docker images.
>
> We faced the following problems:
>
> 1. Connections are not always validated before use.
>
> If a database node is not available or has any issues, the connections in
> the connection-pool don't reflect this immediately, although the
> `check-valid-connection-sql` is set.
>
> 2. No timeout configured for database queries.
>
> Some database queries in Keycloak could run quite slowly (due to
> performance bugs, inefficient queries etc.). Sometimes this freezes the
> admin-console and if the operation is retried in different tabs, could use
> up all connections from the pool.
> Eventually, the query runs into a timeout, but only after a driver specific
> amount of time.
>
> 3. Creation of new connections could introduce an unnecessary long delay
> (1-5s.
>
>
> We managed to mitigate those issues by using the following additional
> settings in production - and haven't seen any problems with database
> connections since.
>
> This mitigates problem 1: This ensures that a connection is "really" tested
> before use.
>
> # Configure datasource to connection before use
>
>
> /subsystem=datasources/data-source=KeycloakDS/:write-attribute(name=validate-on-match,value=${env.DB_VALIDATE_ON_MATCH:true})
>
> This mitigates problem 2: since we can now explicitly control how long a
> query can run at max. --> better transparency.
>

Doesn't this result in extra overhead for each request? Would it not be
better to use background validation?


>
> # Configure datasource to use explicit query timeout in seconds
>
>
> /subsystem=datasources/data-source=KeycloakDS/:write-attribute(name=query-timeout,value=${env.DB_QUERY_TIMEOUT:60})
>
> This mitigates problem 3:
>
> To reduce the time for connection reuse we also use the following setting
> to use the next valid connection first, instead of immediately trying to
> create a new one.
>

It is probably a better default to have 60 seconds timeout, but that may
result in issues during migration.


>
> # Configure datasource to try all other connections before failing
>
>
> /subsystem=datasources/data-source=KeycloakDS/:write-attribute(name=use-fast-fail,value=${env.DB_USE_CAST_FAIL:false})
>
> In combination with PostgreSQL we also configured the following, which
> helped to make the database error handling more robust:
>
>
> /subsystem=datasources/data-source=KeycloakDS/:write-attribute(name=valid-connection-checker-class-name,value=org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker)
>
>
> /subsystem=datasources/data-source=KeycloakDS/:write-attribute(name=exception-sorter-class-name,value=org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter)
>
> This improves the PostgreSQL database error handling in Keycloak.
>

Would make sense to add those by default for PostgreSQL


>
> See:
>
> https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_application_platform/7.2/html/configuration_guide/datasource_management#example_postgresql_datasource
>
> Note that this document contains useful configurations for other database
> vendors as well.
>
> For reference, this is the current postgres change-database.cli script:
>
>
> https://github.com/jboss-dockerfiles/keycloak/blob/master/server/tools/cli/databases/postgres/change-database.cli
>
> ```
>
> /subsystem=datasources/data-source=KeycloakDS: remove()
>
> /subsystem=datasources/data-source=KeycloakDS:
>
> add(jndi-name=java:jboss/datasources/KeycloakDS,enabled=true,use-java-context=true,use-ccm=true,
>
> connection-url=jdbc:postgresql://${env.DB_ADDR:postgres}:${env.DB_PORT:5432}/${env.DB_DATABASE:keycloak}${env.JDBC_PARAMS:},
> driver-name=postgresql)
>
> /subsystem=datasources/data-source=KeycloakDS:
> write-attribute(name=user-name, value=${env.DB_USER:keycloak})
>
> /subsystem=datasources/data-source=KeycloakDS:
> write-attribute(name=password, value=${env.DB_PASSWORD:password})
>
> /subsystem=datasources/data-source=KeycloakDS:
> write-attribute(name=check-valid-connection-sql, value="SELECT 1")
>
> /subsystem=datasources/data-source=KeycloakDS:
> write-attribute(name=background-validation, value=true)
>
> /subsystem=datasources/data-source=KeycloakDS:
> write-attribute(name=background-validation-millis, value=60000)
>
> /subsystem=datasources/data-source=KeycloakDS:
> write-attribute(name=flush-strategy, value=IdleConnections)
>
> /subsystem=datasources/jdbc-driver=postgresql:add(driver-name=postgresql,
> driver-module-name=org.postgresql.jdbc,
> driver-xa-datasource-class-name=org.postgresql.xa.PGXADataSource)
>
> ```
>
> What do you think about adding the proposed settings?
>
> Cheers,
>
> Thomas
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sthorger at redhat.com  Tue Feb  5 03:39:37 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 5 Feb 2019 09:39:37 +0100
Subject: [keycloak-dev] Better support for "scope" in adapters
In-Reply-To: <CAJrcDBcyu+OD4KH0NZ1C=Z81bi+s7GtaTE+Fv8zNSCyOSWLU7A@mail.gmail.com>
References: <3030a267-b2b6-7a76-3020-42959ef344c5@redhat.com>
	<CAJrcDBep7ScX4O7G5fSh5oPhsbT9B5-ekqhF01MKiikZXB9ywg@mail.gmail.com>
	<e01a6dc8-3163-f132-835b-713b8cfdfc62@redhat.com>
	<CAJrcDBfNE8_8wSDCSrhvcnDa80w1=q=Ngm8wOae5pi9YERKqig@mail.gmail.com>
	<a57ed42b-3f80-21e2-f4e6-7f434030bef4@redhat.com>
	<CAJrcDBcUuiuD4sm5UaXh-BTy70mf+ipR10oHFq08jTS7ntxeUQ@mail.gmail.com>
	<27b5cb1e-cbc0-e79d-03f8-2203cddcf9e3@redhat.com>
	<CAJrcDBcyu+OD4KH0NZ1C=Z81bi+s7GtaTE+Fv8zNSCyOSWLU7A@mail.gmail.com>
Message-ID: <CAJgngAcRDk3omuu7TVZQC52Os1dB-_tnYyjawZS5bAFYKGjD0g@mail.gmail.com>

Tried to filter out implementation details here, so may have lost some
details. It would be good if we can try to keep discussions at a higher
level at least initially as it makes it much easier to follow the
discussion.

For scopes I can see the most common use-case will be the ability to do
incremental scopes. By that I mean the application doesn't request all
permissions it may need, but rather starts small and asks for more as the
user extends use of the application. This is mostly relevant to
applications that require consent.

Now with regards to the application being able to have different tokens to
invoke different services I'm not convinced this is needed so we should
rather wait for demand here. There's two ways a single app can consume
multiple services:

1) Application directly invokes multiple services - in this case the
application should be able to use scopes or token exchange to obtain tokens
to invoke different services. In fact I'd say token exchange is probably
what is wanted here rather than scopes.
2) Application invokes a backend service that aggregates multiple services
- in this case token exchange comes in as the backend service needs to be
able to obtain tokens to invoke the different services

I would think option 2 is the best approach as it allows implementing the
complex code in server side code and also makes the application more
transparent to API changes.

With regards to incremental scope support we need to be able to do that
without requiring logout. For JS adapter that should already work, but it
has one issue and that is you can't set the scope to use with automated
login. We should probably make the scope configurable in the init function
as well as when invoking login function directly. For servlet we should
probably also have a way to configure the initial scope and expose a method
to obtain additional scopes without requiring logout.

I'm not convinced about client scope inheritance. It has an additional
implementation complexity, but most importantly usability with regards to
understand what is actually included in the token when you have
inheritance. It may also have some strange side-effects like how do you
make sure the order of what is applied is correct. Again, probably
something best left until there is demand for it.


On Thu, 31 Jan 2019 at 17:04, Pedro Igor Silva <psilva at redhat.com> wrote:

> +1
>
> On Thu, Jan 31, 2019 at 11:14 AM Marek Posolda <mposolda at redhat.com>
> wrote:
>
> > On 31/01/2019 14:07, Pedro Igor Silva wrote:
> >
> > This what I like most about client scopes (in addition to all mapping you
> > do to claims in the tokens) :) Would also make sense to do the same thing
> > to client scopes ? So clients requesting "foo" would also get "bar" and
> > "xpto", for instance ?
> >
> > Maybe this could avoid the client to request 10 scopes but just a more
> > coarse-grained scope representing all of them.
> >
> > There is opened JIRA for client scopes inheritance
> > https://issues.jboss.org/browse/KEYCLOAK-6633 . I believe this will
> cover
> > what you have in mind? It's just not yet done...
> >
> > Marek
> >
> >
> >
> > On Thu, Jan 31, 2019 at 10:43 AM Marek Posolda <mposolda at redhat.com>
> > wrote:
> >
> >> On 30/01/2019 14:40, Pedro Igor Silva wrote:
> >>
> >>
> >>
> >> On Wed, Jan 30, 2019 at 5:25 AM Marek Posolda <mposolda at redhat.com>
> >> wrote:
> >>
> >>> On 29/01/2019 19:49, Pedro Igor Silva wrote:
> >>>
> >>> I'm not sure if we need to consider that in our adapters.
> >>>
> >>> Usually, the front-end knows the set of scopes that it needs to
> interact
> >>> with the backend and stay functional.
> >>>
> >>> Maybe. I am personally not sure how people expect to use "scope"
> >>> parameters in their frontend applications. Maybe 90% of frontend
> clients
> >>> don't need to use "scope" parameter at all. And from the remaining,
> they
> >>> will be fine with the current support of the "scope" parameter.
> >>>
> >> I would say so, mainly because I think people are still using RBAC to
> >> enforce access to APIs. Enterprise scenarios don't really use scopes as
> >> they are more related with delegation.
> >>
> >> Yeah, maybe. Just a note that our client scopes support also allows to
> >> limit roles in the token. For example you can define role scope
> mappings of
> >> client scope "service1" to have role "service1.my-service1-role" . So by
> >> requesting "scope=service1", you will also receive this role in the
> token
> >> and hence can be used for RBAC based authorization.
> >>
> >> But anyway, I probably won't create any JIRAs for now. Will wait if
> there
> >> is some more feedback or some more requests for better support of
> "scope"
> >> parameter in the adapters.
> >>
> >> Thanks for the feedback Pedro!
> >>
> >> Marek
> >>
> >> One possibility, where I can see usage of this, is when frontend client
> >>> wants to invoke multiple different services and he wants to use
> different
> >>> access tokens with properly "isolated" audiences. So for example you
> want
> >>> to have:
> >>>
> >>> - access token with "scope=service1", which will have in itself
> audience
> >>> claim "aud: service1" and you will use it to invoke backend service1
> >>> - access token with "scope=service2", which will have in itself
> audience
> >>> claim "aud: service2" and you will use it to invoke backend service2
> >>>
> >>> In this case, having the possibility for adapters to "cache" multiple
> >>> tokens for various scopes can be beneficial IMO, so client can easily
> >>> retrieve proper access token based on the service he wants to invoke.
> >>>
> >>> And the backend by itself is free to exchange tokens to call other
> >>> services (service chaining).
> >>>
> >>> Don't think that brings a lot of complexity to the front-end and,
> >> probably, indicates a bad design?
> >>
> >>> IMO in many cases, you're right. For example when frontend client uses
> >>> access token to invoke backend "service1", this backend may want to
> >>> retrieve some other data from "service11". So service1 backend needs to
> >>> reuse the token or he wants to exchange this token.
> >>>
> >>> But in many cases, you want to avoid this. So in my example above, when
> >>> you have access token with "aud: service1", you want this access token
> to
> >>> be used solely to invoke service1. You don't want to have one huge
> access
> >>> token, which will have all the audiences like:
> >>>
> >>> aud: [ "service1", "service2" ]
> >>>
> >> The access token is also tied with the client, what means "this client
> is
> >> allowed to invoke service1 and service2". I usually don't see a problem
> on
> >> that if you consider that multiple audiences mean that a high degree of
> >> trust between the parties involved. What I think is true for most
> >> enterprise use cases where the front-end is basically accessing internal
> >> services.
> >>
> >> It is also worthy to consider, IMO, that the fact that you have distinct
> >> services, does not mean they are not part of the same API, thus the same
> >> audience.
> >>
> >>> You may want separate access tokens with isolated audiences exactly
> >>> because you don't want service1 and service2 to be able to invoke each
> >>> other. IMO this isolation is one of the main usages of the "aud" claim
> in
> >>> the tokens.
> >>>
> >>>
> >>> One thing that makes sense though is "incremental authorization" and
> >>> allow apps to request additional scopes during an authentication
> session,
> >>> so the app gets what was previously granted and the new scopes
> (depending
> >>> on user consent). But I think we support that already, right ?
> >>>
> >>> We don't support it directly and maybe this is something to improve.
> ATM
> >>> you will need programatically do something like this:
> >>>
> >>> String existingScope = existingAccessToken.getScope();
> >>>
> >>> // I want to use existingScope and add "phone" scope to it
> >>> String newScope = existingScope + " phone";
> >>>
> >>> // Request the login for new scope now
> >>>
> >>>
> >>> The part of "requesting login for new scope" is possible with
> javascript
> >>> adapter, but not easily with the "java" adapter. With java adapter,
> there
> >>> is no easy way to manually "build" URL to sent to OIDC authentication
> >>> endpoint (equivalent of keycloak.js method "createLoginUrl"). That's
> also
> >>> one of the things, which I proposed to improve in this email thread.
> >>>
> >> Marek
> >>>
> >>>
> >>> Regards.
> >>> Pedro Igor
> >>>
> >>> On Tue, Jan 29, 2019 at 9:36 AM Marek Posolda <mposolda at redhat.com>
> >>> wrote:
> >>>
> >>>> During my work on Client Scopes last year, I did not any work on the
> >>>> adapters side. I think there is a space for improvement here. I will
> >>>> try
> >>>> to summary current issues and some initial proposals for improve
> >>>> things.
> >>>> Suggestions welcomed! And sorry for longer email :)
> >>>>
> >>>>
> >>>> Both javascript adapter and servlet adapter has some way for
> requesting
> >>>> the additional "scope" and ensure that that initial OIDC
> authentication
> >>>> request sent to Keycloak will contain some custom "scope" parameter.
> >>>> The
> >>>> javascript adapter has support for "scope" as an option of the "login"
> >>>> method [1]. The servlet adapter has a possibility to inject custom
> >>>> "scope" with parameters forwarding [2]. I am not sure about node.js
> and
> >>>> other adapters TBH. But even for javascript and servlet adapter, the
> >>>> current support is quite limited for few reasons. For example:
> >>>>
> >>>> - The approach of parameters forwarding used in servlet adapters
> >>>> requires to logout before requesting the additional scope. Because
> >>>> when
> >>>> I am already authenticated in the application and I open secured URL
> >>>> like http://localhost/app/secured?scope=some-custom-scope, the
> adapter
> >>>> will just ignore it in case that user is already logged-in and it will
> >>>> automatically forward to the application.
> >>>>
> >>>> - Both servlet and javascript adapters support to have just single
> >>>> "triplet" of tokens per browser session. In this context "triplet"
> >>>> means
> >>>> the single set of 3 tokens (ID token , Access Token , Refresh token).
> >>>> So
> >>>> for example when I want to request the custom scope for being able to
> >>>> invoke "service1", I can use "scope=service1". However after Keycloak
> >>>> redirects me back to the application, the existing triplet of tokens
> is
> >>>> just replaced with the new one for "service1" . Then when I want to
> >>>> later invoke another service like "service2", I need to request the
> >>>> additional scope "scope=service2", which will replace my tokens on the
> >>>> adapter's side with the "service2" tokens . But then later when I want
> >>>> to switch again to "service1", I need to redirect to Keycloak again as
> >>>> the current triplet of tokens for "service1" etc.
> >>>>
> >>>>
> >>>> To improve this limitation, I think that it will be good if adapters
> >>>> easily support the following:
> >>>>
> >>>> - Instead of having single triplet of tokens, it will be good if
> >>>> adapters can contain Map of tokens. Key of the map can be "scope"
> >>>> parameter. So for example, the adapter will have "default" tokens
> >>>> (those, which were used for initial login), the tokens for "service1"
> >>>> and the tokens for "service2" .
> >>>>
> >>>> - It will be nice if there is easy way to ask adapter for "service1"
> >>>> scope. In case that I don't have yet this scope, adapter will redirect
> >>>> me to Keycloak with "scope=service1". If I already have it, adapter
> >>>> will
> >>>> return me an existing token. If existing access token is expired,
> >>>> adapter will refresh the access token for requested scope in the
> >>>> background and return me the "updated" token.
> >>>>
> >>>> - When I want to invoke service1 and I need to use "scope=service1", I
> >>>> usually need just access token and refresh token. I don't need ID
> Token
> >>>> anymore. I also don't need the "profile" and "email" claims to be
> >>>> returned in the new access token. This is related to the JIRA of
> having
> >>>> the server-side support for client scopes like (always, default,
> >>>> optional) instead of current (default, optional) [3]. In other words,
> >>>> the client scopes "profile" and "email" will be default client scopes,
> >>>> which means that if I don't use "scope=openid" in the OIDC initial
> >>>> request, the "profile" and "email" will be ommited from the response
> as
> >>>> well as the ID Token will be ommited from the response.
> >>>>
> >>>>
> >>>> So how to support this on adapters? For Keycloak.js, I can think about
> >>>> some variation of existing "update" method like this:
> >>>>
> >>>>
> >>>> keycloak.updateTokenWithScope('service1',
> >>>> 5).success(function(accessToken, refreshed) {
> >>>>          if (refreshed) {
> >>>>              alert("I had existing accessToken for scope 'service1',
> >>>> but
> >>>> it needed to be refreshed as it was expired or about to expire in less
> >>>> than 5 seconds");
> >>>>          } else {
> >>>>              alert('I have accessToken for 'service1',  which didn't
> >>>> need to be refreshed');
> >>>>          }
> >>>>          // I can invoke REST service now with the accessToken
> >>>>          ...
> >>>>      }).error(function() {
> >>>>          alert("Failed to refresh the token OR I don't have yet scope
> >>>> for 'service1' .");
> >>>>          // User usually need to call keycloak.login with the
> requested
> >>>> scope now...
> >>>>      });
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> For servlet adapter something like:
> >>>>
> >>>> KeycloakSecurityContext ctx = ... // Retrieved from HttpServletRequest
> >>>> or Principal as currently
> >>>>
> >>>> if (ctx.hasScope("service1")) {
> >>>>      try {
> >>>>          String accessToken = ctx.getScope("service1");
> >>>>          // Invoke service1 with accessToken now
> >>>>      } catch (TokenRefreshException ex) {
> >>>>          log.error("I already had scope for service1, but failed to
> >>>> refresh the token. Need to re-login for the scope service1");
> >>>>
> >>>>          // See method below
> >>>>          redirectToKeycloakWithService1Scope();
> >>>>      }
> >>>> } else {
> >>>>      // See method below
> >>>>      redirectToKeycloakWithService1Scope();
> >>>> }
> >>>>
> >>>>
> >>>> private void redirectToKeycloakWithService1Scope() {
> >>>>      KeycloakRedirectUriBuilder builder = ctx.createLoginUrl();
> >>>>      URL url = builder.scope("service1").build();
> >>>>      httpServletResponse.sendRedirect(url);
> >>>> }
> >>>>
> >>>>
> >>>> Regarding the class KeycloakRedirectUriBuilder, I was thinking about
> >>>> this class so that servlet adapter are able to easily create login URL
> >>>> with custom values for things like scope, prompt, max_age etc. This
> >>>> capability is currently missing in servlet adapters and the current
> >>>> approach based on parameters forwarding is a bit clunky for few
> >>>> reasons.
> >>>> One reason is usability and the other is, that you need to logout
> first.
> >>>>
> >>>>
> >>>> [1]
> >>>>
> >>>>
> https://www.keycloak.org/docs/latest/securing_apps/index.html#javascript-adapter-reference
> >>>> [2]
> >>>>
> >>>>
> https://www.keycloak.org/docs/latest/securing_apps/index.html#_params_forwarding
> >>>> [3] https://issues.jboss.org/browse/KEYCLOAK-8323
> >>>>
> >>>> Marek
> >>>>
> >>>> _______________________________________________
> >>>> 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 Feb  5 03:45:38 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 5 Feb 2019 09:45:38 +0100
Subject: [keycloak-dev] OIDC Discovery-enabled IdentityProvider
In-Reply-To: <CA+AQu3z4JTTSCQU0g9m5VV5SFYUk92-sA1hqT-AedPZRotmcCw@mail.gmail.com>
References: <00aa01d4ac7b$a7767460$f6635d20$@gmail.com>
	<1914838141.50603473.1547562353763.JavaMail.zimbra@redhat.com>
	<38415268.50625497.1547566301029.JavaMail.zimbra@redhat.com>
	<CA+AQu3yKjkTU2XCaiE1-xbfyn3idiswk5OWSsLxNnZRKsMFJWA@mail.gmail.com>
	<CAJgngAccFbcFOE4Dt4v=R-WXky9mdmGPZqzDvwi3AthrBLOjvQ@mail.gmail.com>
	<CA+AQu3waQr+Zdm1kA_PwoghNfcDzzhttc56saxTEhhxRXwy7Eg@mail.gmail.com>
	<CAJgngAeJn1jSQRk-7yZzaYfDTYE_Ww5pE9MgyumPCkSfYa4tQw@mail.gmail.com>
	<CA+AQu3yuSeN+pOFRwuDR-2CdNvNVPjoHv=xEmTNS5pHHv1qR8Q@mail.gmail.com>
	<CA+AQu3z4JTTSCQU0g9m5VV5SFYUk92-sA1hqT-AedPZRotmcCw@mail.gmail.com>
Message-ID: <CAJgngAf-w-=Pwvu0JLGkAJ0ipPs9v8noPUdbkvsiG52RobKGSA@mail.gmail.com>

On Mon, 4 Feb 2019 at 05:14, James Campbell <james.p.campbell at gmail.com>
wrote:

> All--
>
> Thanks to Stian's recommendations for similar features in the codebase,
> I've developed a proposal for how to implement this feature, and sketched
> out an initial implementation. As he suggested, I'd like to get feedback
> before opening up a PR.
>
> 1. We introduce a new subclass of the OIDCIdentityProvider / Factory
> called OIDCDiscoveryIdentityProvider. The new class adds a discoverConfig
> method that can be used to discover and set all relevant endpoints in a
> configuration except the issuer. Issuer then becomes the sole required
> element of the config. (So the GoogleIdentityProvider, for example, will
> then just call discoverConfig with its hard-coded issuer).
>    -> During the parseConfig call, the Factory will raise a
> RuntimeException if the config cannot be obtained, since if the config can
> never be obtained there is no way to have a valid configuration at all.
>    -> During the discoverConfig call, we return the cached value, and
> optionally refresh it based on when we last obtained the configuration.
>    -> In the event of a failure in the *refresh* I'm imagining the best
> behavior is to log a warning but then return the cached config (last known
> good config).
>

This should just be added to the OIDCIdentityProvider directly rather than
a subclass. Perhaps we should have an option to configure how frequently
the configuration is reloaded.


>
> 2. We introduce an SPI and interface called
> OIDCDiscoveryRepresentationProvider / Factory and implementations called
> Infinispan... which obtains OIDCConfigurationRepresentations using the
> /.well-known/openid-configuration endpoint on the issuer.
>
> I have a couple questions:
>
> 1. I began an implementation of this, but the @JsonProperty annotations on
> the existing OIDCCOnfigurationRepresentation class seem to be ignored when
> I try to have it read from the openid-configuration docuement, e.g.:
>   - OIDCConfigurationRepresentation rep = SimpleHttp.doGet(issuer +
> "/.well-known/openid-configuration",
> session).asJson(OIDCConfigurationRepresentation.class); // FAILS with
> "Unrecognized field ..." Perhaps a mismatch of the jackson annotation
> version in the keycloak-model-infinispan submodule?
>

Is the unknown field actually mapped or is the ignore unknown fields option
enabled? The ignore unknown fields should probably be enabled as there may
be unknown elements in the config.


>
> 2. Assuming the design above makes sense, what is the right way to plug
> this into the testing framework? Is one of the core developers interested
> in tackling that aspect if I push a PR with the above features implemented?
>

We are very reluctant to receive PRs from the community that do not include
tests. Think about it, would you as a developer like to implement tests for
other developers? We can help give you recommendations on how to test it
though.


>
> James
>
> On Sun, Jan 27, 2019 at 11:15 AM James Campbell <
> james.p.campbell at gmail.com> wrote:
>
>> Got it; I checked that code out and it does look like a pretty direct
>> model for the refreshing feature. I'll begin working on a PR.
>>
>> On Mon, Jan 21, 2019 at 3:25 AM Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>>
>>> JWKs used by identity brokering and client authentication.
>>>
>>> On Sat, 19 Jan 2019 at 23:29, James Campbell <james.p.campbell at gmail.com>
>>> wrote:
>>>
>>>> Stian--
>>>>
>>>> Thanks for confirming. Which keys are you referring to--I'll take a
>>>> look at that in the code and try to follow that pattern closely.
>>>>
>>>> James
>>>>
>>>> On Wed, Jan 16, 2019 at 1:52 AM Stian Thorgersen <sthorger at redhat.com>
>>>> wrote:
>>>>
>>>>> It would be good to get these changes included. We do something
>>>>> similar for the keys today and they are cached in an Infinispan local
>>>>> cache. Could do something similar for the OIDC discovery/config.
>>>>>
>>>>> On Tue, 15 Jan 2019 at 17:44, James Campbell <
>>>>> james.p.campbell at gmail.com> wrote:
>>>>>
>>>>>> Tomas--
>>>>>>
>>>>>> Thanks--it certainly seems close, you're right! It looks, however
>>>>>> like an
>>>>>> OIDC provider still uses a static configuration even though it loads
>>>>>> it
>>>>>> from the discovery URL--that is, once it's loaded at configuraiton
>>>>>> time, it
>>>>>> doesn't discover new changes, and there isn't an option to
>>>>>> refresh/store
>>>>>> that discovery endpoint outside of configuration.
>>>>>>
>>>>>> It's not clear to me how important that feature is--on one hand, it
>>>>>> seems
>>>>>> unlikely that we should expect frequent changes; on the other, in the
>>>>>> short
>>>>>> time since I started exploring this setup, I have encountered three
>>>>>> changes
>>>>>> in google's OIDC endpoints between what was hard-coded into keycloak,
>>>>>> what
>>>>>> is in their documentation, and what their current discovery endpoint
>>>>>> provides. (And, the google docs specifically suggest refreshing from
>>>>>> the
>>>>>> endpoint periodically).
>>>>>>
>>>>>> Thoughts?
>>>>>>
>>>>>> James
>>>>>>
>>>>>>
>>>>>> On Tue, Jan 15, 2019 at 10:31 AM Tomas Kyjovsky <tkyjovsk at redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>> > Please disregard my previous message.
>>>>>> >
>>>>>> > Looking at the docs [1] and the Admin Console UI this should be
>>>>>> already
>>>>>> > possible with the OIDC identity provider.
>>>>>> > When creating a OIDC identity provider in the Admin Console there
>>>>>> is an
>>>>>> > option at the bottom of the page to import OIDC configuration
>>>>>> metadata from
>>>>>> > URL.
>>>>>> >
>>>>>> > Does this cover your use case?
>>>>>> >
>>>>>> >
>>>>>> > Regards,
>>>>>> > Tomas
>>>>>> >
>>>>>> > [1]
>>>>>> >
>>>>>> https://www.keycloak.org/docs/latest/server_admin/index.html#openid-connect-v1-0-identity-providers
>>>>>> >
>>>>>> >
>>>>>> > ----- Original Message -----
>>>>>> > > Hello James,
>>>>>> > >
>>>>>> > > See my 2 cents inline..
>>>>>> > >
>>>>>> > > ----- Original Message -----
>>>>>> > > > All--
>>>>>> > > >
>>>>>> > > >
>>>>>> > > >
>>>>>> > > > After observing that the Google Social Identity Provider in
>>>>>> Keycloak
>>>>>> > was
>>>>>> > > > using a deprecated userprofile endpoint [
>>>>>> > > > <
>>>>>> https://issues.jboss.org/projects/KEYCLOAK/issues/KEYCLOAK-9179>
>>>>>> > > > Keycloak-9179,  <https://issues.jboss.org/browse/KEYCLOAK-9169>
>>>>>> > > > Keycloak-9169], I wanted to propose the creation of an
>>>>>> IdentityProvider
>>>>>> > > > that
>>>>>> > > > will use the OIDC Discovery mechanism to dynamically build a
>>>>>> config [
>>>>>> > > > <https://issues.jboss.org/browse/KEYCLOAK-9194> Keycloak-9194].
>>>>>> > > >
>>>>>> > > >
>>>>>> > > >
>>>>>> > > > I see a few decision points along the way that I wanted to ask
>>>>>> about
>>>>>> > before
>>>>>> > > > an implementation, since I'm very new to keycloak and just
>>>>>> starting to
>>>>>> > > > understand the codebase. In particular, I wondered if this
>>>>>> group could
>>>>>> > > > share
>>>>>> > > > insight into these couple issues so I can make a more informed
>>>>>> design:
>>>>>> > > >
>>>>>> > > >
>>>>>> > > >
>>>>>> > > > 1.    It looks to me like the actual IdentityProviders are
>>>>>> instantiated
>>>>>> > > > just
>>>>>> > > > as they're being used, but that the models are persisted in the
>>>>>> > RealmModel.
>>>>>> > > > It's not clear to me where the separation of concerns is
>>>>>> supposed to be
>>>>>> > > > between the IdentityProvider and the IdentityProviderModel-in
>>>>>> > particular
>>>>>> > > > since the GoogeIdentityProvider, say, immediately sets
>>>>>> endpoints in its
>>>>>> > > > constructor. Normatively, where *should* social identity
>>>>>> providers'
>>>>>> > model
>>>>>> > > > configuration be set (and, e.g., where are the models first
>>>>>> added to
>>>>>> > the
>>>>>> > > > RealmModel)?
>>>>>> > >
>>>>>> > > Provider classes are being instantiated per transaction by their
>>>>>> > > corresponding ProviderFactories and then left to be
>>>>>> garbage-collected
>>>>>> > after
>>>>>> > > Provider.close() is called.
>>>>>> > > The Provider class is given its configuration
>>>>>> (IdentityProviderModel in
>>>>>> > this
>>>>>> > > case) by its factory which I believe loads it from cache/jpa
>>>>>> layer. Any
>>>>>> > > class extending AbstractIdentityProvider should then be able to
>>>>>> access
>>>>>> > its
>>>>>> > > config via getConfig() method but I don't think it will be able to
>>>>>> > > update/persist it back. The provider configuration/model itself is
>>>>>> > managed
>>>>>> > > by the IdentityProviderResource (REST endpoint accessible via
>>>>>> REST or
>>>>>> > admin
>>>>>> > > console UI) in the keycloak/services module so I think the
>>>>>> > > auto-configuration logic would have to be placed somewhere there.
>>>>>> > >
>>>>>> > > >
>>>>>> > > >
>>>>>> > > >
>>>>>> > > > 2.    I see that there is logic to parse OIDC Discovery
>>>>>> configuration
>>>>>> > as
>>>>>> > > > part of configuring Keycloak itself as an OIDC provider /
>>>>>> implementer
>>>>>> > of
>>>>>> > > > OIDC protocol (including building and parsing the .well-known
>>>>>> config
>>>>>> > > > elements), but that logic seems not to be used in any setting
>>>>>> > currently as
>>>>>> > > > a
>>>>>> > > > client. Should I plan to reuse, say, the
>>>>>> > OIDCConfigurationRepresentation
>>>>>> > > > and
>>>>>> > > > OIDCWellKnownProvider classes for their logic in handling such
>>>>>> configs?
>>>>>> > > >
>>>>>> > > >
>>>>>> > > >
>>>>>> > > >
>>>>>> > > >
>>>>>> > > > Currently, I'm imagining something along the lines of extending
>>>>>> > > > OIDCIdentityProvider with a new OIDCDiscoveryIdentityProvider
>>>>>> that
>>>>>> > adds a
>>>>>> > > > discoverConfig method which can be used by an implementing
>>>>>> class (such
>>>>>> > as
>>>>>> > > > GoogleIdentityProvider) to discover and cache endpoints such
>>>>>> that they
>>>>>> > are
>>>>>> > > > not hard-coded into the implementing class. Each implementing
>>>>>> class
>>>>>> > would
>>>>>> > > > then have a public static final DISCOVERY_URL that it passes to
>>>>>> > > > discoverConfig.
>>>>>> > > >
>>>>>> > > >
>>>>>> > > >
>>>>>> > > > My main hangup, as suggested above, is that to implement the
>>>>>> caching, I
>>>>>> > > > want
>>>>>> > > > to ensure that the model configuration is stored/set in the
>>>>>> right
>>>>>> > place.
>>>>>> > > >
>>>>>> > > >
>>>>>> > > >
>>>>>> > > > Thanks for bearing with me as I come up to speed on this!
>>>>>> > > >
>>>>>> > > >
>>>>>> > > >
>>>>>> > > > James
>>>>>> > > >
>>>>>> > > > _______________________________________________
>>>>>> > > > keycloak-dev mailing list
>>>>>> > > > keycloak-dev at lists.jboss.org
>>>>>> > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>> > > >
>>>>>> > >
>>>>>> > >
>>>>>> > > Regards,
>>>>>> > > Tomas
>>>>>> > >
>>>>>> >
>>>>>>
>>>>>>
>>>>>> --
>>>>>> -... . / - .-. ..- . .-.-.- / -... . / .--. .-. . ... . -. - .-.-.- /
>>>>>> -...
>>>>>> . / ..-. .. -
>>>>>> 07:d0:2d:0b:d6:9d:27:c6:a7:c1:ec:e3:b1:65:f4:70
>>>>>> _______________________________________________
>>>>>> keycloak-dev mailing list
>>>>>> keycloak-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>
>>>>>
>>>>
>>>> --
>>>> -... . / - .-. ..- . .-.-.- / -... . / .--. .-. . ... . -. - .-.-.- /
>>>> -... . / ..-. .. -
>>>> 07:d0:2d:0b:d6:9d:27:c6:a7:c1:ec:e3:b1:65:f4:70
>>>>
>>>
>>
>> --
>> -... . / - .-. ..- . .-.-.- / -... . / .--. .-. . ... . -. - .-.-.- /
>> -... . / ..-. .. -
>> 07:d0:2d:0b:d6:9d:27:c6:a7:c1:ec:e3:b1:65:f4:70
>>
>
>
> --
> -... . / - .-. ..- . .-.-.- / -... . / .--. .-. . ... . -. - .-.-.- / -...
> . / ..-. .. -
> 07:d0:2d:0b:d6:9d:27:c6:a7:c1:ec:e3:b1:65:f4:70
>

From ieugen at netdava.com  Tue Feb  5 03:46:27 2019
From: ieugen at netdava.com (Eugen Stan)
Date: Tue, 5 Feb 2019 10:46:27 +0200
Subject: [keycloak-dev] translate keycloak
In-Reply-To: <CAJgngAc3GeJrRBQqAORCOPob=OUHGSH4dxu3EgpHa+9QsbrXUg@mail.gmail.com>
References: <81d32d1e-1fbd-8068-1c56-b04fbe5d8652@netdava.com>
	<9e245cd6-6865-c3dd-80f3-56fa0a226c4f@netdava.com>
	<CAJgngAc3GeJrRBQqAORCOPob=OUHGSH4dxu3EgpHa+9QsbrXUg@mail.gmail.com>
Message-ID: <c5da360b-ebd0-3c40-47a8-808ec5b27e7d@netdava.com>

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>> 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>
>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>


From sthorger at redhat.com  Tue Feb  5 04:47:39 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 5 Feb 2019 10:47:39 +0100
Subject: [keycloak-dev] translate keycloak
In-Reply-To: <c5da360b-ebd0-3c40-47a8-808ec5b27e7d@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>
Message-ID: <CAJgngAdMjfhOS3qBf=pKocpAPBxPZ0L_q+Uvw=w-WMxT0N4TfQ@mail.gmail.com>

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> 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>> 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>
> >     https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
>
>

From sthorger at redhat.com  Tue Feb  5 04:53:15 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 5 Feb 2019 10:53:15 +0100
Subject: [keycloak-dev] RH-SSO 7.3 missing on Commercial Support page?
In-Reply-To: <CAAskycSjgB8Cd23xZJPLLxh=oKq3JrpiuDJcmuj-A4uu8r88Hg@mail.gmail.com>
References: <CAK-7U1iddNTW1rn_zVDZ8JzD13v4V-crJAVdE7dWqTA5DefEEA@mail.gmail.com>
	<CAJgngAcmyzVoRG_vg6fE55STUy5kLtdsTo-YgZ+vp3o+a2A52Q@mail.gmail.com>
	<CAAskycSjgB8Cd23xZJPLLxh=oKq3JrpiuDJcmuj-A4uu8r88Hg@mail.gmail.com>
Message-ID: <CAJgngAeSPbiUj3nKB7njgremHnuUFijaxVhun-NhgD_44dh+Cw@mail.gmail.com>

It's not accurate, but can't find much details on the new bundles. Will
look into it.

On Tue, 5 Feb 2019 at 08:40, Martin Kanis <mkanis at redhat.com> wrote:

> Stian,
>
> one more related thing. Is the "Buying support" paragraph still accurate?
> I think it should refer to Red Hat Application Runtimes bundle.
>
> Martin
>
> On Tue, Feb 5, 2019 at 7:20 AM Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> Fixed. Will be updated in an hour or so when GitHub pages have done its
>> job.
>>
>> On Mon, 4 Feb 2019 at 17:25, Thomas Darimont <
>> thomas.darimont at googlemail.com>
>> wrote:
>>
>> > Hello,
>> >
>> > just noticed that RH-SSO 7.3 (based on Keycloak 4.8.3) was released in
>> > January.
>> >
>> >
>> https://access.redhat.com/documentation/en-us/red_hat_single_sign-on/7.3/html/release_notes/
>> >
>> > I think this info is missing on:
>> > https://www.keycloak.org/support.html
>> >
>> > Cheers,
>> > Thomas
>> > _______________________________________________
>> > 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 ieugen at netdava.com  Tue Feb  5 05:11:51 2019
From: ieugen at netdava.com (Eugen Stan)
Date: Tue, 5 Feb 2019 12:11:51 +0200
Subject: [keycloak-dev] translate keycloak
In-Reply-To: <CAJgngAdMjfhOS3qBf=pKocpAPBxPZ0L_q+Uvw=w-WMxT0N4TfQ@mail.gmail.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>
Message-ID: <0e632a6e-3c74-0392-75df-055bb7c8e54f@netdava.com>

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>> 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>>> 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>>
>     >? ? ?https://lists.jboss.org/mailman/listinfo/keycloak-dev
>     >
>


From pskopek at redhat.com  Tue Feb  5 08:00:31 2019
From: pskopek at redhat.com (Peter Skopek)
Date: Tue, 5 Feb 2019 14:00:31 +0100
Subject: [keycloak-dev] Link to guide for setting up an Eclipse
	Workspace?
In-Reply-To: <CY4PR22MB02481A016339051A9F09FA20986D0@CY4PR22MB0248.namprd22.prod.outlook.com>
References: <CY4PR22MB02481A016339051A9F09FA20986D0@CY4PR22MB0248.namprd22.prod.outlook.com>
Message-ID: <CAM01paYRysV3xNap8xkt3wQrNSo6jAj8=PvymFa5FJya_1Yb7g@mail.gmail.com>

Hi Chris,
not sure if we have something keycloak specific, but this [1] should
work as well.

Peter

[1] https://github.com/wildfly/wildfly/blob/master/README.md#using-eclipse

On Mon, Feb 4, 2019 at 12:33 PM Chris Smith
<chris.smith at cmfirstgroup.com> wrote:
>
> I am embarking on a custom extension.  I've cloned the Git repository and setup the upstream.
>
> I'd like to be sure I'm following project standards in my workspace
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From james.p.campbell at gmail.com  Tue Feb  5 20:27:07 2019
From: james.p.campbell at gmail.com (James Campbell)
Date: Tue, 5 Feb 2019 20:27:07 -0500
Subject: [keycloak-dev] OIDC Discovery-enabled IdentityProvider
In-Reply-To: <CAJgngAf-w-=Pwvu0JLGkAJ0ipPs9v8noPUdbkvsiG52RobKGSA@mail.gmail.com>
References: <00aa01d4ac7b$a7767460$f6635d20$@gmail.com>
	<1914838141.50603473.1547562353763.JavaMail.zimbra@redhat.com>
	<38415268.50625497.1547566301029.JavaMail.zimbra@redhat.com>
	<CA+AQu3yKjkTU2XCaiE1-xbfyn3idiswk5OWSsLxNnZRKsMFJWA@mail.gmail.com>
	<CAJgngAccFbcFOE4Dt4v=R-WXky9mdmGPZqzDvwi3AthrBLOjvQ@mail.gmail.com>
	<CA+AQu3waQr+Zdm1kA_PwoghNfcDzzhttc56saxTEhhxRXwy7Eg@mail.gmail.com>
	<CAJgngAeJn1jSQRk-7yZzaYfDTYE_Ww5pE9MgyumPCkSfYa4tQw@mail.gmail.com>
	<CA+AQu3yuSeN+pOFRwuDR-2CdNvNVPjoHv=xEmTNS5pHHv1qR8Q@mail.gmail.com>
	<CA+AQu3z4JTTSCQU0g9m5VV5SFYUk92-sA1hqT-AedPZRotmcCw@mail.gmail.com>
	<CAJgngAf-w-=Pwvu0JLGkAJ0ipPs9v8noPUdbkvsiG52RobKGSA@mail.gmail.com>
Message-ID: <CA+AQu3zu8KXvtGVJLgHxZ+dno-5f9tBYgd6UU5NJGOXBAZjT=w@mail.gmail.com>

Inline...

On Tue, Feb 5, 2019 at 3:45 AM Stian Thorgersen <sthorger at redhat.com> wrote:

>
>
> On Mon, 4 Feb 2019 at 05:14, James Campbell <james.p.campbell at gmail.com>
> wrote:
>
>> All--
>>
>> Thanks to Stian's recommendations for similar features in the codebase,
>> I've developed a proposal for how to implement this feature, and sketched
>> out an initial implementation. As he suggested, I'd like to get feedback
>> before opening up a PR.
>>
>> 1. We introduce a new subclass of the OIDCIdentityProvider / Factory
>> called OIDCDiscoveryIdentityProvider. The new class adds a discoverConfig
>> method that can be used to discover and set all relevant endpoints in a
>> configuration except the issuer. Issuer then becomes the sole required
>> element of the config. (So the GoogleIdentityProvider, for example, will
>> then just call discoverConfig with its hard-coded issuer).
>>    -> During the parseConfig call, the Factory will raise a
>> RuntimeException if the config cannot be obtained, since if the config can
>> never be obtained there is no way to have a valid configuration at all.
>>    -> During the discoverConfig call, we return the cached value, and
>> optionally refresh it based on when we last obtained the configuration.
>>    -> In the event of a failure in the *refresh* I'm imagining the best
>> behavior is to log a warning but then return the cached config (last known
>> good config).
>>
>
> This should just be added to the OIDCIdentityProvider directly rather than
> a subclass. Perhaps we should have an option to configure how frequently
> the configuration is reloaded.
>

Makes sense, thank you.


>
>> 2. We introduce an SPI and interface called
>> OIDCDiscoveryRepresentationProvider / Factory and implementations called
>> Infinispan... which obtains OIDCConfigurationRepresentations using the
>> /.well-known/openid-configuration endpoint on the issuer.
>>
>> I have a couple questions:
>>
>> 1. I began an implementation of this, but the @JsonProperty annotations
>> on the existing OIDCCOnfigurationRepresentation class seem to be ignored
>> when I try to have it read from the openid-configuration docuement, e.g.:
>>   - OIDCConfigurationRepresentation rep = SimpleHttp.doGet(issuer +
>> "/.well-known/openid-configuration",
>> session).asJson(OIDCConfigurationRepresentation.class); // FAILS with
>> "Unrecognized field ..." Perhaps a mismatch of the jackson annotation
>> version in the keycloak-model-infinispan submodule?
>>
>
> Is the unknown field actually mapped or is the ignore unknown fields
> option enabled? The ignore unknown fields should probably be enabled as
> there may be unknown elements in the config.
>

The unknown field in this case was authorization_endpoint (so yes, mapped,
and in code that I did not change). I wondered whether perhaps the issue is
that I was doing this from inside the keycloak-model-infinispan module, and
a conflicting JSON parser dependency is in play? I did try adding
the @JsonIgnoreProperties annotation as well, to no avail. My suspicion is
just based on (1) the current class correctly supporting deserialization in
existing tests, and (2) a search of common causes for this error (which
I've not encountered before).


>
>
>>
>> 2. Assuming the design above makes sense, what is the right way to plug
>> this into the testing framework? Is one of the core developers interested
>> in tackling that aspect if I push a PR with the above features implemented?
>>
>
> We are very reluctant to receive PRs from the community that do not
> include tests. Think about it, would you as a developer like to implement
> tests for other developers? We can help give you recommendations on how to
> test it though.
>
>

Definitely makes sense; I just didn't see any documentation on the testing
framework at all, whereas there is documentation on the core server
development components. Happy to either take a look at docs you flag, or to
work from any recommendations you have (I certainly wasn't thinking a PR
would be ready without tests!). The current testing system is pretty opaque
to me.



>
>> James
>>
>> On Sun, Jan 27, 2019 at 11:15 AM James Campbell <
>> james.p.campbell at gmail.com> wrote:
>>
>>> Got it; I checked that code out and it does look like a pretty direct
>>> model for the refreshing feature. I'll begin working on a PR.
>>>
>>> On Mon, Jan 21, 2019 at 3:25 AM Stian Thorgersen <sthorger at redhat.com>
>>> wrote:
>>>
>>>> JWKs used by identity brokering and client authentication.
>>>>
>>>> On Sat, 19 Jan 2019 at 23:29, James Campbell <
>>>> james.p.campbell at gmail.com> wrote:
>>>>
>>>>> Stian--
>>>>>
>>>>> Thanks for confirming. Which keys are you referring to--I'll take a
>>>>> look at that in the code and try to follow that pattern closely.
>>>>>
>>>>> James
>>>>>
>>>>> On Wed, Jan 16, 2019 at 1:52 AM Stian Thorgersen <sthorger at redhat.com>
>>>>> wrote:
>>>>>
>>>>>> It would be good to get these changes included. We do something
>>>>>> similar for the keys today and they are cached in an Infinispan local
>>>>>> cache. Could do something similar for the OIDC discovery/config.
>>>>>>
>>>>>> On Tue, 15 Jan 2019 at 17:44, James Campbell <
>>>>>> james.p.campbell at gmail.com> wrote:
>>>>>>
>>>>>>> Tomas--
>>>>>>>
>>>>>>> Thanks--it certainly seems close, you're right! It looks, however
>>>>>>> like an
>>>>>>> OIDC provider still uses a static configuration even though it loads
>>>>>>> it
>>>>>>> from the discovery URL--that is, once it's loaded at configuraiton
>>>>>>> time, it
>>>>>>> doesn't discover new changes, and there isn't an option to
>>>>>>> refresh/store
>>>>>>> that discovery endpoint outside of configuration.
>>>>>>>
>>>>>>> It's not clear to me how important that feature is--on one hand, it
>>>>>>> seems
>>>>>>> unlikely that we should expect frequent changes; on the other, in
>>>>>>> the short
>>>>>>> time since I started exploring this setup, I have encountered three
>>>>>>> changes
>>>>>>> in google's OIDC endpoints between what was hard-coded into
>>>>>>> keycloak, what
>>>>>>> is in their documentation, and what their current discovery endpoint
>>>>>>> provides. (And, the google docs specifically suggest refreshing from
>>>>>>> the
>>>>>>> endpoint periodically).
>>>>>>>
>>>>>>> Thoughts?
>>>>>>>
>>>>>>> James
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Jan 15, 2019 at 10:31 AM Tomas Kyjovsky <tkyjovsk at redhat.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> > Please disregard my previous message.
>>>>>>> >
>>>>>>> > Looking at the docs [1] and the Admin Console UI this should be
>>>>>>> already
>>>>>>> > possible with the OIDC identity provider.
>>>>>>> > When creating a OIDC identity provider in the Admin Console there
>>>>>>> is an
>>>>>>> > option at the bottom of the page to import OIDC configuration
>>>>>>> metadata from
>>>>>>> > URL.
>>>>>>> >
>>>>>>> > Does this cover your use case?
>>>>>>> >
>>>>>>> >
>>>>>>> > Regards,
>>>>>>> > Tomas
>>>>>>> >
>>>>>>> > [1]
>>>>>>> >
>>>>>>> https://www.keycloak.org/docs/latest/server_admin/index.html#openid-connect-v1-0-identity-providers
>>>>>>> >
>>>>>>> >
>>>>>>> > ----- Original Message -----
>>>>>>> > > Hello James,
>>>>>>> > >
>>>>>>> > > See my 2 cents inline..
>>>>>>> > >
>>>>>>> > > ----- Original Message -----
>>>>>>> > > > All--
>>>>>>> > > >
>>>>>>> > > >
>>>>>>> > > >
>>>>>>> > > > After observing that the Google Social Identity Provider in
>>>>>>> Keycloak
>>>>>>> > was
>>>>>>> > > > using a deprecated userprofile endpoint [
>>>>>>> > > > <
>>>>>>> https://issues.jboss.org/projects/KEYCLOAK/issues/KEYCLOAK-9179>
>>>>>>> > > > Keycloak-9179,  <https://issues.jboss.org/browse/KEYCLOAK-9169
>>>>>>> >
>>>>>>> > > > Keycloak-9169], I wanted to propose the creation of an
>>>>>>> IdentityProvider
>>>>>>> > > > that
>>>>>>> > > > will use the OIDC Discovery mechanism to dynamically build a
>>>>>>> config [
>>>>>>> > > > <https://issues.jboss.org/browse/KEYCLOAK-9194>
>>>>>>> Keycloak-9194].
>>>>>>> > > >
>>>>>>> > > >
>>>>>>> > > >
>>>>>>> > > > I see a few decision points along the way that I wanted to ask
>>>>>>> about
>>>>>>> > before
>>>>>>> > > > an implementation, since I'm very new to keycloak and just
>>>>>>> starting to
>>>>>>> > > > understand the codebase. In particular, I wondered if this
>>>>>>> group could
>>>>>>> > > > share
>>>>>>> > > > insight into these couple issues so I can make a more informed
>>>>>>> design:
>>>>>>> > > >
>>>>>>> > > >
>>>>>>> > > >
>>>>>>> > > > 1.    It looks to me like the actual IdentityProviders are
>>>>>>> instantiated
>>>>>>> > > > just
>>>>>>> > > > as they're being used, but that the models are persisted in the
>>>>>>> > RealmModel.
>>>>>>> > > > It's not clear to me where the separation of concerns is
>>>>>>> supposed to be
>>>>>>> > > > between the IdentityProvider and the IdentityProviderModel-in
>>>>>>> > particular
>>>>>>> > > > since the GoogeIdentityProvider, say, immediately sets
>>>>>>> endpoints in its
>>>>>>> > > > constructor. Normatively, where *should* social identity
>>>>>>> providers'
>>>>>>> > model
>>>>>>> > > > configuration be set (and, e.g., where are the models first
>>>>>>> added to
>>>>>>> > the
>>>>>>> > > > RealmModel)?
>>>>>>> > >
>>>>>>> > > Provider classes are being instantiated per transaction by their
>>>>>>> > > corresponding ProviderFactories and then left to be
>>>>>>> garbage-collected
>>>>>>> > after
>>>>>>> > > Provider.close() is called.
>>>>>>> > > The Provider class is given its configuration
>>>>>>> (IdentityProviderModel in
>>>>>>> > this
>>>>>>> > > case) by its factory which I believe loads it from cache/jpa
>>>>>>> layer. Any
>>>>>>> > > class extending AbstractIdentityProvider should then be able to
>>>>>>> access
>>>>>>> > its
>>>>>>> > > config via getConfig() method but I don't think it will be able
>>>>>>> to
>>>>>>> > > update/persist it back. The provider configuration/model itself
>>>>>>> is
>>>>>>> > managed
>>>>>>> > > by the IdentityProviderResource (REST endpoint accessible via
>>>>>>> REST or
>>>>>>> > admin
>>>>>>> > > console UI) in the keycloak/services module so I think the
>>>>>>> > > auto-configuration logic would have to be placed somewhere there.
>>>>>>> > >
>>>>>>> > > >
>>>>>>> > > >
>>>>>>> > > >
>>>>>>> > > > 2.    I see that there is logic to parse OIDC Discovery
>>>>>>> configuration
>>>>>>> > as
>>>>>>> > > > part of configuring Keycloak itself as an OIDC provider /
>>>>>>> implementer
>>>>>>> > of
>>>>>>> > > > OIDC protocol (including building and parsing the .well-known
>>>>>>> config
>>>>>>> > > > elements), but that logic seems not to be used in any setting
>>>>>>> > currently as
>>>>>>> > > > a
>>>>>>> > > > client. Should I plan to reuse, say, the
>>>>>>> > OIDCConfigurationRepresentation
>>>>>>> > > > and
>>>>>>> > > > OIDCWellKnownProvider classes for their logic in handling such
>>>>>>> configs?
>>>>>>> > > >
>>>>>>> > > >
>>>>>>> > > >
>>>>>>> > > >
>>>>>>> > > >
>>>>>>> > > > Currently, I'm imagining something along the lines of extending
>>>>>>> > > > OIDCIdentityProvider with a new OIDCDiscoveryIdentityProvider
>>>>>>> that
>>>>>>> > adds a
>>>>>>> > > > discoverConfig method which can be used by an implementing
>>>>>>> class (such
>>>>>>> > as
>>>>>>> > > > GoogleIdentityProvider) to discover and cache endpoints such
>>>>>>> that they
>>>>>>> > are
>>>>>>> > > > not hard-coded into the implementing class. Each implementing
>>>>>>> class
>>>>>>> > would
>>>>>>> > > > then have a public static final DISCOVERY_URL that it passes to
>>>>>>> > > > discoverConfig.
>>>>>>> > > >
>>>>>>> > > >
>>>>>>> > > >
>>>>>>> > > > My main hangup, as suggested above, is that to implement the
>>>>>>> caching, I
>>>>>>> > > > want
>>>>>>> > > > to ensure that the model configuration is stored/set in the
>>>>>>> right
>>>>>>> > place.
>>>>>>> > > >
>>>>>>> > > >
>>>>>>> > > >
>>>>>>> > > > Thanks for bearing with me as I come up to speed on this!
>>>>>>> > > >
>>>>>>> > > >
>>>>>>> > > >
>>>>>>> > > > James
>>>>>>> > > >
>>>>>>> > > > _______________________________________________
>>>>>>> > > > keycloak-dev mailing list
>>>>>>> > > > keycloak-dev at lists.jboss.org
>>>>>>> > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>> > > >
>>>>>>> > >
>>>>>>> > >
>>>>>>> > > Regards,
>>>>>>> > > Tomas
>>>>>>> > >
>>>>>>> >
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> -... . / - .-. ..- . .-.-.- / -... . / .--. .-. . ... . -. - .-.-.-
>>>>>>> / -...
>>>>>>> . / ..-. .. -
>>>>>>> 07:d0:2d:0b:d6:9d:27:c6:a7:c1:ec:e3:b1:65:f4:70
>>>>>>> _______________________________________________
>>>>>>> keycloak-dev mailing list
>>>>>>> keycloak-dev at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> -... . / - .-. ..- . .-.-.- / -... . / .--. .-. . ... . -. - .-.-.- /
>>>>> -... . / ..-. .. -
>>>>> 07:d0:2d:0b:d6:9d:27:c6:a7:c1:ec:e3:b1:65:f4:70
>>>>>
>>>>
>>>
>>> --
>>> -... . / - .-. ..- . .-.-.- / -... . / .--. .-. . ... . -. - .-.-.- /
>>> -... . / ..-. .. -
>>> 07:d0:2d:0b:d6:9d:27:c6:a7:c1:ec:e3:b1:65:f4:70
>>>
>>
>>
>> --
>> -... . / - .-. ..- . .-.-.- / -... . / .--. .-. . ... . -. - .-.-.- /
>> -... . / ..-. .. -
>> 07:d0:2d:0b:d6:9d:27:c6:a7:c1:ec:e3:b1:65:f4:70
>>
>

-- 
-... . / - .-. ..- . .-.-.- / -... . / .--. .-. . ... . -. - .-.-.- / -...
. / ..-. .. -
07:d0:2d:0b:d6:9d:27:c6:a7:c1:ec:e3:b1:65:f4:70

From sthorger at redhat.com  Wed Feb  6 05:30:31 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 6 Feb 2019 11:30:31 +0100
Subject: [keycloak-dev] OIDC Discovery-enabled IdentityProvider
In-Reply-To: <CA+AQu3zu8KXvtGVJLgHxZ+dno-5f9tBYgd6UU5NJGOXBAZjT=w@mail.gmail.com>
References: <00aa01d4ac7b$a7767460$f6635d20$@gmail.com>
	<1914838141.50603473.1547562353763.JavaMail.zimbra@redhat.com>
	<38415268.50625497.1547566301029.JavaMail.zimbra@redhat.com>
	<CA+AQu3yKjkTU2XCaiE1-xbfyn3idiswk5OWSsLxNnZRKsMFJWA@mail.gmail.com>
	<CAJgngAccFbcFOE4Dt4v=R-WXky9mdmGPZqzDvwi3AthrBLOjvQ@mail.gmail.com>
	<CA+AQu3waQr+Zdm1kA_PwoghNfcDzzhttc56saxTEhhxRXwy7Eg@mail.gmail.com>
	<CAJgngAeJn1jSQRk-7yZzaYfDTYE_Ww5pE9MgyumPCkSfYa4tQw@mail.gmail.com>
	<CA+AQu3yuSeN+pOFRwuDR-2CdNvNVPjoHv=xEmTNS5pHHv1qR8Q@mail.gmail.com>
	<CA+AQu3z4JTTSCQU0g9m5VV5SFYUk92-sA1hqT-AedPZRotmcCw@mail.gmail.com>
	<CAJgngAf-w-=Pwvu0JLGkAJ0ipPs9v8noPUdbkvsiG52RobKGSA@mail.gmail.com>
	<CA+AQu3zu8KXvtGVJLgHxZ+dno-5f9tBYgd6UU5NJGOXBAZjT=w@mail.gmail.com>
Message-ID: <CAJgngAdyEzhrx5Zk9DQH6Gd5xwjTxkGaP2WaZGmmEmCUj5jC=A@mail.gmail.com>

On Wed, 6 Feb 2019 at 02:27, James Campbell <james.p.campbell at gmail.com>
wrote:

> Inline...
>
> On Tue, Feb 5, 2019 at 3:45 AM Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>>
>>
>> On Mon, 4 Feb 2019 at 05:14, James Campbell <james.p.campbell at gmail.com>
>> wrote:
>>
>>> All--
>>>
>>> Thanks to Stian's recommendations for similar features in the codebase,
>>> I've developed a proposal for how to implement this feature, and sketched
>>> out an initial implementation. As he suggested, I'd like to get feedback
>>> before opening up a PR.
>>>
>>> 1. We introduce a new subclass of the OIDCIdentityProvider / Factory
>>> called OIDCDiscoveryIdentityProvider. The new class adds a discoverConfig
>>> method that can be used to discover and set all relevant endpoints in a
>>> configuration except the issuer. Issuer then becomes the sole required
>>> element of the config. (So the GoogleIdentityProvider, for example, will
>>> then just call discoverConfig with its hard-coded issuer).
>>>    -> During the parseConfig call, the Factory will raise a
>>> RuntimeException if the config cannot be obtained, since if the config can
>>> never be obtained there is no way to have a valid configuration at all.
>>>    -> During the discoverConfig call, we return the cached value, and
>>> optionally refresh it based on when we last obtained the configuration.
>>>    -> In the event of a failure in the *refresh* I'm imagining the best
>>> behavior is to log a warning but then return the cached config (last known
>>> good config).
>>>
>>
>> This should just be added to the OIDCIdentityProvider directly rather
>> than a subclass. Perhaps we should have an option to configure how
>> frequently the configuration is reloaded.
>>
>
> Makes sense, thank you.
>
>
>>
>>> 2. We introduce an SPI and interface called
>>> OIDCDiscoveryRepresentationProvider / Factory and implementations called
>>> Infinispan... which obtains OIDCConfigurationRepresentations using the
>>> /.well-known/openid-configuration endpoint on the issuer.
>>>
>>> I have a couple questions:
>>>
>>> 1. I began an implementation of this, but the @JsonProperty annotations
>>> on the existing OIDCCOnfigurationRepresentation class seem to be ignored
>>> when I try to have it read from the openid-configuration docuement, e.g.:
>>>   - OIDCConfigurationRepresentation rep = SimpleHttp.doGet(issuer +
>>> "/.well-known/openid-configuration",
>>> session).asJson(OIDCConfigurationRepresentation.class); // FAILS with
>>> "Unrecognized field ..." Perhaps a mismatch of the jackson annotation
>>> version in the keycloak-model-infinispan submodule?
>>>
>>
>> Is the unknown field actually mapped or is the ignore unknown fields
>> option enabled? The ignore unknown fields should probably be enabled as
>> there may be unknown elements in the config.
>>
>
> The unknown field in this case was authorization_endpoint (so yes, mapped,
> and in code that I did not change). I wondered whether perhaps the issue is
> that I was doing this from inside the keycloak-model-infinispan module, and
> a conflicting JSON parser dependency is in play? I did try adding
> the @JsonIgnoreProperties annotation as well, to no avail. My suspicion is
> just based on (1) the current class correctly supporting deserialization in
> existing tests, and (2) a search of common causes for this error (which
> I've not encountered before).
>

Is this from unit tests within the keycloak-model-infinispan module or test
in the Arquillian testsuite? If the latter it should pick up the correct
serializer. It has to be the fasterxml one otherwise the annotations will
be ignored.


>
>
>>
>>
>>>
>>> 2. Assuming the design above makes sense, what is the right way to plug
>>> this into the testing framework? Is one of the core developers interested
>>> in tackling that aspect if I push a PR with the above features implemented?
>>>
>>
>> We are very reluctant to receive PRs from the community that do not
>> include tests. Think about it, would you as a developer like to implement
>> tests for other developers? We can help give you recommendations on how to
>> test it though.
>>
>>
>
> Definitely makes sense; I just didn't see any documentation on the testing
> framework at all, whereas there is documentation on the core server
> development components. Happy to either take a look at docs you flag, or to
> work from any recommendations you have (I certainly wasn't thinking a PR
> would be ready without tests!). The current testing system is pretty opaque
> to me.
>

We have an Arquillian based testsuite that allows us to write functional
tests with all the benefits of unit tests. The testsuite allows running
tests from within the IDE (uses Keycloak with an embedded Undertow server)
and also run them against a proper built Keycloak on top of WildFly from
the command line.

Some details are here:
https://github.com/keycloak/keycloak/tree/master/testsuite/integration-arquillian

To understand how to write the tests and run them try to run any test
inside testsuite/integration-arquillian/tests/base/src/test from the IDE.

Identity brokering tests are under
testsuite/integration-arquillian/tests/base/src/test/java/org/keycloak/testsuite/broker.
You should be able to relatively easily extend these tests to include
testing of OIDC well-known endpoints. We also have support in the testsuite
to run code directly on the server (embedded or external) to be able to
probe inside the server if needed. Take a look at
https://github.com/keycloak/keycloak/blob/master/testsuite/integration-arquillian/tests/base/src/test/java/org/keycloak/testsuite/runonserver/RunOnServerTest.java
as an example on how to do that.



>
>
>
>>
>>> James
>>>
>>> On Sun, Jan 27, 2019 at 11:15 AM James Campbell <
>>> james.p.campbell at gmail.com> wrote:
>>>
>>>> Got it; I checked that code out and it does look like a pretty direct
>>>> model for the refreshing feature. I'll begin working on a PR.
>>>>
>>>> On Mon, Jan 21, 2019 at 3:25 AM Stian Thorgersen <sthorger at redhat.com>
>>>> wrote:
>>>>
>>>>> JWKs used by identity brokering and client authentication.
>>>>>
>>>>> On Sat, 19 Jan 2019 at 23:29, James Campbell <
>>>>> james.p.campbell at gmail.com> wrote:
>>>>>
>>>>>> Stian--
>>>>>>
>>>>>> Thanks for confirming. Which keys are you referring to--I'll take a
>>>>>> look at that in the code and try to follow that pattern closely.
>>>>>>
>>>>>> James
>>>>>>
>>>>>> On Wed, Jan 16, 2019 at 1:52 AM Stian Thorgersen <sthorger at redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>>> It would be good to get these changes included. We do something
>>>>>>> similar for the keys today and they are cached in an Infinispan local
>>>>>>> cache. Could do something similar for the OIDC discovery/config.
>>>>>>>
>>>>>>> On Tue, 15 Jan 2019 at 17:44, James Campbell <
>>>>>>> james.p.campbell at gmail.com> wrote:
>>>>>>>
>>>>>>>> Tomas--
>>>>>>>>
>>>>>>>> Thanks--it certainly seems close, you're right! It looks, however
>>>>>>>> like an
>>>>>>>> OIDC provider still uses a static configuration even though it
>>>>>>>> loads it
>>>>>>>> from the discovery URL--that is, once it's loaded at configuraiton
>>>>>>>> time, it
>>>>>>>> doesn't discover new changes, and there isn't an option to
>>>>>>>> refresh/store
>>>>>>>> that discovery endpoint outside of configuration.
>>>>>>>>
>>>>>>>> It's not clear to me how important that feature is--on one hand, it
>>>>>>>> seems
>>>>>>>> unlikely that we should expect frequent changes; on the other, in
>>>>>>>> the short
>>>>>>>> time since I started exploring this setup, I have encountered three
>>>>>>>> changes
>>>>>>>> in google's OIDC endpoints between what was hard-coded into
>>>>>>>> keycloak, what
>>>>>>>> is in their documentation, and what their current discovery endpoint
>>>>>>>> provides. (And, the google docs specifically suggest refreshing
>>>>>>>> from the
>>>>>>>> endpoint periodically).
>>>>>>>>
>>>>>>>> Thoughts?
>>>>>>>>
>>>>>>>> James
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Jan 15, 2019 at 10:31 AM Tomas Kyjovsky <
>>>>>>>> tkyjovsk at redhat.com> wrote:
>>>>>>>>
>>>>>>>> > Please disregard my previous message.
>>>>>>>> >
>>>>>>>> > Looking at the docs [1] and the Admin Console UI this should be
>>>>>>>> already
>>>>>>>> > possible with the OIDC identity provider.
>>>>>>>> > When creating a OIDC identity provider in the Admin Console there
>>>>>>>> is an
>>>>>>>> > option at the bottom of the page to import OIDC configuration
>>>>>>>> metadata from
>>>>>>>> > URL.
>>>>>>>> >
>>>>>>>> > Does this cover your use case?
>>>>>>>> >
>>>>>>>> >
>>>>>>>> > Regards,
>>>>>>>> > Tomas
>>>>>>>> >
>>>>>>>> > [1]
>>>>>>>> >
>>>>>>>> https://www.keycloak.org/docs/latest/server_admin/index.html#openid-connect-v1-0-identity-providers
>>>>>>>> >
>>>>>>>> >
>>>>>>>> > ----- Original Message -----
>>>>>>>> > > Hello James,
>>>>>>>> > >
>>>>>>>> > > See my 2 cents inline..
>>>>>>>> > >
>>>>>>>> > > ----- Original Message -----
>>>>>>>> > > > All--
>>>>>>>> > > >
>>>>>>>> > > >
>>>>>>>> > > >
>>>>>>>> > > > After observing that the Google Social Identity Provider in
>>>>>>>> Keycloak
>>>>>>>> > was
>>>>>>>> > > > using a deprecated userprofile endpoint [
>>>>>>>> > > > <
>>>>>>>> https://issues.jboss.org/projects/KEYCLOAK/issues/KEYCLOAK-9179>
>>>>>>>> > > > Keycloak-9179,  <
>>>>>>>> https://issues.jboss.org/browse/KEYCLOAK-9169>
>>>>>>>> > > > Keycloak-9169], I wanted to propose the creation of an
>>>>>>>> IdentityProvider
>>>>>>>> > > > that
>>>>>>>> > > > will use the OIDC Discovery mechanism to dynamically build a
>>>>>>>> config [
>>>>>>>> > > > <https://issues.jboss.org/browse/KEYCLOAK-9194>
>>>>>>>> Keycloak-9194].
>>>>>>>> > > >
>>>>>>>> > > >
>>>>>>>> > > >
>>>>>>>> > > > I see a few decision points along the way that I wanted to
>>>>>>>> ask about
>>>>>>>> > before
>>>>>>>> > > > an implementation, since I'm very new to keycloak and just
>>>>>>>> starting to
>>>>>>>> > > > understand the codebase. In particular, I wondered if this
>>>>>>>> group could
>>>>>>>> > > > share
>>>>>>>> > > > insight into these couple issues so I can make a more
>>>>>>>> informed design:
>>>>>>>> > > >
>>>>>>>> > > >
>>>>>>>> > > >
>>>>>>>> > > > 1.    It looks to me like the actual IdentityProviders are
>>>>>>>> instantiated
>>>>>>>> > > > just
>>>>>>>> > > > as they're being used, but that the models are persisted in
>>>>>>>> the
>>>>>>>> > RealmModel.
>>>>>>>> > > > It's not clear to me where the separation of concerns is
>>>>>>>> supposed to be
>>>>>>>> > > > between the IdentityProvider and the IdentityProviderModel-in
>>>>>>>> > particular
>>>>>>>> > > > since the GoogeIdentityProvider, say, immediately sets
>>>>>>>> endpoints in its
>>>>>>>> > > > constructor. Normatively, where *should* social identity
>>>>>>>> providers'
>>>>>>>> > model
>>>>>>>> > > > configuration be set (and, e.g., where are the models first
>>>>>>>> added to
>>>>>>>> > the
>>>>>>>> > > > RealmModel)?
>>>>>>>> > >
>>>>>>>> > > Provider classes are being instantiated per transaction by their
>>>>>>>> > > corresponding ProviderFactories and then left to be
>>>>>>>> garbage-collected
>>>>>>>> > after
>>>>>>>> > > Provider.close() is called.
>>>>>>>> > > The Provider class is given its configuration
>>>>>>>> (IdentityProviderModel in
>>>>>>>> > this
>>>>>>>> > > case) by its factory which I believe loads it from cache/jpa
>>>>>>>> layer. Any
>>>>>>>> > > class extending AbstractIdentityProvider should then be able to
>>>>>>>> access
>>>>>>>> > its
>>>>>>>> > > config via getConfig() method but I don't think it will be able
>>>>>>>> to
>>>>>>>> > > update/persist it back. The provider configuration/model itself
>>>>>>>> is
>>>>>>>> > managed
>>>>>>>> > > by the IdentityProviderResource (REST endpoint accessible via
>>>>>>>> REST or
>>>>>>>> > admin
>>>>>>>> > > console UI) in the keycloak/services module so I think the
>>>>>>>> > > auto-configuration logic would have to be placed somewhere
>>>>>>>> there.
>>>>>>>> > >
>>>>>>>> > > >
>>>>>>>> > > >
>>>>>>>> > > >
>>>>>>>> > > > 2.    I see that there is logic to parse OIDC Discovery
>>>>>>>> configuration
>>>>>>>> > as
>>>>>>>> > > > part of configuring Keycloak itself as an OIDC provider /
>>>>>>>> implementer
>>>>>>>> > of
>>>>>>>> > > > OIDC protocol (including building and parsing the .well-known
>>>>>>>> config
>>>>>>>> > > > elements), but that logic seems not to be used in any setting
>>>>>>>> > currently as
>>>>>>>> > > > a
>>>>>>>> > > > client. Should I plan to reuse, say, the
>>>>>>>> > OIDCConfigurationRepresentation
>>>>>>>> > > > and
>>>>>>>> > > > OIDCWellKnownProvider classes for their logic in handling
>>>>>>>> such configs?
>>>>>>>> > > >
>>>>>>>> > > >
>>>>>>>> > > >
>>>>>>>> > > >
>>>>>>>> > > >
>>>>>>>> > > > Currently, I'm imagining something along the lines of
>>>>>>>> extending
>>>>>>>> > > > OIDCIdentityProvider with a new OIDCDiscoveryIdentityProvider
>>>>>>>> that
>>>>>>>> > adds a
>>>>>>>> > > > discoverConfig method which can be used by an implementing
>>>>>>>> class (such
>>>>>>>> > as
>>>>>>>> > > > GoogleIdentityProvider) to discover and cache endpoints such
>>>>>>>> that they
>>>>>>>> > are
>>>>>>>> > > > not hard-coded into the implementing class. Each implementing
>>>>>>>> class
>>>>>>>> > would
>>>>>>>> > > > then have a public static final DISCOVERY_URL that it passes
>>>>>>>> to
>>>>>>>> > > > discoverConfig.
>>>>>>>> > > >
>>>>>>>> > > >
>>>>>>>> > > >
>>>>>>>> > > > My main hangup, as suggested above, is that to implement the
>>>>>>>> caching, I
>>>>>>>> > > > want
>>>>>>>> > > > to ensure that the model configuration is stored/set in the
>>>>>>>> right
>>>>>>>> > place.
>>>>>>>> > > >
>>>>>>>> > > >
>>>>>>>> > > >
>>>>>>>> > > > Thanks for bearing with me as I come up to speed on this!
>>>>>>>> > > >
>>>>>>>> > > >
>>>>>>>> > > >
>>>>>>>> > > > James
>>>>>>>> > > >
>>>>>>>> > > > _______________________________________________
>>>>>>>> > > > keycloak-dev mailing list
>>>>>>>> > > > keycloak-dev at lists.jboss.org
>>>>>>>> > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>> > > >
>>>>>>>> > >
>>>>>>>> > >
>>>>>>>> > > Regards,
>>>>>>>> > > Tomas
>>>>>>>> > >
>>>>>>>> >
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> -... . / - .-. ..- . .-.-.- / -... . / .--. .-. . ... . -. - .-.-.-
>>>>>>>> / -...
>>>>>>>> . / ..-. .. -
>>>>>>>> 07:d0:2d:0b:d6:9d:27:c6:a7:c1:ec:e3:b1:65:f4:70
>>>>>>>> _______________________________________________
>>>>>>>> keycloak-dev mailing list
>>>>>>>> keycloak-dev at lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> -... . / - .-. ..- . .-.-.- / -... . / .--. .-. . ... . -. - .-.-.- /
>>>>>> -... . / ..-. .. -
>>>>>> 07:d0:2d:0b:d6:9d:27:c6:a7:c1:ec:e3:b1:65:f4:70
>>>>>>
>>>>>
>>>>
>>>> --
>>>> -... . / - .-. ..- . .-.-.- / -... . / .--. .-. . ... . -. - .-.-.- /
>>>> -... . / ..-. .. -
>>>> 07:d0:2d:0b:d6:9d:27:c6:a7:c1:ec:e3:b1:65:f4:70
>>>>
>>>
>>>
>>> --
>>> -... . / - .-. ..- . .-.-.- / -... . / .--. .-. . ... . -. - .-.-.- /
>>> -... . / ..-. .. -
>>> 07:d0:2d:0b:d6:9d:27:c6:a7:c1:ec:e3:b1:65:f4:70
>>>
>>
>
> --
> -... . / - .-. ..- . .-.-.- / -... . / .--. .-. . ... . -. - .-.-.- / -...
> . / ..-. .. -
> 07:d0:2d:0b:d6:9d:27:c6:a7:c1:ec:e3:b1:65:f4:70
>

From cristianomarquesadm02 at gmail.com  Wed Feb  6 05:32:22 2019
From: cristianomarquesadm02 at gmail.com (Cristiano Marques)
Date: Wed, 6 Feb 2019 08:32:22 -0200
Subject: [keycloak-dev] help to personaling Keycloark
Message-ID: <CAAYRsuCq06T8syhJtJAYcvZNkp=rnd4e_fnHk5OSdatDi=oUyQ@mail.gmail.com>

hi, i need help to questions about Keycloark and also personaling Keycloak.
Thanks fo attention
Cristiano Marques dos Santos

From mposolda at redhat.com  Wed Feb  6 05:53:22 2019
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 6 Feb 2019 11:53:22 +0100
Subject: [keycloak-dev] Better support for "scope" in adapters
In-Reply-To: <CAJgngAcRDk3omuu7TVZQC52Os1dB-_tnYyjawZS5bAFYKGjD0g@mail.gmail.com>
References: <3030a267-b2b6-7a76-3020-42959ef344c5@redhat.com>
	<CAJrcDBep7ScX4O7G5fSh5oPhsbT9B5-ekqhF01MKiikZXB9ywg@mail.gmail.com>
	<e01a6dc8-3163-f132-835b-713b8cfdfc62@redhat.com>
	<CAJrcDBfNE8_8wSDCSrhvcnDa80w1=q=Ngm8wOae5pi9YERKqig@mail.gmail.com>
	<a57ed42b-3f80-21e2-f4e6-7f434030bef4@redhat.com>
	<CAJrcDBcUuiuD4sm5UaXh-BTy70mf+ipR10oHFq08jTS7ntxeUQ@mail.gmail.com>
	<27b5cb1e-cbc0-e79d-03f8-2203cddcf9e3@redhat.com>
	<CAJrcDBcyu+OD4KH0NZ1C=Z81bi+s7GtaTE+Fv8zNSCyOSWLU7A@mail.gmail.com>
	<CAJgngAcRDk3omuu7TVZQC52Os1dB-_tnYyjawZS5bAFYKGjD0g@mail.gmail.com>
Message-ID: <5f9ca2cf-ef26-87ad-4d54-b00ec695baf5@redhat.com>

On 05/02/2019 09:39, Stian Thorgersen wrote:
> Tried to filter out implementation details here, so may have lost some 
> details. It would be good if we can try to keep discussions at a 
> higher level at least initially as it makes it much easier to follow 
> the discussion.
Point taken :) Will try to improve next time.
>
> For scopes I can see the most common use-case will be the ability to 
> do incremental scopes. By that I mean the application doesn't request 
> all permissions it may need, but rather starts small and asks for more 
> as the user extends use of the application. This is mostly relevant to 
> applications that require consent.
>
> Now with regards to the application being able to have different 
> tokens to invoke different services I'm not convinced this is needed 
> so we should rather wait for demand here. There's two ways a single 
> app can consume multiple services:
>
> 1) Application directly invokes multiple services - in this case the 
> application should be able to use scopes or token exchange to obtain 
> tokens to invoke different services. In fact I'd say token exchange is 
> probably what is wanted here rather than scopes.
> 2) Application invokes a backend service that aggregates multiple 
> services - in this case token exchange comes in as the backend service 
> needs to be able to obtain tokens to invoke the different services
>
> I would think option 2 is the best approach as it allows implementing 
> the complex code in server side code and also makes the application 
> more transparent to API changes.
This seems to be inline with what Pedro mentioned as well. +1 for 
waiting for a demand for this.
>
> With regards to incremental scope support we need to be able to do 
> that without requiring logout. For JS adapter that should already 
> work, but it has one issue and that is you can't set the scope to use 
> with automated login. We should probably make the scope configurable 
> in the init function as well as when invoking login function directly. 
> For servlet we should probably also have a way to configure the 
> initial scope and expose a method to obtain additional scopes without 
> requiring logout.

+1

Regarding JS adapter, there are few other things, which you can't do at 
"init" method. For example adding the "prompt" . Maybe all the current 
options of "login" method can be just used as arguments to "init" method?

For the servlet adapter, it will be probably good to have something like 
JS adapter "keycloak.login" method or "keycloak.createLoginUrl", which 
allows to add things like custom scope, prompt etc. I proposed something 
like KeycloakLoginUrlBuilder, which will allow to easy add things like 
"scope" or "prompt" in the adapters code.

>
> I'm not convinced about client scope inheritance. It has an additional 
> implementation complexity, but most importantly usability with regards 
> to understand what is actually included in the token when you have 
> inheritance. It may also have some strange side-effects like how do 
> you make sure the order of what is applied is correct. Again, probably 
> something best left until there is demand for it.

We already have "priority" on protocolMappers, so ordering likely won't 
be an issue. You can add protocolMappers of all the "effective" client 
scopes and sort the protocol mappers. But agree that will be good to 
wait for more demand before adding this.

Marek

> On Thu, 31 Jan 2019 at 17:04, Pedro Igor Silva <psilva at redhat.com 
> <mailto:psilva at redhat.com>> wrote:
>
>     +1
>
>     On Thu, Jan 31, 2019 at 11:14 AM Marek Posolda
>     <mposolda at redhat.com <mailto:mposolda at redhat.com>> wrote:
>
>     > On 31/01/2019 14:07, Pedro Igor Silva wrote:
>     >
>     > This what I like most about client scopes (in addition to all
>     mapping you
>     > do to claims in the tokens) :) Would also make sense to do the
>     same thing
>     > to client scopes ? So clients requesting "foo" would also get
>     "bar" and
>     > "xpto", for instance ?
>     >
>     > Maybe this could avoid the client to request 10 scopes but just
>     a more
>     > coarse-grained scope representing all of them.
>     >
>     > There is opened JIRA for client scopes inheritance
>     > https://issues.jboss.org/browse/KEYCLOAK-6633 . I believe this
>     will cover
>     > what you have in mind? It's just not yet done...
>     >
>     > Marek
>     >
>     >
>     >
>     > On Thu, Jan 31, 2019 at 10:43 AM Marek Posolda
>     <mposolda at redhat.com <mailto:mposolda at redhat.com>>
>     > wrote:
>     >
>     >> On 30/01/2019 14:40, Pedro Igor Silva wrote:
>     >>
>     >>
>     >>
>     >> On Wed, Jan 30, 2019 at 5:25 AM Marek Posolda
>     <mposolda at redhat.com <mailto:mposolda at redhat.com>>
>     >> wrote:
>     >>
>     >>> On 29/01/2019 19:49, Pedro Igor Silva wrote:
>     >>>
>     >>> I'm not sure if we need to consider that in our adapters.
>     >>>
>     >>> Usually, the front-end knows the set of scopes that it needs
>     to interact
>     >>> with the backend and stay functional.
>     >>>
>     >>> Maybe. I am personally not sure how people expect to use "scope"
>     >>> parameters in their frontend applications. Maybe 90% of
>     frontend clients
>     >>> don't need to use "scope" parameter at all. And from the
>     remaining, they
>     >>> will be fine with the current support of the "scope" parameter.
>     >>>
>     >> I would say so, mainly because I think people are still using
>     RBAC to
>     >> enforce access to APIs. Enterprise scenarios don't really use
>     scopes as
>     >> they are more related with delegation.
>     >>
>     >> Yeah, maybe. Just a note that our client scopes support also
>     allows to
>     >> limit roles in the token. For example you can define role scope
>     mappings of
>     >> client scope "service1" to have role
>     "service1.my-service1-role" . So by
>     >> requesting "scope=service1", you will also receive this role in
>     the token
>     >> and hence can be used for RBAC based authorization.
>     >>
>     >> But anyway, I probably won't create any JIRAs for now. Will
>     wait if there
>     >> is some more feedback or some more requests for better support
>     of "scope"
>     >> parameter in the adapters.
>     >>
>     >> Thanks for the feedback Pedro!
>     >>
>     >> Marek
>     >>
>     >> One possibility, where I can see usage of this, is when
>     frontend client
>     >>> wants to invoke multiple different services and he wants to
>     use different
>     >>> access tokens with properly "isolated" audiences. So for
>     example you want
>     >>> to have:
>     >>>
>     >>> - access token with "scope=service1", which will have in
>     itself audience
>     >>> claim "aud: service1" and you will use it to invoke backend
>     service1
>     >>> - access token with "scope=service2", which will have in
>     itself audience
>     >>> claim "aud: service2" and you will use it to invoke backend
>     service2
>     >>>
>     >>> In this case, having the possibility for adapters to "cache"
>     multiple
>     >>> tokens for various scopes can be beneficial IMO, so client can
>     easily
>     >>> retrieve proper access token based on the service he wants to
>     invoke.
>     >>>
>     >>> And the backend by itself is free to exchange tokens to call other
>     >>> services (service chaining).
>     >>>
>     >>> Don't think that brings a lot of complexity to the front-end and,
>     >> probably, indicates a bad design?
>     >>
>     >>> IMO in many cases, you're right. For example when frontend
>     client uses
>     >>> access token to invoke backend "service1", this backend may
>     want to
>     >>> retrieve some other data from "service11". So service1 backend
>     needs to
>     >>> reuse the token or he wants to exchange this token.
>     >>>
>     >>> But in many cases, you want to avoid this. So in my example
>     above, when
>     >>> you have access token with "aud: service1", you want this
>     access token to
>     >>> be used solely to invoke service1. You don't want to have one
>     huge access
>     >>> token, which will have all the audiences like:
>     >>>
>     >>> aud: [ "service1", "service2" ]
>     >>>
>     >> The access token is also tied with the client, what means "this
>     client is
>     >> allowed to invoke service1 and service2". I usually don't see a
>     problem on
>     >> that if you consider that multiple audiences mean that a high
>     degree of
>     >> trust between the parties involved. What I think is true for most
>     >> enterprise use cases where the front-end is basically accessing
>     internal
>     >> services.
>     >>
>     >> It is also worthy to consider, IMO, that the fact that you have
>     distinct
>     >> services, does not mean they are not part of the same API, thus
>     the same
>     >> audience.
>     >>
>     >>> You may want separate access tokens with isolated audiences
>     exactly
>     >>> because you don't want service1 and service2 to be able to
>     invoke each
>     >>> other. IMO this isolation is one of the main usages of the
>     "aud" claim in
>     >>> the tokens.
>     >>>
>     >>>
>     >>> One thing that makes sense though is "incremental
>     authorization" and
>     >>> allow apps to request additional scopes during an
>     authentication session,
>     >>> so the app gets what was previously granted and the new scopes
>     (depending
>     >>> on user consent). But I think we support that already, right ?
>     >>>
>     >>> We don't support it directly and maybe this is something to
>     improve. ATM
>     >>> you will need programatically do something like this:
>     >>>
>     >>> String existingScope = existingAccessToken.getScope();
>     >>>
>     >>> // I want to use existingScope and add "phone" scope to it
>     >>> String newScope = existingScope + " phone";
>     >>>
>     >>> // Request the login for new scope now
>     >>>
>     >>>
>     >>> The part of "requesting login for new scope" is possible with
>     javascript
>     >>> adapter, but not easily with the "java" adapter. With java
>     adapter, there
>     >>> is no easy way to manually "build" URL to sent to OIDC
>     authentication
>     >>> endpoint (equivalent of keycloak.js method "createLoginUrl").
>     That's also
>     >>> one of the things, which I proposed to improve in this email
>     thread.
>     >>>
>     >> Marek
>     >>>
>     >>>
>     >>> Regards.
>     >>> Pedro Igor
>     >>>
>     >>> On Tue, Jan 29, 2019 at 9:36 AM Marek Posolda
>     <mposolda at redhat.com <mailto:mposolda at redhat.com>>
>     >>> wrote:
>     >>>
>     >>>> During my work on Client Scopes last year, I did not any work
>     on the
>     >>>> adapters side. I think there is a space for improvement here.
>     I will
>     >>>> try
>     >>>> to summary current issues and some initial proposals for improve
>     >>>> things.
>     >>>> Suggestions welcomed! And sorry for longer email :)
>     >>>>
>     >>>>
>     >>>> Both javascript adapter and servlet adapter has some way for
>     requesting
>     >>>> the additional "scope" and ensure that that initial OIDC
>     authentication
>     >>>> request sent to Keycloak will contain some custom "scope"
>     parameter.
>     >>>> The
>     >>>> javascript adapter has support for "scope" as an option of
>     the "login"
>     >>>> method [1]. The servlet adapter has a possibility to inject
>     custom
>     >>>> "scope" with parameters forwarding [2]. I am not sure about
>     node.js and
>     >>>> other adapters TBH. But even for javascript and servlet
>     adapter, the
>     >>>> current support is quite limited for few reasons. For example:
>     >>>>
>     >>>> - The approach of parameters forwarding used in servlet adapters
>     >>>> requires to logout before requesting the additional scope.
>     Because
>     >>>> when
>     >>>> I am already authenticated in the application and I open
>     secured URL
>     >>>> like http://localhost/app/secured?scope=some-custom-scope,
>     the adapter
>     >>>> will just ignore it in case that user is already logged-in
>     and it will
>     >>>> automatically forward to the application.
>     >>>>
>     >>>> - Both servlet and javascript adapters support to have just
>     single
>     >>>> "triplet" of tokens per browser session. In this context
>     "triplet"
>     >>>> means
>     >>>> the single set of 3 tokens (ID token , Access Token , Refresh
>     token).
>     >>>> So
>     >>>> for example when I want to request the custom scope for being
>     able to
>     >>>> invoke "service1", I can use "scope=service1". However after
>     Keycloak
>     >>>> redirects me back to the application, the existing triplet of
>     tokens is
>     >>>> just replaced with the new one for "service1" . Then when I
>     want to
>     >>>> later invoke another service like "service2", I need to
>     request the
>     >>>> additional scope "scope=service2", which will replace my
>     tokens on the
>     >>>> adapter's side with the "service2" tokens . But then later
>     when I want
>     >>>> to switch again to "service1", I need to redirect to Keycloak
>     again as
>     >>>> the current triplet of tokens for "service1" etc.
>     >>>>
>     >>>>
>     >>>> To improve this limitation, I think that it will be good if
>     adapters
>     >>>> easily support the following:
>     >>>>
>     >>>> - Instead of having single triplet of tokens, it will be good if
>     >>>> adapters can contain Map of tokens. Key of the map can be "scope"
>     >>>> parameter. So for example, the adapter will have "default" tokens
>     >>>> (those, which were used for initial login), the tokens for
>     "service1"
>     >>>> and the tokens for "service2" .
>     >>>>
>     >>>> - It will be nice if there is easy way to ask adapter for
>     "service1"
>     >>>> scope. In case that I don't have yet this scope, adapter will
>     redirect
>     >>>> me to Keycloak with "scope=service1". If I already have it,
>     adapter
>     >>>> will
>     >>>> return me an existing token. If existing access token is expired,
>     >>>> adapter will refresh the access token for requested scope in the
>     >>>> background and return me the "updated" token.
>     >>>>
>     >>>> - When I want to invoke service1 and I need to use
>     "scope=service1", I
>     >>>> usually need just access token and refresh token. I don't
>     need ID Token
>     >>>> anymore. I also don't need the "profile" and "email" claims to be
>     >>>> returned in the new access token. This is related to the JIRA
>     of having
>     >>>> the server-side support for client scopes like (always, default,
>     >>>> optional) instead of current (default, optional) [3]. In
>     other words,
>     >>>> the client scopes "profile" and "email" will be default
>     client scopes,
>     >>>> which means that if I don't use "scope=openid" in the OIDC
>     initial
>     >>>> request, the "profile" and "email" will be ommited from the
>     response as
>     >>>> well as the ID Token will be ommited from the response.
>     >>>>
>     >>>>
>     >>>> So how to support this on adapters? For Keycloak.js, I can
>     think about
>     >>>> some variation of existing "update" method like this:
>     >>>>
>     >>>>
>     >>>> keycloak.updateTokenWithScope('service1',
>     >>>> 5).success(function(accessToken, refreshed) {
>     >>>>? ? ? ? ? if (refreshed) {
>     >>>>? ? ? ? ? ? ? alert("I had existing accessToken for scope
>     'service1',
>     >>>> but
>     >>>> it needed to be refreshed as it was expired or about to
>     expire in less
>     >>>> than 5 seconds");
>     >>>>? ? ? ? ? } else {
>     >>>>? ? ? ? ? ? ? alert('I have accessToken for 'service1',? which
>     didn't
>     >>>> need to be refreshed');
>     >>>>? ? ? ? ? }
>     >>>>? ? ? ? ? // I can invoke REST service now with the accessToken
>     >>>>? ? ? ? ? ...
>     >>>>? ? ? }).error(function() {
>     >>>>? ? ? ? ? alert("Failed to refresh the token OR I don't have
>     yet scope
>     >>>> for 'service1' .");
>     >>>>? ? ? ? ? // User usually need to call keycloak.login with the
>     requested
>     >>>> scope now...
>     >>>>? ? ? });
>     >>>>
>     >>>>
>     >>>>
>     >>>>
>     >>>> For servlet adapter something like:
>     >>>>
>     >>>> KeycloakSecurityContext ctx = ... // Retrieved from
>     HttpServletRequest
>     >>>> or Principal as currently
>     >>>>
>     >>>> if (ctx.hasScope("service1")) {
>     >>>>? ? ? try {
>     >>>>? ? ? ? ? String accessToken = ctx.getScope("service1");
>     >>>>? ? ? ? ? // Invoke service1 with accessToken now
>     >>>>? ? ? } catch (TokenRefreshException ex) {
>     >>>>? ? ? ? ? log.error("I already had scope for service1, but
>     failed to
>     >>>> refresh the token. Need to re-login for the scope service1");
>     >>>>
>     >>>>? ? ? ? ? // See method below
>     >>>> redirectToKeycloakWithService1Scope();
>     >>>>? ? ? }
>     >>>> } else {
>     >>>>? ? ? // See method below
>     >>>>? ? ? redirectToKeycloakWithService1Scope();
>     >>>> }
>     >>>>
>     >>>>
>     >>>> private void redirectToKeycloakWithService1Scope() {
>     >>>>? ? ? KeycloakRedirectUriBuilder builder = ctx.createLoginUrl();
>     >>>>? ? ? URL url = builder.scope("service1").build();
>     >>>>? ? ? httpServletResponse.sendRedirect(url);
>     >>>> }
>     >>>>
>     >>>>
>     >>>> Regarding the class KeycloakRedirectUriBuilder, I was
>     thinking about
>     >>>> this class so that servlet adapter are able to easily create
>     login URL
>     >>>> with custom values for things like scope, prompt, max_age
>     etc. This
>     >>>> capability is currently missing in servlet adapters and the
>     current
>     >>>> approach based on parameters forwarding is a bit clunky for few
>     >>>> reasons.
>     >>>> One reason is usability and the other is, that you need to
>     logout first.
>     >>>>
>     >>>>
>     >>>> [1]
>     >>>>
>     >>>>
>     https://www.keycloak.org/docs/latest/securing_apps/index.html#javascript-adapter-reference
>     >>>> [2]
>     >>>>
>     >>>>
>     https://www.keycloak.org/docs/latest/securing_apps/index.html#_params_forwarding
>     >>>> [3] https://issues.jboss.org/browse/KEYCLOAK-8323
>     >>>>
>     >>>> Marek
>     >>>>
>     >>>> _______________________________________________
>     >>>> keycloak-dev mailing list
>     >>>> keycloak-dev at lists.jboss.org
>     <mailto:keycloak-dev at lists.jboss.org>
>     >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>     >>>
>     >>>
>     >>>
>     >>
>     >
>     _______________________________________________
>     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  Wed Feb  6 09:26:35 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 6 Feb 2019 15:26:35 +0100
Subject: [keycloak-dev] Better support for "scope" in adapters
In-Reply-To: <5f9ca2cf-ef26-87ad-4d54-b00ec695baf5@redhat.com>
References: <3030a267-b2b6-7a76-3020-42959ef344c5@redhat.com>
	<CAJrcDBep7ScX4O7G5fSh5oPhsbT9B5-ekqhF01MKiikZXB9ywg@mail.gmail.com>
	<e01a6dc8-3163-f132-835b-713b8cfdfc62@redhat.com>
	<CAJrcDBfNE8_8wSDCSrhvcnDa80w1=q=Ngm8wOae5pi9YERKqig@mail.gmail.com>
	<a57ed42b-3f80-21e2-f4e6-7f434030bef4@redhat.com>
	<CAJrcDBcUuiuD4sm5UaXh-BTy70mf+ipR10oHFq08jTS7ntxeUQ@mail.gmail.com>
	<27b5cb1e-cbc0-e79d-03f8-2203cddcf9e3@redhat.com>
	<CAJrcDBcyu+OD4KH0NZ1C=Z81bi+s7GtaTE+Fv8zNSCyOSWLU7A@mail.gmail.com>
	<CAJgngAcRDk3omuu7TVZQC52Os1dB-_tnYyjawZS5bAFYKGjD0g@mail.gmail.com>
	<5f9ca2cf-ef26-87ad-4d54-b00ec695baf5@redhat.com>
Message-ID: <CAJgngAcrw+Na-VaF_8bSnGutCS4aZqyQXgZ0fhGJv560VTbTuw@mail.gmail.com>

On Wed, 6 Feb 2019 at 11:53, Marek Posolda <mposolda at redhat.com> wrote:

> On 05/02/2019 09:39, Stian Thorgersen wrote:
>
> Tried to filter out implementation details here, so may have lost some
> details. It would be good if we can try to keep discussions at a higher
> level at least initially as it makes it much easier to follow the
> discussion.
>
> Point taken :) Will try to improve next time.
>
>
> For scopes I can see the most common use-case will be the ability to do
> incremental scopes. By that I mean the application doesn't request all
> permissions it may need, but rather starts small and asks for more as the
> user extends use of the application. This is mostly relevant to
> applications that require consent.
>
> Now with regards to the application being able to have different tokens to
> invoke different services I'm not convinced this is needed so we should
> rather wait for demand here. There's two ways a single app can consume
> multiple services:
>
> 1) Application directly invokes multiple services - in this case the
> application should be able to use scopes or token exchange to obtain tokens
> to invoke different services. In fact I'd say token exchange is probably
> what is wanted here rather than scopes.
> 2) Application invokes a backend service that aggregates multiple services
> - in this case token exchange comes in as the backend service needs to be
> able to obtain tokens to invoke the different services
>
> I would think option 2 is the best approach as it allows implementing the
> complex code in server side code and also makes the application more
> transparent to API changes.
>
> This seems to be inline with what Pedro mentioned as well. +1 for waiting
> for a demand for this.
>
>
> With regards to incremental scope support we need to be able to do that
> without requiring logout. For JS adapter that should already work, but it
> has one issue and that is you can't set the scope to use with automated
> login. We should probably make the scope configurable in the init function
> as well as when invoking login function directly. For servlet we should
> probably also have a way to configure the initial scope and expose a method
> to obtain additional scopes without requiring logout.
>
> +1
>
> Regarding JS adapter, there are few other things, which you can't do at
> "init" method. For example adding the "prompt" . Maybe all the current
> options of "login" method can be just used as arguments to "init" method?
>
Or perhaps it should be something like defaultLoginOptions which is an
object that we simply pass to the login function?

> For the servlet adapter, it will be probably good to have something like
> JS adapter "keycloak.login" method or "keycloak.createLoginUrl", which
> allows to add things like custom scope, prompt etc. I proposed something
> like KeycloakLoginUrlBuilder, which will allow to easy add things like
> "scope" or "prompt" in the adapters code.
>
Isn't really what you want is server-side action that returns the redirect
rather than directly adding the login url to the page? The reason I'm
saying that is that the adapter needs to generate the state param and such,
which it can't do if the login url is just placed directly on the page.

>
> I'm not convinced about client scope inheritance. It has an additional
> implementation complexity, but most importantly usability with regards to
> understand what is actually included in the token when you have
> inheritance. It may also have some strange side-effects like how do you
> make sure the order of what is applied is correct. Again, probably
> something best left until there is demand for it.
>
> We already have "priority" on protocolMappers, so ordering likely won't be
> an issue. You can add protocolMappers of all the "effective" client scopes
> and sort the protocol mappers. But agree that will be good to wait for more
> demand before adding this.
>
> Marek
>
> On Thu, 31 Jan 2019 at 17:04, Pedro Igor Silva <psilva at redhat.com> wrote:
>
>> +1
>>
>> On Thu, Jan 31, 2019 at 11:14 AM Marek Posolda <mposolda at redhat.com>
>> wrote:
>>
>> > On 31/01/2019 14:07, Pedro Igor Silva wrote:
>> >
>> > This what I like most about client scopes (in addition to all mapping
>> you
>> > do to claims in the tokens) :) Would also make sense to do the same
>> thing
>> > to client scopes ? So clients requesting "foo" would also get "bar" and
>> > "xpto", for instance ?
>> >
>> > Maybe this could avoid the client to request 10 scopes but just a more
>> > coarse-grained scope representing all of them.
>> >
>> > There is opened JIRA for client scopes inheritance
>> > https://issues.jboss.org/browse/KEYCLOAK-6633 . I believe this will
>> cover
>> > what you have in mind? It's just not yet done...
>> >
>> > Marek
>> >
>> >
>> >
>> > On Thu, Jan 31, 2019 at 10:43 AM Marek Posolda <mposolda at redhat.com>
>> > wrote:
>> >
>> >> On 30/01/2019 14:40, Pedro Igor Silva wrote:
>> >>
>> >>
>> >>
>> >> On Wed, Jan 30, 2019 at 5:25 AM Marek Posolda <mposolda at redhat.com>
>> >> wrote:
>> >>
>> >>> On 29/01/2019 19:49, Pedro Igor Silva wrote:
>> >>>
>> >>> I'm not sure if we need to consider that in our adapters.
>> >>>
>> >>> Usually, the front-end knows the set of scopes that it needs to
>> interact
>> >>> with the backend and stay functional.
>> >>>
>> >>> Maybe. I am personally not sure how people expect to use "scope"
>> >>> parameters in their frontend applications. Maybe 90% of frontend
>> clients
>> >>> don't need to use "scope" parameter at all. And from the remaining,
>> they
>> >>> will be fine with the current support of the "scope" parameter.
>> >>>
>> >> I would say so, mainly because I think people are still using RBAC to
>> >> enforce access to APIs. Enterprise scenarios don't really use scopes as
>> >> they are more related with delegation.
>> >>
>> >> Yeah, maybe. Just a note that our client scopes support also allows to
>> >> limit roles in the token. For example you can define role scope
>> mappings of
>> >> client scope "service1" to have role "service1.my-service1-role" . So
>> by
>> >> requesting "scope=service1", you will also receive this role in the
>> token
>> >> and hence can be used for RBAC based authorization.
>> >>
>> >> But anyway, I probably won't create any JIRAs for now. Will wait if
>> there
>> >> is some more feedback or some more requests for better support of
>> "scope"
>> >> parameter in the adapters.
>> >>
>> >> Thanks for the feedback Pedro!
>> >>
>> >> Marek
>> >>
>> >> One possibility, where I can see usage of this, is when frontend client
>> >>> wants to invoke multiple different services and he wants to use
>> different
>> >>> access tokens with properly "isolated" audiences. So for example you
>> want
>> >>> to have:
>> >>>
>> >>> - access token with "scope=service1", which will have in itself
>> audience
>> >>> claim "aud: service1" and you will use it to invoke backend service1
>> >>> - access token with "scope=service2", which will have in itself
>> audience
>> >>> claim "aud: service2" and you will use it to invoke backend service2
>> >>>
>> >>> In this case, having the possibility for adapters to "cache" multiple
>> >>> tokens for various scopes can be beneficial IMO, so client can easily
>> >>> retrieve proper access token based on the service he wants to invoke.
>> >>>
>> >>> And the backend by itself is free to exchange tokens to call other
>> >>> services (service chaining).
>> >>>
>> >>> Don't think that brings a lot of complexity to the front-end and,
>> >> probably, indicates a bad design?
>> >>
>> >>> IMO in many cases, you're right. For example when frontend client uses
>> >>> access token to invoke backend "service1", this backend may want to
>> >>> retrieve some other data from "service11". So service1 backend needs
>> to
>> >>> reuse the token or he wants to exchange this token.
>> >>>
>> >>> But in many cases, you want to avoid this. So in my example above,
>> when
>> >>> you have access token with "aud: service1", you want this access
>> token to
>> >>> be used solely to invoke service1. You don't want to have one huge
>> access
>> >>> token, which will have all the audiences like:
>> >>>
>> >>> aud: [ "service1", "service2" ]
>> >>>
>> >> The access token is also tied with the client, what means "this client
>> is
>> >> allowed to invoke service1 and service2". I usually don't see a
>> problem on
>> >> that if you consider that multiple audiences mean that a high degree of
>> >> trust between the parties involved. What I think is true for most
>> >> enterprise use cases where the front-end is basically accessing
>> internal
>> >> services.
>> >>
>> >> It is also worthy to consider, IMO, that the fact that you have
>> distinct
>> >> services, does not mean they are not part of the same API, thus the
>> same
>> >> audience.
>> >>
>> >>> You may want separate access tokens with isolated audiences exactly
>> >>> because you don't want service1 and service2 to be able to invoke each
>> >>> other. IMO this isolation is one of the main usages of the "aud"
>> claim in
>> >>> the tokens.
>> >>>
>> >>>
>> >>> One thing that makes sense though is "incremental authorization" and
>> >>> allow apps to request additional scopes during an authentication
>> session,
>> >>> so the app gets what was previously granted and the new scopes
>> (depending
>> >>> on user consent). But I think we support that already, right ?
>> >>>
>> >>> We don't support it directly and maybe this is something to improve.
>> ATM
>> >>> you will need programatically do something like this:
>> >>>
>> >>> String existingScope = existingAccessToken.getScope();
>> >>>
>> >>> // I want to use existingScope and add "phone" scope to it
>> >>> String newScope = existingScope + " phone";
>> >>>
>> >>> // Request the login for new scope now
>> >>>
>> >>>
>> >>> The part of "requesting login for new scope" is possible with
>> javascript
>> >>> adapter, but not easily with the "java" adapter. With java adapter,
>> there
>> >>> is no easy way to manually "build" URL to sent to OIDC authentication
>> >>> endpoint (equivalent of keycloak.js method "createLoginUrl"). That's
>> also
>> >>> one of the things, which I proposed to improve in this email thread.
>> >>>
>> >> Marek
>> >>>
>> >>>
>> >>> Regards.
>> >>> Pedro Igor
>> >>>
>> >>> On Tue, Jan 29, 2019 at 9:36 AM Marek Posolda <mposolda at redhat.com>
>> >>> wrote:
>> >>>
>> >>>> During my work on Client Scopes last year, I did not any work on the
>> >>>> adapters side. I think there is a space for improvement here. I will
>> >>>> try
>> >>>> to summary current issues and some initial proposals for improve
>> >>>> things.
>> >>>> Suggestions welcomed! And sorry for longer email :)
>> >>>>
>> >>>>
>> >>>> Both javascript adapter and servlet adapter has some way for
>> requesting
>> >>>> the additional "scope" and ensure that that initial OIDC
>> authentication
>> >>>> request sent to Keycloak will contain some custom "scope" parameter.
>> >>>> The
>> >>>> javascript adapter has support for "scope" as an option of the
>> "login"
>> >>>> method [1]. The servlet adapter has a possibility to inject custom
>> >>>> "scope" with parameters forwarding [2]. I am not sure about node.js
>> and
>> >>>> other adapters TBH. But even for javascript and servlet adapter, the
>> >>>> current support is quite limited for few reasons. For example:
>> >>>>
>> >>>> - The approach of parameters forwarding used in servlet adapters
>> >>>> requires to logout before requesting the additional scope. Because
>> >>>> when
>> >>>> I am already authenticated in the application and I open secured URL
>> >>>> like http://localhost/app/secured?scope=some-custom-scope, the
>> adapter
>> >>>> will just ignore it in case that user is already logged-in and it
>> will
>> >>>> automatically forward to the application.
>> >>>>
>> >>>> - Both servlet and javascript adapters support to have just single
>> >>>> "triplet" of tokens per browser session. In this context "triplet"
>> >>>> means
>> >>>> the single set of 3 tokens (ID token , Access Token , Refresh token).
>> >>>> So
>> >>>> for example when I want to request the custom scope for being able to
>> >>>> invoke "service1", I can use "scope=service1". However after Keycloak
>> >>>> redirects me back to the application, the existing triplet of tokens
>> is
>> >>>> just replaced with the new one for "service1" . Then when I want to
>> >>>> later invoke another service like "service2", I need to request the
>> >>>> additional scope "scope=service2", which will replace my tokens on
>> the
>> >>>> adapter's side with the "service2" tokens . But then later when I
>> want
>> >>>> to switch again to "service1", I need to redirect to Keycloak again
>> as
>> >>>> the current triplet of tokens for "service1" etc.
>> >>>>
>> >>>>
>> >>>> To improve this limitation, I think that it will be good if adapters
>> >>>> easily support the following:
>> >>>>
>> >>>> - Instead of having single triplet of tokens, it will be good if
>> >>>> adapters can contain Map of tokens. Key of the map can be "scope"
>> >>>> parameter. So for example, the adapter will have "default" tokens
>> >>>> (those, which were used for initial login), the tokens for "service1"
>> >>>> and the tokens for "service2" .
>> >>>>
>> >>>> - It will be nice if there is easy way to ask adapter for "service1"
>> >>>> scope. In case that I don't have yet this scope, adapter will
>> redirect
>> >>>> me to Keycloak with "scope=service1". If I already have it, adapter
>> >>>> will
>> >>>> return me an existing token. If existing access token is expired,
>> >>>> adapter will refresh the access token for requested scope in the
>> >>>> background and return me the "updated" token.
>> >>>>
>> >>>> - When I want to invoke service1 and I need to use "scope=service1",
>> I
>> >>>> usually need just access token and refresh token. I don't need ID
>> Token
>> >>>> anymore. I also don't need the "profile" and "email" claims to be
>> >>>> returned in the new access token. This is related to the JIRA of
>> having
>> >>>> the server-side support for client scopes like (always, default,
>> >>>> optional) instead of current (default, optional) [3]. In other words,
>> >>>> the client scopes "profile" and "email" will be default client
>> scopes,
>> >>>> which means that if I don't use "scope=openid" in the OIDC initial
>> >>>> request, the "profile" and "email" will be ommited from the response
>> as
>> >>>> well as the ID Token will be ommited from the response.
>> >>>>
>> >>>>
>> >>>> So how to support this on adapters? For Keycloak.js, I can think
>> about
>> >>>> some variation of existing "update" method like this:
>> >>>>
>> >>>>
>> >>>> keycloak.updateTokenWithScope('service1',
>> >>>> 5).success(function(accessToken, refreshed) {
>> >>>>          if (refreshed) {
>> >>>>              alert("I had existing accessToken for scope 'service1',
>> >>>> but
>> >>>> it needed to be refreshed as it was expired or about to expire in
>> less
>> >>>> than 5 seconds");
>> >>>>          } else {
>> >>>>              alert('I have accessToken for 'service1',  which didn't
>> >>>> need to be refreshed');
>> >>>>          }
>> >>>>          // I can invoke REST service now with the accessToken
>> >>>>          ...
>> >>>>      }).error(function() {
>> >>>>          alert("Failed to refresh the token OR I don't have yet scope
>> >>>> for 'service1' .");
>> >>>>          // User usually need to call keycloak.login with the
>> requested
>> >>>> scope now...
>> >>>>      });
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> For servlet adapter something like:
>> >>>>
>> >>>> KeycloakSecurityContext ctx = ... // Retrieved from
>> HttpServletRequest
>> >>>> or Principal as currently
>> >>>>
>> >>>> if (ctx.hasScope("service1")) {
>> >>>>      try {
>> >>>>          String accessToken = ctx.getScope("service1");
>> >>>>          // Invoke service1 with accessToken now
>> >>>>      } catch (TokenRefreshException ex) {
>> >>>>          log.error("I already had scope for service1, but failed to
>> >>>> refresh the token. Need to re-login for the scope service1");
>> >>>>
>> >>>>          // See method below
>> >>>>          redirectToKeycloakWithService1Scope();
>> >>>>      }
>> >>>> } else {
>> >>>>      // See method below
>> >>>>      redirectToKeycloakWithService1Scope();
>> >>>> }
>> >>>>
>> >>>>
>> >>>> private void redirectToKeycloakWithService1Scope() {
>> >>>>      KeycloakRedirectUriBuilder builder = ctx.createLoginUrl();
>> >>>>      URL url = builder.scope("service1").build();
>> >>>>      httpServletResponse.sendRedirect(url);
>> >>>> }
>> >>>>
>> >>>>
>> >>>> Regarding the class KeycloakRedirectUriBuilder, I was thinking about
>> >>>> this class so that servlet adapter are able to easily create login
>> URL
>> >>>> with custom values for things like scope, prompt, max_age etc. This
>> >>>> capability is currently missing in servlet adapters and the current
>> >>>> approach based on parameters forwarding is a bit clunky for few
>> >>>> reasons.
>> >>>> One reason is usability and the other is, that you need to logout
>> first.
>> >>>>
>> >>>>
>> >>>> [1]
>> >>>>
>> >>>>
>> https://www.keycloak.org/docs/latest/securing_apps/index.html#javascript-adapter-reference
>> >>>> [2]
>> >>>>
>> >>>>
>> https://www.keycloak.org/docs/latest/securing_apps/index.html#_params_forwarding
>> >>>> [3] https://issues.jboss.org/browse/KEYCLOAK-8323
>> >>>>
>> >>>> Marek
>> >>>>
>> >>>> _______________________________________________
>> >>>> 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  Wed Feb  6 09:27:31 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 6 Feb 2019 15:27:31 +0100
Subject: [keycloak-dev] help to personaling Keycloark
In-Reply-To: <CAAYRsuCq06T8syhJtJAYcvZNkp=rnd4e_fnHk5OSdatDi=oUyQ@mail.gmail.com>
References: <CAAYRsuCq06T8syhJtJAYcvZNkp=rnd4e_fnHk5OSdatDi=oUyQ@mail.gmail.com>
Message-ID: <CAJgngAcm332ZZw1O3XMQCdALVhy-A87Yd7-9V2N1SY4i7sUOFA@mail.gmail.com>

If you have specific questions feel free to send them to the user mailing
list. This mailing list is for core developers of Keycloak and contributors
to Keycloak itself.

On Wed, 6 Feb 2019 at 11:34, Cristiano Marques <
cristianomarquesadm02 at gmail.com> wrote:

> hi, i need help to questions about Keycloark and also personaling Keycloak.
> Thanks fo attention
> Cristiano Marques dos Santos
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sthorger at redhat.com  Wed Feb  6 09:38:13 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 6 Feb 2019 15:38:13 +0100
Subject: [keycloak-dev] translate keycloak
In-Reply-To: <0e632a6e-3c74-0392-75df-055bb7c8e54f@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>
Message-ID: <CAJgngAfAOMnq03_gBvy_gtXhxa9wMaNY9P=f8ny7ZprV3s_doQ@mail.gmail.com>

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> 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>> 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>>> 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>>
> >     >     https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >     >
> >
>
>

From cristianomarquesadm02 at gmail.com  Wed Feb  6 22:43:46 2019
From: cristianomarquesadm02 at gmail.com (Cristiano Marques)
Date: Thu, 7 Feb 2019 01:43:46 -0200
Subject: [keycloak-dev] HELP IN PERSONALING KEYCLOARK AND QUESTIONS ABOUT
	KEYCLOARK
Message-ID: <CAAYRsuDVQ38ZDZF-rC9G+Y+2kgucvkaW-8J8XPX7S5MQQ2_3Tg@mail.gmail.com>

Hi, i need help some questions about Keycloark, for ex.: Whats your
principal utility?
How can me heulp?
also how personalize the Keycloark?
Thanks for attention
Cristiano Marques dos Santos

From mposolda at redhat.com  Thu Feb  7 03:40:41 2019
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 7 Feb 2019 09:40:41 +0100
Subject: [keycloak-dev] Better support for "scope" in adapters
In-Reply-To: <CAJgngAcrw+Na-VaF_8bSnGutCS4aZqyQXgZ0fhGJv560VTbTuw@mail.gmail.com>
References: <3030a267-b2b6-7a76-3020-42959ef344c5@redhat.com>
	<CAJrcDBep7ScX4O7G5fSh5oPhsbT9B5-ekqhF01MKiikZXB9ywg@mail.gmail.com>
	<e01a6dc8-3163-f132-835b-713b8cfdfc62@redhat.com>
	<CAJrcDBfNE8_8wSDCSrhvcnDa80w1=q=Ngm8wOae5pi9YERKqig@mail.gmail.com>
	<a57ed42b-3f80-21e2-f4e6-7f434030bef4@redhat.com>
	<CAJrcDBcUuiuD4sm5UaXh-BTy70mf+ipR10oHFq08jTS7ntxeUQ@mail.gmail.com>
	<27b5cb1e-cbc0-e79d-03f8-2203cddcf9e3@redhat.com>
	<CAJrcDBcyu+OD4KH0NZ1C=Z81bi+s7GtaTE+Fv8zNSCyOSWLU7A@mail.gmail.com>
	<CAJgngAcRDk3omuu7TVZQC52Os1dB-_tnYyjawZS5bAFYKGjD0g@mail.gmail.com>
	<5f9ca2cf-ef26-87ad-4d54-b00ec695baf5@redhat.com>
	<CAJgngAcrw+Na-VaF_8bSnGutCS4aZqyQXgZ0fhGJv560VTbTuw@mail.gmail.com>
Message-ID: <0e13794d-43ea-ab17-5859-91d4ec5e1fcc@redhat.com>

On 06/02/2019 15:26, Stian Thorgersen wrote:
>
>
> On Wed, 6 Feb 2019 at 11:53, Marek Posolda <mposolda at redhat.com 
> <mailto:mposolda at redhat.com>> wrote:
>
>     On 05/02/2019 09:39, Stian Thorgersen wrote:
>>     Tried to filter out implementation details here, so may have lost
>>     some details. It would be good if we can try to keep discussions
>>     at a higher level at least initially as it makes it much easier
>>     to follow the discussion.
>     Point taken :) Will try to improve next time.
>>
>>     For scopes I can see the most common use-case will be the ability
>>     to do incremental scopes. By that I mean the application doesn't
>>     request all permissions it may need, but rather starts small and
>>     asks for more as the user extends use of the application. This is
>>     mostly relevant to applications that require consent.
>>
>>     Now with regards to the application being able to have different
>>     tokens to invoke different services I'm not convinced this is
>>     needed so we should rather wait for demand here. There's two ways
>>     a single app can consume multiple services:
>>
>>     1) Application directly invokes multiple services - in this case
>>     the application should be able to use scopes or token exchange to
>>     obtain tokens to invoke different services. In fact I'd say token
>>     exchange is probably what is wanted here rather than scopes.
>>     2) Application invokes a backend service that aggregates multiple
>>     services - in this case token exchange comes in as the backend
>>     service needs to be able to obtain tokens to invoke the different
>>     services
>>
>>     I would think option 2 is the best approach as it allows
>>     implementing the complex code in server side code and also makes
>>     the application more transparent to API changes.
>     This seems to be inline with what Pedro mentioned as well. +1 for
>     waiting for a demand for this.
>>
>>     With regards to incremental scope support we need to be able to
>>     do that without requiring logout. For JS adapter that should
>>     already work, but it has one issue and that is you can't set the
>>     scope to use with automated login. We should probably make the
>>     scope configurable in the init function as well as when invoking
>>     login function directly. For servlet we should probably also have
>>     a way to configure the initial scope and expose a method to
>>     obtain additional scopes without requiring logout.
>
>     +1
>
>     Regarding JS adapter, there are few other things, which you can't
>     do at "init" method. For example adding the "prompt" . Maybe all
>     the current options of "login" method can be just used as
>     arguments to "init" method?
>
> Or perhaps it should be something like defaultLoginOptions which is an 
> object that we simply pass to the login function?
Was thinking about that as well :) It will be probably better as if 
someone wants to call "keycloak.login" and override just single thing 
(EG. scope), he can clone the defaultLoginOptions and override just scope.
>
>     For the servlet adapter, it will be probably good to have
>     something like JS adapter "keycloak.login" method or
>     "keycloak.createLoginUrl", which allows to add things like custom
>     scope, prompt etc. I proposed something like
>     KeycloakLoginUrlBuilder, which will allow to easy add things like
>     "scope" or "prompt" in the adapters code.
>
> Isn't really what you want is server-side action that returns the 
> redirect rather than directly adding the login url to the page? The 
> reason I'm saying that is that the adapter needs to generate the state 
> param and such, which it can't do if the login url is just placed 
> directly on the page.

I did not mean to directly add URL to the page, but rather something 
along the lines of:

KeycloakLoginRedirectURL loginRedirect = KeycloakLoginRedirectURLBuilder
 ??? ??? .prompt("consent")
 ??? ??? .scope(accessToken.getScope() + " phone")
 ??? ??? .build();

getKeycloakSecurityContext().sendRedirectToLogin(loginRedirect);

Note that when you call "sendRedirectToLogin", it will the 
responsibility of the adapter to generate "state" and add "redirect_uri" 
from the keycloak.json config etc. Maybe KeycloakLoginRedirectURL is not 
the best name for this, rather something like "KeycloakLoginRedirect" or 
"KeycloakLoginRedirectState", but that's an implementation detail.

Marek

>>
>>     I'm not convinced about client scope inheritance. It has an
>>     additional implementation complexity, but most importantly
>>     usability with regards to understand what is actually included in
>>     the token when you have inheritance. It may also have some
>>     strange side-effects like how do you make sure the order of what
>>     is applied is correct. Again, probably something best left until
>>     there is demand for it.
>
>     We already have "priority" on protocolMappers, so ordering likely
>     won't be an issue. You can add protocolMappers of all the
>     "effective" client scopes and sort the protocol mappers. But agree
>     that will be good to wait for more demand before adding this.
>
>     Marek
>
>>     On Thu, 31 Jan 2019 at 17:04, Pedro Igor Silva <psilva at redhat.com
>>     <mailto:psilva at redhat.com>> wrote:
>>
>>         +1
>>
>>         On Thu, Jan 31, 2019 at 11:14 AM Marek Posolda
>>         <mposolda at redhat.com <mailto:mposolda at redhat.com>> wrote:
>>
>>         > On 31/01/2019 14:07, Pedro Igor Silva wrote:
>>         >
>>         > This what I like most about client scopes (in addition to
>>         all mapping you
>>         > do to claims in the tokens) :) Would also make sense to do
>>         the same thing
>>         > to client scopes ? So clients requesting "foo" would also
>>         get "bar" and
>>         > "xpto", for instance ?
>>         >
>>         > Maybe this could avoid the client to request 10 scopes but
>>         just a more
>>         > coarse-grained scope representing all of them.
>>         >
>>         > There is opened JIRA for client scopes inheritance
>>         > https://issues.jboss.org/browse/KEYCLOAK-6633 . I believe
>>         this will cover
>>         > what you have in mind? It's just not yet done...
>>         >
>>         > Marek
>>         >
>>         >
>>         >
>>         > On Thu, Jan 31, 2019 at 10:43 AM Marek Posolda
>>         <mposolda at redhat.com <mailto:mposolda at redhat.com>>
>>         > wrote:
>>         >
>>         >> On 30/01/2019 14:40, Pedro Igor Silva wrote:
>>         >>
>>         >>
>>         >>
>>         >> On Wed, Jan 30, 2019 at 5:25 AM Marek Posolda
>>         <mposolda at redhat.com <mailto:mposolda at redhat.com>>
>>         >> wrote:
>>         >>
>>         >>> On 29/01/2019 19:49, Pedro Igor Silva wrote:
>>         >>>
>>         >>> I'm not sure if we need to consider that in our adapters.
>>         >>>
>>         >>> Usually, the front-end knows the set of scopes that it
>>         needs to interact
>>         >>> with the backend and stay functional.
>>         >>>
>>         >>> Maybe. I am personally not sure how people expect to use
>>         "scope"
>>         >>> parameters in their frontend applications. Maybe 90% of
>>         frontend clients
>>         >>> don't need to use "scope" parameter at all. And from the
>>         remaining, they
>>         >>> will be fine with the current support of the "scope"
>>         parameter.
>>         >>>
>>         >> I would say so, mainly because I think people are still
>>         using RBAC to
>>         >> enforce access to APIs. Enterprise scenarios don't really
>>         use scopes as
>>         >> they are more related with delegation.
>>         >>
>>         >> Yeah, maybe. Just a note that our client scopes support
>>         also allows to
>>         >> limit roles in the token. For example you can define role
>>         scope mappings of
>>         >> client scope "service1" to have role
>>         "service1.my-service1-role" . So by
>>         >> requesting "scope=service1", you will also receive this
>>         role in the token
>>         >> and hence can be used for RBAC based authorization.
>>         >>
>>         >> But anyway, I probably won't create any JIRAs for now.
>>         Will wait if there
>>         >> is some more feedback or some more requests for better
>>         support of "scope"
>>         >> parameter in the adapters.
>>         >>
>>         >> Thanks for the feedback Pedro!
>>         >>
>>         >> Marek
>>         >>
>>         >> One possibility, where I can see usage of this, is when
>>         frontend client
>>         >>> wants to invoke multiple different services and he wants
>>         to use different
>>         >>> access tokens with properly "isolated" audiences. So for
>>         example you want
>>         >>> to have:
>>         >>>
>>         >>> - access token with "scope=service1", which will have in
>>         itself audience
>>         >>> claim "aud: service1" and you will use it to invoke
>>         backend service1
>>         >>> - access token with "scope=service2", which will have in
>>         itself audience
>>         >>> claim "aud: service2" and you will use it to invoke
>>         backend service2
>>         >>>
>>         >>> In this case, having the possibility for adapters to
>>         "cache" multiple
>>         >>> tokens for various scopes can be beneficial IMO, so
>>         client can easily
>>         >>> retrieve proper access token based on the service he
>>         wants to invoke.
>>         >>>
>>         >>> And the backend by itself is free to exchange tokens to
>>         call other
>>         >>> services (service chaining).
>>         >>>
>>         >>> Don't think that brings a lot of complexity to the
>>         front-end and,
>>         >> probably, indicates a bad design?
>>         >>
>>         >>> IMO in many cases, you're right. For example when
>>         frontend client uses
>>         >>> access token to invoke backend "service1", this backend
>>         may want to
>>         >>> retrieve some other data from "service11". So service1
>>         backend needs to
>>         >>> reuse the token or he wants to exchange this token.
>>         >>>
>>         >>> But in many cases, you want to avoid this. So in my
>>         example above, when
>>         >>> you have access token with "aud: service1", you want this
>>         access token to
>>         >>> be used solely to invoke service1. You don't want to have
>>         one huge access
>>         >>> token, which will have all the audiences like:
>>         >>>
>>         >>> aud: [ "service1", "service2" ]
>>         >>>
>>         >> The access token is also tied with the client, what means
>>         "this client is
>>         >> allowed to invoke service1 and service2". I usually don't
>>         see a problem on
>>         >> that if you consider that multiple audiences mean that a
>>         high degree of
>>         >> trust between the parties involved. What I think is true
>>         for most
>>         >> enterprise use cases where the front-end is basically
>>         accessing internal
>>         >> services.
>>         >>
>>         >> It is also worthy to consider, IMO, that the fact that you
>>         have distinct
>>         >> services, does not mean they are not part of the same API,
>>         thus the same
>>         >> audience.
>>         >>
>>         >>> You may want separate access tokens with isolated
>>         audiences exactly
>>         >>> because you don't want service1 and service2 to be able
>>         to invoke each
>>         >>> other. IMO this isolation is one of the main usages of
>>         the "aud" claim in
>>         >>> the tokens.
>>         >>>
>>         >>>
>>         >>> One thing that makes sense though is "incremental
>>         authorization" and
>>         >>> allow apps to request additional scopes during an
>>         authentication session,
>>         >>> so the app gets what was previously granted and the new
>>         scopes (depending
>>         >>> on user consent). But I think we support that already,
>>         right ?
>>         >>>
>>         >>> We don't support it directly and maybe this is something
>>         to improve. ATM
>>         >>> you will need programatically do something like this:
>>         >>>
>>         >>> String existingScope = existingAccessToken.getScope();
>>         >>>
>>         >>> // I want to use existingScope and add "phone" scope to it
>>         >>> String newScope = existingScope + " phone";
>>         >>>
>>         >>> // Request the login for new scope now
>>         >>>
>>         >>>
>>         >>> The part of "requesting login for new scope" is possible
>>         with javascript
>>         >>> adapter, but not easily with the "java" adapter. With
>>         java adapter, there
>>         >>> is no easy way to manually "build" URL to sent to OIDC
>>         authentication
>>         >>> endpoint (equivalent of keycloak.js method
>>         "createLoginUrl"). That's also
>>         >>> one of the things, which I proposed to improve in this
>>         email thread.
>>         >>>
>>         >> Marek
>>         >>>
>>         >>>
>>         >>> Regards.
>>         >>> Pedro Igor
>>         >>>
>>         >>> On Tue, Jan 29, 2019 at 9:36 AM Marek Posolda
>>         <mposolda at redhat.com <mailto:mposolda at redhat.com>>
>>         >>> wrote:
>>         >>>
>>         >>>> During my work on Client Scopes last year, I did not any
>>         work on the
>>         >>>> adapters side. I think there is a space for improvement
>>         here. I will
>>         >>>> try
>>         >>>> to summary current issues and some initial proposals for
>>         improve
>>         >>>> things.
>>         >>>> Suggestions welcomed! And sorry for longer email :)
>>         >>>>
>>         >>>>
>>         >>>> Both javascript adapter and servlet adapter has some way
>>         for requesting
>>         >>>> the additional "scope" and ensure that that initial OIDC
>>         authentication
>>         >>>> request sent to Keycloak will contain some custom
>>         "scope" parameter.
>>         >>>> The
>>         >>>> javascript adapter has support for "scope" as an option
>>         of the "login"
>>         >>>> method [1]. The servlet adapter has a possibility to
>>         inject custom
>>         >>>> "scope" with parameters forwarding [2]. I am not sure
>>         about node.js and
>>         >>>> other adapters TBH. But even for javascript and servlet
>>         adapter, the
>>         >>>> current support is quite limited for few reasons. For
>>         example:
>>         >>>>
>>         >>>> - The approach of parameters forwarding used in servlet
>>         adapters
>>         >>>> requires to logout before requesting the additional
>>         scope. Because
>>         >>>> when
>>         >>>> I am already authenticated in the application and I open
>>         secured URL
>>         >>>> like
>>         http://localhost/app/secured?scope=some-custom-scope, the adapter
>>         >>>> will just ignore it in case that user is already
>>         logged-in and it will
>>         >>>> automatically forward to the application.
>>         >>>>
>>         >>>> - Both servlet and javascript adapters support to have
>>         just single
>>         >>>> "triplet" of tokens per browser session. In this context
>>         "triplet"
>>         >>>> means
>>         >>>> the single set of 3 tokens (ID token , Access Token ,
>>         Refresh token).
>>         >>>> So
>>         >>>> for example when I want to request the custom scope for
>>         being able to
>>         >>>> invoke "service1", I can use "scope=service1". However
>>         after Keycloak
>>         >>>> redirects me back to the application, the existing
>>         triplet of tokens is
>>         >>>> just replaced with the new one for "service1" . Then
>>         when I want to
>>         >>>> later invoke another service like "service2", I need to
>>         request the
>>         >>>> additional scope "scope=service2", which will replace my
>>         tokens on the
>>         >>>> adapter's side with the "service2" tokens . But then
>>         later when I want
>>         >>>> to switch again to "service1", I need to redirect to
>>         Keycloak again as
>>         >>>> the current triplet of tokens for "service1" etc.
>>         >>>>
>>         >>>>
>>         >>>> To improve this limitation, I think that it will be good
>>         if adapters
>>         >>>> easily support the following:
>>         >>>>
>>         >>>> - Instead of having single triplet of tokens, it will be
>>         good if
>>         >>>> adapters can contain Map of tokens. Key of the map can
>>         be "scope"
>>         >>>> parameter. So for example, the adapter will have
>>         "default" tokens
>>         >>>> (those, which were used for initial login), the tokens
>>         for "service1"
>>         >>>> and the tokens for "service2" .
>>         >>>>
>>         >>>> - It will be nice if there is easy way to ask adapter
>>         for "service1"
>>         >>>> scope. In case that I don't have yet this scope, adapter
>>         will redirect
>>         >>>> me to Keycloak with "scope=service1". If I already have
>>         it, adapter
>>         >>>> will
>>         >>>> return me an existing token. If existing access token is
>>         expired,
>>         >>>> adapter will refresh the access token for requested
>>         scope in the
>>         >>>> background and return me the "updated" token.
>>         >>>>
>>         >>>> - When I want to invoke service1 and I need to use
>>         "scope=service1", I
>>         >>>> usually need just access token and refresh token. I
>>         don't need ID Token
>>         >>>> anymore. I also don't need the "profile" and "email"
>>         claims to be
>>         >>>> returned in the new access token. This is related to the
>>         JIRA of having
>>         >>>> the server-side support for client scopes like (always,
>>         default,
>>         >>>> optional) instead of current (default, optional) [3]. In
>>         other words,
>>         >>>> the client scopes "profile" and "email" will be default
>>         client scopes,
>>         >>>> which means that if I don't use "scope=openid" in the
>>         OIDC initial
>>         >>>> request, the "profile" and "email" will be ommited from
>>         the response as
>>         >>>> well as the ID Token will be ommited from the response.
>>         >>>>
>>         >>>>
>>         >>>> So how to support this on adapters? For Keycloak.js, I
>>         can think about
>>         >>>> some variation of existing "update" method like this:
>>         >>>>
>>         >>>>
>>         >>>> keycloak.updateTokenWithScope('service1',
>>         >>>> 5).success(function(accessToken, refreshed) {
>>         >>>>? ? ? ? ? if (refreshed) {
>>         >>>>? ? ? ? ? ? ? alert("I had existing accessToken for scope
>>         'service1',
>>         >>>> but
>>         >>>> it needed to be refreshed as it was expired or about to
>>         expire in less
>>         >>>> than 5 seconds");
>>         >>>>? ? ? ? ? } else {
>>         >>>>? ? ? ? ? ? ? alert('I have accessToken for 'service1',?
>>         which didn't
>>         >>>> need to be refreshed');
>>         >>>>? ? ? ? ? }
>>         >>>>? ? ? ? ? // I can invoke REST service now with the
>>         accessToken
>>         >>>>? ? ? ? ? ...
>>         >>>>? ? ? }).error(function() {
>>         >>>>? ? ? ? ? alert("Failed to refresh the token OR I don't
>>         have yet scope
>>         >>>> for 'service1' .");
>>         >>>>? ? ? ? ? // User usually need to call keycloak.login
>>         with the requested
>>         >>>> scope now...
>>         >>>>? ? ? });
>>         >>>>
>>         >>>>
>>         >>>>
>>         >>>>
>>         >>>> For servlet adapter something like:
>>         >>>>
>>         >>>> KeycloakSecurityContext ctx = ... // Retrieved from
>>         HttpServletRequest
>>         >>>> or Principal as currently
>>         >>>>
>>         >>>> if (ctx.hasScope("service1")) {
>>         >>>>? ? ? try {
>>         >>>>? ? ? ? ? String accessToken = ctx.getScope("service1");
>>         >>>>? ? ? ? ? // Invoke service1 with accessToken now
>>         >>>>? ? ? } catch (TokenRefreshException ex) {
>>         >>>>? ? ? ? ? log.error("I already had scope for service1,
>>         but failed to
>>         >>>> refresh the token. Need to re-login for the scope
>>         service1");
>>         >>>>
>>         >>>>? ? ? ? ? // See method below
>>         >>>> redirectToKeycloakWithService1Scope();
>>         >>>>? ? ? }
>>         >>>> } else {
>>         >>>>? ? ? // See method below
>>         >>>> redirectToKeycloakWithService1Scope();
>>         >>>> }
>>         >>>>
>>         >>>>
>>         >>>> private void redirectToKeycloakWithService1Scope() {
>>         >>>>? ? ? KeycloakRedirectUriBuilder builder =
>>         ctx.createLoginUrl();
>>         >>>>? ? ? URL url = builder.scope("service1").build();
>>         >>>> httpServletResponse.sendRedirect(url);
>>         >>>> }
>>         >>>>
>>         >>>>
>>         >>>> Regarding the class KeycloakRedirectUriBuilder, I was
>>         thinking about
>>         >>>> this class so that servlet adapter are able to easily
>>         create login URL
>>         >>>> with custom values for things like scope, prompt,
>>         max_age etc. This
>>         >>>> capability is currently missing in servlet adapters and
>>         the current
>>         >>>> approach based on parameters forwarding is a bit clunky
>>         for few
>>         >>>> reasons.
>>         >>>> One reason is usability and the other is, that you need
>>         to logout first.
>>         >>>>
>>         >>>>
>>         >>>> [1]
>>         >>>>
>>         >>>>
>>         https://www.keycloak.org/docs/latest/securing_apps/index.html#javascript-adapter-reference
>>         >>>> [2]
>>         >>>>
>>         >>>>
>>         https://www.keycloak.org/docs/latest/securing_apps/index.html#_params_forwarding
>>         >>>> [3] https://issues.jboss.org/browse/KEYCLOAK-8323
>>         >>>>
>>         >>>> Marek
>>         >>>>
>>         >>>> _______________________________________________
>>         >>>> keycloak-dev mailing list
>>         >>>> keycloak-dev at lists.jboss.org
>>         <mailto:keycloak-dev at lists.jboss.org>
>>         >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>         >>>
>>         >>>
>>         >>>
>>         >>
>>         >
>>         _______________________________________________
>>         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  Thu Feb  7 08:31:54 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 7 Feb 2019 14:31:54 +0100
Subject: [keycloak-dev] Better support for "scope" in adapters
In-Reply-To: <0e13794d-43ea-ab17-5859-91d4ec5e1fcc@redhat.com>
References: <3030a267-b2b6-7a76-3020-42959ef344c5@redhat.com>
	<CAJrcDBep7ScX4O7G5fSh5oPhsbT9B5-ekqhF01MKiikZXB9ywg@mail.gmail.com>
	<e01a6dc8-3163-f132-835b-713b8cfdfc62@redhat.com>
	<CAJrcDBfNE8_8wSDCSrhvcnDa80w1=q=Ngm8wOae5pi9YERKqig@mail.gmail.com>
	<a57ed42b-3f80-21e2-f4e6-7f434030bef4@redhat.com>
	<CAJrcDBcUuiuD4sm5UaXh-BTy70mf+ipR10oHFq08jTS7ntxeUQ@mail.gmail.com>
	<27b5cb1e-cbc0-e79d-03f8-2203cddcf9e3@redhat.com>
	<CAJrcDBcyu+OD4KH0NZ1C=Z81bi+s7GtaTE+Fv8zNSCyOSWLU7A@mail.gmail.com>
	<CAJgngAcRDk3omuu7TVZQC52Os1dB-_tnYyjawZS5bAFYKGjD0g@mail.gmail.com>
	<5f9ca2cf-ef26-87ad-4d54-b00ec695baf5@redhat.com>
	<CAJgngAcrw+Na-VaF_8bSnGutCS4aZqyQXgZ0fhGJv560VTbTuw@mail.gmail.com>
	<0e13794d-43ea-ab17-5859-91d4ec5e1fcc@redhat.com>
Message-ID: <CAJgngAfo=ri32O58XxgBUKA-VxOzjnwEWY9ENga7aDb_NWBTCw@mail.gmail.com>

On Thu, 7 Feb 2019 at 09:40, Marek Posolda <mposolda at redhat.com> wrote:

> On 06/02/2019 15:26, Stian Thorgersen wrote:
>
>
>
> On Wed, 6 Feb 2019 at 11:53, Marek Posolda <mposolda at redhat.com> wrote:
>
>> On 05/02/2019 09:39, Stian Thorgersen wrote:
>>
>> Tried to filter out implementation details here, so may have lost some
>> details. It would be good if we can try to keep discussions at a higher
>> level at least initially as it makes it much easier to follow the
>> discussion.
>>
>> Point taken :) Will try to improve next time.
>>
>>
>> For scopes I can see the most common use-case will be the ability to do
>> incremental scopes. By that I mean the application doesn't request all
>> permissions it may need, but rather starts small and asks for more as the
>> user extends use of the application. This is mostly relevant to
>> applications that require consent.
>>
>> Now with regards to the application being able to have different tokens
>> to invoke different services I'm not convinced this is needed so we should
>> rather wait for demand here. There's two ways a single app can consume
>> multiple services:
>>
>> 1) Application directly invokes multiple services - in this case the
>> application should be able to use scopes or token exchange to obtain tokens
>> to invoke different services. In fact I'd say token exchange is probably
>> what is wanted here rather than scopes.
>> 2) Application invokes a backend service that aggregates multiple
>> services - in this case token exchange comes in as the backend service
>> needs to be able to obtain tokens to invoke the different services
>>
>> I would think option 2 is the best approach as it allows implementing the
>> complex code in server side code and also makes the application more
>> transparent to API changes.
>>
>> This seems to be inline with what Pedro mentioned as well. +1 for waiting
>> for a demand for this.
>>
>>
>> With regards to incremental scope support we need to be able to do that
>> without requiring logout. For JS adapter that should already work, but it
>> has one issue and that is you can't set the scope to use with automated
>> login. We should probably make the scope configurable in the init function
>> as well as when invoking login function directly. For servlet we should
>> probably also have a way to configure the initial scope and expose a method
>> to obtain additional scopes without requiring logout.
>>
>> +1
>>
>> Regarding JS adapter, there are few other things, which you can't do at
>> "init" method. For example adding the "prompt" . Maybe all the current
>> options of "login" method can be just used as arguments to "init" method?
>>
> Or perhaps it should be something like defaultLoginOptions which is an
> object that we simply pass to the login function?
>
> Was thinking about that as well :) It will be probably better as if
> someone wants to call "keycloak.login" and override just single thing (EG.
> scope), he can clone the defaultLoginOptions and override just scope.
>

Can you create a JIRA for it?


> For the servlet adapter, it will be probably good to have something like
>> JS adapter "keycloak.login" method or "keycloak.createLoginUrl", which
>> allows to add things like custom scope, prompt etc. I proposed something
>> like KeycloakLoginUrlBuilder, which will allow to easy add things like
>> "scope" or "prompt" in the adapters code.
>>
> Isn't really what you want is server-side action that returns the redirect
> rather than directly adding the login url to the page? The reason I'm
> saying that is that the adapter needs to generate the state param and such,
> which it can't do if the login url is just placed directly on the page.
>
> I did not mean to directly add URL to the page, but rather something along
> the lines of:
>
> KeycloakLoginRedirectURL loginRedirect = KeycloakLoginRedirectURLBuilder
>         .prompt("consent")
>         .scope(accessToken.getScope() + " phone")
>         .build();
>
> getKeycloakSecurityContext().sendRedirectToLogin(loginRedirect);
>
> Note that when you call "sendRedirectToLogin", it will the responsibility
> of the adapter to generate "state" and add "redirect_uri" from the
> keycloak.json config etc. Maybe KeycloakLoginRedirectURL is not the best
> name for this, rather something like "KeycloakLoginRedirect" or
> "KeycloakLoginRedirectState", but that's an implementation detail.
>

Got it. That makes sense. Can you create a JIRA?


> Marek
>
>
>> I'm not convinced about client scope inheritance. It has an additional
>> implementation complexity, but most importantly usability with regards to
>> understand what is actually included in the token when you have
>> inheritance. It may also have some strange side-effects like how do you
>> make sure the order of what is applied is correct. Again, probably
>> something best left until there is demand for it.
>>
>> We already have "priority" on protocolMappers, so ordering likely won't
>> be an issue. You can add protocolMappers of all the "effective" client
>> scopes and sort the protocol mappers. But agree that will be good to wait
>> for more demand before adding this.
>>
>> Marek
>>
>> On Thu, 31 Jan 2019 at 17:04, Pedro Igor Silva <psilva at redhat.com> wrote:
>>
>>> +1
>>>
>>> On Thu, Jan 31, 2019 at 11:14 AM Marek Posolda <mposolda at redhat.com>
>>> wrote:
>>>
>>> > On 31/01/2019 14:07, Pedro Igor Silva wrote:
>>> >
>>> > This what I like most about client scopes (in addition to all mapping
>>> you
>>> > do to claims in the tokens) :) Would also make sense to do the same
>>> thing
>>> > to client scopes ? So clients requesting "foo" would also get "bar" and
>>> > "xpto", for instance ?
>>> >
>>> > Maybe this could avoid the client to request 10 scopes but just a more
>>> > coarse-grained scope representing all of them.
>>> >
>>> > There is opened JIRA for client scopes inheritance
>>> > https://issues.jboss.org/browse/KEYCLOAK-6633 . I believe this will
>>> cover
>>> > what you have in mind? It's just not yet done...
>>> >
>>> > Marek
>>> >
>>> >
>>> >
>>> > On Thu, Jan 31, 2019 at 10:43 AM Marek Posolda <mposolda at redhat.com>
>>> > wrote:
>>> >
>>> >> On 30/01/2019 14:40, Pedro Igor Silva wrote:
>>> >>
>>> >>
>>> >>
>>> >> On Wed, Jan 30, 2019 at 5:25 AM Marek Posolda <mposolda at redhat.com>
>>> >> wrote:
>>> >>
>>> >>> On 29/01/2019 19:49, Pedro Igor Silva wrote:
>>> >>>
>>> >>> I'm not sure if we need to consider that in our adapters.
>>> >>>
>>> >>> Usually, the front-end knows the set of scopes that it needs to
>>> interact
>>> >>> with the backend and stay functional.
>>> >>>
>>> >>> Maybe. I am personally not sure how people expect to use "scope"
>>> >>> parameters in their frontend applications. Maybe 90% of frontend
>>> clients
>>> >>> don't need to use "scope" parameter at all. And from the remaining,
>>> they
>>> >>> will be fine with the current support of the "scope" parameter.
>>> >>>
>>> >> I would say so, mainly because I think people are still using RBAC to
>>> >> enforce access to APIs. Enterprise scenarios don't really use scopes
>>> as
>>> >> they are more related with delegation.
>>> >>
>>> >> Yeah, maybe. Just a note that our client scopes support also allows to
>>> >> limit roles in the token. For example you can define role scope
>>> mappings of
>>> >> client scope "service1" to have role "service1.my-service1-role" . So
>>> by
>>> >> requesting "scope=service1", you will also receive this role in the
>>> token
>>> >> and hence can be used for RBAC based authorization.
>>> >>
>>> >> But anyway, I probably won't create any JIRAs for now. Will wait if
>>> there
>>> >> is some more feedback or some more requests for better support of
>>> "scope"
>>> >> parameter in the adapters.
>>> >>
>>> >> Thanks for the feedback Pedro!
>>> >>
>>> >> Marek
>>> >>
>>> >> One possibility, where I can see usage of this, is when frontend
>>> client
>>> >>> wants to invoke multiple different services and he wants to use
>>> different
>>> >>> access tokens with properly "isolated" audiences. So for example you
>>> want
>>> >>> to have:
>>> >>>
>>> >>> - access token with "scope=service1", which will have in itself
>>> audience
>>> >>> claim "aud: service1" and you will use it to invoke backend service1
>>> >>> - access token with "scope=service2", which will have in itself
>>> audience
>>> >>> claim "aud: service2" and you will use it to invoke backend service2
>>> >>>
>>> >>> In this case, having the possibility for adapters to "cache" multiple
>>> >>> tokens for various scopes can be beneficial IMO, so client can easily
>>> >>> retrieve proper access token based on the service he wants to invoke.
>>> >>>
>>> >>> And the backend by itself is free to exchange tokens to call other
>>> >>> services (service chaining).
>>> >>>
>>> >>> Don't think that brings a lot of complexity to the front-end and,
>>> >> probably, indicates a bad design?
>>> >>
>>> >>> IMO in many cases, you're right. For example when frontend client
>>> uses
>>> >>> access token to invoke backend "service1", this backend may want to
>>> >>> retrieve some other data from "service11". So service1 backend needs
>>> to
>>> >>> reuse the token or he wants to exchange this token.
>>> >>>
>>> >>> But in many cases, you want to avoid this. So in my example above,
>>> when
>>> >>> you have access token with "aud: service1", you want this access
>>> token to
>>> >>> be used solely to invoke service1. You don't want to have one huge
>>> access
>>> >>> token, which will have all the audiences like:
>>> >>>
>>> >>> aud: [ "service1", "service2" ]
>>> >>>
>>> >> The access token is also tied with the client, what means "this
>>> client is
>>> >> allowed to invoke service1 and service2". I usually don't see a
>>> problem on
>>> >> that if you consider that multiple audiences mean that a high degree
>>> of
>>> >> trust between the parties involved. What I think is true for most
>>> >> enterprise use cases where the front-end is basically accessing
>>> internal
>>> >> services.
>>> >>
>>> >> It is also worthy to consider, IMO, that the fact that you have
>>> distinct
>>> >> services, does not mean they are not part of the same API, thus the
>>> same
>>> >> audience.
>>> >>
>>> >>> You may want separate access tokens with isolated audiences exactly
>>> >>> because you don't want service1 and service2 to be able to invoke
>>> each
>>> >>> other. IMO this isolation is one of the main usages of the "aud"
>>> claim in
>>> >>> the tokens.
>>> >>>
>>> >>>
>>> >>> One thing that makes sense though is "incremental authorization" and
>>> >>> allow apps to request additional scopes during an authentication
>>> session,
>>> >>> so the app gets what was previously granted and the new scopes
>>> (depending
>>> >>> on user consent). But I think we support that already, right ?
>>> >>>
>>> >>> We don't support it directly and maybe this is something to improve.
>>> ATM
>>> >>> you will need programatically do something like this:
>>> >>>
>>> >>> String existingScope = existingAccessToken.getScope();
>>> >>>
>>> >>> // I want to use existingScope and add "phone" scope to it
>>> >>> String newScope = existingScope + " phone";
>>> >>>
>>> >>> // Request the login for new scope now
>>> >>>
>>> >>>
>>> >>> The part of "requesting login for new scope" is possible with
>>> javascript
>>> >>> adapter, but not easily with the "java" adapter. With java adapter,
>>> there
>>> >>> is no easy way to manually "build" URL to sent to OIDC authentication
>>> >>> endpoint (equivalent of keycloak.js method "createLoginUrl"). That's
>>> also
>>> >>> one of the things, which I proposed to improve in this email thread.
>>> >>>
>>> >> Marek
>>> >>>
>>> >>>
>>> >>> Regards.
>>> >>> Pedro Igor
>>> >>>
>>> >>> On Tue, Jan 29, 2019 at 9:36 AM Marek Posolda <mposolda at redhat.com>
>>> >>> wrote:
>>> >>>
>>> >>>> During my work on Client Scopes last year, I did not any work on the
>>> >>>> adapters side. I think there is a space for improvement here. I will
>>> >>>> try
>>> >>>> to summary current issues and some initial proposals for improve
>>> >>>> things.
>>> >>>> Suggestions welcomed! And sorry for longer email :)
>>> >>>>
>>> >>>>
>>> >>>> Both javascript adapter and servlet adapter has some way for
>>> requesting
>>> >>>> the additional "scope" and ensure that that initial OIDC
>>> authentication
>>> >>>> request sent to Keycloak will contain some custom "scope" parameter.
>>> >>>> The
>>> >>>> javascript adapter has support for "scope" as an option of the
>>> "login"
>>> >>>> method [1]. The servlet adapter has a possibility to inject custom
>>> >>>> "scope" with parameters forwarding [2]. I am not sure about node.js
>>> and
>>> >>>> other adapters TBH. But even for javascript and servlet adapter, the
>>> >>>> current support is quite limited for few reasons. For example:
>>> >>>>
>>> >>>> - The approach of parameters forwarding used in servlet adapters
>>> >>>> requires to logout before requesting the additional scope. Because
>>> >>>> when
>>> >>>> I am already authenticated in the application and I open secured URL
>>> >>>> like http://localhost/app/secured?scope=some-custom-scope, the
>>> adapter
>>> >>>> will just ignore it in case that user is already logged-in and it
>>> will
>>> >>>> automatically forward to the application.
>>> >>>>
>>> >>>> - Both servlet and javascript adapters support to have just single
>>> >>>> "triplet" of tokens per browser session. In this context "triplet"
>>> >>>> means
>>> >>>> the single set of 3 tokens (ID token , Access Token , Refresh
>>> token).
>>> >>>> So
>>> >>>> for example when I want to request the custom scope for being able
>>> to
>>> >>>> invoke "service1", I can use "scope=service1". However after
>>> Keycloak
>>> >>>> redirects me back to the application, the existing triplet of
>>> tokens is
>>> >>>> just replaced with the new one for "service1" . Then when I want to
>>> >>>> later invoke another service like "service2", I need to request the
>>> >>>> additional scope "scope=service2", which will replace my tokens on
>>> the
>>> >>>> adapter's side with the "service2" tokens . But then later when I
>>> want
>>> >>>> to switch again to "service1", I need to redirect to Keycloak again
>>> as
>>> >>>> the current triplet of tokens for "service1" etc.
>>> >>>>
>>> >>>>
>>> >>>> To improve this limitation, I think that it will be good if adapters
>>> >>>> easily support the following:
>>> >>>>
>>> >>>> - Instead of having single triplet of tokens, it will be good if
>>> >>>> adapters can contain Map of tokens. Key of the map can be "scope"
>>> >>>> parameter. So for example, the adapter will have "default" tokens
>>> >>>> (those, which were used for initial login), the tokens for
>>> "service1"
>>> >>>> and the tokens for "service2" .
>>> >>>>
>>> >>>> - It will be nice if there is easy way to ask adapter for "service1"
>>> >>>> scope. In case that I don't have yet this scope, adapter will
>>> redirect
>>> >>>> me to Keycloak with "scope=service1". If I already have it, adapter
>>> >>>> will
>>> >>>> return me an existing token. If existing access token is expired,
>>> >>>> adapter will refresh the access token for requested scope in the
>>> >>>> background and return me the "updated" token.
>>> >>>>
>>> >>>> - When I want to invoke service1 and I need to use
>>> "scope=service1", I
>>> >>>> usually need just access token and refresh token. I don't need ID
>>> Token
>>> >>>> anymore. I also don't need the "profile" and "email" claims to be
>>> >>>> returned in the new access token. This is related to the JIRA of
>>> having
>>> >>>> the server-side support for client scopes like (always, default,
>>> >>>> optional) instead of current (default, optional) [3]. In other
>>> words,
>>> >>>> the client scopes "profile" and "email" will be default client
>>> scopes,
>>> >>>> which means that if I don't use "scope=openid" in the OIDC initial
>>> >>>> request, the "profile" and "email" will be ommited from the
>>> response as
>>> >>>> well as the ID Token will be ommited from the response.
>>> >>>>
>>> >>>>
>>> >>>> So how to support this on adapters? For Keycloak.js, I can think
>>> about
>>> >>>> some variation of existing "update" method like this:
>>> >>>>
>>> >>>>
>>> >>>> keycloak.updateTokenWithScope('service1',
>>> >>>> 5).success(function(accessToken, refreshed) {
>>> >>>>          if (refreshed) {
>>> >>>>              alert("I had existing accessToken for scope 'service1',
>>> >>>> but
>>> >>>> it needed to be refreshed as it was expired or about to expire in
>>> less
>>> >>>> than 5 seconds");
>>> >>>>          } else {
>>> >>>>              alert('I have accessToken for 'service1',  which didn't
>>> >>>> need to be refreshed');
>>> >>>>          }
>>> >>>>          // I can invoke REST service now with the accessToken
>>> >>>>          ...
>>> >>>>      }).error(function() {
>>> >>>>          alert("Failed to refresh the token OR I don't have yet
>>> scope
>>> >>>> for 'service1' .");
>>> >>>>          // User usually need to call keycloak.login with the
>>> requested
>>> >>>> scope now...
>>> >>>>      });
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> For servlet adapter something like:
>>> >>>>
>>> >>>> KeycloakSecurityContext ctx = ... // Retrieved from
>>> HttpServletRequest
>>> >>>> or Principal as currently
>>> >>>>
>>> >>>> if (ctx.hasScope("service1")) {
>>> >>>>      try {
>>> >>>>          String accessToken = ctx.getScope("service1");
>>> >>>>          // Invoke service1 with accessToken now
>>> >>>>      } catch (TokenRefreshException ex) {
>>> >>>>          log.error("I already had scope for service1, but failed to
>>> >>>> refresh the token. Need to re-login for the scope service1");
>>> >>>>
>>> >>>>          // See method below
>>> >>>>          redirectToKeycloakWithService1Scope();
>>> >>>>      }
>>> >>>> } else {
>>> >>>>      // See method below
>>> >>>>      redirectToKeycloakWithService1Scope();
>>> >>>> }
>>> >>>>
>>> >>>>
>>> >>>> private void redirectToKeycloakWithService1Scope() {
>>> >>>>      KeycloakRedirectUriBuilder builder = ctx.createLoginUrl();
>>> >>>>      URL url = builder.scope("service1").build();
>>> >>>>      httpServletResponse.sendRedirect(url);
>>> >>>> }
>>> >>>>
>>> >>>>
>>> >>>> Regarding the class KeycloakRedirectUriBuilder, I was thinking about
>>> >>>> this class so that servlet adapter are able to easily create login
>>> URL
>>> >>>> with custom values for things like scope, prompt, max_age etc. This
>>> >>>> capability is currently missing in servlet adapters and the current
>>> >>>> approach based on parameters forwarding is a bit clunky for few
>>> >>>> reasons.
>>> >>>> One reason is usability and the other is, that you need to logout
>>> first.
>>> >>>>
>>> >>>>
>>> >>>> [1]
>>> >>>>
>>> >>>>
>>> https://www.keycloak.org/docs/latest/securing_apps/index.html#javascript-adapter-reference
>>> >>>> [2]
>>> >>>>
>>> >>>>
>>> https://www.keycloak.org/docs/latest/securing_apps/index.html#_params_forwarding
>>> >>>> [3] https://issues.jboss.org/browse/KEYCLOAK-8323
>>> >>>>
>>> >>>> Marek
>>> >>>>
>>> >>>> _______________________________________________
>>> >>>> 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  Thu Feb  7 08:32:49 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 7 Feb 2019 14:32:49 +0100
Subject: [keycloak-dev] HELP IN PERSONALING KEYCLOARK AND QUESTIONS
	ABOUT KEYCLOARK
In-Reply-To: <CAAYRsuDVQ38ZDZF-rC9G+Y+2kgucvkaW-8J8XPX7S5MQQ2_3Tg@mail.gmail.com>
References: <CAAYRsuDVQ38ZDZF-rC9G+Y+2kgucvkaW-8J8XPX7S5MQQ2_3Tg@mail.gmail.com>
Message-ID: <CAJgngAcLv7rt4Q5v1365Q0BL5iLoQhN73eDAseFfmLkxLFK2EQ@mail.gmail.com>

This mailing list is for core developers of Keycloak and contributors to
the Keycloak code base. For general questions and help please send specific
questions to the user mailing list (also please don't shout!).

On Thu, 7 Feb 2019 at 04:46, Cristiano Marques <
cristianomarquesadm02 at gmail.com> wrote:

> Hi, i need help some questions about Keycloark, for ex.: Whats your
> principal utility?
> How can me heulp?
> also how personalize the Keycloark?
> Thanks for attention
> Cristiano Marques dos Santos
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From mposolda at redhat.com  Thu Feb  7 13:13:14 2019
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 7 Feb 2019 19:13:14 +0100
Subject: [keycloak-dev] Better support for "scope" in adapters
In-Reply-To: <CAJgngAfo=ri32O58XxgBUKA-VxOzjnwEWY9ENga7aDb_NWBTCw@mail.gmail.com>
References: <3030a267-b2b6-7a76-3020-42959ef344c5@redhat.com>
	<CAJrcDBep7ScX4O7G5fSh5oPhsbT9B5-ekqhF01MKiikZXB9ywg@mail.gmail.com>
	<e01a6dc8-3163-f132-835b-713b8cfdfc62@redhat.com>
	<CAJrcDBfNE8_8wSDCSrhvcnDa80w1=q=Ngm8wOae5pi9YERKqig@mail.gmail.com>
	<a57ed42b-3f80-21e2-f4e6-7f434030bef4@redhat.com>
	<CAJrcDBcUuiuD4sm5UaXh-BTy70mf+ipR10oHFq08jTS7ntxeUQ@mail.gmail.com>
	<27b5cb1e-cbc0-e79d-03f8-2203cddcf9e3@redhat.com>
	<CAJrcDBcyu+OD4KH0NZ1C=Z81bi+s7GtaTE+Fv8zNSCyOSWLU7A@mail.gmail.com>
	<CAJgngAcRDk3omuu7TVZQC52Os1dB-_tnYyjawZS5bAFYKGjD0g@mail.gmail.com>
	<5f9ca2cf-ef26-87ad-4d54-b00ec695baf5@redhat.com>
	<CAJgngAcrw+Na-VaF_8bSnGutCS4aZqyQXgZ0fhGJv560VTbTuw@mail.gmail.com>
	<0e13794d-43ea-ab17-5859-91d4ec5e1fcc@redhat.com>
	<CAJgngAfo=ri32O58XxgBUKA-VxOzjnwEWY9ENga7aDb_NWBTCw@mail.gmail.com>
Message-ID: <af60f8e1-09b6-c9bb-b192-086627348b83@redhat.com>

On 07/02/2019 14:31, Stian Thorgersen wrote:
>
>
> On Thu, 7 Feb 2019 at 09:40, Marek Posolda <mposolda at redhat.com 
> <mailto:mposolda at redhat.com>> wrote:
>
>     On 06/02/2019 15:26, Stian Thorgersen wrote:
>>
>>
>>     On Wed, 6 Feb 2019 at 11:53, Marek Posolda <mposolda at redhat.com
>>     <mailto:mposolda at redhat.com>> wrote:
>>
>>         On 05/02/2019 09:39, Stian Thorgersen wrote:
>>>         Tried to filter out implementation details here, so may have
>>>         lost some details. It would be good if we can try to keep
>>>         discussions at a higher level at least initially as it makes
>>>         it much easier to follow the discussion.
>>         Point taken :) Will try to improve next time.
>>>
>>>         For scopes I can see the most common use-case will be the
>>>         ability to do incremental scopes. By that I mean the
>>>         application doesn't request all permissions it may need, but
>>>         rather starts small and asks for more as the user extends
>>>         use of the application. This is mostly relevant to
>>>         applications that require consent.
>>>
>>>         Now with regards to the application being able to have
>>>         different tokens to invoke different services I'm not
>>>         convinced this is needed so we should rather wait for demand
>>>         here. There's two ways a single app can consume multiple
>>>         services:
>>>
>>>         1) Application directly invokes multiple services - in this
>>>         case the application should be able to use scopes or token
>>>         exchange to obtain tokens to invoke different services. In
>>>         fact I'd say token exchange is probably what is wanted here
>>>         rather than scopes.
>>>         2) Application invokes a backend service that aggregates
>>>         multiple services - in this case token exchange comes in as
>>>         the backend service needs to be able to obtain tokens to
>>>         invoke the different services
>>>
>>>         I would think option 2 is the best approach as it allows
>>>         implementing the complex code in server side code and also
>>>         makes the application more transparent to API changes.
>>         This seems to be inline with what Pedro mentioned as well. +1
>>         for waiting for a demand for this.
>>>
>>>         With regards to incremental scope support we need to be able
>>>         to do that without requiring logout. For JS adapter that
>>>         should already work, but it has one issue and that is you
>>>         can't set the scope to use with automated login. We should
>>>         probably make the scope configurable in the init function as
>>>         well as when invoking login function directly. For servlet
>>>         we should probably also have a way to configure the initial
>>>         scope and expose a method to obtain additional scopes
>>>         without requiring logout.
>>
>>         +1
>>
>>         Regarding JS adapter, there are few other things, which you
>>         can't do at "init" method. For example adding the "prompt" .
>>         Maybe all the current options of "login" method can be just
>>         used as arguments to "init" method?
>>
>>     Or perhaps it should be something like defaultLoginOptions which
>>     is an object that we simply pass to the login function?
>     Was thinking about that as well :) It will be probably better as
>     if someone wants to call "keycloak.login" and override just single
>     thing (EG. scope), he can clone the defaultLoginOptions and
>     override just scope.
>
>
> Can you create a JIRA for it?
Created https://issues.jboss.org/browse/KEYCLOAK-9519
>
>>         For the servlet adapter, it will be probably good to have
>>         something like JS adapter "keycloak.login" method or
>>         "keycloak.createLoginUrl", which allows to add things like
>>         custom scope, prompt etc. I proposed something like
>>         KeycloakLoginUrlBuilder, which will allow to easy add things
>>         like "scope" or "prompt" in the adapters code.
>>
>>     Isn't really what you want is server-side action that returns the
>>     redirect rather than directly adding the login url to the page?
>>     The reason I'm saying that is that the adapter needs to generate
>>     the state param and such, which it can't do if the login url is
>>     just placed directly on the page.
>
>     I did not mean to directly add URL to the page, but rather
>     something along the lines of:
>
>     KeycloakLoginRedirectURL loginRedirect =
>     KeycloakLoginRedirectURLBuilder
>     ??? ??? .prompt("consent")
>     ??? ??? .scope(accessToken.getScope() + " phone")
>     ??? ??? .build();
>
>     getKeycloakSecurityContext().sendRedirectToLogin(loginRedirect);
>
>     Note that when you call "sendRedirectToLogin", it will the
>     responsibility of the adapter to generate "state" and add
>     "redirect_uri" from the keycloak.json config etc. Maybe
>     KeycloakLoginRedirectURL is not the best name for this, rather
>     something like "KeycloakLoginRedirect" or
>     "KeycloakLoginRedirectState", but that's an implementation detail.
>
>
> Got it. That makes sense. Can you create a JIRA?

Created https://issues.jboss.org/browse/KEYCLOAK-9520

Marek

>     Marek
>
>>>
>>>         I'm not convinced about client scope inheritance. It has an
>>>         additional implementation complexity, but most importantly
>>>         usability with regards to understand what is actually
>>>         included in the token when you have inheritance. It may also
>>>         have some strange side-effects like how do you make sure the
>>>         order of what is applied is correct. Again, probably
>>>         something best left until there is demand for it.
>>
>>         We already have "priority" on protocolMappers, so ordering
>>         likely won't be an issue. You can add protocolMappers of all
>>         the "effective" client scopes and sort the protocol mappers.
>>         But agree that will be good to wait for more demand before
>>         adding this.
>>
>>         Marek
>>
>>>         On Thu, 31 Jan 2019 at 17:04, Pedro Igor Silva
>>>         <psilva at redhat.com <mailto:psilva at redhat.com>> wrote:
>>>
>>>             +1
>>>
>>>             On Thu, Jan 31, 2019 at 11:14 AM Marek Posolda
>>>             <mposolda at redhat.com <mailto:mposolda at redhat.com>> wrote:
>>>
>>>             > On 31/01/2019 14:07, Pedro Igor Silva wrote:
>>>             >
>>>             > This what I like most about client scopes (in addition
>>>             to all mapping you
>>>             > do to claims in the tokens) :) Would also make sense
>>>             to do the same thing
>>>             > to client scopes ? So clients requesting "foo" would
>>>             also get "bar" and
>>>             > "xpto", for instance ?
>>>             >
>>>             > Maybe this could avoid the client to request 10 scopes
>>>             but just a more
>>>             > coarse-grained scope representing all of them.
>>>             >
>>>             > There is opened JIRA for client scopes inheritance
>>>             > https://issues.jboss.org/browse/KEYCLOAK-6633 . I
>>>             believe this will cover
>>>             > what you have in mind? It's just not yet done...
>>>             >
>>>             > Marek
>>>             >
>>>             >
>>>             >
>>>             > On Thu, Jan 31, 2019 at 10:43 AM Marek Posolda
>>>             <mposolda at redhat.com <mailto:mposolda at redhat.com>>
>>>             > wrote:
>>>             >
>>>             >> On 30/01/2019 14:40, Pedro Igor Silva wrote:
>>>             >>
>>>             >>
>>>             >>
>>>             >> On Wed, Jan 30, 2019 at 5:25 AM Marek Posolda
>>>             <mposolda at redhat.com <mailto:mposolda at redhat.com>>
>>>             >> wrote:
>>>             >>
>>>             >>> On 29/01/2019 19:49, Pedro Igor Silva wrote:
>>>             >>>
>>>             >>> I'm not sure if we need to consider that in our
>>>             adapters.
>>>             >>>
>>>             >>> Usually, the front-end knows the set of scopes that
>>>             it needs to interact
>>>             >>> with the backend and stay functional.
>>>             >>>
>>>             >>> Maybe. I am personally not sure how people expect to
>>>             use "scope"
>>>             >>> parameters in their frontend applications. Maybe 90%
>>>             of frontend clients
>>>             >>> don't need to use "scope" parameter at all. And from
>>>             the remaining, they
>>>             >>> will be fine with the current support of the "scope"
>>>             parameter.
>>>             >>>
>>>             >> I would say so, mainly because I think people are
>>>             still using RBAC to
>>>             >> enforce access to APIs. Enterprise scenarios don't
>>>             really use scopes as
>>>             >> they are more related with delegation.
>>>             >>
>>>             >> Yeah, maybe. Just a note that our client scopes
>>>             support also allows to
>>>             >> limit roles in the token. For example you can define
>>>             role scope mappings of
>>>             >> client scope "service1" to have role
>>>             "service1.my-service1-role" . So by
>>>             >> requesting "scope=service1", you will also receive
>>>             this role in the token
>>>             >> and hence can be used for RBAC based authorization.
>>>             >>
>>>             >> But anyway, I probably won't create any JIRAs for
>>>             now. Will wait if there
>>>             >> is some more feedback or some more requests for
>>>             better support of "scope"
>>>             >> parameter in the adapters.
>>>             >>
>>>             >> Thanks for the feedback Pedro!
>>>             >>
>>>             >> Marek
>>>             >>
>>>             >> One possibility, where I can see usage of this, is
>>>             when frontend client
>>>             >>> wants to invoke multiple different services and he
>>>             wants to use different
>>>             >>> access tokens with properly "isolated" audiences. So
>>>             for example you want
>>>             >>> to have:
>>>             >>>
>>>             >>> - access token with "scope=service1", which will
>>>             have in itself audience
>>>             >>> claim "aud: service1" and you will use it to invoke
>>>             backend service1
>>>             >>> - access token with "scope=service2", which will
>>>             have in itself audience
>>>             >>> claim "aud: service2" and you will use it to invoke
>>>             backend service2
>>>             >>>
>>>             >>> In this case, having the possibility for adapters to
>>>             "cache" multiple
>>>             >>> tokens for various scopes can be beneficial IMO, so
>>>             client can easily
>>>             >>> retrieve proper access token based on the service he
>>>             wants to invoke.
>>>             >>>
>>>             >>> And the backend by itself is free to exchange tokens
>>>             to call other
>>>             >>> services (service chaining).
>>>             >>>
>>>             >>> Don't think that brings a lot of complexity to the
>>>             front-end and,
>>>             >> probably, indicates a bad design?
>>>             >>
>>>             >>> IMO in many cases, you're right. For example when
>>>             frontend client uses
>>>             >>> access token to invoke backend "service1", this
>>>             backend may want to
>>>             >>> retrieve some other data from "service11". So
>>>             service1 backend needs to
>>>             >>> reuse the token or he wants to exchange this token.
>>>             >>>
>>>             >>> But in many cases, you want to avoid this. So in my
>>>             example above, when
>>>             >>> you have access token with "aud: service1", you want
>>>             this access token to
>>>             >>> be used solely to invoke service1. You don't want to
>>>             have one huge access
>>>             >>> token, which will have all the audiences like:
>>>             >>>
>>>             >>> aud: [ "service1", "service2" ]
>>>             >>>
>>>             >> The access token is also tied with the client, what
>>>             means "this client is
>>>             >> allowed to invoke service1 and service2". I usually
>>>             don't see a problem on
>>>             >> that if you consider that multiple audiences mean
>>>             that a high degree of
>>>             >> trust between the parties involved. What I think is
>>>             true for most
>>>             >> enterprise use cases where the front-end is basically
>>>             accessing internal
>>>             >> services.
>>>             >>
>>>             >> It is also worthy to consider, IMO, that the fact
>>>             that you have distinct
>>>             >> services, does not mean they are not part of the same
>>>             API, thus the same
>>>             >> audience.
>>>             >>
>>>             >>> You may want separate access tokens with isolated
>>>             audiences exactly
>>>             >>> because you don't want service1 and service2 to be
>>>             able to invoke each
>>>             >>> other. IMO this isolation is one of the main usages
>>>             of the "aud" claim in
>>>             >>> the tokens.
>>>             >>>
>>>             >>>
>>>             >>> One thing that makes sense though is "incremental
>>>             authorization" and
>>>             >>> allow apps to request additional scopes during an
>>>             authentication session,
>>>             >>> so the app gets what was previously granted and the
>>>             new scopes (depending
>>>             >>> on user consent). But I think we support that
>>>             already, right ?
>>>             >>>
>>>             >>> We don't support it directly and maybe this is
>>>             something to improve. ATM
>>>             >>> you will need programatically do something like this:
>>>             >>>
>>>             >>> String existingScope = existingAccessToken.getScope();
>>>             >>>
>>>             >>> // I want to use existingScope and add "phone" scope
>>>             to it
>>>             >>> String newScope = existingScope + " phone";
>>>             >>>
>>>             >>> // Request the login for new scope now
>>>             >>>
>>>             >>>
>>>             >>> The part of "requesting login for new scope" is
>>>             possible with javascript
>>>             >>> adapter, but not easily with the "java" adapter.
>>>             With java adapter, there
>>>             >>> is no easy way to manually "build" URL to sent to
>>>             OIDC authentication
>>>             >>> endpoint (equivalent of keycloak.js method
>>>             "createLoginUrl"). That's also
>>>             >>> one of the things, which I proposed to improve in
>>>             this email thread.
>>>             >>>
>>>             >> Marek
>>>             >>>
>>>             >>>
>>>             >>> Regards.
>>>             >>> Pedro Igor
>>>             >>>
>>>             >>> On Tue, Jan 29, 2019 at 9:36 AM Marek Posolda
>>>             <mposolda at redhat.com <mailto:mposolda at redhat.com>>
>>>             >>> wrote:
>>>             >>>
>>>             >>>> During my work on Client Scopes last year, I did
>>>             not any work on the
>>>             >>>> adapters side. I think there is a space for
>>>             improvement here. I will
>>>             >>>> try
>>>             >>>> to summary current issues and some initial
>>>             proposals for improve
>>>             >>>> things.
>>>             >>>> Suggestions welcomed! And sorry for longer email :)
>>>             >>>>
>>>             >>>>
>>>             >>>> Both javascript adapter and servlet adapter has
>>>             some way for requesting
>>>             >>>> the additional "scope" and ensure that that initial
>>>             OIDC authentication
>>>             >>>> request sent to Keycloak will contain some custom
>>>             "scope" parameter.
>>>             >>>> The
>>>             >>>> javascript adapter has support for "scope" as an
>>>             option of the "login"
>>>             >>>> method [1]. The servlet adapter has a possibility
>>>             to inject custom
>>>             >>>> "scope" with parameters forwarding [2]. I am not
>>>             sure about node.js and
>>>             >>>> other adapters TBH. But even for javascript and
>>>             servlet adapter, the
>>>             >>>> current support is quite limited for few reasons.
>>>             For example:
>>>             >>>>
>>>             >>>> - The approach of parameters forwarding used in
>>>             servlet adapters
>>>             >>>> requires to logout before requesting the additional
>>>             scope. Because
>>>             >>>> when
>>>             >>>> I am already authenticated in the application and I
>>>             open secured URL
>>>             >>>> like
>>>             http://localhost/app/secured?scope=some-custom-scope,
>>>             the adapter
>>>             >>>> will just ignore it in case that user is already
>>>             logged-in and it will
>>>             >>>> automatically forward to the application.
>>>             >>>>
>>>             >>>> - Both servlet and javascript adapters support to
>>>             have just single
>>>             >>>> "triplet" of tokens per browser session. In this
>>>             context "triplet"
>>>             >>>> means
>>>             >>>> the single set of 3 tokens (ID token , Access Token
>>>             , Refresh token).
>>>             >>>> So
>>>             >>>> for example when I want to request the custom scope
>>>             for being able to
>>>             >>>> invoke "service1", I can use "scope=service1".
>>>             However after Keycloak
>>>             >>>> redirects me back to the application, the existing
>>>             triplet of tokens is
>>>             >>>> just replaced with the new one for "service1" .
>>>             Then when I want to
>>>             >>>> later invoke another service like "service2", I
>>>             need to request the
>>>             >>>> additional scope "scope=service2", which will
>>>             replace my tokens on the
>>>             >>>> adapter's side with the "service2" tokens . But
>>>             then later when I want
>>>             >>>> to switch again to "service1", I need to redirect
>>>             to Keycloak again as
>>>             >>>> the current triplet of tokens for "service1" etc.
>>>             >>>>
>>>             >>>>
>>>             >>>> To improve this limitation, I think that it will be
>>>             good if adapters
>>>             >>>> easily support the following:
>>>             >>>>
>>>             >>>> - Instead of having single triplet of tokens, it
>>>             will be good if
>>>             >>>> adapters can contain Map of tokens. Key of the map
>>>             can be "scope"
>>>             >>>> parameter. So for example, the adapter will have
>>>             "default" tokens
>>>             >>>> (those, which were used for initial login), the
>>>             tokens for "service1"
>>>             >>>> and the tokens for "service2" .
>>>             >>>>
>>>             >>>> - It will be nice if there is easy way to ask
>>>             adapter for "service1"
>>>             >>>> scope. In case that I don't have yet this scope,
>>>             adapter will redirect
>>>             >>>> me to Keycloak with "scope=service1". If I already
>>>             have it, adapter
>>>             >>>> will
>>>             >>>> return me an existing token. If existing access
>>>             token is expired,
>>>             >>>> adapter will refresh the access token for requested
>>>             scope in the
>>>             >>>> background and return me the "updated" token.
>>>             >>>>
>>>             >>>> - When I want to invoke service1 and I need to use
>>>             "scope=service1", I
>>>             >>>> usually need just access token and refresh token. I
>>>             don't need ID Token
>>>             >>>> anymore. I also don't need the "profile" and
>>>             "email" claims to be
>>>             >>>> returned in the new access token. This is related
>>>             to the JIRA of having
>>>             >>>> the server-side support for client scopes like
>>>             (always, default,
>>>             >>>> optional) instead of current (default, optional)
>>>             [3]. In other words,
>>>             >>>> the client scopes "profile" and "email" will be
>>>             default client scopes,
>>>             >>>> which means that if I don't use "scope=openid" in
>>>             the OIDC initial
>>>             >>>> request, the "profile" and "email" will be ommited
>>>             from the response as
>>>             >>>> well as the ID Token will be ommited from the response.
>>>             >>>>
>>>             >>>>
>>>             >>>> So how to support this on adapters? For
>>>             Keycloak.js, I can think about
>>>             >>>> some variation of existing "update" method like this:
>>>             >>>>
>>>             >>>>
>>>             >>>> keycloak.updateTokenWithScope('service1',
>>>             >>>> 5).success(function(accessToken, refreshed) {
>>>             >>>>? ? ? ? ? if (refreshed) {
>>>             >>>>? ? ? ? ? ? ? alert("I had existing accessToken for
>>>             scope 'service1',
>>>             >>>> but
>>>             >>>> it needed to be refreshed as it was expired or
>>>             about to expire in less
>>>             >>>> than 5 seconds");
>>>             >>>>? ? ? ? ? } else {
>>>             >>>>? ? ? ? ? ? ? alert('I have accessToken for
>>>             'service1',? which didn't
>>>             >>>> need to be refreshed');
>>>             >>>>? ? ? ? ? }
>>>             >>>>? ? ? ? ? // I can invoke REST service now with the
>>>             accessToken
>>>             >>>>? ? ? ? ? ...
>>>             >>>>? ? ? }).error(function() {
>>>             >>>>? ? ? ? ? alert("Failed to refresh the token OR I
>>>             don't have yet scope
>>>             >>>> for 'service1' .");
>>>             >>>>? ? ? ? ? // User usually need to call
>>>             keycloak.login with the requested
>>>             >>>> scope now...
>>>             >>>>? ? ? });
>>>             >>>>
>>>             >>>>
>>>             >>>>
>>>             >>>>
>>>             >>>> For servlet adapter something like:
>>>             >>>>
>>>             >>>> KeycloakSecurityContext ctx = ... // Retrieved from
>>>             HttpServletRequest
>>>             >>>> or Principal as currently
>>>             >>>>
>>>             >>>> if (ctx.hasScope("service1")) {
>>>             >>>>? ? ? try {
>>>             >>>>? ? ? ? ? String accessToken = ctx.getScope("service1");
>>>             >>>>? ? ? ? ? // Invoke service1 with accessToken now
>>>             >>>>? ? ? } catch (TokenRefreshException ex) {
>>>             >>>>? ? ? ? ? log.error("I already had scope for
>>>             service1, but failed to
>>>             >>>> refresh the token. Need to re-login for the scope
>>>             service1");
>>>             >>>>
>>>             >>>>? ? ? ? ? // See method below
>>>             >>>> redirectToKeycloakWithService1Scope();
>>>             >>>>? ? ? }
>>>             >>>> } else {
>>>             >>>>? ? ? // See method below
>>>             >>>> redirectToKeycloakWithService1Scope();
>>>             >>>> }
>>>             >>>>
>>>             >>>>
>>>             >>>> private void redirectToKeycloakWithService1Scope() {
>>>             >>>> KeycloakRedirectUriBuilder builder =
>>>             ctx.createLoginUrl();
>>>             >>>>? ? ? URL url = builder.scope("service1").build();
>>>             >>>> httpServletResponse.sendRedirect(url);
>>>             >>>> }
>>>             >>>>
>>>             >>>>
>>>             >>>> Regarding the class KeycloakRedirectUriBuilder, I
>>>             was thinking about
>>>             >>>> this class so that servlet adapter are able to
>>>             easily create login URL
>>>             >>>> with custom values for things like scope, prompt,
>>>             max_age etc. This
>>>             >>>> capability is currently missing in servlet adapters
>>>             and the current
>>>             >>>> approach based on parameters forwarding is a bit
>>>             clunky for few
>>>             >>>> reasons.
>>>             >>>> One reason is usability and the other is, that you
>>>             need to logout first.
>>>             >>>>
>>>             >>>>
>>>             >>>> [1]
>>>             >>>>
>>>             >>>>
>>>             https://www.keycloak.org/docs/latest/securing_apps/index.html#javascript-adapter-reference
>>>             >>>> [2]
>>>             >>>>
>>>             >>>>
>>>             https://www.keycloak.org/docs/latest/securing_apps/index.html#_params_forwarding
>>>             >>>> [3] https://issues.jboss.org/browse/KEYCLOAK-8323
>>>             >>>>
>>>             >>>> Marek
>>>             >>>>
>>>             >>>> _______________________________________________
>>>             >>>> keycloak-dev mailing list
>>>             >>>> keycloak-dev at lists.jboss.org
>>>             <mailto:keycloak-dev at lists.jboss.org>
>>>             >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>             >>>
>>>             >>>
>>>             >>>
>>>             >>
>>>             >
>>>             _______________________________________________
>>>             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 chris.smith at cmfirstgroup.com  Thu Feb  7 16:56:30 2019
From: chris.smith at cmfirstgroup.com (Chris Smith)
Date: Thu, 7 Feb 2019 21:56:30 +0000
Subject: [keycloak-dev] [keycloak-user] Get a GSSCredential when user
 browser is not in Active Directory domain
In-Reply-To: <BN6PR22MB0244E50640E8F70BF5570DA3986F0@BN6PR22MB0244.namprd22.prod.outlook.com>
References: <BN6PR22MB024411A53CDE05035A0EEB1198990@BN6PR22MB0244.namprd22.prod.outlook.com>
	<BN6PR22MB02446F8141FBA0DD80FB7E6A98990@BN6PR22MB0244.namprd22.prod.outlook.com>
	<CY4PR22MB0248BF0B11C97A1D9E4EA1C798960@CY4PR22MB0248.namprd22.prod.outlook.com>
	<1548656466.19952.3.camel@acutus.pro>
	<8eb89cb9-f64f-c9c9-a681-4f2a775eaf67@redhat.com>
	<BN6PR22MB0244E50640E8F70BF5570DA3986F0@BN6PR22MB0244.namprd22.prod.outlook.com>
Message-ID: <BN6PR22MB0244CA5FF8E4361117D7F49298680@BN6PR22MB0244.namprd22.prod.outlook.com>

I originally asked this on the user list but I'm making a change to Federation.
I had asked on the dev list earlier about this on the dev as I started to see how this would work
I got the Kerberos Ticket and serialized it to a Base 64 string. it deserializes to a GSSCredential

Now I have to put the Base 64 token into the  access token

Any guidance? 


-----Original Message-----
From: keycloak-user-bounces at lists.jboss.org <keycloak-user-bounces at lists.jboss.org> On Behalf Of Chris Smith
Sent: Thursday, February 7, 2019 2:17 AM
To: Marek Posolda <mposolda at redhat.com>; Dmitry Telegin <dt at acutus.pro>; keycloak-user at lists.jboss.org
Subject: Re: [keycloak-user] Get a GSSCredential when user browser is not in Active Directory domain

So I made a small addition and stepped through the authenticate method

    public Subject authenticateSubject(String username, String password) throws LoginException {
        String principal = getKerberosPrincipal(username);

        logger.debug("Validating password of principal: " + principal);
        loginContext = new LoginContext("does-not-matter", null, createJaasCallbackHandler(principal, password),
            createJaasConfiguration());

        loginContext.login();
        logger.debug("Principal " + principal + " authenticated succesfully");
**        Subject subject = loginContext.getSubject();
**        for (KerberosTicket ticket : subject.getPrivateCredentials(KerberosTicket.class)) {
**            System.out.println(ticket.getClient().getName());
**        }
        return loginContext.getSubject();
    }

The subject that is gotten from the loginContext has one KerberosTicket  private credential

Googling has not given me any insight on where I go from here.

Do you have any suggestions?

-----Original Message-----
From: Marek Posolda <mposolda at redhat.com>
Sent: Tuesday, January 29, 2019 4:07 AM
To: Dmitry Telegin <dt at acutus.pro>; Chris Smith <chris.smith at cmfirstgroup.com>; keycloak-user at lists.jboss.org
Subject: Re: [keycloak-user] Get a GSSCredential when user browser is not in Active Directory domain

+1

GSSCredential is used just during SPNEGO authentication. You may possibly change the built-in authentication flows or userStorage provider, so that after verification with username/password, the GSSCredential will be somehow obtained from the JAAS Subject used for the authentication (See class KerberosUsernamePasswordAuthenticator for the details).

However I am not sure if this is really possible and it will require some more deep-dive into the Keycloak codebase and Kerberos implementation in JDK... Just a hint...

Marek

On 28/01/2019 07:21, Dmitry Telegin wrote:
> Hello Chris,
>
> AFAIK GSSCredential is something very specific to Kerberos, so I'm not sure it's possible at all to obtain it outside of Kerberos context, like e.g. via pure LDAP authentication.
>
> Cheers,
> Dmitry
>
> On Mon, 2019-01-28 at 03:04 +0000, Chris Smith wrote:
>> Does anyone have feedback about getting a delegated GSSCredential?
>>
>> -----Original Message-----
>>> From: keycloak-user-bounces at lists.jboss.org
>>> <keycloak-user-bounces at lists.jboss.org> On Behalf Of Chris Smith
>> Sent: Wednesday, January 23, 2019 10:12 PM
>> To: keycloak-user at lists.jboss.org
>> Subject: Re: [keycloak-user] Get a GSSCredential when user browser is 
>> not in Active Directory domain
>>
>> Here is a Diagram of what I'm trying to do
>>
>> From: Chris Smith
>> Sent: Wednesday, January 23, 2019 8:08 AM
>>>> To: 'keycloak-user at lists.jboss.org' <keycloak-user at lists.jboss.org>
>> Subject: Get a GSSCredential when user browser is not in Active 
>> Directory domain
>>
>> I have setup my servlet to authenticate a user my web app using 
>> Keycloak Active Directory ldap user federation
>>
>> I can get a Delegated GSSCredential when the SPNEGO enabled browser??runs on a workstation in the AD domain.
>> When the browser workstation is not a member of the AD Domain, Keycloak will authenticate the user id and password entered on the keycloak login page, but there will not be a Delegated GSSCredential in the Access Token in my servlet.
>>
>> I have a requirement to use the GSSCredential to call programs on an IBM i (AS/400) and JDBC to the IBM i.??My IBM i is configured to accept a Kerberos Ticket from Active Directory as an authenticated credential (aka EIM, Enterprise Identity Mapping).
>>
>> Less than 1% of the users will be using browsers on workstations in the Active Directory domain.
>>
>> Can Keycloak put a GSSCredential for the logged in user??in the Access Token when SPNEGO is not available from the browser?
>>
>>
>>
>> _______________________________________________
>> 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



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


From luke at code-house.org  Thu Feb  7 19:27:02 2019
From: luke at code-house.org (luke at code-house.org)
Date: Fri, 8 Feb 2019 01:27:02 +0100
Subject: [keycloak-dev] Authentication SPI - Pinning the IDP
In-Reply-To: <CA+AP+fPA7YRmf_vUzCiU2kegp0xQVv35GWSX7zO06Xvif0L39A@mail.gmail.com>
References: <CA+AP+fPA7YRmf_vUzCiU2kegp0xQVv35GWSX7zO06Xvif0L39A@mail.gmail.com>
Message-ID: <6EAB1B4D-DFDC-43D5-9878-38FEDC58B5DA@code-house.org>

I come across same issue, have you any found solution?

Best regards,
?ukasz

> On 9 Nov 2018, at 11:11, gambol <gambol99 at gmail.com> wrote:
> 
> Hiya
> 
> Hopefully someone know's a way around this ..
> 
> We have a requirement to pin a keycloak client to a specific group of login
> options i.e. they can only login via a social provider and not a local
> username/password, BUT we also wish to allow certain users the ability to
> override the behavior. I mocked up authenticator which used the
> IdentityProviderSpi.IDENTITY_PROVIDER_SPI_NAME checked it against the a
> configurable list for the authenticator and also looked for a user override
> attribute. Now on first login that works fine, but as the access token
> comes up for refresh the IdentityProviderSpi.IDENTITY_PROVIDER_SPI_NAME is
> not retained (i guess because it's now a sso session refresh and not a
> login) and so the authenticator throws the error message.
> 
> Is it possible to hook into login only? .. Anyone think of another way
> around it? :-) .. I tried using SetClientNotes / SetAuthNote to retain the
> logged in provider, but that doesn't appear to work either.
> 
> Disclaimer: I know the official stance would be the IDP provides
> authentication only with authorization handled by the application end, but
> in many case's third party applications can't support this .. so was hoping
> we could control it at source.
> 
> Rohith
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From gambol99 at gmail.com  Fri Feb  8 04:50:13 2019
From: gambol99 at gmail.com (gambol)
Date: Fri, 8 Feb 2019 09:50:13 +0000
Subject: [keycloak-dev] Authentication SPI - Pinning the IDP
In-Reply-To: <6EAB1B4D-DFDC-43D5-9878-38FEDC58B5DA@code-house.org>
References: <CA+AP+fPA7YRmf_vUzCiU2kegp0xQVv35GWSX7zO06Xvif0L39A@mail.gmail.com>
	<6EAB1B4D-DFDC-43D5-9878-38FEDC58B5DA@code-house.org>
Message-ID: <CA+AP+fP+-mpB9zLhPWht4xY48nLqRypWSOg+SoqdCFixsNxMsg@mail.gmail.com>

Hi Luke

Unfortunately I didn't find a solution, though we've not moved off v4.5.0
yet so hoping something is in the latest or the very least on the horizon
:-(

Rohith


On Fri, Feb 8, 2019, 12:27 AM <luke at code-house.org wrote:

> I come across same issue, have you any found solution?
>
> Best regards,
> ?ukasz
>
> > On 9 Nov 2018, at 11:11, gambol <gambol99 at gmail.com> wrote:
> >
> > Hiya
> >
> > Hopefully someone know's a way around this ..
> >
> > We have a requirement to pin a keycloak client to a specific group of
> login
> > options i.e. they can only login via a social provider and not a local
> > username/password, BUT we also wish to allow certain users the ability to
> > override the behavior. I mocked up authenticator which used the
> > IdentityProviderSpi.IDENTITY_PROVIDER_SPI_NAME checked it against the a
> > configurable list for the authenticator and also looked for a user
> override
> > attribute. Now on first login that works fine, but as the access token
> > comes up for refresh the IdentityProviderSpi.IDENTITY_PROVIDER_SPI_NAME
> is
> > not retained (i guess because it's now a sso session refresh and not a
> > login) and so the authenticator throws the error message.
> >
> > Is it possible to hook into login only? .. Anyone think of another way
> > around it? :-) .. I tried using SetClientNotes / SetAuthNote to retain
> the
> > logged in provider, but that doesn't appear to work either.
> >
> > Disclaimer: I know the official stance would be the IDP provides
> > authentication only with authorization handled by the application end,
> but
> > in many case's third party applications can't support this .. so was
> hoping
> > we could control it at source.
> >
> > Rohith
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>

From mauriciogiacomini at hotmail.com  Fri Feb  8 05:36:47 2019
From: mauriciogiacomini at hotmail.com (=?iso-8859-1?Q?Maur=EDcio_Giacomini_Penteado?=)
Date: Fri, 8 Feb 2019 10:36:47 +0000
Subject: [keycloak-dev] Keycloak and Webseal (IBM Identity provider)
	integration
Message-ID: <CY4PR07MB34947DDF24505E07EB13B9E7A8690@CY4PR07MB3494.namprd07.prod.outlook.com>

Hi folks,

The systems on which I am currently working, have used Webseal (an IBM's Identity provider) for about 10 years. It providing SAML tokens.
I had some experience on my last job with Keycloak, OAuth, OpenID and UMA. On my point of view these technologies work a lot better then only a SAML token identity manager.

Please, I would like to know if somebody has expertise on Webseal,  if it is possible to have both Webseal and Keycloak managing Identity tokens or some idea about how to migrate from Webseal to Keycloak.

Kind regards,
Mauricio.


From ssilvert at redhat.com  Fri Feb  8 14:00:39 2019
From: ssilvert at redhat.com (Stan Silvert)
Date: Fri, 8 Feb 2019 14:00:39 -0500
Subject: [keycloak-dev] Testsuite broken?
Message-ID: <f3490cd7-b89b-0dfd-6b7c-eda2eb31e92f@redhat.com>

Trying to run tests locally.? I did a clean build from master. Anyone 
know what is wrong?

java.lang.RuntimeException: RESTEASY003325: Failed to construct public 
org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher)
 ??? at 
org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:166)
 ??? at 
org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2757)
 ??? at 
org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:363)
 ??? at 
org.jboss.resteasy.spi.ResteasyDeployment.startInternal(ResteasyDeployment.java:276)
 ??? at 
org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:88)
 ??? at 
org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:119)
 ??? at 
org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36)
 ??? at 
io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117)
 ??? at 
io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:300)
 ??? at 
io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:140)
 ??? at 
io.undertow.servlet.core.DeploymentManagerImpl$2.call(DeploymentManagerImpl.java:583)
 ??? at 
io.undertow.servlet.core.DeploymentManagerImpl$2.call(DeploymentManagerImpl.java:554)
 ??? at 
io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42)
 ??? at 
io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
 ??? at 
io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:596)
 ??? at 
org.jboss.resteasy.plugins.server.undertow.UndertowJaxrsServer.deploy(UndertowJaxrsServer.java:270)
 ??? at 
org.keycloak.testsuite.arquillian.undertow.KeycloakOnUndertow.start(KeycloakOnUndertow.java:204)
 ??? at 
org.jboss.arquillian.container.impl.ContainerImpl.start(ContainerImpl.java:179)
 ??? at 
org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:137)
 ??? at 
org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:133)
 ??? at 
org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forContainer(ContainerLifecycleController.java:208)
 ??? at 
org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startContainer(ContainerLifecycleController.java:133)
 ??? at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 ??? at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
 ??? at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 ??? at java.lang.reflect.Method.invoke(Method.java:498)
 ??? at 
org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
 ??? at 
org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103)
 ??? at 
org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:90)
 ??? at 
org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:54)
 ??? at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 ??? at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
 ??? at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 ??? at java.lang.reflect.Method.invoke(Method.java:498)
 ??? at 
org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
 ??? at 
org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:95)
 ??? at 
org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:133)
 ??? at 
org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:105)
 ??? at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:62)
 ??? at 
org.keycloak.testsuite.arquillian.AuthServerTestEnricher.startAuthContainer(AuthServerTestEnricher.java:321)
 ??? at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 ??? at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
 ??? at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 ??? at java.lang.reflect.Method.invoke(Method.java:498)
 ??? at 
org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
 ??? at 
org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103)
 ??? at 
org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:90)
 ??? at 
org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:133)
 ??? at 
org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:105)
 ??? at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:62)
 ??? at 
org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:83)
 ??? at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 ??? at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
 ??? at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 ??? at java.lang.reflect.Method.invoke(Method.java:498)
 ??? at 
org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
 ??? at 
org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103)
 ??? at 
org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:90)
 ??? at 
org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:69)
 ??? at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 ??? at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
 ??? at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 ??? at java.lang.reflect.Method.invoke(Method.java:498)
 ??? at 
org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
 ??? at 
org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:95)
 ??? at 
org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:133)
 ??? at 
org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:105)
 ??? at 
org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeSuite(EventTestRunnerAdaptor.java:70)
 ??? at 
org.jboss.arquillian.junit.AdaptorManager.initializeAdaptor(AdaptorManager.java:23)
 ??? at 
org.jboss.arquillian.junit.AdaptorManagerWithNotifier.initializeAdaptor(AdaptorManagerWithNotifier.java:19)
 ??? at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:109)
 ??? at 
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367)
 ??? at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
 ??? at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
 ??? at 
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
 ??? at 
org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
 ??? at 
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
 ??? at 
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
Caused by: java.lang.RuntimeException: Failed to connect to database
 ??? at 
org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.getConnection(DefaultJpaConnectionProviderFactory.java:382)
 ??? at 
org.keycloak.connections.jpa.updater.liquibase.lock.LiquibaseDBLockProvider.lazyInit(LiquibaseDBLockProvider.java:65)
 ??? at 
org.keycloak.connections.jpa.updater.liquibase.lock.LiquibaseDBLockProvider.lambda$waitForLock$0(LiquibaseDBLockProvider.java:97)
 ??? at 
org.keycloak.models.utils.KeycloakModelUtils.suspendJtaTransaction(KeycloakModelUtils.java:678)
 ??? at 
org.keycloak.connections.jpa.updater.liquibase.lock.LiquibaseDBLockProvider.waitForLock(LiquibaseDBLockProvider.java:95)
 ??? at 
org.keycloak.services.resources.KeycloakApplication$1.run(KeycloakApplication.java:148)
 ??? at 
org.keycloak.models.utils.KeycloakModelUtils.runJobInTransaction(KeycloakModelUtils.java:227)
 ??? at 
org.keycloak.services.resources.KeycloakApplication.<init>(KeycloakApplication.java:141)
 ??? at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native 
Method)
 ??? at 
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
 ??? at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
 ??? at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
 ??? at 
org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:154)
 ??? ... 77 more
Caused by: java.lang.ClassNotFoundException:
 ??? at java.lang.Class.forName0(Native Method)
 ??? at java.lang.Class.forName(Class.java:264)
 ??? at 
org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.getConnection(DefaultJpaConnectionProviderFactory.java:378)
 ??? ... 89 more


From ssilvert at redhat.com  Fri Feb  8 14:24:40 2019
From: ssilvert at redhat.com (Stan Silvert)
Date: Fri, 8 Feb 2019 14:24:40 -0500
Subject: [keycloak-dev] Testsuite broken?
In-Reply-To: <f3490cd7-b89b-0dfd-6b7c-eda2eb31e92f@redhat.com>
References: <f3490cd7-b89b-0dfd-6b7c-eda2eb31e92f@redhat.com>
Message-ID: <11620a0b-0b95-5339-5fe0-8b8d75f39af1@redhat.com>

Wondering if something has changed recently that causes this to fail 
locally.? The stack trace I posted earlier is what happens if you run 
arquillian testsuite alone.

If I run full testsuite with "mvn test", I get:

[INFO] --- maven-dependency-plugin:3.1.1:unpack (unpack-undertow-server) 
@ integration-arquillian-tests-base ---
[INFO] Configured Artifact: 
org.keycloak.testsuite:integration-arquillian-servers-auth-server-undertow:4.8.3.Final-SNAPSHOT:jar
[INFO] Unpacking 
C:\GitHub\keycloak\testsuite\integration-arquillian\servers\auth-server\undertow\target\classes 
to 
C:\GitHub\keycloak\testsuite\integration-arquillian\tests\base\target\containers\auth-server-undertow 
with includes "*.jks,*.crt,*.truststore" and excludes ""
[INFO] 
------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
[INFO] Keycloak TestSuite 4.8.3.Final-SNAPSHOT ............ SUCCESS [? 
1.308 s]
[INFO] Keycloak Arquillian Integration TestSuite .......... SUCCESS [? 
0.034 s]
[INFO] Servers ............................................ SUCCESS [? 
0.034 s]
[INFO] Auth Server ........................................ SUCCESS [? 
0.036 s]
[INFO] Auth Server Services ............................... SUCCESS [? 
0.040 s]
[INFO] Auth Server Services - Testsuite Providers ......... SUCCESS [? 
2.268 s]
[INFO] Keycloak TestSuite Utils ........................... SUCCESS [? 
1.314 s]
[INFO] Test apps .......................................... SUCCESS [? 
0.036 s]
[INFO] integration-arquillian-test-apps-servlets .......... SUCCESS [? 
0.144 s]
[INFO] Keycloak Integration TestSuite - deprecated ........ SUCCESS 
[03:58 min]
[INFO] Keycloak Tomcat 8 Integration TestSuite ............ SUCCESS [ 
36.763 s]
[INFO] Test apps distribution ............................. SUCCESS [? 
0.861 s]
[INFO] Keycloak Authz: PhotoZ? Test Parent ................ SUCCESS [? 
0.035 s]
[INFO] Keycloak Authz Test: Photoz RESTful API ............ SUCCESS [? 
0.127 s]
[INFO] Keycloak Authz Tests: Photoz HTML5 Client .......... SUCCESS [? 
0.082 s]
[INFO] Keycloak Authz Tests: Photoz Authz Rule-based Policy SUCCESS [? 
0.081 s]
[INFO] Keycloak Authz Tests: Hello World Example .......... SUCCESS [? 
0.094 s]
[INFO] Keycloak Authz: Servlet Authorization Test ......... SUCCESS [? 
0.084 s]
[INFO] Keycloak Authz: Simple Servlet App with Policy Enforcer SUCCESS 
[? 0.069 s]
[INFO] Keycloak Test App Profile JEE ...................... SUCCESS [? 
0.090 s]
[INFO] integration-arquillian-test-apps-cors-parent ....... SUCCESS [? 
0.035 s]
[INFO] Angular Product Portal JS .......................... SUCCESS [? 
0.108 s]
[INFO] JAX-RS Database Service Using OAuth Bearer Tokens .. SUCCESS [? 
0.099 s]
[INFO] Fuse Test Applications ............................. SUCCESS [? 
0.038 s]
[INFO] Customer Portal - Secured in Karaf/Fuse ............ SUCCESS [? 
0.834 s]
[INFO] CXF JAXRS Example - Secured in Karaf/Fuse .......... SUCCESS [? 
0.142 s]
[INFO] CXF JAXRS Example - Secured in Karaf/Fuse 7.0 on Undertow SUCCESS 
[? 0.102 s]
[INFO] CXF JAXWS Example - Secured in Karaf/Fuse .......... SUCCESS [? 
0.584 s]
[INFO] CXF JAXWS Example - Secured in Karaf/Fuse 7.0 on Undertow SUCCESS 
[? 0.264 s]
[INFO] Product Portal - Secured in Karaf/Fuse ............. SUCCESS [? 
0.104 s]
[INFO] Product Portal - Secured in Karaf/Fuse 7.0 on Undertow SUCCESS [? 
0.105 s]
[INFO] Camel endpoint example - Secured in Karaf/Fuse ..... SUCCESS [? 
0.173 s]
[INFO] Camel endpoint example - Secured in Karaf/Fuse 7.0 on Undertow 
SUCCESS [? 0.110 s]
[INFO] Keycloak Fuse Example - Features ................... SUCCESS [? 
0.091 s]
[INFO] Keycloak Examples - External Config ................ SUCCESS [? 
0.252 s]
[INFO] Auth Server - JBoss ................................ SUCCESS [? 
0.034 s]
[INFO] Test Util .......................................... SUCCESS [? 
0.351 s]
[INFO] Auth Server - Undertow ............................. SUCCESS [? 
0.497 s]
[INFO] App Server ......................................... SUCCESS [? 
0.031 s]
[INFO] App Server - SPI ................................... SUCCESS [? 
0.097 s]
[INFO] App Server - JBoss ................................. SUCCESS [? 
0.034 s]
[INFO] App Server - Karaf ................................. SUCCESS [? 
0.031 s]
[INFO] App Server - Tomcat ................................ SUCCESS [? 
0.032 s]
[INFO] App Server - Undertow .............................. SUCCESS [? 
0.167 s]
[INFO] Cache Server ....................................... SUCCESS [? 
0.035 s]
[INFO] Cache Server - JBoss Family ........................ SUCCESS [? 
0.038 s]
[INFO] Tests .............................................. SUCCESS [? 
0.132 s]
[INFO] Base TestSuite ..................................... FAILURE [? 
6.991 s]
[INFO] Other Tests Modules ................................ SKIPPED
[INFO] Adapter Tests ...................................... SKIPPED
[INFO] Adapter Tests - JBoss .............................. SKIPPED
[INFO] Adapter Tests - Karaf .............................. SKIPPED
[INFO] Adapter Tests - Tomcat ............................. SKIPPED
[INFO] Adapter Tests - WAS ................................ SKIPPED
[INFO] Adapter Tests - WLS ................................ SKIPPED
[INFO] SSSD tests ......................................... SKIPPED
[INFO] integration-arquillian-tests-springboot ............ SKIPPED
[INFO] Keycloak Jetty 9.2.x Integration TestSuite ......... SKIPPED
[INFO] Keycloak Jetty 9.3.x Integration TestSuite ......... SKIPPED
[INFO] Keycloak Jetty 9.4.x Integration TestSuite ......... SKIPPED
[INFO] Keycloak SAML Jetty Testsuite Integration .......... SKIPPED
[INFO] Keycloak Security Proxy TestSuite .................. SKIPPED
[INFO] Keycloak Tomcat 7 Integration TestSuite 4.8.3.Final-SNAPSHOT SKIPPED
[INFO] 
------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] 
------------------------------------------------------------------------
[INFO] Total time: 04:55 min
[INFO] Finished at: 2019-02-08T14:19:21-05:00
[INFO] 
------------------------------------------------------------------------
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-dependency-plugin:3.1.1:unpack 
(unpack-undertow-server) on project integration-arquillian-tests-base: 
Artifact has not been packaged yet. When used on reactor artifact, 
unpack should be executed after packaging: see MDEP-98. -> [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/MojoExecutionException
[ERROR]
[ERROR] After correcting the problems, you can resume the build with the 
command
[ERROR]?? mvn <goals> -rf :integration-arquillian-tests-base

On 2/8/2019 2:00 PM, Stan Silvert wrote:
> Trying to run tests locally.? I did a clean build from master. Anyone
> know what is wrong?
>
> java.lang.RuntimeException: RESTEASY003325: Failed to construct public
> org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher)
>   ??? at
> org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:166)
>   ??? at
> org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2757)
>   ??? at
> org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:363)
>   ??? at
> org.jboss.resteasy.spi.ResteasyDeployment.startInternal(ResteasyDeployment.java:276)
>   ??? at
> org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:88)
>   ??? at
> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:119)
>   ??? at
> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36)
>   ??? at
> io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117)
>   ??? at
> io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:300)
>   ??? at
> io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:140)
>   ??? at
> io.undertow.servlet.core.DeploymentManagerImpl$2.call(DeploymentManagerImpl.java:583)
>   ??? at
> io.undertow.servlet.core.DeploymentManagerImpl$2.call(DeploymentManagerImpl.java:554)
>   ??? at
> io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42)
>   ??? at
> io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
>   ??? at
> io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:596)
>   ??? at
> org.jboss.resteasy.plugins.server.undertow.UndertowJaxrsServer.deploy(UndertowJaxrsServer.java:270)
>   ??? at
> org.keycloak.testsuite.arquillian.undertow.KeycloakOnUndertow.start(KeycloakOnUndertow.java:204)
>   ??? at
> org.jboss.arquillian.container.impl.ContainerImpl.start(ContainerImpl.java:179)
>   ??? at
> org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:137)
>   ??? at
> org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:133)
>   ??? at
> org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forContainer(ContainerLifecycleController.java:208)
>   ??? at
> org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startContainer(ContainerLifecycleController.java:133)
>   ??? at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   ??? at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   ??? at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   ??? at java.lang.reflect.Method.invoke(Method.java:498)
>   ??? at
> org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
>   ??? at
> org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103)
>   ??? at
> org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:90)
>   ??? at
> org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:54)
>   ??? at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   ??? at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   ??? at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   ??? at java.lang.reflect.Method.invoke(Method.java:498)
>   ??? at
> org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
>   ??? at
> org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:95)
>   ??? at
> org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:133)
>   ??? at
> org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:105)
>   ??? at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:62)
>   ??? at
> org.keycloak.testsuite.arquillian.AuthServerTestEnricher.startAuthContainer(AuthServerTestEnricher.java:321)
>   ??? at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   ??? at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   ??? at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   ??? at java.lang.reflect.Method.invoke(Method.java:498)
>   ??? at
> org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
>   ??? at
> org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103)
>   ??? at
> org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:90)
>   ??? at
> org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:133)
>   ??? at
> org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:105)
>   ??? at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:62)
>   ??? at
> org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:83)
>   ??? at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   ??? at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   ??? at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   ??? at java.lang.reflect.Method.invoke(Method.java:498)
>   ??? at
> org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
>   ??? at
> org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103)
>   ??? at
> org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:90)
>   ??? at
> org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:69)
>   ??? at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   ??? at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   ??? at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   ??? at java.lang.reflect.Method.invoke(Method.java:498)
>   ??? at
> org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
>   ??? at
> org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:95)
>   ??? at
> org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:133)
>   ??? at
> org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:105)
>   ??? at
> org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeSuite(EventTestRunnerAdaptor.java:70)
>   ??? at
> org.jboss.arquillian.junit.AdaptorManager.initializeAdaptor(AdaptorManager.java:23)
>   ??? at
> org.jboss.arquillian.junit.AdaptorManagerWithNotifier.initializeAdaptor(AdaptorManagerWithNotifier.java:19)
>   ??? at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:109)
>   ??? at
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367)
>   ??? at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
>   ??? at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
>   ??? at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
>   ??? at
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
>   ??? at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
>   ??? at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
> Caused by: java.lang.RuntimeException: Failed to connect to database
>   ??? at
> org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.getConnection(DefaultJpaConnectionProviderFactory.java:382)
>   ??? at
> org.keycloak.connections.jpa.updater.liquibase.lock.LiquibaseDBLockProvider.lazyInit(LiquibaseDBLockProvider.java:65)
>   ??? at
> org.keycloak.connections.jpa.updater.liquibase.lock.LiquibaseDBLockProvider.lambda$waitForLock$0(LiquibaseDBLockProvider.java:97)
>   ??? at
> org.keycloak.models.utils.KeycloakModelUtils.suspendJtaTransaction(KeycloakModelUtils.java:678)
>   ??? at
> org.keycloak.connections.jpa.updater.liquibase.lock.LiquibaseDBLockProvider.waitForLock(LiquibaseDBLockProvider.java:95)
>   ??? at
> org.keycloak.services.resources.KeycloakApplication$1.run(KeycloakApplication.java:148)
>   ??? at
> org.keycloak.models.utils.KeycloakModelUtils.runJobInTransaction(KeycloakModelUtils.java:227)
>   ??? at
> org.keycloak.services.resources.KeycloakApplication.<init>(KeycloakApplication.java:141)
>   ??? at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
>   ??? at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>   ??? at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>   ??? at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
>   ??? at
> org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:154)
>   ??? ... 77 more
> Caused by: java.lang.ClassNotFoundException:
>   ??? at java.lang.Class.forName0(Native Method)
>   ??? at java.lang.Class.forName(Class.java:264)
>   ??? at
> org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.getConnection(DefaultJpaConnectionProviderFactory.java:378)
>   ??? ... 89 more
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



From psilva at redhat.com  Fri Feb  8 15:00:16 2019
From: psilva at redhat.com (Pedro Igor Silva)
Date: Fri, 8 Feb 2019 18:00:16 -0200
Subject: [keycloak-dev] Testsuite broken?
In-Reply-To: <f3490cd7-b89b-0dfd-6b7c-eda2eb31e92f@redhat.com>
References: <f3490cd7-b89b-0dfd-6b7c-eda2eb31e92f@redhat.com>
Message-ID: <CAJrcDBdzGDwjQUxCkqW9qJEpWOSXLEdBBDBKX5uo2zrq4qMdUg@mail.gmail.com>

You are probably missing this last
commit 59430e7cd606480b32b63a46fd12dc1ebd779f2e.

On Fri, Feb 8, 2019 at 5:04 PM Stan Silvert <ssilvert at redhat.com> wrote:

> Trying to run tests locally.  I did a clean build from master. Anyone
> know what is wrong?
>
> java.lang.RuntimeException: RESTEASY003325: Failed to construct public
>
> org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher)
>      at
>
> org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:166)
>      at
>
> org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2757)
>      at
>
> org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:363)
>      at
>
> org.jboss.resteasy.spi.ResteasyDeployment.startInternal(ResteasyDeployment.java:276)
>      at
> org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:88)
>      at
>
> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:119)
>      at
>
> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36)
>      at
>
> io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117)
>      at
>
> io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:300)
>      at
>
> io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:140)
>      at
>
> io.undertow.servlet.core.DeploymentManagerImpl$2.call(DeploymentManagerImpl.java:583)
>      at
>
> io.undertow.servlet.core.DeploymentManagerImpl$2.call(DeploymentManagerImpl.java:554)
>      at
>
> io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42)
>      at
>
> io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
>      at
>
> io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:596)
>      at
>
> org.jboss.resteasy.plugins.server.undertow.UndertowJaxrsServer.deploy(UndertowJaxrsServer.java:270)
>      at
>
> org.keycloak.testsuite.arquillian.undertow.KeycloakOnUndertow.start(KeycloakOnUndertow.java:204)
>      at
>
> org.jboss.arquillian.container.impl.ContainerImpl.start(ContainerImpl.java:179)
>      at
>
> org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:137)
>      at
>
> org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:133)
>      at
>
> org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forContainer(ContainerLifecycleController.java:208)
>      at
>
> org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startContainer(ContainerLifecycleController.java:133)
>      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>      at
>
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>      at
>
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>      at java.lang.reflect.Method.invoke(Method.java:498)
>      at
> org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
>      at
>
> org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103)
>      at
>
> org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:90)
>      at
>
> org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:54)
>      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>      at
>
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>      at
>
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>      at java.lang.reflect.Method.invoke(Method.java:498)
>      at
> org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
>      at
>
> org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:95)
>      at
> org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:133)
>      at
> org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:105)
>      at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:62)
>      at
>
> org.keycloak.testsuite.arquillian.AuthServerTestEnricher.startAuthContainer(AuthServerTestEnricher.java:321)
>      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>      at
>
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>      at
>
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>      at java.lang.reflect.Method.invoke(Method.java:498)
>      at
> org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
>      at
>
> org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103)
>      at
>
> org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:90)
>      at
> org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:133)
>      at
> org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:105)
>      at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:62)
>      at
>
> org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:83)
>      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>      at
>
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>      at
>
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>      at java.lang.reflect.Method.invoke(Method.java:498)
>      at
> org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
>      at
>
> org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103)
>      at
>
> org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:90)
>      at
>
> org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:69)
>      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>      at
>
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>      at
>
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>      at java.lang.reflect.Method.invoke(Method.java:498)
>      at
> org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
>      at
>
> org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:95)
>      at
> org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:133)
>      at
> org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:105)
>      at
>
> org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeSuite(EventTestRunnerAdaptor.java:70)
>      at
>
> org.jboss.arquillian.junit.AdaptorManager.initializeAdaptor(AdaptorManager.java:23)
>      at
>
> org.jboss.arquillian.junit.AdaptorManagerWithNotifier.initializeAdaptor(AdaptorManagerWithNotifier.java:19)
>      at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:109)
>      at
>
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367)
>      at
>
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
>      at
>
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
>      at
>
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
>      at
>
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
>      at
>
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
>      at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
> Caused by: java.lang.RuntimeException: Failed to connect to database
>      at
>
> org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.getConnection(DefaultJpaConnectionProviderFactory.java:382)
>      at
>
> org.keycloak.connections.jpa.updater.liquibase.lock.LiquibaseDBLockProvider.lazyInit(LiquibaseDBLockProvider.java:65)
>      at
>
> org.keycloak.connections.jpa.updater.liquibase.lock.LiquibaseDBLockProvider.lambda$waitForLock$0(LiquibaseDBLockProvider.java:97)
>      at
>
> org.keycloak.models.utils.KeycloakModelUtils.suspendJtaTransaction(KeycloakModelUtils.java:678)
>      at
>
> org.keycloak.connections.jpa.updater.liquibase.lock.LiquibaseDBLockProvider.waitForLock(LiquibaseDBLockProvider.java:95)
>      at
>
> org.keycloak.services.resources.KeycloakApplication$1.run(KeycloakApplication.java:148)
>      at
>
> org.keycloak.models.utils.KeycloakModelUtils.runJobInTransaction(KeycloakModelUtils.java:227)
>      at
>
> org.keycloak.services.resources.KeycloakApplication.<init>(KeycloakApplication.java:141)
>      at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
>      at
>
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>      at
>
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>      at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
>      at
>
> org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:154)
>      ... 77 more
> Caused by: java.lang.ClassNotFoundException:
>      at java.lang.Class.forName0(Native Method)
>      at java.lang.Class.forName(Class.java:264)
>      at
>
> org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.getConnection(DefaultJpaConnectionProviderFactory.java:378)
>      ... 89 more
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From bruno at abstractj.org  Fri Feb  8 17:06:41 2019
From: bruno at abstractj.org (Bruno Oliveira)
Date: Fri, 8 Feb 2019 20:06:41 -0200
Subject: [keycloak-dev] Testsuite broken?
In-Reply-To: <11620a0b-0b95-5339-5fe0-8b8d75f39af1@redhat.com>
References: <f3490cd7-b89b-0dfd-6b7c-eda2eb31e92f@redhat.com>
	<11620a0b-0b95-5339-5fe0-8b8d75f39af1@redhat.com>
Message-ID: <20190208220641.GA12670@abstractj.org>

Based on the latest changes from master I tried this:

mvn clean test -f testsuite/integration-arquillian/tests/base/pom.xml '-Dtest=org.keycloak.testsuite.oidc.UserInfoTest' test 

All the tests are passing. Could you please provide the command you ran?

On 2019-02-08, Stan Silvert wrote:
> Wondering if something has changed recently that causes this to fail 
> locally.? The stack trace I posted earlier is what happens if you run 
> arquillian testsuite alone.
> 
> If I run full testsuite with "mvn test", I get:
> 
> [INFO] --- maven-dependency-plugin:3.1.1:unpack (unpack-undertow-server) 
> @ integration-arquillian-tests-base ---
> [INFO] Configured Artifact: 
> org.keycloak.testsuite:integration-arquillian-servers-auth-server-undertow:4.8.3.Final-SNAPSHOT:jar
> [INFO] Unpacking 
> C:\GitHub\keycloak\testsuite\integration-arquillian\servers\auth-server\undertow\target\classes 
> to 
> C:\GitHub\keycloak\testsuite\integration-arquillian\tests\base\target\containers\auth-server-undertow 
> with includes "*.jks,*.crt,*.truststore" and excludes ""
> [INFO] 
> ------------------------------------------------------------------------
> [INFO] Reactor Summary:
> [INFO]
> [INFO] Keycloak TestSuite 4.8.3.Final-SNAPSHOT ............ SUCCESS [? 
> 1.308 s]
> [INFO] Keycloak Arquillian Integration TestSuite .......... SUCCESS [? 
> 0.034 s]
> [INFO] Servers ............................................ SUCCESS [? 
> 0.034 s]
> [INFO] Auth Server ........................................ SUCCESS [? 
> 0.036 s]
> [INFO] Auth Server Services ............................... SUCCESS [? 
> 0.040 s]
> [INFO] Auth Server Services - Testsuite Providers ......... SUCCESS [? 
> 2.268 s]
> [INFO] Keycloak TestSuite Utils ........................... SUCCESS [? 
> 1.314 s]
> [INFO] Test apps .......................................... SUCCESS [? 
> 0.036 s]
> [INFO] integration-arquillian-test-apps-servlets .......... SUCCESS [? 
> 0.144 s]
> [INFO] Keycloak Integration TestSuite - deprecated ........ SUCCESS 
> [03:58 min]
> [INFO] Keycloak Tomcat 8 Integration TestSuite ............ SUCCESS [ 
> 36.763 s]
> [INFO] Test apps distribution ............................. SUCCESS [? 
> 0.861 s]
> [INFO] Keycloak Authz: PhotoZ? Test Parent ................ SUCCESS [? 
> 0.035 s]
> [INFO] Keycloak Authz Test: Photoz RESTful API ............ SUCCESS [? 
> 0.127 s]
> [INFO] Keycloak Authz Tests: Photoz HTML5 Client .......... SUCCESS [? 
> 0.082 s]
> [INFO] Keycloak Authz Tests: Photoz Authz Rule-based Policy SUCCESS [? 
> 0.081 s]
> [INFO] Keycloak Authz Tests: Hello World Example .......... SUCCESS [? 
> 0.094 s]
> [INFO] Keycloak Authz: Servlet Authorization Test ......... SUCCESS [? 
> 0.084 s]
> [INFO] Keycloak Authz: Simple Servlet App with Policy Enforcer SUCCESS 
> [? 0.069 s]
> [INFO] Keycloak Test App Profile JEE ...................... SUCCESS [? 
> 0.090 s]
> [INFO] integration-arquillian-test-apps-cors-parent ....... SUCCESS [? 
> 0.035 s]
> [INFO] Angular Product Portal JS .......................... SUCCESS [? 
> 0.108 s]
> [INFO] JAX-RS Database Service Using OAuth Bearer Tokens .. SUCCESS [? 
> 0.099 s]
> [INFO] Fuse Test Applications ............................. SUCCESS [? 
> 0.038 s]
> [INFO] Customer Portal - Secured in Karaf/Fuse ............ SUCCESS [? 
> 0.834 s]
> [INFO] CXF JAXRS Example - Secured in Karaf/Fuse .......... SUCCESS [? 
> 0.142 s]
> [INFO] CXF JAXRS Example - Secured in Karaf/Fuse 7.0 on Undertow SUCCESS 
> [? 0.102 s]
> [INFO] CXF JAXWS Example - Secured in Karaf/Fuse .......... SUCCESS [? 
> 0.584 s]
> [INFO] CXF JAXWS Example - Secured in Karaf/Fuse 7.0 on Undertow SUCCESS 
> [? 0.264 s]
> [INFO] Product Portal - Secured in Karaf/Fuse ............. SUCCESS [? 
> 0.104 s]
> [INFO] Product Portal - Secured in Karaf/Fuse 7.0 on Undertow SUCCESS [? 
> 0.105 s]
> [INFO] Camel endpoint example - Secured in Karaf/Fuse ..... SUCCESS [? 
> 0.173 s]
> [INFO] Camel endpoint example - Secured in Karaf/Fuse 7.0 on Undertow 
> SUCCESS [? 0.110 s]
> [INFO] Keycloak Fuse Example - Features ................... SUCCESS [? 
> 0.091 s]
> [INFO] Keycloak Examples - External Config ................ SUCCESS [? 
> 0.252 s]
> [INFO] Auth Server - JBoss ................................ SUCCESS [? 
> 0.034 s]
> [INFO] Test Util .......................................... SUCCESS [? 
> 0.351 s]
> [INFO] Auth Server - Undertow ............................. SUCCESS [? 
> 0.497 s]
> [INFO] App Server ......................................... SUCCESS [? 
> 0.031 s]
> [INFO] App Server - SPI ................................... SUCCESS [? 
> 0.097 s]
> [INFO] App Server - JBoss ................................. SUCCESS [? 
> 0.034 s]
> [INFO] App Server - Karaf ................................. SUCCESS [? 
> 0.031 s]
> [INFO] App Server - Tomcat ................................ SUCCESS [? 
> 0.032 s]
> [INFO] App Server - Undertow .............................. SUCCESS [? 
> 0.167 s]
> [INFO] Cache Server ....................................... SUCCESS [? 
> 0.035 s]
> [INFO] Cache Server - JBoss Family ........................ SUCCESS [? 
> 0.038 s]
> [INFO] Tests .............................................. SUCCESS [? 
> 0.132 s]
> [INFO] Base TestSuite ..................................... FAILURE [? 
> 6.991 s]
> [INFO] Other Tests Modules ................................ SKIPPED
> [INFO] Adapter Tests ...................................... SKIPPED
> [INFO] Adapter Tests - JBoss .............................. SKIPPED
> [INFO] Adapter Tests - Karaf .............................. SKIPPED
> [INFO] Adapter Tests - Tomcat ............................. SKIPPED
> [INFO] Adapter Tests - WAS ................................ SKIPPED
> [INFO] Adapter Tests - WLS ................................ SKIPPED
> [INFO] SSSD tests ......................................... SKIPPED
> [INFO] integration-arquillian-tests-springboot ............ SKIPPED
> [INFO] Keycloak Jetty 9.2.x Integration TestSuite ......... SKIPPED
> [INFO] Keycloak Jetty 9.3.x Integration TestSuite ......... SKIPPED
> [INFO] Keycloak Jetty 9.4.x Integration TestSuite ......... SKIPPED
> [INFO] Keycloak SAML Jetty Testsuite Integration .......... SKIPPED
> [INFO] Keycloak Security Proxy TestSuite .................. SKIPPED
> [INFO] Keycloak Tomcat 7 Integration TestSuite 4.8.3.Final-SNAPSHOT SKIPPED
> [INFO] 
> ------------------------------------------------------------------------
> [INFO] BUILD FAILURE
> [INFO] 
> ------------------------------------------------------------------------
> [INFO] Total time: 04:55 min
> [INFO] Finished at: 2019-02-08T14:19:21-05:00
> [INFO] 
> ------------------------------------------------------------------------
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-dependency-plugin:3.1.1:unpack 
> (unpack-undertow-server) on project integration-arquillian-tests-base: 
> Artifact has not been packaged yet. When used on reactor artifact, 
> unpack should be executed after packaging: see MDEP-98. -> [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/MojoExecutionException
> [ERROR]
> [ERROR] After correcting the problems, you can resume the build with the 
> command
> [ERROR]?? mvn <goals> -rf :integration-arquillian-tests-base
> 
> On 2/8/2019 2:00 PM, Stan Silvert wrote:
> > Trying to run tests locally.? I did a clean build from master. Anyone
> > know what is wrong?
> >
> > java.lang.RuntimeException: RESTEASY003325: Failed to construct public
> > org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher)
> >   ??? at
> > org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:166)
> >   ??? at
> > org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2757)
> >   ??? at
> > org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:363)
> >   ??? at
> > org.jboss.resteasy.spi.ResteasyDeployment.startInternal(ResteasyDeployment.java:276)
> >   ??? at
> > org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:88)
> >   ??? at
> > org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:119)
> >   ??? at
> > org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36)
> >   ??? at
> > io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117)
> >   ??? at
> > io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:300)
> >   ??? at
> > io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:140)
> >   ??? at
> > io.undertow.servlet.core.DeploymentManagerImpl$2.call(DeploymentManagerImpl.java:583)
> >   ??? at
> > io.undertow.servlet.core.DeploymentManagerImpl$2.call(DeploymentManagerImpl.java:554)
> >   ??? at
> > io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42)
> >   ??? at
> > io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> >   ??? at
> > io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:596)
> >   ??? at
> > org.jboss.resteasy.plugins.server.undertow.UndertowJaxrsServer.deploy(UndertowJaxrsServer.java:270)
> >   ??? at
> > org.keycloak.testsuite.arquillian.undertow.KeycloakOnUndertow.start(KeycloakOnUndertow.java:204)
> >   ??? at
> > org.jboss.arquillian.container.impl.ContainerImpl.start(ContainerImpl.java:179)
> >   ??? at
> > org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:137)
> >   ??? at
> > org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:133)
> >   ??? at
> > org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forContainer(ContainerLifecycleController.java:208)
> >   ??? at
> > org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startContainer(ContainerLifecycleController.java:133)
> >   ??? at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >   ??? at
> > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> >   ??? at
> > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> >   ??? at java.lang.reflect.Method.invoke(Method.java:498)
> >   ??? at
> > org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
> >   ??? at
> > org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103)
> >   ??? at
> > org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:90)
> >   ??? at
> > org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:54)
> >   ??? at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >   ??? at
> > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> >   ??? at
> > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> >   ??? at java.lang.reflect.Method.invoke(Method.java:498)
> >   ??? at
> > org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
> >   ??? at
> > org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:95)
> >   ??? at
> > org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:133)
> >   ??? at
> > org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:105)
> >   ??? at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:62)
> >   ??? at
> > org.keycloak.testsuite.arquillian.AuthServerTestEnricher.startAuthContainer(AuthServerTestEnricher.java:321)
> >   ??? at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >   ??? at
> > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> >   ??? at
> > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> >   ??? at java.lang.reflect.Method.invoke(Method.java:498)
> >   ??? at
> > org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
> >   ??? at
> > org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103)
> >   ??? at
> > org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:90)
> >   ??? at
> > org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:133)
> >   ??? at
> > org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:105)
> >   ??? at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:62)
> >   ??? at
> > org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:83)
> >   ??? at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >   ??? at
> > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> >   ??? at
> > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> >   ??? at java.lang.reflect.Method.invoke(Method.java:498)
> >   ??? at
> > org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
> >   ??? at
> > org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103)
> >   ??? at
> > org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:90)
> >   ??? at
> > org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:69)
> >   ??? at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >   ??? at
> > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> >   ??? at
> > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> >   ??? at java.lang.reflect.Method.invoke(Method.java:498)
> >   ??? at
> > org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
> >   ??? at
> > org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:95)
> >   ??? at
> > org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:133)
> >   ??? at
> > org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:105)
> >   ??? at
> > org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeSuite(EventTestRunnerAdaptor.java:70)
> >   ??? at
> > org.jboss.arquillian.junit.AdaptorManager.initializeAdaptor(AdaptorManager.java:23)
> >   ??? at
> > org.jboss.arquillian.junit.AdaptorManagerWithNotifier.initializeAdaptor(AdaptorManagerWithNotifier.java:19)
> >   ??? at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:109)
> >   ??? at
> > org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367)
> >   ??? at
> > org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
> >   ??? at
> > org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> >   ??? at
> > org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> >   ??? at
> > org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
> >   ??? at
> > org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
> >   ??? at
> > org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
> > Caused by: java.lang.RuntimeException: Failed to connect to database
> >   ??? at
> > org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.getConnection(DefaultJpaConnectionProviderFactory.java:382)
> >   ??? at
> > org.keycloak.connections.jpa.updater.liquibase.lock.LiquibaseDBLockProvider.lazyInit(LiquibaseDBLockProvider.java:65)
> >   ??? at
> > org.keycloak.connections.jpa.updater.liquibase.lock.LiquibaseDBLockProvider.lambda$waitForLock$0(LiquibaseDBLockProvider.java:97)
> >   ??? at
> > org.keycloak.models.utils.KeycloakModelUtils.suspendJtaTransaction(KeycloakModelUtils.java:678)
> >   ??? at
> > org.keycloak.connections.jpa.updater.liquibase.lock.LiquibaseDBLockProvider.waitForLock(LiquibaseDBLockProvider.java:95)
> >   ??? at
> > org.keycloak.services.resources.KeycloakApplication$1.run(KeycloakApplication.java:148)
> >   ??? at
> > org.keycloak.models.utils.KeycloakModelUtils.runJobInTransaction(KeycloakModelUtils.java:227)
> >   ??? at
> > org.keycloak.services.resources.KeycloakApplication.<init>(KeycloakApplication.java:141)
> >   ??? at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> > Method)
> >   ??? at
> > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> >   ??? at
> > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> >   ??? at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> >   ??? at
> > org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:154)
> >   ??? ... 77 more
> > Caused by: java.lang.ClassNotFoundException:
> >   ??? at java.lang.Class.forName0(Native Method)
> >   ??? at java.lang.Class.forName(Class.java:264)
> >   ??? at
> > org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.getConnection(DefaultJpaConnectionProviderFactory.java:378)
> >   ??? ... 89 more
> >
> > _______________________________________________
> > 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

-- 

abstractj

From slaskawi at redhat.com  Sat Feb  9 02:26:14 2019
From: slaskawi at redhat.com (Sebastian Laskawiec)
Date: Sat, 9 Feb 2019 08:26:14 +0100
Subject: [keycloak-dev] Testsuite broken?
In-Reply-To: <20190208220641.GA12670@abstractj.org>
References: <f3490cd7-b89b-0dfd-6b7c-eda2eb31e92f@redhat.com>
	<11620a0b-0b95-5339-5fe0-8b8d75f39af1@redhat.com>
	<20190208220641.GA12670@abstractj.org>
Message-ID: <CAA9R9O67XdMw69RKhcJfMuk5LwA6rUth4YtmYfqZrTiN7DAa4A@mail.gmail.com>

Hey Stan,

This seems to be related to my TLS changes. Please try rebuilding the whole
project with mvn clean install -DskipTests on the root.

Thanks,
Seb

pt., 8.02.2019, 23:11: Bruno Oliveira <bruno at abstractj.org> napisa?(a):

> Based on the latest changes from master I tried this:
>
> mvn clean test -f testsuite/integration-arquillian/tests/base/pom.xml
> '-Dtest=org.keycloak.testsuite.oidc.UserInfoTest' test
>
> All the tests are passing. Could you please provide the command you ran?
>
> On 2019-02-08, Stan Silvert wrote:
> > Wondering if something has changed recently that causes this to fail
> > locally.  The stack trace I posted earlier is what happens if you run
> > arquillian testsuite alone.
> >
> > If I run full testsuite with "mvn test", I get:
> >
> > [INFO] --- maven-dependency-plugin:3.1.1:unpack (unpack-undertow-server)
> > @ integration-arquillian-tests-base ---
> > [INFO] Configured Artifact:
> >
> org.keycloak.testsuite:integration-arquillian-servers-auth-server-undertow:4.8.3.Final-SNAPSHOT:jar
> > [INFO] Unpacking
> >
> C:\GitHub\keycloak\testsuite\integration-arquillian\servers\auth-server\undertow\target\classes
>
> > to
> >
> C:\GitHub\keycloak\testsuite\integration-arquillian\tests\base\target\containers\auth-server-undertow
>
> > with includes "*.jks,*.crt,*.truststore" and excludes ""
> > [INFO]
> > ------------------------------------------------------------------------
> > [INFO] Reactor Summary:
> > [INFO]
> > [INFO] Keycloak TestSuite 4.8.3.Final-SNAPSHOT ............ SUCCESS [
> > 1.308 s]
> > [INFO] Keycloak Arquillian Integration TestSuite .......... SUCCESS [
> > 0.034 s]
> > [INFO] Servers ............................................ SUCCESS [
> > 0.034 s]
> > [INFO] Auth Server ........................................ SUCCESS [
> > 0.036 s]
> > [INFO] Auth Server Services ............................... SUCCESS [
> > 0.040 s]
> > [INFO] Auth Server Services - Testsuite Providers ......... SUCCESS [
> > 2.268 s]
> > [INFO] Keycloak TestSuite Utils ........................... SUCCESS [
> > 1.314 s]
> > [INFO] Test apps .......................................... SUCCESS [
> > 0.036 s]
> > [INFO] integration-arquillian-test-apps-servlets .......... SUCCESS [
> > 0.144 s]
> > [INFO] Keycloak Integration TestSuite - deprecated ........ SUCCESS
> > [03:58 min]
> > [INFO] Keycloak Tomcat 8 Integration TestSuite ............ SUCCESS [
> > 36.763 s]
> > [INFO] Test apps distribution ............................. SUCCESS [
> > 0.861 s]
> > [INFO] Keycloak Authz: PhotoZ  Test Parent ................ SUCCESS [
> > 0.035 s]
> > [INFO] Keycloak Authz Test: Photoz RESTful API ............ SUCCESS [
> > 0.127 s]
> > [INFO] Keycloak Authz Tests: Photoz HTML5 Client .......... SUCCESS [
> > 0.082 s]
> > [INFO] Keycloak Authz Tests: Photoz Authz Rule-based Policy SUCCESS [
> > 0.081 s]
> > [INFO] Keycloak Authz Tests: Hello World Example .......... SUCCESS [
> > 0.094 s]
> > [INFO] Keycloak Authz: Servlet Authorization Test ......... SUCCESS [
> > 0.084 s]
> > [INFO] Keycloak Authz: Simple Servlet App with Policy Enforcer SUCCESS
> > [  0.069 s]
> > [INFO] Keycloak Test App Profile JEE ...................... SUCCESS [
> > 0.090 s]
> > [INFO] integration-arquillian-test-apps-cors-parent ....... SUCCESS [
> > 0.035 s]
> > [INFO] Angular Product Portal JS .......................... SUCCESS [
> > 0.108 s]
> > [INFO] JAX-RS Database Service Using OAuth Bearer Tokens .. SUCCESS [
> > 0.099 s]
> > [INFO] Fuse Test Applications ............................. SUCCESS [
> > 0.038 s]
> > [INFO] Customer Portal - Secured in Karaf/Fuse ............ SUCCESS [
> > 0.834 s]
> > [INFO] CXF JAXRS Example - Secured in Karaf/Fuse .......... SUCCESS [
> > 0.142 s]
> > [INFO] CXF JAXRS Example - Secured in Karaf/Fuse 7.0 on Undertow SUCCESS
> > [  0.102 s]
> > [INFO] CXF JAXWS Example - Secured in Karaf/Fuse .......... SUCCESS [
> > 0.584 s]
> > [INFO] CXF JAXWS Example - Secured in Karaf/Fuse 7.0 on Undertow SUCCESS
> > [  0.264 s]
> > [INFO] Product Portal - Secured in Karaf/Fuse ............. SUCCESS [
> > 0.104 s]
> > [INFO] Product Portal - Secured in Karaf/Fuse 7.0 on Undertow SUCCESS [
> > 0.105 s]
> > [INFO] Camel endpoint example - Secured in Karaf/Fuse ..... SUCCESS [
> > 0.173 s]
> > [INFO] Camel endpoint example - Secured in Karaf/Fuse 7.0 on Undertow
> > SUCCESS [  0.110 s]
> > [INFO] Keycloak Fuse Example - Features ................... SUCCESS [
> > 0.091 s]
> > [INFO] Keycloak Examples - External Config ................ SUCCESS [
> > 0.252 s]
> > [INFO] Auth Server - JBoss ................................ SUCCESS [
> > 0.034 s]
> > [INFO] Test Util .......................................... SUCCESS [
> > 0.351 s]
> > [INFO] Auth Server - Undertow ............................. SUCCESS [
> > 0.497 s]
> > [INFO] App Server ......................................... SUCCESS [
> > 0.031 s]
> > [INFO] App Server - SPI ................................... SUCCESS [
> > 0.097 s]
> > [INFO] App Server - JBoss ................................. SUCCESS [
> > 0.034 s]
> > [INFO] App Server - Karaf ................................. SUCCESS [
> > 0.031 s]
> > [INFO] App Server - Tomcat ................................ SUCCESS [
> > 0.032 s]
> > [INFO] App Server - Undertow .............................. SUCCESS [
> > 0.167 s]
> > [INFO] Cache Server ....................................... SUCCESS [
> > 0.035 s]
> > [INFO] Cache Server - JBoss Family ........................ SUCCESS [
> > 0.038 s]
> > [INFO] Tests .............................................. SUCCESS [
> > 0.132 s]
> > [INFO] Base TestSuite ..................................... FAILURE [
> > 6.991 s]
> > [INFO] Other Tests Modules ................................ SKIPPED
> > [INFO] Adapter Tests ...................................... SKIPPED
> > [INFO] Adapter Tests - JBoss .............................. SKIPPED
> > [INFO] Adapter Tests - Karaf .............................. SKIPPED
> > [INFO] Adapter Tests - Tomcat ............................. SKIPPED
> > [INFO] Adapter Tests - WAS ................................ SKIPPED
> > [INFO] Adapter Tests - WLS ................................ SKIPPED
> > [INFO] SSSD tests ......................................... SKIPPED
> > [INFO] integration-arquillian-tests-springboot ............ SKIPPED
> > [INFO] Keycloak Jetty 9.2.x Integration TestSuite ......... SKIPPED
> > [INFO] Keycloak Jetty 9.3.x Integration TestSuite ......... SKIPPED
> > [INFO] Keycloak Jetty 9.4.x Integration TestSuite ......... SKIPPED
> > [INFO] Keycloak SAML Jetty Testsuite Integration .......... SKIPPED
> > [INFO] Keycloak Security Proxy TestSuite .................. SKIPPED
> > [INFO] Keycloak Tomcat 7 Integration TestSuite 4.8.3.Final-SNAPSHOT
> SKIPPED
> > [INFO]
> > ------------------------------------------------------------------------
> > [INFO] BUILD FAILURE
> > [INFO]
> > ------------------------------------------------------------------------
> > [INFO] Total time: 04:55 min
> > [INFO] Finished at: 2019-02-08T14:19:21-05:00
> > [INFO]
> > ------------------------------------------------------------------------
> > [ERROR] Failed to execute goal
> > org.apache.maven.plugins:maven-dependency-plugin:3.1.1:unpack
> > (unpack-undertow-server) on project integration-arquillian-tests-base:
> > Artifact has not been packaged yet. When used on reactor artifact,
> > unpack should be executed after packaging: see MDEP-98. -> [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/MojoExecutionException
> > [ERROR]
> > [ERROR] After correcting the problems, you can resume the build with the
> > command
> > [ERROR]   mvn <goals> -rf :integration-arquillian-tests-base
> >
> > On 2/8/2019 2:00 PM, Stan Silvert wrote:
> > > Trying to run tests locally.  I did a clean build from master. Anyone
> > > know what is wrong?
> > >
> > > java.lang.RuntimeException: RESTEASY003325: Failed to construct public
> > >
> org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher)
> > >       at
> > >
> org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:166)
> > >       at
> > >
> org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2757)
> > >       at
> > >
> org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:363)
> > >       at
> > >
> org.jboss.resteasy.spi.ResteasyDeployment.startInternal(ResteasyDeployment.java:276)
> > >       at
> > >
> org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:88)
> > >       at
> > >
> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:119)
> > >       at
> > >
> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36)
> > >       at
> > >
> io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117)
> > >       at
> > >
> io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:300)
> > >       at
> > >
> io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:140)
> > >       at
> > >
> io.undertow.servlet.core.DeploymentManagerImpl$2.call(DeploymentManagerImpl.java:583)
> > >       at
> > >
> io.undertow.servlet.core.DeploymentManagerImpl$2.call(DeploymentManagerImpl.java:554)
> > >       at
> > >
> io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42)
> > >       at
> > >
> io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> > >       at
> > >
> io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:596)
> > >       at
> > >
> org.jboss.resteasy.plugins.server.undertow.UndertowJaxrsServer.deploy(UndertowJaxrsServer.java:270)
> > >       at
> > >
> org.keycloak.testsuite.arquillian.undertow.KeycloakOnUndertow.start(KeycloakOnUndertow.java:204)
> > >       at
> > >
> org.jboss.arquillian.container.impl.ContainerImpl.start(ContainerImpl.java:179)
> > >       at
> > >
> org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:137)
> > >       at
> > >
> org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:133)
> > >       at
> > >
> org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forContainer(ContainerLifecycleController.java:208)
> > >       at
> > >
> org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startContainer(ContainerLifecycleController.java:133)
> > >       at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > >       at
> > >
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> > >       at
> > >
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> > >       at java.lang.reflect.Method.invoke(Method.java:498)
> > >       at
> > >
> org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
> > >       at
> > >
> org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103)
> > >       at
> > >
> org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:90)
> > >       at
> > >
> org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:54)
> > >       at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > >       at
> > >
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> > >       at
> > >
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> > >       at java.lang.reflect.Method.invoke(Method.java:498)
> > >       at
> > >
> org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
> > >       at
> > >
> org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:95)
> > >       at
> > > org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:133)
> > >       at
> > > org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:105)
> > >       at
> org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:62)
> > >       at
> > >
> org.keycloak.testsuite.arquillian.AuthServerTestEnricher.startAuthContainer(AuthServerTestEnricher.java:321)
> > >       at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > >       at
> > >
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> > >       at
> > >
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> > >       at java.lang.reflect.Method.invoke(Method.java:498)
> > >       at
> > >
> org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
> > >       at
> > >
> org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103)
> > >       at
> > >
> org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:90)
> > >       at
> > > org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:133)
> > >       at
> > > org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:105)
> > >       at
> org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:62)
> > >       at
> > >
> org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:83)
> > >       at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > >       at
> > >
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> > >       at
> > >
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> > >       at java.lang.reflect.Method.invoke(Method.java:498)
> > >       at
> > >
> org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
> > >       at
> > >
> org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103)
> > >       at
> > >
> org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:90)
> > >       at
> > >
> org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:69)
> > >       at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > >       at
> > >
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> > >       at
> > >
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> > >       at java.lang.reflect.Method.invoke(Method.java:498)
> > >       at
> > >
> org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
> > >       at
> > >
> org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:95)
> > >       at
> > > org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:133)
> > >       at
> > > org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:105)
> > >       at
> > >
> org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeSuite(EventTestRunnerAdaptor.java:70)
> > >       at
> > >
> org.jboss.arquillian.junit.AdaptorManager.initializeAdaptor(AdaptorManager.java:23)
> > >       at
> > >
> org.jboss.arquillian.junit.AdaptorManagerWithNotifier.initializeAdaptor(AdaptorManagerWithNotifier.java:19)
> > >       at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:109)
> > >       at
> > >
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367)
> > >       at
> > >
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
> > >       at
> > >
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> > >       at
> > >
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> > >       at
> > >
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
> > >       at
> > >
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
> > >       at
> > >
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
> > > Caused by: java.lang.RuntimeException: Failed to connect to database
> > >       at
> > >
> org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.getConnection(DefaultJpaConnectionProviderFactory.java:382)
> > >       at
> > >
> org.keycloak.connections.jpa.updater.liquibase.lock.LiquibaseDBLockProvider.lazyInit(LiquibaseDBLockProvider.java:65)
> > >       at
> > >
> org.keycloak.connections.jpa.updater.liquibase.lock.LiquibaseDBLockProvider.lambda$waitForLock$0(LiquibaseDBLockProvider.java:97)
> > >       at
> > >
> org.keycloak.models.utils.KeycloakModelUtils.suspendJtaTransaction(KeycloakModelUtils.java:678)
> > >       at
> > >
> org.keycloak.connections.jpa.updater.liquibase.lock.LiquibaseDBLockProvider.waitForLock(LiquibaseDBLockProvider.java:95)
> > >       at
> > >
> org.keycloak.services.resources.KeycloakApplication$1.run(KeycloakApplication.java:148)
> > >       at
> > >
> org.keycloak.models.utils.KeycloakModelUtils.runJobInTransaction(KeycloakModelUtils.java:227)
> > >       at
> > >
> org.keycloak.services.resources.KeycloakApplication.<init>(KeycloakApplication.java:141)
> > >       at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> > > Method)
> > >       at
> > >
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> > >       at
> > >
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> > >       at
> java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> > >       at
> > >
> org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:154)
> > >       ... 77 more
> > > Caused by: java.lang.ClassNotFoundException:
> > >       at java.lang.Class.forName0(Native Method)
> > >       at java.lang.Class.forName(Class.java:264)
> > >       at
> > >
> org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.getConnection(DefaultJpaConnectionProviderFactory.java:378)
> > >       ... 89 more
> > >
> > > _______________________________________________
> > > 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
>
> --
>
> abstractj
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From ssilvert at redhat.com  Sat Feb  9 07:58:46 2019
From: ssilvert at redhat.com (Stan Silvert)
Date: Sat, 9 Feb 2019 07:58:46 -0500
Subject: [keycloak-dev] Testsuite broken?
In-Reply-To: <CAA9R9O67XdMw69RKhcJfMuk5LwA6rUth4YtmYfqZrTiN7DAa4A@mail.gmail.com>
References: <f3490cd7-b89b-0dfd-6b7c-eda2eb31e92f@redhat.com>
	<11620a0b-0b95-5339-5fe0-8b8d75f39af1@redhat.com>
	<20190208220641.GA12670@abstractj.org>
	<CAA9R9O67XdMw69RKhcJfMuk5LwA6rUth4YtmYfqZrTiN7DAa4A@mail.gmail.com>
Message-ID: <e3867fc9-89e9-b9bc-28a0-b9654e376be1@redhat.com>

On 2/9/2019 2:26 AM, Sebastian Laskawiec wrote:
> Hey Stan,
>
> This seems to be related to my TLS changes. Please try rebuilding the 
> whole project with mvn clean install -DskipTests on the root.
I tried that already.
>
> Thanks,
> Seb
>
> pt., 8.02.2019, 23:11: Bruno Oliveira <bruno at abstractj.org 
> <mailto:bruno at abstractj.org>> napisa?(a):
>
>     Based on the latest changes from master I tried this:
>
>     mvn clean test -f
>     testsuite/integration-arquillian/tests/base/pom.xml
>     '-Dtest=org.keycloak.testsuite.oidc.UserInfoTest' test
>
>     All the tests are passing. Could you please provide the command
>     you ran?
>
>     On 2019-02-08, Stan Silvert wrote:
>     > Wondering if something has changed recently that causes this to
>     fail
>     > locally.? The stack trace I posted earlier is what happens if
>     you run
>     > arquillian testsuite alone.
>     >
>     > If I run full testsuite with "mvn test", I get:
>     >
>     > [INFO] --- maven-dependency-plugin:3.1.1:unpack
>     (unpack-undertow-server)
>     > @ integration-arquillian-tests-base ---
>     > [INFO] Configured Artifact:
>     >
>     org.keycloak.testsuite:integration-arquillian-servers-auth-server-undertow:4.8.3.Final-SNAPSHOT:jar
>     > [INFO] Unpacking
>     >
>     C:\GitHub\keycloak\testsuite\integration-arquillian\servers\auth-server\undertow\target\classes
>
>     > to
>     >
>     C:\GitHub\keycloak\testsuite\integration-arquillian\tests\base\target\containers\auth-server-undertow
>
>     > with includes "*.jks,*.crt,*.truststore" and excludes ""
>     > [INFO]
>     >
>     ------------------------------------------------------------------------
>     > [INFO] Reactor Summary:
>     > [INFO]
>     > [INFO] Keycloak TestSuite 4.8.3.Final-SNAPSHOT ............
>     SUCCESS [
>     > 1.308 s]
>     > [INFO] Keycloak Arquillian Integration TestSuite ..........
>     SUCCESS [
>     > 0.034 s]
>     > [INFO] Servers ............................................
>     SUCCESS [
>     > 0.034 s]
>     > [INFO] Auth Server ........................................
>     SUCCESS [
>     > 0.036 s]
>     > [INFO] Auth Server Services ...............................
>     SUCCESS [
>     > 0.040 s]
>     > [INFO] Auth Server Services - Testsuite Providers .........
>     SUCCESS [
>     > 2.268 s]
>     > [INFO] Keycloak TestSuite Utils ...........................
>     SUCCESS [
>     > 1.314 s]
>     > [INFO] Test apps ..........................................
>     SUCCESS [
>     > 0.036 s]
>     > [INFO] integration-arquillian-test-apps-servlets ..........
>     SUCCESS [
>     > 0.144 s]
>     > [INFO] Keycloak Integration TestSuite - deprecated ........ SUCCESS
>     > [03:58 min]
>     > [INFO] Keycloak Tomcat 8 Integration TestSuite ............
>     SUCCESS [
>     > 36.763 s]
>     > [INFO] Test apps distribution .............................
>     SUCCESS [
>     > 0.861 s]
>     > [INFO] Keycloak Authz: PhotoZ? Test Parent ................
>     SUCCESS [
>     > 0.035 s]
>     > [INFO] Keycloak Authz Test: Photoz RESTful API ............
>     SUCCESS [
>     > 0.127 s]
>     > [INFO] Keycloak Authz Tests: Photoz HTML5 Client ..........
>     SUCCESS [
>     > 0.082 s]
>     > [INFO] Keycloak Authz Tests: Photoz Authz Rule-based Policy
>     SUCCESS [
>     > 0.081 s]
>     > [INFO] Keycloak Authz Tests: Hello World Example ..........
>     SUCCESS [
>     > 0.094 s]
>     > [INFO] Keycloak Authz: Servlet Authorization Test .........
>     SUCCESS [
>     > 0.084 s]
>     > [INFO] Keycloak Authz: Simple Servlet App with Policy Enforcer
>     SUCCESS
>     > [? 0.069 s]
>     > [INFO] Keycloak Test App Profile JEE ......................
>     SUCCESS [
>     > 0.090 s]
>     > [INFO] integration-arquillian-test-apps-cors-parent .......
>     SUCCESS [
>     > 0.035 s]
>     > [INFO] Angular Product Portal JS ..........................
>     SUCCESS [
>     > 0.108 s]
>     > [INFO] JAX-RS Database Service Using OAuth Bearer Tokens ..
>     SUCCESS [
>     > 0.099 s]
>     > [INFO] Fuse Test Applications .............................
>     SUCCESS [
>     > 0.038 s]
>     > [INFO] Customer Portal - Secured in Karaf/Fuse ............
>     SUCCESS [
>     > 0.834 s]
>     > [INFO] CXF JAXRS Example - Secured in Karaf/Fuse ..........
>     SUCCESS [
>     > 0.142 s]
>     > [INFO] CXF JAXRS Example - Secured in Karaf/Fuse 7.0 on Undertow
>     SUCCESS
>     > [? 0.102 s]
>     > [INFO] CXF JAXWS Example - Secured in Karaf/Fuse ..........
>     SUCCESS [
>     > 0.584 s]
>     > [INFO] CXF JAXWS Example - Secured in Karaf/Fuse 7.0 on Undertow
>     SUCCESS
>     > [? 0.264 s]
>     > [INFO] Product Portal - Secured in Karaf/Fuse .............
>     SUCCESS [
>     > 0.104 s]
>     > [INFO] Product Portal - Secured in Karaf/Fuse 7.0 on Undertow
>     SUCCESS [
>     > 0.105 s]
>     > [INFO] Camel endpoint example - Secured in Karaf/Fuse .....
>     SUCCESS [
>     > 0.173 s]
>     > [INFO] Camel endpoint example - Secured in Karaf/Fuse 7.0 on
>     Undertow
>     > SUCCESS [? 0.110 s]
>     > [INFO] Keycloak Fuse Example - Features ...................
>     SUCCESS [
>     > 0.091 s]
>     > [INFO] Keycloak Examples - External Config ................
>     SUCCESS [
>     > 0.252 s]
>     > [INFO] Auth Server - JBoss ................................
>     SUCCESS [
>     > 0.034 s]
>     > [INFO] Test Util ..........................................
>     SUCCESS [
>     > 0.351 s]
>     > [INFO] Auth Server - Undertow .............................
>     SUCCESS [
>     > 0.497 s]
>     > [INFO] App Server .........................................
>     SUCCESS [
>     > 0.031 s]
>     > [INFO] App Server - SPI ...................................
>     SUCCESS [
>     > 0.097 s]
>     > [INFO] App Server - JBoss .................................
>     SUCCESS [
>     > 0.034 s]
>     > [INFO] App Server - Karaf .................................
>     SUCCESS [
>     > 0.031 s]
>     > [INFO] App Server - Tomcat ................................
>     SUCCESS [
>     > 0.032 s]
>     > [INFO] App Server - Undertow ..............................
>     SUCCESS [
>     > 0.167 s]
>     > [INFO] Cache Server .......................................
>     SUCCESS [
>     > 0.035 s]
>     > [INFO] Cache Server - JBoss Family ........................
>     SUCCESS [
>     > 0.038 s]
>     > [INFO] Tests ..............................................
>     SUCCESS [
>     > 0.132 s]
>     > [INFO] Base TestSuite .....................................
>     FAILURE [
>     > 6.991 s]
>     > [INFO] Other Tests Modules ................................ SKIPPED
>     > [INFO] Adapter Tests ...................................... SKIPPED
>     > [INFO] Adapter Tests - JBoss .............................. SKIPPED
>     > [INFO] Adapter Tests - Karaf .............................. SKIPPED
>     > [INFO] Adapter Tests - Tomcat ............................. SKIPPED
>     > [INFO] Adapter Tests - WAS ................................ SKIPPED
>     > [INFO] Adapter Tests - WLS ................................ SKIPPED
>     > [INFO] SSSD tests ......................................... SKIPPED
>     > [INFO] integration-arquillian-tests-springboot ............ SKIPPED
>     > [INFO] Keycloak Jetty 9.2.x Integration TestSuite ......... SKIPPED
>     > [INFO] Keycloak Jetty 9.3.x Integration TestSuite ......... SKIPPED
>     > [INFO] Keycloak Jetty 9.4.x Integration TestSuite ......... SKIPPED
>     > [INFO] Keycloak SAML Jetty Testsuite Integration .......... SKIPPED
>     > [INFO] Keycloak Security Proxy TestSuite .................. SKIPPED
>     > [INFO] Keycloak Tomcat 7 Integration TestSuite
>     4.8.3.Final-SNAPSHOT SKIPPED
>     > [INFO]
>     >
>     ------------------------------------------------------------------------
>     > [INFO] BUILD FAILURE
>     > [INFO]
>     >
>     ------------------------------------------------------------------------
>     > [INFO] Total time: 04:55 min
>     > [INFO] Finished at: 2019-02-08T14:19:21-05:00
>     > [INFO]
>     >
>     ------------------------------------------------------------------------
>     > [ERROR] Failed to execute goal
>     > org.apache.maven.plugins:maven-dependency-plugin:3.1.1:unpack
>     > (unpack-undertow-server) on project
>     integration-arquillian-tests-base:
>     > Artifact has not been packaged yet. When used on reactor artifact,
>     > unpack should be executed after packaging: see MDEP-98. -> [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/MojoExecutionException
>     > [ERROR]
>     > [ERROR] After correcting the problems, you can resume the build
>     with the
>     > command
>     > [ERROR]?? mvn <goals> -rf :integration-arquillian-tests-base
>     >
>     > On 2/8/2019 2:00 PM, Stan Silvert wrote:
>     > > Trying to run tests locally.? I did a clean build from master.
>     Anyone
>     > > know what is wrong?
>     > >
>     > > java.lang.RuntimeException: RESTEASY003325: Failed to
>     construct public
>     > >
>     org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher)
>     > >? ???? at
>     > >
>     org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:166)
>     > >? ???? at
>     > >
>     org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2757)
>     > >? ???? at
>     > >
>     org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:363)
>     > >? ???? at
>     > >
>     org.jboss.resteasy.spi.ResteasyDeployment.startInternal(ResteasyDeployment.java:276)
>     > >? ???? at
>     > >
>     org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:88)
>     > >? ???? at
>     > >
>     org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:119)
>     > >? ???? at
>     > >
>     org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36)
>     > >? ???? at
>     > >
>     io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117)
>     > >? ???? at
>     > >
>     io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:300)
>     > >? ???? at
>     > >
>     io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:140)
>     > >? ???? at
>     > >
>     io.undertow.servlet.core.DeploymentManagerImpl$2.call(DeploymentManagerImpl.java:583)
>     > >? ???? at
>     > >
>     io.undertow.servlet.core.DeploymentManagerImpl$2.call(DeploymentManagerImpl.java:554)
>     > >? ???? at
>     > >
>     io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42)
>     > >? ???? at
>     > >
>     io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
>     > >? ???? at
>     > >
>     io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:596)
>     > >? ???? at
>     > >
>     org.jboss.resteasy.plugins.server.undertow.UndertowJaxrsServer.deploy(UndertowJaxrsServer.java:270)
>     > >? ???? at
>     > >
>     org.keycloak.testsuite.arquillian.undertow.KeycloakOnUndertow.start(KeycloakOnUndertow.java:204)
>     > >? ???? at
>     > >
>     org.jboss.arquillian.container.impl.ContainerImpl.start(ContainerImpl.java:179)
>     > >? ???? at
>     > >
>     org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:137)
>     > >? ???? at
>     > >
>     org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:133)
>     > >? ???? at
>     > >
>     org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forContainer(ContainerLifecycleController.java:208)
>     > >? ???? at
>     > >
>     org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startContainer(ContainerLifecycleController.java:133)
>     > >? ???? at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
>     Method)
>     > >? ???? at
>     > >
>     sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>     > >? ???? at
>     > >
>     sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>     > >? ???? at java.lang.reflect.Method.invoke(Method.java:498)
>     > >? ???? at
>     > >
>     org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
>     > >? ???? at
>     > >
>     org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103)
>     > >? ???? at
>     > >
>     org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:90)
>     > >? ???? at
>     > >
>     org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:54)
>     > >? ???? at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
>     Method)
>     > >? ???? at
>     > >
>     sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>     > >? ???? at
>     > >
>     sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>     > >? ???? at java.lang.reflect.Method.invoke(Method.java:498)
>     > >? ???? at
>     > >
>     org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
>     > >? ???? at
>     > >
>     org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:95)
>     > >? ???? at
>     > >
>     org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:133)
>     > >? ???? at
>     > >
>     org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:105)
>     > >? ???? at
>     org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:62)
>     > >? ???? at
>     > >
>     org.keycloak.testsuite.arquillian.AuthServerTestEnricher.startAuthContainer(AuthServerTestEnricher.java:321)
>     > >? ???? at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
>     Method)
>     > >? ???? at
>     > >
>     sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>     > >? ???? at
>     > >
>     sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>     > >? ???? at java.lang.reflect.Method.invoke(Method.java:498)
>     > >? ???? at
>     > >
>     org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
>     > >? ???? at
>     > >
>     org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103)
>     > >? ???? at
>     > >
>     org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:90)
>     > >? ???? at
>     > >
>     org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:133)
>     > >? ???? at
>     > >
>     org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:105)
>     > >? ???? at
>     org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:62)
>     > >? ???? at
>     > >
>     org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:83)
>     > >? ???? at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
>     Method)
>     > >? ???? at
>     > >
>     sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>     > >? ???? at
>     > >
>     sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>     > >? ???? at java.lang.reflect.Method.invoke(Method.java:498)
>     > >? ???? at
>     > >
>     org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
>     > >? ???? at
>     > >
>     org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103)
>     > >? ???? at
>     > >
>     org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:90)
>     > >? ???? at
>     > >
>     org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:69)
>     > >? ???? at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
>     Method)
>     > >? ???? at
>     > >
>     sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>     > >? ???? at
>     > >
>     sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>     > >? ???? at java.lang.reflect.Method.invoke(Method.java:498)
>     > >? ???? at
>     > >
>     org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
>     > >? ???? at
>     > >
>     org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:95)
>     > >? ???? at
>     > >
>     org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:133)
>     > >? ???? at
>     > >
>     org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:105)
>     > >? ???? at
>     > >
>     org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeSuite(EventTestRunnerAdaptor.java:70)
>     > >? ???? at
>     > >
>     org.jboss.arquillian.junit.AdaptorManager.initializeAdaptor(AdaptorManager.java:23)
>     > >? ???? at
>     > >
>     org.jboss.arquillian.junit.AdaptorManagerWithNotifier.initializeAdaptor(AdaptorManagerWithNotifier.java:19)
>     > >? ???? at
>     org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:109)
>     > >? ???? at
>     > >
>     org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367)
>     > >? ???? at
>     > >
>     org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
>     > >? ???? at
>     > >
>     org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
>     > >? ???? at
>     > >
>     org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
>     > >? ???? at
>     > >
>     org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
>     > >? ???? at
>     > >
>     org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
>     > >? ???? at
>     > >
>     org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
>     > > Caused by: java.lang.RuntimeException: Failed to connect to
>     database
>     > >? ???? at
>     > >
>     org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.getConnection(DefaultJpaConnectionProviderFactory.java:382)
>     > >? ???? at
>     > >
>     org.keycloak.connections.jpa.updater.liquibase.lock.LiquibaseDBLockProvider.lazyInit(LiquibaseDBLockProvider.java:65)
>     > >? ???? at
>     > >
>     org.keycloak.connections.jpa.updater.liquibase.lock.LiquibaseDBLockProvider.lambda$waitForLock$0(LiquibaseDBLockProvider.java:97)
>     > >? ???? at
>     > >
>     org.keycloak.models.utils.KeycloakModelUtils.suspendJtaTransaction(KeycloakModelUtils.java:678)
>     > >? ???? at
>     > >
>     org.keycloak.connections.jpa.updater.liquibase.lock.LiquibaseDBLockProvider.waitForLock(LiquibaseDBLockProvider.java:95)
>     > >? ???? at
>     > >
>     org.keycloak.services.resources.KeycloakApplication$1.run(KeycloakApplication.java:148)
>     > >? ???? at
>     > >
>     org.keycloak.models.utils.KeycloakModelUtils.runJobInTransaction(KeycloakModelUtils.java:227)
>     > >? ???? at
>     > >
>     org.keycloak.services.resources.KeycloakApplication.<init>(KeycloakApplication.java:141)
>     > >? ???? at
>     sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
>     > > Method)
>     > >? ???? at
>     > >
>     sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>     > >? ???? at
>     > >
>     sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>     > >? ???? at
>     java.lang.reflect.Constructor.newInstance(Constructor.java:423)
>     > >? ???? at
>     > >
>     org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:154)
>     > >? ???? ... 77 more
>     > > Caused by: java.lang.ClassNotFoundException:
>     > >? ???? at java.lang.Class.forName0(Native Method)
>     > >? ???? at java.lang.Class.forName(Class.java:264)
>     > >? ???? at
>     > >
>     org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.getConnection(DefaultJpaConnectionProviderFactory.java:378)
>     > >? ???? ... 89 more
>     > >
>     > > _______________________________________________
>     > > 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
>
>     -- 
>
>     abstractj
>     _______________________________________________
>     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 ssilvert at redhat.com  Sat Feb  9 08:01:43 2019
From: ssilvert at redhat.com (Stan Silvert)
Date: Sat, 9 Feb 2019 08:01:43 -0500
Subject: [keycloak-dev] Testsuite broken?
In-Reply-To: <20190208220641.GA12670@abstractj.org>
References: <f3490cd7-b89b-0dfd-6b7c-eda2eb31e92f@redhat.com>
	<11620a0b-0b95-5339-5fe0-8b8d75f39af1@redhat.com>
	<20190208220641.GA12670@abstractj.org>
Message-ID: <680cf56a-9434-a7db-d4e4-7ce614488f6f@redhat.com>

On 2/8/2019 5:06 PM, Bruno Oliveira wrote:
> Based on the latest changes from master I tried this:
>
> mvn clean test -f testsuite/integration-arquillian/tests/base/pom.xml '-Dtest=org.keycloak.testsuite.oidc.UserInfoTest' test
>
> All the tests are passing. Could you please provide the command you ran?
I did your command.? Got the same error:
Caused by: java.lang.ClassNotFoundException:
 ??????? at java.lang.Class.forName0(Native Method)
 ??????? at java.lang.Class.forName(Class.java:264)
 ??????? at 
org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.getConnection(DefaultJpaConnectionProviderFactory.java:378)
 ??????? ... 89 more

>
> On 2019-02-08, Stan Silvert wrote:
>> Wondering if something has changed recently that causes this to fail
>> locally.? The stack trace I posted earlier is what happens if you run
>> arquillian testsuite alone.
>>
>> If I run full testsuite with "mvn test", I get:
>>
>> [INFO] --- maven-dependency-plugin:3.1.1:unpack (unpack-undertow-server)
>> @ integration-arquillian-tests-base ---
>> [INFO] Configured Artifact:
>> org.keycloak.testsuite:integration-arquillian-servers-auth-server-undertow:4.8.3.Final-SNAPSHOT:jar
>> [INFO] Unpacking
>> C:\GitHub\keycloak\testsuite\integration-arquillian\servers\auth-server\undertow\target\classes
>> to
>> C:\GitHub\keycloak\testsuite\integration-arquillian\tests\base\target\containers\auth-server-undertow
>> with includes "*.jks,*.crt,*.truststore" and excludes ""
>> [INFO]
>> ------------------------------------------------------------------------
>> [INFO] Reactor Summary:
>> [INFO]
>> [INFO] Keycloak TestSuite 4.8.3.Final-SNAPSHOT ............ SUCCESS [
>> 1.308 s]
>> [INFO] Keycloak Arquillian Integration TestSuite .......... SUCCESS [
>> 0.034 s]
>> [INFO] Servers ............................................ SUCCESS [
>> 0.034 s]
>> [INFO] Auth Server ........................................ SUCCESS [
>> 0.036 s]
>> [INFO] Auth Server Services ............................... SUCCESS [
>> 0.040 s]
>> [INFO] Auth Server Services - Testsuite Providers ......... SUCCESS [
>> 2.268 s]
>> [INFO] Keycloak TestSuite Utils ........................... SUCCESS [
>> 1.314 s]
>> [INFO] Test apps .......................................... SUCCESS [
>> 0.036 s]
>> [INFO] integration-arquillian-test-apps-servlets .......... SUCCESS [
>> 0.144 s]
>> [INFO] Keycloak Integration TestSuite - deprecated ........ SUCCESS
>> [03:58 min]
>> [INFO] Keycloak Tomcat 8 Integration TestSuite ............ SUCCESS [
>> 36.763 s]
>> [INFO] Test apps distribution ............................. SUCCESS [
>> 0.861 s]
>> [INFO] Keycloak Authz: PhotoZ? Test Parent ................ SUCCESS [
>> 0.035 s]
>> [INFO] Keycloak Authz Test: Photoz RESTful API ............ SUCCESS [
>> 0.127 s]
>> [INFO] Keycloak Authz Tests: Photoz HTML5 Client .......... SUCCESS [
>> 0.082 s]
>> [INFO] Keycloak Authz Tests: Photoz Authz Rule-based Policy SUCCESS [
>> 0.081 s]
>> [INFO] Keycloak Authz Tests: Hello World Example .......... SUCCESS [
>> 0.094 s]
>> [INFO] Keycloak Authz: Servlet Authorization Test ......... SUCCESS [
>> 0.084 s]
>> [INFO] Keycloak Authz: Simple Servlet App with Policy Enforcer SUCCESS
>> [? 0.069 s]
>> [INFO] Keycloak Test App Profile JEE ...................... SUCCESS [
>> 0.090 s]
>> [INFO] integration-arquillian-test-apps-cors-parent ....... SUCCESS [
>> 0.035 s]
>> [INFO] Angular Product Portal JS .......................... SUCCESS [
>> 0.108 s]
>> [INFO] JAX-RS Database Service Using OAuth Bearer Tokens .. SUCCESS [
>> 0.099 s]
>> [INFO] Fuse Test Applications ............................. SUCCESS [
>> 0.038 s]
>> [INFO] Customer Portal - Secured in Karaf/Fuse ............ SUCCESS [
>> 0.834 s]
>> [INFO] CXF JAXRS Example - Secured in Karaf/Fuse .......... SUCCESS [
>> 0.142 s]
>> [INFO] CXF JAXRS Example - Secured in Karaf/Fuse 7.0 on Undertow SUCCESS
>> [? 0.102 s]
>> [INFO] CXF JAXWS Example - Secured in Karaf/Fuse .......... SUCCESS [
>> 0.584 s]
>> [INFO] CXF JAXWS Example - Secured in Karaf/Fuse 7.0 on Undertow SUCCESS
>> [? 0.264 s]
>> [INFO] Product Portal - Secured in Karaf/Fuse ............. SUCCESS [
>> 0.104 s]
>> [INFO] Product Portal - Secured in Karaf/Fuse 7.0 on Undertow SUCCESS [
>> 0.105 s]
>> [INFO] Camel endpoint example - Secured in Karaf/Fuse ..... SUCCESS [
>> 0.173 s]
>> [INFO] Camel endpoint example - Secured in Karaf/Fuse 7.0 on Undertow
>> SUCCESS [? 0.110 s]
>> [INFO] Keycloak Fuse Example - Features ................... SUCCESS [
>> 0.091 s]
>> [INFO] Keycloak Examples - External Config ................ SUCCESS [
>> 0.252 s]
>> [INFO] Auth Server - JBoss ................................ SUCCESS [
>> 0.034 s]
>> [INFO] Test Util .......................................... SUCCESS [
>> 0.351 s]
>> [INFO] Auth Server - Undertow ............................. SUCCESS [
>> 0.497 s]
>> [INFO] App Server ......................................... SUCCESS [
>> 0.031 s]
>> [INFO] App Server - SPI ................................... SUCCESS [
>> 0.097 s]
>> [INFO] App Server - JBoss ................................. SUCCESS [
>> 0.034 s]
>> [INFO] App Server - Karaf ................................. SUCCESS [
>> 0.031 s]
>> [INFO] App Server - Tomcat ................................ SUCCESS [
>> 0.032 s]
>> [INFO] App Server - Undertow .............................. SUCCESS [
>> 0.167 s]
>> [INFO] Cache Server ....................................... SUCCESS [
>> 0.035 s]
>> [INFO] Cache Server - JBoss Family ........................ SUCCESS [
>> 0.038 s]
>> [INFO] Tests .............................................. SUCCESS [
>> 0.132 s]
>> [INFO] Base TestSuite ..................................... FAILURE [
>> 6.991 s]
>> [INFO] Other Tests Modules ................................ SKIPPED
>> [INFO] Adapter Tests ...................................... SKIPPED
>> [INFO] Adapter Tests - JBoss .............................. SKIPPED
>> [INFO] Adapter Tests - Karaf .............................. SKIPPED
>> [INFO] Adapter Tests - Tomcat ............................. SKIPPED
>> [INFO] Adapter Tests - WAS ................................ SKIPPED
>> [INFO] Adapter Tests - WLS ................................ SKIPPED
>> [INFO] SSSD tests ......................................... SKIPPED
>> [INFO] integration-arquillian-tests-springboot ............ SKIPPED
>> [INFO] Keycloak Jetty 9.2.x Integration TestSuite ......... SKIPPED
>> [INFO] Keycloak Jetty 9.3.x Integration TestSuite ......... SKIPPED
>> [INFO] Keycloak Jetty 9.4.x Integration TestSuite ......... SKIPPED
>> [INFO] Keycloak SAML Jetty Testsuite Integration .......... SKIPPED
>> [INFO] Keycloak Security Proxy TestSuite .................. SKIPPED
>> [INFO] Keycloak Tomcat 7 Integration TestSuite 4.8.3.Final-SNAPSHOT SKIPPED
>> [INFO]
>> ------------------------------------------------------------------------
>> [INFO] BUILD FAILURE
>> [INFO]
>> ------------------------------------------------------------------------
>> [INFO] Total time: 04:55 min
>> [INFO] Finished at: 2019-02-08T14:19:21-05:00
>> [INFO]
>> ------------------------------------------------------------------------
>> [ERROR] Failed to execute goal
>> org.apache.maven.plugins:maven-dependency-plugin:3.1.1:unpack
>> (unpack-undertow-server) on project integration-arquillian-tests-base:
>> Artifact has not been packaged yet. When used on reactor artifact,
>> unpack should be executed after packaging: see MDEP-98. -> [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/MojoExecutionException
>> [ERROR]
>> [ERROR] After correcting the problems, you can resume the build with the
>> command
>> [ERROR]?? mvn <goals> -rf :integration-arquillian-tests-base
>>
>> On 2/8/2019 2:00 PM, Stan Silvert wrote:
>>> Trying to run tests locally.? I did a clean build from master. Anyone
>>> know what is wrong?
>>>
>>> java.lang.RuntimeException: RESTEASY003325: Failed to construct public
>>> org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher)
>>>    ??? at
>>> org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:166)
>>>    ??? at
>>> org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2757)
>>>    ??? at
>>> org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:363)
>>>    ??? at
>>> org.jboss.resteasy.spi.ResteasyDeployment.startInternal(ResteasyDeployment.java:276)
>>>    ??? at
>>> org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:88)
>>>    ??? at
>>> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:119)
>>>    ??? at
>>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36)
>>>    ??? at
>>> io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117)
>>>    ??? at
>>> io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:300)
>>>    ??? at
>>> io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:140)
>>>    ??? at
>>> io.undertow.servlet.core.DeploymentManagerImpl$2.call(DeploymentManagerImpl.java:583)
>>>    ??? at
>>> io.undertow.servlet.core.DeploymentManagerImpl$2.call(DeploymentManagerImpl.java:554)
>>>    ??? at
>>> io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42)
>>>    ??? at
>>> io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
>>>    ??? at
>>> io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:596)
>>>    ??? at
>>> org.jboss.resteasy.plugins.server.undertow.UndertowJaxrsServer.deploy(UndertowJaxrsServer.java:270)
>>>    ??? at
>>> org.keycloak.testsuite.arquillian.undertow.KeycloakOnUndertow.start(KeycloakOnUndertow.java:204)
>>>    ??? at
>>> org.jboss.arquillian.container.impl.ContainerImpl.start(ContainerImpl.java:179)
>>>    ??? at
>>> org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:137)
>>>    ??? at
>>> org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:133)
>>>    ??? at
>>> org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forContainer(ContainerLifecycleController.java:208)
>>>    ??? at
>>> org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startContainer(ContainerLifecycleController.java:133)
>>>    ??? at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>    ??? at
>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>>>    ??? at
>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>    ??? at java.lang.reflect.Method.invoke(Method.java:498)
>>>    ??? at
>>> org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
>>>    ??? at
>>> org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103)
>>>    ??? at
>>> org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:90)
>>>    ??? at
>>> org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:54)
>>>    ??? at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>    ??? at
>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>>>    ??? at
>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>    ??? at java.lang.reflect.Method.invoke(Method.java:498)
>>>    ??? at
>>> org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
>>>    ??? at
>>> org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:95)
>>>    ??? at
>>> org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:133)
>>>    ??? at
>>> org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:105)
>>>    ??? at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:62)
>>>    ??? at
>>> org.keycloak.testsuite.arquillian.AuthServerTestEnricher.startAuthContainer(AuthServerTestEnricher.java:321)
>>>    ??? at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>    ??? at
>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>>>    ??? at
>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>    ??? at java.lang.reflect.Method.invoke(Method.java:498)
>>>    ??? at
>>> org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
>>>    ??? at
>>> org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103)
>>>    ??? at
>>> org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:90)
>>>    ??? at
>>> org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:133)
>>>    ??? at
>>> org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:105)
>>>    ??? at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:62)
>>>    ??? at
>>> org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:83)
>>>    ??? at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>    ??? at
>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>>>    ??? at
>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>    ??? at java.lang.reflect.Method.invoke(Method.java:498)
>>>    ??? at
>>> org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
>>>    ??? at
>>> org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103)
>>>    ??? at
>>> org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:90)
>>>    ??? at
>>> org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:69)
>>>    ??? at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>    ??? at
>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>>>    ??? at
>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>    ??? at java.lang.reflect.Method.invoke(Method.java:498)
>>>    ??? at
>>> org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
>>>    ??? at
>>> org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:95)
>>>    ??? at
>>> org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:133)
>>>    ??? at
>>> org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:105)
>>>    ??? at
>>> org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeSuite(EventTestRunnerAdaptor.java:70)
>>>    ??? at
>>> org.jboss.arquillian.junit.AdaptorManager.initializeAdaptor(AdaptorManager.java:23)
>>>    ??? at
>>> org.jboss.arquillian.junit.AdaptorManagerWithNotifier.initializeAdaptor(AdaptorManagerWithNotifier.java:19)
>>>    ??? at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:109)
>>>    ??? at
>>> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367)
>>>    ??? at
>>> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
>>>    ??? at
>>> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
>>>    ??? at
>>> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
>>>    ??? at
>>> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
>>>    ??? at
>>> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
>>>    ??? at
>>> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
>>> Caused by: java.lang.RuntimeException: Failed to connect to database
>>>    ??? at
>>> org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.getConnection(DefaultJpaConnectionProviderFactory.java:382)
>>>    ??? at
>>> org.keycloak.connections.jpa.updater.liquibase.lock.LiquibaseDBLockProvider.lazyInit(LiquibaseDBLockProvider.java:65)
>>>    ??? at
>>> org.keycloak.connections.jpa.updater.liquibase.lock.LiquibaseDBLockProvider.lambda$waitForLock$0(LiquibaseDBLockProvider.java:97)
>>>    ??? at
>>> org.keycloak.models.utils.KeycloakModelUtils.suspendJtaTransaction(KeycloakModelUtils.java:678)
>>>    ??? at
>>> org.keycloak.connections.jpa.updater.liquibase.lock.LiquibaseDBLockProvider.waitForLock(LiquibaseDBLockProvider.java:95)
>>>    ??? at
>>> org.keycloak.services.resources.KeycloakApplication$1.run(KeycloakApplication.java:148)
>>>    ??? at
>>> org.keycloak.models.utils.KeycloakModelUtils.runJobInTransaction(KeycloakModelUtils.java:227)
>>>    ??? at
>>> org.keycloak.services.resources.KeycloakApplication.<init>(KeycloakApplication.java:141)
>>>    ??? at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
>>> Method)
>>>    ??? at
>>> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>>>    ??? at
>>> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>>>    ??? at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
>>>    ??? at
>>> org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:154)
>>>    ??? ... 77 more
>>> Caused by: java.lang.ClassNotFoundException:
>>>    ??? at java.lang.Class.forName0(Native Method)
>>>    ??? at java.lang.Class.forName(Class.java:264)
>>>    ??? at
>>> org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.getConnection(DefaultJpaConnectionProviderFactory.java:378)
>>>    ??? ... 89 more
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev



From ssilvert at redhat.com  Sat Feb  9 08:52:26 2019
From: ssilvert at redhat.com (Stan Silvert)
Date: Sat, 9 Feb 2019 08:52:26 -0500
Subject: [keycloak-dev] Testsuite broken?
In-Reply-To: <CAJrcDBdzGDwjQUxCkqW9qJEpWOSXLEdBBDBKX5uo2zrq4qMdUg@mail.gmail.com>
References: <f3490cd7-b89b-0dfd-6b7c-eda2eb31e92f@redhat.com>
	<CAJrcDBdzGDwjQUxCkqW9qJEpWOSXLEdBBDBKX5uo2zrq4qMdUg@mail.gmail.com>
Message-ID: <7f134500-8d45-0ece-1c17-9a40ddf308f5@redhat.com>

On 2/8/2019 3:00 PM, Pedro Igor Silva wrote:
> You are probably missing this last 
> commit?59430e7cd606480b32b63a46fd12dc1ebd779f2e.
That was it.? Thanks Pedro!

Guess I picked the wrong time to do an update.
>
> On Fri, Feb 8, 2019 at 5:04 PM Stan Silvert <ssilvert at redhat.com 
> <mailto:ssilvert at redhat.com>> wrote:
>
>     Trying to run tests locally.? I did a clean build from master. Anyone
>     know what is wrong?
>
>     java.lang.RuntimeException: RESTEASY003325: Failed to construct
>     public
>     org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher)
>     ???? at
>     org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:166)
>     ???? at
>     org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2757)
>     ???? at
>     org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:363)
>     ???? at
>     org.jboss.resteasy.spi.ResteasyDeployment.startInternal(ResteasyDeployment.java:276)
>     ???? at
>     org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:88)
>     ???? at
>     org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:119)
>     ???? at
>     org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36)
>     ???? at
>     io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117)
>     ???? at
>     io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:300)
>     ???? at
>     io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:140)
>     ???? at
>     io.undertow.servlet.core.DeploymentManagerImpl$2.call(DeploymentManagerImpl.java:583)
>     ???? at
>     io.undertow.servlet.core.DeploymentManagerImpl$2.call(DeploymentManagerImpl.java:554)
>     ???? at
>     io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42)
>     ???? at
>     io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
>     ???? at
>     io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:596)
>     ???? at
>     org.jboss.resteasy.plugins.server.undertow.UndertowJaxrsServer.deploy(UndertowJaxrsServer.java:270)
>     ???? at
>     org.keycloak.testsuite.arquillian.undertow.KeycloakOnUndertow.start(KeycloakOnUndertow.java:204)
>     ???? at
>     org.jboss.arquillian.container.impl.ContainerImpl.start(ContainerImpl.java:179)
>     ???? at
>     org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:137)
>     ???? at
>     org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:133)
>     ???? at
>     org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forContainer(ContainerLifecycleController.java:208)
>     ???? at
>     org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startContainer(ContainerLifecycleController.java:133)
>     ???? at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>     ???? at
>     sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>     ???? at
>     sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>     ???? at java.lang.reflect.Method.invoke(Method.java:498)
>     ???? at
>     org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
>     ???? at
>     org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103)
>     ???? at
>     org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:90)
>     ???? at
>     org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:54)
>     ???? at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>     ???? at
>     sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>     ???? at
>     sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>     ???? at java.lang.reflect.Method.invoke(Method.java:498)
>     ???? at
>     org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
>     ???? at
>     org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:95)
>     ???? at
>     org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:133)
>     ???? at
>     org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:105)
>     ???? at
>     org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:62)
>     ???? at
>     org.keycloak.testsuite.arquillian.AuthServerTestEnricher.startAuthContainer(AuthServerTestEnricher.java:321)
>     ???? at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>     ???? at
>     sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>     ???? at
>     sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>     ???? at java.lang.reflect.Method.invoke(Method.java:498)
>     ???? at
>     org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
>     ???? at
>     org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103)
>     ???? at
>     org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:90)
>     ???? at
>     org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:133)
>     ???? at
>     org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:105)
>     ???? at
>     org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:62)
>     ???? at
>     org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:83)
>     ???? at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>     ???? at
>     sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>     ???? at
>     sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>     ???? at java.lang.reflect.Method.invoke(Method.java:498)
>     ???? at
>     org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
>     ???? at
>     org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103)
>     ???? at
>     org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:90)
>     ???? at
>     org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:69)
>     ???? at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>     ???? at
>     sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>     ???? at
>     sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>     ???? at java.lang.reflect.Method.invoke(Method.java:498)
>     ???? at
>     org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
>     ???? at
>     org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:95)
>     ???? at
>     org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:133)
>     ???? at
>     org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:105)
>     ???? at
>     org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeSuite(EventTestRunnerAdaptor.java:70)
>     ???? at
>     org.jboss.arquillian.junit.AdaptorManager.initializeAdaptor(AdaptorManager.java:23)
>     ???? at
>     org.jboss.arquillian.junit.AdaptorManagerWithNotifier.initializeAdaptor(AdaptorManagerWithNotifier.java:19)
>     ???? at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:109)
>     ???? at
>     org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367)
>     ???? at
>     org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
>     ???? at
>     org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
>     ???? at
>     org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
>     ???? at
>     org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
>     ???? at
>     org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
>     ???? at
>     org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
>     Caused by: java.lang.RuntimeException: Failed to connect to database
>     ???? at
>     org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.getConnection(DefaultJpaConnectionProviderFactory.java:382)
>     ???? at
>     org.keycloak.connections.jpa.updater.liquibase.lock.LiquibaseDBLockProvider.lazyInit(LiquibaseDBLockProvider.java:65)
>     ???? at
>     org.keycloak.connections.jpa.updater.liquibase.lock.LiquibaseDBLockProvider.lambda$waitForLock$0(LiquibaseDBLockProvider.java:97)
>     ???? at
>     org.keycloak.models.utils.KeycloakModelUtils.suspendJtaTransaction(KeycloakModelUtils.java:678)
>     ???? at
>     org.keycloak.connections.jpa.updater.liquibase.lock.LiquibaseDBLockProvider.waitForLock(LiquibaseDBLockProvider.java:95)
>     ???? at
>     org.keycloak.services.resources.KeycloakApplication$1.run(KeycloakApplication.java:148)
>     ???? at
>     org.keycloak.models.utils.KeycloakModelUtils.runJobInTransaction(KeycloakModelUtils.java:227)
>     ???? at
>     org.keycloak.services.resources.KeycloakApplication.<init>(KeycloakApplication.java:141)
>     ???? at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
>     Method)
>     ???? at
>     sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>     ???? at
>     sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>     ???? at
>     java.lang.reflect.Constructor.newInstance(Constructor.java:423)
>     ???? at
>     org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:154)
>     ???? ... 77 more
>     Caused by: java.lang.ClassNotFoundException:
>     ???? at java.lang.Class.forName0(Native Method)
>     ???? at java.lang.Class.forName(Class.java:264)
>     ???? at
>     org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.getConnection(DefaultJpaConnectionProviderFactory.java:378)
>     ???? ... 89 more
>
>     _______________________________________________
>     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 alexis.almeida at gmail.com  Sat Feb  9 15:17:02 2019
From: alexis.almeida at gmail.com (Alexis Almeida)
Date: Sat, 9 Feb 2019 18:17:02 -0200
Subject: [keycloak-dev] [keycloak-user] Get a GSSCredential when user
 browser is not in Active Directory domain
Message-ID: <CA+H6wMyeppxKiPsqE=Bd1Lm2LiNR=ws58ET-Q14_4Fr-ZMUmVw@mail.gmail.com>

> I originally asked this on the user list but I'm making a change to
Federation.
> I had asked on the dev list earlier about this on the dev as I started to
see how this would work
> I got the Kerberos Ticket and serialized it to a Base 64 string. it
deserializes to a GSSCredential

> Now I have to put the Base 64 token into the  access token

> Any guidance?

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

Hi Chris,

I hope this help you some way.

In a similar situation I created a service provider endpoint that get
Access Token as input and, after validation, generate a new bearer token
with custom claims. In that claim I put additional parameters.

This generated bearer token isn't associated to user session so I put into
this new token a new claim with the jti of the original Access Token.

From alexis.almeida at gmail.com  Sat Feb  9 19:15:56 2019
From: alexis.almeida at gmail.com (Alexis Almeida)
Date: Sat, 9 Feb 2019 22:15:56 -0200
Subject: [keycloak-dev] Authentication SPI - Pinning the IDP
Message-ID: <CA+H6wMyx4_8wq1FazG21T+QRF3H1K_BefiFPf3TtVHhvm=B=rw@mail.gmail.com>

> We have a requirement to pin a
> keycloak client to a specific group of
> login options i.e. they can only login via
> a social provider and not a local
> username/password, BUT we also
> wish to allow certain users the ability
> to override the behavior.

-----------

Hi Rohith,

I think you could solve this problem putting an alternative authenticator
provider between the "Identity Provider Redirector" and the "User and
password form" authenticator in browser flow.

In your provider you can implement all of the rules to check if you must or
not accept login with local user/password.

If the user bypass social login you can catch it in your provider and force
a fail If itsn't allowed.

I've done something like that using a provider that only requires OTP in
some applications.

Regards

Alexis

From mauriciogiacomini at hotmail.com  Mon Feb 11 07:12:14 2019
From: mauriciogiacomini at hotmail.com (=?iso-8859-1?Q?Maur=EDcio_Giacomini_Penteado?=)
Date: Mon, 11 Feb 2019 12:12:14 +0000
Subject: [keycloak-dev] OAuth2 with SAML Authentication
Message-ID: <CY4PR07MB3494286DC652986ECBC0ED3AA8640@CY4PR07MB3494.namprd07.prod.outlook.com>

Hi folks


I am working with some legacy systems that rely on an identity server based on SAML tokens.
Therefore, I do not have the excellent features provided by the OAuth2, OpenID, and UMA specifications on these systems.


I am looking for some documents to help me activate Keycloak as an identity server that works with OAuth2, but using SAML tokens for authentication.

It would help a lot if such configurations were possible. Please, if anyone knows documents to help me, let me know.


Kind regards,

Mauricio.


From psilva at redhat.com  Mon Feb 11 07:52:57 2019
From: psilva at redhat.com (Pedro Igor Silva)
Date: Mon, 11 Feb 2019 10:52:57 -0200
Subject: [keycloak-dev] OAuth2 with SAML Authentication
In-Reply-To: <CY4PR07MB3494286DC652986ECBC0ED3AA8640@CY4PR07MB3494.namprd07.prod.outlook.com>
References: <CY4PR07MB3494286DC652986ECBC0ED3AA8640@CY4PR07MB3494.namprd07.prod.outlook.com>
Message-ID: <CAJrcDBfiFzrwYE3egNpps3goTpuzZztyo2GXK2ZN0CKapTMZZw@mail.gmail.com>

Hi Mauricio,

keycloak-dev is not the right audience for such questions. Could you send
your message to keycloak-user instead ?

Regards.
Pedro Igor

On Mon, Feb 11, 2019 at 10:31 AM Maur?cio Giacomini Penteado <
mauriciogiacomini at hotmail.com> wrote:

> Hi folks
>
>
> I am working with some legacy systems that rely on an identity server
> based on SAML tokens.
> Therefore, I do not have the excellent features provided by the OAuth2,
> OpenID, and UMA specifications on these systems.
>
>
> I am looking for some documents to help me activate Keycloak as an
> identity server that works with OAuth2, but using SAML tokens for
> authentication.
>
> It would help a lot if such configurations were possible. Please, if
> anyone knows documents to help me, let me know.
>
>
> Kind regards,
>
> Mauricio.
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From slaskawi at redhat.com  Mon Feb 11 08:54:50 2019
From: slaskawi at redhat.com (Sebastian Laskawiec)
Date: Mon, 11 Feb 2019 14:54:50 +0100
Subject: [keycloak-dev] [keycloak-user] Remove realm in HA environment
 throw org.keycloak.models.ModelException:
 javax.persistence.OptimisticLockException
In-Reply-To: <CAA9R9O6tqS=nf=f4UwMje0qupBHLaD1m+wbLeZczPzDP0w=N7Q@mail.gmail.com>
References: <CAF8MQahMG++70x_DFMfU4KyfhuiBctOft-2F7pfjztGBPn0XcQ@mail.gmail.com>
	<CAA9R9O7MO1Z4md4ZOZuySvH0T0Sx4d-yYqLCpndDtLSHqdsUcA@mail.gmail.com>
	<CAF8MQahNN-QLZaR2McxyWK53+UicBzLPFrOyggwOKoFS3yq3_w@mail.gmail.com>
	<CAA9R9O6tqS=nf=f4UwMje0qupBHLaD1m+wbLeZczPzDP0w=N7Q@mail.gmail.com>
Message-ID: <CAA9R9O4x=7ZPhx0y7mGJpxAuKTVkTwmAC3YUSw3LxyNdX1FVWw@mail.gmail.com>

Dropping the Keycloak User mailing list.

@Marek - so do we want to do something with it? Have you heard any more
complains about this?

On Tue, Feb 5, 2019 at 2:31 PM Sebastian Laskawiec <slaskawi at redhat.com>
wrote:

> So perhaps you can slightly modify your performance test to do steps 1..3
> multiple times and then just wipe out all the realms that were created?
>
> On Mon, Feb 4, 2019 at 2:47 PM madhura nishshanka <
> madhura.nishshanka at gmail.com> wrote:
>
>> I was invoking following 1,2,and 3 steps sequentially in one thread and
>> then the 4th step in a seperate thread. The whole test was done with
>> multiple theads in parallel.
>>
>> 1) Create realm with a user
>> 2) Create another user on the same realm
>> 3) Delete orginal user
>> 4) Delete the new realm.
>>
>> On Mon, Feb 4, 2019, 6:10 PM Sebastian Laskawiec <slaskawi at redhat.com
>> wrote:
>>
>>> Let me add +Marek Posolda <mposolda at redhat.com>, maybe he'll have
>>> better idea, what might be causing this...
>>>
>>> The error happened here [1]. Hibernate wanted to remove a
>>> given RoleEntity object but between `em.remove(roleEntity)` and
>>> `em.flush()`, some other transaction had removed that object from the
>>> database.
>>>
>>> One of the things that could result in such a behavior is deleting
>>> multiple realms at the same time. Could you please tell us more about your
>>> test? How it works, does it perform operations in sequential order or in
>>> parallel?
>>>
>>> One improvement we could do on our side is to swap flushing the
>>> EntityManager and publishing events. That could also potentially solve your
>>> problem. Marek, what do you think about this?
>>>
>>> Thanks,
>>> Sebastian
>>>
>>> [1]
>>> https://github.com/keycloak/keycloak/blob/7d85ce93bbf33eb11981a6c118abc48cab39742d/model/jpa/src/main/java/org/keycloak/models/jpa/JpaRealmProvider.java#L320
>>>
>>> On Fri, Feb 1, 2019 at 5:12 AM madhura nishshanka <
>>> madhura.nishshanka at gmail.com> wrote:
>>>
>>>> Hi All,
>>>>
>>>> I am getting "org.keycloak.models.ModelException:
>>>> javax.persistence.OptimisticLockException: Batch update returned
>>>> unexpected
>>>> row count from update [0]; actual row count: 0; expected: 1" When a
>>>> realm
>>>> is delte from keycloak java admin client. This occurs in a HA
>>>> environment
>>>> when we do a performance test. Can someone please help me on this?
>>>>
>>>> I am using keycloak  4.8.1 final.
>>>>
>>>> Full exception
>>>> 11:56:25,452 ERROR [org.keycloak.services.error.KeycloakErrorHandler]
>>>> (default task-2) Uncaught server error:
>>>> org.keycloak.models.ModelException:
>>>> javax.persistence.OptimisticLockException: Batch update returned
>>>> unexpected
>>>> row count from update [0]; actual row count: 0; expected: 1
>>>>         at
>>>>
>>>> org.keycloak.connections.jpa.PersistenceExceptionConverter.convert(PersistenceExceptionConverter.java:61)
>>>>         at
>>>>
>>>> org.keycloak.connections.jpa.PersistenceExceptionConverter.invoke(PersistenceExceptionConverter.java:51)
>>>>         at com.sun.proxy.$Proxy99.flush(Unknown Source)
>>>>         at
>>>>
>>>> org.keycloak.models.jpa.JpaRealmProvider.removeRole(JpaRealmProvider.java:320)
>>>>         at
>>>>
>>>> org.keycloak.models.jpa.JpaRealmProvider.removeClient(JpaRealmProvider.java:567)
>>>>         at
>>>>
>>>> *org.keycloak.models.jpa.JpaRealmProvider.removeRealm(JpaRealmProvider.java:153)*
>>>>         at
>>>>
>>>> org.keycloak.models.cache.infinispan.RealmCacheSession.removeRealm(RealmCacheSession.java:486)
>>>>         at
>>>>
>>>> org.keycloak.services.managers.RealmManager.removeRealm(RealmManager.java:248)
>>>>         at
>>>>
>>>> org.keycloak.services.resources.admin.RealmAdminResource.deleteRealm(RealmAdminResource.java:453)
>>>>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>>         at
>>>>
>>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>>>>         at
>>>>
>>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>>         at java.lang.reflect.Method.invoke(Method.java:498)
>>>>         at
>>>>
>>>> org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:140)
>>>>         at
>>>>
>>>> org.jboss.resteasy.core.ResourceMethodInvoker.internalInvokeOnTarget(ResourceMethodInvoker.java:509)
>>>>         at
>>>>
>>>> org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTargetAfterFilter(ResourceMethodInvoker.java:399)
>>>>         at
>>>>
>>>> org.jboss.resteasy.core.ResourceMethodInvoker.lambda$invokeOnTarget$0(ResourceMethodInvoker.java:363)
>>>>         at
>>>>
>>>> org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:358)
>>>>         at
>>>>
>>>> org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:365)
>>>>         at
>>>>
>>>> org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:337)
>>>>         at
>>>>
>>>> org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:137)
>>>>         at
>>>>
>>>> org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:106)
>>>>         at
>>>>
>>>> org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:132)
>>>>         at
>>>>
>>>> org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:100)
>>>>         at
>>>>
>>>> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:443)
>>>>         at
>>>>
>>>> org.jboss.resteasy.core.SynchronousDispatcher.lambda$invoke$4(SynchronousDispatcher.java:233)
>>>>         at
>>>>
>>>> org.jboss.resteasy.core.SynchronousDispatcher.lambda$preprocess$0(SynchronousDispatcher.java:139)
>>>>         at
>>>>
>>>> org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:358)
>>>>         at
>>>>
>>>> org.jboss.resteasy.core.SynchronousDispatcher.preprocess(SynchronousDispatcher.java:142)
>>>>         at
>>>>
>>>> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:219)
>>>>         at
>>>>
>>>> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:227)
>>>>         at
>>>>
>>>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
>>>>         at
>>>>
>>>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
>>>>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:791)
>>>>         at
>>>>
>>>> io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:74)
>>>>         at
>>>>
>>>> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
>>>>         at
>>>>
>>>> org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:90)
>>>>         at
>>>> io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
>>>>         at
>>>>
>>>> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
>>>>         at
>>>>
>>>> io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
>>>>         at
>>>>
>>>> io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
>>>>         at
>>>>
>>>> io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:68)
>>>>         at
>>>>
>>>> io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
>>>>         at
>>>>
>>>> org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
>>>>         at
>>>>
>>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>>>>         at
>>>>
>>>> io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:132)
>>>>         at
>>>>
>>>> io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
>>>>         at
>>>>
>>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>>>>         at
>>>>
>>>> io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
>>>>         at
>>>>
>>>> io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
>>>>         at
>>>>
>>>> io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
>>>>         at
>>>>
>>>> io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
>>>>         at
>>>>
>>>> io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
>>>>         at
>>>>
>>>> io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
>>>>         at
>>>>
>>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>>>>         at
>>>>
>>>> org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
>>>>         at
>>>>
>>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>>>>         at
>>>>
>>>> org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
>>>>         at
>>>>
>>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>>>>         at
>>>>
>>>> io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
>>>>         at
>>>>
>>>> io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
>>>>         at
>>>>
>>>> io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
>>>>         at
>>>>
>>>> io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
>>>>         at
>>>>
>>>> io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
>>>>         at
>>>>
>>>> io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
>>>>         at
>>>>
>>>> org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
>>>>         at
>>>>
>>>> org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
>>>>         at
>>>>
>>>> org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
>>>>         at
>>>>
>>>> org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
>>>>         at
>>>>
>>>> org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
>>>>         at
>>>>
>>>> io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
>>>>         at
>>>>
>>>> io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
>>>>         at
>>>>
>>>> io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
>>>>         at
>>>> io.undertow.server.Connectors.executeRootHandler(Connectors.java:360)
>>>>         at
>>>> io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
>>>>         at
>>>>
>>>> org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
>>>>         at
>>>>
>>>> org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
>>>>         at
>>>>
>>>> org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
>>>>         at
>>>>
>>>> org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
>>>>         at java.lang.Thread.run(Thread.java:748)
>>>> Caused by: javax.persistence.OptimisticLockException: Batch update
>>>> returned
>>>> unexpected row count from update [0]; actual row count: 0; expected: 1
>>>>         at
>>>>
>>>> org.hibernate.internal.ExceptionConverterImpl.wrapStaleStateException(ExceptionConverterImpl.java:238)
>>>>         at
>>>>
>>>> org.hibernate.internal.ExceptionConverterImpl.convert(ExceptionConverterImpl.java:93)
>>>>         at
>>>>
>>>> org.hibernate.internal.ExceptionConverterImpl.convert(ExceptionConverterImpl.java:181)
>>>>         at
>>>>
>>>> org.hibernate.internal.ExceptionConverterImpl.convert(ExceptionConverterImpl.java:188)
>>>>         at
>>>> org.hibernate.internal.SessionImpl.doFlush(SessionImpl.java:1460)
>>>>         at
>>>> org.hibernate.internal.SessionImpl.flush(SessionImpl.java:1440)
>>>>         at sun.reflect.GeneratedMethodAccessor483.invoke(Unknown Source)
>>>>         at
>>>>
>>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>>         at java.lang.reflect.Method.invoke(Method.java:498)
>>>>         at
>>>>
>>>> org.keycloak.connections.jpa.PersistenceExceptionConverter.invoke(PersistenceExceptionConverter.java:49)
>>>>         ... 78 more
>>>> Caused by: org.hibernate.StaleStateException: Batch update returned
>>>> unexpected row count from update [0]; actual row count: 0; expected: 1
>>>>         at
>>>>
>>>> org.hibernate.jdbc.Expectations$BasicExpectation.checkBatched(Expectations.java:67)
>>>>         at
>>>>
>>>> org.hibernate.jdbc.Expectations$BasicExpectation.verifyOutcome(Expectations.java:54)
>>>>         at
>>>>
>>>> org.hibernate.engine.jdbc.batch.internal.NonBatchingBatch.addToBatch(NonBatchingBatch.java:46)
>>>>         at
>>>>
>>>> org.hibernate.persister.entity.AbstractEntityPersister.delete(AbstractEntityPersister.java:3478)
>>>>         at
>>>>
>>>> org.hibernate.persister.entity.AbstractEntityPersister.delete(AbstractEntityPersister.java:3735)
>>>>         at
>>>>
>>>> org.hibernate.action.internal.EntityDeleteAction.execute(EntityDeleteAction.java:99)
>>>>         at
>>>>
>>>> org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:604)
>>>>         at
>>>>
>>>> org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:478)
>>>>         at
>>>>
>>>> org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:356)
>>>>         at
>>>>
>>>> org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:39)
>>>>         at
>>>> org.hibernate.internal.SessionImpl.doFlush(SessionImpl.java:1454)
>>>>         ... 83 more
>>>>
>>>> Thanks
>>>> Madhura
>>>> _______________________________________________
>>>> keycloak-user mailing list
>>>> keycloak-user at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>
>>>

From mposolda at redhat.com  Mon Feb 11 12:08:05 2019
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 11 Feb 2019 18:08:05 +0100
Subject: [keycloak-dev] [keycloak-user] Remove realm in HA environment
 throw org.keycloak.models.ModelException:
 javax.persistence.OptimisticLockException
In-Reply-To: <CAA9R9O4x=7ZPhx0y7mGJpxAuKTVkTwmAC3YUSw3LxyNdX1FVWw@mail.gmail.com>
References: <CAF8MQahMG++70x_DFMfU4KyfhuiBctOft-2F7pfjztGBPn0XcQ@mail.gmail.com>
	<CAA9R9O7MO1Z4md4ZOZuySvH0T0Sx4d-yYqLCpndDtLSHqdsUcA@mail.gmail.com>
	<CAF8MQahNN-QLZaR2McxyWK53+UicBzLPFrOyggwOKoFS3yq3_w@mail.gmail.com>
	<CAA9R9O6tqS=nf=f4UwMje0qupBHLaD1m+wbLeZczPzDP0w=N7Q@mail.gmail.com>
	<CAA9R9O4x=7ZPhx0y7mGJpxAuKTVkTwmAC3YUSw3LxyNdX1FVWw@mail.gmail.com>
Message-ID: <8a726dc2-fa09-04e0-e2a4-51aecb903127@redhat.com>

Hello,

am I understand correctly that you're creating realms (and then doing 
some other updates on those realms) and the other thread is trying to 
delete the realm?

TBH it looks to me like quite corner case scenario as deleting the realm 
is not very often operation. Considering that we may want to do some 
more refactoring of our RDBMS storage layer in near future and 
considering that deleting realm is quite rare operation, I am not sure 
if we want to prioritize fixing this particular issue?

Maybe others have different opinion, but ATM my vote is to deffer this. 
However if you send PR with the fix, it may be accepted (hard to promise 
as it depends on the amount of refactoring needed and the risk of 
introducing regressions with various databses etc.)

Marek

On 11/02/2019 14:54, Sebastian Laskawiec wrote:
> Dropping the Keycloak User mailing list.
>
> @Marek - so do we want to do something with it? Have you heard any 
> more complains about this?
>
> On Tue, Feb 5, 2019 at 2:31 PM Sebastian Laskawiec 
> <slaskawi at redhat.com <mailto:slaskawi at redhat.com>> wrote:
>
>     So perhaps you can slightly modify your performance test to do
>     steps 1..3 multiple times and then just wipe out all the realms
>     that were created?
>
>     On Mon, Feb 4, 2019 at 2:47 PM madhura nishshanka
>     <madhura.nishshanka at gmail.com
>     <mailto:madhura.nishshanka at gmail.com>> wrote:
>
>         I was invoking following 1,2,and 3 steps sequentially in one
>         thread and then the 4th step in a seperate thread. The whole
>         test was done with multiple theads in parallel.
>
>         1) Create realm with a user
>         2) Create another user on the same realm
>         3) Delete orginal user
>         4) Delete the new realm.
>
>         On Mon, Feb 4, 2019, 6:10 PM Sebastian Laskawiec
>         <slaskawi at redhat.com <mailto:slaskawi at redhat.com> wrote:
>
>             Let me add +Marek Posolda <mailto:mposolda at redhat.com>,
>             maybe he'll have better idea, what might be causing this...
>
>             The error happened here [1]. Hibernate wanted to remove a
>             given?RoleEntity object but between
>             `em.remove(roleEntity)` and `em.flush()`, some other
>             transaction had removed that object from the database.
>
>             One of the things that could result in such a behavior is
>             deleting multiple realms at the same time. Could you
>             please tell us more about your test? How it works, does it
>             perform operations in sequential order or in parallel?
>
>             One improvement we could do on our side is to swap
>             flushing the EntityManager and publishing events. That
>             could also potentially solve your problem. Marek, what do
>             you think about this?
>
>             Thanks,
>             Sebastian
>
>             [1]
>             https://github.com/keycloak/keycloak/blob/7d85ce93bbf33eb11981a6c118abc48cab39742d/model/jpa/src/main/java/org/keycloak/models/jpa/JpaRealmProvider.java#L320
>
>             On Fri, Feb 1, 2019 at 5:12 AM madhura nishshanka
>             <madhura.nishshanka at gmail.com
>             <mailto:madhura.nishshanka at gmail.com>> wrote:
>
>                 Hi All,
>
>                 I am getting "org.keycloak.models.ModelException:
>                 javax.persistence.OptimisticLockException: Batch
>                 update returned unexpected
>                 row count from update [0]; actual row count: 0;
>                 expected: 1" When a realm
>                 is delte from keycloak java admin client. This occurs
>                 in a HA environment
>                 when we do a performance test. Can someone please help
>                 me on this?
>
>                 I am using keycloak? 4.8.1 final.
>
>                 Full exception
>                 11:56:25,452 ERROR
>                 [org.keycloak.services.error.KeycloakErrorHandler]
>                 (default task-2) Uncaught server error:
>                 org.keycloak.models.ModelException:
>                 javax.persistence.OptimisticLockException: Batch
>                 update returned unexpected
>                 row count from update [0]; actual row count: 0;
>                 expected: 1
>                 ? ? ? ? at
>                 org.keycloak.connections.jpa.PersistenceExceptionConverter.convert(PersistenceExceptionConverter.java:61)
>                 ? ? ? ? at
>                 org.keycloak.connections.jpa.PersistenceExceptionConverter.invoke(PersistenceExceptionConverter.java:51)
>                 ? ? ? ? at com.sun.proxy.$Proxy99.flush(Unknown Source)
>                 ? ? ? ? at
>                 org.keycloak.models.jpa.JpaRealmProvider.removeRole(JpaRealmProvider.java:320)
>                 ? ? ? ? at
>                 org.keycloak.models.jpa.JpaRealmProvider.removeClient(JpaRealmProvider.java:567)
>                 ? ? ? ? at
>                 *org.keycloak.models.jpa.JpaRealmProvider.removeRealm(JpaRealmProvider.java:153)*
>                 ? ? ? ? at
>                 org.keycloak.models.cache.infinispan.RealmCacheSession.removeRealm(RealmCacheSession.java:486)
>                 ? ? ? ? at
>                 org.keycloak.services.managers.RealmManager.removeRealm(RealmManager.java:248)
>                 ? ? ? ? at
>                 org.keycloak.services.resources.admin.RealmAdminResource.deleteRealm(RealmAdminResource.java:453)
>                 ? ? ? ? at
>                 sun.reflect.NativeMethodAccessorImpl.invoke0(Native
>                 Method)
>                 ? ? ? ? at
>                 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>                 ? ? ? ? at
>                 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>                 ? ? ? ? at
>                 java.lang.reflect.Method.invoke(Method.java:498)
>                 ? ? ? ? at
>                 org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:140)
>                 ? ? ? ? at
>                 org.jboss.resteasy.core.ResourceMethodInvoker.internalInvokeOnTarget(ResourceMethodInvoker.java:509)
>                 ? ? ? ? at
>                 org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTargetAfterFilter(ResourceMethodInvoker.java:399)
>                 ? ? ? ? at
>                 org.jboss.resteasy.core.ResourceMethodInvoker.lambda$invokeOnTarget$0(ResourceMethodInvoker.java:363)
>                 ? ? ? ? at
>                 org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:358)
>                 ? ? ? ? at
>                 org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:365)
>                 ? ? ? ? at
>                 org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:337)
>                 ? ? ? ? at
>                 org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:137)
>                 ? ? ? ? at
>                 org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:106)
>                 ? ? ? ? at
>                 org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:132)
>                 ? ? ? ? at
>                 org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:100)
>                 ? ? ? ? at
>                 org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:443)
>                 ? ? ? ? at
>                 org.jboss.resteasy.core.SynchronousDispatcher.lambda$invoke$4(SynchronousDispatcher.java:233)
>                 ? ? ? ? at
>                 org.jboss.resteasy.core.SynchronousDispatcher.lambda$preprocess$0(SynchronousDispatcher.java:139)
>                 ? ? ? ? at
>                 org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:358)
>                 ? ? ? ? at
>                 org.jboss.resteasy.core.SynchronousDispatcher.preprocess(SynchronousDispatcher.java:142)
>                 ? ? ? ? at
>                 org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:219)
>                 ? ? ? ? at
>                 org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:227)
>                 ? ? ? ? at
>                 org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
>                 ? ? ? ? at
>                 org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
>                 ? ? ? ? at
>                 javax.servlet.http.HttpServlet.service(HttpServlet.java:791)
>                 ? ? ? ? at
>                 io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:74)
>                 ? ? ? ? at
>                 io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
>                 ? ? ? ? at
>                 org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:90)
>                 ? ? ? ? at
>                 io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
>                 ? ? ? ? at
>                 io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
>                 ? ? ? ? at
>                 io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
>                 ? ? ? ? at
>                 io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
>                 ? ? ? ? at
>                 io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:68)
>                 ? ? ? ? at
>                 io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
>                 ? ? ? ? at
>                 org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
>                 ? ? ? ? at
>                 io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>                 ? ? ? ? at
>                 io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:132)
>                 ? ? ? ? at
>                 io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
>                 ? ? ? ? at
>                 io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>                 ? ? ? ? at
>                 io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
>                 ? ? ? ? at
>                 io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
>                 ? ? ? ? at
>                 io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
>                 ? ? ? ? at
>                 io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
>                 ? ? ? ? at
>                 io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
>                 ? ? ? ? at
>                 io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
>                 ? ? ? ? at
>                 io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>                 ? ? ? ? at
>                 org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
>                 ? ? ? ? at
>                 io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>                 ? ? ? ? at
>                 org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
>                 ? ? ? ? at
>                 io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>                 ? ? ? ? at
>                 io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
>                 ? ? ? ? at
>                 io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
>                 ? ? ? ? at
>                 io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
>                 ? ? ? ? at
>                 io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
>                 ? ? ? ? at
>                 io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
>                 ? ? ? ? at
>                 io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
>                 ? ? ? ? at
>                 org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
>                 ? ? ? ? at
>                 org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
>                 ? ? ? ? at
>                 org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
>                 ? ? ? ? at
>                 org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
>                 ? ? ? ? at
>                 org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
>                 ? ? ? ? at
>                 io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
>                 ? ? ? ? at
>                 io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
>                 ? ? ? ? at
>                 io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
>                 ? ? ? ? at
>                 io.undertow.server.Connectors.executeRootHandler(Connectors.java:360)
>                 ? ? ? ? at
>                 io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
>                 ? ? ? ? at
>                 org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
>                 ? ? ? ? at
>                 org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
>                 ? ? ? ? at
>                 org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
>                 ? ? ? ? at
>                 org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
>                 ? ? ? ? at java.lang.Thread.run(Thread.java:748)
>                 Caused by: javax.persistence.OptimisticLockException:
>                 Batch update returned
>                 unexpected row count from update [0]; actual row
>                 count: 0; expected: 1
>                 ? ? ? ? at
>                 org.hibernate.internal.ExceptionConverterImpl.wrapStaleStateException(ExceptionConverterImpl.java:238)
>                 ? ? ? ? at
>                 org.hibernate.internal.ExceptionConverterImpl.convert(ExceptionConverterImpl.java:93)
>                 ? ? ? ? at
>                 org.hibernate.internal.ExceptionConverterImpl.convert(ExceptionConverterImpl.java:181)
>                 ? ? ? ? at
>                 org.hibernate.internal.ExceptionConverterImpl.convert(ExceptionConverterImpl.java:188)
>                 ? ? ? ? at
>                 org.hibernate.internal.SessionImpl.doFlush(SessionImpl.java:1460)
>                 ? ? ? ? at
>                 org.hibernate.internal.SessionImpl.flush(SessionImpl.java:1440)
>                 ? ? ? ? at
>                 sun.reflect.GeneratedMethodAccessor483.invoke(Unknown
>                 Source)
>                 ? ? ? ? at
>                 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>                 ? ? ? ? at
>                 java.lang.reflect.Method.invoke(Method.java:498)
>                 ? ? ? ? at
>                 org.keycloak.connections.jpa.PersistenceExceptionConverter.invoke(PersistenceExceptionConverter.java:49)
>                 ? ? ? ? ... 78 more
>                 Caused by: org.hibernate.StaleStateException: Batch
>                 update returned
>                 unexpected row count from update [0]; actual row
>                 count: 0; expected: 1
>                 ? ? ? ? at
>                 org.hibernate.jdbc.Expectations$BasicExpectation.checkBatched(Expectations.java:67)
>                 ? ? ? ? at
>                 org.hibernate.jdbc.Expectations$BasicExpectation.verifyOutcome(Expectations.java:54)
>                 ? ? ? ? at
>                 org.hibernate.engine.jdbc.batch.internal.NonBatchingBatch.addToBatch(NonBatchingBatch.java:46)
>                 ? ? ? ? at
>                 org.hibernate.persister.entity.AbstractEntityPersister.delete(AbstractEntityPersister.java:3478)
>                 ? ? ? ? at
>                 org.hibernate.persister.entity.AbstractEntityPersister.delete(AbstractEntityPersister.java:3735)
>                 ? ? ? ? at
>                 org.hibernate.action.internal.EntityDeleteAction.execute(EntityDeleteAction.java:99)
>                 ? ? ? ? at
>                 org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:604)
>                 ? ? ? ? at
>                 org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:478)
>                 ? ? ? ? at
>                 org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:356)
>                 ? ? ? ? at
>                 org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:39)
>                 ? ? ? ? at
>                 org.hibernate.internal.SessionImpl.doFlush(SessionImpl.java:1454)
>                 ? ? ? ? ... 83 more
>
>                 Thanks
>                 Madhura
>                 _______________________________________________
>                 keycloak-user mailing list
>                 keycloak-user at lists.jboss.org
>                 <mailto:keycloak-user at lists.jboss.org>
>                 https://lists.jboss.org/mailman/listinfo/keycloak-user
>


From thomas.darimont at googlemail.com  Tue Feb 12 03:39:30 2019
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Tue, 12 Feb 2019 09:39:30 +0100
Subject: [keycloak-dev] Example Setup to simplify the development of
	Keycloak Extensions
Message-ID: <CAK-7U1j1=x1aKwJGG_zXjsSw+qd7_ZEx_3pXb1ie5OyDRqoSyw@mail.gmail.com>

Hello Keycloak-Team,

I found a neat setup to simplify the development of Keycloak extensions.
I setup a "keycloak-extension-playground" project that contains two or more
maven modules:
- keycloak-playground-server
- simple-auth-extension (example)

In the "keycloak-playground-server" module, I wrap a KeycloakServer from
the "keycloak-testsuite-utils" library where one could potentially add
additional configuration. Note that this library must be in (local) Maven
Repository.

The "simple-auth-extension" is an example extension module that
demonstrates the usage of the Authenticator SPI.

I now declare "simple-auth-extension" as a compile time dependency of the
"keycloak-playground-server" project. This ensures that it's classes and
resources are on the classpath of KeycloakServer. Therefore all SPI
implementations in custom extensions can be found. This improves the
debugging experience and speeds up development time.

The example project can be found here:
https://github.com/thomasdarimont/keycloak-extension-playground

What do you guys think about this approach?

Cheers,
Thomas

From thomas.darimont at googlemail.com  Tue Feb 12 03:48:25 2019
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Tue, 12 Feb 2019 09:48:25 +0100
Subject: [keycloak-dev] Keycloak Support for testcontainers-java
Message-ID: <CAK-7U1j4dXc1TW0MY18RB=aK1Lfu-g4MEG4g7h5TP+HrifSmig@mail.gmail.com>

Hello Keycloak Team,

I've seen that Keycloak uses testcontainers-java for Keycloak integration
tests but doesn't seem to expose a Keycloak testcontainer that can be used
outside of the Keycloak build.
I've been working on adding dedicated support for Keycloak to the
testcontainers-java project.

The idea is to be able to parameterize Keycloak containers based on
standard or custom images and provide an API to interact with Keycloak.

Current API would allow to manage Keycloak users in an integration test and
import an existing realm definition. This can be used to test Keycloak
integrations during integration tests with a local Keycloak.

An example for this can be found here:
https://github.com/thomasdarimont/testcontainers-java/blob/feature/keycloak-container/modules/keycloak/src/test/java/org/testcontainers/keycloak/KeycloakContainerTest.java

What do you think about that?

Cheers,
Thomas

From slaskawi at redhat.com  Tue Feb 12 04:21:24 2019
From: slaskawi at redhat.com (Sebastian Laskawiec)
Date: Tue, 12 Feb 2019 10:21:24 +0100
Subject: [keycloak-dev] What Jetty versions we want to support?
Message-ID: <CAA9R9O5hqjn577MjtMfFT1hGQJxhYivFwPdOfd6dOuG76k+v7A@mail.gmail.com>

Hey guys,

I'm working on moving Jetty adapter tests from the old testsuite into the
new one. I can see we support this Jetty versions [1]:
- 8.1
- 9.1
- 9.2
- 9.3
- 9.4

Do we want to keep it this way or maybe concentrate on testing adapters
against 8.1 and 9.4 only (the last major versions)?

Thanks,
Sebastian

[1] grep -lir "keycloak-saml-jetty" --include="*.xml"

From sthorger at redhat.com  Tue Feb 12 05:48:28 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 12 Feb 2019 11:48:28 +0100
Subject: [keycloak-dev] What Jetty versions we want to support?
In-Reply-To: <CAA9R9O5hqjn577MjtMfFT1hGQJxhYivFwPdOfd6dOuG76k+v7A@mail.gmail.com>
References: <CAA9R9O5hqjn577MjtMfFT1hGQJxhYivFwPdOfd6dOuG76k+v7A@mail.gmail.com>
Message-ID: <CAJgngAfA2YLWQ5R4EzidkUdQe0oq=pA__0k5tUQoXLrFGP_5-w@mail.gmail.com>

We test them until we remove ;)

8.1 and 9.1 have already been removed from the community. We need to
confirm if these are needed by Fuse (we don't support Jetty directly for
RH-SSO, but rather only through Fuse). If Fuse relies on these we need to
continue testing them.

9.2 and 9.3 still has users in the community (25 dls of each the last 3
months, but that is only direct dls through website, not sure if folks also
use them from Maven central). We should keep these for now though and
consider deprecating at some point in the future.

On Tue, 12 Feb 2019 at 10:24, Sebastian Laskawiec <slaskawi at redhat.com>
wrote:

> Hey guys,
>
> I'm working on moving Jetty adapter tests from the old testsuite into the
> new one. I can see we support this Jetty versions [1]:
> - 8.1
> - 9.1
> - 9.2
> - 9.3
> - 9.4
>
> Do we want to keep it this way or maybe concentrate on testing adapters
> against 8.1 and 9.4 only (the last major versions)?
>
> Thanks,
> Sebastian
>
> [1] grep -lir "keycloak-saml-jetty" --include="*.xml"
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From slaskawi at redhat.com  Tue Feb 12 05:59:10 2019
From: slaskawi at redhat.com (Sebastian Laskawiec)
Date: Tue, 12 Feb 2019 11:59:10 +0100
Subject: [keycloak-dev] What Jetty versions we want to support?
In-Reply-To: <CAJgngAfA2YLWQ5R4EzidkUdQe0oq=pA__0k5tUQoXLrFGP_5-w@mail.gmail.com>
References: <CAA9R9O5hqjn577MjtMfFT1hGQJxhYivFwPdOfd6dOuG76k+v7A@mail.gmail.com>
	<CAJgngAfA2YLWQ5R4EzidkUdQe0oq=pA__0k5tUQoXLrFGP_5-w@mail.gmail.com>
Message-ID: <CAA9R9O4oqKfq8jOkwV2hQNiH2x=Ci7VQ9VYGMOpCU4kWQ6LdRQ@mail.gmail.com>

Ok, understood! Thanks a lot for the info Stian!

On Tue, Feb 12, 2019 at 11:48 AM Stian Thorgersen <sthorger at redhat.com>
wrote:

> We test them until we remove ;)
>
> 8.1 and 9.1 have already been removed from the community. We need to
> confirm if these are needed by Fuse (we don't support Jetty directly for
> RH-SSO, but rather only through Fuse). If Fuse relies on these we need to
> continue testing them.
>
> 9.2 and 9.3 still has users in the community (25 dls of each the last 3
> months, but that is only direct dls through website, not sure if folks also
> use them from Maven central). We should keep these for now though and
> consider deprecating at some point in the future.
>
> On Tue, 12 Feb 2019 at 10:24, Sebastian Laskawiec <slaskawi at redhat.com>
> wrote:
>
>> Hey guys,
>>
>> I'm working on moving Jetty adapter tests from the old testsuite into the
>> new one. I can see we support this Jetty versions [1]:
>> - 8.1
>> - 9.1
>> - 9.2
>> - 9.3
>> - 9.4
>>
>> Do we want to keep it this way or maybe concentrate on testing adapters
>> against 8.1 and 9.4 only (the last major versions)?
>>
>> Thanks,
>> Sebastian
>>
>> [1] grep -lir "keycloak-saml-jetty" --include="*.xml"
>>
> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>

From sthorger at redhat.com  Tue Feb 12 06:21:31 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 12 Feb 2019 12:21:31 +0100
Subject: [keycloak-dev] Example Setup to simplify the development of
 Keycloak Extensions
In-Reply-To: <CAK-7U1j1=x1aKwJGG_zXjsSw+qd7_ZEx_3pXb1ie5OyDRqoSyw@mail.gmail.com>
References: <CAK-7U1j1=x1aKwJGG_zXjsSw+qd7_ZEx_3pXb1ie5OyDRqoSyw@mail.gmail.com>
Message-ID: <CAJgngAdKVWgxtpH9jmoNFRTtuGy5mTDH-q6c7Cjt7Mf0DnN+Fg@mail.gmail.com>

I'd say it would be better to target the real distribution rather than the
KeycloakServer. It should be reasonably easy to setup Arquillian to use the
Keycloak distribution from Maven Central and allow it to hot-deploy
extensions for testing purposes.

On Tue, 12 Feb 2019 at 09:42, Thomas Darimont <
thomas.darimont at googlemail.com> wrote:

> Hello Keycloak-Team,
>
> I found a neat setup to simplify the development of Keycloak extensions.
> I setup a "keycloak-extension-playground" project that contains two or more
> maven modules:
> - keycloak-playground-server
> - simple-auth-extension (example)
>
> In the "keycloak-playground-server" module, I wrap a KeycloakServer from
> the "keycloak-testsuite-utils" library where one could potentially add
> additional configuration. Note that this library must be in (local) Maven
> Repository.
>
> The "simple-auth-extension" is an example extension module that
> demonstrates the usage of the Authenticator SPI.
>
> I now declare "simple-auth-extension" as a compile time dependency of the
> "keycloak-playground-server" project. This ensures that it's classes and
> resources are on the classpath of KeycloakServer. Therefore all SPI
> implementations in custom extensions can be found. This improves the
> debugging experience and speeds up development time.
>
> The example project can be found here:
> https://github.com/thomasdarimont/keycloak-extension-playground
>
> What do you guys think about this approach?
>
> Cheers,
> Thomas
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From Sebastian.Loesch at governikus.de  Tue Feb 12 06:22:23 2019
From: Sebastian.Loesch at governikus.de (=?iso-8859-1?Q?L=F6sch=2C_Sebastian?=)
Date: Tue, 12 Feb 2019 11:22:23 +0000
Subject: [keycloak-dev] Certificate subject DN is provider dependent
Message-ID: <76d2854ebcf943a39f30f2ba4891984c@BOSKGEXC01.boskg.local>

Hello Keycloak developers,

I am currently working on configuring keycloak for X.509 certificate login.
We store the whole user certificate's subject DN as user attribute. During the login we match the authentication certificate's subjectDN against the value stored in the user attributes.
The subject DN is determined executing:
cert.getSubjectDN().getName()

Here we have a problem regarding the subject DN order. We realized that the subject DN order is security provider specific:

?         Using SUN security provider we get a subject DN like:
"EMAILADDRESS=bjensen at example.com, CN=Ms. Barbara J Jensen III, O=example.com, ST=California, C=US"

?         Using BouncyCastle security provider we get a subject DN like:
"C=US,ST=California,O=example.com,CN=Ms. Barbara J Jensen III,E=bjensen at example.com"
This is obviously a problem.
Does anybody else ran into the same problem?

In my opinion it would be better to use:

cert.getSubjectX500Principal().getName(X500Principal.CANONICAL)
to determine the subject DN, as the result is provider independent.
But this would be an backward incompatible change in Method
org.keycloak.authentication.authenticators.x509.AbstractX509ClientCertificateAuthenticator.UserIdentityExtractorBuilder.fromConfig()

What is your opinion?

Best regards
Sebastian

--
Solution Engineering
--
Governikus GmbH & Co. KG
Hochschulring 4
28359 Bremen, Germany

Phone: +49 421 204 95 - 28
Fax: +49 421 204 95 - 11
E-Mail: Sebastian.Loesch at governikus.de<mailto:Sebastian.Loesch at governikus.de>
www.governikus.de<http://www.governikus.de/>
--
Governikus GmbH & Co. KG
Aufsichtsratsvorsitzender: Dr. Martin Hagen | Amtsgericht Bremen HRA
22041
Gesch?ftsf?hrer: Dr. Stephan Klein

Pers?nlich haftende Gesellschafterin: Governikus Bremen GmbH
Gesch?ftsf?hrer: Dr. Stephan Klein | Amtsgericht Bremen HRB 18756


****************************************************
Wir sind umgezogen! Bitte beachten Sie unsere neue Anschrift: Hochschulring 4, 28359 Bremen

Veranstaltungsvorschau: Besuchen Sie uns...
Dataport Hausmesse | 02.04.2019 | Hamburg - Schnelsen<https://www.dataport.de/Seiten/Aktuelles/Veranstaltungen/190402-Hausmesse-Dataport.aspx>
Digitaler Staat | 02. + 03.04.2019 | Berlin<https://www.digitaler-staat.org/>
7. Zukunftskongress Staat & Verwaltung | 27. - 29.05.2019 | Berlin<https://www.zukunftskongress.info/de>
Kongress Baden-W?rttemberg | 04.07.2019 | Stuttgart<https://www.bw-4-0.de/>

[cid:image8a82cf.JPG at 26f9b88d.448c29be]<http://www.jahrestagung.governikus.de/>

From thomas.darimont at googlemail.com  Tue Feb 12 06:32:08 2019
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Tue, 12 Feb 2019 12:32:08 +0100
Subject: [keycloak-dev] Example Setup to simplify the development of
 Keycloak Extensions
In-Reply-To: <CAJgngAdKVWgxtpH9jmoNFRTtuGy5mTDH-q6c7Cjt7Mf0DnN+Fg@mail.gmail.com>
References: <CAK-7U1j1=x1aKwJGG_zXjsSw+qd7_ZEx_3pXb1ie5OyDRqoSyw@mail.gmail.com>
	<CAJgngAdKVWgxtpH9jmoNFRTtuGy5mTDH-q6c7Cjt7Mf0DnN+Fg@mail.gmail.com>
Message-ID: <CAK-7U1jj7DhuwwSqbZfYDiXBW_HKW69UOvY_k1g5s8K+F0bL2w@mail.gmail.com>

HI Stian,

Thanks for the feedback. In my experience using Arquillian is rather slow -
at least I haven't seen an example setup that doesn't need 30+ seconds
round-trip time per change (without hot-code replacement). Do you have a
fast example at hand (< 10sec round-trip time)?

The aforementioned approach is easy to use and makes a cold-start
round-trip much faster (~5 sec my machine).
Also one can concentrate on the actual extension development first, instead
of figuring out the proper packaging of their extension right from the
beginning, which is IMHO not a nice getting started experience.

Cheers,
Thomas

Am Di., 12. Feb. 2019 um 12:21 Uhr schrieb Stian Thorgersen <
sthorger at redhat.com>:

> I'd say it would be better to target the real distribution rather than the
> KeycloakServer. It should be reasonably easy to setup Arquillian to use the
> Keycloak distribution from Maven Central and allow it to hot-deploy
> extensions for testing purposes.
>
> On Tue, 12 Feb 2019 at 09:42, Thomas Darimont <
> thomas.darimont at googlemail.com> wrote:
>
>> Hello Keycloak-Team,
>>
>> I found a neat setup to simplify the development of Keycloak extensions.
>> I setup a "keycloak-extension-playground" project that contains two or
>> more
>> maven modules:
>> - keycloak-playground-server
>> - simple-auth-extension (example)
>>
>> In the "keycloak-playground-server" module, I wrap a KeycloakServer from
>> the "keycloak-testsuite-utils" library where one could potentially add
>> additional configuration. Note that this library must be in (local) Maven
>> Repository.
>>
>> The "simple-auth-extension" is an example extension module that
>> demonstrates the usage of the Authenticator SPI.
>>
>> I now declare "simple-auth-extension" as a compile time dependency of the
>> "keycloak-playground-server" project. This ensures that it's classes and
>> resources are on the classpath of KeycloakServer. Therefore all SPI
>> implementations in custom extensions can be found. This improves the
>> debugging experience and speeds up development time.
>>
>> The example project can be found here:
>> https://github.com/thomasdarimont/keycloak-extension-playground
>>
>> What do you guys think about this approach?
>>
>> Cheers,
>> Thomas
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>

From thomas.darimont at googlemail.com  Tue Feb 12 06:51:36 2019
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Tue, 12 Feb 2019 12:51:36 +0100
Subject: [keycloak-dev] Certificate subject DN is provider dependent
In-Reply-To: <76d2854ebcf943a39f30f2ba4891984c@BOSKGEXC01.boskg.local>
References: <76d2854ebcf943a39f30f2ba4891984c@BOSKGEXC01.boskg.local>
Message-ID: <CAK-7U1hLTOg2pFX0WyXLE+PmtZLAOYwSovprKq_W8j5LusKreQ@mail.gmail.com>

Hi Sebastian,

how about Keycloak would introduce an option for this authenticator like:
"Use canonical principal extraction" on/off with default "off",
meaning the default behavior stays the same. "on" would then mean to use
the "canonical" option for extracting the subject as you suggested.

Cheers,
Thomas

Am Di., 12. Feb. 2019 um 12:33 Uhr schrieb L?sch, Sebastian <
Sebastian.Loesch at governikus.de>:

> Hello Keycloak developers,
>
> I am currently working on configuring keycloak for X.509 certificate login.
> We store the whole user certificate's subject DN as user attribute. During
> the login we match the authentication certificate's subjectDN against the
> value stored in the user attributes.
> The subject DN is determined executing:
> cert.getSubjectDN().getName()
>
> Here we have a problem regarding the subject DN order. We realized that
> the subject DN order is security provider specific:
>
> ?         Using SUN security provider we get a subject DN like:
> "EMAILADDRESS=bjensen at example.com, CN=Ms. Barbara J Jensen III, O=
> example.com, ST=California, C=US"
>
> ?         Using BouncyCastle security provider we get a subject DN like:
> "C=US,ST=California,O=example.com,CN=Ms. Barbara J Jensen III,E=
> bjensen at example.com"
> This is obviously a problem.
> Does anybody else ran into the same problem?
>
> In my opinion it would be better to use:
>
> cert.getSubjectX500Principal().getName(X500Principal.CANONICAL)
> to determine the subject DN, as the result is provider independent.
> But this would be an backward incompatible change in Method
>
> org.keycloak.authentication.authenticators.x509.AbstractX509ClientCertificateAuthenticator.UserIdentityExtractorBuilder.fromConfig()
>
> What is your opinion?
>
> Best regards
> Sebastian
>
> --
> Solution Engineering
> --
> Governikus GmbH & Co. KG
> Hochschulring 4
> 28359 Bremen, Germany
>
> Phone: +49 421 204 95 - 28
> Fax: +49 421 204 95 - 11
> E-Mail: Sebastian.Loesch at governikus.de<mailto:
> Sebastian.Loesch at governikus.de>
> www.governikus.de<http://www.governikus.de/>
> --
> Governikus GmbH & Co. KG
> Aufsichtsratsvorsitzender: Dr. Martin Hagen | Amtsgericht Bremen HRA
> 22041
> Gesch?ftsf?hrer: Dr. Stephan Klein
>
> Pers?nlich haftende Gesellschafterin: Governikus Bremen GmbH
> Gesch?ftsf?hrer: Dr. Stephan Klein | Amtsgericht Bremen HRB 18756
>
>
> ****************************************************
> Wir sind umgezogen! Bitte beachten Sie unsere neue Anschrift:
> Hochschulring 4, 28359 Bremen
>
> Veranstaltungsvorschau: Besuchen Sie uns...
> Dataport Hausmesse | 02.04.2019 | Hamburg - Schnelsen<
> https://www.dataport.de/Seiten/Aktuelles/Veranstaltungen/190402-Hausmesse-Dataport.aspx
> >
> Digitaler Staat | 02. + 03.04.2019 | Berlin<
> https://www.digitaler-staat.org/>
> 7. Zukunftskongress Staat & Verwaltung | 27. - 29.05.2019 | Berlin<
> https://www.zukunftskongress.info/de>
> Kongress Baden-W?rttemberg | 04.07.2019 | Stuttgart<https://www.bw-4-0.de/
> >
>
> [cid:image8a82cf.JPG at 26f9b88d.448c29be]<
> http://www.jahrestagung.governikus.de/>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From sblanc at redhat.com  Tue Feb 12 06:57:32 2019
From: sblanc at redhat.com (Sebastien Blanc)
Date: Tue, 12 Feb 2019 12:57:32 +0100
Subject: [keycloak-dev] Example Setup to simplify the development of
 Keycloak Extensions
In-Reply-To: <CAK-7U1jj7DhuwwSqbZfYDiXBW_HKW69UOvY_k1g5s8K+F0bL2w@mail.gmail.com>
References: <CAK-7U1j1=x1aKwJGG_zXjsSw+qd7_ZEx_3pXb1ie5OyDRqoSyw@mail.gmail.com>
	<CAJgngAdKVWgxtpH9jmoNFRTtuGy5mTDH-q6c7Cjt7Mf0DnN+Fg@mail.gmail.com>
	<CAK-7U1jj7DhuwwSqbZfYDiXBW_HKW69UOvY_k1g5s8K+F0bL2w@mail.gmail.com>
Message-ID: <CAMZCGg_jwEvimLtcS7N_qcjEK9XYis7Mon79dL4+c+bf1xtk4A@mail.gmail.com>

I just tried it out and I must admit it's pretty nice to have a such fast
feedback loop while changing the code of the extension. To bootstrap the
development of a new extension I think this is something we must explore as
it increases the developer experience a lot.


On Tue, Feb 12, 2019 at 12:35 PM Thomas Darimont <
thomas.darimont at googlemail.com> wrote:

> HI Stian,
>
> Thanks for the feedback. In my experience using Arquillian is rather slow -
> at least I haven't seen an example setup that doesn't need 30+ seconds
> round-trip time per change (without hot-code replacement). Do you have a
> fast example at hand (< 10sec round-trip time)?
>
> The aforementioned approach is easy to use and makes a cold-start
> round-trip much faster (~5 sec my machine).
> Also one can concentrate on the actual extension development first, instead
> of figuring out the proper packaging of their extension right from the
> beginning, which is IMHO not a nice getting started experience.
>
> Cheers,
> Thomas
>
> Am Di., 12. Feb. 2019 um 12:21 Uhr schrieb Stian Thorgersen <
> sthorger at redhat.com>:
>
> > I'd say it would be better to target the real distribution rather than
> the
> > KeycloakServer. It should be reasonably easy to setup Arquillian to use
> the
> > Keycloak distribution from Maven Central and allow it to hot-deploy
> > extensions for testing purposes.
> >
> > On Tue, 12 Feb 2019 at 09:42, Thomas Darimont <
> > thomas.darimont at googlemail.com> wrote:
> >
> >> Hello Keycloak-Team,
> >>
> >> I found a neat setup to simplify the development of Keycloak extensions.
> >> I setup a "keycloak-extension-playground" project that contains two or
> >> more
> >> maven modules:
> >> - keycloak-playground-server
> >> - simple-auth-extension (example)
> >>
> >> In the "keycloak-playground-server" module, I wrap a KeycloakServer from
> >> the "keycloak-testsuite-utils" library where one could potentially add
> >> additional configuration. Note that this library must be in (local)
> Maven
> >> Repository.
> >>
> >> The "simple-auth-extension" is an example extension module that
> >> demonstrates the usage of the Authenticator SPI.
> >>
> >> I now declare "simple-auth-extension" as a compile time dependency of
> the
> >> "keycloak-playground-server" project. This ensures that it's classes and
> >> resources are on the classpath of KeycloakServer. Therefore all SPI
> >> implementations in custom extensions can be found. This improves the
> >> debugging experience and speeds up development time.
> >>
> >> The example project can be found here:
> >> https://github.com/thomasdarimont/keycloak-extension-playground
> >>
> >> What do you guys think about this approach?
> >>
> >> Cheers,
> >> Thomas
> >> _______________________________________________
> >> 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.Loesch at governikus.de  Tue Feb 12 07:00:26 2019
From: Sebastian.Loesch at governikus.de (=?utf-8?B?TMO2c2NoLCBTZWJhc3RpYW4=?=)
Date: Tue, 12 Feb 2019 12:00:26 +0000
Subject: [keycloak-dev] Certificate subject DN is provider dependent
In-Reply-To: <CAK-7U1hLTOg2pFX0WyXLE+PmtZLAOYwSovprKq_W8j5LusKreQ@mail.gmail.com>
References: <76d2854ebcf943a39f30f2ba4891984c@BOSKGEXC01.boskg.local>
	<CAK-7U1hLTOg2pFX0WyXLE+PmtZLAOYwSovprKq_W8j5LusKreQ@mail.gmail.com>
Message-ID: <8814d7715dbf475f949d843762ce4068@BOSKGEXC01.boskg.local>

Hello Thomas,

 

sounds good. Would you be happy, if I provide a pull request fort that?  It seem?s not a big thing to implement.

 

Best regards,

Sebastian

 

Von: Thomas Darimont <thomas.darimont at googlemail.com> 
Gesendet: Dienstag, 12. Februar 2019 12:52
An: L?sch, Sebastian <Sebastian.Loesch at governikus.de>
Cc: keycloak-dev <keycloak-dev at lists.jboss.org>
Betreff: Re: [keycloak-dev] Certificate subject DN is provider dependent

 

Hi Sebastian,

 

how about Keycloak would introduce an option for this authenticator like: "Use canonical principal extraction" on/off with default "off", 

meaning the default behavior stays the same. "on" would then mean to use the "canonical" option for extracting the subject as you suggested.

 

Cheers,

Thomas

 

Am Di., 12. Feb. 2019 um 12:33 Uhr schrieb L?sch, Sebastian <Sebastian.Loesch at governikus.de <mailto:Sebastian.Loesch at governikus.de> >:

Hello Keycloak developers,

I am currently working on configuring keycloak for X.509 certificate login.
We store the whole user certificate's subject DN as user attribute. During the login we match the authentication certificate's subjectDN against the value stored in the user attributes.
The subject DN is determined executing:
cert.getSubjectDN().getName()

Here we have a problem regarding the subject DN order. We realized that the subject DN order is security provider specific:

?         Using SUN security provider we get a subject DN like:
"EMAILADDRESS=bjensen at example.com <mailto:bjensen at example.com> , CN=Ms. Barbara J Jensen III, O=example.com <http://example.com> , ST=California, C=US"

?         Using BouncyCastle security provider we get a subject DN like:
"C=US,ST=California,O=example.com <http://example.com> ,CN=Ms. Barbara J Jensen III,E=bjensen at example.com <mailto:bjensen at example.com> "
This is obviously a problem.
Does anybody else ran into the same problem?

In my opinion it would be better to use:

cert.getSubjectX500Principal().getName(X500Principal.CANONICAL)
to determine the subject DN, as the result is provider independent.
But this would be an backward incompatible change in Method
org.keycloak.authentication.authenticators.x509.AbstractX509ClientCertificateAuthenticator.UserIdentityExtractorBuilder.fromConfig()

What is your opinion?

Best regards
Sebastian

--
Solution Engineering
--
Governikus GmbH & Co. KG
Hochschulring 4
28359 Bremen, Germany

Phone: +49 421 204 95 - 28
Fax: +49 421 204 95 - 11
E-Mail: Sebastian.Loesch at governikus.de <mailto:Sebastian.Loesch at governikus.de> <mailto:Sebastian.Loesch at governikus.de <mailto:Sebastian.Loesch at governikus.de> >
www.governikus.de <http://www.governikus.de> <http://www.governikus.de/>
--
Governikus GmbH & Co. KG
Aufsichtsratsvorsitzender: Dr. Martin Hagen | Amtsgericht Bremen HRA
22041
Gesch?ftsf?hrer: Dr. Stephan Klein

Pers?nlich haftende Gesellschafterin: Governikus Bremen GmbH
Gesch?ftsf?hrer: Dr. Stephan Klein | Amtsgericht Bremen HRB 18756


****************************************************
Wir sind umgezogen! Bitte beachten Sie unsere neue Anschrift: Hochschulring 4, 28359 Bremen

Veranstaltungsvorschau: Besuchen Sie uns...
Dataport Hausmesse | 02.04.2019 | Hamburg - Schnelsen<https://www.dataport.de/Seiten/Aktuelles/Veranstaltungen/190402-Hausmesse-Dataport.aspx>
Digitaler Staat | 02. + 03.04.2019 | Berlin<https://www.digitaler-staat.org/>
7. Zukunftskongress Staat & Verwaltung | 27. - 29.05.2019 | Berlin<https://www.zukunftskongress.info/de>
Kongress Baden-W?rttemberg | 04.07.2019 | Stuttgart<https://www.bw-4-0.de/>

[cid:image8a82cf.JPG at 26f9b88d.448c29be]<http://www.jahrestagung.governikus.de/>
_______________________________________________
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 psilva at redhat.com  Tue Feb 12 07:19:01 2019
From: psilva at redhat.com (Pedro Igor Silva)
Date: Tue, 12 Feb 2019 10:19:01 -0200
Subject: [keycloak-dev] Certificate subject DN is provider dependent
In-Reply-To: <CAK-7U1hLTOg2pFX0WyXLE+PmtZLAOYwSovprKq_W8j5LusKreQ@mail.gmail.com>
References: <76d2854ebcf943a39f30f2ba4891984c@BOSKGEXC01.boskg.local>
	<CAK-7U1hLTOg2pFX0WyXLE+PmtZLAOYwSovprKq_W8j5LusKreQ@mail.gmail.com>
Message-ID: <CAJrcDBedQeK35-E5g1Ru9aMyUBQ5LjJ_6=iGWKCKFL4O1nXeNw@mail.gmail.com>

IIRC, email address should be included/parsed as a subject alternative name
extension. BouncyCastle seems doing it right.

What is the JDK version being used?

On Tue, Feb 12, 2019 at 9:57 AM Thomas Darimont <
thomas.darimont at googlemail.com> wrote:

> Hi Sebastian,
>
> how about Keycloak would introduce an option for this authenticator like:
> "Use canonical principal extraction" on/off with default "off",
> meaning the default behavior stays the same. "on" would then mean to use
> the "canonical" option for extracting the subject as you suggested.
>
> Cheers,
> Thomas
>
> Am Di., 12. Feb. 2019 um 12:33 Uhr schrieb L?sch, Sebastian <
> Sebastian.Loesch at governikus.de>:
>
> > Hello Keycloak developers,
> >
> > I am currently working on configuring keycloak for X.509 certificate
> login.
> > We store the whole user certificate's subject DN as user attribute.
> During
> > the login we match the authentication certificate's subjectDN against the
> > value stored in the user attributes.
> > The subject DN is determined executing:
> > cert.getSubjectDN().getName()
> >
> > Here we have a problem regarding the subject DN order. We realized that
> > the subject DN order is security provider specific:
> >
> > ?         Using SUN security provider we get a subject DN like:
> > "EMAILADDRESS=bjensen at example.com, CN=Ms. Barbara J Jensen III, O=
> > example.com, ST=California, C=US"
> >
> > ?         Using BouncyCastle security provider we get a subject DN like:
> > "C=US,ST=California,O=example.com,CN=Ms. Barbara J Jensen III,E=
> > bjensen at example.com"
> > This is obviously a problem.
> > Does anybody else ran into the same problem?
> >
> > In my opinion it would be better to use:
> >
> > cert.getSubjectX500Principal().getName(X500Principal.CANONICAL)
> > to determine the subject DN, as the result is provider independent.
> > But this would be an backward incompatible change in Method
> >
> >
> org.keycloak.authentication.authenticators.x509.AbstractX509ClientCertificateAuthenticator.UserIdentityExtractorBuilder.fromConfig()
> >
> > What is your opinion?
> >
> > Best regards
> > Sebastian
> >
> > --
> > Solution Engineering
> > --
> > Governikus GmbH & Co. KG
> > Hochschulring 4
> > 28359 Bremen, Germany
> >
> > Phone: +49 421 204 95 - 28
> > Fax: +49 421 204 95 - 11
> > E-Mail: Sebastian.Loesch at governikus.de<mailto:
> > Sebastian.Loesch at governikus.de>
> > www.governikus.de<http://www.governikus.de/>
> > --
> > Governikus GmbH & Co. KG
> > Aufsichtsratsvorsitzender: Dr. Martin Hagen | Amtsgericht Bremen HRA
> > 22041
> > Gesch?ftsf?hrer: Dr. Stephan Klein
> >
> > Pers?nlich haftende Gesellschafterin: Governikus Bremen GmbH
> > Gesch?ftsf?hrer: Dr. Stephan Klein | Amtsgericht Bremen HRB 18756
> >
> >
> > ****************************************************
> > Wir sind umgezogen! Bitte beachten Sie unsere neue Anschrift:
> > Hochschulring 4, 28359 Bremen
> >
> > Veranstaltungsvorschau: Besuchen Sie uns...
> > Dataport Hausmesse | 02.04.2019 | Hamburg - Schnelsen<
> >
> https://www.dataport.de/Seiten/Aktuelles/Veranstaltungen/190402-Hausmesse-Dataport.aspx
> > >
> > Digitaler Staat | 02. + 03.04.2019 | Berlin<
> > https://www.digitaler-staat.org/>
> > 7. Zukunftskongress Staat & Verwaltung | 27. - 29.05.2019 | Berlin<
> > https://www.zukunftskongress.info/de>
> > Kongress Baden-W?rttemberg | 04.07.2019 | Stuttgart<
> https://www.bw-4-0.de/
> > >
> >
> > [cid:image8a82cf.JPG at 26f9b88d.448c29be]<
> > http://www.jahrestagung.governikus.de/>
> > _______________________________________________
> > 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 Feb 12 07:23:51 2019
From: psilva at redhat.com (Pedro Igor Silva)
Date: Tue, 12 Feb 2019 10:23:51 -0200
Subject: [keycloak-dev] Certificate subject DN is provider dependent
In-Reply-To: <CAJrcDBedQeK35-E5g1Ru9aMyUBQ5LjJ_6=iGWKCKFL4O1nXeNw@mail.gmail.com>
References: <76d2854ebcf943a39f30f2ba4891984c@BOSKGEXC01.boskg.local>
	<CAK-7U1hLTOg2pFX0WyXLE+PmtZLAOYwSovprKq_W8j5LusKreQ@mail.gmail.com>
	<CAJrcDBedQeK35-E5g1Ru9aMyUBQ5LjJ_6=iGWKCKFL4O1nXeNw@mail.gmail.com>
Message-ID: <CAJrcDBearA9dmhWxLYO6zX07SxELQkr0Y_upFdOjXcd_4-BUzw@mail.gmail.com>

Btw, we also support extracting email using a subject alt name extension.
Maybe we could safely use CANONICAL (which seems to be more aligned with
the specs) and tell people to use this extractor if they want to use email
address from certificates.

On Tue, Feb 12, 2019 at 10:19 AM Pedro Igor Silva <psilva at redhat.com> wrote:

> IIRC, email address should be included/parsed as a subject alternative
> name extension. BouncyCastle seems doing it right.
>
> What is the JDK version being used?
>
> On Tue, Feb 12, 2019 at 9:57 AM Thomas Darimont <
> thomas.darimont at googlemail.com> wrote:
>
>> Hi Sebastian,
>>
>> how about Keycloak would introduce an option for this authenticator like:
>> "Use canonical principal extraction" on/off with default "off",
>> meaning the default behavior stays the same. "on" would then mean to use
>> the "canonical" option for extracting the subject as you suggested.
>>
>> Cheers,
>> Thomas
>>
>> Am Di., 12. Feb. 2019 um 12:33 Uhr schrieb L?sch, Sebastian <
>> Sebastian.Loesch at governikus.de>:
>>
>> > Hello Keycloak developers,
>> >
>> > I am currently working on configuring keycloak for X.509 certificate
>> login.
>> > We store the whole user certificate's subject DN as user attribute.
>> During
>> > the login we match the authentication certificate's subjectDN against
>> the
>> > value stored in the user attributes.
>> > The subject DN is determined executing:
>> > cert.getSubjectDN().getName()
>> >
>> > Here we have a problem regarding the subject DN order. We realized that
>> > the subject DN order is security provider specific:
>> >
>> > ?         Using SUN security provider we get a subject DN like:
>> > "EMAILADDRESS=bjensen at example.com, CN=Ms. Barbara J Jensen III, O=
>> > example.com, ST=California, C=US"
>> >
>> > ?         Using BouncyCastle security provider we get a subject DN like:
>> > "C=US,ST=California,O=example.com,CN=Ms. Barbara J Jensen III,E=
>> > bjensen at example.com"
>> > This is obviously a problem.
>> > Does anybody else ran into the same problem?
>> >
>> > In my opinion it would be better to use:
>> >
>> > cert.getSubjectX500Principal().getName(X500Principal.CANONICAL)
>> > to determine the subject DN, as the result is provider independent.
>> > But this would be an backward incompatible change in Method
>> >
>> >
>> org.keycloak.authentication.authenticators.x509.AbstractX509ClientCertificateAuthenticator.UserIdentityExtractorBuilder.fromConfig()
>> >
>> > What is your opinion?
>> >
>> > Best regards
>> > Sebastian
>> >
>> > --
>> > Solution Engineering
>> > --
>> > Governikus GmbH & Co. KG
>> > Hochschulring 4
>> > 28359 Bremen, Germany
>> >
>> > Phone: +49 421 204 95 - 28
>> > Fax: +49 421 204 95 - 11
>> > E-Mail: Sebastian.Loesch at governikus.de<mailto:
>> > Sebastian.Loesch at governikus.de>
>> > www.governikus.de<http://www.governikus.de/>
>> > --
>> > Governikus GmbH & Co. KG
>> > Aufsichtsratsvorsitzender: Dr. Martin Hagen | Amtsgericht Bremen HRA
>> > 22041
>> > Gesch?ftsf?hrer: Dr. Stephan Klein
>> >
>> > Pers?nlich haftende Gesellschafterin: Governikus Bremen GmbH
>> > Gesch?ftsf?hrer: Dr. Stephan Klein | Amtsgericht Bremen HRB 18756
>> >
>> >
>> > ****************************************************
>> > Wir sind umgezogen! Bitte beachten Sie unsere neue Anschrift:
>> > Hochschulring 4, 28359 Bremen
>> >
>> > Veranstaltungsvorschau: Besuchen Sie uns...
>> > Dataport Hausmesse | 02.04.2019 | Hamburg - Schnelsen<
>> >
>> https://www.dataport.de/Seiten/Aktuelles/Veranstaltungen/190402-Hausmesse-Dataport.aspx
>> > >
>> > Digitaler Staat | 02. + 03.04.2019 | Berlin<
>> > https://www.digitaler-staat.org/>
>> > 7. Zukunftskongress Staat & Verwaltung | 27. - 29.05.2019 | Berlin<
>> > https://www.zukunftskongress.info/de>
>> > Kongress Baden-W?rttemberg | 04.07.2019 | Stuttgart<
>> https://www.bw-4-0.de/
>> > >
>> >
>> > [cid:image8a82cf.JPG at 26f9b88d.448c29be]<
>> > http://www.jahrestagung.governikus.de/>
>> > _______________________________________________
>> > 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.Loesch at governikus.de  Tue Feb 12 07:36:18 2019
From: Sebastian.Loesch at governikus.de (=?utf-8?B?TMO2c2NoLCBTZWJhc3RpYW4=?=)
Date: Tue, 12 Feb 2019 12:36:18 +0000
Subject: [keycloak-dev] Certificate subject DN is provider dependent
In-Reply-To: <CAJrcDBedQeK35-E5g1Ru9aMyUBQ5LjJ_6=iGWKCKFL4O1nXeNw@mail.gmail.com>
References: <76d2854ebcf943a39f30f2ba4891984c@BOSKGEXC01.boskg.local>
	<CAK-7U1hLTOg2pFX0WyXLE+PmtZLAOYwSovprKq_W8j5LusKreQ@mail.gmail.com>
	<CAJrcDBedQeK35-E5g1Ru9aMyUBQ5LjJ_6=iGWKCKFL4O1nXeNw@mail.gmail.com>
Message-ID: <cf22672e667d4c03b085b3289c290b5f@BOSKGEXC01.boskg.local>

Hello Pedro,

I am using JDK 1.8 Update 201.

Best regards,
Sebastian



Von: Pedro Igor Silva <psilva at redhat.com>
Gesendet: Dienstag, 12. Februar 2019 13:19
An: Thomas Darimont <thomas.darimont at googlemail.com>
Cc: L?sch, Sebastian <Sebastian.Loesch at governikus.de>; keycloak-dev <keycloak-dev at lists.jboss.org>
Betreff: Re: [keycloak-dev] Certificate subject DN is provider dependent

IIRC, email address should be included/parsed as a subject alternative name extension. BouncyCastle seems doing it right.

What is the JDK version being used?

On Tue, Feb 12, 2019 at 9:57 AM Thomas Darimont <mailto:thomas.darimont at googlemail.com> wrote:
Hi Sebastian,

how about Keycloak would introduce an option for this authenticator like:
"Use canonical principal extraction" on/off with default "off",
meaning the default behavior stays the same. "on" would then mean to use
the "canonical" option for extracting the subject as you suggested.

Cheers,
Thomas

Am Di., 12. Feb. 2019 um 12:33 Uhr schrieb L?sch, Sebastian <
mailto:Sebastian.Loesch at governikus.de>:

> Hello Keycloak developers,
>
> I am currently working on configuring keycloak for X.509 certificate login.
> We store the whole user certificate's subject DN as user attribute. During
> the login we match the authentication certificate's subjectDN against the
> value stored in the user attributes.
> The subject DN is determined executing:
> cert.getSubjectDN().getName()
>
> Here we have a problem regarding the subject DN order. We realized that
> the subject DN order is security provider specific:
>
> ?         Using SUN security provider we get a subject DN like:
> "EMAILADDRESS=mailto:bjensen at example.com, CN=Ms. Barbara J Jensen III, O=
> http://example.com, ST=California, C=US"
>
> ?         Using BouncyCastle security provider we get a subject DN like:
> "C=US,ST=California,O=http://example.com,CN=Ms. Barbara J Jensen III,E=
> mailto:bjensen at example.com"
> This is obviously a problem.
> Does anybody else ran into the same problem?
>
> In my opinion it would be better to use:
>
> cert.getSubjectX500Principal().getName(X500Principal.CANONICAL)
> to determine the subject DN, as the result is provider independent.
> But this would be an backward incompatible change in Method
>
> org.keycloak.authentication.authenticators.x509.AbstractX509ClientCertificateAuthenticator.UserIdentityExtractorBuilder.fromConfig()
>
> What is your opinion?
>
> Best regards
> Sebastian
>
> --
> Solution Engineering
> --
> Governikus GmbH & Co. KG
> Hochschulring 4
> 28359 Bremen, Germany
>
> Phone: +49 421 204 95 - 28
> Fax: +49 421 204 95 - 11
> E-Mail: mailto:Sebastian.Loesch at governikus.de<mailto:
> mailto:Sebastian.Loesch at governikus.de>
> http://www.governikus.de<http://www.governikus.de/>
> --
> Governikus GmbH & Co. KG
> Aufsichtsratsvorsitzender: Dr. Martin Hagen | Amtsgericht Bremen HRA
> 22041
> Gesch?ftsf?hrer: Dr. Stephan Klein
>
> Pers?nlich haftende Gesellschafterin: Governikus Bremen GmbH
> Gesch?ftsf?hrer: Dr. Stephan Klein | Amtsgericht Bremen HRB 18756
>
>
> ****************************************************
> Wir sind umgezogen! Bitte beachten Sie unsere neue Anschrift:
> Hochschulring 4, 28359 Bremen
>
> Veranstaltungsvorschau: Besuchen Sie uns...
> Dataport Hausmesse | 02.04.2019 | Hamburg - Schnelsen<
> https://www.dataport.de/Seiten/Aktuelles/Veranstaltungen/190402-Hausmesse-Dataport.aspx
> >
> Digitaler Staat | 02. + 03.04.2019 | Berlin<
> https://www.digitaler-staat.org/>
> 7. Zukunftskongress Staat & Verwaltung | 27. - 29.05.2019 | Berlin<
> https://www.zukunftskongress.info/de>
> Kongress Baden-W?rttemberg | 04.07.2019 | Stuttgart<https://www.bw-4-0.de/
> >
>
> [cid:image8a82cf.JPG at 26f9b88d.448c29be]<
> http://www.jahrestagung.governikus.de/>
>
****************************************************
Neue Adresse!
Ab 1.1.2019 ?ndert sich unsere Bremer Anschrift: Hochschulring 4, 28359 Bremen

7. Anwenderforum AusweisApp2 | 21.01.2019 | Berlin
OMNISECURE | 21. - 23.01.2019 | Berlin

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



From slaskawi at redhat.com  Tue Feb 12 08:02:55 2019
From: slaskawi at redhat.com (Sebastian Laskawiec)
Date: Tue, 12 Feb 2019 14:02:55 +0100
Subject: [keycloak-dev] [keycloak-user] Remove realm in HA environment
 throw org.keycloak.models.ModelException:
 javax.persistence.OptimisticLockException
In-Reply-To: <8a726dc2-fa09-04e0-e2a4-51aecb903127@redhat.com>
References: <CAF8MQahMG++70x_DFMfU4KyfhuiBctOft-2F7pfjztGBPn0XcQ@mail.gmail.com>
	<CAA9R9O7MO1Z4md4ZOZuySvH0T0Sx4d-yYqLCpndDtLSHqdsUcA@mail.gmail.com>
	<CAF8MQahNN-QLZaR2McxyWK53+UicBzLPFrOyggwOKoFS3yq3_w@mail.gmail.com>
	<CAA9R9O6tqS=nf=f4UwMje0qupBHLaD1m+wbLeZczPzDP0w=N7Q@mail.gmail.com>
	<CAA9R9O4x=7ZPhx0y7mGJpxAuKTVkTwmAC3YUSw3LxyNdX1FVWw@mail.gmail.com>
	<8a726dc2-fa09-04e0-e2a4-51aecb903127@redhat.com>
Message-ID: <CAA9R9O6dmk5+CLNTkHhrnkcei=bRp5tzVe5t8GbsjK6NjhdrRA@mail.gmail.com>

+madhura nishshanka <madhura.nishshanka at gmail.com>

I totally agree with you Marek.

Madhura, would that be ok with you for now? Once we revisit our storage
layer, we should have better option on the table.

On Mon, Feb 11, 2019 at 6:08 PM Marek Posolda <mposolda at redhat.com> wrote:

> Hello,
>
> am I understand correctly that you're creating realms (and then doing some
> other updates on those realms) and the other thread is trying to delete the
> realm?
>
> TBH it looks to me like quite corner case scenario as deleting the realm
> is not very often operation. Considering that we may want to do some more
> refactoring of our RDBMS storage layer in near future and considering that
> deleting realm is quite rare operation, I am not sure if we want to
> prioritize fixing this particular issue?
>
> Maybe others have different opinion, but ATM my vote is to deffer this.
> However if you send PR with the fix, it may be accepted (hard to promise as
> it depends on the amount of refactoring needed and the risk of introducing
> regressions with various databses etc.)
>
> Marek
>
> On 11/02/2019 14:54, Sebastian Laskawiec wrote:
>
> Dropping the Keycloak User mailing list.
>
> @Marek - so do we want to do something with it? Have you heard any more
> complains about this?
>
> On Tue, Feb 5, 2019 at 2:31 PM Sebastian Laskawiec <slaskawi at redhat.com>
> wrote:
>
>> So perhaps you can slightly modify your performance test to do steps 1..3
>> multiple times and then just wipe out all the realms that were created?
>>
>> On Mon, Feb 4, 2019 at 2:47 PM madhura nishshanka <
>> madhura.nishshanka at gmail.com> wrote:
>>
>>> I was invoking following 1,2,and 3 steps sequentially in one thread and
>>> then the 4th step in a seperate thread. The whole test was done with
>>> multiple theads in parallel.
>>>
>>> 1) Create realm with a user
>>> 2) Create another user on the same realm
>>> 3) Delete orginal user
>>> 4) Delete the new realm.
>>>
>>> On Mon, Feb 4, 2019, 6:10 PM Sebastian Laskawiec <slaskawi at redhat.com
>>> wrote:
>>>
>>>> Let me add +Marek Posolda <mposolda at redhat.com>, maybe he'll have
>>>> better idea, what might be causing this...
>>>>
>>>> The error happened here [1]. Hibernate wanted to remove a
>>>> given RoleEntity object but between `em.remove(roleEntity)` and
>>>> `em.flush()`, some other transaction had removed that object from the
>>>> database.
>>>>
>>>> One of the things that could result in such a behavior is deleting
>>>> multiple realms at the same time. Could you please tell us more about your
>>>> test? How it works, does it perform operations in sequential order or in
>>>> parallel?
>>>>
>>>> One improvement we could do on our side is to swap flushing the
>>>> EntityManager and publishing events. That could also potentially solve your
>>>> problem. Marek, what do you think about this?
>>>>
>>>> Thanks,
>>>> Sebastian
>>>>
>>>> [1]
>>>> https://github.com/keycloak/keycloak/blob/7d85ce93bbf33eb11981a6c118abc48cab39742d/model/jpa/src/main/java/org/keycloak/models/jpa/JpaRealmProvider.java#L320
>>>>
>>>> On Fri, Feb 1, 2019 at 5:12 AM madhura nishshanka <
>>>> madhura.nishshanka at gmail.com> wrote:
>>>>
>>>>> Hi All,
>>>>>
>>>>> I am getting "org.keycloak.models.ModelException:
>>>>> javax.persistence.OptimisticLockException: Batch update returned
>>>>> unexpected
>>>>> row count from update [0]; actual row count: 0; expected: 1" When a
>>>>> realm
>>>>> is delte from keycloak java admin client. This occurs in a HA
>>>>> environment
>>>>> when we do a performance test. Can someone please help me on this?
>>>>>
>>>>> I am using keycloak  4.8.1 final.
>>>>>
>>>>> Full exception
>>>>> 11:56:25,452 ERROR [org.keycloak.services.error.KeycloakErrorHandler]
>>>>> (default task-2) Uncaught server error:
>>>>> org.keycloak.models.ModelException:
>>>>> javax.persistence.OptimisticLockException: Batch update returned
>>>>> unexpected
>>>>> row count from update [0]; actual row count: 0; expected: 1
>>>>>         at
>>>>>
>>>>> org.keycloak.connections.jpa.PersistenceExceptionConverter.convert(PersistenceExceptionConverter.java:61)
>>>>>         at
>>>>>
>>>>> org.keycloak.connections.jpa.PersistenceExceptionConverter.invoke(PersistenceExceptionConverter.java:51)
>>>>>         at com.sun.proxy.$Proxy99.flush(Unknown Source)
>>>>>         at
>>>>>
>>>>> org.keycloak.models.jpa.JpaRealmProvider.removeRole(JpaRealmProvider.java:320)
>>>>>         at
>>>>>
>>>>> org.keycloak.models.jpa.JpaRealmProvider.removeClient(JpaRealmProvider.java:567)
>>>>>         at
>>>>>
>>>>> *org.keycloak.models.jpa.JpaRealmProvider.removeRealm(JpaRealmProvider.java:153)*
>>>>>         at
>>>>>
>>>>> org.keycloak.models.cache.infinispan.RealmCacheSession.removeRealm(RealmCacheSession.java:486)
>>>>>         at
>>>>>
>>>>> org.keycloak.services.managers.RealmManager.removeRealm(RealmManager.java:248)
>>>>>         at
>>>>>
>>>>> org.keycloak.services.resources.admin.RealmAdminResource.deleteRealm(RealmAdminResource.java:453)
>>>>>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>>>         at
>>>>>
>>>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>>>>>         at
>>>>>
>>>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>>>         at java.lang.reflect.Method.invoke(Method.java:498)
>>>>>         at
>>>>>
>>>>> org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:140)
>>>>>         at
>>>>>
>>>>> org.jboss.resteasy.core.ResourceMethodInvoker.internalInvokeOnTarget(ResourceMethodInvoker.java:509)
>>>>>         at
>>>>>
>>>>> org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTargetAfterFilter(ResourceMethodInvoker.java:399)
>>>>>         at
>>>>>
>>>>> org.jboss.resteasy.core.ResourceMethodInvoker.lambda$invokeOnTarget$0(ResourceMethodInvoker.java:363)
>>>>>         at
>>>>>
>>>>> org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:358)
>>>>>         at
>>>>>
>>>>> org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:365)
>>>>>         at
>>>>>
>>>>> org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:337)
>>>>>         at
>>>>>
>>>>> org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:137)
>>>>>         at
>>>>>
>>>>> org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:106)
>>>>>         at
>>>>>
>>>>> org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:132)
>>>>>         at
>>>>>
>>>>> org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:100)
>>>>>         at
>>>>>
>>>>> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:443)
>>>>>         at
>>>>>
>>>>> org.jboss.resteasy.core.SynchronousDispatcher.lambda$invoke$4(SynchronousDispatcher.java:233)
>>>>>         at
>>>>>
>>>>> org.jboss.resteasy.core.SynchronousDispatcher.lambda$preprocess$0(SynchronousDispatcher.java:139)
>>>>>         at
>>>>>
>>>>> org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:358)
>>>>>         at
>>>>>
>>>>> org.jboss.resteasy.core.SynchronousDispatcher.preprocess(SynchronousDispatcher.java:142)
>>>>>         at
>>>>>
>>>>> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:219)
>>>>>         at
>>>>>
>>>>> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:227)
>>>>>         at
>>>>>
>>>>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
>>>>>         at
>>>>>
>>>>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
>>>>>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:791)
>>>>>         at
>>>>>
>>>>> io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:74)
>>>>>         at
>>>>>
>>>>> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
>>>>>         at
>>>>>
>>>>> org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:90)
>>>>>         at
>>>>> io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
>>>>>         at
>>>>>
>>>>> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
>>>>>         at
>>>>>
>>>>> io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
>>>>>         at
>>>>>
>>>>> io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
>>>>>         at
>>>>>
>>>>> io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:68)
>>>>>         at
>>>>>
>>>>> io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
>>>>>         at
>>>>>
>>>>> org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
>>>>>         at
>>>>>
>>>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>>>>>         at
>>>>>
>>>>> io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:132)
>>>>>         at
>>>>>
>>>>> io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
>>>>>         at
>>>>>
>>>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>>>>>         at
>>>>>
>>>>> io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
>>>>>         at
>>>>>
>>>>> io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
>>>>>         at
>>>>>
>>>>> io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
>>>>>         at
>>>>>
>>>>> io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
>>>>>         at
>>>>>
>>>>> io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
>>>>>         at
>>>>>
>>>>> io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
>>>>>         at
>>>>>
>>>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>>>>>         at
>>>>>
>>>>> org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
>>>>>         at
>>>>>
>>>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>>>>>         at
>>>>>
>>>>> org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
>>>>>         at
>>>>>
>>>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>>>>>         at
>>>>>
>>>>> io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
>>>>>         at
>>>>>
>>>>> io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
>>>>>         at
>>>>>
>>>>> io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
>>>>>         at
>>>>>
>>>>> io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
>>>>>         at
>>>>>
>>>>> io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
>>>>>         at
>>>>>
>>>>> io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
>>>>>         at
>>>>>
>>>>> org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
>>>>>         at
>>>>>
>>>>> org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
>>>>>         at
>>>>>
>>>>> org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
>>>>>         at
>>>>>
>>>>> org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
>>>>>         at
>>>>>
>>>>> org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
>>>>>         at
>>>>>
>>>>> io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
>>>>>         at
>>>>>
>>>>> io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
>>>>>         at
>>>>>
>>>>> io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
>>>>>         at
>>>>> io.undertow.server.Connectors.executeRootHandler(Connectors.java:360)
>>>>>         at
>>>>>
>>>>> io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
>>>>>         at
>>>>>
>>>>> org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
>>>>>         at
>>>>>
>>>>> org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
>>>>>         at
>>>>>
>>>>> org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
>>>>>         at
>>>>>
>>>>> org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
>>>>>         at java.lang.Thread.run(Thread.java:748)
>>>>> Caused by: javax.persistence.OptimisticLockException: Batch update
>>>>> returned
>>>>> unexpected row count from update [0]; actual row count: 0; expected: 1
>>>>>         at
>>>>>
>>>>> org.hibernate.internal.ExceptionConverterImpl.wrapStaleStateException(ExceptionConverterImpl.java:238)
>>>>>         at
>>>>>
>>>>> org.hibernate.internal.ExceptionConverterImpl.convert(ExceptionConverterImpl.java:93)
>>>>>         at
>>>>>
>>>>> org.hibernate.internal.ExceptionConverterImpl.convert(ExceptionConverterImpl.java:181)
>>>>>         at
>>>>>
>>>>> org.hibernate.internal.ExceptionConverterImpl.convert(ExceptionConverterImpl.java:188)
>>>>>         at
>>>>> org.hibernate.internal.SessionImpl.doFlush(SessionImpl.java:1460)
>>>>>         at
>>>>> org.hibernate.internal.SessionImpl.flush(SessionImpl.java:1440)
>>>>>         at sun.reflect.GeneratedMethodAccessor483.invoke(Unknown
>>>>> Source)
>>>>>         at
>>>>>
>>>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>>>         at java.lang.reflect.Method.invoke(Method.java:498)
>>>>>         at
>>>>>
>>>>> org.keycloak.connections.jpa.PersistenceExceptionConverter.invoke(PersistenceExceptionConverter.java:49)
>>>>>         ... 78 more
>>>>> Caused by: org.hibernate.StaleStateException: Batch update returned
>>>>> unexpected row count from update [0]; actual row count: 0; expected: 1
>>>>>         at
>>>>>
>>>>> org.hibernate.jdbc.Expectations$BasicExpectation.checkBatched(Expectations.java:67)
>>>>>         at
>>>>>
>>>>> org.hibernate.jdbc.Expectations$BasicExpectation.verifyOutcome(Expectations.java:54)
>>>>>         at
>>>>>
>>>>> org.hibernate.engine.jdbc.batch.internal.NonBatchingBatch.addToBatch(NonBatchingBatch.java:46)
>>>>>         at
>>>>>
>>>>> org.hibernate.persister.entity.AbstractEntityPersister.delete(AbstractEntityPersister.java:3478)
>>>>>         at
>>>>>
>>>>> org.hibernate.persister.entity.AbstractEntityPersister.delete(AbstractEntityPersister.java:3735)
>>>>>         at
>>>>>
>>>>> org.hibernate.action.internal.EntityDeleteAction.execute(EntityDeleteAction.java:99)
>>>>>         at
>>>>>
>>>>> org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:604)
>>>>>         at
>>>>>
>>>>> org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:478)
>>>>>         at
>>>>>
>>>>> org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:356)
>>>>>         at
>>>>>
>>>>> org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:39)
>>>>>         at
>>>>> org.hibernate.internal.SessionImpl.doFlush(SessionImpl.java:1454)
>>>>>         ... 83 more
>>>>>
>>>>> Thanks
>>>>> Madhura
>>>>> _______________________________________________
>>>>> keycloak-user mailing list
>>>>> keycloak-user at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>
>>>>
>

From slaskawi at redhat.com  Tue Feb 12 08:24:58 2019
From: slaskawi at redhat.com (Sebastian Laskawiec)
Date: Tue, 12 Feb 2019 14:24:58 +0100
Subject: [keycloak-dev] Running custom scripts in Keycloak container image
Message-ID: <CAA9R9O4-0-3D0pLyquAVjHN7qKb=NZosPH-iu51OA2oNXfM99A@mail.gmail.com>

Hey guys,

A while ago, one of our contributors, Wouter, sent an interesting pull
request: https://github.com/jboss-dockerfiles/keycloak/pull/176

The aim is to allow running custom scripts just before Keycloak boots up
and after the main configuration is done. This allows a user to inject his
own scripts (even *.cli) into /opt/jboss/tools/docker-entrypoint.d and
execute them automatically.

This is somewhat related to what the Integrately Team is doing. They
basically use an InitContainer [1] to put additional extensions into our
image. Perhaps with the proposed approach, they could embed a custom script
that would download whatever extensions they need and put them into the
deployments directory?

After thinking about this for a while, and besides really good advantages
of the Pull Request, I have some doubts. The biggest one is about our
guarantees with regard the Keycloak distribution (by saying distribution I
mean the binaries, their structure and Keycloak server location in the
image). If we accept this approach, it will be pretty hard for us to change
any major thing (even some trivial things like the location of the Keycloak
Server) without breaking the client scripts.

Personally, I'm slightly leaning towards accepting this feature, but with a
description in README, that the user scripts may break at any time and in
any version (maybe even we should print this message in our logs). This way
we'll make the contract for such scripts very clear.

What do you think?

Thanks,
Sebastian

[1] https://kubernetes.io/docs/concepts/workloads/pods/init-containers/

From Sebastian.Loesch at governikus.de  Tue Feb 12 08:57:06 2019
From: Sebastian.Loesch at governikus.de (=?iso-8859-1?Q?L=F6sch=2C_Sebastian?=)
Date: Tue, 12 Feb 2019 13:57:06 +0000
Subject: [keycloak-dev] Certificate subject DN is provider dependent
In-Reply-To: <CAJrcDBearA9dmhWxLYO6zX07SxELQkr0Y_upFdOjXcd_4-BUzw@mail.gmail.com>
References: <76d2854ebcf943a39f30f2ba4891984c@BOSKGEXC01.boskg.local>
	<CAK-7U1hLTOg2pFX0WyXLE+PmtZLAOYwSovprKq_W8j5LusKreQ@mail.gmail.com>
	<CAJrcDBedQeK35-E5g1Ru9aMyUBQ5LjJ_6=iGWKCKFL4O1nXeNw@mail.gmail.com>
	<CAJrcDBearA9dmhWxLYO6zX07SxELQkr0Y_upFdOjXcd_4-BUzw@mail.gmail.com>
Message-ID: <99d26631531742279d851c74850fe737@BOSKGEXC01.boskg.local>

Hello developer,

I opened a new issue for Keycloak: https://issues.jboss.org/browse/KEYCLOAK-9554
and provided a pull request: https://github.com/keycloak/keycloak/pull/5878

Best regards,
Sebastian


Von: Pedro Igor Silva <psilva at redhat.com>
Gesendet: Dienstag, 12. Februar 2019 13:24
An: Thomas Darimont <thomas.darimont at googlemail.com>
Cc: L?sch, Sebastian <Sebastian.Loesch at governikus.de>; keycloak-dev <keycloak-dev at lists.jboss.org>
Betreff: Re: [keycloak-dev] Certificate subject DN is provider dependent

Btw, we also support extracting email using a subject alt name extension. Maybe we could safely use CANONICAL (which seems to be more aligned with the specs) and tell people to use this extractor if they want to use email address from certificates.

On Tue, Feb 12, 2019 at 10:19 AM Pedro Igor Silva <psilva at redhat.com<mailto:psilva at redhat.com>> wrote:
IIRC, email address should be included/parsed as a subject alternative name extension. BouncyCastle seems doing it right.

What is the JDK version being used?

On Tue, Feb 12, 2019 at 9:57 AM Thomas Darimont <thomas.darimont at googlemail.com<mailto:thomas.darimont at googlemail.com>> wrote:
Hi Sebastian,

how about Keycloak would introduce an option for this authenticator like:
"Use canonical principal extraction" on/off with default "off",
meaning the default behavior stays the same. "on" would then mean to use
the "canonical" option for extracting the subject as you suggested.

Cheers,
Thomas

Am Di., 12. Feb. 2019 um 12:33 Uhr schrieb L?sch, Sebastian <
Sebastian.Loesch at governikus.de<mailto:Sebastian.Loesch at governikus.de>>:

> Hello Keycloak developers,
>
> I am currently working on configuring keycloak for X.509 certificate login.
> We store the whole user certificate's subject DN as user attribute. During
> the login we match the authentication certificate's subjectDN against the
> value stored in the user attributes.
> The subject DN is determined executing:
> cert.getSubjectDN().getName()
>
> Here we have a problem regarding the subject DN order. We realized that
> the subject DN order is security provider specific:
>
> ?         Using SUN security provider we get a subject DN like:
> "EMAILADDRESS=bjensen at example.com<mailto:bjensen at example.com>, CN=Ms. Barbara J Jensen III, O=
> example.com<http://example.com>, ST=California, C=US"
>
> ?         Using BouncyCastle security provider we get a subject DN like:
> "C=US,ST=California,O=example.com<http://example.com>,CN=Ms. Barbara J Jensen III,E=
> bjensen at example.com<mailto:bjensen at example.com>"
> This is obviously a problem.
> Does anybody else ran into the same problem?
>
> In my opinion it would be better to use:
>
> cert.getSubjectX500Principal().getName(X500Principal.CANONICAL)
> to determine the subject DN, as the result is provider independent.
> But this would be an backward incompatible change in Method
>
> org.keycloak.authentication.authenticators.x509.AbstractX509ClientCertificateAuthenticator.UserIdentityExtractorBuilder.fromConfig()
>
> What is your opinion?
>
> Best regards
> Sebastian
>
> --
> Solution Engineering
> --
> Governikus GmbH & Co. KG
> Hochschulring 4
> 28359 Bremen, Germany
>
> Phone: +49 421 204 95 - 28
> Fax: +49 421 204 95 - 11
> E-Mail: Sebastian.Loesch at governikus.de<mailto:Sebastian.Loesch at governikus.de><mailto:
> Sebastian.Loesch at governikus.de<mailto:Sebastian.Loesch at governikus.de>>
> www.governikus.de<http://www.governikus.de><http://www.governikus.de/>
> --
> Governikus GmbH & Co. KG
> Aufsichtsratsvorsitzender: Dr. Martin Hagen | Amtsgericht Bremen HRA
> 22041
> Gesch?ftsf?hrer: Dr. Stephan Klein
>
> Pers?nlich haftende Gesellschafterin: Governikus Bremen GmbH
> Gesch?ftsf?hrer: Dr. Stephan Klein | Amtsgericht Bremen HRB 18756
>
>
> ****************************************************
> Wir sind umgezogen! Bitte beachten Sie unsere neue Anschrift:
> Hochschulring 4, 28359 Bremen
>
> Veranstaltungsvorschau: Besuchen Sie uns...
> Dataport Hausmesse | 02.04.2019 | Hamburg - Schnelsen<
> https://www.dataport.de/Seiten/Aktuelles/Veranstaltungen/190402-Hausmesse-Dataport.aspx
> >
> Digitaler Staat | 02. + 03.04.2019 | Berlin<
> https://www.digitaler-staat.org/>
> 7. Zukunftskongress Staat & Verwaltung | 27. - 29.05.2019 | Berlin<
> https://www.zukunftskongress.info/de>
> Kongress Baden-W?rttemberg | 04.07.2019 | Stuttgart<https://www.bw-4-0.de/
> >
>
> [cid:image8a82cf.JPG at 26f9b88d.448c29be]<
> http://www.jahrestagung.governikus.de/>
>

****************************************************
Wir sind umgezogen! Bitte beachten Sie unsere neue Anschrift: Hochschulring 4, 28359 Bremen

Veranstaltungsvorschau: Besuchen Sie uns...
Dataport Hausmesse | 02.04.2019 | Hamburg - Schnelsen<https://www.dataport.de/Seiten/Aktuelles/Veranstaltungen/190402-Hausmesse-Dataport.aspx>
Digitaler Staat | 02. + 03.04.2019 | Berlin<https://www.digitaler-staat.org/>
7. Zukunftskongress Staat & Verwaltung | 27. - 29.05.2019 | Berlin<https://www.zukunftskongress.info/de>
Kongress Baden-W?rttemberg | 04.07.2019 | Stuttgart<https://www.bw-4-0.de/>

[cid:image71d7fc.JPG at 4dd78026.4b9f719f]<http://www.jahrestagung.governikus.de/>
_______________________________________________
> 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 psilva at redhat.com  Tue Feb 12 09:27:39 2019
From: psilva at redhat.com (Pedro Igor Silva)
Date: Tue, 12 Feb 2019 12:27:39 -0200
Subject: [keycloak-dev] Certificate subject DN is provider dependent
In-Reply-To: <99d26631531742279d851c74850fe737@BOSKGEXC01.boskg.local>
References: <76d2854ebcf943a39f30f2ba4891984c@BOSKGEXC01.boskg.local>
	<CAK-7U1hLTOg2pFX0WyXLE+PmtZLAOYwSovprKq_W8j5LusKreQ@mail.gmail.com>
	<CAJrcDBedQeK35-E5g1Ru9aMyUBQ5LjJ_6=iGWKCKFL4O1nXeNw@mail.gmail.com>
	<CAJrcDBearA9dmhWxLYO6zX07SxELQkr0Y_upFdOjXcd_4-BUzw@mail.gmail.com>
	<99d26631531742279d851c74850fe737@BOSKGEXC01.boskg.local>
Message-ID: <CAJrcDBcfLnqDbApUPan--n9CW=dNLdRo_eJYfmCn5ihWtbBrDw@mail.gmail.com>

Thanks. I'm still not sure about that new CANONICAL parameter. Added a
comment to your PR.

On Tue, Feb 12, 2019 at 11:57 AM L?sch, Sebastian <
Sebastian.Loesch at governikus.de> wrote:

> Hello developer,
>
>
>
> I opened a new issue for Keycloak:
> https://issues.jboss.org/browse/KEYCLOAK-9554
>
> and provided a pull request:
> https://github.com/keycloak/keycloak/pull/5878
>
>
>
> Best regards,
>
> Sebastian
>
>
>
>
>
> *Von:* Pedro Igor Silva <psilva at redhat.com>
> *Gesendet:* Dienstag, 12. Februar 2019 13:24
> *An:* Thomas Darimont <thomas.darimont at googlemail.com>
> *Cc:* L?sch, Sebastian <Sebastian.Loesch at governikus.de>; keycloak-dev <
> keycloak-dev at lists.jboss.org>
> *Betreff:* Re: [keycloak-dev] Certificate subject DN is provider dependent
>
>
>
> Btw, we also support extracting email using a subject alt name extension.
> Maybe we could safely use CANONICAL (which seems to be more aligned with
> the specs) and tell people to use this extractor if they want to use email
> address from certificates.
>
>
>
> On Tue, Feb 12, 2019 at 10:19 AM Pedro Igor Silva <psilva at redhat.com>
> wrote:
>
> IIRC, email address should be included/parsed as a subject alternative
> name extension. BouncyCastle seems doing it right.
>
>
>
> What is the JDK version being used?
>
>
>
> On Tue, Feb 12, 2019 at 9:57 AM Thomas Darimont <
> thomas.darimont at googlemail.com> wrote:
>
> Hi Sebastian,
>
> how about Keycloak would introduce an option for this authenticator like:
> "Use canonical principal extraction" on/off with default "off",
> meaning the default behavior stays the same. "on" would then mean to use
> the "canonical" option for extracting the subject as you suggested.
>
> Cheers,
> Thomas
>
> Am Di., 12. Feb. 2019 um 12:33 Uhr schrieb L?sch, Sebastian <
> Sebastian.Loesch at governikus.de>:
>
> > Hello Keycloak developers,
> >
> > I am currently working on configuring keycloak for X.509 certificate
> login.
> > We store the whole user certificate's subject DN as user attribute.
> During
> > the login we match the authentication certificate's subjectDN against the
> > value stored in the user attributes.
> > The subject DN is determined executing:
> > cert.getSubjectDN().getName()
> >
> > Here we have a problem regarding the subject DN order. We realized that
> > the subject DN order is security provider specific:
> >
> > ?         Using SUN security provider we get a subject DN like:
> > "EMAILADDRESS=bjensen at example.com, CN=Ms. Barbara J Jensen III, O=
> > example.com, ST=California, C=US"
> >
> > ?         Using BouncyCastle security provider we get a subject DN like:
> > "C=US,ST=California,O=example.com,CN=Ms. Barbara J Jensen III,E=
> > bjensen at example.com"
> > This is obviously a problem.
> > Does anybody else ran into the same problem?
> >
> > In my opinion it would be better to use:
> >
> > cert.getSubjectX500Principal().getName(X500Principal.CANONICAL)
> > to determine the subject DN, as the result is provider independent.
> > But this would be an backward incompatible change in Method
> >
> >
> org.keycloak.authentication.authenticators.x509.AbstractX509ClientCertificateAuthenticator.UserIdentityExtractorBuilder.fromConfig()
> >
> > What is your opinion?
> >
> > Best regards
> > Sebastian
> >
> > --
> > Solution Engineering
> > --
> > Governikus GmbH & Co. KG
> > Hochschulring 4
> > 28359 Bremen, Germany
> >
> > Phone: +49 421 204 95 - 28
> > Fax: +49 421 204 95 - 11
> > E-Mail: Sebastian.Loesch at governikus.de<mailto:
> > Sebastian.Loesch at governikus.de>
> > www.governikus.de<http://www.governikus.de/>
> > --
> > Governikus GmbH & Co. KG
> > Aufsichtsratsvorsitzender: Dr. Martin Hagen | Amtsgericht Bremen HRA
> > 22041
> > Gesch?ftsf?hrer: Dr. Stephan Klein
> >
> > Pers?nlich haftende Gesellschafterin: Governikus Bremen GmbH
> > Gesch?ftsf?hrer: Dr. Stephan Klein | Amtsgericht Bremen HRB 18756
> >
> >
> > ****************************************************
> > Wir sind umgezogen! Bitte beachten Sie unsere neue Anschrift:
> > Hochschulring 4, 28359 Bremen
> >
> > Veranstaltungsvorschau: Besuchen Sie uns...
> > Dataport Hausmesse | 02.04.2019 | Hamburg - Schnelsen<
> >
> https://www.dataport.de/Seiten/Aktuelles/Veranstaltungen/190402-Hausmesse-Dataport.aspx
> > >
> > Digitaler Staat | 02. + 03.04.2019 | Berlin<
> > https://www.digitaler-staat.org/>
> > 7. Zukunftskongress Staat & Verwaltung | 27. - 29.05.2019 | Berlin<
> > https://www.zukunftskongress.info/de>
> > Kongress Baden-W?rttemberg | 04.07.2019 | Stuttgart<
> https://www.bw-4-0.de/
> > >
> >
> > [cid:image8a82cf.JPG at 26f9b88d.448c29be]<
> > http://www.jahrestagung.governikus.de/>
> >
>
>
> ****************************************************
> Wir sind umgezogen! Bitte beachten Sie unsere neue Anschrift:
> Hochschulring 4, 28359 Bremen
>
> Veranstaltungsvorschau: Besuchen Sie uns?
> Dataport Hausmesse | 02.04.2019 | Hamburg ? Schnelsen
> <https://www.dataport.de/Seiten/Aktuelles/Veranstaltungen/190402-Hausmesse-Dataport.aspx>
> Digitaler Staat | 02. + 03.04.2019 | Berlin
> <https://www.digitaler-staat.org/>
> 7. Zukunftskongress Staat & Verwaltung | 27. - 29.05.2019 | Berlin
> <https://www.zukunftskongress.info/de>
> Kongress Baden-W?rttemberg | 04.07.2019 | Stuttgart
> <https://www.bw-4-0.de/>
>
> <http://www.jahrestagung.governikus.de/>
>
> _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>

From thomas.darimont at googlemail.com  Tue Feb 12 09:35:31 2019
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Tue, 12 Feb 2019 15:35:31 +0100
Subject: [keycloak-dev] Running custom scripts in Keycloak container
	image
In-Reply-To: <CAA9R9O4-0-3D0pLyquAVjHN7qKb=NZosPH-iu51OA2oNXfM99A@mail.gmail.com>
References: <CAA9R9O4-0-3D0pLyquAVjHN7qKb=NZosPH-iu51OA2oNXfM99A@mail.gmail.com>
Message-ID: <CAK-7U1jdW-g4bcNbjoDG3yxST3rKHJXn+Zideed4EQTwWGWWew@mail.gmail.com>

Hello,

I'm one of the maintainers of the Keycloak helm chart:
https://github.com/helm/charts/tree/master/stable/keycloak
Since a lot of our users need to adjust the default configuration that is
provided by the Keycloak docker images, we currently generate a
keycloak.cli file that we apply during start. However, some of this
configuration is again overridden by the defaults from the Keycloak docker
image.

See:
https://github.com/helm/charts/blob/master/stable/keycloak/templates/configmap.yaml#L12
Configuration:
https://github.com/helm/charts/blob/master/stable/keycloak/values.yaml#L121

Having dedicated support for config customizations at bootstrap in the
stock Keycloak image would make things much easier here :)

Cheers,
Thomas

Am Di., 12. Feb. 2019 um 14:42 Uhr schrieb Sebastian Laskawiec <
slaskawi at redhat.com>:

> Hey guys,
>
> A while ago, one of our contributors, Wouter, sent an interesting pull
> request: https://github.com/jboss-dockerfiles/keycloak/pull/176
>
> The aim is to allow running custom scripts just before Keycloak boots up
> and after the main configuration is done. This allows a user to inject his
> own scripts (even *.cli) into /opt/jboss/tools/docker-entrypoint.d and
> execute them automatically.
>
> This is somewhat related to what the Integrately Team is doing. They
> basically use an InitContainer [1] to put additional extensions into our
> image. Perhaps with the proposed approach, they could embed a custom script
> that would download whatever extensions they need and put them into the
> deployments directory?
>
> After thinking about this for a while, and besides really good advantages
> of the Pull Request, I have some doubts. The biggest one is about our
> guarantees with regard the Keycloak distribution (by saying distribution I
> mean the binaries, their structure and Keycloak server location in the
> image). If we accept this approach, it will be pretty hard for us to change
> any major thing (even some trivial things like the location of the Keycloak
> Server) without breaking the client scripts.
>
> Personally, I'm slightly leaning towards accepting this feature, but with a
> description in README, that the user scripts may break at any time and in
> any version (maybe even we should print this message in our logs). This way
> we'll make the contract for such scripts very clear.
>
> What do you think?
>
> Thanks,
> Sebastian
>
> [1] https://kubernetes.io/docs/concepts/workloads/pods/init-containers/
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From psilva at redhat.com  Tue Feb 12 10:19:21 2019
From: psilva at redhat.com (Pedro Igor Silva)
Date: Tue, 12 Feb 2019 13:19:21 -0200
Subject: [keycloak-dev] Running custom scripts in Keycloak container
	image
In-Reply-To: <CAK-7U1jdW-g4bcNbjoDG3yxST3rKHJXn+Zideed4EQTwWGWWew@mail.gmail.com>
References: <CAA9R9O4-0-3D0pLyquAVjHN7qKb=NZosPH-iu51OA2oNXfM99A@mail.gmail.com>
	<CAK-7U1jdW-g4bcNbjoDG3yxST3rKHJXn+Zideed4EQTwWGWWew@mail.gmail.com>
Message-ID: <CAJrcDBe+7RZ5iiOw_91o3NC9=c+QWrnBkEWixmxBeFQf=eR6cw@mail.gmail.com>

Regarding the PR from Wouter. Instead of extending the image would be
possible to attach a volume with the scripts that need to be run on
startup? That would avoid the burden of creating a new image to only add a
few files into a directory.

On Tue, Feb 12, 2019 at 12:37 PM Thomas Darimont <
thomas.darimont at googlemail.com> wrote:

> Hello,
>
> I'm one of the maintainers of the Keycloak helm chart:
> https://github.com/helm/charts/tree/master/stable/keycloak
> Since a lot of our users need to adjust the default configuration that is
> provided by the Keycloak docker images, we currently generate a
> keycloak.cli file that we apply during start. However, some of this
> configuration is again overridden by the defaults from the Keycloak docker
> image.
>
> See:
>
> https://github.com/helm/charts/blob/master/stable/keycloak/templates/configmap.yaml#L12
> Configuration:
> https://github.com/helm/charts/blob/master/stable/keycloak/values.yaml#L121
>
> Having dedicated support for config customizations at bootstrap in the
> stock Keycloak image would make things much easier here :)
>
> Cheers,
> Thomas
>
> Am Di., 12. Feb. 2019 um 14:42 Uhr schrieb Sebastian Laskawiec <
> slaskawi at redhat.com>:
>
> > Hey guys,
> >
> > A while ago, one of our contributors, Wouter, sent an interesting pull
> > request: https://github.com/jboss-dockerfiles/keycloak/pull/176
> >
> > The aim is to allow running custom scripts just before Keycloak boots up
> > and after the main configuration is done. This allows a user to inject
> his
> > own scripts (even *.cli) into /opt/jboss/tools/docker-entrypoint.d and
> > execute them automatically.
> >
> > This is somewhat related to what the Integrately Team is doing. They
> > basically use an InitContainer [1] to put additional extensions into our
> > image. Perhaps with the proposed approach, they could embed a custom
> script
> > that would download whatever extensions they need and put them into the
> > deployments directory?
> >
> > After thinking about this for a while, and besides really good advantages
> > of the Pull Request, I have some doubts. The biggest one is about our
> > guarantees with regard the Keycloak distribution (by saying distribution
> I
> > mean the binaries, their structure and Keycloak server location in the
> > image). If we accept this approach, it will be pretty hard for us to
> change
> > any major thing (even some trivial things like the location of the
> Keycloak
> > Server) without breaking the client scripts.
> >
> > Personally, I'm slightly leaning towards accepting this feature, but
> with a
> > description in README, that the user scripts may break at any time and in
> > any version (maybe even we should print this message in our logs). This
> way
> > we'll make the contract for such scripts very clear.
> >
> > What do you think?
> >
> > Thanks,
> > Sebastian
> >
> > [1] https://kubernetes.io/docs/concepts/workloads/pods/init-containers/
> > _______________________________________________
> > 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 hmlnarik at redhat.com  Tue Feb 12 11:25:44 2019
From: hmlnarik at redhat.com (Hynek Mlnarik)
Date: Tue, 12 Feb 2019 17:25:44 +0100
Subject: [keycloak-dev] What Jetty versions we want to support?
In-Reply-To: <CAA9R9O4oqKfq8jOkwV2hQNiH2x=Ci7VQ9VYGMOpCU4kWQ6LdRQ@mail.gmail.com>
References: <CAA9R9O5hqjn577MjtMfFT1hGQJxhYivFwPdOfd6dOuG76k+v7A@mail.gmail.com>
	<CAJgngAfA2YLWQ5R4EzidkUdQe0oq=pA__0k5tUQoXLrFGP_5-w@mail.gmail.com>
	<CAA9R9O4oqKfq8jOkwV2hQNiH2x=Ci7VQ9VYGMOpCU4kWQ6LdRQ@mail.gmail.com>
Message-ID: <CAMvXD=EyCVC7C6sNwQLW+SmacKjpvibpr0fUndjEEN2H1FBGUA@mail.gmail.com>

For Fuse, we use 8.1 [1] and 9.2 [2].

--Hynek

[1]
https://github.com/keycloak/keycloak/blob/4.8.3.Final/distribution/adapters/osgi/features/src/main/resources/features.xml#L54
[2]
https://github.com/keycloak/keycloak/blob/4.8.3.Final/distribution/adapters/osgi/features/src/main/resources/features.xml#L63

On Tue, Feb 12, 2019 at 12:05 PM Sebastian Laskawiec <slaskawi at redhat.com>
wrote:

> Ok, understood! Thanks a lot for the info Stian!
>
> On Tue, Feb 12, 2019 at 11:48 AM Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
> > We test them until we remove ;)
> >
> > 8.1 and 9.1 have already been removed from the community. We need to
> > confirm if these are needed by Fuse (we don't support Jetty directly for
> > RH-SSO, but rather only through Fuse). If Fuse relies on these we need to
> > continue testing them.
> >
> > 9.2 and 9.3 still has users in the community (25 dls of each the last 3
> > months, but that is only direct dls through website, not sure if folks
> also
> > use them from Maven central). We should keep these for now though and
> > consider deprecating at some point in the future.
> >
> > On Tue, 12 Feb 2019 at 10:24, Sebastian Laskawiec <slaskawi at redhat.com>
> > wrote:
> >
> >> Hey guys,
> >>
> >> I'm working on moving Jetty adapter tests from the old testsuite into
> the
> >> new one. I can see we support this Jetty versions [1]:
> >> - 8.1
> >> - 9.1
> >> - 9.2
> >> - 9.3
> >> - 9.4
> >>
> >> Do we want to keep it this way or maybe concentrate on testing adapters
> >> against 8.1 and 9.4 only (the last major versions)?
> >>
> >> Thanks,
> >> Sebastian
> >>
> >> [1] grep -lir "keycloak-saml-jetty" --include="*.xml"
> >>
> > _______________________________________________
> >> 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 hmlnarik at redhat.com  Tue Feb 12 12:01:04 2019
From: hmlnarik at redhat.com (Hynek Mlnarik)
Date: Tue, 12 Feb 2019 18:01:04 +0100
Subject: [keycloak-dev] User TLS client certificate authentication -
 inconsistent DN string representation with LDAP
In-Reply-To: <079961fe-e298-1ea7-d946-f32729785b17@redhat.com>
References: <5D9D597A-206A-4E7C-96E9-DB3368842117@mitre.org>
	<CAA9R9O71Gmg7Vicsxqw9yTivGUpic7fWO6b=WdM44cQVhtcC_Q@mail.gmail.com>
	<BL0PR07MB5009EDA268DBC0E082743001DA8A0@BL0PR07MB5009.namprd07.prod.outlook.com>
	<6d2958f3-da03-bbc7-d37e-3c42bb76d188@redhat.com>
	<CAA9R9O6KShp_SyXNe6usPg0mFY18_AsbytFkBQvC+m5AKRnzDg@mail.gmail.com>
	<BL0PR07MB50091823826745DD5210B5FBDA840@BL0PR07MB5009.namprd07.prod.outlook.com>
	<CAMvXD=HdLyzPhNMV0vzg2Bm9iJFNSB0r0rqFzeTJjUk+GGPreg@mail.gmail.com>
	<BL0PR07MB500945357DB3FB151ED6C20DDA9D0@BL0PR07MB5009.namprd07.prod.outlook.com>
	<079961fe-e298-1ea7-d946-f32729785b17@redhat.com>
Message-ID: <CAMvXD=GqbFQ2GFwmpYiLf3ui4NQDJ2732qugnxNPMGPD57gwkg@mail.gmail.com>

Note: This thread (or slight alteration thereof) has been resurrected in
parallel thread "Certificate subject DN is provider dependent".

On Tue, Jan 29, 2019 at 12:30 PM Marek Posolda <mposolda at redhat.com> wrote:

> The reason for intoduce LdapDn class instead of LdapName was the
> compatibility issue, but I can't recall the details... Some more below
>
> On 19/01/2019 05:04, Nalyvayko, Peter wrote:
> >> I am not very keen on uppercasing attribute type in the proposed patch
> though it might be the most pragmatic way to go. Is it supported by any DN
> > RFC? In any case, any such a normalization would have to take place
> consistently in both places.
> > An alternative is to modify X500NameRDNExtractor.extractUserIdentity in
> keycloak/services/src/main/java/org/keycloak/authentication/authenticators/x509/UserIdentityExtractor.java
> to return new
> LdapName(IETFUtils.valueToString(cn.getFirst().getValue())).toString()
> instead of IETFUtils.valueToString(cn.getFirst().getValue()) (line 92),
> thus in essence normalizing the user identity from subjectDN/issuerDN to
> the representation conformant to a variant of RFC2253 format which can then
> be safely compared to LDAP_ENTRY_DN attribute.
>
> I think that either this change or the proposed change in LdapDn will
> work. However change in X500NameRDNExtractor has the advantage, that it
> will work immediately for the existing users imported from LDAP.
>
> I mean that if we do the change in the LdapDn class, then the existing
> users in Keycloak DB will still have the LDAP_ENTRY_DN attribute on them
> in the old format like "uid=john,dc=example,dc=com" . So until the
> particular user is re-synced from LDAP to Keycloak DB, it won't be
> successfully lookup when it is searched by authenticator for the
> attribute in new format like "UID=john, DC=example, DC=com" . As the
> change of the LDAP_ENTRY_DN to new format will be triggered by re-sync
> from LDAP.
>
> Marek
>
>
> >
> >
> > ________________________________________
> > From: Hynek Mlnarik [hmlnarik at redhat.com]
> > Sent: Tuesday, January 15, 2019 5:59 AM
> > To: Nalyvayko, Peter
> > Cc: Sebastian Laskawiec; John Dennis; keycloak-dev at lists.jboss.org
> > Subject: Re: [keycloak-dev] User TLS client certificate authentication -
> inconsistent DN string representation with LDAP
> >
> > We should adhere to the standard implementations as much as possible.
> However there likely was a reason for introducing LDAPDn class, possibly
> due to some supported LDAP server having different implementation than
> allowed by Java javax.naming.ldap.LdapName and similar. @Marek, could you
> please comment here?
> >
> > Sidenote: Currently the javax.naming.ldap.LdapName class respects RFC
> 2253 which was obsoleted by RFC 4514. I believe the differences are
> irrelevant in the domain of user ids but comments are welcome.
> >
> > Since a DN is stored as string user attribute value and searched for as
> such, we have to stick to canonical string representation. This can be
> obtained via javax.naming.ldap.LdapName.toString method which should be
> used both in the LDAPDn and the authenticator. It is in the latter, but not
> in the former.
> >
> > I am not very keen on uppercasing attribute type in the proposed patch
> though it might be the most pragmatic way to go. Is it supported by any DN
> RFC? In any case, any such a normalization would have to take place
> consistently in both places.
> >
> > Ideally the comparison would be able to recognize that the following
> inputs are just the same:
> > - DC=example,DC=com
> > - DC=example, DC=com
> > - dc=example,dc=com
> > - dc=ex\61mple,dc=com
> > - 0.9.2342.19200300.100.1.25=example,0.9.2342.19200300.100.1.25=com
> >
> >
> > On Thu, Jan 10, 2019 at 3:21 AM Nalyvayko, Peter <pnalyvayko at agi.com
> <mailto:pnalyvayko at agi.com>> wrote:
> > Hi Sebastian,
> >
> > Short of trying to extend the authenticator itself to handle such cases,
> one possible short term approach can be  to implement an attribute mapper
> responsible for importing and translating the LDAP's DN into representation
> that matches the canonical representation of the subject DN returned by
> X509Cert.getSubjectDN().getName() and configuring the x509 authenticator to
> compare the subjectDN against that attribute.
> >
> >
> > ________________________________________
> > From: Sebastian Laskawiec [slaskawi at redhat.com<mailto:
> slaskawi at redhat.com>]
> > Sent: Wednesday, January 9, 2019 10:11 AM
> > To: John Dennis
> > Cc: Nalyvayko, Peter; Peck, Michael A; sblanc at redhat.com<mailto:
> sblanc at redhat.com>; keycloak-dev at lists.jboss.org<mailto:
> keycloak-dev at lists.jboss.org>
> > Subject: Re: [keycloak-dev] User TLS client certificate authentication -
> inconsistent DN string representation with LDAP
> >
> > Hey guys,
> >
> > Answering a few email in a row below.
> >
> > Thanks,
> > Sebastian
> >
> > On Wed, Jan 9, 2019 at 12:19 AM John Dennis <jdennis at redhat.com<mailto:
> jdennis at redhat.com><mailto:jdennis at redhat.com<mailto:jdennis at redhat.com>>>
> wrote:
> > On 1/8/19 5:02 PM, Nalyvayko, Peter wrote:
> >> Hi,
> >>
> >>>> I believe that's a bug. The `X509ClientCertificateAuthenticator`
> should ignore those extra spaces. May I kindly ask you to create a ticket
> for us and assign it either to me or Sebastien?
> >> Sebastian/Michael,
> >>
> >> According to https://tools.ietf.org/html/rfc1779, BNF for
> distinguished name allows for optional space before and after the
> separator. Do you know of any reason why the DN returned by LDAP and the DN
> returned by  calling to X509Certificate.getSubjectDN().getName() should or
> expected be identical? It seems to me BNF allows for some discrepancies in
> representation thus comparing two strings verbatim may not be a good idea,
> no?
> > Let me try to reiterate the whole flow to make sure I understand
> everything correctly:
> > - X509ClientCertificateAuthenticator extracts certificates from an
> incoming HTTP request using one of the implementations of
> X509ClientCertificateLookup.
> > - Obtained certificate chain is of a type X509Certificate[].
> > - Then we extract a User identity based on his certificate
> (certs[0].getSubjectDN().getName()).
> > - Once we have a User identity in our hands, we can extract a UserModel,
> our representation of a User in Keycloak. This user might be imported from
> LDAP. Here's where those two pieces play together.
> > - If we find a user and he's valid, we end the flow.
> > So the root problem is that certificate obtained from the request
> doesn't match the one from LDAP, even though they are maintained in a
> single place (somehow, details omitted).
> >
> > So, yes, this situation may happen since in the essence, we do just a DN
> comparison by strings. The easiest workaround in my opinion is to normalize
> those DNs across Keycloak codebase. The simplest solution is to modify
> LDAPDn class as Michel suggested. I believe it should also work if we
> modify a user certificate attribute and put spaces there (", ").
> >
> > At first I though the fix should go X509ClientCertificateAuthenticator
> but obviously, I was wrong. It's just a mismatch problem.
> >
> > RFC 1779 (A String Representation of Distinguished Names) also mentions
> different separators like for example ";", "," or ", " (comma with or
> without a space). In order to support all this usecases, we'd probably need
> to implement a custom DN comparator and modify our database queries that
> extract users based on DN. At this point I'm not 100% convinced we need
> this. Maybe we should just say in the docs that if you synchronize users
> with LDAP, you should use ", " as a separator when specifying user
> certificates?
> >
> > @Michael, @Peter - WDYT about that? Would that solution solve your
> problem?
> >
> > @Hynek, @Marek - maybe you guys have some thoughts around this?
> >
> >
> > On previous projects I did a lot of work with DN handling, I believe the
> > relevant RFC is 4514 (unless it's been superseded). The short answer is
> > it's never correct to compare DN's via string comparison unless the DN
> > was normalized to a consistent representation. The reason is there are
> > multiple valid string representations of the same DN. Aside from issues
> > related to whitespace, encoding, etc. you need to remember that there is
> > such a thing as multi-valued RDN's (e.g. an RDN with an UNORDERED set of
> > AVA's), any ordering of the AVA's in the RDN yield a semantically
> > equivalent RDN.
> >
> > Most libraries that compare DN's do so by parsing the string
> > representation and building a data structure consisting of the
> > individual components which are then iterated over during comparison.
> > Once the DN has been parsed into it's constituent components there is
> > usually a routine to convert it back into a string representation. This
> > can be used to normalize the string representation thus permitting a
> > simple string compare to check for equality.
> >
> >> Kindly,
> >> Peter
> >>
> >>
> >> -----Original Message-----
> >> From: keycloak-dev-bounces at lists.jboss.org<mailto:
> keycloak-dev-bounces at lists.jboss.org><mailto:
> keycloak-dev-bounces at lists.jboss.org<mailto:
> keycloak-dev-bounces at lists.jboss.org>> <
> keycloak-dev-bounces at lists.jboss.org<mailto:
> keycloak-dev-bounces at lists.jboss.org><mailto:
> keycloak-dev-bounces at lists.jboss.org<mailto:
> keycloak-dev-bounces at lists.jboss.org>>> On Behalf Of Sebastian Laskawiec
> >> Sent: Monday, January 7, 2019 7:36 AM
> >> To: Peck, Michael A <mpeck at mitre.org<mailto:mpeck at mitre.org><mailto:
> mpeck at mitre.org<mailto:mpeck at mitre.org>>>; sblanc at redhat.com<mailto:
> sblanc at redhat.com><mailto:sblanc at redhat.com<mailto:sblanc at redhat.com>>
> >> Cc: keycloak-dev at lists.jboss.org<mailto:keycloak-dev at lists.jboss.org
> ><mailto:keycloak-dev at lists.jboss.org<mailto:keycloak-dev at lists.jboss.org
> >>
> >> Subject: Re: [keycloak-dev] User TLS client certificate authentication
> - inconsistent DN string representation with LDAP
> >>
> >> Hey Michael,
> >>
> >> Adding +Sebastien Blanc <sblanc at redhat.com<mailto:sblanc at redhat.com
> ><mailto:sblanc at redhat.com<mailto:sblanc at redhat.com>>> for visibility.
> >>
> >> I believe that's a bug. The `X509ClientCertificateAuthenticator` should
> ignore those extra spaces. May I kindly ask you to create a ticket for us
> and assign it either to me or Sebastien?
> >>
> >> Thanks,
> >> Sebastian
> >>
> >> On Sun, Dec 23, 2018 at 6:49 PM Peck, Michael A <mpeck at mitre.org
> <mailto:mpeck at mitre.org><mailto:mpeck at mitre.org<mailto:mpeck at mitre.org>>>
> wrote:
> >>
> >>> Hello,
> >>>
> >>> I?ve configured Keycloak to authenticate users using TLS client
> >>> certificate authentication.
> >>> I?ve also configured Keycloak to synchronize users with my LDAP server.
> >>>
> >>> I?d like to match the TLS client certificate?s Subject DN to the
> >>> Subject DNs synchronized from my LDAP server (which are stored by
> >>> Keycloak in each user?s LDAP_ENTRY_DN attribute).
> >>>
> >>> I?ve set that up, but am running into an issue that Keycloak appears
> >>> to have inconsistent string representations of DNs between those two
> >>> methods - so the Subject DNs from the TLS client certificate and the
> >>> LDAP server aren?t matching as I was expecting.
> >>>
> >>> The TLS client certificate DNs look like this:
> >>> CN=Peck Michael, OU=People, DC=test, DC=net
> >>>
> >>> While the LDAP_ENTRY_DN attribute is formatted like this:
> >>> cn=Peck Michael,ou=People,dc=test,dc=net
> >>>
> >>> It looks to me that the TLS client certificate DN string
> >>> representation is coming from the standard Java X500Principal class
> >>> used by calls to
> >>> X509Certificate.getSubjectDN().getName() in
> >>> keycloak/services/src/main/java/org/keycloak/authentication/authentica
> >>> tors/x509/X509ClientCertificateAuthenticator.java
> >>> and the LDAP_ENTRY_DN string representation is coming from the
> >>> toString method in
> >>>
> keycloak/federation/ldap/src/main/java/org/keycloak/storage/ldap/idm/model/LDAPDn.java.
> >>>
> >>> I modified the LDAPDn class?s toString method to follow the same
> >>> format as used in the TLS client certificate DNs, and authentication
> works for me now.
> >>> Would the Keycloak project consider accepting a pull request to change
> >>> the way LDAPDn formats DNs as strings?
> >>> (However I have not checked if this would impact other uses of the
> >>> LDAPDn class within Keycloak or cause problems with upgrading existing
> >>> deployments?)
> >>>
> >>> The suggested change follows:
> >>> diff --git
> >>> a/federation/ldap/src/main/java/org/keycloak/storage/ldap/idm/model/LD
> >>> APDn.java
> >>> b/federation/ldap/src/main/
> >>> index 39e7d97..2f8c805 100644
> >>> ---
> >>> a/federation/ldap/src/main/java/org/keycloak/storage/ldap/idm/model/LD
> >>> APDn.java
> >>> +++
> >>> b/federation/ldap/src/main/java/org/keycloak/storage/ldap/idm/model/LD
> >>> APDn.java @@ -87,9 +87,9 @@ public class LDAPDn {
> >>>                if (first) {
> >>>                    first = false;
> >>>                } else {
> >>> -                builder.append(",");
> >>> +                builder.append(", ");
> >>>                }
> >>> -
> >>> builder.append(rdn.attrName).append("=").append(rdn.attrValue);
> >>> +
> >>>
> builder.append(rdn.attrName.toUpperCase()).append("=").append(rdn.attrValue);
> >>>            }
> >>>
> >>>            return builder.toString();
> >>>
> >>>
> >>>
> >>> Thank you,
> >>> Michael Peck
> >>> The MITRE Corporation
> >>> _______________________________________________
> >>> 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
> ><mailto:keycloak-dev at lists.jboss.org<mailto:keycloak-dev at lists.jboss.org
> >>
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> >
> > --
> > John Dennis
> >
> > _______________________________________________
> > 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 hmlnarik at redhat.com  Tue Feb 12 12:01:15 2019
From: hmlnarik at redhat.com (Hynek Mlnarik)
Date: Tue, 12 Feb 2019 18:01:15 +0100
Subject: [keycloak-dev] Certificate subject DN is provider dependent
In-Reply-To: <CAJrcDBcfLnqDbApUPan--n9CW=dNLdRo_eJYfmCn5ihWtbBrDw@mail.gmail.com>
References: <76d2854ebcf943a39f30f2ba4891984c@BOSKGEXC01.boskg.local>
	<CAK-7U1hLTOg2pFX0WyXLE+PmtZLAOYwSovprKq_W8j5LusKreQ@mail.gmail.com>
	<CAJrcDBedQeK35-E5g1Ru9aMyUBQ5LjJ_6=iGWKCKFL4O1nXeNw@mail.gmail.com>
	<CAJrcDBearA9dmhWxLYO6zX07SxELQkr0Y_upFdOjXcd_4-BUzw@mail.gmail.com>
	<99d26631531742279d851c74850fe737@BOSKGEXC01.boskg.local>
	<CAJrcDBcfLnqDbApUPan--n9CW=dNLdRo_eJYfmCn5ihWtbBrDw@mail.gmail.com>
Message-ID: <CAMvXD=Fovok=OkNDH2iPMukSw2z-sdTA5Wi-VGOY4JADhnW0AA@mail.gmail.com>

Incidentally, this issue has been discussed few weeks ago on this mailing
list in the thread "User TLS client certificate authentication -
inconsistent DN string representation with LDAP" starting on Dec 23. Could
you please ensure the concerns from that thread are addressed in the PR?

On Tue, Feb 12, 2019 at 3:30 PM Pedro Igor Silva <psilva at redhat.com> wrote:

> Thanks. I'm still not sure about that new CANONICAL parameter. Added a
> comment to your PR.
>
> On Tue, Feb 12, 2019 at 11:57 AM L?sch, Sebastian <
> Sebastian.Loesch at governikus.de> wrote:
>
> > Hello developer,
> >
> >
> >
> > I opened a new issue for Keycloak:
> > https://issues.jboss.org/browse/KEYCLOAK-9554
> >
> > and provided a pull request:
> > https://github.com/keycloak/keycloak/pull/5878
> >
> >
> >
> > Best regards,
> >
> > Sebastian
> >
> >
> >
> >
> >
> > *Von:* Pedro Igor Silva <psilva at redhat.com>
> > *Gesendet:* Dienstag, 12. Februar 2019 13:24
> > *An:* Thomas Darimont <thomas.darimont at googlemail.com>
> > *Cc:* L?sch, Sebastian <Sebastian.Loesch at governikus.de>; keycloak-dev <
> > keycloak-dev at lists.jboss.org>
> > *Betreff:* Re: [keycloak-dev] Certificate subject DN is provider
> dependent
> >
> >
> >
> > Btw, we also support extracting email using a subject alt name extension.
> > Maybe we could safely use CANONICAL (which seems to be more aligned with
> > the specs) and tell people to use this extractor if they want to use
> email
> > address from certificates.
> >
> >
> >
> > On Tue, Feb 12, 2019 at 10:19 AM Pedro Igor Silva <psilva at redhat.com>
> > wrote:
> >
> > IIRC, email address should be included/parsed as a subject alternative
> > name extension. BouncyCastle seems doing it right.
> >
> >
> >
> > What is the JDK version being used?
> >
> >
> >
> > On Tue, Feb 12, 2019 at 9:57 AM Thomas Darimont <
> > thomas.darimont at googlemail.com> wrote:
> >
> > Hi Sebastian,
> >
> > how about Keycloak would introduce an option for this authenticator like:
> > "Use canonical principal extraction" on/off with default "off",
> > meaning the default behavior stays the same. "on" would then mean to use
> > the "canonical" option for extracting the subject as you suggested.
> >
> > Cheers,
> > Thomas
> >
> > Am Di., 12. Feb. 2019 um 12:33 Uhr schrieb L?sch, Sebastian <
> > Sebastian.Loesch at governikus.de>:
> >
> > > Hello Keycloak developers,
> > >
> > > I am currently working on configuring keycloak for X.509 certificate
> > login.
> > > We store the whole user certificate's subject DN as user attribute.
> > During
> > > the login we match the authentication certificate's subjectDN against
> the
> > > value stored in the user attributes.
> > > The subject DN is determined executing:
> > > cert.getSubjectDN().getName()
> > >
> > > Here we have a problem regarding the subject DN order. We realized that
> > > the subject DN order is security provider specific:
> > >
> > > ?         Using SUN security provider we get a subject DN like:
> > > "EMAILADDRESS=bjensen at example.com, CN=Ms. Barbara J Jensen III, O=
> > > example.com, ST=California, C=US"
> > >
> > > ?         Using BouncyCastle security provider we get a subject DN
> like:
> > > "C=US,ST=California,O=example.com,CN=Ms. Barbara J Jensen III,E=
> > > bjensen at example.com"
> > > This is obviously a problem.
> > > Does anybody else ran into the same problem?
> > >
> > > In my opinion it would be better to use:
> > >
> > > cert.getSubjectX500Principal().getName(X500Principal.CANONICAL)
> > > to determine the subject DN, as the result is provider independent.
> > > But this would be an backward incompatible change in Method
> > >
> > >
> >
> org.keycloak.authentication.authenticators.x509.AbstractX509ClientCertificateAuthenticator.UserIdentityExtractorBuilder.fromConfig()
> > >
> > > What is your opinion?
> > >
> > > Best regards
> > > Sebastian
> > >
> > > --
> > > Solution Engineering
> > > --
> > > Governikus GmbH & Co. KG
> > > Hochschulring 4
> > > 28359 Bremen, Germany
> > >
> > > Phone: +49 421 204 95 - 28
> > > Fax: +49 421 204 95 - 11
> > > E-Mail: Sebastian.Loesch at governikus.de<mailto:
> > > Sebastian.Loesch at governikus.de>
> > > www.governikus.de<http://www.governikus.de/>
> > > --
> > > Governikus GmbH & Co. KG
> > > Aufsichtsratsvorsitzender: Dr. Martin Hagen | Amtsgericht Bremen HRA
> > > 22041
> > > Gesch?ftsf?hrer: Dr. Stephan Klein
> > >
> > > Pers?nlich haftende Gesellschafterin: Governikus Bremen GmbH
> > > Gesch?ftsf?hrer: Dr. Stephan Klein | Amtsgericht Bremen HRB 18756
> > >
> > >
> > > ****************************************************
> > > Wir sind umgezogen! Bitte beachten Sie unsere neue Anschrift:
> > > Hochschulring 4, 28359 Bremen
> > >
> > > Veranstaltungsvorschau: Besuchen Sie uns...
> > > Dataport Hausmesse | 02.04.2019 | Hamburg - Schnelsen<
> > >
> >
> https://www.dataport.de/Seiten/Aktuelles/Veranstaltungen/190402-Hausmesse-Dataport.aspx
> > > >
> > > Digitaler Staat | 02. + 03.04.2019 | Berlin<
> > > https://www.digitaler-staat.org/>
> > > 7. Zukunftskongress Staat & Verwaltung | 27. - 29.05.2019 | Berlin<
> > > https://www.zukunftskongress.info/de>
> > > Kongress Baden-W?rttemberg | 04.07.2019 | Stuttgart<
> > https://www.bw-4-0.de/
> > > >
> > >
> > > [cid:image8a82cf.JPG at 26f9b88d.448c29be]<
> > > http://www.jahrestagung.governikus.de/>
> > >
> >
> >
> > ****************************************************
> > Wir sind umgezogen! Bitte beachten Sie unsere neue Anschrift:
> > Hochschulring 4, 28359 Bremen
> >
> > Veranstaltungsvorschau: Besuchen Sie uns?
> > Dataport Hausmesse | 02.04.2019 | Hamburg ? Schnelsen
> > <
> https://www.dataport.de/Seiten/Aktuelles/Veranstaltungen/190402-Hausmesse-Dataport.aspx
> >
> > Digitaler Staat | 02. + 03.04.2019 | Berlin
> > <https://www.digitaler-staat.org/>
> > 7. Zukunftskongress Staat & Verwaltung | 27. - 29.05.2019 | Berlin
> > <https://www.zukunftskongress.info/de>
> > Kongress Baden-W?rttemberg | 04.07.2019 | Stuttgart
> > <https://www.bw-4-0.de/>
> >
> > <http://www.jahrestagung.governikus.de/>
> >
> > _______________________________________________
> > > keycloak-dev mailing list
> > > keycloak-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> >
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From psilva at redhat.com  Tue Feb 12 13:05:06 2019
From: psilva at redhat.com (Pedro Igor Silva)
Date: Tue, 12 Feb 2019 16:05:06 -0200
Subject: [keycloak-dev] Certificate subject DN is provider dependent
In-Reply-To: <CAMvXD=Fovok=OkNDH2iPMukSw2z-sdTA5Wi-VGOY4JADhnW0AA@mail.gmail.com>
References: <76d2854ebcf943a39f30f2ba4891984c@BOSKGEXC01.boskg.local>
	<CAK-7U1hLTOg2pFX0WyXLE+PmtZLAOYwSovprKq_W8j5LusKreQ@mail.gmail.com>
	<CAJrcDBedQeK35-E5g1Ru9aMyUBQ5LjJ_6=iGWKCKFL4O1nXeNw@mail.gmail.com>
	<CAJrcDBearA9dmhWxLYO6zX07SxELQkr0Y_upFdOjXcd_4-BUzw@mail.gmail.com>
	<99d26631531742279d851c74850fe737@BOSKGEXC01.boskg.local>
	<CAJrcDBcfLnqDbApUPan--n9CW=dNLdRo_eJYfmCn5ihWtbBrDw@mail.gmail.com>
	<CAMvXD=Fovok=OkNDH2iPMukSw2z-sdTA5Wi-VGOY4JADhnW0AA@mail.gmail.com>
Message-ID: <CAJrcDBeeGShDpktMzJO7NfUV6L6i-rgb4QPxgLr5yfxyd-PjkQ@mail.gmail.com>

I think these threads are not talking about the same thing. The issue here
is the email address within the subject dn, which is deprecated in favor of
a specific subject alternative name extension in the certificate.

The PR LGTM too, I'm just not sure about the new "CANONICAL" configuration
option ...

On Tue, Feb 12, 2019 at 3:01 PM Hynek Mlnarik <hmlnarik at redhat.com> wrote:

> Incidentally, this issue has been discussed few weeks ago on this mailing
> list in the thread "User TLS client certificate authentication -
> inconsistent DN string representation with LDAP" starting on Dec 23. Could
> you please ensure the concerns from that thread are addressed in the PR?
>
> On Tue, Feb 12, 2019 at 3:30 PM Pedro Igor Silva <psilva at redhat.com>
> wrote:
>
>> Thanks. I'm still not sure about that new CANONICAL parameter. Added a
>> comment to your PR.
>>
>> On Tue, Feb 12, 2019 at 11:57 AM L?sch, Sebastian <
>> Sebastian.Loesch at governikus.de> wrote:
>>
>> > Hello developer,
>> >
>> >
>> >
>> > I opened a new issue for Keycloak:
>> > https://issues.jboss.org/browse/KEYCLOAK-9554
>> >
>> > and provided a pull request:
>> > https://github.com/keycloak/keycloak/pull/5878
>> >
>> >
>> >
>> > Best regards,
>> >
>> > Sebastian
>> >
>> >
>> >
>> >
>> >
>> > *Von:* Pedro Igor Silva <psilva at redhat.com>
>> > *Gesendet:* Dienstag, 12. Februar 2019 13:24
>> > *An:* Thomas Darimont <thomas.darimont at googlemail.com>
>> > *Cc:* L?sch, Sebastian <Sebastian.Loesch at governikus.de>; keycloak-dev <
>> > keycloak-dev at lists.jboss.org>
>> > *Betreff:* Re: [keycloak-dev] Certificate subject DN is provider
>> dependent
>> >
>> >
>> >
>> > Btw, we also support extracting email using a subject alt name
>> extension.
>> > Maybe we could safely use CANONICAL (which seems to be more aligned with
>> > the specs) and tell people to use this extractor if they want to use
>> email
>> > address from certificates.
>> >
>> >
>> >
>> > On Tue, Feb 12, 2019 at 10:19 AM Pedro Igor Silva <psilva at redhat.com>
>> > wrote:
>> >
>> > IIRC, email address should be included/parsed as a subject alternative
>> > name extension. BouncyCastle seems doing it right.
>> >
>> >
>> >
>> > What is the JDK version being used?
>> >
>> >
>> >
>> > On Tue, Feb 12, 2019 at 9:57 AM Thomas Darimont <
>> > thomas.darimont at googlemail.com> wrote:
>> >
>> > Hi Sebastian,
>> >
>> > how about Keycloak would introduce an option for this authenticator
>> like:
>> > "Use canonical principal extraction" on/off with default "off",
>> > meaning the default behavior stays the same. "on" would then mean to use
>> > the "canonical" option for extracting the subject as you suggested.
>> >
>> > Cheers,
>> > Thomas
>> >
>> > Am Di., 12. Feb. 2019 um 12:33 Uhr schrieb L?sch, Sebastian <
>> > Sebastian.Loesch at governikus.de>:
>> >
>> > > Hello Keycloak developers,
>> > >
>> > > I am currently working on configuring keycloak for X.509 certificate
>> > login.
>> > > We store the whole user certificate's subject DN as user attribute.
>> > During
>> > > the login we match the authentication certificate's subjectDN against
>> the
>> > > value stored in the user attributes.
>> > > The subject DN is determined executing:
>> > > cert.getSubjectDN().getName()
>> > >
>> > > Here we have a problem regarding the subject DN order. We realized
>> that
>> > > the subject DN order is security provider specific:
>> > >
>> > > ?         Using SUN security provider we get a subject DN like:
>> > > "EMAILADDRESS=bjensen at example.com, CN=Ms. Barbara J Jensen III, O=
>> > > example.com, ST=California, C=US"
>> > >
>> > > ?         Using BouncyCastle security provider we get a subject DN
>> like:
>> > > "C=US,ST=California,O=example.com,CN=Ms. Barbara J Jensen III,E=
>> > > bjensen at example.com"
>> > > This is obviously a problem.
>> > > Does anybody else ran into the same problem?
>> > >
>> > > In my opinion it would be better to use:
>> > >
>> > > cert.getSubjectX500Principal().getName(X500Principal.CANONICAL)
>> > > to determine the subject DN, as the result is provider independent.
>> > > But this would be an backward incompatible change in Method
>> > >
>> > >
>> >
>> org.keycloak.authentication.authenticators.x509.AbstractX509ClientCertificateAuthenticator.UserIdentityExtractorBuilder.fromConfig()
>> > >
>> > > What is your opinion?
>> > >
>> > > Best regards
>> > > Sebastian
>> > >
>> > > --
>> > > Solution Engineering
>> > > --
>> > > Governikus GmbH & Co. KG
>> > > Hochschulring 4
>> > > 28359 Bremen, Germany
>> > >
>> > > Phone: +49 421 204 95 - 28
>> > > Fax: +49 421 204 95 - 11
>> > > E-Mail: Sebastian.Loesch at governikus.de<mailto:
>> > > Sebastian.Loesch at governikus.de>
>> > > www.governikus.de<http://www.governikus.de/>
>> > > --
>> > > Governikus GmbH & Co. KG
>> > > Aufsichtsratsvorsitzender: Dr. Martin Hagen | Amtsgericht Bremen HRA
>> > > 22041
>> > > Gesch?ftsf?hrer: Dr. Stephan Klein
>> > >
>> > > Pers?nlich haftende Gesellschafterin: Governikus Bremen GmbH
>> > > Gesch?ftsf?hrer: Dr. Stephan Klein | Amtsgericht Bremen HRB 18756
>> > >
>> > >
>> > > ****************************************************
>> > > Wir sind umgezogen! Bitte beachten Sie unsere neue Anschrift:
>> > > Hochschulring 4, 28359 Bremen
>> > >
>> > > Veranstaltungsvorschau: Besuchen Sie uns...
>> > > Dataport Hausmesse | 02.04.2019 | Hamburg - Schnelsen<
>> > >
>> >
>> https://www.dataport.de/Seiten/Aktuelles/Veranstaltungen/190402-Hausmesse-Dataport.aspx
>> > > >
>> > > Digitaler Staat | 02. + 03.04.2019 | Berlin<
>> > > https://www.digitaler-staat.org/>
>> > > 7. Zukunftskongress Staat & Verwaltung | 27. - 29.05.2019 | Berlin<
>> > > https://www.zukunftskongress.info/de>
>> > > Kongress Baden-W?rttemberg | 04.07.2019 | Stuttgart<
>> > https://www.bw-4-0.de/
>> > > >
>> > >
>> > > [cid:image8a82cf.JPG at 26f9b88d.448c29be]<
>> > > http://www.jahrestagung.governikus.de/>
>> > >
>> >
>> >
>> > ****************************************************
>> > Wir sind umgezogen! Bitte beachten Sie unsere neue Anschrift:
>> > Hochschulring 4, 28359 Bremen
>> >
>> > Veranstaltungsvorschau: Besuchen Sie uns?
>> > Dataport Hausmesse | 02.04.2019 | Hamburg ? Schnelsen
>> > <
>> https://www.dataport.de/Seiten/Aktuelles/Veranstaltungen/190402-Hausmesse-Dataport.aspx
>> >
>> > Digitaler Staat | 02. + 03.04.2019 | Berlin
>> > <https://www.digitaler-staat.org/>
>> > 7. Zukunftskongress Staat & Verwaltung | 27. - 29.05.2019 | Berlin
>> > <https://www.zukunftskongress.info/de>
>> > Kongress Baden-W?rttemberg | 04.07.2019 | Stuttgart
>> > <https://www.bw-4-0.de/>
>> >
>> > <http://www.jahrestagung.governikus.de/>
>> >
>> > _______________________________________________
>> > > keycloak-dev mailing list
>> > > keycloak-dev at lists.jboss.org
>> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> > _______________________________________________
>> > keycloak-dev mailing list
>> > keycloak-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> >
>> >
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>

From jdennis at redhat.com  Tue Feb 12 14:27:36 2019
From: jdennis at redhat.com (John Dennis)
Date: Tue, 12 Feb 2019 14:27:36 -0500
Subject: [keycloak-dev] Certificate subject DN is provider dependent
In-Reply-To: <CAJrcDBeeGShDpktMzJO7NfUV6L6i-rgb4QPxgLr5yfxyd-PjkQ@mail.gmail.com>
References: <76d2854ebcf943a39f30f2ba4891984c@BOSKGEXC01.boskg.local>
	<CAK-7U1hLTOg2pFX0WyXLE+PmtZLAOYwSovprKq_W8j5LusKreQ@mail.gmail.com>
	<CAJrcDBedQeK35-E5g1Ru9aMyUBQ5LjJ_6=iGWKCKFL4O1nXeNw@mail.gmail.com>
	<CAJrcDBearA9dmhWxLYO6zX07SxELQkr0Y_upFdOjXcd_4-BUzw@mail.gmail.com>
	<99d26631531742279d851c74850fe737@BOSKGEXC01.boskg.local>
	<CAJrcDBcfLnqDbApUPan--n9CW=dNLdRo_eJYfmCn5ihWtbBrDw@mail.gmail.com>
	<CAMvXD=Fovok=OkNDH2iPMukSw2z-sdTA5Wi-VGOY4JADhnW0AA@mail.gmail.com>
	<CAJrcDBeeGShDpktMzJO7NfUV6L6i-rgb4QPxgLr5yfxyd-PjkQ@mail.gmail.com>
Message-ID: <3e3b522e-d435-a197-8792-72caf35254ca@redhat.com>

On 2/12/19 1:05 PM, Pedro Igor Silva wrote:
> I think these threads are not talking about the same thing. The issue here
> is the email address within the subject dn, which is deprecated in favor of
> a specific subject alternative name extension in the certificate.

Actually I think the two issues are pretty much the same and presence of 
an email address is a red herring [1]. In both cases one is trying to 
compare a DN for equality.

What is a bit troubling is the order of the RDN's as returned by the two 
providers. Notice they are reversed. This is a common problem with 
different X509 implementations. The RFC's are clear, the order of RDN's 
in a string representation are supposed to be added by starting with the 
LAST RDN in the binary format (ASN.1) and proceeds towards the first. 
However this is often the opposite of how humans want to read these 
strings and some implementations reverse the order (a classic example is 
OpenSSL vs. NSS).

The other thing to note is one provider is using an alias for the email 
address and the other isn't.

What is not clear to me from the email is how the string representations 
from the two providers was obtained, clearly they are using different 
algorithms. BUT the certificate subject is in binary form in the 
certificate and the same X509 implementation SHOULD produce identical 
string representations from the same binary data. Therefore be careful 
and draw a sharp distinction between asking one implementation to 
convert binary data to string format and the actual binary data.

FWIW the Java implementations refer to RFC 2253 but that has been 
superseded by RFC 4514.

[1] Yes, email addresses are better specified in a SAN but for legacy 
reasons it's perfectly fine to include them in the subject, things 
should still work.
-- 
John Dennis

From psilva at redhat.com  Tue Feb 12 15:04:41 2019
From: psilva at redhat.com (Pedro Igor Silva)
Date: Tue, 12 Feb 2019 18:04:41 -0200
Subject: [keycloak-dev] Certificate subject DN is provider dependent
In-Reply-To: <3e3b522e-d435-a197-8792-72caf35254ca@redhat.com>
References: <76d2854ebcf943a39f30f2ba4891984c@BOSKGEXC01.boskg.local>
	<CAK-7U1hLTOg2pFX0WyXLE+PmtZLAOYwSovprKq_W8j5LusKreQ@mail.gmail.com>
	<CAJrcDBedQeK35-E5g1Ru9aMyUBQ5LjJ_6=iGWKCKFL4O1nXeNw@mail.gmail.com>
	<CAJrcDBearA9dmhWxLYO6zX07SxELQkr0Y_upFdOjXcd_4-BUzw@mail.gmail.com>
	<99d26631531742279d851c74850fe737@BOSKGEXC01.boskg.local>
	<CAJrcDBcfLnqDbApUPan--n9CW=dNLdRo_eJYfmCn5ihWtbBrDw@mail.gmail.com>
	<CAMvXD=Fovok=OkNDH2iPMukSw2z-sdTA5Wi-VGOY4JADhnW0AA@mail.gmail.com>
	<CAJrcDBeeGShDpktMzJO7NfUV6L6i-rgb4QPxgLr5yfxyd-PjkQ@mail.gmail.com>
	<3e3b522e-d435-a197-8792-72caf35254ca@redhat.com>
Message-ID: <CAJrcDBfTRmtOaw19vfZ2PMM8HXbHeqv2yFxBAkKmh8apYbYXCQ@mail.gmail.com>

Pretty much, but not the same. The fix for this still does not seem to
solve the problem being discussed in the other thread.

The change provided by Sebastian does solve this problem while still
backwards compatible with certificates with subject dn containing an
emailAddress. My point though is whether or not we should be backward
compatible given that emailAddress is a deprecated RDN in the subject DN.

As you mentioned, RFC-2253 was superseded by RFC-4514 and there you can't
have emailAddress in subject DN but prefer a SAN. So, my question is ... Is
OK in 2019 to assume that certificates are using RFC-4514 ? So we could
just use the canonical format in our side and avoid any additional
configuration.

You are right, java defaults to RFC-2253, I'm not sure if the "canonical"
format is related with the support for 4514 (at least removing emailAddress
from subject DN).

On Tue, Feb 12, 2019 at 5:27 PM John Dennis <jdennis at redhat.com> wrote:

> On 2/12/19 1:05 PM, Pedro Igor Silva wrote:
> > I think these threads are not talking about the same thing. The issue
> here
> > is the email address within the subject dn, which is deprecated in favor
> of
> > a specific subject alternative name extension in the certificate.
>
> Actually I think the two issues are pretty much the same and presence of
> an email address is a red herring [1]. In both cases one is trying to
> compare a DN for equality.


> What is a bit troubling is the order of the RDN's as returned by the two
> providers. Notice they are reversed. This is a common problem with
> different X509 implementations. The RFC's are clear, the order of RDN's
> in a string representation are supposed to be added by starting with the
> LAST RDN in the binary format (ASN.1) and proceeds towards the first.
> However this is often the opposite of how humans want to read these
> strings and some implementations reverse the order (a classic example is
> OpenSSL vs. NSS).
>
> The other thing to note is one provider is using an alias for the email
> address and the other isn't.
>
> What is not clear to me from the email is how the string representations
> from the two providers was obtained, clearly they are using different
> algorithms. BUT the certificate subject is in binary form in the
> certificate and the same X509 implementation SHOULD produce identical
> string representations from the same binary data. Therefore be careful
> and draw a sharp distinction between asking one implementation to
> convert binary data to string format and the actual binary data.
>
> FWIW the Java implementations refer to RFC 2253 but that has been
> superseded by RFC 4514.
>
> [1] Yes, email addresses are better specified in a SAN but for legacy
> reasons it's perfectly fine to include them in the subject, things
> should still work.
> --
> John Dennis
>

From jdennis at redhat.com  Tue Feb 12 15:43:15 2019
From: jdennis at redhat.com (John Dennis)
Date: Tue, 12 Feb 2019 15:43:15 -0500
Subject: [keycloak-dev] Certificate subject DN is provider dependent
In-Reply-To: <CAJrcDBfTRmtOaw19vfZ2PMM8HXbHeqv2yFxBAkKmh8apYbYXCQ@mail.gmail.com>
References: <76d2854ebcf943a39f30f2ba4891984c@BOSKGEXC01.boskg.local>
	<CAK-7U1hLTOg2pFX0WyXLE+PmtZLAOYwSovprKq_W8j5LusKreQ@mail.gmail.com>
	<CAJrcDBedQeK35-E5g1Ru9aMyUBQ5LjJ_6=iGWKCKFL4O1nXeNw@mail.gmail.com>
	<CAJrcDBearA9dmhWxLYO6zX07SxELQkr0Y_upFdOjXcd_4-BUzw@mail.gmail.com>
	<99d26631531742279d851c74850fe737@BOSKGEXC01.boskg.local>
	<CAJrcDBcfLnqDbApUPan--n9CW=dNLdRo_eJYfmCn5ihWtbBrDw@mail.gmail.com>
	<CAMvXD=Fovok=OkNDH2iPMukSw2z-sdTA5Wi-VGOY4JADhnW0AA@mail.gmail.com>
	<CAJrcDBeeGShDpktMzJO7NfUV6L6i-rgb4QPxgLr5yfxyd-PjkQ@mail.gmail.com>
	<3e3b522e-d435-a197-8792-72caf35254ca@redhat.com>
	<CAJrcDBfTRmtOaw19vfZ2PMM8HXbHeqv2yFxBAkKmh8apYbYXCQ@mail.gmail.com>
Message-ID: <29ac8ce8-cbd8-6021-11b7-5104d369d578@redhat.com>

On 2/12/19 3:04 PM, Pedro Igor Silva wrote:
> Pretty much, but not the same. The fix for this still does not seem?to 
> solve the problem being discussed in the other thread.
> 
> The change provided by Sebastian does solve this problem while still 
> backwards compatible with certificates with subject dn containing an 
> emailAddress. My point though is whether or not we should be backward 
> compatible given that emailAddress?is a deprecated RDN in the subject DN.
> 
> As you mentioned, RFC-2253 was superseded by RFC-4514 and there you 
> can't have?emailAddress in subject?DN but prefer a SAN. So, my question 
> is ... Is OK in 2019 to assume that certificates are using?RFC-4514 ??So 
> we could just use the canonical format in our side and avoid any 
> additional configuration.
> 
> You are right, java defaults to RFC-2253, I'm not sure if the 
> "canonical" format is related with the support for 4514 (at least 
> removing emailAddress from subject DN).

No, RFC's 2253 and 4514 *only* describe the process by which a binary DN 
in ASN.1 format is converted to a string representation. These RFC's do 
not define the permissible members of a DN in an X509 certificate. In 
fact the subject member of an X509 certificate was originally *under* 
specified leading to all sorts of compatibility problems. The usual 
solution adopted only by convention and not by specification is to 
extract the CommonName (i.e. CN) RDN value and use that as the subject 
name (usually in the scope of the issuer). But as you can imagine that 
also has it's own problems (e.g. name collisions that would otherwise be 
uniquely determined by the other RDN values and/or scoping to the issuer).

I go back to my original assertion when I first replied weeks ago. If 
you want to compare DN's for equality you're going to have to do so by 
breaking the DN down into it's component parts and comparing them 
individually or reformat the string representation of the DN into a 
canonical form and perform a string comparison (note that forming a 
canonical string representation also requires breaking the components 
apart so there is little actual difference between doing an equality 
test between DN objects and an equality comparison on the resulting 
canonical strings, the later just adds the cycles needed to format the 
individual components).


-- 
John Dennis

From psilva at redhat.com  Tue Feb 12 16:26:45 2019
From: psilva at redhat.com (Pedro Igor Silva)
Date: Tue, 12 Feb 2019 19:26:45 -0200
Subject: [keycloak-dev] Certificate subject DN is provider dependent
In-Reply-To: <29ac8ce8-cbd8-6021-11b7-5104d369d578@redhat.com>
References: <76d2854ebcf943a39f30f2ba4891984c@BOSKGEXC01.boskg.local>
	<CAK-7U1hLTOg2pFX0WyXLE+PmtZLAOYwSovprKq_W8j5LusKreQ@mail.gmail.com>
	<CAJrcDBedQeK35-E5g1Ru9aMyUBQ5LjJ_6=iGWKCKFL4O1nXeNw@mail.gmail.com>
	<CAJrcDBearA9dmhWxLYO6zX07SxELQkr0Y_upFdOjXcd_4-BUzw@mail.gmail.com>
	<99d26631531742279d851c74850fe737@BOSKGEXC01.boskg.local>
	<CAJrcDBcfLnqDbApUPan--n9CW=dNLdRo_eJYfmCn5ihWtbBrDw@mail.gmail.com>
	<CAMvXD=Fovok=OkNDH2iPMukSw2z-sdTA5Wi-VGOY4JADhnW0AA@mail.gmail.com>
	<CAJrcDBeeGShDpktMzJO7NfUV6L6i-rgb4QPxgLr5yfxyd-PjkQ@mail.gmail.com>
	<3e3b522e-d435-a197-8792-72caf35254ca@redhat.com>
	<CAJrcDBfTRmtOaw19vfZ2PMM8HXbHeqv2yFxBAkKmh8apYbYXCQ@mail.gmail.com>
	<29ac8ce8-cbd8-6021-11b7-5104d369d578@redhat.com>
Message-ID: <CAJrcDBf0MVuqdR6W6vF8EUf2jWN=TYK5+kzWqS+egVF9VOsgSA@mail.gmail.com>

On Tue, Feb 12, 2019 at 6:43 PM John Dennis <jdennis at redhat.com> wrote:

> On 2/12/19 3:04 PM, Pedro Igor Silva wrote:
> > Pretty much, but not the same. The fix for this still does not seem to
> > solve the problem being discussed in the other thread.
> >
> > The change provided by Sebastian does solve this problem while still
> > backwards compatible with certificates with subject dn containing an
> > emailAddress. My point though is whether or not we should be backward
> > compatible given that emailAddress is a deprecated RDN in the subject DN.
> >
> > As you mentioned, RFC-2253 was superseded by RFC-4514 and there you
> > can't have emailAddress in subject DN but prefer a SAN. So, my question
> > is ... Is OK in 2019 to assume that certificates are using RFC-4514 ? So
> > we could just use the canonical format in our side and avoid any
> > additional configuration.
> >
> > You are right, java defaults to RFC-2253, I'm not sure if the
> > "canonical" format is related with the support for 4514 (at least
> > removing emailAddress from subject DN).
>
> No, RFC's 2253 and 4514 *only* describe the process by which a binary DN
> in ASN.1 format is converted to a string representation. These RFC's do
> not define the permissible members of a DN in an X509 certificate. In
> fact the subject member of an X509 certificate was originally *under*
> specified leading to all sorts of compatibility problems. The usual
> solution adopted only by convention and not by specification is to
> extract the CommonName (i.e. CN) RDN value and use that as the subject
> name (usually in the scope of the issuer). But as you can imagine that
> also has it's own problems (e.g. name collisions that would otherwise be
> uniquely determined by the other RDN values and/or scoping to the issuer).
>

Sure, but note that RFC-4514 relies on 4519 (which actually defines the
supported attributed types).


>
> I go back to my original assertion when I first replied weeks ago. If
> you want to compare DN's for equality you're going to have to do so by
> breaking the DN down into it's component parts and comparing them
> individually or reformat the string representation of the DN into a
> canonical form and perform a string comparison (note that forming a
> canonical string representation also requires breaking the components
> apart so there is little actual difference between doing an equality
> test between DN objects and an equality comparison on the resulting
> canonical strings, the later just adds the cycles needed to format the
> individual components).
>

Yeah, I think so. I hope this can solve the "comparison issue". Need to get
more familiar with what was discussed in the other thread.

So, based on your experience in Openstack. Is there people still using
certificates with deprecated emailAddress as part of the subject DN ? If
your answer is no, we probably want to avoid an additional configuration to
enable/disable java canonical format. Otherwise, if your answer is
yes/don't know, maybe we should keep the configuration option implemented
in the PR.

The main reason for pushing this question is that from a security
perspective, using a deprecated attribute type in subject dn is not good.
Privacy concerns may apply here too where you may not want people to put
the email (sensitive) in something that is supposed to be public.

Thanks.


>
>
> --
> John Dennis
>

From psilva at redhat.com  Tue Feb 12 16:30:18 2019
From: psilva at redhat.com (Pedro Igor Silva)
Date: Tue, 12 Feb 2019 19:30:18 -0200
Subject: [keycloak-dev] Certificate subject DN is provider dependent
In-Reply-To: <CAJrcDBf0MVuqdR6W6vF8EUf2jWN=TYK5+kzWqS+egVF9VOsgSA@mail.gmail.com>
References: <76d2854ebcf943a39f30f2ba4891984c@BOSKGEXC01.boskg.local>
	<CAK-7U1hLTOg2pFX0WyXLE+PmtZLAOYwSovprKq_W8j5LusKreQ@mail.gmail.com>
	<CAJrcDBedQeK35-E5g1Ru9aMyUBQ5LjJ_6=iGWKCKFL4O1nXeNw@mail.gmail.com>
	<CAJrcDBearA9dmhWxLYO6zX07SxELQkr0Y_upFdOjXcd_4-BUzw@mail.gmail.com>
	<99d26631531742279d851c74850fe737@BOSKGEXC01.boskg.local>
	<CAJrcDBcfLnqDbApUPan--n9CW=dNLdRo_eJYfmCn5ihWtbBrDw@mail.gmail.com>
	<CAMvXD=Fovok=OkNDH2iPMukSw2z-sdTA5Wi-VGOY4JADhnW0AA@mail.gmail.com>
	<CAJrcDBeeGShDpktMzJO7NfUV6L6i-rgb4QPxgLr5yfxyd-PjkQ@mail.gmail.com>
	<3e3b522e-d435-a197-8792-72caf35254ca@redhat.com>
	<CAJrcDBfTRmtOaw19vfZ2PMM8HXbHeqv2yFxBAkKmh8apYbYXCQ@mail.gmail.com>
	<29ac8ce8-cbd8-6021-11b7-5104d369d578@redhat.com>
	<CAJrcDBf0MVuqdR6W6vF8EUf2jWN=TYK5+kzWqS+egVF9VOsgSA@mail.gmail.com>
Message-ID: <CAJrcDBdaR0xVe3r_nO1TgXjpQOu-K66J06gyEjoBV4To=a2a7g@mail.gmail.com>

On Tue, Feb 12, 2019 at 7:26 PM Pedro Igor Silva <psilva at redhat.com> wrote:

>
>
> On Tue, Feb 12, 2019 at 6:43 PM John Dennis <jdennis at redhat.com> wrote:
>
>> On 2/12/19 3:04 PM, Pedro Igor Silva wrote:
>> > Pretty much, but not the same. The fix for this still does not seem to
>> > solve the problem being discussed in the other thread.
>> >
>> > The change provided by Sebastian does solve this problem while still
>> > backwards compatible with certificates with subject dn containing an
>> > emailAddress. My point though is whether or not we should be backward
>> > compatible given that emailAddress is a deprecated RDN in the subject
>> DN.
>> >
>> > As you mentioned, RFC-2253 was superseded by RFC-4514 and there you
>> > can't have emailAddress in subject DN but prefer a SAN. So, my question
>> > is ... Is OK in 2019 to assume that certificates are using RFC-4514
>> ? So
>> > we could just use the canonical format in our side and avoid any
>> > additional configuration.
>> >
>> > You are right, java defaults to RFC-2253, I'm not sure if the
>> > "canonical" format is related with the support for 4514 (at least
>> > removing emailAddress from subject DN).
>>
>> No, RFC's 2253 and 4514 *only* describe the process by which a binary DN
>> in ASN.1 format is converted to a string representation. These RFC's do
>> not define the permissible members of a DN in an X509 certificate. In
>> fact the subject member of an X509 certificate was originally *under*
>> specified leading to all sorts of compatibility problems. The usual
>> solution adopted only by convention and not by specification is to
>> extract the CommonName (i.e. CN) RDN value and use that as the subject
>> name (usually in the scope of the issuer). But as you can imagine that
>> also has it's own problems (e.g. name collisions that would otherwise be
>> uniquely determined by the other RDN values and/or scoping to the issuer).
>>
>
> Sure, but note that RFC-4514 relies on 4519 (which actually defines the
> supported attributed types).
>
>
>>
>> I go back to my original assertion when I first replied weeks ago. If
>> you want to compare DN's for equality you're going to have to do so by
>> breaking the DN down into it's component parts and comparing them
>> individually or reformat the string representation of the DN into a
>> canonical form and perform a string comparison (note that forming a
>> canonical string representation also requires breaking the components
>> apart so there is little actual difference between doing an equality
>> test between DN objects and an equality comparison on the resulting
>> canonical strings, the later just adds the cycles needed to format the
>> individual components).
>>
>
> Yeah, I think so. I hope this can solve the "comparison issue". Need to
> get more familiar with what was discussed in the other thread.
>
> So, based on your experience in Openstack. Is there people still using
> certificates with deprecated emailAddress as part of the subject DN ? If
> your answer is no, we probably want to avoid an additional configuration to
> enable/disable java canonical format. Otherwise, if your answer is
> yes/don't know, maybe we should keep the configuration option implemented
> in the PR.
>
> The main reason for pushing this question is that from a security
> perspective, using a deprecated attribute type in subject dn is not good.
> Privacy concerns may apply here too where you may not want people to put
> the email (sensitive) in something that is supposed to be public.
>

I mean, encourage people to use that way ....


>
> Thanks.
>
>
>>
>>
>> --
>> John Dennis
>>
>

From jdennis at redhat.com  Tue Feb 12 17:17:51 2019
From: jdennis at redhat.com (John Dennis)
Date: Tue, 12 Feb 2019 17:17:51 -0500
Subject: [keycloak-dev] Certificate subject DN is provider dependent
In-Reply-To: <CAJrcDBf0MVuqdR6W6vF8EUf2jWN=TYK5+kzWqS+egVF9VOsgSA@mail.gmail.com>
References: <76d2854ebcf943a39f30f2ba4891984c@BOSKGEXC01.boskg.local>
	<CAK-7U1hLTOg2pFX0WyXLE+PmtZLAOYwSovprKq_W8j5LusKreQ@mail.gmail.com>
	<CAJrcDBedQeK35-E5g1Ru9aMyUBQ5LjJ_6=iGWKCKFL4O1nXeNw@mail.gmail.com>
	<CAJrcDBearA9dmhWxLYO6zX07SxELQkr0Y_upFdOjXcd_4-BUzw@mail.gmail.com>
	<99d26631531742279d851c74850fe737@BOSKGEXC01.boskg.local>
	<CAJrcDBcfLnqDbApUPan--n9CW=dNLdRo_eJYfmCn5ihWtbBrDw@mail.gmail.com>
	<CAMvXD=Fovok=OkNDH2iPMukSw2z-sdTA5Wi-VGOY4JADhnW0AA@mail.gmail.com>
	<CAJrcDBeeGShDpktMzJO7NfUV6L6i-rgb4QPxgLr5yfxyd-PjkQ@mail.gmail.com>
	<3e3b522e-d435-a197-8792-72caf35254ca@redhat.com>
	<CAJrcDBfTRmtOaw19vfZ2PMM8HXbHeqv2yFxBAkKmh8apYbYXCQ@mail.gmail.com>
	<29ac8ce8-cbd8-6021-11b7-5104d369d578@redhat.com>
	<CAJrcDBf0MVuqdR6W6vF8EUf2jWN=TYK5+kzWqS+egVF9VOsgSA@mail.gmail.com>
Message-ID: <76df2c03-1db9-19df-7220-99476748b1d8@redhat.com>

On 2/12/19 4:26 PM, Pedro Igor Silva wrote:
> Sure, but note that RFC-4514 relies on 4519 (which actually defines the 
> supported attributed types).

I don't think RFC 4519 is what you're looking for, you want to be 
looking at the X509 Certificate RFC's.

Ugh, the RFC's for this stuff is a tangled mess of cross references to 
other RFC's. It's ugly and hard to decipher which is probably why these 
issues seem to keep cropping up.

> The main reason for pushing this question is that from a security 
> perspective, using a deprecated attribute type in subject dn is not 
> good. Privacy concerns may apply here too where you may not want people 
> to put the email (sensitive) in something that is supposed to be public.

I'm not sure that's the question. You don't have control over the certs 
that are presented to you. Rather your job is to ascertain if you can 
unequivocally map the cert subject to a principal in your domain. You 
probably can't put a stake in the ground and demand the subject contain 
certain RDN's (with the exception of the CN). And FWIW just to make 
things even more confusing a common convention for client certs is to 
put the users email address as the subject's CN.

I have a suggestion, I'm not the ultimate authority on this stuff. We 
have a developer on the Certificate Server team who I believe has an 
even more in depth understanding and is probably more current on this 
topic that I am (I did this work several years ago). He is Fraser 
Tweedale <ftweedal at redhat.com>, perhaps you might want to open a 
discussion with him. FWIW the Certificate Server is also written in Java 
and he might be able to share Java code snippets with you on the best 
way to perform these comparisons.


-- 
John Dennis

From psilva at redhat.com  Tue Feb 12 18:02:46 2019
From: psilva at redhat.com (Pedro Igor Silva)
Date: Tue, 12 Feb 2019 21:02:46 -0200
Subject: [keycloak-dev] Certificate subject DN is provider dependent
In-Reply-To: <76df2c03-1db9-19df-7220-99476748b1d8@redhat.com>
References: <76d2854ebcf943a39f30f2ba4891984c@BOSKGEXC01.boskg.local>
	<CAK-7U1hLTOg2pFX0WyXLE+PmtZLAOYwSovprKq_W8j5LusKreQ@mail.gmail.com>
	<CAJrcDBedQeK35-E5g1Ru9aMyUBQ5LjJ_6=iGWKCKFL4O1nXeNw@mail.gmail.com>
	<CAJrcDBearA9dmhWxLYO6zX07SxELQkr0Y_upFdOjXcd_4-BUzw@mail.gmail.com>
	<99d26631531742279d851c74850fe737@BOSKGEXC01.boskg.local>
	<CAJrcDBcfLnqDbApUPan--n9CW=dNLdRo_eJYfmCn5ihWtbBrDw@mail.gmail.com>
	<CAMvXD=Fovok=OkNDH2iPMukSw2z-sdTA5Wi-VGOY4JADhnW0AA@mail.gmail.com>
	<CAJrcDBeeGShDpktMzJO7NfUV6L6i-rgb4QPxgLr5yfxyd-PjkQ@mail.gmail.com>
	<3e3b522e-d435-a197-8792-72caf35254ca@redhat.com>
	<CAJrcDBfTRmtOaw19vfZ2PMM8HXbHeqv2yFxBAkKmh8apYbYXCQ@mail.gmail.com>
	<29ac8ce8-cbd8-6021-11b7-5104d369d578@redhat.com>
	<CAJrcDBf0MVuqdR6W6vF8EUf2jWN=TYK5+kzWqS+egVF9VOsgSA@mail.gmail.com>
	<76df2c03-1db9-19df-7220-99476748b1d8@redhat.com>
Message-ID: <CAJrcDBeKbZhFzQpJfubr-swP3h8q4_EpT-JuAgXZ=PGSYF0ozA@mail.gmail.com>

On Tue, Feb 12, 2019 at 8:17 PM John Dennis <jdennis at redhat.com> wrote:

> On 2/12/19 4:26 PM, Pedro Igor Silva wrote:
> > Sure, but note that RFC-4514 relies on 4519 (which actually defines the
> > supported attributed types).
>
> I don't think RFC 4519 is what you're looking for, you want to be
> looking at the X509 Certificate RFC's.
>
> Ugh, the RFC's for this stuff is a tangled mess of cross references to
> other RFC's. It's ugly and hard to decipher which is probably why these
> issues seem to keep cropping up.
>

Yes, they are ...


>
> > The main reason for pushing this question is that from a security
> > perspective, using a deprecated attribute type in subject dn is not
> > good. Privacy concerns may apply here too where you may not want people
> > to put the email (sensitive) in something that is supposed to be public.
>
> I'm not sure that's the question. You don't have control over the certs
> that are presented to you. Rather your job is to ascertain if you can
> unequivocally map the cert subject to a principal in your domain. You
> probably can't put a stake in the ground and demand the subject contain
> certain RDN's (with the exception of the CN). And FWIW just to make
> things even more confusing a common convention for client certs is to
> put the users email address as the subject's CN.
>
> I have a suggestion, I'm not the ultimate authority on this stuff. We
> have a developer on the Certificate Server team who I believe has an
> even more in depth understanding and is probably more current on this
> topic that I am (I did this work several years ago). He is Fraser
> Tweedale <ftweedal at redhat.com>, perhaps you might want to open a
> discussion with him. FWIW the Certificate Server is also written in Java
> and he might be able to share Java code snippets with you on the best
> way to perform these comparisons.
>

Yeah, we can not control how people are issuing certificates. I was trying
to find someone to say "Yeah, emailAddress is really a bad practice in
subject dn. People should use SAN instead".

I think your contact may help here with both issues, for sure. Although I'm
convinced that at least the changes made in that PR are fine instead of
possibly breaking use cases by forcing canonicalization.


>
>
> --
> John Dennis
>

From Sebastian.Loesch at governikus.de  Wed Feb 13 00:37:41 2019
From: Sebastian.Loesch at governikus.de (=?iso-8859-1?Q?L=F6sch=2C_Sebastian?=)
Date: Wed, 13 Feb 2019 05:37:41 +0000
Subject: [keycloak-dev] Certificate subject DN is provider dependent
In-Reply-To: <CAJrcDBeKbZhFzQpJfubr-swP3h8q4_EpT-JuAgXZ=PGSYF0ozA@mail.gmail.com>
References: <76d2854ebcf943a39f30f2ba4891984c@BOSKGEXC01.boskg.local>
	<CAK-7U1hLTOg2pFX0WyXLE+PmtZLAOYwSovprKq_W8j5LusKreQ@mail.gmail.com>
	<CAJrcDBedQeK35-E5g1Ru9aMyUBQ5LjJ_6=iGWKCKFL4O1nXeNw@mail.gmail.com>
	<CAJrcDBearA9dmhWxLYO6zX07SxELQkr0Y_upFdOjXcd_4-BUzw@mail.gmail.com>
	<99d26631531742279d851c74850fe737@BOSKGEXC01.boskg.local>
	<CAJrcDBcfLnqDbApUPan--n9CW=dNLdRo_eJYfmCn5ihWtbBrDw@mail.gmail.com>
	<CAMvXD=Fovok=OkNDH2iPMukSw2z-sdTA5Wi-VGOY4JADhnW0AA@mail.gmail.com>
	<CAJrcDBeeGShDpktMzJO7NfUV6L6i-rgb4QPxgLr5yfxyd-PjkQ@mail.gmail.com>
	<3e3b522e-d435-a197-8792-72caf35254ca@redhat.com>
	<CAJrcDBfTRmtOaw19vfZ2PMM8HXbHeqv2yFxBAkKmh8apYbYXCQ@mail.gmail.com>
	<29ac8ce8-cbd8-6021-11b7-5104d369d578@redhat.com>
	<CAJrcDBf0MVuqdR6W6vF8EUf2jWN=TYK5+kzWqS+egVF9VOsgSA@mail.gmail.com>
	<76df2c03-1db9-19df-7220-99476748b1d8@redhat.com>
	<CAJrcDBeKbZhFzQpJfubr-swP3h8q4_EpT-JuAgXZ=PGSYF0ozA@mail.gmail.com>
Message-ID: <786a08d034b24fb5bc1b3dddcbc2b42d@BOSKGEXC01.boskg.local>

The main point on this issue in my opinion is to have a reliable, provider independent DN representation.
This is not given using the currently used Java API X509Certificate.getSubjectDN() and X509Certificate.getIssuerDN(). 
The JavaDoc states here the result is "[...]an implementation specific Principal object, which should not be relied upon by portable code."
So I think providing an alternative is necessary.

I am wondering if this canonical config switch ON/OFF is the right way. It has no effect on all other user identity source, e.g. serial number.
Wouldn't it be better to implement two alternatives "Match canonical IssuerDN using regular expression" and "Match canonical SubjectDN using regular expression"?
The existing solutions are kept for backward compatibility but deprecated in the documentation?

Best regards,
Sebastian

> -----Urspr?ngliche Nachricht-----
> Von: keycloak-dev-bounces at lists.jboss.org <keycloak-dev-
> bounces at lists.jboss.org> Im Auftrag von Pedro Igor Silva
> Gesendet: Mittwoch, 13. Februar 2019 00:03
> An: John Dennis <jdennis at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Betreff: Re: [keycloak-dev] Certificate subject DN is provider dependent
> 
> On Tue, Feb 12, 2019 at 8:17 PM John Dennis <jdennis at redhat.com> wrote:
> 
> > On 2/12/19 4:26 PM, Pedro Igor Silva wrote:
> > > Sure, but note that RFC-4514 relies on 4519 (which actually defines
> > > the supported attributed types).
> >
> > I don't think RFC 4519 is what you're looking for, you want to be
> > looking at the X509 Certificate RFC's.
> >
> > Ugh, the RFC's for this stuff is a tangled mess of cross references to
> > other RFC's. It's ugly and hard to decipher which is probably why
> > these issues seem to keep cropping up.
> >
> 
> Yes, they are ...
> 
> 
> >
> > > The main reason for pushing this question is that from a security
> > > perspective, using a deprecated attribute type in subject dn is not
> > > good. Privacy concerns may apply here too where you may not want
> > > people to put the email (sensitive) in something that is supposed to be public.
> >
> > I'm not sure that's the question. You don't have control over the
> > certs that are presented to you. Rather your job is to ascertain if
> > you can unequivocally map the cert subject to a principal in your
> > domain. You probably can't put a stake in the ground and demand the
> > subject contain certain RDN's (with the exception of the CN). And FWIW
> > just to make things even more confusing a common convention for client
> > certs is to put the users email address as the subject's CN.
> >
> > I have a suggestion, I'm not the ultimate authority on this stuff. We
> > have a developer on the Certificate Server team who I believe has an
> > even more in depth understanding and is probably more current on this
> > topic that I am (I did this work several years ago). He is Fraser
> > Tweedale <ftweedal at redhat.com>, perhaps you might want to open a
> > discussion with him. FWIW the Certificate Server is also written in
> > Java and he might be able to share Java code snippets with you on the
> > best way to perform these comparisons.
> >
> 
> Yeah, we can not control how people are issuing certificates. I was trying to find
> someone to say "Yeah, emailAddress is really a bad practice in subject dn.
> People should use SAN instead".
> 
> I think your contact may help here with both issues, for sure. Although I'm
> convinced that at least the changes made in that PR are fine instead of possibly
> breaking use cases by forcing canonicalization.
> 
> 
> >
> >
> > --
> > John Dennis
> >
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From Joerg.Zaunegger at kvbawue.de  Wed Feb 13 04:39:48 2019
From: Joerg.Zaunegger at kvbawue.de (=?iso-8859-1?Q?Zaunegger=2C_J=F6rg?=)
Date: Wed, 13 Feb 2019 09:39:48 +0000
Subject: [keycloak-dev] Client and Service Account Session
In-Reply-To: <8661B716A6678E46A20FB7FCFF2504A10129B6D9C1@VMSST107.kvbw.local>
References: <8661B716A6678E46A20FB7FCFF2504A10129B6D9C1@VMSST107.kvbw.local>
Message-ID: <8661B716A6678E46A20FB7FCFF2504A10129B6D9E4@VMSST107.kvbw.local>

Hi Pedro,

In our application we are securing spring-actuator endpoints with a keycloak role. These endpoints are requested repeatedly (every 5 s) by an application called spring-boot-admin<https://github.com/codecentric/spring-boot-admin>. For the request spring-boot-admin obtains an AccessToken. Because there is a session for each request, we have thousands of open sessions for the service account of spring-boot-admin.
Any news, suggestions or solutions on avoiding these open sessions?

Thanks.
J?rg Zaunegger

-----Urspr?ngliche Nachricht-----
Von: keycloak-user-bounces at lists.jboss.org<mailto:keycloak-user-bounces at lists.jboss.org> <keycloak-user-bounces at lists.jboss.org<mailto:keycloak-user-bounces at lists.jboss.org>> Im Auftrag von Pedro Igor Silva
Gesendet: Montag, 13. November 2017 09:52
An: keycloak-dev at lists.jboss.org<mailto:keycloak-dev at lists.jboss.org>
Betreff: RE: [keycloak-dev] Client and Service Account Session


Hi,

Currently, every time a confidential client tries to get a new access token
from the token endpoint a new session is created on the server. This can
lead to multiple active sessions for a single client/service account when
doing multiple requests to token endpoint.

To avoid that the client should store the access token/refresh token and
use a refresh token when appropriate in case the access token has expired.
That is fine.

Now, suppose a confidential client is deployed and wants an access token. A
new session will be created on the server. In case the application goes
down for some reason (e.g.: container moved to a different node in
kubernetes and without a persistent volume) and tries to get a new access
token, we may end-up with two active sessions when asking for a new token
after a re-deploy.

What are your thoughts about re-using existing sessions when doing client
credentials ? What could be the impact on clustering if we need (and we'll
probably need) to update the session ?

Another question would be ... Does make sense to also enable clients to
obtain tokens without necessarily creating a session on the server ? I
think that in most cases, you don't really want to keep track of sessions
when doing client credentials.

Regards.
Pedro Igor



From mposolda at redhat.com  Wed Feb 13 06:42:35 2019
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 13 Feb 2019 12:42:35 +0100
Subject: [keycloak-dev] Certificate subject DN is provider dependent
In-Reply-To: <CAJrcDBf0MVuqdR6W6vF8EUf2jWN=TYK5+kzWqS+egVF9VOsgSA@mail.gmail.com>
References: <76d2854ebcf943a39f30f2ba4891984c@BOSKGEXC01.boskg.local>
	<CAK-7U1hLTOg2pFX0WyXLE+PmtZLAOYwSovprKq_W8j5LusKreQ@mail.gmail.com>
	<CAJrcDBedQeK35-E5g1Ru9aMyUBQ5LjJ_6=iGWKCKFL4O1nXeNw@mail.gmail.com>
	<CAJrcDBearA9dmhWxLYO6zX07SxELQkr0Y_upFdOjXcd_4-BUzw@mail.gmail.com>
	<99d26631531742279d851c74850fe737@BOSKGEXC01.boskg.local>
	<CAJrcDBcfLnqDbApUPan--n9CW=dNLdRo_eJYfmCn5ihWtbBrDw@mail.gmail.com>
	<CAMvXD=Fovok=OkNDH2iPMukSw2z-sdTA5Wi-VGOY4JADhnW0AA@mail.gmail.com>
	<CAJrcDBeeGShDpktMzJO7NfUV6L6i-rgb4QPxgLr5yfxyd-PjkQ@mail.gmail.com>
	<3e3b522e-d435-a197-8792-72caf35254ca@redhat.com>
	<CAJrcDBfTRmtOaw19vfZ2PMM8HXbHeqv2yFxBAkKmh8apYbYXCQ@mail.gmail.com>
	<29ac8ce8-cbd8-6021-11b7-5104d369d578@redhat.com>
	<CAJrcDBf0MVuqdR6W6vF8EUf2jWN=TYK5+kzWqS+egVF9VOsgSA@mail.gmail.com>
Message-ID: <86706fd1-6b66-2eb8-474a-ae93bb3047ca@redhat.com>

On 12/02/2019 22:26, Pedro Igor Silva wrote:
> On Tue, Feb 12, 2019 at 6:43 PM John Dennis <jdennis at redhat.com> wrote:
>
>> On 2/12/19 3:04 PM, Pedro Igor Silva wrote:
>>> Pretty much, but not the same. The fix for this still does not seem to
>>> solve the problem being discussed in the other thread.
>>>
>>> The change provided by Sebastian does solve this problem while still
>>> backwards compatible with certificates with subject dn containing an
>>> emailAddress. My point though is whether or not we should be backward
>>> compatible given that emailAddress is a deprecated RDN in the subject DN.
>>>
>>> As you mentioned, RFC-2253 was superseded by RFC-4514 and there you
>>> can't have emailAddress in subject DN but prefer a SAN. So, my question
>>> is ... Is OK in 2019 to assume that certificates are using RFC-4514 ? So
>>> we could just use the canonical format in our side and avoid any
>>> additional configuration.
>>>
>>> You are right, java defaults to RFC-2253, I'm not sure if the
>>> "canonical" format is related with the support for 4514 (at least
>>> removing emailAddress from subject DN).
>> No, RFC's 2253 and 4514 *only* describe the process by which a binary DN
>> in ASN.1 format is converted to a string representation. These RFC's do
>> not define the permissible members of a DN in an X509 certificate. In
>> fact the subject member of an X509 certificate was originally *under*
>> specified leading to all sorts of compatibility problems. The usual
>> solution adopted only by convention and not by specification is to
>> extract the CommonName (i.e. CN) RDN value and use that as the subject
>> name (usually in the scope of the issuer). But as you can imagine that
>> also has it's own problems (e.g. name collisions that would otherwise be
>> uniquely determined by the other RDN values and/or scoping to the issuer).
>>
> Sure, but note that RFC-4514 relies on 4519 (which actually defines the
> supported attributed types).
>
>
>> I go back to my original assertion when I first replied weeks ago. If
>> you want to compare DN's for equality you're going to have to do so by
>> breaking the DN down into it's component parts and comparing them
>> individually or reformat the string representation of the DN into a
>> canonical form and perform a string comparison (note that forming a
>> canonical string representation also requires breaking the components
>> apart so there is little actual difference between doing an equality
>> test between DN objects and an equality comparison on the resulting
>> canonical strings, the later just adds the cycles needed to format the
>> individual components).
>>
> Yeah, I think so. I hope this can solve the "comparison issue". Need to get
> more familiar with what was discussed in the other thread.

Just to refresh, the problem discussed on the other thread was 
unfortunately not simply "comparison issue" (which I think is not hard 
to solve with the proposal you suggested above), but "lookup user 
issue", which makes things slightly more complicated.

AFAIR the use-case was, that you just received the certificate with some 
Subject DN and based on that, you needed to lookup Keycloak user with 
corresponding LDAP DN.

Marek

>
> So, based on your experience in Openstack. Is there people still using
> certificates with deprecated emailAddress as part of the subject DN ? If
> your answer is no, we probably want to avoid an additional configuration to
> enable/disable java canonical format. Otherwise, if your answer is
> yes/don't know, maybe we should keep the configuration option implemented
> in the PR.
>
> The main reason for pushing this question is that from a security
> perspective, using a deprecated attribute type in subject dn is not good.
> Privacy concerns may apply here too where you may not want people to put
> the email (sensitive) in something that is supposed to be public.
>
> Thanks.
>
>
>>
>> --
>> John Dennis
>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



From psilva at redhat.com  Wed Feb 13 07:08:01 2019
From: psilva at redhat.com (Pedro Igor Silva)
Date: Wed, 13 Feb 2019 10:08:01 -0200
Subject: [keycloak-dev] Certificate subject DN is provider dependent
In-Reply-To: <786a08d034b24fb5bc1b3dddcbc2b42d@BOSKGEXC01.boskg.local>
References: <76d2854ebcf943a39f30f2ba4891984c@BOSKGEXC01.boskg.local>
	<CAK-7U1hLTOg2pFX0WyXLE+PmtZLAOYwSovprKq_W8j5LusKreQ@mail.gmail.com>
	<CAJrcDBedQeK35-E5g1Ru9aMyUBQ5LjJ_6=iGWKCKFL4O1nXeNw@mail.gmail.com>
	<CAJrcDBearA9dmhWxLYO6zX07SxELQkr0Y_upFdOjXcd_4-BUzw@mail.gmail.com>
	<99d26631531742279d851c74850fe737@BOSKGEXC01.boskg.local>
	<CAJrcDBcfLnqDbApUPan--n9CW=dNLdRo_eJYfmCn5ihWtbBrDw@mail.gmail.com>
	<CAMvXD=Fovok=OkNDH2iPMukSw2z-sdTA5Wi-VGOY4JADhnW0AA@mail.gmail.com>
	<CAJrcDBeeGShDpktMzJO7NfUV6L6i-rgb4QPxgLr5yfxyd-PjkQ@mail.gmail.com>
	<3e3b522e-d435-a197-8792-72caf35254ca@redhat.com>
	<CAJrcDBfTRmtOaw19vfZ2PMM8HXbHeqv2yFxBAkKmh8apYbYXCQ@mail.gmail.com>
	<29ac8ce8-cbd8-6021-11b7-5104d369d578@redhat.com>
	<CAJrcDBf0MVuqdR6W6vF8EUf2jWN=TYK5+kzWqS+egVF9VOsgSA@mail.gmail.com>
	<76df2c03-1db9-19df-7220-99476748b1d8@redhat.com>
	<CAJrcDBeKbZhFzQpJfubr-swP3h8q4_EpT-JuAgXZ=PGSYF0ozA@mail.gmail.com>
	<786a08d034b24fb5bc1b3dddcbc2b42d@BOSKGEXC01.boskg.local>
Message-ID: <CAJrcDBduVAxkUV_vuHxkRYXzNjPEKKg+RLePonMgAqZ+2gY_pA@mail.gmail.com>

What if we use the same provider in all those identity extractors? As it
stands today, it is a mix of BC and JDK.


On Wed, Feb 13, 2019 at 3:37 AM L?sch, Sebastian <
Sebastian.Loesch at governikus.de> wrote:

> The main point on this issue in my opinion is to have a reliable, provider
> independent DN representation.
> This is not given using the currently used Java API
> X509Certificate.getSubjectDN() and X509Certificate.getIssuerDN().
> The JavaDoc states here the result is "[...]an implementation specific
> Principal object, which should not be relied upon by portable code."
> So I think providing an alternative is necessary.
>
> I am wondering if this canonical config switch ON/OFF is the right way. It
> has no effect on all other user identity source, e.g. serial number.
> Wouldn't it be better to implement two alternatives "Match canonical
> IssuerDN using regular expression" and "Match canonical SubjectDN using
> regular expression"?
> The existing solutions are kept for backward compatibility but deprecated
> in the documentation?
>
> Best regards,
> Sebastian
>
> > -----Urspr?ngliche Nachricht-----
> > Von: keycloak-dev-bounces at lists.jboss.org <keycloak-dev-
> > bounces at lists.jboss.org> Im Auftrag von Pedro Igor Silva
> > Gesendet: Mittwoch, 13. Februar 2019 00:03
> > An: John Dennis <jdennis at redhat.com>
> > Cc: keycloak-dev at lists.jboss.org
> > Betreff: Re: [keycloak-dev] Certificate subject DN is provider dependent
> >
> > On Tue, Feb 12, 2019 at 8:17 PM John Dennis <jdennis at redhat.com> wrote:
> >
> > > On 2/12/19 4:26 PM, Pedro Igor Silva wrote:
> > > > Sure, but note that RFC-4514 relies on 4519 (which actually defines
> > > > the supported attributed types).
> > >
> > > I don't think RFC 4519 is what you're looking for, you want to be
> > > looking at the X509 Certificate RFC's.
> > >
> > > Ugh, the RFC's for this stuff is a tangled mess of cross references to
> > > other RFC's. It's ugly and hard to decipher which is probably why
> > > these issues seem to keep cropping up.
> > >
> >
> > Yes, they are ...
> >
> >
> > >
> > > > The main reason for pushing this question is that from a security
> > > > perspective, using a deprecated attribute type in subject dn is not
> > > > good. Privacy concerns may apply here too where you may not want
> > > > people to put the email (sensitive) in something that is supposed to
> be public.
> > >
> > > I'm not sure that's the question. You don't have control over the
> > > certs that are presented to you. Rather your job is to ascertain if
> > > you can unequivocally map the cert subject to a principal in your
> > > domain. You probably can't put a stake in the ground and demand the
> > > subject contain certain RDN's (with the exception of the CN). And FWIW
> > > just to make things even more confusing a common convention for client
> > > certs is to put the users email address as the subject's CN.
> > >
> > > I have a suggestion, I'm not the ultimate authority on this stuff. We
> > > have a developer on the Certificate Server team who I believe has an
> > > even more in depth understanding and is probably more current on this
> > > topic that I am (I did this work several years ago). He is Fraser
> > > Tweedale <ftweedal at redhat.com>, perhaps you might want to open a
> > > discussion with him. FWIW the Certificate Server is also written in
> > > Java and he might be able to share Java code snippets with you on the
> > > best way to perform these comparisons.
> > >
> >
> > Yeah, we can not control how people are issuing certificates. I was
> trying to find
> > someone to say "Yeah, emailAddress is really a bad practice in subject
> dn.
> > People should use SAN instead".
> >
> > I think your contact may help here with both issues, for sure. Although
> I'm
> > convinced that at least the changes made in that PR are fine instead of
> possibly
> > breaking use cases by forcing canonicalization.
> >
> >
> > >
> > >
> > > --
> > > John Dennis
> > >
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From bruno at abstractj.org  Wed Feb 13 08:14:57 2019
From: bruno at abstractj.org (Bruno Oliveira)
Date: Wed, 13 Feb 2019 11:14:57 -0200
Subject: [keycloak-dev] Introduce GolangCI to Gatekeeper repository
Message-ID: <20190213131457.GA31743@abstractj.org>

Good morning,

A week ago Frederic, one of our contributors, suggested the
inclusion of GolangCI[1][2]. For those not familiar,
GolangCI can run a set of linters against the source tree. It can
check if the code respects the code style, if there are vulnerabilities
introduced into the codebase and also advise on best practices.

Even though I think it's something nice to have, I'm afraid that
GolangCI could add too much noise commenting on PRs (I'm not
sure if this can be disabled). 

Even though is something cool, I'm 50/50 on this. I don't see the
adoption from big projects like Openshift or Kubernetes.

Thoughts?

[1] - https://github.com/keycloak/keycloak-gatekeeper/pull/454
[2] - https://golangci.com/

-- 

abstractj

From kschwiersch at yahoo.de  Wed Feb 13 08:15:26 2019
From: kschwiersch at yahoo.de (Ken Haendel)
Date: Wed, 13 Feb 2019 14:15:26 +0100
Subject: [keycloak-dev] Why does client session expire regardless
 remember-me extended validity?
Message-ID: <7637f53f-dd9b-2a3c-3816-a25d14ca189a@yahoo.de>

I have a problem authenticating a spring secured web-app using keycloak 
4.8.3.

If the user logs in with remember-me enabled, the user session does use 
a larger SSO max life span (ssoSessionMaxLifespanRememberMe).

So far so good.

Now i want to call another secured REST-API using the KeycloakRestService.

That triggers OAuthRequestAuthenticator to verify token 
(AdapterTokenVerifier.verifyTokens).

That operation fails, because the client session expired much earlier 
(after ssoSessionMaxLifespan). The client session gets removed from the 
client session cache 
(InfinispanUserSessionProvider.removeExpiredUserSessions).

Error message of AdapterTokenVerifier.verifyTokens() is:

"ERROR RefreshableKeycloakSecurityContext Refresh token failure status: 
400 {"error":"invalid_grant","error_description":"Session doesn't have 
required client"}"


So, the point is: after the client session gets removed from cache (SSO 
max life span) i can no longer use the refresh token to request new 
tokens and call another REST-API service

using the same identity as the web-app.

Even though i have still a valid user session to use my spring app.


Expectation was: I can use refresh token within the larger time span? 
with remember-me enabled (SsoSessionMaxLifespanRememberMe).

Actual behaviour is: Refresh token gets useless within the shorter time 
span (ssoSessionMaxLifespan)

Question: Why is the client session removed so early and not when the 
user session expires? Is that expected behavoiur?

Thank you in advance,

Ken



From slaskawi at redhat.com  Wed Feb 13 08:53:03 2019
From: slaskawi at redhat.com (Sebastian Laskawiec)
Date: Wed, 13 Feb 2019 14:53:03 +0100
Subject: [keycloak-dev] Running custom scripts in Keycloak container
	image
In-Reply-To: <CAJrcDBe+7RZ5iiOw_91o3NC9=c+QWrnBkEWixmxBeFQf=eR6cw@mail.gmail.com>
References: <CAA9R9O4-0-3D0pLyquAVjHN7qKb=NZosPH-iu51OA2oNXfM99A@mail.gmail.com>
	<CAK-7U1jdW-g4bcNbjoDG3yxST3rKHJXn+Zideed4EQTwWGWWew@mail.gmail.com>
	<CAJrcDBe+7RZ5iiOw_91o3NC9=c+QWrnBkEWixmxBeFQf=eR6cw@mail.gmail.com>
Message-ID: <CAA9R9O7BBjeMeXUd6YFkMs_YpDXeeq0g8TSzzzeT5n1ySgAVog@mail.gmail.com>

Yes, that's the idea how this can work.

On Tue, Feb 12, 2019 at 4:19 PM Pedro Igor Silva <psilva at redhat.com> wrote:

> Regarding the PR from Wouter. Instead of extending the image would be
> possible to attach a volume with the scripts that need to be run on
> startup? That would avoid the burden of creating a new image to only add a
> few files into a directory.
>
> On Tue, Feb 12, 2019 at 12:37 PM Thomas Darimont <
> thomas.darimont at googlemail.com> wrote:
>
>> Hello,
>>
>> I'm one of the maintainers of the Keycloak helm chart:
>> https://github.com/helm/charts/tree/master/stable/keycloak
>> Since a lot of our users need to adjust the default configuration that is
>> provided by the Keycloak docker images, we currently generate a
>> keycloak.cli file that we apply during start. However, some of this
>> configuration is again overridden by the defaults from the Keycloak docker
>> image.
>>
>> See:
>>
>> https://github.com/helm/charts/blob/master/stable/keycloak/templates/configmap.yaml#L12
>> Configuration:
>>
>> https://github.com/helm/charts/blob/master/stable/keycloak/values.yaml#L121
>>
>> Having dedicated support for config customizations at bootstrap in the
>> stock Keycloak image would make things much easier here :)
>>
>> Cheers,
>> Thomas
>>
>> Am Di., 12. Feb. 2019 um 14:42 Uhr schrieb Sebastian Laskawiec <
>> slaskawi at redhat.com>:
>>
>> > Hey guys,
>> >
>> > A while ago, one of our contributors, Wouter, sent an interesting pull
>> > request: https://github.com/jboss-dockerfiles/keycloak/pull/176
>> >
>> > The aim is to allow running custom scripts just before Keycloak boots up
>> > and after the main configuration is done. This allows a user to inject
>> his
>> > own scripts (even *.cli) into /opt/jboss/tools/docker-entrypoint.d and
>> > execute them automatically.
>> >
>> > This is somewhat related to what the Integrately Team is doing. They
>> > basically use an InitContainer [1] to put additional extensions into our
>> > image. Perhaps with the proposed approach, they could embed a custom
>> script
>> > that would download whatever extensions they need and put them into the
>> > deployments directory?
>> >
>> > After thinking about this for a while, and besides really good
>> advantages
>> > of the Pull Request, I have some doubts. The biggest one is about our
>> > guarantees with regard the Keycloak distribution (by saying
>> distribution I
>> > mean the binaries, their structure and Keycloak server location in the
>> > image). If we accept this approach, it will be pretty hard for us to
>> change
>> > any major thing (even some trivial things like the location of the
>> Keycloak
>> > Server) without breaking the client scripts.
>> >
>> > Personally, I'm slightly leaning towards accepting this feature, but
>> with a
>> > description in README, that the user scripts may break at any time and
>> in
>> > any version (maybe even we should print this message in our logs). This
>> way
>> > we'll make the contract for such scripts very clear.
>> >
>> > What do you think?
>> >
>> > Thanks,
>> > Sebastian
>> >
>> > [1] https://kubernetes.io/docs/concepts/workloads/pods/init-containers/
>> > _______________________________________________
>> > 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 slaskawi at redhat.com  Wed Feb 13 08:55:37 2019
From: slaskawi at redhat.com (Sebastian Laskawiec)
Date: Wed, 13 Feb 2019 14:55:37 +0100
Subject: [keycloak-dev] What Jetty versions we want to support?
In-Reply-To: <CAMvXD=EyCVC7C6sNwQLW+SmacKjpvibpr0fUndjEEN2H1FBGUA@mail.gmail.com>
References: <CAA9R9O5hqjn577MjtMfFT1hGQJxhYivFwPdOfd6dOuG76k+v7A@mail.gmail.com>
	<CAJgngAfA2YLWQ5R4EzidkUdQe0oq=pA__0k5tUQoXLrFGP_5-w@mail.gmail.com>
	<CAA9R9O4oqKfq8jOkwV2hQNiH2x=Ci7VQ9VYGMOpCU4kWQ6LdRQ@mail.gmail.com>
	<CAMvXD=EyCVC7C6sNwQLW+SmacKjpvibpr0fUndjEEN2H1FBGUA@mail.gmail.com>
Message-ID: <CAA9R9O7Ku-A6y-sGT=+pnKqoLQGqBPXVFa+nu5wiGPBCR5kZQQ@mail.gmail.com>

So it seems we have our support matrix:
- 8.1 (because of Fuse)
- 9.2 (heavily used by the community and required by Fuse)
- 9.3 (heavily used by the community)
- 9.4 (it's the latest version)

So we might consider dropping 9.3 at some point in favor of 9.4. But that's
something to think of and probably not for now.

On Tue, Feb 12, 2019 at 5:25 PM Hynek Mlnarik <hmlnarik at redhat.com> wrote:

> For Fuse, we use 8.1 [1] and 9.2 [2].
>
> --Hynek
>
> [1]
> https://github.com/keycloak/keycloak/blob/4.8.3.Final/distribution/adapters/osgi/features/src/main/resources/features.xml#L54
> [2]
> https://github.com/keycloak/keycloak/blob/4.8.3.Final/distribution/adapters/osgi/features/src/main/resources/features.xml#L63
>
> On Tue, Feb 12, 2019 at 12:05 PM Sebastian Laskawiec <slaskawi at redhat.com>
> wrote:
>
>> Ok, understood! Thanks a lot for the info Stian!
>>
>> On Tue, Feb 12, 2019 at 11:48 AM Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>>
>> > We test them until we remove ;)
>> >
>> > 8.1 and 9.1 have already been removed from the community. We need to
>> > confirm if these are needed by Fuse (we don't support Jetty directly for
>> > RH-SSO, but rather only through Fuse). If Fuse relies on these we need
>> to
>> > continue testing them.
>> >
>> > 9.2 and 9.3 still has users in the community (25 dls of each the last 3
>> > months, but that is only direct dls through website, not sure if folks
>> also
>> > use them from Maven central). We should keep these for now though and
>> > consider deprecating at some point in the future.
>> >
>> > On Tue, 12 Feb 2019 at 10:24, Sebastian Laskawiec <slaskawi at redhat.com>
>> > wrote:
>> >
>> >> Hey guys,
>> >>
>> >> I'm working on moving Jetty adapter tests from the old testsuite into
>> the
>> >> new one. I can see we support this Jetty versions [1]:
>> >> - 8.1
>> >> - 9.1
>> >> - 9.2
>> >> - 9.3
>> >> - 9.4
>> >>
>> >> Do we want to keep it this way or maybe concentrate on testing adapters
>> >> against 8.1 and 9.4 only (the last major versions)?
>> >>
>> >> Thanks,
>> >> Sebastian
>> >>
>> >> [1] grep -lir "keycloak-saml-jetty" --include="*.xml"
>> >>
>> > _______________________________________________
>> >> 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.Loesch at governikus.de  Wed Feb 13 09:12:57 2019
From: Sebastian.Loesch at governikus.de (=?iso-8859-1?Q?L=F6sch=2C_Sebastian?=)
Date: Wed, 13 Feb 2019 14:12:57 +0000
Subject: [keycloak-dev] Certificate subject DN is provider dependent
In-Reply-To: <CAJrcDBduVAxkUV_vuHxkRYXzNjPEKKg+RLePonMgAqZ+2gY_pA@mail.gmail.com>
References: <76d2854ebcf943a39f30f2ba4891984c@BOSKGEXC01.boskg.local>
	<CAK-7U1hLTOg2pFX0WyXLE+PmtZLAOYwSovprKq_W8j5LusKreQ@mail.gmail.com>
	<CAJrcDBedQeK35-E5g1Ru9aMyUBQ5LjJ_6=iGWKCKFL4O1nXeNw@mail.gmail.com>
	<CAJrcDBearA9dmhWxLYO6zX07SxELQkr0Y_upFdOjXcd_4-BUzw@mail.gmail.com>
	<99d26631531742279d851c74850fe737@BOSKGEXC01.boskg.local>
	<CAJrcDBcfLnqDbApUPan--n9CW=dNLdRo_eJYfmCn5ihWtbBrDw@mail.gmail.com>
	<CAMvXD=Fovok=OkNDH2iPMukSw2z-sdTA5Wi-VGOY4JADhnW0AA@mail.gmail.com>
	<CAJrcDBeeGShDpktMzJO7NfUV6L6i-rgb4QPxgLr5yfxyd-PjkQ@mail.gmail.com>
	<3e3b522e-d435-a197-8792-72caf35254ca@redhat.com>
	<CAJrcDBfTRmtOaw19vfZ2PMM8HXbHeqv2yFxBAkKmh8apYbYXCQ@mail.gmail.com>
	<29ac8ce8-cbd8-6021-11b7-5104d369d578@redhat.com>
	<CAJrcDBf0MVuqdR6W6vF8EUf2jWN=TYK5+kzWqS+egVF9VOsgSA@mail.gmail.com>
	<76df2c03-1db9-19df-7220-99476748b1d8@redhat.com>
	<CAJrcDBeKbZhFzQpJfubr-swP3h8q4_EpT-JuAgXZ=PGSYF0ozA@mail.gmail.com>
	<786a08d034b24fb5bc1b3dddcbc2b42d@BOSKGEXC01.boskg.local>
	<CAJrcDBduVAxkUV_vuHxkRYXzNjPEKKg+RLePonMgAqZ+2gY_pA@mail.gmail.com>
Message-ID: <63e7999724b040098b4449b1fd559c0b@BOSKGEXC01.boskg.local>

The provider that generates the certificate contained in the HttpRequest ist he default security provider of the application server. So using the same provider means using the default provider.

That may lead to problems when the default security provider changes, as the DN format changes at this time as well.





Von: Pedro Igor Silva <psilva at redhat.com>
Gesendet: Mittwoch, 13. Februar 2019 13:08
An: L?sch, Sebastian <Sebastian.Loesch at governikus.de>
Cc: jdennis at redhat.com; keycloak-dev at lists.jboss.org
Betreff: Re: [keycloak-dev] Certificate subject DN is provider dependent



What if we use the same provider in all those identity extractors? As it stands today, it is a mix of BC and JDK.





On Wed, Feb 13, 2019 at 3:37 AM L?sch, Sebastian <Sebastian.Loesch at governikus.de<mailto:Sebastian.Loesch at governikus.de>> wrote:

   The main point on this issue in my opinion is to have a reliable, provider independent DN representation.
   This is not given using the currently used Java API X509Certificate.getSubjectDN() and X509Certificate.getIssuerDN().
   The JavaDoc states here the result is "[...]an implementation specific Principal object, which should not be relied upon by portable code."
   So I think providing an alternative is necessary.

   I am wondering if this canonical config switch ON/OFF is the right way. It has no effect on all other user identity source, e.g. serial number.
   Wouldn't it be better to implement two alternatives "Match canonical IssuerDN using regular expression" and "Match canonical SubjectDN using regular expression"?
   The existing solutions are kept for backward compatibility but deprecated in the documentation?

   Best regards,
   Sebastian

   > -----Urspr?ngliche Nachricht-----
   > Von: keycloak-dev-bounces at lists.jboss.org<mailto:keycloak-dev-bounces at lists.jboss.org> <keycloak-dev-
   > bounces at lists.jboss.org<mailto:bounces at lists.jboss.org>> Im Auftrag von Pedro Igor Silva
   > Gesendet: Mittwoch, 13. Februar 2019 00:03
   > An: John Dennis <jdennis at redhat.com<mailto:jdennis at redhat.com>>
   > Cc: keycloak-dev at lists.jboss.org<mailto:keycloak-dev at lists.jboss.org>
   > Betreff: Re: [keycloak-dev] Certificate subject DN is provider dependent
   >
   > On Tue, Feb 12, 2019 at 8:17 PM John Dennis <jdennis at redhat.com<mailto:jdennis at redhat.com>> wrote:
   >
   > > On 2/12/19 4:26 PM, Pedro Igor Silva wrote:
   > > > Sure, but note that RFC-4514 relies on 4519 (which actually defines
   > > > the supported attributed types).
   > >
   > > I don't think RFC 4519 is what you're looking for, you want to be
   > > looking at the X509 Certificate RFC's.
   > >
   > > Ugh, the RFC's for this stuff is a tangled mess of cross references to
   > > other RFC's. It's ugly and hard to decipher which is probably why
   > > these issues seem to keep cropping up.
   > >
   >
   > Yes, they are ...
   >
   >
   > >
   > > > The main reason for pushing this question is that from a security
   > > > perspective, using a deprecated attribute type in subject dn is not
   > > > good. Privacy concerns may apply here too where you may not want
   > > > people to put the email (sensitive) in something that is supposed to be public.
   > >
   > > I'm not sure that's the question. You don't have control over the
   > > certs that are presented to you. Rather your job is to ascertain if
   > > you can unequivocally map the cert subject to a principal in your
   > > domain. You probably can't put a stake in the ground and demand the
   > > subject contain certain RDN's (with the exception of the CN). And FWIW
   > > just to make things even more confusing a common convention for client
   > > certs is to put the users email address as the subject's CN.
   > >
   > > I have a suggestion, I'm not the ultimate authority on this stuff. We
   > > have a developer on the Certificate Server team who I believe has an
   > > even more in depth understanding and is probably more current on this
   > > topic that I am (I did this work several years ago). He is Fraser
   > > Tweedale <ftweedal at redhat.com<mailto:ftweedal at redhat.com>>, perhaps you might want to open a
   > > discussion with him. FWIW the Certificate Server is also written in
   > > Java and he might be able to share Java code snippets with you on the
   > > best way to perform these comparisons.
   > >
   >
   > Yeah, we can not control how people are issuing certificates. I was trying to find
   > someone to say "Yeah, emailAddress is really a bad practice in subject dn.
   > People should use SAN instead".
   >
   > I think your contact may help here with both issues, for sure. Although I'm
   > convinced that at least the changes made in that PR are fine instead of possibly
   > breaking use cases by forcing canonicalization.
   >
   >
   > >
   > >
   > > --
   > > John Dennis
   > >
   > _______________________________________________
   > 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 thomas.darimont at googlemail.com  Wed Feb 13 10:27:08 2019
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Wed, 13 Feb 2019 16:27:08 +0100
Subject: [keycloak-dev] Client and Service Account Session
In-Reply-To: <8661B716A6678E46A20FB7FCFF2504A10129B6D9E4@VMSST107.kvbw.local>
References: <8661B716A6678E46A20FB7FCFF2504A10129B6D9C1@VMSST107.kvbw.local>
	<8661B716A6678E46A20FB7FCFF2504A10129B6D9E4@VMSST107.kvbw.local>
Message-ID: <CAK-7U1i48Tc1jrnjzTc9Ny=n7V=cgvi-LksUUA7A+JOOSuELsg@mail.gmail.com>

Hello J?rg,

I built an example app that demonstrates this spring-boot-admin / Keycloak
setup.

Would it help to use offline_tokens for the spring-boot-admin service
account instead of normal refresh-tokens?

Unfortunately the Keycloak Admin client library currently does not support
custom scopes like scope=offline_access.

I just pushed a PoC with patched offline_access support via a custom
TokenManager. Would you mind giving it a try?
https://github.com/thomasdarimont/spring-boot-admin-keycloak-example/tree/poc/keycloak-offline-access


Cheers,
Thomas

Am Mi., 13. Feb. 2019 um 10:43 Uhr schrieb Zaunegger, J?rg <
Joerg.Zaunegger at kvbawue.de>:

> Hi Pedro,
>
> In our application we are securing spring-actuator endpoints with a
> keycloak role. These endpoints are requested repeatedly (every 5 s) by an
> application called spring-boot-admin<
> https://github.com/codecentric/spring-boot-admin>. For the request
> spring-boot-admin obtains an AccessToken. Because there is a session for
> each request, we have thousands of open sessions for the service account of
> spring-boot-admin.
> Any news, suggestions or solutions on avoiding these open sessions?
>
> Thanks.
> J?rg Zaunegger
>
> -----Urspr?ngliche Nachricht-----
> Von: keycloak-user-bounces at lists.jboss.org<mailto:
> keycloak-user-bounces at lists.jboss.org> <
> keycloak-user-bounces at lists.jboss.org<mailto:
> keycloak-user-bounces at lists.jboss.org>> Im Auftrag von Pedro Igor Silva
> Gesendet: Montag, 13. November 2017 09:52
> An: keycloak-dev at lists.jboss.org<mailto:keycloak-dev at lists.jboss.org>
> Betreff: RE: [keycloak-dev] Client and Service Account Session
>
>
> Hi,
>
> Currently, every time a confidential client tries to get a new access token
> from the token endpoint a new session is created on the server. This can
> lead to multiple active sessions for a single client/service account when
> doing multiple requests to token endpoint.
>
> To avoid that the client should store the access token/refresh token and
> use a refresh token when appropriate in case the access token has expired.
> That is fine.
>
> Now, suppose a confidential client is deployed and wants an access token. A
> new session will be created on the server. In case the application goes
> down for some reason (e.g.: container moved to a different node in
> kubernetes and without a persistent volume) and tries to get a new access
> token, we may end-up with two active sessions when asking for a new token
> after a re-deploy.
>
> What are your thoughts about re-using existing sessions when doing client
> credentials ? What could be the impact on clustering if we need (and we'll
> probably need) to update the session ?
>
> Another question would be ... Does make sense to also enable clients to
> obtain tokens without necessarily creating a session on the server ? I
> think that in most cases, you don't really want to keep track of sessions
> when doing client credentials.
>
> Regards.
> Pedro Igor
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From psilva at redhat.com  Wed Feb 13 10:23:55 2019
From: psilva at redhat.com (Pedro Igor Silva)
Date: Wed, 13 Feb 2019 13:23:55 -0200
Subject: [keycloak-dev] Certificate subject DN is provider dependent
In-Reply-To: <63e7999724b040098b4449b1fd559c0b@BOSKGEXC01.boskg.local>
References: <76d2854ebcf943a39f30f2ba4891984c@BOSKGEXC01.boskg.local>
	<CAK-7U1hLTOg2pFX0WyXLE+PmtZLAOYwSovprKq_W8j5LusKreQ@mail.gmail.com>
	<CAJrcDBedQeK35-E5g1Ru9aMyUBQ5LjJ_6=iGWKCKFL4O1nXeNw@mail.gmail.com>
	<CAJrcDBearA9dmhWxLYO6zX07SxELQkr0Y_upFdOjXcd_4-BUzw@mail.gmail.com>
	<99d26631531742279d851c74850fe737@BOSKGEXC01.boskg.local>
	<CAJrcDBcfLnqDbApUPan--n9CW=dNLdRo_eJYfmCn5ihWtbBrDw@mail.gmail.com>
	<CAMvXD=Fovok=OkNDH2iPMukSw2z-sdTA5Wi-VGOY4JADhnW0AA@mail.gmail.com>
	<CAJrcDBeeGShDpktMzJO7NfUV6L6i-rgb4QPxgLr5yfxyd-PjkQ@mail.gmail.com>
	<3e3b522e-d435-a197-8792-72caf35254ca@redhat.com>
	<CAJrcDBfTRmtOaw19vfZ2PMM8HXbHeqv2yFxBAkKmh8apYbYXCQ@mail.gmail.com>
	<29ac8ce8-cbd8-6021-11b7-5104d369d578@redhat.com>
	<CAJrcDBf0MVuqdR6W6vF8EUf2jWN=TYK5+kzWqS+egVF9VOsgSA@mail.gmail.com>
	<76df2c03-1db9-19df-7220-99476748b1d8@redhat.com>
	<CAJrcDBeKbZhFzQpJfubr-swP3h8q4_EpT-JuAgXZ=PGSYF0ozA@mail.gmail.com>
	<786a08d034b24fb5bc1b3dddcbc2b42d@BOSKGEXC01.boskg.local>
	<CAJrcDBduVAxkUV_vuHxkRYXzNjPEKKg+RLePonMgAqZ+2gY_pA@mail.gmail.com>
	<63e7999724b040098b4449b1fd559c0b@BOSKGEXC01.boskg.local>
Message-ID: <CAJrcDBeyJiy8Yyy554L5hcuB3XMVEQX5sz4-5DKCXmNRee=w2Q@mail.gmail.com>

I meant, use the BC API directly without depending on the installed
provider. If you look at how those identity extractors are implemented,
you'll see that some of them are using BC API. Not sure if this approach is
good though as we are removing the "portability" through JCA/JCE. In fact,
I think use BC for extracting DN will make things even more worse for the
problem discussed in the other thread ...

Back to your question, I'm OK about your PR and I'm not sure if we need
those two alternatives you proposed. The example you gave about
serialnumber does not seem to be impacted by canonicalization. Or I'm
missing something ? If others are happy too about your solution, we can
have your changes in as soon as you provide tests and docs.

Thanks.

On Wed, Feb 13, 2019 at 12:13 PM L?sch, Sebastian <
Sebastian.Loesch at governikus.de> wrote:

> The provider that generates the certificate contained in the HttpRequest
> ist he default security provider of the application server. So using the
> same provider means using the default provider.
>
> That may lead to problems when the default security provider changes, as
> the DN format changes at this time as well.
>
>
>
>
>
> *Von:* Pedro Igor Silva <psilva at redhat.com>
> *Gesendet:* Mittwoch, 13. Februar 2019 13:08
> *An:* L?sch, Sebastian <Sebastian.Loesch at governikus.de>
> *Cc:* jdennis at redhat.com; keycloak-dev at lists.jboss.org
> *Betreff:* Re: [keycloak-dev] Certificate subject DN is provider dependent
>
>
>
> What if we use the same provider in all those identity extractors? As it
> stands today, it is a mix of BC and JDK.
>
>
>
>
>
> On Wed, Feb 13, 2019 at 3:37 AM L?sch, Sebastian <
> Sebastian.Loesch at governikus.de> wrote:
>
> The main point on this issue in my opinion is to have a reliable, provider
> independent DN representation.
> This is not given using the currently used Java API
> X509Certificate.getSubjectDN() and X509Certificate.getIssuerDN().
> The JavaDoc states here the result is "[...]an implementation specific
> Principal object, which should not be relied upon by portable code."
> So I think providing an alternative is necessary.
>
> I am wondering if this canonical config switch ON/OFF is the right way. It
> has no effect on all other user identity source, e.g. serial number.
> Wouldn't it be better to implement two alternatives "Match canonical
> IssuerDN using regular expression" and "Match canonical SubjectDN using
> regular expression"?
> The existing solutions are kept for backward compatibility but deprecated
> in the documentation?
>
> Best regards,
> Sebastian
>
> > -----Urspr?ngliche Nachricht-----
> > Von: keycloak-dev-bounces at lists.jboss.org <keycloak-dev-
> > bounces at lists.jboss.org> Im Auftrag von Pedro Igor Silva
> > Gesendet: Mittwoch, 13. Februar 2019 00:03
> > An: John Dennis <jdennis at redhat.com>
> > Cc: keycloak-dev at lists.jboss.org
> > Betreff: Re: [keycloak-dev] Certificate subject DN is provider dependent
> >
> > On Tue, Feb 12, 2019 at 8:17 PM John Dennis <jdennis at redhat.com> wrote:
> >
> > > On 2/12/19 4:26 PM, Pedro Igor Silva wrote:
> > > > Sure, but note that RFC-4514 relies on 4519 (which actually defines
> > > > the supported attributed types).
> > >
> > > I don't think RFC 4519 is what you're looking for, you want to be
> > > looking at the X509 Certificate RFC's.
> > >
> > > Ugh, the RFC's for this stuff is a tangled mess of cross references to
> > > other RFC's. It's ugly and hard to decipher which is probably why
> > > these issues seem to keep cropping up.
> > >
> >
> > Yes, they are ...
> >
> >
> > >
> > > > The main reason for pushing this question is that from a security
> > > > perspective, using a deprecated attribute type in subject dn is not
> > > > good. Privacy concerns may apply here too where you may not want
> > > > people to put the email (sensitive) in something that is supposed to
> be public.
> > >
> > > I'm not sure that's the question. You don't have control over the
> > > certs that are presented to you. Rather your job is to ascertain if
> > > you can unequivocally map the cert subject to a principal in your
> > > domain. You probably can't put a stake in the ground and demand the
> > > subject contain certain RDN's (with the exception of the CN). And FWIW
> > > just to make things even more confusing a common convention for client
> > > certs is to put the users email address as the subject's CN.
> > >
> > > I have a suggestion, I'm not the ultimate authority on this stuff. We
> > > have a developer on the Certificate Server team who I believe has an
> > > even more in depth understanding and is probably more current on this
> > > topic that I am (I did this work several years ago). He is Fraser
> > > Tweedale <ftweedal at redhat.com>, perhaps you might want to open a
> > > discussion with him. FWIW the Certificate Server is also written in
> > > Java and he might be able to share Java code snippets with you on the
> > > best way to perform these comparisons.
> > >
> >
> > Yeah, we can not control how people are issuing certificates. I was
> trying to find
> > someone to say "Yeah, emailAddress is really a bad practice in subject
> dn.
> > People should use SAN instead".
> >
> > I think your contact may help here with both issues, for sure. Although
> I'm
> > convinced that at least the changes made in that PR are fine instead of
> possibly
> > breaking use cases by forcing canonicalization.
> >
> >
> > >
> > >
> > > --
> > > John Dennis
> > >
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>

From Sebastian.Loesch at governikus.de  Wed Feb 13 10:27:28 2019
From: Sebastian.Loesch at governikus.de (=?utf-8?B?TMO2c2NoLCBTZWJhc3RpYW4=?=)
Date: Wed, 13 Feb 2019 15:27:28 +0000
Subject: [keycloak-dev] Certificate subject DN is provider dependent
In-Reply-To: <CAJrcDBeyJiy8Yyy554L5hcuB3XMVEQX5sz4-5DKCXmNRee=w2Q@mail.gmail.com>
References: <76d2854ebcf943a39f30f2ba4891984c@BOSKGEXC01.boskg.local>
	<CAK-7U1hLTOg2pFX0WyXLE+PmtZLAOYwSovprKq_W8j5LusKreQ@mail.gmail.com>
	<CAJrcDBedQeK35-E5g1Ru9aMyUBQ5LjJ_6=iGWKCKFL4O1nXeNw@mail.gmail.com>
	<CAJrcDBearA9dmhWxLYO6zX07SxELQkr0Y_upFdOjXcd_4-BUzw@mail.gmail.com>
	<99d26631531742279d851c74850fe737@BOSKGEXC01.boskg.local>
	<CAJrcDBcfLnqDbApUPan--n9CW=dNLdRo_eJYfmCn5ihWtbBrDw@mail.gmail.com>
	<CAMvXD=Fovok=OkNDH2iPMukSw2z-sdTA5Wi-VGOY4JADhnW0AA@mail.gmail.com>
	<CAJrcDBeeGShDpktMzJO7NfUV6L6i-rgb4QPxgLr5yfxyd-PjkQ@mail.gmail.com>
	<3e3b522e-d435-a197-8792-72caf35254ca@redhat.com>
	<CAJrcDBfTRmtOaw19vfZ2PMM8HXbHeqv2yFxBAkKmh8apYbYXCQ@mail.gmail.com>
	<29ac8ce8-cbd8-6021-11b7-5104d369d578@redhat.com>
	<CAJrcDBf0MVuqdR6W6vF8EUf2jWN=TYK5+kzWqS+egVF9VOsgSA@mail.gmail.com>
	<76df2c03-1db9-19df-7220-99476748b1d8@redhat.com>
	<CAJrcDBeKbZhFzQpJfubr-swP3h8q4_EpT-JuAgXZ=PGSYF0ozA@mail.gmail.com>
	<786a08d034b24fb5bc1b3dddcbc2b42d@BOSKGEXC01.boskg.local>
	<CAJrcDBduVAxkUV_vuHxkRYXzNjPEKKg+RLePonMgAqZ+2gY_pA@mail.gmail.com>
	<63e7999724b040098b4449b1fd559c0b@BOSKGEXC01.boskg.local>
	<CAJrcDBeyJiy8Yyy554L5hcuB3XMVEQX5sz4-5DKCXmNRee=w2Q@mail.gmail.com>
Message-ID: <fce91aa8449f4027be04ee29367866b1@BOSKGEXC01.boskg.local>

Okay, that sound?s great! I will work on that soon.

Thanks.

Von: Pedro Igor Silva <psilva at redhat.com> 
Gesendet: Mittwoch, 13. Februar 2019 16:24
An: L?sch, Sebastian <Sebastian.Loesch at governikus.de>
Cc: jdennis at redhat.com; keycloak-dev at lists.jboss.org
Betreff: Re: [keycloak-dev] Certificate subject DN is provider dependent

 

I meant, use the BC API directly without depending on the installed provider. If you look at how those identity extractors are implemented, you'll see that some of them are using BC API. Not sure if this approach is good though as we are removing the "portability" through JCA/JCE. In fact, I think use BC for extracting DN will make things even more worse for the problem discussed in the other thread ...

 

Back to your question, I'm OK about your PR and I'm not sure if we need those two alternatives you proposed. The example you gave about serialnumber does not seem to be impacted by canonicalization. Or I'm missing something ? If others are happy too about your solution, we can have your changes in as soon as you provide tests and docs.

 

Thanks.

 

On Wed, Feb 13, 2019 at 12:13 PM L?sch, Sebastian <Sebastian.Loesch at governikus.de <mailto:Sebastian.Loesch at governikus.de> > wrote:

The provider that generates the certificate contained in the HttpRequest ist he default security provider of the application server. So using the same provider means using the default provider. 

That may lead to problems when the default security provider changes, as the DN format changes at this time as well.

 

 

Von: Pedro Igor Silva <psilva at redhat.com <mailto:psilva at redhat.com> > 
Gesendet: Mittwoch, 13. Februar 2019 13:08
An: L?sch, Sebastian <Sebastian.Loesch at governikus.de <mailto:Sebastian.Loesch at governikus.de> >
Cc: jdennis at redhat.com <mailto:jdennis at redhat.com> ; keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org> 
Betreff: Re: [keycloak-dev] Certificate subject DN is provider dependent

 

What if we use the same provider in all those identity extractors? As it stands today, it is a mix of BC and JDK.

 

 

On Wed, Feb 13, 2019 at 3:37 AM L?sch, Sebastian <Sebastian.Loesch at governikus.de <mailto:Sebastian.Loesch at governikus.de> > wrote:

The main point on this issue in my opinion is to have a reliable, provider independent DN representation.
This is not given using the currently used Java API X509Certificate.getSubjectDN() and X509Certificate.getIssuerDN(). 
The JavaDoc states here the result is "[...]an implementation specific Principal object, which should not be relied upon by portable code."
So I think providing an alternative is necessary.

I am wondering if this canonical config switch ON/OFF is the right way. It has no effect on all other user identity source, e.g. serial number.
Wouldn't it be better to implement two alternatives "Match canonical IssuerDN using regular expression" and "Match canonical SubjectDN using regular expression"?
The existing solutions are kept for backward compatibility but deprecated in the documentation?

Best regards,
Sebastian

> -----Urspr?ngliche Nachricht-----
> Von: keycloak-dev-bounces at lists.jboss.org <mailto:keycloak-dev-bounces at lists.jboss.org>  <keycloak-dev-
> bounces at lists.jboss.org <mailto:bounces at lists.jboss.org> > Im Auftrag von Pedro Igor Silva
> Gesendet: Mittwoch, 13. Februar 2019 00:03
> An: John Dennis <jdennis at redhat.com <mailto:jdennis at redhat.com> >
> Cc: keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org> 
> Betreff: Re: [keycloak-dev] Certificate subject DN is provider dependent
> 
> On Tue, Feb 12, 2019 at 8:17 PM John Dennis <jdennis at redhat.com <mailto:jdennis at redhat.com> > wrote:
> 
> > On 2/12/19 4:26 PM, Pedro Igor Silva wrote:
> > > Sure, but note that RFC-4514 relies on 4519 (which actually defines
> > > the supported attributed types).
> >
> > I don't think RFC 4519 is what you're looking for, you want to be
> > looking at the X509 Certificate RFC's.
> >
> > Ugh, the RFC's for this stuff is a tangled mess of cross references to
> > other RFC's. It's ugly and hard to decipher which is probably why
> > these issues seem to keep cropping up.
> >
> 
> Yes, they are ...
> 
> 
> >
> > > The main reason for pushing this question is that from a security
> > > perspective, using a deprecated attribute type in subject dn is not
> > > good. Privacy concerns may apply here too where you may not want
> > > people to put the email (sensitive) in something that is supposed to be public.
> >
> > I'm not sure that's the question. You don't have control over the
> > certs that are presented to you. Rather your job is to ascertain if
> > you can unequivocally map the cert subject to a principal in your
> > domain. You probably can't put a stake in the ground and demand the
> > subject contain certain RDN's (with the exception of the CN). And FWIW
> > just to make things even more confusing a common convention for client
> > certs is to put the users email address as the subject's CN.
> >
> > I have a suggestion, I'm not the ultimate authority on this stuff. We
> > have a developer on the Certificate Server team who I believe has an
> > even more in depth understanding and is probably more current on this
> > topic that I am (I did this work several years ago). He is Fraser
> > Tweedale <ftweedal at redhat.com <mailto:ftweedal at redhat.com> >, perhaps you might want to open a
> > discussion with him. FWIW the Certificate Server is also written in
> > Java and he might be able to share Java code snippets with you on the
> > best way to perform these comparisons.
> >
> 
> Yeah, we can not control how people are issuing certificates. I was trying to find
> someone to say "Yeah, emailAddress is really a bad practice in subject dn.
> People should use SAN instead".
> 
> I think your contact may help here with both issues, for sure. Although I'm
> convinced that at least the changes made in that PR are fine instead of possibly
> breaking use cases by forcing canonicalization.
> 
> 
> >
> >
> > --
> > John Dennis
> >
> _______________________________________________
> 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 mposolda at redhat.com  Wed Feb 13 10:43:20 2019
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 13 Feb 2019 16:43:20 +0100
Subject: [keycloak-dev] Why does client session expire regardless
 remember-me extended validity?
In-Reply-To: <7637f53f-dd9b-2a3c-3816-a25d14ca189a@yahoo.de>
References: <7637f53f-dd9b-2a3c-3816-a25d14ca189a@yahoo.de>
Message-ID: <685a0dff-80b9-ddd6-18ff-4847755204df@redhat.com>

We have PR open, which is related to that [1], but not sure if that PR 
fixes also your issue. It seems there is nothing related to client 
sessions. I am CCing Stefan in case he has some more to it.

In the meantime, if you are curious if fix works, I suggest to 
cherry-pick Stefan's commit and build Keycloak and check if the 
behaviour is fixed with that PR.

[1] https://github.com/keycloak/keycloak/pull/5852

Marek

On 13/02/2019 14:15, Ken Haendel wrote:
> I have a problem authenticating a spring secured web-app using keycloak
> 4.8.3.
>
> If the user logs in with remember-me enabled, the user session does use
> a larger SSO max life span (ssoSessionMaxLifespanRememberMe).
>
> So far so good.
>
> Now i want to call another secured REST-API using the KeycloakRestService.
>
> That triggers OAuthRequestAuthenticator to verify token
> (AdapterTokenVerifier.verifyTokens).
>
> That operation fails, because the client session expired much earlier
> (after ssoSessionMaxLifespan). The client session gets removed from the
> client session cache
> (InfinispanUserSessionProvider.removeExpiredUserSessions).
>
> Error message of AdapterTokenVerifier.verifyTokens() is:
>
> "ERROR RefreshableKeycloakSecurityContext Refresh token failure status:
> 400 {"error":"invalid_grant","error_description":"Session doesn't have
> required client"}"
>
>
> So, the point is: after the client session gets removed from cache (SSO
> max life span) i can no longer use the refresh token to request new
> tokens and call another REST-API service
>
> using the same identity as the web-app.
>
> Even though i have still a valid user session to use my spring app.
>
>
> Expectation was: I can use refresh token within the larger time span
> with remember-me enabled (SsoSessionMaxLifespanRememberMe).
>
> Actual behaviour is: Refresh token gets useless within the shorter time
> span (ssoSessionMaxLifespan)
>
> Question: Why is the client session removed so early and not when the
> user session expires? Is that expected behavoiur?
>
> Thank you in advance,
>
> Ken
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



From Joerg.Zaunegger at kvbawue.de  Wed Feb 13 12:11:28 2019
From: Joerg.Zaunegger at kvbawue.de (=?utf-8?B?WmF1bmVnZ2VyLCBKw7ZyZw==?=)
Date: Wed, 13 Feb 2019 17:11:28 +0000
Subject: [keycloak-dev] Client and Service Account Session
In-Reply-To: <CAK-7U1i48Tc1jrnjzTc9Ny=n7V=cgvi-LksUUA7A+JOOSuELsg@mail.gmail.com>
References: <8661B716A6678E46A20FB7FCFF2504A10129B6D9C1@VMSST107.kvbw.local>
	<8661B716A6678E46A20FB7FCFF2504A10129B6D9E4@VMSST107.kvbw.local>
	<CAK-7U1i48Tc1jrnjzTc9Ny=n7V=cgvi-LksUUA7A+JOOSuELsg@mail.gmail.com>
Message-ID: <8661B716A6678E46A20FB7FCFF2504A10129B6DB2A@VMSST107.kvbw.local>

Hi Thomas,

thanks. Of course I will give it a try.
Today I did also try to find a solution by myself.
Because we are using AccessTokens in our applications to access other applications, we will having the problem not only with spring-boot-admin. What do you think about caching the AccessTokenResponse.

If the AccessToken is not valid but the RefreshToken is, then we obtain a new AcessToken with that RefreshToken. If the RefreshToken is no longer valid, we obtain a new token with the credentials of the service account.
It seems to work. Do you see any problem with this solution?

Cheers J?rg

Von: Thomas Darimont <thomas.darimont at googlemail.com>
Gesendet: Mittwoch, 13. Februar 2019 16:27
An: Zaunegger, J?rg <Joerg.Zaunegger at kvbawue.de>
Cc: keycloak-dev at lists.jboss.org
Betreff: Re: [keycloak-dev] Client and Service Account Session

Hello J?rg,

I built an example app that demonstrates this spring-boot-admin / Keycloak setup.

Would it help to use offline_tokens for the spring-boot-admin service account instead of normal refresh-tokens?

Unfortunately the Keycloak Admin client library currently does not support custom scopes like scope=offline_access.

I just pushed a PoC with patched offline_access support via a custom TokenManager. Would you mind giving it a try?
https://github.com/thomasdarimont/spring-boot-admin-keycloak-example/tree/poc/keycloak-offline-access

Cheers,
Thomas

Am Mi., 13. Feb. 2019 um 10:43 Uhr schrieb Zaunegger, J?rg <Joerg.Zaunegger at kvbawue.de<mailto:Joerg.Zaunegger at kvbawue.de>>:
Hi Pedro,

In our application we are securing spring-actuator endpoints with a keycloak role. These endpoints are requested repeatedly (every 5 s) by an application called spring-boot-admin<https://github.com/codecentric/spring-boot-admin>. For the request spring-boot-admin obtains an AccessToken. Because there is a session for each request, we have thousands of open sessions for the service account of spring-boot-admin.
Any news, suggestions or solutions on avoiding these open sessions?

Thanks.
J?rg Zaunegger

-----Urspr?ngliche Nachricht-----
Von: keycloak-user-bounces at lists.jboss.org<mailto:keycloak-user-bounces at lists.jboss.org><mailto:keycloak-user-bounces at lists.jboss.org<mailto:keycloak-user-bounces at lists.jboss.org>> <keycloak-user-bounces at lists.jboss.org<mailto:keycloak-user-bounces at lists.jboss.org><mailto:keycloak-user-bounces at lists.jboss.org<mailto:keycloak-user-bounces at lists.jboss.org>>> Im Auftrag von Pedro Igor Silva
Gesendet: Montag, 13. November 2017 09:52
An: 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>>
Betreff: RE: [keycloak-dev] Client and Service Account Session


Hi,

Currently, every time a confidential client tries to get a new access token
from the token endpoint a new session is created on the server. This can
lead to multiple active sessions for a single client/service account when
doing multiple requests to token endpoint.

To avoid that the client should store the access token/refresh token and
use a refresh token when appropriate in case the access token has expired.
That is fine.

Now, suppose a confidential client is deployed and wants an access token. A
new session will be created on the server. In case the application goes
down for some reason (e.g.: container moved to a different node in
kubernetes and without a persistent volume) and tries to get a new access
token, we may end-up with two active sessions when asking for a new token
after a re-deploy.

What are your thoughts about re-using existing sessions when doing client
credentials ? What could be the impact on clustering if we need (and we'll
probably need) to update the session ?

Another question would be ... Does make sense to also enable clients to
obtain tokens without necessarily creating a session on the server ? I
think that in most cases, you don't really want to keep track of sessions
when doing client credentials.

Regards.
Pedro Igor


_______________________________________________
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 Joerg.Zaunegger at kvbawue.de  Wed Feb 13 12:21:38 2019
From: Joerg.Zaunegger at kvbawue.de (=?utf-8?B?WmF1bmVnZ2VyLCBKw7ZyZw==?=)
Date: Wed, 13 Feb 2019 17:21:38 +0000
Subject: [keycloak-dev] Client and Service Account Session
Message-ID: <8661B716A6678E46A20FB7FCFF2504A10129B6DB3A@VMSST107.kvbw.local>

Hi Thomas,

thanks. Of course I will give it a try.
Today I did also try to find a solution by myself.
Because we are using AccessTokens in our applications to access other applications, we will having the problem not only with spring-boot-admin. What do you think about caching the AccessTokenResponse.

If the AccessToken is not valid but the RefreshToken is, then we obtain a new AcessToken with that RefreshToken. If the RefreshToken is no longer valid, we obtain a new token with the credentials of the service account.
It seems to work. Do you see any problem with this solution?

Cheers J?rg

Von: Thomas Darimont <thomas.darimont at googlemail.com<mailto:thomas.darimont at googlemail.com>>
Gesendet: Mittwoch, 13. Februar 2019 16:27
An: Zaunegger, J?rg <Joerg.Zaunegger at kvbawue.de<mailto:Joerg.Zaunegger at kvbawue.de>>
Cc: keycloak-dev at lists.jboss.org<mailto:keycloak-dev at lists.jboss.org>
Betreff: Re: [keycloak-dev] Client and Service Account Session

Hello J?rg,

I built an example app that demonstrates this spring-boot-admin / Keycloak setup.

Would it help to use offline_tokens for the spring-boot-admin service account instead of normal refresh-tokens?

Unfortunately the Keycloak Admin client library currently does not support custom scopes like scope=offline_access.

I just pushed a PoC with patched offline_access support via a custom TokenManager. Would you mind giving it a try?
https://github.com/thomasdarimont/spring-boot-admin-keycloak-example/tree/poc/keycloak-offline-access

Cheers,
Thomas

Am Mi., 13. Feb. 2019 um 10:43 Uhr schrieb Zaunegger, J?rg <Joerg.Zaunegger at kvbawue.de<mailto:Joerg.Zaunegger at kvbawue.de>>:
Hi Pedro,

In our application we are securing spring-actuator endpoints with a keycloak role. These endpoints are requested repeatedly (every 5 s) by an application called spring-boot-admin<https://github.com/codecentric/spring-boot-admin>. For the request spring-boot-admin obtains an AccessToken. Because there is a session for each request, we have thousands of open sessions for the service account of spring-boot-admin.
Any news, suggestions or solutions on avoiding these open sessions?

Thanks.
J?rg Zaunegger

-----Urspr?ngliche Nachricht-----
Von: keycloak-user-bounces at lists.jboss.org<mailto:keycloak-user-bounces at lists.jboss.org><mailto:keycloak-user-bounces at lists.jboss.org<mailto:keycloak-user-bounces at lists.jboss.org>> <keycloak-user-bounces at lists.jboss.org<mailto:keycloak-user-bounces at lists.jboss.org><mailto:keycloak-user-bounces at lists.jboss.org<mailto:keycloak-user-bounces at lists.jboss.org>>> Im Auftrag von Pedro Igor Silva
Gesendet: Montag, 13. November 2017 09:52
An: 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>>
Betreff: RE: [keycloak-dev] Client and Service Account Session


Hi,

Currently, every time a confidential client tries to get a new access token
from the token endpoint a new session is created on the server. This can
lead to multiple active sessions for a single client/service account when
doing multiple requests to token endpoint.

To avoid that the client should store the access token/refresh token and
use a refresh token when appropriate in case the access token has expired.
That is fine.

Now, suppose a confidential client is deployed and wants an access token. A
new session will be created on the server. In case the application goes
down for some reason (e.g.: container moved to a different node in
kubernetes and without a persistent volume) and tries to get a new access
token, we may end-up with two active sessions when asking for a new token
after a re-deploy.

What are your thoughts about re-using existing sessions when doing client
credentials ? What could be the impact on clustering if we need (and we'll
probably need) to update the session ?

Another question would be ... Does make sense to also enable clients to
obtain tokens without necessarily creating a session on the server ? I
think that in most cases, you don't really want to keep track of sessions
when doing client credentials.

Regards.
Pedro Igor


_______________________________________________
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 sguilhen at redhat.com  Wed Feb 13 12:27:15 2019
From: sguilhen at redhat.com (Stefan Guilhen)
Date: Wed, 13 Feb 2019 15:27:15 -0200
Subject: [keycloak-dev] Why does client session expire regardless
 remember-me extended validity?
In-Reply-To: <685a0dff-80b9-ddd6-18ff-4847755204df@redhat.com>
References: <7637f53f-dd9b-2a3c-3816-a25d14ca189a@yahoo.de>
	<685a0dff-80b9-ddd6-18ff-4847755204df@redhat.com>
Message-ID: <CA+7ohf=nRhHaWhk7vOfRZ1j1fOHLUwNRsmS5KQiXv7PVabyk8g@mail.gmail.com>

It is possible that Ken is seeing something different. I will take a look
into it to be sure.

Best regards,
Stefan

On Wed, Feb 13, 2019, 13:43 Marek Posolda <mposolda at redhat.com wrote:

> We have PR open, which is related to that [1], but not sure if that PR
> fixes also your issue. It seems there is nothing related to client
> sessions. I am CCing Stefan in case he has some more to it.
>
> In the meantime, if you are curious if fix works, I suggest to
> cherry-pick Stefan's commit and build Keycloak and check if the
> behaviour is fixed with that PR.
>
> [1] https://github.com/keycloak/keycloak/pull/5852
>
> Marek
>
> On 13/02/2019 14:15, Ken Haendel wrote:
> > I have a problem authenticating a spring secured web-app using keycloak
> > 4.8.3.
> >
> > If the user logs in with remember-me enabled, the user session does use
> > a larger SSO max life span (ssoSessionMaxLifespanRememberMe).
> >
> > So far so good.
> >
> > Now i want to call another secured REST-API using the
> KeycloakRestService.
> >
> > That triggers OAuthRequestAuthenticator to verify token
> > (AdapterTokenVerifier.verifyTokens).
> >
> > That operation fails, because the client session expired much earlier
> > (after ssoSessionMaxLifespan). The client session gets removed from the
> > client session cache
> > (InfinispanUserSessionProvider.removeExpiredUserSessions).
> >
> > Error message of AdapterTokenVerifier.verifyTokens() is:
> >
> > "ERROR RefreshableKeycloakSecurityContext Refresh token failure status:
> > 400 {"error":"invalid_grant","error_description":"Session doesn't have
> > required client"}"
> >
> >
> > So, the point is: after the client session gets removed from cache (SSO
> > max life span) i can no longer use the refresh token to request new
> > tokens and call another REST-API service
> >
> > using the same identity as the web-app.
> >
> > Even though i have still a valid user session to use my spring app.
> >
> >
> > Expectation was: I can use refresh token within the larger time span
> > with remember-me enabled (SsoSessionMaxLifespanRememberMe).
> >
> > Actual behaviour is: Refresh token gets useless within the shorter time
> > span (ssoSessionMaxLifespan)
> >
> > Question: Why is the client session removed so early and not when the
> > user session expires? Is that expected behavoiur?
> >
> > Thank you in advance,
> >
> > Ken
> >
> >
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>

From slaskawi at redhat.com  Thu Feb 14 05:48:04 2019
From: slaskawi at redhat.com (Sebastian Laskawiec)
Date: Thu, 14 Feb 2019 11:48:04 +0100
Subject: [keycloak-dev] Running custom scripts in Keycloak container
	image
In-Reply-To: <CAA9R9O7BBjeMeXUd6YFkMs_YpDXeeq0g8TSzzzeT5n1ySgAVog@mail.gmail.com>
References: <CAA9R9O4-0-3D0pLyquAVjHN7qKb=NZosPH-iu51OA2oNXfM99A@mail.gmail.com>
	<CAK-7U1jdW-g4bcNbjoDG3yxST3rKHJXn+Zideed4EQTwWGWWew@mail.gmail.com>
	<CAJrcDBe+7RZ5iiOw_91o3NC9=c+QWrnBkEWixmxBeFQf=eR6cw@mail.gmail.com>
	<CAA9R9O7BBjeMeXUd6YFkMs_YpDXeeq0g8TSzzzeT5n1ySgAVog@mail.gmail.com>
Message-ID: <CAA9R9O6nZbdfqcJF7dehLFTK_rokE7MOYh9Vm0P6n-7MPprgXQ@mail.gmail.com>

So, are there any comments regarding to this?

If not, I'll add some suggestions to the PR and generally approve this
direction.

On Wed, Feb 13, 2019 at 2:53 PM Sebastian Laskawiec <slaskawi at redhat.com>
wrote:

> Yes, that's the idea how this can work.
>
> On Tue, Feb 12, 2019 at 4:19 PM Pedro Igor Silva <psilva at redhat.com>
> wrote:
>
>> Regarding the PR from Wouter. Instead of extending the image would be
>> possible to attach a volume with the scripts that need to be run on
>> startup? That would avoid the burden of creating a new image to only add a
>> few files into a directory.
>>
>> On Tue, Feb 12, 2019 at 12:37 PM Thomas Darimont <
>> thomas.darimont at googlemail.com> wrote:
>>
>>> Hello,
>>>
>>> I'm one of the maintainers of the Keycloak helm chart:
>>> https://github.com/helm/charts/tree/master/stable/keycloak
>>> Since a lot of our users need to adjust the default configuration that is
>>> provided by the Keycloak docker images, we currently generate a
>>> keycloak.cli file that we apply during start. However, some of this
>>> configuration is again overridden by the defaults from the Keycloak
>>> docker
>>> image.
>>>
>>> See:
>>>
>>> https://github.com/helm/charts/blob/master/stable/keycloak/templates/configmap.yaml#L12
>>> Configuration:
>>>
>>> https://github.com/helm/charts/blob/master/stable/keycloak/values.yaml#L121
>>>
>>> Having dedicated support for config customizations at bootstrap in the
>>> stock Keycloak image would make things much easier here :)
>>>
>>> Cheers,
>>> Thomas
>>>
>>> Am Di., 12. Feb. 2019 um 14:42 Uhr schrieb Sebastian Laskawiec <
>>> slaskawi at redhat.com>:
>>>
>>> > Hey guys,
>>> >
>>> > A while ago, one of our contributors, Wouter, sent an interesting pull
>>> > request: https://github.com/jboss-dockerfiles/keycloak/pull/176
>>> >
>>> > The aim is to allow running custom scripts just before Keycloak boots
>>> up
>>> > and after the main configuration is done. This allows a user to inject
>>> his
>>> > own scripts (even *.cli) into /opt/jboss/tools/docker-entrypoint.d and
>>> > execute them automatically.
>>> >
>>> > This is somewhat related to what the Integrately Team is doing. They
>>> > basically use an InitContainer [1] to put additional extensions into
>>> our
>>> > image. Perhaps with the proposed approach, they could embed a custom
>>> script
>>> > that would download whatever extensions they need and put them into the
>>> > deployments directory?
>>> >
>>> > After thinking about this for a while, and besides really good
>>> advantages
>>> > of the Pull Request, I have some doubts. The biggest one is about our
>>> > guarantees with regard the Keycloak distribution (by saying
>>> distribution I
>>> > mean the binaries, their structure and Keycloak server location in the
>>> > image). If we accept this approach, it will be pretty hard for us to
>>> change
>>> > any major thing (even some trivial things like the location of the
>>> Keycloak
>>> > Server) without breaking the client scripts.
>>> >
>>> > Personally, I'm slightly leaning towards accepting this feature, but
>>> with a
>>> > description in README, that the user scripts may break at any time and
>>> in
>>> > any version (maybe even we should print this message in our logs).
>>> This way
>>> > we'll make the contract for such scripts very clear.
>>> >
>>> > What do you think?
>>> >
>>> > Thanks,
>>> > Sebastian
>>> >
>>> > [1]
>>> https://kubernetes.io/docs/concepts/workloads/pods/init-containers/
>>> > _______________________________________________
>>> > 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 bruno at abstractj.org  Thu Feb 14 07:24:22 2019
From: bruno at abstractj.org (Bruno Oliveira)
Date: Thu, 14 Feb 2019 10:24:22 -0200
Subject: [keycloak-dev] Running custom scripts in Keycloak container
	image
In-Reply-To: <CAA9R9O6nZbdfqcJF7dehLFTK_rokE7MOYh9Vm0P6n-7MPprgXQ@mail.gmail.com>
References: <CAA9R9O4-0-3D0pLyquAVjHN7qKb=NZosPH-iu51OA2oNXfM99A@mail.gmail.com>
	<CAK-7U1jdW-g4bcNbjoDG3yxST3rKHJXn+Zideed4EQTwWGWWew@mail.gmail.com>
	<CAJrcDBe+7RZ5iiOw_91o3NC9=c+QWrnBkEWixmxBeFQf=eR6cw@mail.gmail.com>
	<CAA9R9O7BBjeMeXUd6YFkMs_YpDXeeq0g8TSzzzeT5n1ySgAVog@mail.gmail.com>
	<CAA9R9O6nZbdfqcJF7dehLFTK_rokE7MOYh9Vm0P6n-7MPprgXQ@mail.gmail.com>
Message-ID: <CAM5SUC7wRzA0_zB-Dn61oqO4emVBgwi71Cx1OJ+dcs2N76B-Ag@mail.gmail.com>

+1 on Pedro's comments. Other than that, let's add this.

On Thu, Feb 14, 2019 at 8:53 AM Sebastian Laskawiec <slaskawi at redhat.com> wrote:
>
> So, are there any comments regarding to this?
>
> If not, I'll add some suggestions to the PR and generally approve this
> direction.
>
> On Wed, Feb 13, 2019 at 2:53 PM Sebastian Laskawiec <slaskawi at redhat.com>
> wrote:
>
> > Yes, that's the idea how this can work.
> >
> > On Tue, Feb 12, 2019 at 4:19 PM Pedro Igor Silva <psilva at redhat.com>
> > wrote:
> >
> >> Regarding the PR from Wouter. Instead of extending the image would be
> >> possible to attach a volume with the scripts that need to be run on
> >> startup? That would avoid the burden of creating a new image to only add a
> >> few files into a directory.
> >>
> >> On Tue, Feb 12, 2019 at 12:37 PM Thomas Darimont <
> >> thomas.darimont at googlemail.com> wrote:
> >>
> >>> Hello,
> >>>
> >>> I'm one of the maintainers of the Keycloak helm chart:
> >>> https://github.com/helm/charts/tree/master/stable/keycloak
> >>> Since a lot of our users need to adjust the default configuration that is
> >>> provided by the Keycloak docker images, we currently generate a
> >>> keycloak.cli file that we apply during start. However, some of this
> >>> configuration is again overridden by the defaults from the Keycloak
> >>> docker
> >>> image.
> >>>
> >>> See:
> >>>
> >>> https://github.com/helm/charts/blob/master/stable/keycloak/templates/configmap.yaml#L12
> >>> Configuration:
> >>>
> >>> https://github.com/helm/charts/blob/master/stable/keycloak/values.yaml#L121
> >>>
> >>> Having dedicated support for config customizations at bootstrap in the
> >>> stock Keycloak image would make things much easier here :)
> >>>
> >>> Cheers,
> >>> Thomas
> >>>
> >>> Am Di., 12. Feb. 2019 um 14:42 Uhr schrieb Sebastian Laskawiec <
> >>> slaskawi at redhat.com>:
> >>>
> >>> > Hey guys,
> >>> >
> >>> > A while ago, one of our contributors, Wouter, sent an interesting pull
> >>> > request: https://github.com/jboss-dockerfiles/keycloak/pull/176
> >>> >
> >>> > The aim is to allow running custom scripts just before Keycloak boots
> >>> up
> >>> > and after the main configuration is done. This allows a user to inject
> >>> his
> >>> > own scripts (even *.cli) into /opt/jboss/tools/docker-entrypoint.d and
> >>> > execute them automatically.
> >>> >
> >>> > This is somewhat related to what the Integrately Team is doing. They
> >>> > basically use an InitContainer [1] to put additional extensions into
> >>> our
> >>> > image. Perhaps with the proposed approach, they could embed a custom
> >>> script
> >>> > that would download whatever extensions they need and put them into the
> >>> > deployments directory?
> >>> >
> >>> > After thinking about this for a while, and besides really good
> >>> advantages
> >>> > of the Pull Request, I have some doubts. The biggest one is about our
> >>> > guarantees with regard the Keycloak distribution (by saying
> >>> distribution I
> >>> > mean the binaries, their structure and Keycloak server location in the
> >>> > image). If we accept this approach, it will be pretty hard for us to
> >>> change
> >>> > any major thing (even some trivial things like the location of the
> >>> Keycloak
> >>> > Server) without breaking the client scripts.
> >>> >
> >>> > Personally, I'm slightly leaning towards accepting this feature, but
> >>> with a
> >>> > description in README, that the user scripts may break at any time and
> >>> in
> >>> > any version (maybe even we should print this message in our logs).
> >>> This way
> >>> > we'll make the contract for such scripts very clear.
> >>> >
> >>> > What do you think?
> >>> >
> >>> > Thanks,
> >>> > Sebastian
> >>> >
> >>> > [1]
> >>> https://kubernetes.io/docs/concepts/workloads/pods/init-containers/
> >>> > _______________________________________________
> >>> > keycloak-dev mailing list
> >>> > keycloak-dev at lists.jboss.org
> >>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>> >
> >>> _______________________________________________
> >>> keycloak-dev mailing list
> >>> keycloak-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>
> >>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



-- 
- abstractj

From kschwiersch at yahoo.de  Thu Feb 14 07:34:26 2019
From: kschwiersch at yahoo.de (Ken Haendel)
Date: Thu, 14 Feb 2019 13:34:26 +0100
Subject: [keycloak-dev] Why does client session expire regardless
 remember-me extended validity?
In-Reply-To: <CA+7ohf=nRhHaWhk7vOfRZ1j1fOHLUwNRsmS5KQiXv7PVabyk8g@mail.gmail.com>
References: <7637f53f-dd9b-2a3c-3816-a25d14ca189a@yahoo.de>
	<685a0dff-80b9-ddd6-18ff-4847755204df@redhat.com>
	<CA+7ohf=nRhHaWhk7vOfRZ1j1fOHLUwNRsmS5KQiXv7PVabyk8g@mail.gmail.com>
Message-ID: <c7d47317-2297-534c-8bc2-407a0da21a47@yahoo.de>

Hi Stefan, Marek


Thank you for your quick reply.

I have recently tested your pull request [1], if that fixes my issue 
with the expired client session cache and it does NOT. It only fixes an 
issue with the user session cache.

My proposal to fix that problem would be as follows (verified here):

diff --git 
a/model/infinispan/src/main/java/org/keycloak/models/sessions/infinispan/InfinispanUserSessionProvider.java 
b/model/infinispan/src/main/java/org/keycloak/models/sessions/infinispan/InfinispanUserSessionProvider.java
index b1429a6391..54cb244624 100755
--- 
a/model/infinispan/src/main/java/org/keycloak/models/sessions/infinispan/InfinispanUserSessionProvider.java
+++ 
b/model/infinispan/src/main/java/org/keycloak/models/sessions/infinispan/InfinispanUserSessionProvider.java
@@ -529,7 +529,7 @@ public class InfinispanUserSessionProvider 
implements UserSessionProvider {
 ???????? localClientSessionCacheStoreIgnore
 ???????????????? .entrySet()
 ???????????????? .stream()
- 
.filter(AuthenticatedClientSessionPredicate.create(realm.getId()).expired(expired))
+ 
.filter(AuthenticatedClientSessionPredicate.create(realm.getId()).expired(expiredRememberMe))


Using that change, the life span of the client session would be longer 
for remember-me logins.

Can you please check if that makes sense for you?

It would be nice if a fix could be added in the next releases to make it 
unnecessary to patch the further release :-)

Kind regards,

Ken


[1] https://github.com/keycloak/keycloak/pull/5852

Am 13.02.19 um 18:27 schrieb Stefan Guilhen:
> It is possible that Ken is seeing something different. I will take a 
> look into it to be sure.
>
> Best regards,
> Stefan
>
> On Wed, Feb 13, 2019, 13:43 Marek Posolda <mposolda at redhat.com 
> <mailto:mposolda at redhat.com> wrote:
>
>     We have PR open, which is related to that [1], but not sure if
>     that PR
>     fixes also your issue. It seems there is nothing related to client
>     sessions. I am CCing Stefan in case he has some more to it.
>
>     In the meantime, if you are curious if fix works, I suggest to
>     cherry-pick Stefan's commit and build Keycloak and check if the
>     behaviour is fixed with that PR.
>
>     [1] https://github.com/keycloak/keycloak/pull/5852
>
>     Marek
>
>     On 13/02/2019 14:15, Ken Haendel wrote:
>     > I have a problem authenticating a spring secured web-app using
>     keycloak
>     > 4.8.3.
>     >
>     > If the user logs in with remember-me enabled, the user session
>     does use
>     > a larger SSO max life span (ssoSessionMaxLifespanRememberMe).
>     >
>     > So far so good.
>     >
>     > Now i want to call another secured REST-API using the
>     KeycloakRestService.
>     >
>     > That triggers OAuthRequestAuthenticator to verify token
>     > (AdapterTokenVerifier.verifyTokens).
>     >
>     > That operation fails, because the client session expired much
>     earlier
>     > (after ssoSessionMaxLifespan). The client session gets removed
>     from the
>     > client session cache
>     > (InfinispanUserSessionProvider.removeExpiredUserSessions).
>     >
>     > Error message of AdapterTokenVerifier.verifyTokens() is:
>     >
>     > "ERROR RefreshableKeycloakSecurityContext Refresh token failure
>     status:
>     > 400 {"error":"invalid_grant","error_description":"Session
>     doesn't have
>     > required client"}"
>     >
>     >
>     > So, the point is: after the client session gets removed from
>     cache (SSO
>     > max life span) i can no longer use the refresh token to request new
>     > tokens and call another REST-API service
>     >
>     > using the same identity as the web-app.
>     >
>     > Even though i have still a valid user session to use my spring app.
>     >
>     >
>     > Expectation was: I can use refresh token within the larger time span
>     > with remember-me enabled (SsoSessionMaxLifespanRememberMe).
>     >
>     > Actual behaviour is: Refresh token gets useless within the
>     shorter time
>     > span (ssoSessionMaxLifespan)
>     >
>     > Question: Why is the client session removed so early and not
>     when the
>     > user session expires? Is that expected behavoiur?
>     >
>     > Thank you in advance,
>     >
>     > Ken
>     >
>     >
>     > _______________________________________________
>     > 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 psilva at redhat.com  Thu Feb 14 08:44:48 2019
From: psilva at redhat.com (Pedro Igor Silva)
Date: Thu, 14 Feb 2019 11:44:48 -0200
Subject: [keycloak-dev] UMA specs submitted to IETF
Message-ID: <CAJrcDBdLQ97AOrqy4LHGmwJxP9dzQkr==+KKM24k1TvmsJR6Kw@mail.gmail.com>

Hi,

The UMA work group did an important move this week by contributing [1] UMA
2.0 specs to IETF.

As an OAuth2 extension, UMA aims to leverage OAuth2 in order to support
asynchronous authorization, loosely coupled AS, clients and resource
servers (in regards to authorization to protected resources) as well as
give to resource owners more control over the permissions that govern
access to their protected resources.

Regards.
Pedro Igor

[1] https://mailarchive.ietf.org/arch/msg/oauth/r1mFPzQaXy322wSR3my5i1uCdXQ

From bruno at abstractj.org  Thu Feb 14 08:58:13 2019
From: bruno at abstractj.org (Bruno Oliveira)
Date: Thu, 14 Feb 2019 11:58:13 -0200
Subject: [keycloak-dev] [keycloak-user] UMA specs submitted to IETF
In-Reply-To: <CAJrcDBdLQ97AOrqy4LHGmwJxP9dzQkr==+KKM24k1TvmsJR6Kw@mail.gmail.com>
References: <CAJrcDBdLQ97AOrqy4LHGmwJxP9dzQkr==+KKM24k1TvmsJR6Kw@mail.gmail.com>
Message-ID: <CAM5SUC4LieOEwfhh7iUj6BHHX-McNXSFkYZTb_AHXSRC9mJ3Jg@mail.gmail.com>

That's great news!

On Thu, Feb 14, 2019 at 11:49 AM Pedro Igor Silva <psilva at redhat.com> wrote:
>
> Hi,
>
> The UMA work group did an important move this week by contributing [1] UMA
> 2.0 specs to IETF.
>
> As an OAuth2 extension, UMA aims to leverage OAuth2 in order to support
> asynchronous authorization, loosely coupled AS, clients and resource
> servers (in regards to authorization to protected resources) as well as
> give to resource owners more control over the permissions that govern
> access to their protected resources.
>
> Regards.
> Pedro Igor
>
> [1] https://mailarchive.ietf.org/arch/msg/oauth/r1mFPzQaXy322wSR3my5i1uCdXQ
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user



-- 
- abstractj

From Sebastian.Loesch at governikus.de  Thu Feb 14 10:01:13 2019
From: Sebastian.Loesch at governikus.de (=?utf-8?B?TMO2c2NoLCBTZWJhc3RpYW4=?=)
Date: Thu, 14 Feb 2019 15:01:13 +0000
Subject: [keycloak-dev] Certificate subject DN is provider dependent
In-Reply-To: <fce91aa8449f4027be04ee29367866b1@BOSKGEXC01.boskg.local>
References: <76d2854ebcf943a39f30f2ba4891984c@BOSKGEXC01.boskg.local>
	<CAK-7U1hLTOg2pFX0WyXLE+PmtZLAOYwSovprKq_W8j5LusKreQ@mail.gmail.com>
	<CAJrcDBedQeK35-E5g1Ru9aMyUBQ5LjJ_6=iGWKCKFL4O1nXeNw@mail.gmail.com>
	<CAJrcDBearA9dmhWxLYO6zX07SxELQkr0Y_upFdOjXcd_4-BUzw@mail.gmail.com>
	<99d26631531742279d851c74850fe737@BOSKGEXC01.boskg.local>
	<CAJrcDBcfLnqDbApUPan--n9CW=dNLdRo_eJYfmCn5ihWtbBrDw@mail.gmail.com>
	<CAMvXD=Fovok=OkNDH2iPMukSw2z-sdTA5Wi-VGOY4JADhnW0AA@mail.gmail.com>
	<CAJrcDBeeGShDpktMzJO7NfUV6L6i-rgb4QPxgLr5yfxyd-PjkQ@mail.gmail.com>
	<3e3b522e-d435-a197-8792-72caf35254ca@redhat.com>
	<CAJrcDBfTRmtOaw19vfZ2PMM8HXbHeqv2yFxBAkKmh8apYbYXCQ@mail.gmail.com>
	<29ac8ce8-cbd8-6021-11b7-5104d369d578@redhat.com>
	<CAJrcDBf0MVuqdR6W6vF8EUf2jWN=TYK5+kzWqS+egVF9VOsgSA@mail.gmail.com>
	<76df2c03-1db9-19df-7220-99476748b1d8@redhat.com>
	<CAJrcDBeKbZhFzQpJfubr-swP3h8q4_EpT-JuAgXZ=PGSYF0ozA@mail.gmail.com>
	<786a08d034b24fb5bc1b3dddcbc2b42d@BOSKGEXC01.boskg.local>
	<CAJrcDBduVAxkUV_vuHxkRYXzNjPEKKg+RLePonMgAqZ+2gY_pA@mail.gmail.com>
	<63e7999724b040098b4449b1fd559c0b@BOSKGEXC01.boskg.local>
	<CAJrcDBeyJiy8Yyy554L5hcuB3XMVEQX5sz4-5DKCXmNRee=w2Q@mail.gmail.com>
	<fce91aa8449f4027be04ee29367866b1@BOSKGEXC01.boskg.local>
Message-ID: <558037418a93496fbc2147695f1e20b8@BOSKGEXC01.boskg.local>

Hello devs,

I implemented tests and added documentation. So please have a look if something is missing:
https://github.com/keycloak/keycloak/pull/5878
https://github.com/keycloak/keycloak-documentation/pull/587

Best regards,
Sebastian

> -----Urspr?ngliche Nachricht-----
> Von: keycloak-dev-bounces at lists.jboss.org <keycloak-dev-
> bounces at lists.jboss.org> Im Auftrag von L?sch, Sebastian
> Gesendet: Mittwoch, 13. Februar 2019 16:27
> An: psilva at redhat.com
> Cc: keycloak-dev at lists.jboss.org
> Betreff: Re: [keycloak-dev] Certificate subject DN is provider dependent
> 
> Okay, that sound?s great! I will work on that soon.
> 
> Thanks.
> 
> Von: Pedro Igor Silva <psilva at redhat.com>
> Gesendet: Mittwoch, 13. Februar 2019 16:24
> An: L?sch, Sebastian <Sebastian.Loesch at governikus.de>
> Cc: jdennis at redhat.com; keycloak-dev at lists.jboss.org
> Betreff: Re: [keycloak-dev] Certificate subject DN is provider dependent
> 
> 
> 
> I meant, use the BC API directly without depending on the installed provider.
> If you look at how those identity extractors are implemented, you'll see that
> some of them are using BC API. Not sure if this approach is good though as
> we are removing the "portability" through JCA/JCE. In fact, I think use BC for
> extracting DN will make things even more worse for the problem discussed in
> the other thread ...
> 
> 
> 
> Back to your question, I'm OK about your PR and I'm not sure if we need
> those two alternatives you proposed. The example you gave about
> serialnumber does not seem to be impacted by canonicalization. Or I'm
> missing something ? If others are happy too about your solution, we can
> have your changes in as soon as you provide tests and docs.
> 
> 
> 
> Thanks.
> 
> 
> 
> On Wed, Feb 13, 2019 at 12:13 PM L?sch, Sebastian
> <Sebastian.Loesch at governikus.de
> <mailto:Sebastian.Loesch at governikus.de> > wrote:
> 
> The provider that generates the certificate contained in the HttpRequest ist
> he default security provider of the application server. So using the same
> provider means using the default provider.
> 
> That may lead to problems when the default security provider changes, as
> the DN format changes at this time as well.
> 
> 
> 
> 
> 
> Von: Pedro Igor Silva <psilva at redhat.com <mailto:psilva at redhat.com> >
> Gesendet: Mittwoch, 13. Februar 2019 13:08
> An: L?sch, Sebastian <Sebastian.Loesch at governikus.de
> <mailto:Sebastian.Loesch at governikus.de> >
> Cc: jdennis at redhat.com <mailto:jdennis at redhat.com> ; keycloak-
> dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
> Betreff: Re: [keycloak-dev] Certificate subject DN is provider dependent
> 
> 
> 
> What if we use the same provider in all those identity extractors? As it stands
> today, it is a mix of BC and JDK.
> 
> 
> 
> 
> 
> On Wed, Feb 13, 2019 at 3:37 AM L?sch, Sebastian
> <Sebastian.Loesch at governikus.de
> <mailto:Sebastian.Loesch at governikus.de> > wrote:
> 
> The main point on this issue in my opinion is to have a reliable, provider
> independent DN representation.
> This is not given using the currently used Java API
> X509Certificate.getSubjectDN() and X509Certificate.getIssuerDN().
> The JavaDoc states here the result is "[...]an implementation specific Principal
> object, which should not be relied upon by portable code."
> So I think providing an alternative is necessary.
> 
> I am wondering if this canonical config switch ON/OFF is the right way. It has
> no effect on all other user identity source, e.g. serial number.
> Wouldn't it be better to implement two alternatives "Match canonical
> IssuerDN using regular expression" and "Match canonical SubjectDN using
> regular expression"?
> The existing solutions are kept for backward compatibility but deprecated in
> the documentation?
> 
> Best regards,
> Sebastian
> 
> > -----Urspr?ngliche Nachricht-----
> > Von: keycloak-dev-bounces at lists.jboss.org <mailto:keycloak-dev-
> bounces at lists.jboss.org>  <keycloak-dev-
> > bounces at lists.jboss.org <mailto:bounces at lists.jboss.org> > Im Auftrag
> von Pedro Igor Silva
> > Gesendet: Mittwoch, 13. Februar 2019 00:03
> > An: John Dennis <jdennis at redhat.com <mailto:jdennis at redhat.com> >
> > Cc: keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
> > Betreff: Re: [keycloak-dev] Certificate subject DN is provider dependent
> >
> > On Tue, Feb 12, 2019 at 8:17 PM John Dennis <jdennis at redhat.com
> <mailto:jdennis at redhat.com> > wrote:
> >
> > > On 2/12/19 4:26 PM, Pedro Igor Silva wrote:
> > > > Sure, but note that RFC-4514 relies on 4519 (which actually defines
> > > > the supported attributed types).
> > >
> > > I don't think RFC 4519 is what you're looking for, you want to be
> > > looking at the X509 Certificate RFC's.
> > >
> > > Ugh, the RFC's for this stuff is a tangled mess of cross references to
> > > other RFC's. It's ugly and hard to decipher which is probably why
> > > these issues seem to keep cropping up.
> > >
> >
> > Yes, they are ...
> >
> >
> > >
> > > > The main reason for pushing this question is that from a security
> > > > perspective, using a deprecated attribute type in subject dn is not
> > > > good. Privacy concerns may apply here too where you may not want
> > > > people to put the email (sensitive) in something that is supposed to be
> public.
> > >
> > > I'm not sure that's the question. You don't have control over the
> > > certs that are presented to you. Rather your job is to ascertain if
> > > you can unequivocally map the cert subject to a principal in your
> > > domain. You probably can't put a stake in the ground and demand the
> > > subject contain certain RDN's (with the exception of the CN). And FWIW
> > > just to make things even more confusing a common convention for client
> > > certs is to put the users email address as the subject's CN.
> > >
> > > I have a suggestion, I'm not the ultimate authority on this stuff. We
> > > have a developer on the Certificate Server team who I believe has an
> > > even more in depth understanding and is probably more current on this
> > > topic that I am (I did this work several years ago). He is Fraser
> > > Tweedale <ftweedal at redhat.com <mailto:ftweedal at redhat.com> >,
> perhaps you might want to open a
> > > discussion with him. FWIW the Certificate Server is also written in
> > > Java and he might be able to share Java code snippets with you on the
> > > best way to perform these comparisons.
> > >
> >
> > Yeah, we can not control how people are issuing certificates. I was trying to
> find
> > someone to say "Yeah, emailAddress is really a bad practice in subject dn.
> > People should use SAN instead".
> >
> > I think your contact may help here with both issues, for sure. Although I'm
> > convinced that at least the changes made in that PR are fine instead of
> possibly
> > breaking use cases by forcing canonicalization.
> >
> >
> > >
> > >
> > > --
> > > John Dennis
> > >
> > _______________________________________________
> > 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 sguilhen at redhat.com  Thu Feb 14 20:57:58 2019
From: sguilhen at redhat.com (Stefan Guilhen)
Date: Thu, 14 Feb 2019 23:57:58 -0200
Subject: [keycloak-dev] Why does client session expire regardless
 remember-me extended validity?
In-Reply-To: <c7d47317-2297-534c-8bc2-407a0da21a47@yahoo.de>
References: <7637f53f-dd9b-2a3c-3816-a25d14ca189a@yahoo.de>
	<685a0dff-80b9-ddd6-18ff-4847755204df@redhat.com>
	<CA+7ohf=nRhHaWhk7vOfRZ1j1fOHLUwNRsmS5KQiXv7PVabyk8g@mail.gmail.com>
	<c7d47317-2297-534c-8bc2-407a0da21a47@yahoo.de>
Message-ID: <CA+7ohfm=GbNpnhLpSNDjHmnoR_5oc=utZe09JP41iqVgvMdKQw@mail.gmail.com>

Hi Ken,

Yes, it does make sense to me to use the remember-me value for the client
session as well. Marek, WDYT? Should we open a new Jira just for this or
can I just amend the commit to include this fix too?

Stefan

On Thu, Feb 14, 2019 at 10:34 AM Ken Haendel <kschwiersch at yahoo.de> wrote:

> Hi Stefan, Marek
>
>
> Thank you for your quick reply.
>
> I have recently tested your pull request [1], if that fixes my issue with
> the expired client session cache and it does NOT. It only fixes an issue
> with the user session cache.
>
> My proposal to fix that problem would be as follows (verified here):
>
> diff --git
> a/model/infinispan/src/main/java/org/keycloak/models/sessions/infinispan/InfinispanUserSessionProvider.java
> b/model/infinispan/src/main/java/org/keycloak/models/sessions/infinispan/InfinispanUserSessionProvider.java
> index b1429a6391..54cb244624 100755
> ---
> a/model/infinispan/src/main/java/org/keycloak/models/sessions/infinispan/InfinispanUserSessionProvider.java
> +++
> b/model/infinispan/src/main/java/org/keycloak/models/sessions/infinispan/InfinispanUserSessionProvider.java
> @@ -529,7 +529,7 @@ public class InfinispanUserSessionProvider implements
> UserSessionProvider {
>          localClientSessionCacheStoreIgnore
>                  .entrySet()
>                  .stream()
> -
> .filter(AuthenticatedClientSessionPredicate.create(realm.getId()).expired(expired))
> +
> .filter(AuthenticatedClientSessionPredicate.create(realm.getId()).expired(expiredRememberMe))
>
>
> Using that change, the life span of the client session would be longer for
> remember-me logins.
>
> Can you please check if that makes sense for you?
>
> It would be nice if a fix could be added in the next releases to make it
> unnecessary to patch the further release :-)
>
> Kind regards,
>
> Ken
>
>
> [1] https://github.com/keycloak/keycloak/pull/5852
> Am 13.02.19 um 18:27 schrieb Stefan Guilhen:
>
> It is possible that Ken is seeing something different. I will take a look
> into it to be sure.
>
> Best regards,
> Stefan
>
> On Wed, Feb 13, 2019, 13:43 Marek Posolda <mposolda at redhat.com wrote:
>
>> We have PR open, which is related to that [1], but not sure if that PR
>> fixes also your issue. It seems there is nothing related to client
>> sessions. I am CCing Stefan in case he has some more to it.
>>
>> In the meantime, if you are curious if fix works, I suggest to
>> cherry-pick Stefan's commit and build Keycloak and check if the
>> behaviour is fixed with that PR.
>>
>> [1] https://github.com/keycloak/keycloak/pull/5852
>>
>> Marek
>>
>> On 13/02/2019 14:15, Ken Haendel wrote:
>> > I have a problem authenticating a spring secured web-app using keycloak
>> > 4.8.3.
>> >
>> > If the user logs in with remember-me enabled, the user session does use
>> > a larger SSO max life span (ssoSessionMaxLifespanRememberMe).
>> >
>> > So far so good.
>> >
>> > Now i want to call another secured REST-API using the
>> KeycloakRestService.
>> >
>> > That triggers OAuthRequestAuthenticator to verify token
>> > (AdapterTokenVerifier.verifyTokens).
>> >
>> > That operation fails, because the client session expired much earlier
>> > (after ssoSessionMaxLifespan). The client session gets removed from the
>> > client session cache
>> > (InfinispanUserSessionProvider.removeExpiredUserSessions).
>> >
>> > Error message of AdapterTokenVerifier.verifyTokens() is:
>> >
>> > "ERROR RefreshableKeycloakSecurityContext Refresh token failure status:
>> > 400 {"error":"invalid_grant","error_description":"Session doesn't have
>> > required client"}"
>> >
>> >
>> > So, the point is: after the client session gets removed from cache (SSO
>> > max life span) i can no longer use the refresh token to request new
>> > tokens and call another REST-API service
>> >
>> > using the same identity as the web-app.
>> >
>> > Even though i have still a valid user session to use my spring app.
>> >
>> >
>> > Expectation was: I can use refresh token within the larger time span
>> > with remember-me enabled (SsoSessionMaxLifespanRememberMe).
>> >
>> > Actual behaviour is: Refresh token gets useless within the shorter time
>> > span (ssoSessionMaxLifespan)
>> >
>> > Question: Why is the client session removed so early and not when the
>> > user session expires? Is that expected behavoiur?
>> >
>> > Thank you in advance,
>> >
>> > Ken
>> >
>> >
>> > _______________________________________________
>> > 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 james.p.campbell at gmail.com  Thu Feb 14 21:32:49 2019
From: james.p.campbell at gmail.com (James Campbell)
Date: Thu, 14 Feb 2019 21:32:49 -0500
Subject: [keycloak-dev] OIDC Discovery-enabled IdentityProvider
In-Reply-To: <CAJgngAdyEzhrx5Zk9DQH6Gd5xwjTxkGaP2WaZGmmEmCUj5jC=A@mail.gmail.com>
References: <00aa01d4ac7b$a7767460$f6635d20$@gmail.com>
	<1914838141.50603473.1547562353763.JavaMail.zimbra@redhat.com>
	<38415268.50625497.1547566301029.JavaMail.zimbra@redhat.com>
	<CA+AQu3yKjkTU2XCaiE1-xbfyn3idiswk5OWSsLxNnZRKsMFJWA@mail.gmail.com>
	<CAJgngAccFbcFOE4Dt4v=R-WXky9mdmGPZqzDvwi3AthrBLOjvQ@mail.gmail.com>
	<CA+AQu3waQr+Zdm1kA_PwoghNfcDzzhttc56saxTEhhxRXwy7Eg@mail.gmail.com>
	<CAJgngAeJn1jSQRk-7yZzaYfDTYE_Ww5pE9MgyumPCkSfYa4tQw@mail.gmail.com>
	<CA+AQu3yuSeN+pOFRwuDR-2CdNvNVPjoHv=xEmTNS5pHHv1qR8Q@mail.gmail.com>
	<CA+AQu3z4JTTSCQU0g9m5VV5SFYUk92-sA1hqT-AedPZRotmcCw@mail.gmail.com>
	<CAJgngAf-w-=Pwvu0JLGkAJ0ipPs9v8noPUdbkvsiG52RobKGSA@mail.gmail.com>
	<CA+AQu3zu8KXvtGVJLgHxZ+dno-5f9tBYgd6UU5NJGOXBAZjT=w@mail.gmail.com>
	<CAJgngAdyEzhrx5Zk9DQH6Gd5xwjTxkGaP2WaZGmmEmCUj5jC=A@mail.gmail.com>
Message-ID: <CA+AQu3wgT4B1+Msva=9DOp=Po-s7GDCapY1+Gs-E4q_cE+jR2g@mail.gmail.com>

Thanks, Stian--the more detailed documentation inside the
integration-arquillian folder helped understand the tests better.

I've been able to read through a lot more on the tests, and I thought I had
a picture of how to extend the current tests, but when I tried directly it
seems that there must be configuration elements of the testing
infrastructure itself that I'm not finding. Specifically, the code I added
uses a new Infinispan cache to hold the configs, and I have been able to
successfully test it via a manual build and run of keycloak. However,
running inside the test harness gives me an error that the cache is not
configured. I suspect I just don't know where the relevant XML and/or
DeploymentProcessors are located for the testing framework.

If there's a path to making the work I did useful, I'm game for it, but I'd
need some more hints I'm sure to make it through the proper implementation
of the tests.

James



On Wed, Feb 6, 2019 at 5:30 AM Stian Thorgersen <sthorger at redhat.com> wrote:

>
>
> On Wed, 6 Feb 2019 at 02:27, James Campbell <james.p.campbell at gmail.com>
> wrote:
>
>> Inline...
>>
>> On Tue, Feb 5, 2019 at 3:45 AM Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>>
>>>
>>>
>>> On Mon, 4 Feb 2019 at 05:14, James Campbell <james.p.campbell at gmail.com>
>>> wrote:
>>>
>>>> All--
>>>>
>>>> Thanks to Stian's recommendations for similar features in the codebase,
>>>> I've developed a proposal for how to implement this feature, and sketched
>>>> out an initial implementation. As he suggested, I'd like to get feedback
>>>> before opening up a PR.
>>>>
>>>> 1. We introduce a new subclass of the OIDCIdentityProvider / Factory
>>>> called OIDCDiscoveryIdentityProvider. The new class adds a discoverConfig
>>>> method that can be used to discover and set all relevant endpoints in a
>>>> configuration except the issuer. Issuer then becomes the sole required
>>>> element of the config. (So the GoogleIdentityProvider, for example, will
>>>> then just call discoverConfig with its hard-coded issuer).
>>>>    -> During the parseConfig call, the Factory will raise a
>>>> RuntimeException if the config cannot be obtained, since if the config can
>>>> never be obtained there is no way to have a valid configuration at all.
>>>>    -> During the discoverConfig call, we return the cached value, and
>>>> optionally refresh it based on when we last obtained the configuration.
>>>>    -> In the event of a failure in the *refresh* I'm imagining the best
>>>> behavior is to log a warning but then return the cached config (last known
>>>> good config).
>>>>
>>>
>>> This should just be added to the OIDCIdentityProvider directly rather
>>> than a subclass. Perhaps we should have an option to configure how
>>> frequently the configuration is reloaded.
>>>
>>
>> Makes sense, thank you.
>>
>>
>>>
>>>> 2. We introduce an SPI and interface called
>>>> OIDCDiscoveryRepresentationProvider / Factory and implementations called
>>>> Infinispan... which obtains OIDCConfigurationRepresentations using the
>>>> /.well-known/openid-configuration endpoint on the issuer.
>>>>
>>>> I have a couple questions:
>>>>
>>>> 1. I began an implementation of this, but the @JsonProperty annotations
>>>> on the existing OIDCCOnfigurationRepresentation class seem to be ignored
>>>> when I try to have it read from the openid-configuration docuement, e.g.:
>>>>   - OIDCConfigurationRepresentation rep = SimpleHttp.doGet(issuer +
>>>> "/.well-known/openid-configuration",
>>>> session).asJson(OIDCConfigurationRepresentation.class); // FAILS with
>>>> "Unrecognized field ..." Perhaps a mismatch of the jackson annotation
>>>> version in the keycloak-model-infinispan submodule?
>>>>
>>>
>>> Is the unknown field actually mapped or is the ignore unknown fields
>>> option enabled? The ignore unknown fields should probably be enabled as
>>> there may be unknown elements in the config.
>>>
>>
>> The unknown field in this case was authorization_endpoint (so yes,
>> mapped, and in code that I did not change). I wondered whether perhaps the
>> issue is that I was doing this from inside the keycloak-model-infinispan
>> module, and a conflicting JSON parser dependency is in play? I did try
>> adding the @JsonIgnoreProperties annotation as well, to no avail. My
>> suspicion is just based on (1) the current class correctly supporting
>> deserialization in existing tests, and (2) a search of common causes for
>> this error (which I've not encountered before).
>>
>
> Is this from unit tests within the keycloak-model-infinispan module or
> test in the Arquillian testsuite? If the latter it should pick up the
> correct serializer. It has to be the fasterxml one otherwise the
> annotations will be ignored.
>
>
>>
>>
>>>
>>>
>>>>
>>>> 2. Assuming the design above makes sense, what is the right way to plug
>>>> this into the testing framework? Is one of the core developers interested
>>>> in tackling that aspect if I push a PR with the above features implemented?
>>>>
>>>
>>> We are very reluctant to receive PRs from the community that do not
>>> include tests. Think about it, would you as a developer like to implement
>>> tests for other developers? We can help give you recommendations on how to
>>> test it though.
>>>
>>>
>>
>> Definitely makes sense; I just didn't see any documentation on the
>> testing framework at all, whereas there is documentation on the core server
>> development components. Happy to either take a look at docs you flag, or to
>> work from any recommendations you have (I certainly wasn't thinking a PR
>> would be ready without tests!). The current testing system is pretty opaque
>> to me.
>>
>
> We have an Arquillian based testsuite that allows us to write functional
> tests with all the benefits of unit tests. The testsuite allows running
> tests from within the IDE (uses Keycloak with an embedded Undertow server)
> and also run them against a proper built Keycloak on top of WildFly from
> the command line.
>
> Some details are here:
>
> https://github.com/keycloak/keycloak/tree/master/testsuite/integration-arquillian
>
> To understand how to write the tests and run them try to run any test
> inside testsuite/integration-arquillian/tests/base/src/test from the IDE.
>
> Identity brokering tests are under
> testsuite/integration-arquillian/tests/base/src/test/java/org/keycloak/testsuite/broker.
> You should be able to relatively easily extend these tests to include
> testing of OIDC well-known endpoints. We also have support in the testsuite
> to run code directly on the server (embedded or external) to be able to
> probe inside the server if needed. Take a look at
> https://github.com/keycloak/keycloak/blob/master/testsuite/integration-arquillian/tests/base/src/test/java/org/keycloak/testsuite/runonserver/RunOnServerTest.java
> as an example on how to do that.
>
>
>
>>
>>
>>
>>>
>>>> James
>>>>
>>>> On Sun, Jan 27, 2019 at 11:15 AM James Campbell <
>>>> james.p.campbell at gmail.com> wrote:
>>>>
>>>>> Got it; I checked that code out and it does look like a pretty direct
>>>>> model for the refreshing feature. I'll begin working on a PR.
>>>>>
>>>>> On Mon, Jan 21, 2019 at 3:25 AM Stian Thorgersen <sthorger at redhat.com>
>>>>> wrote:
>>>>>
>>>>>> JWKs used by identity brokering and client authentication.
>>>>>>
>>>>>> On Sat, 19 Jan 2019 at 23:29, James Campbell <
>>>>>> james.p.campbell at gmail.com> wrote:
>>>>>>
>>>>>>> Stian--
>>>>>>>
>>>>>>> Thanks for confirming. Which keys are you referring to--I'll take a
>>>>>>> look at that in the code and try to follow that pattern closely.
>>>>>>>
>>>>>>> James
>>>>>>>
>>>>>>> On Wed, Jan 16, 2019 at 1:52 AM Stian Thorgersen <
>>>>>>> sthorger at redhat.com> wrote:
>>>>>>>
>>>>>>>> It would be good to get these changes included. We do something
>>>>>>>> similar for the keys today and they are cached in an Infinispan local
>>>>>>>> cache. Could do something similar for the OIDC discovery/config.
>>>>>>>>
>>>>>>>> On Tue, 15 Jan 2019 at 17:44, James Campbell <
>>>>>>>> james.p.campbell at gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Tomas--
>>>>>>>>>
>>>>>>>>> Thanks--it certainly seems close, you're right! It looks, however
>>>>>>>>> like an
>>>>>>>>> OIDC provider still uses a static configuration even though it
>>>>>>>>> loads it
>>>>>>>>> from the discovery URL--that is, once it's loaded at configuraiton
>>>>>>>>> time, it
>>>>>>>>> doesn't discover new changes, and there isn't an option to
>>>>>>>>> refresh/store
>>>>>>>>> that discovery endpoint outside of configuration.
>>>>>>>>>
>>>>>>>>> It's not clear to me how important that feature is--on one hand,
>>>>>>>>> it seems
>>>>>>>>> unlikely that we should expect frequent changes; on the other, in
>>>>>>>>> the short
>>>>>>>>> time since I started exploring this setup, I have encountered
>>>>>>>>> three changes
>>>>>>>>> in google's OIDC endpoints between what was hard-coded into
>>>>>>>>> keycloak, what
>>>>>>>>> is in their documentation, and what their current discovery
>>>>>>>>> endpoint
>>>>>>>>> provides. (And, the google docs specifically suggest refreshing
>>>>>>>>> from the
>>>>>>>>> endpoint periodically).
>>>>>>>>>
>>>>>>>>> Thoughts?
>>>>>>>>>
>>>>>>>>> James
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Tue, Jan 15, 2019 at 10:31 AM Tomas Kyjovsky <
>>>>>>>>> tkyjovsk at redhat.com> wrote:
>>>>>>>>>
>>>>>>>>> > Please disregard my previous message.
>>>>>>>>> >
>>>>>>>>> > Looking at the docs [1] and the Admin Console UI this should be
>>>>>>>>> already
>>>>>>>>> > possible with the OIDC identity provider.
>>>>>>>>> > When creating a OIDC identity provider in the Admin Console
>>>>>>>>> there is an
>>>>>>>>> > option at the bottom of the page to import OIDC configuration
>>>>>>>>> metadata from
>>>>>>>>> > URL.
>>>>>>>>> >
>>>>>>>>> > Does this cover your use case?
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> > Regards,
>>>>>>>>> > Tomas
>>>>>>>>> >
>>>>>>>>> > [1]
>>>>>>>>> >
>>>>>>>>> https://www.keycloak.org/docs/latest/server_admin/index.html#openid-connect-v1-0-identity-providers
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> > ----- Original Message -----
>>>>>>>>> > > Hello James,
>>>>>>>>> > >
>>>>>>>>> > > See my 2 cents inline..
>>>>>>>>> > >
>>>>>>>>> > > ----- Original Message -----
>>>>>>>>> > > > All--
>>>>>>>>> > > >
>>>>>>>>> > > >
>>>>>>>>> > > >
>>>>>>>>> > > > After observing that the Google Social Identity Provider in
>>>>>>>>> Keycloak
>>>>>>>>> > was
>>>>>>>>> > > > using a deprecated userprofile endpoint [
>>>>>>>>> > > > <
>>>>>>>>> https://issues.jboss.org/projects/KEYCLOAK/issues/KEYCLOAK-9179>
>>>>>>>>> > > > Keycloak-9179,  <
>>>>>>>>> https://issues.jboss.org/browse/KEYCLOAK-9169>
>>>>>>>>> > > > Keycloak-9169], I wanted to propose the creation of an
>>>>>>>>> IdentityProvider
>>>>>>>>> > > > that
>>>>>>>>> > > > will use the OIDC Discovery mechanism to dynamically build a
>>>>>>>>> config [
>>>>>>>>> > > > <https://issues.jboss.org/browse/KEYCLOAK-9194>
>>>>>>>>> Keycloak-9194].
>>>>>>>>> > > >
>>>>>>>>> > > >
>>>>>>>>> > > >
>>>>>>>>> > > > I see a few decision points along the way that I wanted to
>>>>>>>>> ask about
>>>>>>>>> > before
>>>>>>>>> > > > an implementation, since I'm very new to keycloak and just
>>>>>>>>> starting to
>>>>>>>>> > > > understand the codebase. In particular, I wondered if this
>>>>>>>>> group could
>>>>>>>>> > > > share
>>>>>>>>> > > > insight into these couple issues so I can make a more
>>>>>>>>> informed design:
>>>>>>>>> > > >
>>>>>>>>> > > >
>>>>>>>>> > > >
>>>>>>>>> > > > 1.    It looks to me like the actual IdentityProviders are
>>>>>>>>> instantiated
>>>>>>>>> > > > just
>>>>>>>>> > > > as they're being used, but that the models are persisted in
>>>>>>>>> the
>>>>>>>>> > RealmModel.
>>>>>>>>> > > > It's not clear to me where the separation of concerns is
>>>>>>>>> supposed to be
>>>>>>>>> > > > between the IdentityProvider and the IdentityProviderModel-in
>>>>>>>>> > particular
>>>>>>>>> > > > since the GoogeIdentityProvider, say, immediately sets
>>>>>>>>> endpoints in its
>>>>>>>>> > > > constructor. Normatively, where *should* social identity
>>>>>>>>> providers'
>>>>>>>>> > model
>>>>>>>>> > > > configuration be set (and, e.g., where are the models first
>>>>>>>>> added to
>>>>>>>>> > the
>>>>>>>>> > > > RealmModel)?
>>>>>>>>> > >
>>>>>>>>> > > Provider classes are being instantiated per transaction by
>>>>>>>>> their
>>>>>>>>> > > corresponding ProviderFactories and then left to be
>>>>>>>>> garbage-collected
>>>>>>>>> > after
>>>>>>>>> > > Provider.close() is called.
>>>>>>>>> > > The Provider class is given its configuration
>>>>>>>>> (IdentityProviderModel in
>>>>>>>>> > this
>>>>>>>>> > > case) by its factory which I believe loads it from cache/jpa
>>>>>>>>> layer. Any
>>>>>>>>> > > class extending AbstractIdentityProvider should then be able
>>>>>>>>> to access
>>>>>>>>> > its
>>>>>>>>> > > config via getConfig() method but I don't think it will be
>>>>>>>>> able to
>>>>>>>>> > > update/persist it back. The provider configuration/model
>>>>>>>>> itself is
>>>>>>>>> > managed
>>>>>>>>> > > by the IdentityProviderResource (REST endpoint accessible via
>>>>>>>>> REST or
>>>>>>>>> > admin
>>>>>>>>> > > console UI) in the keycloak/services module so I think the
>>>>>>>>> > > auto-configuration logic would have to be placed somewhere
>>>>>>>>> there.
>>>>>>>>> > >
>>>>>>>>> > > >
>>>>>>>>> > > >
>>>>>>>>> > > >
>>>>>>>>> > > > 2.    I see that there is logic to parse OIDC Discovery
>>>>>>>>> configuration
>>>>>>>>> > as
>>>>>>>>> > > > part of configuring Keycloak itself as an OIDC provider /
>>>>>>>>> implementer
>>>>>>>>> > of
>>>>>>>>> > > > OIDC protocol (including building and parsing the
>>>>>>>>> .well-known config
>>>>>>>>> > > > elements), but that logic seems not to be used in any setting
>>>>>>>>> > currently as
>>>>>>>>> > > > a
>>>>>>>>> > > > client. Should I plan to reuse, say, the
>>>>>>>>> > OIDCConfigurationRepresentation
>>>>>>>>> > > > and
>>>>>>>>> > > > OIDCWellKnownProvider classes for their logic in handling
>>>>>>>>> such configs?
>>>>>>>>> > > >
>>>>>>>>> > > >
>>>>>>>>> > > >
>>>>>>>>> > > >
>>>>>>>>> > > >
>>>>>>>>> > > > Currently, I'm imagining something along the lines of
>>>>>>>>> extending
>>>>>>>>> > > > OIDCIdentityProvider with a new
>>>>>>>>> OIDCDiscoveryIdentityProvider that
>>>>>>>>> > adds a
>>>>>>>>> > > > discoverConfig method which can be used by an implementing
>>>>>>>>> class (such
>>>>>>>>> > as
>>>>>>>>> > > > GoogleIdentityProvider) to discover and cache endpoints such
>>>>>>>>> that they
>>>>>>>>> > are
>>>>>>>>> > > > not hard-coded into the implementing class. Each
>>>>>>>>> implementing class
>>>>>>>>> > would
>>>>>>>>> > > > then have a public static final DISCOVERY_URL that it passes
>>>>>>>>> to
>>>>>>>>> > > > discoverConfig.
>>>>>>>>> > > >
>>>>>>>>> > > >
>>>>>>>>> > > >
>>>>>>>>> > > > My main hangup, as suggested above, is that to implement the
>>>>>>>>> caching, I
>>>>>>>>> > > > want
>>>>>>>>> > > > to ensure that the model configuration is stored/set in the
>>>>>>>>> right
>>>>>>>>> > place.
>>>>>>>>> > > >
>>>>>>>>> > > >
>>>>>>>>> > > >
>>>>>>>>> > > > Thanks for bearing with me as I come up to speed on this!
>>>>>>>>> > > >
>>>>>>>>> > > >
>>>>>>>>> > > >
>>>>>>>>> > > > James
>>>>>>>>> > > >
>>>>>>>>> > > > _______________________________________________
>>>>>>>>> > > > keycloak-dev mailing list
>>>>>>>>> > > > keycloak-dev at lists.jboss.org
>>>>>>>>> > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>>> > > >
>>>>>>>>> > >
>>>>>>>>> > >
>>>>>>>>> > > Regards,
>>>>>>>>> > > Tomas
>>>>>>>>> > >
>>>>>>>>> >
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> -... . / - .-. ..- . .-.-.- / -... . / .--. .-. . ... . -. -
>>>>>>>>> .-.-.- / -...
>>>>>>>>> . / ..-. .. -
>>>>>>>>> 07:d0:2d:0b:d6:9d:27:c6:a7:c1:ec:e3:b1:65:f4:70
>>>>>>>>> _______________________________________________
>>>>>>>>> keycloak-dev mailing list
>>>>>>>>> keycloak-dev at lists.jboss.org
>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> -... . / - .-. ..- . .-.-.- / -... . / .--. .-. . ... . -. - .-.-.-
>>>>>>> / -... . / ..-. .. -
>>>>>>> 07:d0:2d:0b:d6:9d:27:c6:a7:c1:ec:e3:b1:65:f4:70
>>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> -... . / - .-. ..- . .-.-.- / -... . / .--. .-. . ... . -. - .-.-.- /
>>>>> -... . / ..-. .. -
>>>>> 07:d0:2d:0b:d6:9d:27:c6:a7:c1:ec:e3:b1:65:f4:70
>>>>>
>>>>
>>>>
>>>> --
>>>> -... . / - .-. ..- . .-.-.- / -... . / .--. .-. . ... . -. - .-.-.- /
>>>> -... . / ..-. .. -
>>>> 07:d0:2d:0b:d6:9d:27:c6:a7:c1:ec:e3:b1:65:f4:70
>>>>
>>>
>>
>> --
>> -... . / - .-. ..- . .-.-.- / -... . / .--. .-. . ... . -. - .-.-.- /
>> -... . / ..-. .. -
>> 07:d0:2d:0b:d6:9d:27:c6:a7:c1:ec:e3:b1:65:f4:70
>>
>

From sthorger at redhat.com  Fri Feb 15 02:31:45 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 15 Feb 2019 08:31:45 +0100
Subject: [keycloak-dev] Node.js admin client project
Message-ID: <CAJgngAfgMLnbGOPfgcREy3htGXpmWMyuyfdLX_XyKC1i039xzg@mail.gmail.com>

The old Node.js admin client (
https://github.com/keycloak/keycloak-admin-client) has for a long time not
been maintained.

As there is a limit to how many projects the core Keycloak team can
maintain we needed some help here.

Thanks to developers from Canner and InfuseAI we know have a new Node.js
admin client project that also has an active group to maintain the library.

Take a look at https://github.com/keycloak/keycloak-nodejs-admin-client.

From thomas.darimont at googlemail.com  Fri Feb 15 04:27:57 2019
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Fri, 15 Feb 2019 10:27:57 +0100
Subject: [keycloak-dev] KEYCLOAK-9574 Role selection in Federation Provider
	Mappers broken in 4.8.3.Final
Message-ID: <CAK-7U1iVY9FZ8JbfoOo-sV3nCCeySXPDg0g714We4MCu63tJCw@mail.gmail.com>

Hello,

Yesterday, I noticed that the role selection is broken in federation
provider mappers, e.g. hardcoded-ldap-role-mapper.

See: https://issues.jboss.org/browse/KEYCLOAK-9574
It seems that the format how single role selections are transferred to the
server is broken.

Did the config structure change, or has this been broken for a while?
I provided a fix (html, js) via PR.

Cheers,
Thomas

From mposolda at redhat.com  Fri Feb 15 08:56:19 2019
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 15 Feb 2019 14:56:19 +0100
Subject: [keycloak-dev] Why does client session expire regardless
 remember-me extended validity?
In-Reply-To: <CA+7ohfm=GbNpnhLpSNDjHmnoR_5oc=utZe09JP41iqVgvMdKQw@mail.gmail.com>
References: <7637f53f-dd9b-2a3c-3816-a25d14ca189a@yahoo.de>
	<685a0dff-80b9-ddd6-18ff-4847755204df@redhat.com>
	<CA+7ohf=nRhHaWhk7vOfRZ1j1fOHLUwNRsmS5KQiXv7PVabyk8g@mail.gmail.com>
	<c7d47317-2297-534c-8bc2-407a0da21a47@yahoo.de>
	<CA+7ohfm=GbNpnhLpSNDjHmnoR_5oc=utZe09JP41iqVgvMdKQw@mail.gmail.com>
Message-ID: <6852a835-88f0-7408-e6ea-41f77ea8b12e@redhat.com>

IMO single PR is fine. But I suggest to create new JIRA or update 
description of existing JIRA, so that it contains also the description 
for this "new" bug.

2 minor things:
- Is it possible to update this check, so it considers the "min(expired, 
expiredRememberMe)" instead of being hardcoded to expiredRememberMe? In 
most cases, the "ssoSessionMAxLifespanRememberMe" is bigger than 
"ssoSessionMaxLifespan", however it may not be always true. For example, 
someone can want to increase ssoSessionMaxLifespan to some very big 
value, but he doesn't use "remember me", so he won't increase the 
"ssoSessionMAxLifespanRememberMe" .
- Is it possible to add the test for the buggy scenarios? It is hard to 
test it properly, but we somehow test it with usage of time offset and 
manually invoking "expiration check". It is done in 
UserSessionProviderTest - please make sure to use the one from new 
testsuite as this test is currently duplicated in both the new and old 
testsuite :(

WDYT?
Marek

On 15/02/2019 02:57, Stefan Guilhen wrote:
> Hi Ken,
>
> Yes, it does make sense to me to use the remember-me value for the 
> client session as well. Marek, WDYT? Should we open a new Jira just 
> for this or can I just amend the commit to include this fix too?
>
> Stefan
>
> On Thu, Feb 14, 2019 at 10:34 AM Ken Haendel <kschwiersch at yahoo.de 
> <mailto:kschwiersch at yahoo.de>> wrote:
>
>     Hi Stefan, Marek
>
>
>     Thank you for your quick reply.
>
>     I have recently tested your pull request [1], if that fixes my
>     issue with the expired client session cache and it does NOT. It
>     only fixes an issue with the user session cache.
>
>     My proposal to fix that problem would be as follows (verified here):
>
>     diff --git
>     a/model/infinispan/src/main/java/org/keycloak/models/sessions/infinispan/InfinispanUserSessionProvider.java
>     b/model/infinispan/src/main/java/org/keycloak/models/sessions/infinispan/InfinispanUserSessionProvider.java
>     index b1429a6391..54cb244624 100755
>     ---
>     a/model/infinispan/src/main/java/org/keycloak/models/sessions/infinispan/InfinispanUserSessionProvider.java
>     +++
>     b/model/infinispan/src/main/java/org/keycloak/models/sessions/infinispan/InfinispanUserSessionProvider.java
>     @@ -529,7 +529,7 @@ public class InfinispanUserSessionProvider
>     implements UserSessionProvider {
>     ???????? localClientSessionCacheStoreIgnore
>     ???????????????? .entrySet()
>     ???????????????? .stream()
>     -
>     .filter(AuthenticatedClientSessionPredicate.create(realm.getId()).expired(expired))
>     +
>     .filter(AuthenticatedClientSessionPredicate.create(realm.getId()).expired(expiredRememberMe))
>
>
>     Using that change, the life span of the client session would be
>     longer for remember-me logins.
>
>     Can you please check if that makes sense for you?
>
>     It would be nice if a fix could be added in the next releases to
>     make it unnecessary to patch the further release :-)
>
>     Kind regards,
>
>     Ken
>
>
>     [1] https://github.com/keycloak/keycloak/pull/5852
>
>     Am 13.02.19 um 18:27 schrieb Stefan Guilhen:
>>     It is possible that Ken is seeing something different. I will
>>     take a look into it to be sure.
>>
>>     Best regards,
>>     Stefan
>>
>>     On Wed, Feb 13, 2019, 13:43 Marek Posolda <mposolda at redhat.com
>>     <mailto:mposolda at redhat.com> wrote:
>>
>>         We have PR open, which is related to that [1], but not sure
>>         if that PR
>>         fixes also your issue. It seems there is nothing related to
>>         client
>>         sessions. I am CCing Stefan in case he has some more to it.
>>
>>         In the meantime, if you are curious if fix works, I suggest to
>>         cherry-pick Stefan's commit and build Keycloak and check if the
>>         behaviour is fixed with that PR.
>>
>>         [1] https://github.com/keycloak/keycloak/pull/5852
>>
>>         Marek
>>
>>         On 13/02/2019 14:15, Ken Haendel wrote:
>>         > I have a problem authenticating a spring secured web-app
>>         using keycloak
>>         > 4.8.3.
>>         >
>>         > If the user logs in with remember-me enabled, the user
>>         session does use
>>         > a larger SSO max life span (ssoSessionMaxLifespanRememberMe).
>>         >
>>         > So far so good.
>>         >
>>         > Now i want to call another secured REST-API using the
>>         KeycloakRestService.
>>         >
>>         > That triggers OAuthRequestAuthenticator to verify token
>>         > (AdapterTokenVerifier.verifyTokens).
>>         >
>>         > That operation fails, because the client session expired
>>         much earlier
>>         > (after ssoSessionMaxLifespan). The client session gets
>>         removed from the
>>         > client session cache
>>         > (InfinispanUserSessionProvider.removeExpiredUserSessions).
>>         >
>>         > Error message of AdapterTokenVerifier.verifyTokens() is:
>>         >
>>         > "ERROR RefreshableKeycloakSecurityContext Refresh token
>>         failure status:
>>         > 400 {"error":"invalid_grant","error_description":"Session
>>         doesn't have
>>         > required client"}"
>>         >
>>         >
>>         > So, the point is: after the client session gets removed
>>         from cache (SSO
>>         > max life span) i can no longer use the refresh token to
>>         request new
>>         > tokens and call another REST-API service
>>         >
>>         > using the same identity as the web-app.
>>         >
>>         > Even though i have still a valid user session to use my
>>         spring app.
>>         >
>>         >
>>         > Expectation was: I can use refresh token within the larger
>>         time span
>>         > with remember-me enabled (SsoSessionMaxLifespanRememberMe).
>>         >
>>         > Actual behaviour is: Refresh token gets useless within the
>>         shorter time
>>         > span (ssoSessionMaxLifespan)
>>         >
>>         > Question: Why is the client session removed so early and
>>         not when the
>>         > user session expires? Is that expected behavoiur?
>>         >
>>         > Thank you in advance,
>>         >
>>         > Ken
>>         >
>>         >
>>         > _______________________________________________
>>         > 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
>>
>>
>
>
> -- 
>
> STEFAN GUILHEN
>
> PRINCIPAL SOFTWARE ENGINEER
>
> Red Hat<https://www.redhat.com/>
>
> sguilhen at redhat.com <mailto:sguilhen at redhat.com> M: +55-11-98117-7332 
> <tel:+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 pa at pauloangelo.com  Sun Feb 17 13:22:30 2019
From: pa at pauloangelo.com (Paulo Angelo)
Date: Sun, 17 Feb 2019 15:22:30 -0300
Subject: [keycloak-dev] Integration with GuardianKey
In-Reply-To: <CAFjP4XQvSgNr2fB9oqDBrq2PJ5fuN=_CLEgU6E7Vo9KKRg_b2Q@mail.gmail.com>
References: <CAFjP4XTv=yupw4jZAf275q37JNJZj5jh9tr+BTH0A+0EeNSQMw@mail.gmail.com>
	<CA+H6wMzRFPSf2mkqa4vizP1SaSn6pbbqsFoP+YtwOF4aDvKboA@mail.gmail.com>
	<1549228866.7030.6.camel@acutus.pro>
	<CAFjP4XQvSgNr2fB9oqDBrq2PJ5fuN=_CLEgU6E7Vo9KKRg_b2Q@mail.gmail.com>
Message-ID: <CAFjP4XRghVyWeLeXxpDAc67FLys0WOk6x7KaivtX6KYKf4v3+A@mail.gmail.com>

Hi All,

The GuardianKey extension for KeyCloak is almost complete! Thank you for
the given directions.

We have to get the user client IP and the status of the authentication
attempt (failed/success). For this, we implemented the code below. However,
we are facing Null Pointer exceptions.

public class GuardianKeyAuthenticator implements Authenticator {  // ...
public void authenticate(AuthenticationFlowContext context) {  // ...
         // *Trying to get the Client IP address*
           clientIP =
context.getSession().sessions().getUserSession(context.getAuthenticationSession().getClient().getRealm(),

context.getAuthenticationSession().getClient().getId())
                                                     .getIpAddress(); /*
getting null pointer exception */
          // *Trying to get the status for the auth attempt
(failed/success), this Authenticator should be the last in the flow*
             failed = context.getStatus().equals(FlowStatus.SUCCESS); /*
getting null pointer exception */
       // ...
} }

Any clue about how we can do this?

Thank you in advance.

Paulo Angelo


On Sun, Feb 3, 2019 at 10:21 PM Paulo Angelo <pa at pauloangelo.com> wrote:

> Dmitry and Al?xis,
>
> Thank you very much for the directions. We are going to work on it.
>
> regards,
>
> Paulo Angelo
>
> On Sun, Feb 3, 2019 at 8:06 PM Dmitry Telegin <dt at acutus.pro> wrote:
>
>> Hello Paulo,
>>
>> To add to Alexis's reply, you can use Script authenticator [1]. It's
>> especially good for prototyping since you don't have to create and deploy
>> the whole provider module.
>>
>> Also, you'll need an HttpClient instance to be able to perform external
>> HTTP requests, see [2] for that.
>>
>> [1] https://www.keycloak.org/docs/latest/server_admin/#executions
>> [2]
>> http://lists.jboss.org/pipermail/keycloak-user/2018-November/016456.html
>>
>> Good luck,
>> Dmitry Telegin
>> CTO, Acutus s.r.o.
>> Keycloak Consulting and Training
>>
>> Pod lipami street 339/52, 130 00 Prague 3, Czech Republic
>> +42 (022) 888-30-71
>> E-mail: info at acutus.pro
>>
>> On Sun, 2019-02-03 at 17:46 -0200, Alexis Almeida wrote:
>> > Hi Paulo,
>> >
>> > IMO the simplest way to do this is with an Authenticator Provider.
>> Please
>> > see here:
>> >
>> >
>> https://www.keycloak.org/docs/latest/server_development/index.html#implementing-an-authenticator
>> > .
>> >
>> > In the authenticate method you can call the GuardianKey and, depending
>> on
>> > the result, you call a context.success () or context.failure ().
>> >
>> > Like this:
>> >
>> > public void authenticate(AuthenticationFlowContext context) {
>> > ...
>> > if(!GuardianKeyValidation){
>> >    Response challenge = context.form()
>> >                 .setError("something")
>> >                 .createForm("error_page.ftl");
>> >
>> >  context.failureChallenge(AuthenticationFlowError.INVALID_CREDENTIALS,
>> > challenge);
>> >    return;
>> > }
>> > ...
>> > context.success();
>> > }
>> >
>> > Al?xis
>> >
>> >
>> > > Em dom, 3 de fev de 2019 ?s 15:38, Paulo Angelo <pa at pauloangelo.com>
>> > escreveu:
>> >
>> > > Hi all,
>> > >
>> > > We are trying to integrate KeyCloak with GuardianKey. However, we have
>> > > doubts related to the best way to do this and the best point in the
>> > > KeyCloak?s code for this integration.
>> > >
>> > > GuardianKey is a service to protect systems against authentication
>> attacks.
>> > > It uses Machine Learning and analyses the user's behavior, threat
>> > > intelligence and psychometrics (or behavioral biometrics). The
>> protected
>> > > system (in the concrete case, KeyCloak) must send an event via REST
>> for the
>> > > GuardianKey on each login attempt. More info at
>> https://guardiankey.io .
>> > >
>> > > The best way to integrate would be on having a hook in the procedure
>> that
>> > > process the user credentials submission in KeyCloak (the script that
>> > > receives the POST), something such as:
>> > >
>> > > if(<POST IN AUTH FORM>) {
>> > >
>> > >  boolean loginFailed =  checkLoginInKeyCloak();
>> > >
>> > >  GuardianKeyEvent event =
>> createEventForGuardianKey(username,loginFailed);
>> > >
>> > >  boolean GuardianKeyValidation = checkGuardianKeyViaREST(event);
>> > >
>> > >  if(GuardianKeyValidation){
>> > >
>> > >     // Allow access
>> > >
>> > >  } else {
>> > >
>> > >     // Deny access
>> > >
>> > >  }
>> > >
>> > > }
>> > >
>> > > Where is the best place to create this integration? Is there a way to
>> > > create a hook for this purpose? Should we create an extension?
>> > >
>> > > Any help is welcome.
>> > >
>> > > Thank you in advance.
>> > >
>> > > Best regards,
>> > >
>> > > Paulo Angelo
>> > > _______________________________________________
>> > > keycloak-dev mailing list
>> > > keycloak-dev at lists.jboss.org
>> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> >
>> > _______________________________________________
>> > keycloak-dev mailing list
>> > keycloak-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
> --
>
> Att,
>
> Paulo Angelo
>


-- 

Att,

Paulo Angelo

From thomas.darimont at googlemail.com  Sun Feb 17 15:45:11 2019
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Sun, 17 Feb 2019 21:45:11 +0100
Subject: [keycloak-dev] Integration with GuardianKey
In-Reply-To: <CAFjP4XRghVyWeLeXxpDAc67FLys0WOk6x7KaivtX6KYKf4v3+A@mail.gmail.com>
References: <CAFjP4XTv=yupw4jZAf275q37JNJZj5jh9tr+BTH0A+0EeNSQMw@mail.gmail.com>
	<CA+H6wMzRFPSf2mkqa4vizP1SaSn6pbbqsFoP+YtwOF4aDvKboA@mail.gmail.com>
	<1549228866.7030.6.camel@acutus.pro>
	<CAFjP4XQvSgNr2fB9oqDBrq2PJ5fuN=_CLEgU6E7Vo9KKRg_b2Q@mail.gmail.com>
	<CAFjP4XRghVyWeLeXxpDAc67FLys0WOk6x7KaivtX6KYKf4v3+A@mail.gmail.com>
Message-ID: <CAK-7U1i0Y+hL3r3TAVVxfiVi+m+NtT-mqSNrU7aMzJ=ZfC9awA@mail.gmail.com>

Hello Paulo,

in order to get the remote IP address of the request you could either use
the information from "ClientConnection" or look manually in the current
HttpServletRequest,
or HTTP-Headers. This structures can be obtained from the
"ResteasyProviderFactory".

        // See ResteasyProviderFactory.getContextDataMap() for what's
available.

        ClientConnection clientConnection =
ResteasyProviderFactory.getContextData(ClientConnection.class);
        clientConnection.getRemoteAddr();

        HttpServletRequest request =
ResteasyProviderFactory.getContextData(HttpServletRequest.class);

Cheers,
Thomas

Am So., 17. Feb. 2019 um 19:47 Uhr schrieb Paulo Angelo <pa at pauloangelo.com
>:

> Hi All,
>
> The GuardianKey extension for KeyCloak is almost complete! Thank you for
> the given directions.
>
> We have to get the user client IP and the status of the authentication
> attempt (failed/success). For this, we implemented the code below. However,
> we are facing Null Pointer exceptions.
>
> public class GuardianKeyAuthenticator implements Authenticator {  // ...
> public void authenticate(AuthenticationFlowContext context) {  // ...
>          // *Trying to get the Client IP address*
>            clientIP =
>
> context.getSession().sessions().getUserSession(context.getAuthenticationSession().getClient().getRealm(),
>
> context.getAuthenticationSession().getClient().getId())
>                                                      .getIpAddress(); /*
> getting null pointer exception */
>           // *Trying to get the status for the auth attempt
> (failed/success), this Authenticator should be the last in the flow*
>              failed = context.getStatus().equals(FlowStatus.SUCCESS); /*
> getting null pointer exception */
>        // ...
> } }
>
> Any clue about how we can do this?
>
> Thank you in advance.
>
> Paulo Angelo
>
>
> On Sun, Feb 3, 2019 at 10:21 PM Paulo Angelo <pa at pauloangelo.com> wrote:
>
> > Dmitry and Al?xis,
> >
> > Thank you very much for the directions. We are going to work on it.
> >
> > regards,
> >
> > Paulo Angelo
> >
> > On Sun, Feb 3, 2019 at 8:06 PM Dmitry Telegin <dt at acutus.pro> wrote:
> >
> >> Hello Paulo,
> >>
> >> To add to Alexis's reply, you can use Script authenticator [1]. It's
> >> especially good for prototyping since you don't have to create and
> deploy
> >> the whole provider module.
> >>
> >> Also, you'll need an HttpClient instance to be able to perform external
> >> HTTP requests, see [2] for that.
> >>
> >> [1] https://www.keycloak.org/docs/latest/server_admin/#executions
> >> [2]
> >>
> http://lists.jboss.org/pipermail/keycloak-user/2018-November/016456.html
> >>
> >> Good luck,
> >> Dmitry Telegin
> >> CTO, Acutus s.r.o.
> >> Keycloak Consulting and Training
> >>
> >> Pod lipami street 339/52, 130 00 Prague 3, Czech Republic
> >> +42 (022) 888-30-71
> >> E-mail: info at acutus.pro
> >>
> >> On Sun, 2019-02-03 at 17:46 -0200, Alexis Almeida wrote:
> >> > Hi Paulo,
> >> >
> >> > IMO the simplest way to do this is with an Authenticator Provider.
> >> Please
> >> > see here:
> >> >
> >> >
> >>
> https://www.keycloak.org/docs/latest/server_development/index.html#implementing-an-authenticator
> >> > .
> >> >
> >> > In the authenticate method you can call the GuardianKey and, depending
> >> on
> >> > the result, you call a context.success () or context.failure ().
> >> >
> >> > Like this:
> >> >
> >> > public void authenticate(AuthenticationFlowContext context) {
> >> > ...
> >> > if(!GuardianKeyValidation){
> >> >    Response challenge = context.form()
> >> >                 .setError("something")
> >> >                 .createForm("error_page.ftl");
> >> >
> >> >  context.failureChallenge(AuthenticationFlowError.INVALID_CREDENTIALS,
> >> > challenge);
> >> >    return;
> >> > }
> >> > ...
> >> > context.success();
> >> > }
> >> >
> >> > Al?xis
> >> >
> >> >
> >> > > Em dom, 3 de fev de 2019 ?s 15:38, Paulo Angelo <pa at pauloangelo.com
> >
> >> > escreveu:
> >> >
> >> > > Hi all,
> >> > >
> >> > > We are trying to integrate KeyCloak with GuardianKey. However, we
> have
> >> > > doubts related to the best way to do this and the best point in the
> >> > > KeyCloak?s code for this integration.
> >> > >
> >> > > GuardianKey is a service to protect systems against authentication
> >> attacks.
> >> > > It uses Machine Learning and analyses the user's behavior, threat
> >> > > intelligence and psychometrics (or behavioral biometrics). The
> >> protected
> >> > > system (in the concrete case, KeyCloak) must send an event via REST
> >> for the
> >> > > GuardianKey on each login attempt. More info at
> >> https://guardiankey.io .
> >> > >
> >> > > The best way to integrate would be on having a hook in the procedure
> >> that
> >> > > process the user credentials submission in KeyCloak (the script that
> >> > > receives the POST), something such as:
> >> > >
> >> > > if(<POST IN AUTH FORM>) {
> >> > >
> >> > >  boolean loginFailed =  checkLoginInKeyCloak();
> >> > >
> >> > >  GuardianKeyEvent event =
> >> createEventForGuardianKey(username,loginFailed);
> >> > >
> >> > >  boolean GuardianKeyValidation = checkGuardianKeyViaREST(event);
> >> > >
> >> > >  if(GuardianKeyValidation){
> >> > >
> >> > >     // Allow access
> >> > >
> >> > >  } else {
> >> > >
> >> > >     // Deny access
> >> > >
> >> > >  }
> >> > >
> >> > > }
> >> > >
> >> > > Where is the best place to create this integration? Is there a way
> to
> >> > > create a hook for this purpose? Should we create an extension?
> >> > >
> >> > > Any help is welcome.
> >> > >
> >> > > Thank you in advance.
> >> > >
> >> > > Best regards,
> >> > >
> >> > > Paulo Angelo
> >> > > _______________________________________________
> >> > > keycloak-dev mailing list
> >> > > keycloak-dev at lists.jboss.org
> >> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >> >
> >> > _______________________________________________
> >> > keycloak-dev mailing list
> >> > keycloak-dev at lists.jboss.org
> >> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> >
> >
> > --
> >
> > Att,
> >
> > Paulo Angelo
> >
>
>
> --
>
> Att,
>
> Paulo Angelo
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From alexis.almeida at gmail.com  Sun Feb 17 16:18:06 2019
From: alexis.almeida at gmail.com (Alexis Almeida)
Date: Sun, 17 Feb 2019 18:18:06 -0300
Subject: [keycloak-dev] Integration with GuardianKey
In-Reply-To: <CAK-7U1i0Y+hL3r3TAVVxfiVi+m+NtT-mqSNrU7aMzJ=ZfC9awA@mail.gmail.com>
References: <CAFjP4XTv=yupw4jZAf275q37JNJZj5jh9tr+BTH0A+0EeNSQMw@mail.gmail.com>
	<CA+H6wMzRFPSf2mkqa4vizP1SaSn6pbbqsFoP+YtwOF4aDvKboA@mail.gmail.com>
	<1549228866.7030.6.camel@acutus.pro>
	<CAFjP4XQvSgNr2fB9oqDBrq2PJ5fuN=_CLEgU6E7Vo9KKRg_b2Q@mail.gmail.com>
	<CAFjP4XRghVyWeLeXxpDAc67FLys0WOk6x7KaivtX6KYKf4v3+A@mail.gmail.com>
	<CAK-7U1i0Y+hL3r3TAVVxfiVi+m+NtT-mqSNrU7aMzJ=ZfC9awA@mail.gmail.com>
Message-ID: <CA+H6wMw9dWhEUQRCSPrGD74bWSOYqXQy10P58QskM5dTihWLUA@mail.gmail.com>

Hi Paulo!

In addition to Thomas suggestion, I usually capture the remote IP like this:

String ip = context.getSession (). GetContext (). GetConnection ().
GetRemoteAddr ();

About login status, I think you must to change your approach to get failure
login.

In the authentication flow, if you put your authenticator provider before
"user and password" form this wil not work, because the user is not
authenticated yet.
If you put it after "user and passwrd" form, you'll only catch success
logins.

So I think you could implement the EventListener class to get any event
type:

public class RealmTeste implements EventListenerProvider, Authenticator {
...
    public void onEvent(Event event) {
        String ip = event.getIpAddress();
        if (event.getType().equals("LOGIN_ERROR")) {

        }
    }
    public void onEvent(AdminEvent event, boolean includeRepresentation) {
    }
...

Regards

Al?xis


Em dom, 17 de fev de 2019 ?s 17:45, Thomas Darimont <
thomas.darimont at googlemail.com> escreveu:

> Hello Paulo,
>
> in order to get the remote IP address of the request you could either use
> the information from "ClientConnection" or look manually in the current
> HttpServletRequest,
> or HTTP-Headers. This structures can be obtained from the
> "ResteasyProviderFactory".
>
>         // See ResteasyProviderFactory.getContextDataMap() for what's
> available.
>
>         ClientConnection clientConnection =
> ResteasyProviderFactory.getContextData(ClientConnection.class);
>         clientConnection.getRemoteAddr();
>
>         HttpServletRequest request =
> ResteasyProviderFactory.getContextData(HttpServletRequest.class);
>
> Cheers,
> Thomas
>
> Am So., 17. Feb. 2019 um 19:47 Uhr schrieb Paulo Angelo <
> pa at pauloangelo.com>:
>
>> Hi All,
>>
>> The GuardianKey extension for KeyCloak is almost complete! Thank you for
>> the given directions.
>>
>> We have to get the user client IP and the status of the authentication
>> attempt (failed/success). For this, we implemented the code below.
>> However,
>> we are facing Null Pointer exceptions.
>>
>> public class GuardianKeyAuthenticator implements Authenticator {  // ...
>> public void authenticate(AuthenticationFlowContext context) {  // ...
>>          // *Trying to get the Client IP address*
>>            clientIP =
>>
>> context.getSession().sessions().getUserSession(context.getAuthenticationSession().getClient().getRealm(),
>>
>> context.getAuthenticationSession().getClient().getId())
>>                                                      .getIpAddress(); /*
>> getting null pointer exception */
>>           // *Trying to get the status for the auth attempt
>> (failed/success), this Authenticator should be the last in the flow*
>>              failed = context.getStatus().equals(FlowStatus.SUCCESS); /*
>> getting null pointer exception */
>>        // ...
>> } }
>>
>> Any clue about how we can do this?
>>
>> Thank you in advance.
>>
>> Paulo Angelo
>>
>>
>> On Sun, Feb 3, 2019 at 10:21 PM Paulo Angelo <pa at pauloangelo.com> wrote:
>>
>> > Dmitry and Al?xis,
>> >
>> > Thank you very much for the directions. We are going to work on it.
>> >
>> > regards,
>> >
>> > Paulo Angelo
>> >
>> > On Sun, Feb 3, 2019 at 8:06 PM Dmitry Telegin <dt at acutus.pro> wrote:
>> >
>> >> Hello Paulo,
>> >>
>> >> To add to Alexis's reply, you can use Script authenticator [1]. It's
>> >> especially good for prototyping since you don't have to create and
>> deploy
>> >> the whole provider module.
>> >>
>> >> Also, you'll need an HttpClient instance to be able to perform external
>> >> HTTP requests, see [2] for that.
>> >>
>> >> [1] https://www.keycloak.org/docs/latest/server_admin/#executions
>> >> [2]
>> >>
>> http://lists.jboss.org/pipermail/keycloak-user/2018-November/016456.html
>> >>
>> >> Good luck,
>> >> Dmitry Telegin
>> >> CTO, Acutus s.r.o.
>> >> Keycloak Consulting and Training
>> >>
>> >> Pod lipami street 339/52, 130 00 Prague 3, Czech Republic
>> >> +42 (022) 888-30-71
>> >> E-mail: info at acutus.pro
>> >>
>> >> On Sun, 2019-02-03 at 17:46 -0200, Alexis Almeida wrote:
>> >> > Hi Paulo,
>> >> >
>> >> > IMO the simplest way to do this is with an Authenticator Provider.
>> >> Please
>> >> > see here:
>> >> >
>> >> >
>> >>
>> https://www.keycloak.org/docs/latest/server_development/index.html#implementing-an-authenticator
>> >> > .
>> >> >
>> >> > In the authenticate method you can call the GuardianKey and,
>> depending
>> >> on
>> >> > the result, you call a context.success () or context.failure ().
>> >> >
>> >> > Like this:
>> >> >
>> >> > public void authenticate(AuthenticationFlowContext context) {
>> >> > ...
>> >> > if(!GuardianKeyValidation){
>> >> >    Response challenge = context.form()
>> >> >                 .setError("something")
>> >> >                 .createForm("error_page.ftl");
>> >> >
>> >> >
>> context.failureChallenge(AuthenticationFlowError.INVALID_CREDENTIALS,
>> >> > challenge);
>> >> >    return;
>> >> > }
>> >> > ...
>> >> > context.success();
>> >> > }
>> >> >
>> >> > Al?xis
>> >> >
>> >> >
>> >> > > Em dom, 3 de fev de 2019 ?s 15:38, Paulo Angelo <
>> pa at pauloangelo.com>
>> >> > escreveu:
>> >> >
>> >> > > Hi all,
>> >> > >
>> >> > > We are trying to integrate KeyCloak with GuardianKey. However, we
>> have
>> >> > > doubts related to the best way to do this and the best point in the
>> >> > > KeyCloak?s code for this integration.
>> >> > >
>> >> > > GuardianKey is a service to protect systems against authentication
>> >> attacks.
>> >> > > It uses Machine Learning and analyses the user's behavior, threat
>> >> > > intelligence and psychometrics (or behavioral biometrics). The
>> >> protected
>> >> > > system (in the concrete case, KeyCloak) must send an event via REST
>> >> for the
>> >> > > GuardianKey on each login attempt. More info at
>> >> https://guardiankey.io .
>> >> > >
>> >> > > The best way to integrate would be on having a hook in the
>> procedure
>> >> that
>> >> > > process the user credentials submission in KeyCloak (the script
>> that
>> >> > > receives the POST), something such as:
>> >> > >
>> >> > > if(<POST IN AUTH FORM>) {
>> >> > >
>> >> > >  boolean loginFailed =  checkLoginInKeyCloak();
>> >> > >
>> >> > >  GuardianKeyEvent event =
>> >> createEventForGuardianKey(username,loginFailed);
>> >> > >
>> >> > >  boolean GuardianKeyValidation = checkGuardianKeyViaREST(event);
>> >> > >
>> >> > >  if(GuardianKeyValidation){
>> >> > >
>> >> > >     // Allow access
>> >> > >
>> >> > >  } else {
>> >> > >
>> >> > >     // Deny access
>> >> > >
>> >> > >  }
>> >> > >
>> >> > > }
>> >> > >
>> >> > > Where is the best place to create this integration? Is there a way
>> to
>> >> > > create a hook for this purpose? Should we create an extension?
>> >> > >
>> >> > > Any help is welcome.
>> >> > >
>> >> > > Thank you in advance.
>> >> > >
>> >> > > Best regards,
>> >> > >
>> >> > > Paulo Angelo
>> >> > > _______________________________________________
>> >> > > keycloak-dev mailing list
>> >> > > keycloak-dev at lists.jboss.org
>> >> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> >> >
>> >> > _______________________________________________
>> >> > keycloak-dev mailing list
>> >> > keycloak-dev at lists.jboss.org
>> >> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> >> _______________________________________________
>> >> keycloak-dev mailing list
>> >> keycloak-dev at lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> >
>> >
>> >
>> > --
>> >
>> > Att,
>> >
>> > Paulo Angelo
>> >
>>
>>
>> --
>>
>> Att,
>>
>> Paulo Angelo
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>

From pa at pauloangelo.com  Sun Feb 17 20:11:15 2019
From: pa at pauloangelo.com (Paulo Angelo)
Date: Sun, 17 Feb 2019 22:11:15 -0300
Subject: [keycloak-dev] Integration with GuardianKey
In-Reply-To: <CA+H6wMw9dWhEUQRCSPrGD74bWSOYqXQy10P58QskM5dTihWLUA@mail.gmail.com>
References: <CAFjP4XTv=yupw4jZAf275q37JNJZj5jh9tr+BTH0A+0EeNSQMw@mail.gmail.com>
	<CA+H6wMzRFPSf2mkqa4vizP1SaSn6pbbqsFoP+YtwOF4aDvKboA@mail.gmail.com>
	<1549228866.7030.6.camel@acutus.pro>
	<CAFjP4XQvSgNr2fB9oqDBrq2PJ5fuN=_CLEgU6E7Vo9KKRg_b2Q@mail.gmail.com>
	<CAFjP4XRghVyWeLeXxpDAc67FLys0WOk6x7KaivtX6KYKf4v3+A@mail.gmail.com>
	<CAK-7U1i0Y+hL3r3TAVVxfiVi+m+NtT-mqSNrU7aMzJ=ZfC9awA@mail.gmail.com>
	<CA+H6wMw9dWhEUQRCSPrGD74bWSOYqXQy10P58QskM5dTihWLUA@mail.gmail.com>
Message-ID: <CAFjP4XQwLcQsf8X7Y5CEg7JVkE=5bKmF86OBBR=LuymRZ_mhKQ@mail.gmail.com>

Thank you Thomas and Alexis!

Another question: In the method "onEvent" of an EventListener, how could I
get the configuration for one specific Authenticator?

When the Authenticator is triggered (authenticate method), I can access its
config using:

    Map<String,String> config =
context.getAuthenticatorConfig().getConfig();

However, the context is not directly available (as expected) when the
"EventListener.onEvent" is triggered.

I could see in the documentation [1] that, inside the EventListener, I can
have access to a KeycloakSession and a KeycloakSessionFactory. But I could
not find the path for one specific Authenticator config. I also saw in docs
that it is possible to save the configuration for the EventListener, but
the attributes are the same used in the Authenticator.

Is it possible to retrieve the configuration of a specific Authenticator in
the flow used by the "event"?

Thank you in advance,

Paulo Angelo

[1]
https://www.keycloak.org/docs/3.3/server_development/topics/providers.html



On Sun, Feb 17, 2019 at 6:25 PM Alexis Almeida <alexis.almeida at gmail.com>
wrote:

> Hi Paulo!
>
> In addition to Thomas suggestion, I usually capture the remote IP like
> this:
>
> String ip = context.getSession (). GetContext (). GetConnection ().
> GetRemoteAddr ();
>
> About login status, I think you must to change your approach to get failure
> login.
>
> In the authentication flow, if you put your authenticator provider before
> "user and password" form this wil not work, because the user is not
> authenticated yet.
> If you put it after "user and passwrd" form, you'll only catch success
> logins.
>
> So I think you could implement the EventListener class to get any event
> type:
>
> public class RealmTeste implements EventListenerProvider, Authenticator {
> ...
>     public void onEvent(Event event) {
>         String ip = event.getIpAddress();
>         if (event.getType().equals("LOGIN_ERROR")) {
>
>         }
>     }
>     public void onEvent(AdminEvent event, boolean includeRepresentation) {
>     }
> ...
>
> Regards
>
> Al?xis
>
>
> Em dom, 17 de fev de 2019 ?s 17:45, Thomas Darimont <
> thomas.darimont at googlemail.com> escreveu:
>
> > Hello Paulo,
> >
> > in order to get the remote IP address of the request you could either use
> > the information from "ClientConnection" or look manually in the current
> > HttpServletRequest,
> > or HTTP-Headers. This structures can be obtained from the
> > "ResteasyProviderFactory".
> >
> >         // See ResteasyProviderFactory.getContextDataMap() for what's
> > available.
> >
> >         ClientConnection clientConnection =
> > ResteasyProviderFactory.getContextData(ClientConnection.class);
> >         clientConnection.getRemoteAddr();
> >
> >         HttpServletRequest request =
> > ResteasyProviderFactory.getContextData(HttpServletRequest.class);
> >
> > Cheers,
> > Thomas
> >
> > Am So., 17. Feb. 2019 um 19:47 Uhr schrieb Paulo Angelo <
> > pa at pauloangelo.com>:
> >
> >> Hi All,
> >>
> >> The GuardianKey extension for KeyCloak is almost complete! Thank you for
> >> the given directions.
> >>
> >> We have to get the user client IP and the status of the authentication
> >> attempt (failed/success). For this, we implemented the code below.
> >> However,
> >> we are facing Null Pointer exceptions.
> >>
> >> public class GuardianKeyAuthenticator implements Authenticator {  // ...
> >> public void authenticate(AuthenticationFlowContext context) {  // ...
> >>          // *Trying to get the Client IP address*
> >>            clientIP =
> >>
> >>
> context.getSession().sessions().getUserSession(context.getAuthenticationSession().getClient().getRealm(),
> >>
> >> context.getAuthenticationSession().getClient().getId())
> >>                                                      .getIpAddress(); /*
> >> getting null pointer exception */
> >>           // *Trying to get the status for the auth attempt
> >> (failed/success), this Authenticator should be the last in the flow*
> >>              failed = context.getStatus().equals(FlowStatus.SUCCESS); /*
> >> getting null pointer exception */
> >>        // ...
> >> } }
> >>
> >> Any clue about how we can do this?
> >>
> >> Thank you in advance.
> >>
> >> Paulo Angelo
> >>
> >>
> >> On Sun, Feb 3, 2019 at 10:21 PM Paulo Angelo <pa at pauloangelo.com>
> wrote:
> >>
> >> > Dmitry and Al?xis,
> >> >
> >> > Thank you very much for the directions. We are going to work on it.
> >> >
> >> > regards,
> >> >
> >> > Paulo Angelo
> >> >
> >> > On Sun, Feb 3, 2019 at 8:06 PM Dmitry Telegin <dt at acutus.pro> wrote:
> >> >
> >> >> Hello Paulo,
> >> >>
> >> >> To add to Alexis's reply, you can use Script authenticator [1]. It's
> >> >> especially good for prototyping since you don't have to create and
> >> deploy
> >> >> the whole provider module.
> >> >>
> >> >> Also, you'll need an HttpClient instance to be able to perform
> external
> >> >> HTTP requests, see [2] for that.
> >> >>
> >> >> [1] https://www.keycloak.org/docs/latest/server_admin/#executions
> >> >> [2]
> >> >>
> >>
> http://lists.jboss.org/pipermail/keycloak-user/2018-November/016456.html
> >> >>
> >> >> Good luck,
> >> >> Dmitry Telegin
> >> >> CTO, Acutus s.r.o.
> >> >> Keycloak Consulting and Training
> >> >>
> >> >> Pod lipami street 339/52, 130 00 Prague 3, Czech Republic
> >> >> +42 (022) 888-30-71
> >> >> E-mail: info at acutus.pro
> >> >>
> >> >> On Sun, 2019-02-03 at 17:46 -0200, Alexis Almeida wrote:
> >> >> > Hi Paulo,
> >> >> >
> >> >> > IMO the simplest way to do this is with an Authenticator Provider.
> >> >> Please
> >> >> > see here:
> >> >> >
> >> >> >
> >> >>
> >>
> https://www.keycloak.org/docs/latest/server_development/index.html#implementing-an-authenticator
> >> >> > .
> >> >> >
> >> >> > In the authenticate method you can call the GuardianKey and,
> >> depending
> >> >> on
> >> >> > the result, you call a context.success () or context.failure ().
> >> >> >
> >> >> > Like this:
> >> >> >
> >> >> > public void authenticate(AuthenticationFlowContext context) {
> >> >> > ...
> >> >> > if(!GuardianKeyValidation){
> >> >> >    Response challenge = context.form()
> >> >> >                 .setError("something")
> >> >> >                 .createForm("error_page.ftl");
> >> >> >
> >> >> >
> >> context.failureChallenge(AuthenticationFlowError.INVALID_CREDENTIALS,
> >> >> > challenge);
> >> >> >    return;
> >> >> > }
> >> >> > ...
> >> >> > context.success();
> >> >> > }
> >> >> >
> >> >> > Al?xis
> >> >> >
> >> >> >
> >> >> > > Em dom, 3 de fev de 2019 ?s 15:38, Paulo Angelo <
> >> pa at pauloangelo.com>
> >> >> > escreveu:
> >> >> >
> >> >> > > Hi all,
> >> >> > >
> >> >> > > We are trying to integrate KeyCloak with GuardianKey. However, we
> >> have
> >> >> > > doubts related to the best way to do this and the best point in
> the
> >> >> > > KeyCloak?s code for this integration.
> >> >> > >
> >> >> > > GuardianKey is a service to protect systems against
> authentication
> >> >> attacks.
> >> >> > > It uses Machine Learning and analyses the user's behavior, threat
> >> >> > > intelligence and psychometrics (or behavioral biometrics). The
> >> >> protected
> >> >> > > system (in the concrete case, KeyCloak) must send an event via
> REST
> >> >> for the
> >> >> > > GuardianKey on each login attempt. More info at
> >> >> https://guardiankey.io .
> >> >> > >
> >> >> > > The best way to integrate would be on having a hook in the
> >> procedure
> >> >> that
> >> >> > > process the user credentials submission in KeyCloak (the script
> >> that
> >> >> > > receives the POST), something such as:
> >> >> > >
> >> >> > > if(<POST IN AUTH FORM>) {
> >> >> > >
> >> >> > >  boolean loginFailed =  checkLoginInKeyCloak();
> >> >> > >
> >> >> > >  GuardianKeyEvent event =
> >> >> createEventForGuardianKey(username,loginFailed);
> >> >> > >
> >> >> > >  boolean GuardianKeyValidation = checkGuardianKeyViaREST(event);
> >> >> > >
> >> >> > >  if(GuardianKeyValidation){
> >> >> > >
> >> >> > >     // Allow access
> >> >> > >
> >> >> > >  } else {
> >> >> > >
> >> >> > >     // Deny access
> >> >> > >
> >> >> > >  }
> >> >> > >
> >> >> > > }
> >> >> > >
> >> >> > > Where is the best place to create this integration? Is there a
> way
> >> to
> >> >> > > create a hook for this purpose? Should we create an extension?
> >> >> > >
> >> >> > > Any help is welcome.
> >> >> > >
> >> >> > > Thank you in advance.
> >> >> > >
> >> >> > > Best regards,
> >> >> > >
> >> >> > > Paulo Angelo
> >> >> > > _______________________________________________
> >> >> > > keycloak-dev mailing list
> >> >> > > keycloak-dev at lists.jboss.org
> >> >> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >> >> >
> >> >> > _______________________________________________
> >> >> > keycloak-dev mailing list
> >> >> > keycloak-dev at lists.jboss.org
> >> >> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >> >> _______________________________________________
> >> >> keycloak-dev mailing list
> >> >> keycloak-dev at lists.jboss.org
> >> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >> >
> >> >
> >> >
> >> > --
> >> >
> >> > Att,
> >> >
> >> > Paulo Angelo
> >> >
> >>
> >>
> >> --
> >>
> >> Att,
> >>
> >> Paulo Angelo
> >> _______________________________________________
> >> 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



-- 

Att,

Paulo Angelo

From sthorger at redhat.com  Mon Feb 18 04:10:58 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 18 Feb 2019 10:10:58 +0100
Subject: [keycloak-dev] Example Setup to simplify the development of
 Keycloak Extensions
In-Reply-To: <CAK-7U1jj7DhuwwSqbZfYDiXBW_HKW69UOvY_k1g5s8K+F0bL2w@mail.gmail.com>
References: <CAK-7U1j1=x1aKwJGG_zXjsSw+qd7_ZEx_3pXb1ie5OyDRqoSyw@mail.gmail.com>
	<CAJgngAdKVWgxtpH9jmoNFRTtuGy5mTDH-q6c7Cjt7Mf0DnN+Fg@mail.gmail.com>
	<CAK-7U1jj7DhuwwSqbZfYDiXBW_HKW69UOvY_k1g5s8K+F0bL2w@mail.gmail.com>
Message-ID: <CAJgngAc3C0CD83LJOpXzU=wDL3fuog0saV7yN5iDkKAPBF6jZg@mail.gmail.com>

Arquillian can use a remote container, which allows you pointing to an
already running Keycloak server, then you simply hot deploy your extension
as part of the tests and it should not need to restart Keycloak.

On Tue, 12 Feb 2019 at 12:32, Thomas Darimont <
thomas.darimont at googlemail.com> wrote:

> HI Stian,
>
> Thanks for the feedback. In my experience using Arquillian is rather slow
> - at least I haven't seen an example setup that doesn't need 30+ seconds
> round-trip time per change (without hot-code replacement). Do you have a
> fast example at hand (< 10sec round-trip time)?
>
> The aforementioned approach is easy to use and makes a cold-start
> round-trip much faster (~5 sec my machine).
> Also one can concentrate on the actual extension development first,
> instead of figuring out the proper packaging of their extension right from
> the beginning, which is IMHO not a nice getting started experience.
>
> Cheers,
> Thomas
>
> Am Di., 12. Feb. 2019 um 12:21 Uhr schrieb Stian Thorgersen <
> sthorger at redhat.com>:
>
>> I'd say it would be better to target the real distribution rather than
>> the KeycloakServer. It should be reasonably easy to setup Arquillian to use
>> the Keycloak distribution from Maven Central and allow it to hot-deploy
>> extensions for testing purposes.
>>
>> On Tue, 12 Feb 2019 at 09:42, Thomas Darimont <
>> thomas.darimont at googlemail.com> wrote:
>>
>>> Hello Keycloak-Team,
>>>
>>> I found a neat setup to simplify the development of Keycloak extensions.
>>> I setup a "keycloak-extension-playground" project that contains two or
>>> more
>>> maven modules:
>>> - keycloak-playground-server
>>> - simple-auth-extension (example)
>>>
>>> In the "keycloak-playground-server" module, I wrap a KeycloakServer from
>>> the "keycloak-testsuite-utils" library where one could potentially add
>>> additional configuration. Note that this library must be in (local) Maven
>>> Repository.
>>>
>>> The "simple-auth-extension" is an example extension module that
>>> demonstrates the usage of the Authenticator SPI.
>>>
>>> I now declare "simple-auth-extension" as a compile time dependency of the
>>> "keycloak-playground-server" project. This ensures that it's classes and
>>> resources are on the classpath of KeycloakServer. Therefore all SPI
>>> implementations in custom extensions can be found. This improves the
>>> debugging experience and speeds up development time.
>>>
>>> The example project can be found here:
>>> https://github.com/thomasdarimont/keycloak-extension-playground
>>>
>>> What do you guys think about this approach?
>>>
>>> Cheers,
>>> Thomas
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>

From slaskawi at redhat.com  Mon Feb 18 04:15:15 2019
From: slaskawi at redhat.com (Sebastian Laskawiec)
Date: Mon, 18 Feb 2019 10:15:15 +0100
Subject: [keycloak-dev] What Jetty versions we want to support?
In-Reply-To: <CAA9R9O7Ku-A6y-sGT=+pnKqoLQGqBPXVFa+nu5wiGPBCR5kZQQ@mail.gmail.com>
References: <CAA9R9O5hqjn577MjtMfFT1hGQJxhYivFwPdOfd6dOuG76k+v7A@mail.gmail.com>
	<CAJgngAfA2YLWQ5R4EzidkUdQe0oq=pA__0k5tUQoXLrFGP_5-w@mail.gmail.com>
	<CAA9R9O4oqKfq8jOkwV2hQNiH2x=Ci7VQ9VYGMOpCU4kWQ6LdRQ@mail.gmail.com>
	<CAMvXD=EyCVC7C6sNwQLW+SmacKjpvibpr0fUndjEEN2H1FBGUA@mail.gmail.com>
	<CAA9R9O7Ku-A6y-sGT=+pnKqoLQGqBPXVFa+nu5wiGPBCR5kZQQ@mail.gmail.com>
Message-ID: <CAA9R9O5babsso5WPswNYS9B2R71TVdRqRk_Lnfj72jFjY48UjA@mail.gmail.com>

One more thing to add - we may want to talk with Fuse guys about Jetty 8.1
since it's end of life [1].

Can anyone contact of off-list and point out a contact on Fuse side to talk
about this?

[1] https://wiki.eclipse.org/Jetty/Howto/Configure_JSP
etty 7 and Jetty 8 are now EOL (End of Life)
All development and stable releases are being performed with Jetty 9.
This wiki is now officially out of date and all content has been moved to
the Jetty Documentation Hub
Direct Link to updated documentation:
http://www.eclipse.org/jetty/documentation/current/configuring-jsp.html

On Wed, Feb 13, 2019 at 2:55 PM Sebastian Laskawiec <slaskawi at redhat.com>
wrote:

> So it seems we have our support matrix:
> - 8.1 (because of Fuse)
> - 9.2 (heavily used by the community and required by Fuse)
> - 9.3 (heavily used by the community)
> - 9.4 (it's the latest version)
>
> So we might consider dropping 9.3 at some point in favor of 9.4. But
> that's something to think of and probably not for now.
>
> On Tue, Feb 12, 2019 at 5:25 PM Hynek Mlnarik <hmlnarik at redhat.com> wrote:
>
>> For Fuse, we use 8.1 [1] and 9.2 [2].
>>
>> --Hynek
>>
>> [1]
>> https://github.com/keycloak/keycloak/blob/4.8.3.Final/distribution/adapters/osgi/features/src/main/resources/features.xml#L54
>> [2]
>> https://github.com/keycloak/keycloak/blob/4.8.3.Final/distribution/adapters/osgi/features/src/main/resources/features.xml#L63
>>
>> On Tue, Feb 12, 2019 at 12:05 PM Sebastian Laskawiec <slaskawi at redhat.com>
>> wrote:
>>
>>> Ok, understood! Thanks a lot for the info Stian!
>>>
>>> On Tue, Feb 12, 2019 at 11:48 AM Stian Thorgersen <sthorger at redhat.com>
>>> wrote:
>>>
>>> > We test them until we remove ;)
>>> >
>>> > 8.1 and 9.1 have already been removed from the community. We need to
>>> > confirm if these are needed by Fuse (we don't support Jetty directly
>>> for
>>> > RH-SSO, but rather only through Fuse). If Fuse relies on these we need
>>> to
>>> > continue testing them.
>>> >
>>> > 9.2 and 9.3 still has users in the community (25 dls of each the last 3
>>> > months, but that is only direct dls through website, not sure if folks
>>> also
>>> > use them from Maven central). We should keep these for now though and
>>> > consider deprecating at some point in the future.
>>> >
>>> > On Tue, 12 Feb 2019 at 10:24, Sebastian Laskawiec <slaskawi at redhat.com
>>> >
>>> > wrote:
>>> >
>>> >> Hey guys,
>>> >>
>>> >> I'm working on moving Jetty adapter tests from the old testsuite into
>>> the
>>> >> new one. I can see we support this Jetty versions [1]:
>>> >> - 8.1
>>> >> - 9.1
>>> >> - 9.2
>>> >> - 9.3
>>> >> - 9.4
>>> >>
>>> >> Do we want to keep it this way or maybe concentrate on testing
>>> adapters
>>> >> against 8.1 and 9.4 only (the last major versions)?
>>> >>
>>> >> Thanks,
>>> >> Sebastian
>>> >>
>>> >> [1] grep -lir "keycloak-saml-jetty" --include="*.xml"
>>> >>
>>> > _______________________________________________
>>> >> 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  Mon Feb 18 04:15:25 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 18 Feb 2019 10:15:25 +0100
Subject: [keycloak-dev] Example Setup to simplify the development of
 Keycloak Extensions
In-Reply-To: <CAJgngAc3C0CD83LJOpXzU=wDL3fuog0saV7yN5iDkKAPBF6jZg@mail.gmail.com>
References: <CAK-7U1j1=x1aKwJGG_zXjsSw+qd7_ZEx_3pXb1ie5OyDRqoSyw@mail.gmail.com>
	<CAJgngAdKVWgxtpH9jmoNFRTtuGy5mTDH-q6c7Cjt7Mf0DnN+Fg@mail.gmail.com>
	<CAK-7U1jj7DhuwwSqbZfYDiXBW_HKW69UOvY_k1g5s8K+F0bL2w@mail.gmail.com>
	<CAJgngAc3C0CD83LJOpXzU=wDL3fuog0saV7yN5iDkKAPBF6jZg@mail.gmail.com>
Message-ID: <CAJgngAdvRaryA-igtgwAk-=htUMR3g_QP8VooY=kU3JNhwg9NA@mail.gmail.com>

Adding a few reasons why it should target a real distro and not the
KeycloakServer internal util:

* KeycloakServer is an internal util that we use for our testsuite. This is
not something we will support publicly as we need to be able to change this
without considering backwards compatibility.
* As an extension developer you should not modify Keycloak code itself.
This is actually what makes our testsuite more complex as we do need to be
able to quickly run tests with a modified Keycloak server.
* Using a dist you can test it properly. There is no guarantee that your
extension will work deployed to Keycloak dist if it works on
KeycloakServer. Classpath being one main issue here, but there are other
caveats as well. So you end up having to run your tests twice (once with
embedded Keycloak for development and second with proper dist for proper
testing)

For the above reasons although this is a nice approach for now it's not
very future proof and I'd rather see efforts being put into doing it
"properly" and improving on that experience than working around it.

On Mon, 18 Feb 2019 at 10:10, Stian Thorgersen <sthorger at redhat.com> wrote:

> Arquillian can use a remote container, which allows you pointing to an
> already running Keycloak server, then you simply hot deploy your extension
> as part of the tests and it should not need to restart Keycloak.
>
> On Tue, 12 Feb 2019 at 12:32, Thomas Darimont <
> thomas.darimont at googlemail.com> wrote:
>
>> HI Stian,
>>
>> Thanks for the feedback. In my experience using Arquillian is rather slow
>> - at least I haven't seen an example setup that doesn't need 30+ seconds
>> round-trip time per change (without hot-code replacement). Do you have a
>> fast example at hand (< 10sec round-trip time)?
>>
>> The aforementioned approach is easy to use and makes a cold-start
>> round-trip much faster (~5 sec my machine).
>> Also one can concentrate on the actual extension development first,
>> instead of figuring out the proper packaging of their extension right from
>> the beginning, which is IMHO not a nice getting started experience.
>>
>> Cheers,
>> Thomas
>>
>> Am Di., 12. Feb. 2019 um 12:21 Uhr schrieb Stian Thorgersen <
>> sthorger at redhat.com>:
>>
>>> I'd say it would be better to target the real distribution rather than
>>> the KeycloakServer. It should be reasonably easy to setup Arquillian to use
>>> the Keycloak distribution from Maven Central and allow it to hot-deploy
>>> extensions for testing purposes.
>>>
>>> On Tue, 12 Feb 2019 at 09:42, Thomas Darimont <
>>> thomas.darimont at googlemail.com> wrote:
>>>
>>>> Hello Keycloak-Team,
>>>>
>>>> I found a neat setup to simplify the development of Keycloak extensions.
>>>> I setup a "keycloak-extension-playground" project that contains two or
>>>> more
>>>> maven modules:
>>>> - keycloak-playground-server
>>>> - simple-auth-extension (example)
>>>>
>>>> In the "keycloak-playground-server" module, I wrap a KeycloakServer from
>>>> the "keycloak-testsuite-utils" library where one could potentially add
>>>> additional configuration. Note that this library must be in (local)
>>>> Maven
>>>> Repository.
>>>>
>>>> The "simple-auth-extension" is an example extension module that
>>>> demonstrates the usage of the Authenticator SPI.
>>>>
>>>> I now declare "simple-auth-extension" as a compile time dependency of
>>>> the
>>>> "keycloak-playground-server" project. This ensures that it's classes and
>>>> resources are on the classpath of KeycloakServer. Therefore all SPI
>>>> implementations in custom extensions can be found. This improves the
>>>> debugging experience and speeds up development time.
>>>>
>>>> The example project can be found here:
>>>> https://github.com/thomasdarimont/keycloak-extension-playground
>>>>
>>>> What do you guys think about this approach?
>>>>
>>>> Cheers,
>>>> Thomas
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>>

From sthorger at redhat.com  Mon Feb 18 04:18:11 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 18 Feb 2019 10:18:11 +0100
Subject: [keycloak-dev] Introduce GolangCI to Gatekeeper repository
In-Reply-To: <20190213131457.GA31743@abstractj.org>
References: <20190213131457.GA31743@abstractj.org>
Message-ID: <CAJgngAe3zg4C-Of-yk2mr3SOuWLgT4BVt69Jh1_momGkuU2K-Q@mail.gmail.com>

If it's easy to setup why not try and see? We can always re-evaluate in the
future if benefits vs costs ratio is not correct.

On Wed, 13 Feb 2019 at 14:29, Bruno Oliveira <bruno at abstractj.org> wrote:

> Good morning,
>
> A week ago Frederic, one of our contributors, suggested the
> inclusion of GolangCI[1][2]. For those not familiar,
> GolangCI can run a set of linters against the source tree. It can
> check if the code respects the code style, if there are vulnerabilities
> introduced into the codebase and also advise on best practices.
>
> Even though I think it's something nice to have, I'm afraid that
> GolangCI could add too much noise commenting on PRs (I'm not
> sure if this can be disabled).
>
> Even though is something cool, I'm 50/50 on this. I don't see the
> adoption from big projects like Openshift or Kubernetes.
>
> Thoughts?
>
> [1] - https://github.com/keycloak/keycloak-gatekeeper/pull/454
> [2] - https://golangci.com/
>
> --
>
> abstractj
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sthorger at redhat.com  Mon Feb 18 04:19:55 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 18 Feb 2019 10:19:55 +0100
Subject: [keycloak-dev] What Jetty versions we want to support?
In-Reply-To: <CAA9R9O5babsso5WPswNYS9B2R71TVdRqRk_Lnfj72jFjY48UjA@mail.gmail.com>
References: <CAA9R9O5hqjn577MjtMfFT1hGQJxhYivFwPdOfd6dOuG76k+v7A@mail.gmail.com>
	<CAJgngAfA2YLWQ5R4EzidkUdQe0oq=pA__0k5tUQoXLrFGP_5-w@mail.gmail.com>
	<CAA9R9O4oqKfq8jOkwV2hQNiH2x=Ci7VQ9VYGMOpCU4kWQ6LdRQ@mail.gmail.com>
	<CAMvXD=EyCVC7C6sNwQLW+SmacKjpvibpr0fUndjEEN2H1FBGUA@mail.gmail.com>
	<CAA9R9O7Ku-A6y-sGT=+pnKqoLQGqBPXVFa+nu5wiGPBCR5kZQQ@mail.gmail.com>
	<CAA9R9O5babsso5WPswNYS9B2R71TVdRqRk_Lnfj72jFjY48UjA@mail.gmail.com>
Message-ID: <CAJgngAfoKJh0q8X3fXztAdTQP9W+NUhYAzKm-T0wfxe9B6GhDw@mail.gmail.com>

EOL in community sure, but Fuse have longer support cadence than Jetty
community releases. Jetty 8.1 needs to be supported until whatever Fuse
version that uses it is EOL.

On Mon, 18 Feb 2019 at 10:15, Sebastian Laskawiec <slaskawi at redhat.com>
wrote:

> One more thing to add - we may want to talk with Fuse guys about Jetty 8.1
> since it's end of life [1].
>
> Can anyone contact of off-list and point out a contact on Fuse side to
> talk about this?
>
> [1] https://wiki.eclipse.org/Jetty/Howto/Configure_JSP
> etty 7 and Jetty 8 are now EOL (End of Life)
> All development and stable releases are being performed with Jetty 9.
> This wiki is now officially out of date and all content has been moved to
> the Jetty Documentation Hub
> Direct Link to updated documentation:
> http://www.eclipse.org/jetty/documentation/current/configuring-jsp.html
>
> On Wed, Feb 13, 2019 at 2:55 PM Sebastian Laskawiec <slaskawi at redhat.com>
> wrote:
>
>> So it seems we have our support matrix:
>> - 8.1 (because of Fuse)
>> - 9.2 (heavily used by the community and required by Fuse)
>> - 9.3 (heavily used by the community)
>> - 9.4 (it's the latest version)
>>
>> So we might consider dropping 9.3 at some point in favor of 9.4. But
>> that's something to think of and probably not for now.
>>
>> On Tue, Feb 12, 2019 at 5:25 PM Hynek Mlnarik <hmlnarik at redhat.com>
>> wrote:
>>
>>> For Fuse, we use 8.1 [1] and 9.2 [2].
>>>
>>> --Hynek
>>>
>>> [1]
>>> https://github.com/keycloak/keycloak/blob/4.8.3.Final/distribution/adapters/osgi/features/src/main/resources/features.xml#L54
>>> [2]
>>> https://github.com/keycloak/keycloak/blob/4.8.3.Final/distribution/adapters/osgi/features/src/main/resources/features.xml#L63
>>>
>>> On Tue, Feb 12, 2019 at 12:05 PM Sebastian Laskawiec <
>>> slaskawi at redhat.com> wrote:
>>>
>>>> Ok, understood! Thanks a lot for the info Stian!
>>>>
>>>> On Tue, Feb 12, 2019 at 11:48 AM Stian Thorgersen <sthorger at redhat.com>
>>>> wrote:
>>>>
>>>> > We test them until we remove ;)
>>>> >
>>>> > 8.1 and 9.1 have already been removed from the community. We need to
>>>> > confirm if these are needed by Fuse (we don't support Jetty directly
>>>> for
>>>> > RH-SSO, but rather only through Fuse). If Fuse relies on these we
>>>> need to
>>>> > continue testing them.
>>>> >
>>>> > 9.2 and 9.3 still has users in the community (25 dls of each the last
>>>> 3
>>>> > months, but that is only direct dls through website, not sure if
>>>> folks also
>>>> > use them from Maven central). We should keep these for now though and
>>>> > consider deprecating at some point in the future.
>>>> >
>>>> > On Tue, 12 Feb 2019 at 10:24, Sebastian Laskawiec <
>>>> slaskawi at redhat.com>
>>>> > wrote:
>>>> >
>>>> >> Hey guys,
>>>> >>
>>>> >> I'm working on moving Jetty adapter tests from the old testsuite
>>>> into the
>>>> >> new one. I can see we support this Jetty versions [1]:
>>>> >> - 8.1
>>>> >> - 9.1
>>>> >> - 9.2
>>>> >> - 9.3
>>>> >> - 9.4
>>>> >>
>>>> >> Do we want to keep it this way or maybe concentrate on testing
>>>> adapters
>>>> >> against 8.1 and 9.4 only (the last major versions)?
>>>> >>
>>>> >> Thanks,
>>>> >> Sebastian
>>>> >>
>>>> >> [1] grep -lir "keycloak-saml-jetty" --include="*.xml"
>>>> >>
>>>> > _______________________________________________
>>>> >> 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 bruno at abstractj.org  Mon Feb 18 04:24:51 2019
From: bruno at abstractj.org (Bruno Oliveira)
Date: Mon, 18 Feb 2019 06:24:51 -0300
Subject: [keycloak-dev] Introduce GolangCI to Gatekeeper repository
In-Reply-To: <CAJgngAe3zg4C-Of-yk2mr3SOuWLgT4BVt69Jh1_momGkuU2K-Q@mail.gmail.com>
References: <20190213131457.GA31743@abstractj.org>
	<CAJgngAe3zg4C-Of-yk2mr3SOuWLgT4BVt69Jh1_momGkuU2K-Q@mail.gmail.com>
Message-ID: <CAM5SUC4Mc6CjLB2zt1vTywRVyvpHqP=6oofd-ns_DH3Ha9zqMA@mail.gmail.com>

Thank you. Merged.

I don't have admin rights over the repository. Could you please enable
it here: https://golangci.com/repos/github

On Mon, Feb 18, 2019 at 6:18 AM Stian Thorgersen <sthorger at redhat.com> wrote:
>
> If it's easy to setup why not try and see? We can always re-evaluate in the future if benefits vs costs ratio is not correct.
>
> On Wed, 13 Feb 2019 at 14:29, Bruno Oliveira <bruno at abstractj.org> wrote:
>>
>> Good morning,
>>
>> A week ago Frederic, one of our contributors, suggested the
>> inclusion of GolangCI[1][2]. For those not familiar,
>> GolangCI can run a set of linters against the source tree. It can
>> check if the code respects the code style, if there are vulnerabilities
>> introduced into the codebase and also advise on best practices.
>>
>> Even though I think it's something nice to have, I'm afraid that
>> GolangCI could add too much noise commenting on PRs (I'm not
>> sure if this can be disabled).
>>
>> Even though is something cool, I'm 50/50 on this. I don't see the
>> adoption from big projects like Openshift or Kubernetes.
>>
>> Thoughts?
>>
>> [1] - https://github.com/keycloak/keycloak-gatekeeper/pull/454
>> [2] - https://golangci.com/
>>
>> --
>>
>> abstractj
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev



-- 
- abstractj

From sthorger at redhat.com  Mon Feb 18 04:28:13 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 18 Feb 2019 10:28:13 +0100
Subject: [keycloak-dev] Running custom scripts in Keycloak container
	image
In-Reply-To: <CAM5SUC7wRzA0_zB-Dn61oqO4emVBgwi71Cx1OJ+dcs2N76B-Ag@mail.gmail.com>
References: <CAA9R9O4-0-3D0pLyquAVjHN7qKb=NZosPH-iu51OA2oNXfM99A@mail.gmail.com>
	<CAK-7U1jdW-g4bcNbjoDG3yxST3rKHJXn+Zideed4EQTwWGWWew@mail.gmail.com>
	<CAJrcDBe+7RZ5iiOw_91o3NC9=c+QWrnBkEWixmxBeFQf=eR6cw@mail.gmail.com>
	<CAA9R9O7BBjeMeXUd6YFkMs_YpDXeeq0g8TSzzzeT5n1ySgAVog@mail.gmail.com>
	<CAA9R9O6nZbdfqcJF7dehLFTK_rokE7MOYh9Vm0P6n-7MPprgXQ@mail.gmail.com>
	<CAM5SUC7wRzA0_zB-Dn61oqO4emVBgwi71Cx1OJ+dcs2N76B-Ag@mail.gmail.com>
Message-ID: <CAJgngAcVrZLjmGwg7A3fqFyxaGRoSPxBQouRs9GsdQ=dMe30eg@mail.gmail.com>

I like the idea. Docs should cover how to add the scripts (extend image and
mount). The dir name should be changed to something more sensible. Should
probably also have a note that CLI scripts and especially other types of
scripts won't always be backwards compatible and may need updating from
release to release.

On Thu, 14 Feb 2019 at 13:26, Bruno Oliveira <bruno at abstractj.org> wrote:

> +1 on Pedro's comments. Other than that, let's add this.
>
> On Thu, Feb 14, 2019 at 8:53 AM Sebastian Laskawiec <slaskawi at redhat.com>
> wrote:
> >
> > So, are there any comments regarding to this?
> >
> > If not, I'll add some suggestions to the PR and generally approve this
> > direction.
> >
> > On Wed, Feb 13, 2019 at 2:53 PM Sebastian Laskawiec <slaskawi at redhat.com
> >
> > wrote:
> >
> > > Yes, that's the idea how this can work.
> > >
> > > On Tue, Feb 12, 2019 at 4:19 PM Pedro Igor Silva <psilva at redhat.com>
> > > wrote:
> > >
> > >> Regarding the PR from Wouter. Instead of extending the image would be
> > >> possible to attach a volume with the scripts that need to be run on
> > >> startup? That would avoid the burden of creating a new image to only
> add a
> > >> few files into a directory.
> > >>
> > >> On Tue, Feb 12, 2019 at 12:37 PM Thomas Darimont <
> > >> thomas.darimont at googlemail.com> wrote:
> > >>
> > >>> Hello,
> > >>>
> > >>> I'm one of the maintainers of the Keycloak helm chart:
> > >>> https://github.com/helm/charts/tree/master/stable/keycloak
> > >>> Since a lot of our users need to adjust the default configuration
> that is
> > >>> provided by the Keycloak docker images, we currently generate a
> > >>> keycloak.cli file that we apply during start. However, some of this
> > >>> configuration is again overridden by the defaults from the Keycloak
> > >>> docker
> > >>> image.
> > >>>
> > >>> See:
> > >>>
> > >>>
> https://github.com/helm/charts/blob/master/stable/keycloak/templates/configmap.yaml#L12
> > >>> Configuration:
> > >>>
> > >>>
> https://github.com/helm/charts/blob/master/stable/keycloak/values.yaml#L121
> > >>>
> > >>> Having dedicated support for config customizations at bootstrap in
> the
> > >>> stock Keycloak image would make things much easier here :)
> > >>>
> > >>> Cheers,
> > >>> Thomas
> > >>>
> > >>> Am Di., 12. Feb. 2019 um 14:42 Uhr schrieb Sebastian Laskawiec <
> > >>> slaskawi at redhat.com>:
> > >>>
> > >>> > Hey guys,
> > >>> >
> > >>> > A while ago, one of our contributors, Wouter, sent an interesting
> pull
> > >>> > request: https://github.com/jboss-dockerfiles/keycloak/pull/176
> > >>> >
> > >>> > The aim is to allow running custom scripts just before Keycloak
> boots
> > >>> up
> > >>> > and after the main configuration is done. This allows a user to
> inject
> > >>> his
> > >>> > own scripts (even *.cli) into /opt/jboss/tools/docker-entrypoint.d
> and
> > >>> > execute them automatically.
> > >>> >
> > >>> > This is somewhat related to what the Integrately Team is doing.
> They
> > >>> > basically use an InitContainer [1] to put additional extensions
> into
> > >>> our
> > >>> > image. Perhaps with the proposed approach, they could embed a
> custom
> > >>> script
> > >>> > that would download whatever extensions they need and put them
> into the
> > >>> > deployments directory?
> > >>> >
> > >>> > After thinking about this for a while, and besides really good
> > >>> advantages
> > >>> > of the Pull Request, I have some doubts. The biggest one is about
> our
> > >>> > guarantees with regard the Keycloak distribution (by saying
> > >>> distribution I
> > >>> > mean the binaries, their structure and Keycloak server location in
> the
> > >>> > image). If we accept this approach, it will be pretty hard for us
> to
> > >>> change
> > >>> > any major thing (even some trivial things like the location of the
> > >>> Keycloak
> > >>> > Server) without breaking the client scripts.
> > >>> >
> > >>> > Personally, I'm slightly leaning towards accepting this feature,
> but
> > >>> with a
> > >>> > description in README, that the user scripts may break at any time
> and
> > >>> in
> > >>> > any version (maybe even we should print this message in our logs).
> > >>> This way
> > >>> > we'll make the contract for such scripts very clear.
> > >>> >
> > >>> > What do you think?
> > >>> >
> > >>> > Thanks,
> > >>> > Sebastian
> > >>> >
> > >>> > [1]
> > >>> https://kubernetes.io/docs/concepts/workloads/pods/init-containers/
> > >>> > _______________________________________________
> > >>> > keycloak-dev mailing list
> > >>> > keycloak-dev at lists.jboss.org
> > >>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > >>> >
> > >>> _______________________________________________
> > >>> keycloak-dev mailing list
> > >>> keycloak-dev at lists.jboss.org
> > >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > >>>
> > >>
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
> --
> - abstractj
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sthorger at redhat.com  Mon Feb 18 04:29:28 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 18 Feb 2019 10:29:28 +0100
Subject: [keycloak-dev] OIDC Discovery-enabled IdentityProvider
In-Reply-To: <CA+AQu3wgT4B1+Msva=9DOp=Po-s7GDCapY1+Gs-E4q_cE+jR2g@mail.gmail.com>
References: <00aa01d4ac7b$a7767460$f6635d20$@gmail.com>
	<1914838141.50603473.1547562353763.JavaMail.zimbra@redhat.com>
	<38415268.50625497.1547566301029.JavaMail.zimbra@redhat.com>
	<CA+AQu3yKjkTU2XCaiE1-xbfyn3idiswk5OWSsLxNnZRKsMFJWA@mail.gmail.com>
	<CAJgngAccFbcFOE4Dt4v=R-WXky9mdmGPZqzDvwi3AthrBLOjvQ@mail.gmail.com>
	<CA+AQu3waQr+Zdm1kA_PwoghNfcDzzhttc56saxTEhhxRXwy7Eg@mail.gmail.com>
	<CAJgngAeJn1jSQRk-7yZzaYfDTYE_Ww5pE9MgyumPCkSfYa4tQw@mail.gmail.com>
	<CA+AQu3yuSeN+pOFRwuDR-2CdNvNVPjoHv=xEmTNS5pHHv1qR8Q@mail.gmail.com>
	<CA+AQu3z4JTTSCQU0g9m5VV5SFYUk92-sA1hqT-AedPZRotmcCw@mail.gmail.com>
	<CAJgngAf-w-=Pwvu0JLGkAJ0ipPs9v8noPUdbkvsiG52RobKGSA@mail.gmail.com>
	<CA+AQu3zu8KXvtGVJLgHxZ+dno-5f9tBYgd6UU5NJGOXBAZjT=w@mail.gmail.com>
	<CAJgngAdyEzhrx5Zk9DQH6Gd5xwjTxkGaP2WaZGmmEmCUj5jC=A@mail.gmail.com>
	<CA+AQu3wgT4B1+Msva=9DOp=Po-s7GDCapY1+Gs-E4q_cE+jR2g@mail.gmail.com>
Message-ID: <CAJgngAc6u4cX6yQ9RcL78oqfpbTdLv3xUj-27ych8+5V6pabyQ@mail.gmail.com>

Adding a cache is not trivial as there's quite a few places it needs to be
added. I can't remember exactly where, but you should be able to find it by
simply searching for other caches that we define.

On Fri, 15 Feb 2019 at 03:33, James Campbell <james.p.campbell at gmail.com>
wrote:

> Thanks, Stian--the more detailed documentation inside the
> integration-arquillian folder helped understand the tests better.
>
> I've been able to read through a lot more on the tests, and I thought I
> had a picture of how to extend the current tests, but when I tried directly
> it seems that there must be configuration elements of the testing
> infrastructure itself that I'm not finding. Specifically, the code I added
> uses a new Infinispan cache to hold the configs, and I have been able to
> successfully test it via a manual build and run of keycloak. However,
> running inside the test harness gives me an error that the cache is not
> configured. I suspect I just don't know where the relevant XML and/or
> DeploymentProcessors are located for the testing framework.
>
> If there's a path to making the work I did useful, I'm game for it, but
> I'd need some more hints I'm sure to make it through the proper
> implementation of the tests.
>
> James
>
>
>
> On Wed, Feb 6, 2019 at 5:30 AM Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>>
>>
>> On Wed, 6 Feb 2019 at 02:27, James Campbell <james.p.campbell at gmail.com>
>> wrote:
>>
>>> Inline...
>>>
>>> On Tue, Feb 5, 2019 at 3:45 AM Stian Thorgersen <sthorger at redhat.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Mon, 4 Feb 2019 at 05:14, James Campbell <james.p.campbell at gmail.com>
>>>> wrote:
>>>>
>>>>> All--
>>>>>
>>>>> Thanks to Stian's recommendations for similar features in the
>>>>> codebase, I've developed a proposal for how to implement this feature, and
>>>>> sketched out an initial implementation. As he suggested, I'd like to get
>>>>> feedback before opening up a PR.
>>>>>
>>>>> 1. We introduce a new subclass of the OIDCIdentityProvider / Factory
>>>>> called OIDCDiscoveryIdentityProvider. The new class adds a discoverConfig
>>>>> method that can be used to discover and set all relevant endpoints in a
>>>>> configuration except the issuer. Issuer then becomes the sole required
>>>>> element of the config. (So the GoogleIdentityProvider, for example, will
>>>>> then just call discoverConfig with its hard-coded issuer).
>>>>>    -> During the parseConfig call, the Factory will raise a
>>>>> RuntimeException if the config cannot be obtained, since if the config can
>>>>> never be obtained there is no way to have a valid configuration at all.
>>>>>    -> During the discoverConfig call, we return the cached value, and
>>>>> optionally refresh it based on when we last obtained the configuration.
>>>>>    -> In the event of a failure in the *refresh* I'm imagining the
>>>>> best behavior is to log a warning but then return the cached config (last
>>>>> known good config).
>>>>>
>>>>
>>>> This should just be added to the OIDCIdentityProvider directly rather
>>>> than a subclass. Perhaps we should have an option to configure how
>>>> frequently the configuration is reloaded.
>>>>
>>>
>>> Makes sense, thank you.
>>>
>>>
>>>>
>>>>> 2. We introduce an SPI and interface called
>>>>> OIDCDiscoveryRepresentationProvider / Factory and implementations called
>>>>> Infinispan... which obtains OIDCConfigurationRepresentations using the
>>>>> /.well-known/openid-configuration endpoint on the issuer.
>>>>>
>>>>> I have a couple questions:
>>>>>
>>>>> 1. I began an implementation of this, but the @JsonProperty
>>>>> annotations on the existing OIDCCOnfigurationRepresentation class seem to
>>>>> be ignored when I try to have it read from the openid-configuration
>>>>> docuement, e.g.:
>>>>>   - OIDCConfigurationRepresentation rep = SimpleHttp.doGet(issuer +
>>>>> "/.well-known/openid-configuration",
>>>>> session).asJson(OIDCConfigurationRepresentation.class); // FAILS with
>>>>> "Unrecognized field ..." Perhaps a mismatch of the jackson annotation
>>>>> version in the keycloak-model-infinispan submodule?
>>>>>
>>>>
>>>> Is the unknown field actually mapped or is the ignore unknown fields
>>>> option enabled? The ignore unknown fields should probably be enabled as
>>>> there may be unknown elements in the config.
>>>>
>>>
>>> The unknown field in this case was authorization_endpoint (so yes,
>>> mapped, and in code that I did not change). I wondered whether perhaps the
>>> issue is that I was doing this from inside the keycloak-model-infinispan
>>> module, and a conflicting JSON parser dependency is in play? I did try
>>> adding the @JsonIgnoreProperties annotation as well, to no avail. My
>>> suspicion is just based on (1) the current class correctly supporting
>>> deserialization in existing tests, and (2) a search of common causes for
>>> this error (which I've not encountered before).
>>>
>>
>> Is this from unit tests within the keycloak-model-infinispan module or
>> test in the Arquillian testsuite? If the latter it should pick up the
>> correct serializer. It has to be the fasterxml one otherwise the
>> annotations will be ignored.
>>
>>
>>>
>>>
>>>>
>>>>
>>>>>
>>>>> 2. Assuming the design above makes sense, what is the right way to
>>>>> plug this into the testing framework? Is one of the core developers
>>>>> interested in tackling that aspect if I push a PR with the above features
>>>>> implemented?
>>>>>
>>>>
>>>> We are very reluctant to receive PRs from the community that do not
>>>> include tests. Think about it, would you as a developer like to implement
>>>> tests for other developers? We can help give you recommendations on how to
>>>> test it though.
>>>>
>>>>
>>>
>>> Definitely makes sense; I just didn't see any documentation on the
>>> testing framework at all, whereas there is documentation on the core server
>>> development components. Happy to either take a look at docs you flag, or to
>>> work from any recommendations you have (I certainly wasn't thinking a PR
>>> would be ready without tests!). The current testing system is pretty opaque
>>> to me.
>>>
>>
>> We have an Arquillian based testsuite that allows us to write functional
>> tests with all the benefits of unit tests. The testsuite allows running
>> tests from within the IDE (uses Keycloak with an embedded Undertow server)
>> and also run them against a proper built Keycloak on top of WildFly from
>> the command line.
>>
>> Some details are here:
>>
>> https://github.com/keycloak/keycloak/tree/master/testsuite/integration-arquillian
>>
>> To understand how to write the tests and run them try to run any test
>> inside testsuite/integration-arquillian/tests/base/src/test from the IDE.
>>
>> Identity brokering tests are under
>> testsuite/integration-arquillian/tests/base/src/test/java/org/keycloak/testsuite/broker.
>> You should be able to relatively easily extend these tests to include
>> testing of OIDC well-known endpoints. We also have support in the testsuite
>> to run code directly on the server (embedded or external) to be able to
>> probe inside the server if needed. Take a look at
>> https://github.com/keycloak/keycloak/blob/master/testsuite/integration-arquillian/tests/base/src/test/java/org/keycloak/testsuite/runonserver/RunOnServerTest.java
>> as an example on how to do that.
>>
>>
>>
>>>
>>>
>>>
>>>>
>>>>> James
>>>>>
>>>>> On Sun, Jan 27, 2019 at 11:15 AM James Campbell <
>>>>> james.p.campbell at gmail.com> wrote:
>>>>>
>>>>>> Got it; I checked that code out and it does look like a pretty direct
>>>>>> model for the refreshing feature. I'll begin working on a PR.
>>>>>>
>>>>>> On Mon, Jan 21, 2019 at 3:25 AM Stian Thorgersen <sthorger at redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>>> JWKs used by identity brokering and client authentication.
>>>>>>>
>>>>>>> On Sat, 19 Jan 2019 at 23:29, James Campbell <
>>>>>>> james.p.campbell at gmail.com> wrote:
>>>>>>>
>>>>>>>> Stian--
>>>>>>>>
>>>>>>>> Thanks for confirming. Which keys are you referring to--I'll take a
>>>>>>>> look at that in the code and try to follow that pattern closely.
>>>>>>>>
>>>>>>>> James
>>>>>>>>
>>>>>>>> On Wed, Jan 16, 2019 at 1:52 AM Stian Thorgersen <
>>>>>>>> sthorger at redhat.com> wrote:
>>>>>>>>
>>>>>>>>> It would be good to get these changes included. We do something
>>>>>>>>> similar for the keys today and they are cached in an Infinispan local
>>>>>>>>> cache. Could do something similar for the OIDC discovery/config.
>>>>>>>>>
>>>>>>>>> On Tue, 15 Jan 2019 at 17:44, James Campbell <
>>>>>>>>> james.p.campbell at gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> Tomas--
>>>>>>>>>>
>>>>>>>>>> Thanks--it certainly seems close, you're right! It looks, however
>>>>>>>>>> like an
>>>>>>>>>> OIDC provider still uses a static configuration even though it
>>>>>>>>>> loads it
>>>>>>>>>> from the discovery URL--that is, once it's loaded at
>>>>>>>>>> configuraiton time, it
>>>>>>>>>> doesn't discover new changes, and there isn't an option to
>>>>>>>>>> refresh/store
>>>>>>>>>> that discovery endpoint outside of configuration.
>>>>>>>>>>
>>>>>>>>>> It's not clear to me how important that feature is--on one hand,
>>>>>>>>>> it seems
>>>>>>>>>> unlikely that we should expect frequent changes; on the other, in
>>>>>>>>>> the short
>>>>>>>>>> time since I started exploring this setup, I have encountered
>>>>>>>>>> three changes
>>>>>>>>>> in google's OIDC endpoints between what was hard-coded into
>>>>>>>>>> keycloak, what
>>>>>>>>>> is in their documentation, and what their current discovery
>>>>>>>>>> endpoint
>>>>>>>>>> provides. (And, the google docs specifically suggest refreshing
>>>>>>>>>> from the
>>>>>>>>>> endpoint periodically).
>>>>>>>>>>
>>>>>>>>>> Thoughts?
>>>>>>>>>>
>>>>>>>>>> James
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Tue, Jan 15, 2019 at 10:31 AM Tomas Kyjovsky <
>>>>>>>>>> tkyjovsk at redhat.com> wrote:
>>>>>>>>>>
>>>>>>>>>> > Please disregard my previous message.
>>>>>>>>>> >
>>>>>>>>>> > Looking at the docs [1] and the Admin Console UI this should be
>>>>>>>>>> already
>>>>>>>>>> > possible with the OIDC identity provider.
>>>>>>>>>> > When creating a OIDC identity provider in the Admin Console
>>>>>>>>>> there is an
>>>>>>>>>> > option at the bottom of the page to import OIDC configuration
>>>>>>>>>> metadata from
>>>>>>>>>> > URL.
>>>>>>>>>> >
>>>>>>>>>> > Does this cover your use case?
>>>>>>>>>> >
>>>>>>>>>> >
>>>>>>>>>> > Regards,
>>>>>>>>>> > Tomas
>>>>>>>>>> >
>>>>>>>>>> > [1]
>>>>>>>>>> >
>>>>>>>>>> https://www.keycloak.org/docs/latest/server_admin/index.html#openid-connect-v1-0-identity-providers
>>>>>>>>>> >
>>>>>>>>>> >
>>>>>>>>>> > ----- Original Message -----
>>>>>>>>>> > > Hello James,
>>>>>>>>>> > >
>>>>>>>>>> > > See my 2 cents inline..
>>>>>>>>>> > >
>>>>>>>>>> > > ----- Original Message -----
>>>>>>>>>> > > > All--
>>>>>>>>>> > > >
>>>>>>>>>> > > >
>>>>>>>>>> > > >
>>>>>>>>>> > > > After observing that the Google Social Identity Provider in
>>>>>>>>>> Keycloak
>>>>>>>>>> > was
>>>>>>>>>> > > > using a deprecated userprofile endpoint [
>>>>>>>>>> > > > <
>>>>>>>>>> https://issues.jboss.org/projects/KEYCLOAK/issues/KEYCLOAK-9179>
>>>>>>>>>> > > > Keycloak-9179,  <
>>>>>>>>>> https://issues.jboss.org/browse/KEYCLOAK-9169>
>>>>>>>>>> > > > Keycloak-9169], I wanted to propose the creation of an
>>>>>>>>>> IdentityProvider
>>>>>>>>>> > > > that
>>>>>>>>>> > > > will use the OIDC Discovery mechanism to dynamically build
>>>>>>>>>> a config [
>>>>>>>>>> > > > <https://issues.jboss.org/browse/KEYCLOAK-9194>
>>>>>>>>>> Keycloak-9194].
>>>>>>>>>> > > >
>>>>>>>>>> > > >
>>>>>>>>>> > > >
>>>>>>>>>> > > > I see a few decision points along the way that I wanted to
>>>>>>>>>> ask about
>>>>>>>>>> > before
>>>>>>>>>> > > > an implementation, since I'm very new to keycloak and just
>>>>>>>>>> starting to
>>>>>>>>>> > > > understand the codebase. In particular, I wondered if this
>>>>>>>>>> group could
>>>>>>>>>> > > > share
>>>>>>>>>> > > > insight into these couple issues so I can make a more
>>>>>>>>>> informed design:
>>>>>>>>>> > > >
>>>>>>>>>> > > >
>>>>>>>>>> > > >
>>>>>>>>>> > > > 1.    It looks to me like the actual IdentityProviders are
>>>>>>>>>> instantiated
>>>>>>>>>> > > > just
>>>>>>>>>> > > > as they're being used, but that the models are persisted in
>>>>>>>>>> the
>>>>>>>>>> > RealmModel.
>>>>>>>>>> > > > It's not clear to me where the separation of concerns is
>>>>>>>>>> supposed to be
>>>>>>>>>> > > > between the IdentityProvider and the
>>>>>>>>>> IdentityProviderModel-in
>>>>>>>>>> > particular
>>>>>>>>>> > > > since the GoogeIdentityProvider, say, immediately sets
>>>>>>>>>> endpoints in its
>>>>>>>>>> > > > constructor. Normatively, where *should* social identity
>>>>>>>>>> providers'
>>>>>>>>>> > model
>>>>>>>>>> > > > configuration be set (and, e.g., where are the models first
>>>>>>>>>> added to
>>>>>>>>>> > the
>>>>>>>>>> > > > RealmModel)?
>>>>>>>>>> > >
>>>>>>>>>> > > Provider classes are being instantiated per transaction by
>>>>>>>>>> their
>>>>>>>>>> > > corresponding ProviderFactories and then left to be
>>>>>>>>>> garbage-collected
>>>>>>>>>> > after
>>>>>>>>>> > > Provider.close() is called.
>>>>>>>>>> > > The Provider class is given its configuration
>>>>>>>>>> (IdentityProviderModel in
>>>>>>>>>> > this
>>>>>>>>>> > > case) by its factory which I believe loads it from cache/jpa
>>>>>>>>>> layer. Any
>>>>>>>>>> > > class extending AbstractIdentityProvider should then be able
>>>>>>>>>> to access
>>>>>>>>>> > its
>>>>>>>>>> > > config via getConfig() method but I don't think it will be
>>>>>>>>>> able to
>>>>>>>>>> > > update/persist it back. The provider configuration/model
>>>>>>>>>> itself is
>>>>>>>>>> > managed
>>>>>>>>>> > > by the IdentityProviderResource (REST endpoint accessible via
>>>>>>>>>> REST or
>>>>>>>>>> > admin
>>>>>>>>>> > > console UI) in the keycloak/services module so I think the
>>>>>>>>>> > > auto-configuration logic would have to be placed somewhere
>>>>>>>>>> there.
>>>>>>>>>> > >
>>>>>>>>>> > > >
>>>>>>>>>> > > >
>>>>>>>>>> > > >
>>>>>>>>>> > > > 2.    I see that there is logic to parse OIDC Discovery
>>>>>>>>>> configuration
>>>>>>>>>> > as
>>>>>>>>>> > > > part of configuring Keycloak itself as an OIDC provider /
>>>>>>>>>> implementer
>>>>>>>>>> > of
>>>>>>>>>> > > > OIDC protocol (including building and parsing the
>>>>>>>>>> .well-known config
>>>>>>>>>> > > > elements), but that logic seems not to be used in any
>>>>>>>>>> setting
>>>>>>>>>> > currently as
>>>>>>>>>> > > > a
>>>>>>>>>> > > > client. Should I plan to reuse, say, the
>>>>>>>>>> > OIDCConfigurationRepresentation
>>>>>>>>>> > > > and
>>>>>>>>>> > > > OIDCWellKnownProvider classes for their logic in handling
>>>>>>>>>> such configs?
>>>>>>>>>> > > >
>>>>>>>>>> > > >
>>>>>>>>>> > > >
>>>>>>>>>> > > >
>>>>>>>>>> > > >
>>>>>>>>>> > > > Currently, I'm imagining something along the lines of
>>>>>>>>>> extending
>>>>>>>>>> > > > OIDCIdentityProvider with a new
>>>>>>>>>> OIDCDiscoveryIdentityProvider that
>>>>>>>>>> > adds a
>>>>>>>>>> > > > discoverConfig method which can be used by an implementing
>>>>>>>>>> class (such
>>>>>>>>>> > as
>>>>>>>>>> > > > GoogleIdentityProvider) to discover and cache endpoints
>>>>>>>>>> such that they
>>>>>>>>>> > are
>>>>>>>>>> > > > not hard-coded into the implementing class. Each
>>>>>>>>>> implementing class
>>>>>>>>>> > would
>>>>>>>>>> > > > then have a public static final DISCOVERY_URL that it
>>>>>>>>>> passes to
>>>>>>>>>> > > > discoverConfig.
>>>>>>>>>> > > >
>>>>>>>>>> > > >
>>>>>>>>>> > > >
>>>>>>>>>> > > > My main hangup, as suggested above, is that to implement
>>>>>>>>>> the caching, I
>>>>>>>>>> > > > want
>>>>>>>>>> > > > to ensure that the model configuration is stored/set in the
>>>>>>>>>> right
>>>>>>>>>> > place.
>>>>>>>>>> > > >
>>>>>>>>>> > > >
>>>>>>>>>> > > >
>>>>>>>>>> > > > Thanks for bearing with me as I come up to speed on this!
>>>>>>>>>> > > >
>>>>>>>>>> > > >
>>>>>>>>>> > > >
>>>>>>>>>> > > > James
>>>>>>>>>> > > >
>>>>>>>>>> > > > _______________________________________________
>>>>>>>>>> > > > keycloak-dev mailing list
>>>>>>>>>> > > > keycloak-dev at lists.jboss.org
>>>>>>>>>> > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>>>> > > >
>>>>>>>>>> > >
>>>>>>>>>> > >
>>>>>>>>>> > > Regards,
>>>>>>>>>> > > Tomas
>>>>>>>>>> > >
>>>>>>>>>> >
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> -... . / - .-. ..- . .-.-.- / -... . / .--. .-. . ... . -. -
>>>>>>>>>> .-.-.- / -...
>>>>>>>>>> . / ..-. .. -
>>>>>>>>>> 07:d0:2d:0b:d6:9d:27:c6:a7:c1:ec:e3:b1:65:f4:70
>>>>>>>>>> _______________________________________________
>>>>>>>>>> keycloak-dev mailing list
>>>>>>>>>> keycloak-dev at lists.jboss.org
>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> -... . / - .-. ..- . .-.-.- / -... . / .--. .-. . ... . -. - .-.-.-
>>>>>>>> / -... . / ..-. .. -
>>>>>>>> 07:d0:2d:0b:d6:9d:27:c6:a7:c1:ec:e3:b1:65:f4:70
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> -... . / - .-. ..- . .-.-.- / -... . / .--. .-. . ... . -. - .-.-.- /
>>>>>> -... . / ..-. .. -
>>>>>> 07:d0:2d:0b:d6:9d:27:c6:a7:c1:ec:e3:b1:65:f4:70
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> -... . / - .-. ..- . .-.-.- / -... . / .--. .-. . ... . -. - .-.-.- /
>>>>> -... . / ..-. .. -
>>>>> 07:d0:2d:0b:d6:9d:27:c6:a7:c1:ec:e3:b1:65:f4:70
>>>>>
>>>>
>>>
>>> --
>>> -... . / - .-. ..- . .-.-.- / -... . / .--. .-. . ... . -. - .-.-.- /
>>> -... . / ..-. .. -
>>> 07:d0:2d:0b:d6:9d:27:c6:a7:c1:ec:e3:b1:65:f4:70
>>>
>>

From thomas.darimont at googlemail.com  Mon Feb 18 04:31:01 2019
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Mon, 18 Feb 2019 10:31:01 +0100
Subject: [keycloak-dev] Example Setup to simplify the development of
 Keycloak Extensions
In-Reply-To: <CAJgngAdvRaryA-igtgwAk-=htUMR3g_QP8VooY=kU3JNhwg9NA@mail.gmail.com>
References: <CAK-7U1j1=x1aKwJGG_zXjsSw+qd7_ZEx_3pXb1ie5OyDRqoSyw@mail.gmail.com>
	<CAJgngAdKVWgxtpH9jmoNFRTtuGy5mTDH-q6c7Cjt7Mf0DnN+Fg@mail.gmail.com>
	<CAK-7U1jj7DhuwwSqbZfYDiXBW_HKW69UOvY_k1g5s8K+F0bL2w@mail.gmail.com>
	<CAJgngAc3C0CD83LJOpXzU=wDL3fuog0saV7yN5iDkKAPBF6jZg@mail.gmail.com>
	<CAJgngAdvRaryA-igtgwAk-=htUMR3g_QP8VooY=kU3JNhwg9NA@mail.gmail.com>
Message-ID: <CAK-7U1gj=3_-NBqRhQk8m9fwSxQfSqWEmMKa7s4NhkBd3MKa1A@mail.gmail.com>

Hello Stian,

I agree with most of your points! Using your internal test-infrastructure
is definitely not a long-term solution as it can be quite brittle.
Additionally the actual environment available in a real Keycloak-Server
(Java EE) is quite different from that provided by the KeycloakServer
standalone approach (no EJB, JNDI etc.).

Nevertheless, I think using the KeycloakServer can be a pragmatic solution
(at the moment) for faster development of smaller components like
custom Authenticators, RequiredActions, FormActions, PasswordHashes but not
so much for UserStorageProviders etc.

Repeatedly starting / stopping a wildfly or arquillian container can be
quite slow in my experience - do you have a setup that starts < 3 seconds?
Perhaps using the wildfly-swarm / thorntail (https://thorntail.io/) would
be a better middle-ground solution here, as it would provide a
"close-enough"
environment to what's available in wildfly including fast boot times.

Cheers,
Thomas

Am Mo., 18. Feb. 2019 um 10:15 Uhr schrieb Stian Thorgersen <
sthorger at redhat.com>:

> Adding a few reasons why it should target a real distro and not the
> KeycloakServer internal util:
>
> * KeycloakServer is an internal util that we use for our testsuite. This
> is not something we will support publicly as we need to be able to change
> this without considering backwards compatibility.
> * As an extension developer you should not modify Keycloak code itself.
> This is actually what makes our testsuite more complex as we do need to be
> able to quickly run tests with a modified Keycloak server.
> * Using a dist you can test it properly. There is no guarantee that your
> extension will work deployed to Keycloak dist if it works on
> KeycloakServer. Classpath being one main issue here, but there are other
> caveats as well. So you end up having to run your tests twice (once with
> embedded Keycloak for development and second with proper dist for proper
> testing)
>
> For the above reasons although this is a nice approach for now it's not
> very future proof and I'd rather see efforts being put into doing it
> "properly" and improving on that experience than working around it.
>
> On Mon, 18 Feb 2019 at 10:10, Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> Arquillian can use a remote container, which allows you pointing to an
>> already running Keycloak server, then you simply hot deploy your extension
>> as part of the tests and it should not need to restart Keycloak.
>>
>> On Tue, 12 Feb 2019 at 12:32, Thomas Darimont <
>> thomas.darimont at googlemail.com> wrote:
>>
>>> HI Stian,
>>>
>>> Thanks for the feedback. In my experience using Arquillian is rather
>>> slow - at least I haven't seen an example setup that doesn't need 30+
>>> seconds round-trip time per change (without hot-code replacement). Do you
>>> have a fast example at hand (< 10sec round-trip time)?
>>>
>>> The aforementioned approach is easy to use and makes a cold-start
>>> round-trip much faster (~5 sec my machine).
>>> Also one can concentrate on the actual extension development first,
>>> instead of figuring out the proper packaging of their extension right from
>>> the beginning, which is IMHO not a nice getting started experience.
>>>
>>> Cheers,
>>> Thomas
>>>
>>> Am Di., 12. Feb. 2019 um 12:21 Uhr schrieb Stian Thorgersen <
>>> sthorger at redhat.com>:
>>>
>>>> I'd say it would be better to target the real distribution rather than
>>>> the KeycloakServer. It should be reasonably easy to setup Arquillian to use
>>>> the Keycloak distribution from Maven Central and allow it to hot-deploy
>>>> extensions for testing purposes.
>>>>
>>>> On Tue, 12 Feb 2019 at 09:42, Thomas Darimont <
>>>> thomas.darimont at googlemail.com> wrote:
>>>>
>>>>> Hello Keycloak-Team,
>>>>>
>>>>> I found a neat setup to simplify the development of Keycloak
>>>>> extensions.
>>>>> I setup a "keycloak-extension-playground" project that contains two or
>>>>> more
>>>>> maven modules:
>>>>> - keycloak-playground-server
>>>>> - simple-auth-extension (example)
>>>>>
>>>>> In the "keycloak-playground-server" module, I wrap a KeycloakServer
>>>>> from
>>>>> the "keycloak-testsuite-utils" library where one could potentially add
>>>>> additional configuration. Note that this library must be in (local)
>>>>> Maven
>>>>> Repository.
>>>>>
>>>>> The "simple-auth-extension" is an example extension module that
>>>>> demonstrates the usage of the Authenticator SPI.
>>>>>
>>>>> I now declare "simple-auth-extension" as a compile time dependency of
>>>>> the
>>>>> "keycloak-playground-server" project. This ensures that it's classes
>>>>> and
>>>>> resources are on the classpath of KeycloakServer. Therefore all SPI
>>>>> implementations in custom extensions can be found. This improves the
>>>>> debugging experience and speeds up development time.
>>>>>
>>>>> The example project can be found here:
>>>>> https://github.com/thomasdarimont/keycloak-extension-playground
>>>>>
>>>>> What do you guys think about this approach?
>>>>>
>>>>> Cheers,
>>>>> Thomas
>>>>> _______________________________________________
>>>>> keycloak-dev mailing list
>>>>> keycloak-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>
>>>>

From sthorger at redhat.com  Mon Feb 18 04:32:41 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 18 Feb 2019 10:32:41 +0100
Subject: [keycloak-dev] Introduce GolangCI to Gatekeeper repository
In-Reply-To: <CAM5SUC4Mc6CjLB2zt1vTywRVyvpHqP=6oofd-ns_DH3Ha9zqMA@mail.gmail.com>
References: <20190213131457.GA31743@abstractj.org>
	<CAJgngAe3zg4C-Of-yk2mr3SOuWLgT4BVt69Jh1_momGkuU2K-Q@mail.gmail.com>
	<CAM5SUC4Mc6CjLB2zt1vTywRVyvpHqP=6oofd-ns_DH3Ha9zqMA@mail.gmail.com>
Message-ID: <CAJgngAeaX4QpCQNmrRDu_rxDdgfReumFMSzxmgxLcQCv=Y_RDg@mail.gmail.com>

Enabled

On Mon, 18 Feb 2019 at 10:26, Bruno Oliveira <bruno at abstractj.org> wrote:

> Thank you. Merged.
>
> I don't have admin rights over the repository. Could you please enable
> it here: https://golangci.com/repos/github
>
> On Mon, Feb 18, 2019 at 6:18 AM Stian Thorgersen <sthorger at redhat.com>
> wrote:
> >
> > If it's easy to setup why not try and see? We can always re-evaluate in
> the future if benefits vs costs ratio is not correct.
> >
> > On Wed, 13 Feb 2019 at 14:29, Bruno Oliveira <bruno at abstractj.org>
> wrote:
> >>
> >> Good morning,
> >>
> >> A week ago Frederic, one of our contributors, suggested the
> >> inclusion of GolangCI[1][2]. For those not familiar,
> >> GolangCI can run a set of linters against the source tree. It can
> >> check if the code respects the code style, if there are vulnerabilities
> >> introduced into the codebase and also advise on best practices.
> >>
> >> Even though I think it's something nice to have, I'm afraid that
> >> GolangCI could add too much noise commenting on PRs (I'm not
> >> sure if this can be disabled).
> >>
> >> Even though is something cool, I'm 50/50 on this. I don't see the
> >> adoption from big projects like Openshift or Kubernetes.
> >>
> >> Thoughts?
> >>
> >> [1] - https://github.com/keycloak/keycloak-gatekeeper/pull/454
> >> [2] - https://golangci.com/
> >>
> >> --
> >>
> >> abstractj
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
> --
> - abstractj
>

From sthorger at redhat.com  Mon Feb 18 04:34:25 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 18 Feb 2019 10:34:25 +0100
Subject: [keycloak-dev] Example Setup to simplify the development of
 Keycloak Extensions
In-Reply-To: <CAK-7U1gj=3_-NBqRhQk8m9fwSxQfSqWEmMKa7s4NhkBd3MKa1A@mail.gmail.com>
References: <CAK-7U1j1=x1aKwJGG_zXjsSw+qd7_ZEx_3pXb1ie5OyDRqoSyw@mail.gmail.com>
	<CAJgngAdKVWgxtpH9jmoNFRTtuGy5mTDH-q6c7Cjt7Mf0DnN+Fg@mail.gmail.com>
	<CAK-7U1jj7DhuwwSqbZfYDiXBW_HKW69UOvY_k1g5s8K+F0bL2w@mail.gmail.com>
	<CAJgngAc3C0CD83LJOpXzU=wDL3fuog0saV7yN5iDkKAPBF6jZg@mail.gmail.com>
	<CAJgngAdvRaryA-igtgwAk-=htUMR3g_QP8VooY=kU3JNhwg9NA@mail.gmail.com>
	<CAK-7U1gj=3_-NBqRhQk8m9fwSxQfSqWEmMKa7s4NhkBd3MKa1A@mail.gmail.com>
Message-ID: <CAJgngAcBH6CAiQaJp+LX3D64jtO5DaMS7PYWb+F1h=AzcgqdZA@mail.gmail.com>

For development you don't need to restart the server. Just run it manually
and configure Arquillian to connect to a remote instance. That'll give you
even faster roundtrips than KeycloakServer does.

On Mon, 18 Feb 2019 at 10:32, Thomas Darimont <
thomas.darimont at googlemail.com> wrote:

> Hello Stian,
>
> I agree with most of your points! Using your internal test-infrastructure
> is definitely not a long-term solution as it can be quite brittle.
> Additionally the actual environment available in a real Keycloak-Server
> (Java EE) is quite different from that provided by the KeycloakServer
> standalone approach (no EJB, JNDI etc.).
>
> Nevertheless, I think using the KeycloakServer can be a pragmatic solution
> (at the moment) for faster development of smaller components like
> custom Authenticators, RequiredActions, FormActions, PasswordHashes but
> not so much for UserStorageProviders etc.
>
> Repeatedly starting / stopping a wildfly or arquillian container can be
> quite slow in my experience - do you have a setup that starts < 3 seconds?
> Perhaps using the wildfly-swarm / thorntail (https://thorntail.io/) would
> be a better middle-ground solution here, as it would provide a
> "close-enough"
> environment to what's available in wildfly including fast boot times.
>
> Cheers,
> Thomas
>
> Am Mo., 18. Feb. 2019 um 10:15 Uhr schrieb Stian Thorgersen <
> sthorger at redhat.com>:
>
>> Adding a few reasons why it should target a real distro and not the
>> KeycloakServer internal util:
>>
>> * KeycloakServer is an internal util that we use for our testsuite. This
>> is not something we will support publicly as we need to be able to change
>> this without considering backwards compatibility.
>> * As an extension developer you should not modify Keycloak code itself.
>> This is actually what makes our testsuite more complex as we do need to be
>> able to quickly run tests with a modified Keycloak server.
>> * Using a dist you can test it properly. There is no guarantee that your
>> extension will work deployed to Keycloak dist if it works on
>> KeycloakServer. Classpath being one main issue here, but there are other
>> caveats as well. So you end up having to run your tests twice (once with
>> embedded Keycloak for development and second with proper dist for proper
>> testing)
>>
>> For the above reasons although this is a nice approach for now it's not
>> very future proof and I'd rather see efforts being put into doing it
>> "properly" and improving on that experience than working around it.
>>
>> On Mon, 18 Feb 2019 at 10:10, Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>>
>>> Arquillian can use a remote container, which allows you pointing to an
>>> already running Keycloak server, then you simply hot deploy your extension
>>> as part of the tests and it should not need to restart Keycloak.
>>>
>>> On Tue, 12 Feb 2019 at 12:32, Thomas Darimont <
>>> thomas.darimont at googlemail.com> wrote:
>>>
>>>> HI Stian,
>>>>
>>>> Thanks for the feedback. In my experience using Arquillian is rather
>>>> slow - at least I haven't seen an example setup that doesn't need 30+
>>>> seconds round-trip time per change (without hot-code replacement). Do you
>>>> have a fast example at hand (< 10sec round-trip time)?
>>>>
>>>> The aforementioned approach is easy to use and makes a cold-start
>>>> round-trip much faster (~5 sec my machine).
>>>> Also one can concentrate on the actual extension development first,
>>>> instead of figuring out the proper packaging of their extension right from
>>>> the beginning, which is IMHO not a nice getting started experience.
>>>>
>>>> Cheers,
>>>> Thomas
>>>>
>>>> Am Di., 12. Feb. 2019 um 12:21 Uhr schrieb Stian Thorgersen <
>>>> sthorger at redhat.com>:
>>>>
>>>>> I'd say it would be better to target the real distribution rather than
>>>>> the KeycloakServer. It should be reasonably easy to setup Arquillian to use
>>>>> the Keycloak distribution from Maven Central and allow it to hot-deploy
>>>>> extensions for testing purposes.
>>>>>
>>>>> On Tue, 12 Feb 2019 at 09:42, Thomas Darimont <
>>>>> thomas.darimont at googlemail.com> wrote:
>>>>>
>>>>>> Hello Keycloak-Team,
>>>>>>
>>>>>> I found a neat setup to simplify the development of Keycloak
>>>>>> extensions.
>>>>>> I setup a "keycloak-extension-playground" project that contains two
>>>>>> or more
>>>>>> maven modules:
>>>>>> - keycloak-playground-server
>>>>>> - simple-auth-extension (example)
>>>>>>
>>>>>> In the "keycloak-playground-server" module, I wrap a KeycloakServer
>>>>>> from
>>>>>> the "keycloak-testsuite-utils" library where one could potentially add
>>>>>> additional configuration. Note that this library must be in (local)
>>>>>> Maven
>>>>>> Repository.
>>>>>>
>>>>>> The "simple-auth-extension" is an example extension module that
>>>>>> demonstrates the usage of the Authenticator SPI.
>>>>>>
>>>>>> I now declare "simple-auth-extension" as a compile time dependency of
>>>>>> the
>>>>>> "keycloak-playground-server" project. This ensures that it's classes
>>>>>> and
>>>>>> resources are on the classpath of KeycloakServer. Therefore all SPI
>>>>>> implementations in custom extensions can be found. This improves the
>>>>>> debugging experience and speeds up development time.
>>>>>>
>>>>>> The example project can be found here:
>>>>>> https://github.com/thomasdarimont/keycloak-extension-playground
>>>>>>
>>>>>> What do you guys think about this approach?
>>>>>>
>>>>>> Cheers,
>>>>>> Thomas
>>>>>> _______________________________________________
>>>>>> keycloak-dev mailing list
>>>>>> keycloak-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>
>>>>>

From bward at redhat.com  Mon Feb 18 09:49:32 2019
From: bward at redhat.com (Brian Ward)
Date: Mon, 18 Feb 2019 09:49:32 -0500
Subject: [keycloak-dev] ClientDescriptionConverter
Message-ID: <CAHBgxzvDsNLGVgkrq878K0bARR+BDW2SDvbnnKcvODy9DDjfHg@mail.gmail.com>

Is there any way to access this code through the kcadmin.sh CLI yet?  I
want to import a SAML client the way the GUI does it.  I see the GUI uses
ClientDescriptionConverter to parse the EntityDescriptor xml into a json
object that the API uses.

If this is not yet present, I'm happy to build it from the existing
pieces.  I don't see it, but thought I'd get confirmation first that we
don't have anything like this in the kcadmin or elsewhere.

Thanks,
Brian

From kschwiersch at yahoo.de  Mon Feb 18 11:05:42 2019
From: kschwiersch at yahoo.de (Ken Haendel)
Date: Mon, 18 Feb 2019 17:05:42 +0100
Subject: [keycloak-dev] Why does client session expire regardless
 remember-me extended validity?
In-Reply-To: <6852a835-88f0-7408-e6ea-41f77ea8b12e@redhat.com>
References: <7637f53f-dd9b-2a3c-3816-a25d14ca189a@yahoo.de>
	<685a0dff-80b9-ddd6-18ff-4847755204df@redhat.com>
	<CA+7ohf=nRhHaWhk7vOfRZ1j1fOHLUwNRsmS5KQiXv7PVabyk8g@mail.gmail.com>
	<c7d47317-2297-534c-8bc2-407a0da21a47@yahoo.de>
	<CA+7ohfm=GbNpnhLpSNDjHmnoR_5oc=utZe09JP41iqVgvMdKQw@mail.gmail.com>
	<6852a835-88f0-7408-e6ea-41f77ea8b12e@redhat.com>
Message-ID: <f720c7a7-f25d-2c63-1e18-e894a393d2e7@yahoo.de>


Am 15.02.19 um 14:56 schrieb Marek Posolda:
> IMO single PR is fine. But I suggest to create new JIRA or update 
> description of existing JIRA, so that it contains also the description 
> for this "new" bug.
>
> 2 minor things:
> - Is it possible to update this check, so it considers the 
> "min(expired, expiredRememberMe)" instead of being hardcoded to 
> expiredRememberMe? In most cases, the 
> "ssoSessionMAxLifespanRememberMe" is bigger than 
> "ssoSessionMaxLifespan", however it may not be always true. For 
> example, someone can want to increase ssoSessionMaxLifespan to some 
> very big value, but he doesn't use "remember me", so he won't increase 
> the "ssoSessionMAxLifespanRememberMe" .

1.

min(expired, expiredRememberMe) is NOT the right formula for the normal 
case, where rememberMe is a bigger value than SsoSessionMaxLifespan. It 
would choose the smaller value. Do you mean max?

2.

You are describing a scenario, where ssoSessionMaxLifespan is used with 
a very high value and remember-me is turned off. This could of course be 
the case, but

the variable expiredRememberMe does already check, if a remember-me 
timeout has been set or not (realm.getSsoSessionMaxLifespanRememberMe() 
 > 0) line 488.

Every person, that does not use remember-me will leave the remember-me 
timeouts zero. Therefore my check would work for them and 
SsoSessionMaxLifespan would be used instead.


But this is just my two cents.


Regards,

Ken


> - Is it possible to add the test for the buggy scenarios? It is hard 
> to test it properly, but we somehow test it with usage of time offset 
> and manually invoking "expiration check". It is done in 
> UserSessionProviderTest - please make sure to use the one from new 
> testsuite as this test is currently duplicated in both the new and old 
> testsuite :(
>
> WDYT?
> Marek
>
> On 15/02/2019 02:57, Stefan Guilhen wrote:
>> Hi Ken,
>>
>> Yes, it does make sense to me to use the remember-me value for the 
>> client session as well. Marek, WDYT? Should we open a new Jira just 
>> for this or can I just amend the commit to include this fix too?
>>
>> Stefan
>>
>> On Thu, Feb 14, 2019 at 10:34 AM Ken Haendel <kschwiersch at yahoo.de 
>> <mailto:kschwiersch at yahoo.de>> wrote:
>>
>>     Hi Stefan, Marek
>>
>>
>>     Thank you for your quick reply.
>>
>>     I have recently tested your pull request [1], if that fixes my
>>     issue with the expired client session cache and it does NOT. It
>>     only fixes an issue with the user session cache.
>>
>>     My proposal to fix that problem would be as follows (verified here):
>>
>>     diff --git
>>     a/model/infinispan/src/main/java/org/keycloak/models/sessions/infinispan/InfinispanUserSessionProvider.java
>>     b/model/infinispan/src/main/java/org/keycloak/models/sessions/infinispan/InfinispanUserSessionProvider.java
>>     index b1429a6391..54cb244624 100755
>>     ---
>>     a/model/infinispan/src/main/java/org/keycloak/models/sessions/infinispan/InfinispanUserSessionProvider.java
>>     +++
>>     b/model/infinispan/src/main/java/org/keycloak/models/sessions/infinispan/InfinispanUserSessionProvider.java
>>     @@ -529,7 +529,7 @@ public class InfinispanUserSessionProvider
>>     implements UserSessionProvider {
>>     ???????? localClientSessionCacheStoreIgnore
>>     ???????????????? .entrySet()
>>     ???????????????? .stream()
>>     -
>>     .filter(AuthenticatedClientSessionPredicate.create(realm.getId()).expired(expired))
>>     +
>>     .filter(AuthenticatedClientSessionPredicate.create(realm.getId()).expired(expiredRememberMe))
>>
>>
>>     Using that change, the life span of the client session would be
>>     longer for remember-me logins.
>>
>>     Can you please check if that makes sense for you?
>>
>>     It would be nice if a fix could be added in the next releases to
>>     make it unnecessary to patch the further release :-)
>>
>>     Kind regards,
>>
>>     Ken
>>
>>
>>     [1] https://github.com/keycloak/keycloak/pull/5852
>>
>>     Am 13.02.19 um 18:27 schrieb Stefan Guilhen:
>>>     It is possible that Ken is seeing something different. I will
>>>     take a look into it to be sure.
>>>
>>>     Best regards,
>>>     Stefan
>>>
>>>     On Wed, Feb 13, 2019, 13:43 Marek Posolda <mposolda at redhat.com
>>>     <mailto:mposolda at redhat.com> wrote:
>>>
>>>         We have PR open, which is related to that [1], but not sure
>>>         if that PR
>>>         fixes also your issue. It seems there is nothing related to
>>>         client
>>>         sessions. I am CCing Stefan in case he has some more to it.
>>>
>>>         In the meantime, if you are curious if fix works, I suggest to
>>>         cherry-pick Stefan's commit and build Keycloak and check if the
>>>         behaviour is fixed with that PR.
>>>
>>>         [1] https://github.com/keycloak/keycloak/pull/5852
>>>
>>>         Marek
>>>
>>>         On 13/02/2019 14:15, Ken Haendel wrote:
>>>         > I have a problem authenticating a spring secured web-app
>>>         using keycloak
>>>         > 4.8.3.
>>>         >
>>>         > If the user logs in with remember-me enabled, the user
>>>         session does use
>>>         > a larger SSO max life span (ssoSessionMaxLifespanRememberMe).
>>>         >
>>>         > So far so good.
>>>         >
>>>         > Now i want to call another secured REST-API using the
>>>         KeycloakRestService.
>>>         >
>>>         > That triggers OAuthRequestAuthenticator to verify token
>>>         > (AdapterTokenVerifier.verifyTokens).
>>>         >
>>>         > That operation fails, because the client session expired
>>>         much earlier
>>>         > (after ssoSessionMaxLifespan). The client session gets
>>>         removed from the
>>>         > client session cache
>>>         > (InfinispanUserSessionProvider.removeExpiredUserSessions).
>>>         >
>>>         > Error message of AdapterTokenVerifier.verifyTokens() is:
>>>         >
>>>         > "ERROR RefreshableKeycloakSecurityContext Refresh token
>>>         failure status:
>>>         > 400 {"error":"invalid_grant","error_description":"Session
>>>         doesn't have
>>>         > required client"}"
>>>         >
>>>         >
>>>         > So, the point is: after the client session gets removed
>>>         from cache (SSO
>>>         > max life span) i can no longer use the refresh token to
>>>         request new
>>>         > tokens and call another REST-API service
>>>         >
>>>         > using the same identity as the web-app.
>>>         >
>>>         > Even though i have still a valid user session to use my
>>>         spring app.
>>>         >
>>>         >
>>>         > Expectation was: I can use refresh token within the larger
>>>         time span
>>>         > with remember-me enabled (SsoSessionMaxLifespanRememberMe).
>>>         >
>>>         > Actual behaviour is: Refresh token gets useless within the
>>>         shorter time
>>>         > span (ssoSessionMaxLifespan)
>>>         >
>>>         > Question: Why is the client session removed so early and
>>>         not when the
>>>         > user session expires? Is that expected behavoiur?
>>>         >
>>>         > Thank you in advance,
>>>         >
>>>         > Ken
>>>         >
>>>         >
>>>         > _______________________________________________
>>>         > 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
>>>
>>>
>>
>>
>> -- 
>>
>> STEFAN GUILHEN
>>
>> PRINCIPAL SOFTWARE ENGINEER
>>
>> Red Hat<https://www.redhat.com/>
>>
>> sguilhen at redhat.com <mailto:sguilhen at redhat.com> M: +55-11-98117-7332 
>> <tel:+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 dhardiker at adaptavist.com  Mon Feb 18 12:39:16 2019
From: dhardiker at adaptavist.com (Dan Hardiker)
Date: Mon, 18 Feb 2019 17:39:16 +0000
Subject: [keycloak-dev] Improving support for LDAP backed Keycloak
Message-ID: <9695FE33-85A2-48BC-B440-D50452D070DF@adaptavist.com>

Hi All,

Sorry for such a long first post. Here we go!


TL;DR:
I want to look at https://issues.jboss.org/browse/KEYCLOAK-5571 as it is impacting us. I?m happy to contribute code or write a blog on what configuration settings are needed to achieve this. While the SAGA has more context, here?s a few of my currently burning questions:

1. What implements the org.keycloak.admin.client.resource.UserResource.update(UserRepresentation) and UserRepresentation ...toRepresentation() interface method? (from the integration/admin-client directory - I can?t find the business logic)
2. What would be the right approach to wire up the admin ui User Enabled toggle to a LDAP boolean field, and where in the codebase would that go? (if you can cite examples of similar that would be great)
3. What is the best way to go about setting up an IDE for development? Just importing the root POM into IDEA doesn?t seem to cut it.
4. If I provide a patch for this, is this something that might be considered for pulling into master?

I am interested in all of the features within KEYCLOAK-5571, as a few other requirements, but I?m happy to start here and treat the others as atomic suggested changes. They may include:

* Supporting incremented default values for new users (the uidNumber must be unique and it should be 1 greater than the highest uidNumber that the system can see ? i.e. the next available UID).
* Supporting out-of-band password recovery (where by a code is sent via a trusted path [text message, telephone call, in person conversation with the user] which can be used to reset their password - ideally in combination with another stored value, such as their employee id / tax id / post code / something else which is relatively static but relatively unknown) - this could be developed outside of Keycloak of course, but would ideally be within the same system.

If addressing KEYCLOAK-5571 goes well, I would be interested in continuing to contribute down these paths.

Thanks for your time, I would love to get involved ? I just need a bit of help.


THE SAGA:
Apologies if this message should be in keycloak-users, and if any of it seems incoherent. I?ve been fighting in circles all weekend and I have to admit that I?m not entirely sure I?m approaching the problem correctly. Please bear with me as I?m not entirely sure how to articulate things at this point, but I know I need help!

Problem statement: we are currently using OpenLDAP to manage access to our systems. However, the administration interface is crude and it lacks SAML/OIDC support for integrating systems like Google Suite, AWS Console, Office 365 and others. It also lacks a self service console where users can mange their own accounts. Keycloak at first glance looks ideal - especially as it allows us to continue using OpenLDAP as the primary source of truth, with Keycloak used to enhance the user experience giving self service and integration with SAML/OIDC clients.

As per the docs, some mapping is required to have OpenLDAP support the storage of Keycloak data within the OpenLDAP schemas. Unfortunately, I?ve not bee able to find documentation for what those fields names in Keycloak can be and how I should alter my OpenLDAP schema to support them. I found KEYCLOAK-5571 which appears to cover at least some of the issues I?m having. Amongst other things, I?m a Java developer, so I?m comfortable with working in code and submitting patches. Assuming that the answer isn?t configuration, is this something that would be valuable to contribute? If so, is there any advice that this list can offer on where to start?

What follows is my journey as an outsider into trying to figure out things myself. This may or may not be of interest - but given this list gets indexed by Google, it might help someone in future. Seeing that issue (KEYCLOAK-5571) I figured the best place to start would be the admin ui where you enable/disable users. I thought that I would start at the browser and try to figure out what the enabled/disable user toggle did when saved, trace that into the server side endpoint that picked up that representation and hopefully find out where & why it didn?t make it through to LDAP.

I noticed that there was a PUT to http://localhost/auth/admin/realms/master/users/f:$UUID:$USERNAME and as part of the JSON payload was ?enabled: false?. At this point I started grepping around in the Keycloak code. I figured that org.keycloak.admin.client.resource.UserResource.update(UserRepresentation) Interface was what was being called, but unfortunately when I opened up the root POM then IDEA only saw the files as plain text and none of the Intelisense worked, I could grep around the code though. When I opened up the integration/admin-client/pom.xml it recognise the Java files, however I wasn?t able to find what was implementing this. If found "public static UserRepresentation toRepresentation(KeycloakSession session, RealmModel realm, UserModel user)? in server-spi-private org.keycloak.models.util.ModelToRepresentation, but couldn?t find the glue which connects them together. I?m guessing there might be some WildFly or other magic going on which I?m not aware of?

Seeing the ?enabled: false? lead me to think that I might be able to create a user-attribute-ldap-mapper from the user model attribute ?enabled? to an ?enabled? LDAP attribute I added to our schema to test. The LDAP attribute has SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 (a binary attribute) and I?ve checked I can set that to TRUE / FALSE appropriately. I set it to be mandatory in LDAP and set it to be a Binary Attribute - however when I save it says "Error! With Binary attribute enabled, the 'Always read value from LDAP' must be enabled too? - however there is no ?Always read value from LDAP? option! However, after enabling Import Users in the LDAP user federation settings, ?Always read value from LDAP? becomes available. It?s not clear if Binary Attributes are supported only in this configuration, but ideally I would like to not Import Users as I prefer LDAP to be the authoritative source. After this I can disabled Import Users and the configuration still seemingly remains valid without any errors in the logs. That said, it?s not erroring about not properly persisting the enabled state to LDAP...

If I go across to the user in the admin ui, even though enabled is set to FALSE in LDAP, the toggle is showing as enabled in the UI. The JSON it gets for the UserRepresentation on the client side is ?enabled?:true which explains the state of the toggle. If I stick Wireshark locally, setup a Docker with OpenLDAP and configure it appropriately, sniffing traffic I can see that the enabled attribute for my user comes back as FALSE. So there is something going wrong when trying to build that UserRepresentation. I suspect at the root of the KEYCLOAK-5571 issue. If I change the toggle to false in the UI and save, then reload the page, the toggle is back to true - when it persists to the LDAP server, it?s sending enabled: FALSE - this doesn?t make sense, but it might be just repeating back to LDAP what it read in without changing that field. If I change the name as well, it does send those fields updated, but enabled remains FALSE in the LDAP server.

Given that I didnt get very far with the UserRepresentation angle, I thought about going down the FederatedStorage - something must map the model into LDAP, as changes to the first name / last name, and the other attributes seem to be persisted and loaded in LDAP just fine. In my grepping around in server-spi I found a org.keycloak.models.UserModel Interface, which had a org.keycloak.storage.adapter.AbstractUserAdapterFederatedStorage implementation with a ENABLED_ATTRIBUTE = ?ENABLED? field and isEnabled / setEnabled methods which getFirstAttribute(ENABLED_ATTRIBUTE) / setSingleAttribute(ENABLED_ATTRIBUTE, Boolean.toString(enabled). The class comment has:

* Assumes everything is managed by federated storage except for username.  getId() returns a default value
* of "f:" + providerId + ":" + getUsername().  UserModel properties like enabled, firstName, lastName, email, etc. are all
* stored as attributes in federated storage.

I?m not sure how the case difference between ?enabled? in the UserModel properties and ?ENABLED? as listed in the class field is connected - but there must be a mapping somewhere, as ?firstName? is similarly ?FIRST_NAME? and that maps just fine. I found model/jpa contained org.keycloak.models.jpa.entities/UserEntity which had @Column(name = "ENABLED?) protected boolean enabled, perhaps this is the link and even with Import Users disabled it always goes through the database?

I?ve yet to find the trigger which calls the mapper to run which persists into the database. Part of the problem is that I?m acutely aware my IDE is not setup to effectively jump around the code base, or to effectively attach my IDE as a debugger so I can add breakpoints and step through the code to figure out what happens where. I?ve just turned on trace logging - but this is giving me a wall of text which may take sometime to process. I?ve also yet to comb through the H2 DB to see if there?s cause there.

Any assistance on this would be most welcome.


ON ANOTHER NOTE:
I checked out the code and ran the build as documented against Java 8 on my mac, but unfortunately it failed. I ignored it and progressed, but here?s some excerpts from the output:
[INFO] Keycloak Integration TestSuite - deprecated ........ FAILURE [07:04 min]

[ERROR] Errors:
[ERROR]   OIDCKeyCloakServerBrokerBasicTest.testLogoutWorksWithTokenTimeout:131 ? Processing
[ERROR]   OIDCKeycloakServerBrokerWithConsentTest.before:84 ? Processing java.lang.NoSuc...
[ERROR]   BrokenUserStorageTest.testBootWithBadProviderId:118 ? Processing java.lang.NoS...
[ERROR]   JaxrsBasicAuthTest.testBasic:120 ? NoSuchMethod org.apache.commons.io.output.D...
[ERROR]   JaxrsFilterTest.testBasic:129 ? NoSuchMethod org.apache.commons.io.output.Defe...
[ERROR] Tests run: 238, Failures: 0, Errors: 5, Skipped: 32

I guess this shouldn?t happen on a fresh check out & a following of the instruction.


If you made it this far - bravo!

Thanks again,


?
Dan Hardiker | Adaptavist


From alexis.almeida at gmail.com  Tue Feb 19 00:31:26 2019
From: alexis.almeida at gmail.com (Alexis Almeida)
Date: Tue, 19 Feb 2019 02:31:26 -0300
Subject: [keycloak-dev] Integration with GuardianKey
In-Reply-To: <CAFjP4XQwLcQsf8X7Y5CEg7JVkE=5bKmF86OBBR=LuymRZ_mhKQ@mail.gmail.com>
References: <CAFjP4XTv=yupw4jZAf275q37JNJZj5jh9tr+BTH0A+0EeNSQMw@mail.gmail.com>
	<CA+H6wMzRFPSf2mkqa4vizP1SaSn6pbbqsFoP+YtwOF4aDvKboA@mail.gmail.com>
	<1549228866.7030.6.camel@acutus.pro>
	<CAFjP4XQvSgNr2fB9oqDBrq2PJ5fuN=_CLEgU6E7Vo9KKRg_b2Q@mail.gmail.com>
	<CAFjP4XRghVyWeLeXxpDAc67FLys0WOk6x7KaivtX6KYKf4v3+A@mail.gmail.com>
	<CAK-7U1i0Y+hL3r3TAVVxfiVi+m+NtT-mqSNrU7aMzJ=ZfC9awA@mail.gmail.com>
	<CA+H6wMw9dWhEUQRCSPrGD74bWSOYqXQy10P58QskM5dTihWLUA@mail.gmail.com>
	<CAFjP4XQwLcQsf8X7Y5CEg7JVkE=5bKmF86OBBR=LuymRZ_mhKQ@mail.gmail.com>
Message-ID: <CA+H6wMxmPuii1K0GeWRjNfAtGD4vosjwZ+tAvZ9Jeid12xcS_A@mail.gmail.com>

Hi Paulo!

I had this same problem and to solve it I did this:

private AuthenticatorConfigModel getConfig(KeycloakSession session,
String providerId) {
    logger.info("Getting config for: " + providerId);
    AuthenticatorConfigModel configModel = null;

    RealmModel realm = session.getContext().getRealm();
    String flowId = realm.getBrowserFlow().getId();

    return getConfig(realm, flowId, providerId);

}

private AuthenticatorConfigModel getConfig(RealmModel realm, String
flowId, String providerId) {
    logger.info("Getting config for: " + flowId);

    AuthenticatorConfigModel configModel = null;

    List<AuthenticationExecutionModel> laem =
realm.getAuthenticationExecutions(flowId);

    for (AuthenticationExecutionModel aem : laem) {
        logger.info("aem: " + String.format("%s, %s, %s, %s",
aem.getFlowId(), aem.getId(),
                aem.isEnabled(),aem.isAuthenticatorFlow()));
        if (aem.isAuthenticatorFlow()) {
            logger.info("flow: " + aem.getFlowId());
            configModel = getConfig(realm, aem.getFlowId(), providerId);
            if (configModel!= null) return configModel;
        } else if (aem.getAuthenticator() != null &&
aem.getAuthenticator().equals(providerId)) {
            logger.info("authenticator: " + aem.getAuthenticator());
            configModel =
realm.getAuthenticatorConfigById(aem.getAuthenticatorConfig());
            break;
        }
    }
    return configModel;
}

Best regards

Alexis


Em dom, 17 de fev de 2019 ?s 22:11, Paulo Angelo <pa at pauloangelo.com>
escreveu:

> Thank you Thomas and Alexis!
>
> Another question: In the method "onEvent" of an EventListener, how could I
> get the configuration for one specific Authenticator?
>
> When the Authenticator is triggered (authenticate method), I can access
> its config using:
>
>     Map<String,String> config =
> context.getAuthenticatorConfig().getConfig();
>
> However, the context is not directly available (as expected) when the
> "EventListener.onEvent" is triggered.
>
> I could see in the documentation [1] that, inside the EventListener, I can
> have access to a KeycloakSession and a KeycloakSessionFactory. But I could
> not find the path for one specific Authenticator config. I also saw in docs
> that it is possible to save the configuration for the EventListener, but
> the attributes are the same used in the Authenticator.
>
> Is it possible to retrieve the configuration of a specific Authenticator
> in the flow used by the "event"?
>
> Thank you in advance,
>
> Paulo Angelo
>
> [1]
> https://www.keycloak.org/docs/3.3/server_development/topics/providers.html
>
>
>
> On Sun, Feb 17, 2019 at 6:25 PM Alexis Almeida <alexis.almeida at gmail.com>
> wrote:
>
>> Hi Paulo!
>>
>> In addition to Thomas suggestion, I usually capture the remote IP like
>> this:
>>
>> String ip = context.getSession (). GetContext (). GetConnection ().
>> GetRemoteAddr ();
>>
>> About login status, I think you must to change your approach to get
>> failure
>> login.
>>
>> In the authentication flow, if you put your authenticator provider before
>> "user and password" form this wil not work, because the user is not
>> authenticated yet.
>> If you put it after "user and passwrd" form, you'll only catch success
>> logins.
>>
>> So I think you could implement the EventListener class to get any event
>> type:
>>
>> public class RealmTeste implements EventListenerProvider, Authenticator {
>> ...
>>     public void onEvent(Event event) {
>>         String ip = event.getIpAddress();
>>         if (event.getType().equals("LOGIN_ERROR")) {
>>
>>         }
>>     }
>>     public void onEvent(AdminEvent event, boolean includeRepresentation) {
>>     }
>> ...
>>
>> Regards
>>
>> Al?xis
>>
>>
>> Em dom, 17 de fev de 2019 ?s 17:45, Thomas Darimont <
>> thomas.darimont at googlemail.com> escreveu:
>>
>> > Hello Paulo,
>> >
>> > in order to get the remote IP address of the request you could either
>> use
>> > the information from "ClientConnection" or look manually in the current
>> > HttpServletRequest,
>> > or HTTP-Headers. This structures can be obtained from the
>> > "ResteasyProviderFactory".
>> >
>> >         // See ResteasyProviderFactory.getContextDataMap() for what's
>> > available.
>> >
>> >         ClientConnection clientConnection =
>> > ResteasyProviderFactory.getContextData(ClientConnection.class);
>> >         clientConnection.getRemoteAddr();
>> >
>> >         HttpServletRequest request =
>> > ResteasyProviderFactory.getContextData(HttpServletRequest.class);
>> >
>> > Cheers,
>> > Thomas
>> >
>> > Am So., 17. Feb. 2019 um 19:47 Uhr schrieb Paulo Angelo <
>> > pa at pauloangelo.com>:
>> >
>> >> Hi All,
>> >>
>> >> The GuardianKey extension for KeyCloak is almost complete! Thank you
>> for
>> >> the given directions.
>> >>
>> >> We have to get the user client IP and the status of the authentication
>> >> attempt (failed/success). For this, we implemented the code below.
>> >> However,
>> >> we are facing Null Pointer exceptions.
>> >>
>> >> public class GuardianKeyAuthenticator implements Authenticator {  //
>> ...
>> >> public void authenticate(AuthenticationFlowContext context) {  // ...
>> >>          // *Trying to get the Client IP address*
>> >>            clientIP =
>> >>
>> >>
>> context.getSession().sessions().getUserSession(context.getAuthenticationSession().getClient().getRealm(),
>> >>
>> >> context.getAuthenticationSession().getClient().getId())
>> >>                                                      .getIpAddress();
>> /*
>> >> getting null pointer exception */
>> >>           // *Trying to get the status for the auth attempt
>> >> (failed/success), this Authenticator should be the last in the flow*
>> >>              failed = context.getStatus().equals(FlowStatus.SUCCESS);
>> /*
>> >> getting null pointer exception */
>> >>        // ...
>> >> } }
>> >>
>> >> Any clue about how we can do this?
>> >>
>> >> Thank you in advance.
>> >>
>> >> Paulo Angelo
>> >>
>> >>
>> >> On Sun, Feb 3, 2019 at 10:21 PM Paulo Angelo <pa at pauloangelo.com>
>> wrote:
>> >>
>> >> > Dmitry and Al?xis,
>> >> >
>> >> > Thank you very much for the directions. We are going to work on it.
>> >> >
>> >> > regards,
>> >> >
>> >> > Paulo Angelo
>> >> >
>> >> > On Sun, Feb 3, 2019 at 8:06 PM Dmitry Telegin <dt at acutus.pro> wrote:
>> >> >
>> >> >> Hello Paulo,
>> >> >>
>> >> >> To add to Alexis's reply, you can use Script authenticator [1]. It's
>> >> >> especially good for prototyping since you don't have to create and
>> >> deploy
>> >> >> the whole provider module.
>> >> >>
>> >> >> Also, you'll need an HttpClient instance to be able to perform
>> external
>> >> >> HTTP requests, see [2] for that.
>> >> >>
>> >> >> [1] https://www.keycloak.org/docs/latest/server_admin/#executions
>> >> >> [2]
>> >> >>
>> >>
>> http://lists.jboss.org/pipermail/keycloak-user/2018-November/016456.html
>> >> >>
>> >> >> Good luck,
>> >> >> Dmitry Telegin
>> >> >> CTO, Acutus s.r.o.
>> >> >> Keycloak Consulting and Training
>> >> >>
>> >> >> Pod lipami street 339/52, 130 00 Prague 3, Czech Republic
>> >> >> +42 (022) 888-30-71
>> >> >> E-mail: info at acutus.pro
>> >> >>
>> >> >> On Sun, 2019-02-03 at 17:46 -0200, Alexis Almeida wrote:
>> >> >> > Hi Paulo,
>> >> >> >
>> >> >> > IMO the simplest way to do this is with an Authenticator Provider.
>> >> >> Please
>> >> >> > see here:
>> >> >> >
>> >> >> >
>> >> >>
>> >>
>> https://www.keycloak.org/docs/latest/server_development/index.html#implementing-an-authenticator
>> >> >> > .
>> >> >> >
>> >> >> > In the authenticate method you can call the GuardianKey and,
>> >> depending
>> >> >> on
>> >> >> > the result, you call a context.success () or context.failure ().
>> >> >> >
>> >> >> > Like this:
>> >> >> >
>> >> >> > public void authenticate(AuthenticationFlowContext context) {
>> >> >> > ...
>> >> >> > if(!GuardianKeyValidation){
>> >> >> >    Response challenge = context.form()
>> >> >> >                 .setError("something")
>> >> >> >                 .createForm("error_page.ftl");
>> >> >> >
>> >> >> >
>> >> context.failureChallenge(AuthenticationFlowError.INVALID_CREDENTIALS,
>> >> >> > challenge);
>> >> >> >    return;
>> >> >> > }
>> >> >> > ...
>> >> >> > context.success();
>> >> >> > }
>> >> >> >
>> >> >> > Al?xis
>> >> >> >
>> >> >> >
>> >> >> > > Em dom, 3 de fev de 2019 ?s 15:38, Paulo Angelo <
>> >> pa at pauloangelo.com>
>> >> >> > escreveu:
>> >> >> >
>> >> >> > > Hi all,
>> >> >> > >
>> >> >> > > We are trying to integrate KeyCloak with GuardianKey. However,
>> we
>> >> have
>> >> >> > > doubts related to the best way to do this and the best point in
>> the
>> >> >> > > KeyCloak?s code for this integration.
>> >> >> > >
>> >> >> > > GuardianKey is a service to protect systems against
>> authentication
>> >> >> attacks.
>> >> >> > > It uses Machine Learning and analyses the user's behavior,
>> threat
>> >> >> > > intelligence and psychometrics (or behavioral biometrics). The
>> >> >> protected
>> >> >> > > system (in the concrete case, KeyCloak) must send an event via
>> REST
>> >> >> for the
>> >> >> > > GuardianKey on each login attempt. More info at
>> >> >> https://guardiankey.io .
>> >> >> > >
>> >> >> > > The best way to integrate would be on having a hook in the
>> >> procedure
>> >> >> that
>> >> >> > > process the user credentials submission in KeyCloak (the script
>> >> that
>> >> >> > > receives the POST), something such as:
>> >> >> > >
>> >> >> > > if(<POST IN AUTH FORM>) {
>> >> >> > >
>> >> >> > >  boolean loginFailed =  checkLoginInKeyCloak();
>> >> >> > >
>> >> >> > >  GuardianKeyEvent event =
>> >> >> createEventForGuardianKey(username,loginFailed);
>> >> >> > >
>> >> >> > >  boolean GuardianKeyValidation = checkGuardianKeyViaREST(event);
>> >> >> > >
>> >> >> > >  if(GuardianKeyValidation){
>> >> >> > >
>> >> >> > >     // Allow access
>> >> >> > >
>> >> >> > >  } else {
>> >> >> > >
>> >> >> > >     // Deny access
>> >> >> > >
>> >> >> > >  }
>> >> >> > >
>> >> >> > > }
>> >> >> > >
>> >> >> > > Where is the best place to create this integration? Is there a
>> way
>> >> to
>> >> >> > > create a hook for this purpose? Should we create an extension?
>> >> >> > >
>> >> >> > > Any help is welcome.
>> >> >> > >
>> >> >> > > Thank you in advance.
>> >> >> > >
>> >> >> > > Best regards,
>> >> >> > >
>> >> >> > > Paulo Angelo
>> >> >> > > _______________________________________________
>> >> >> > > keycloak-dev mailing list
>> >> >> > > keycloak-dev at lists.jboss.org
>> >> >> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> >> >> >
>> >> >> > _______________________________________________
>> >> >> > keycloak-dev mailing list
>> >> >> > keycloak-dev at lists.jboss.org
>> >> >> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> >> >> _______________________________________________
>> >> >> keycloak-dev mailing list
>> >> >> keycloak-dev at lists.jboss.org
>> >> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> >
>> >> > Att,
>> >> >
>> >> > Paulo Angelo
>> >> >
>> >>
>> >>
>> >> --
>> >>
>> >> Att,
>> >>
>> >> Paulo Angelo
>> >> _______________________________________________
>> >> 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
>
>
>
> --
>
> Att,
>
> Paulo Angelo
>

From sguilhen at redhat.com  Tue Feb 19 11:20:52 2019
From: sguilhen at redhat.com (Stefan Guilhen)
Date: Tue, 19 Feb 2019 13:20:52 -0300
Subject: [keycloak-dev] Why does client session expire regardless
 remember-me extended validity?
In-Reply-To: <f720c7a7-f25d-2c63-1e18-e894a393d2e7@yahoo.de>
References: <7637f53f-dd9b-2a3c-3816-a25d14ca189a@yahoo.de>
	<685a0dff-80b9-ddd6-18ff-4847755204df@redhat.com>
	<CA+7ohf=nRhHaWhk7vOfRZ1j1fOHLUwNRsmS5KQiXv7PVabyk8g@mail.gmail.com>
	<c7d47317-2297-534c-8bc2-407a0da21a47@yahoo.de>
	<CA+7ohfm=GbNpnhLpSNDjHmnoR_5oc=utZe09JP41iqVgvMdKQw@mail.gmail.com>
	<6852a835-88f0-7408-e6ea-41f77ea8b12e@redhat.com>
	<f720c7a7-f25d-2c63-1e18-e894a393d2e7@yahoo.de>
Message-ID: <CA+7ohfm3zyY+1cHiQStVK7vbXP5i9uw-nx49Z50xyMMRLHHYcA@mail.gmail.com>

Marek, my understanding is the same as Ken's here. In my mind if an admin
has set non zero values for the remember me timeouts and we have a session
with remember me enabled then the specific remember me values should be
used in session timeout checks, not the min or max between remember me and
the default lifespan timeouts.

Also, as Ken has pointed out, the expiredRememberMe value assumes the
default lifespan value if the remember me timeout hasn't been set (i.e. it
is zero in the config), so using it also covers the case where where no
remember me timeouts exist or where the session hasn't the remember me
enabled.

I'll definitely look into enhancing the tests to test the client session
timeout.

On Mon, Feb 18, 2019, 13:11 Ken Haendel <kschwiersch at yahoo.de wrote:

>
> Am 15.02.19 um 14:56 schrieb Marek Posolda:
>
> IMO single PR is fine. But I suggest to create new JIRA or update
> description of existing JIRA, so that it contains also the description for
> this "new" bug.
>
> 2 minor things:
> - Is it possible to update this check, so it considers the "min(expired,
> expiredRememberMe)" instead of being hardcoded to expiredRememberMe? In
> most cases, the "ssoSessionMAxLifespanRememberMe" is bigger than
> "ssoSessionMaxLifespan", however it may not be always true. For example,
> someone can want to increase ssoSessionMaxLifespan to some very big value,
> but he doesn't use "remember me", so he won't increase the
> "ssoSessionMAxLifespanRememberMe" .
>
> 1.
>
> min(expired, expiredRememberMe) is NOT the right formula for the normal
> case, where rememberMe is a bigger value than SsoSessionMaxLifespan. It
> would choose the smaller value. Do you mean max?
>
> 2.
>
> You are describing a scenario, where ssoSessionMaxLifespan is used with a
> very high value and remember-me is turned off. This could of course be the
> case, but
>
> the variable expiredRememberMe does already check, if a remember-me
> timeout has been set or not (realm.getSsoSessionMaxLifespanRememberMe() >
> 0) line 488.
>
> Every person, that does not use remember-me will leave the remember-me
> timeouts zero. Therefore my check would work for them and
> SsoSessionMaxLifespan would be used instead.
>
>
> But this is just my two cents.
>
>
> Regards,
>
> Ken
>
>
> - Is it possible to add the test for the buggy scenarios? It is hard to
> test it properly, but we somehow test it with usage of time offset and
> manually invoking "expiration check". It is done in UserSessionProviderTest
> - please make sure to use the one from new testsuite as this test is
> currently duplicated in both the new and old testsuite :(
>
> WDYT?
> Marek
>
> On 15/02/2019 02:57, Stefan Guilhen wrote:
>
> Hi Ken,
>
> Yes, it does make sense to me to use the remember-me value for the client
> session as well. Marek, WDYT? Should we open a new Jira just for this or
> can I just amend the commit to include this fix too?
>
> Stefan
>
> On Thu, Feb 14, 2019 at 10:34 AM Ken Haendel <kschwiersch at yahoo.de> wrote:
>
>> Hi Stefan, Marek
>>
>>
>> Thank you for your quick reply.
>>
>> I have recently tested your pull request [1], if that fixes my issue with
>> the expired client session cache and it does NOT. It only fixes an issue
>> with the user session cache.
>>
>> My proposal to fix that problem would be as follows (verified here):
>>
>> diff --git
>> a/model/infinispan/src/main/java/org/keycloak/models/sessions/infinispan/InfinispanUserSessionProvider.java
>> b/model/infinispan/src/main/java/org/keycloak/models/sessions/infinispan/InfinispanUserSessionProvider.java
>> index b1429a6391..54cb244624 100755
>> ---
>> a/model/infinispan/src/main/java/org/keycloak/models/sessions/infinispan/InfinispanUserSessionProvider.java
>> +++
>> b/model/infinispan/src/main/java/org/keycloak/models/sessions/infinispan/InfinispanUserSessionProvider.java
>> @@ -529,7 +529,7 @@ public class InfinispanUserSessionProvider implements
>> UserSessionProvider {
>>          localClientSessionCacheStoreIgnore
>>                  .entrySet()
>>                  .stream()
>> -
>> .filter(AuthenticatedClientSessionPredicate.create(realm.getId()).expired(expired))
>> +
>> .filter(AuthenticatedClientSessionPredicate.create(realm.getId()).expired(expiredRememberMe))
>>
>>
>> Using that change, the life span of the client session would be longer
>> for remember-me logins.
>>
>> Can you please check if that makes sense for you?
>>
>> It would be nice if a fix could be added in the next releases to make it
>> unnecessary to patch the further release :-)
>>
>> Kind regards,
>>
>> Ken
>>
>>
>> [1] https://github.com/keycloak/keycloak/pull/5852
>> Am 13.02.19 um 18:27 schrieb Stefan Guilhen:
>>
>> It is possible that Ken is seeing something different. I will take a look
>> into it to be sure.
>>
>> Best regards,
>> Stefan
>>
>> On Wed, Feb 13, 2019, 13:43 Marek Posolda <mposolda at redhat.com wrote:
>>
>>> We have PR open, which is related to that [1], but not sure if that PR
>>> fixes also your issue. It seems there is nothing related to client
>>> sessions. I am CCing Stefan in case he has some more to it.
>>>
>>> In the meantime, if you are curious if fix works, I suggest to
>>> cherry-pick Stefan's commit and build Keycloak and check if the
>>> behaviour is fixed with that PR.
>>>
>>> [1] https://github.com/keycloak/keycloak/pull/5852
>>>
>>> Marek
>>>
>>> On 13/02/2019 14:15, Ken Haendel wrote:
>>> > I have a problem authenticating a spring secured web-app using keycloak
>>> > 4.8.3.
>>> >
>>> > If the user logs in with remember-me enabled, the user session does use
>>> > a larger SSO max life span (ssoSessionMaxLifespanRememberMe).
>>> >
>>> > So far so good.
>>> >
>>> > Now i want to call another secured REST-API using the
>>> KeycloakRestService.
>>> >
>>> > That triggers OAuthRequestAuthenticator to verify token
>>> > (AdapterTokenVerifier.verifyTokens).
>>> >
>>> > That operation fails, because the client session expired much earlier
>>> > (after ssoSessionMaxLifespan). The client session gets removed from the
>>> > client session cache
>>> > (InfinispanUserSessionProvider.removeExpiredUserSessions).
>>> >
>>> > Error message of AdapterTokenVerifier.verifyTokens() is:
>>> >
>>> > "ERROR RefreshableKeycloakSecurityContext Refresh token failure status:
>>> > 400 {"error":"invalid_grant","error_description":"Session doesn't have
>>> > required client"}"
>>> >
>>> >
>>> > So, the point is: after the client session gets removed from cache (SSO
>>> > max life span) i can no longer use the refresh token to request new
>>> > tokens and call another REST-API service
>>> >
>>> > using the same identity as the web-app.
>>> >
>>> > Even though i have still a valid user session to use my spring app.
>>> >
>>> >
>>> > Expectation was: I can use refresh token within the larger time span
>>> > with remember-me enabled (SsoSessionMaxLifespanRememberMe).
>>> >
>>> > Actual behaviour is: Refresh token gets useless within the shorter time
>>> > span (ssoSessionMaxLifespan)
>>> >
>>> > Question: Why is the client session removed so early and not when the
>>> > user session expires? Is that expected behavoiur?
>>> >
>>> > Thank you in advance,
>>> >
>>> > Ken
>>> >
>>> >
>>> > _______________________________________________
>>> > 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 mposolda at redhat.com  Tue Feb 19 11:31:04 2019
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 19 Feb 2019 17:31:04 +0100
Subject: [keycloak-dev] Why does client session expire regardless
 remember-me extended validity?
In-Reply-To: <CA+7ohfm3zyY+1cHiQStVK7vbXP5i9uw-nx49Z50xyMMRLHHYcA@mail.gmail.com>
References: <7637f53f-dd9b-2a3c-3816-a25d14ca189a@yahoo.de>
	<685a0dff-80b9-ddd6-18ff-4847755204df@redhat.com>
	<CA+7ohf=nRhHaWhk7vOfRZ1j1fOHLUwNRsmS5KQiXv7PVabyk8g@mail.gmail.com>
	<c7d47317-2297-534c-8bc2-407a0da21a47@yahoo.de>
	<CA+7ohfm=GbNpnhLpSNDjHmnoR_5oc=utZe09JP41iqVgvMdKQw@mail.gmail.com>
	<6852a835-88f0-7408-e6ea-41f77ea8b12e@redhat.com>
	<f720c7a7-f25d-2c63-1e18-e894a393d2e7@yahoo.de>
	<CA+7ohfm3zyY+1cHiQStVK7vbXP5i9uw-nx49Z50xyMMRLHHYcA@mail.gmail.com>
Message-ID: <7954bf60-9c4a-f081-4f07-ac59149acb40@redhat.com>

On 19/02/2019 17:20, Stefan Guilhen wrote:
> Marek, my understanding is the same as Ken's here. In my mind if an 
> admin has set non zero values for the remember me timeouts and we have 
> a session with remember me enabled then the specific remember me 
> values should be used in session timeout checks, not the min or max 
> between remember me and the default lifespan timeouts.
>
> Also, as Ken has pointed out, the expiredRememberMe value assumes the 
> default lifespan value if the remember me timeout hasn't been set 
> (i.e. it is zero in the config), so using it also covers the case 
> where where no remember me timeouts exist or where the session hasn't 
> the remember me enabled.
Ah, ok. I missed that "SSO Session Max Remember Me" is set to 0 by 
default, which means it is just inherited from the "SSO Session Max". 
Sorry, my bad.
>
> I'll definitely look into enhancing the tests to test the client 
> session timeout.

Cool, Thanks!

Marek

>
> On Mon, Feb 18, 2019, 13:11 Ken Haendel <kschwiersch at yahoo.de 
> <mailto:kschwiersch at yahoo.de> wrote:
>
>
>     Am 15.02.19 um 14:56 schrieb Marek Posolda:
>>     IMO single PR is fine. But I suggest to create new JIRA or update
>>     description of existing JIRA, so that it contains also the
>>     description for this "new" bug.
>>
>>     2 minor things:
>>     - Is it possible to update this check, so it considers the
>>     "min(expired, expiredRememberMe)" instead of being hardcoded to
>>     expiredRememberMe? In most cases, the
>>     "ssoSessionMAxLifespanRememberMe" is bigger than
>>     "ssoSessionMaxLifespan", however it may not be always true. For
>>     example, someone can want to increase ssoSessionMaxLifespan to
>>     some very big value, but he doesn't use "remember me", so he
>>     won't increase the "ssoSessionMAxLifespanRememberMe" .
>
>     1.
>
>     min(expired, expiredRememberMe) is NOT the right formula for the
>     normal case, where rememberMe is a bigger value than
>     SsoSessionMaxLifespan. It would choose the smaller value. Do you
>     mean max?
>
>     2.
>
>     You are describing a scenario, where ssoSessionMaxLifespan is used
>     with a very high value and remember-me is turned off. This could
>     of course be the case, but
>
>     the variable expiredRememberMe does already check, if a
>     remember-me timeout has been set or not
>     (realm.getSsoSessionMaxLifespanRememberMe() > 0) line 488.
>
>     Every person, that does not use remember-me will leave the
>     remember-me timeouts zero. Therefore my check would work for them
>     and SsoSessionMaxLifespan would be used instead.
>
>
>     But this is just my two cents.
>
>
>     Regards,
>
>     Ken
>
>
>>     - Is it possible to add the test for the buggy scenarios? It is
>>     hard to test it properly, but we somehow test it with usage of
>>     time offset and manually invoking "expiration check". It is done
>>     in UserSessionProviderTest - please make sure to use the one from
>>     new testsuite as this test is currently duplicated in both the
>>     new and old testsuite :(
>>
>>     WDYT?
>>     Marek
>>
>>     On 15/02/2019 02:57, Stefan Guilhen wrote:
>>>     Hi Ken,
>>>
>>>     Yes, it does make sense to me to use the remember-me value for
>>>     the client session as well. Marek, WDYT? Should we open a new
>>>     Jira just for this or can I just amend the commit to include
>>>     this fix too?
>>>
>>>     Stefan
>>>
>>>     On Thu, Feb 14, 2019 at 10:34 AM Ken Haendel
>>>     <kschwiersch at yahoo.de <mailto:kschwiersch at yahoo.de>> wrote:
>>>
>>>         Hi Stefan, Marek
>>>
>>>
>>>         Thank you for your quick reply.
>>>
>>>         I have recently tested your pull request [1], if that fixes
>>>         my issue with the expired client session cache and it does
>>>         NOT. It only fixes an issue with the user session cache.
>>>
>>>         My proposal to fix that problem would be as follows
>>>         (verified here):
>>>
>>>         diff --git
>>>         a/model/infinispan/src/main/java/org/keycloak/models/sessions/infinispan/InfinispanUserSessionProvider.java
>>>         b/model/infinispan/src/main/java/org/keycloak/models/sessions/infinispan/InfinispanUserSessionProvider.java
>>>         index b1429a6391..54cb244624 100755
>>>         ---
>>>         a/model/infinispan/src/main/java/org/keycloak/models/sessions/infinispan/InfinispanUserSessionProvider.java
>>>         +++
>>>         b/model/infinispan/src/main/java/org/keycloak/models/sessions/infinispan/InfinispanUserSessionProvider.java
>>>         @@ -529,7 +529,7 @@ public class
>>>         InfinispanUserSessionProvider implements UserSessionProvider {
>>>         localClientSessionCacheStoreIgnore
>>>         ???????????????? .entrySet()
>>>         ???????????????? .stream()
>>>         -
>>>         .filter(AuthenticatedClientSessionPredicate.create(realm.getId()).expired(expired))
>>>         +
>>>         .filter(AuthenticatedClientSessionPredicate.create(realm.getId()).expired(expiredRememberMe))
>>>
>>>
>>>         Using that change, the life span of the client session would
>>>         be longer for remember-me logins.
>>>
>>>         Can you please check if that makes sense for you?
>>>
>>>         It would be nice if a fix could be added in the next
>>>         releases to make it unnecessary to patch the further release :-)
>>>
>>>         Kind regards,
>>>
>>>         Ken
>>>
>>>
>>>         [1] https://github.com/keycloak/keycloak/pull/5852
>>>
>>>         Am 13.02.19 um 18:27 schrieb Stefan Guilhen:
>>>>         It is possible that Ken is seeing something different. I
>>>>         will take a look into it to be sure.
>>>>
>>>>         Best regards,
>>>>         Stefan
>>>>
>>>>         On Wed, Feb 13, 2019, 13:43 Marek Posolda
>>>>         <mposolda at redhat.com <mailto:mposolda at redhat.com> wrote:
>>>>
>>>>             We have PR open, which is related to that [1], but not
>>>>             sure if that PR
>>>>             fixes also your issue. It seems there is nothing
>>>>             related to client
>>>>             sessions. I am CCing Stefan in case he has some more to it.
>>>>
>>>>             In the meantime, if you are curious if fix works, I
>>>>             suggest to
>>>>             cherry-pick Stefan's commit and build Keycloak and
>>>>             check if the
>>>>             behaviour is fixed with that PR.
>>>>
>>>>             [1] https://github.com/keycloak/keycloak/pull/5852
>>>>
>>>>             Marek
>>>>
>>>>             On 13/02/2019 14:15, Ken Haendel wrote:
>>>>             > I have a problem authenticating a spring secured
>>>>             web-app using keycloak
>>>>             > 4.8.3.
>>>>             >
>>>>             > If the user logs in with remember-me enabled, the
>>>>             user session does use
>>>>             > a larger SSO max life span
>>>>             (ssoSessionMaxLifespanRememberMe).
>>>>             >
>>>>             > So far so good.
>>>>             >
>>>>             > Now i want to call another secured REST-API using the
>>>>             KeycloakRestService.
>>>>             >
>>>>             > That triggers OAuthRequestAuthenticator to verify token
>>>>             > (AdapterTokenVerifier.verifyTokens).
>>>>             >
>>>>             > That operation fails, because the client session
>>>>             expired much earlier
>>>>             > (after ssoSessionMaxLifespan). The client session
>>>>             gets removed from the
>>>>             > client session cache
>>>>             >
>>>>             (InfinispanUserSessionProvider.removeExpiredUserSessions).
>>>>             >
>>>>             > Error message of AdapterTokenVerifier.verifyTokens() is:
>>>>             >
>>>>             > "ERROR RefreshableKeycloakSecurityContext Refresh
>>>>             token failure status:
>>>>             > 400
>>>>             {"error":"invalid_grant","error_description":"Session
>>>>             doesn't have
>>>>             > required client"}"
>>>>             >
>>>>             >
>>>>             > So, the point is: after the client session gets
>>>>             removed from cache (SSO
>>>>             > max life span) i can no longer use the refresh token
>>>>             to request new
>>>>             > tokens and call another REST-API service
>>>>             >
>>>>             > using the same identity as the web-app.
>>>>             >
>>>>             > Even though i have still a valid user session to use
>>>>             my spring app.
>>>>             >
>>>>             >
>>>>             > Expectation was: I can use refresh token within the
>>>>             larger time span
>>>>             > with remember-me enabled
>>>>             (SsoSessionMaxLifespanRememberMe).
>>>>             >
>>>>             > Actual behaviour is: Refresh token gets useless
>>>>             within the shorter time
>>>>             > span (ssoSessionMaxLifespan)
>>>>             >
>>>>             > Question: Why is the client session removed so early
>>>>             and not when the
>>>>             > user session expires? Is that expected behavoiur?
>>>>             >
>>>>             > Thank you in advance,
>>>>             >
>>>>             > Ken
>>>>             >
>>>>             >
>>>>             > _______________________________________________
>>>>             > 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
>>>>
>>>>
>>>
>>>
>>>     -- 
>>>
>>>     STEFAN GUILHEN
>>>
>>>     PRINCIPAL SOFTWARE ENGINEER
>>>
>>>     Red Hat<https://www.redhat.com/>
>>>
>>>     sguilhen at redhat.com <mailto:sguilhen at redhat.com> M:
>>>     +55-11-98117-7332 <tel:+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 Sebastian.Loesch at governikus.de  Tue Feb 19 23:29:53 2019
From: Sebastian.Loesch at governikus.de (=?iso-8859-1?Q?L=F6sch=2C_Sebastian?=)
Date: Wed, 20 Feb 2019 04:29:53 +0000
Subject: [keycloak-dev] Allow AdminEvents for custom resource types
Message-ID: <b15b7ae09d5343318384c9b2bfa052a5@BOSKGEXC01.boskg.local>

Hello devs,

we implemented a custom resource type as an extension to keycloak.
For traceability reasons we would like to track actions for this custom resource type via AdminEvents.
Unfortunately the resource type is represented by the enum ResourceType. Therefore no AdminEvents for custom non standard resource types can be created.
It would be nice if it is possible to specify the resource type as string value also.

This is only a small change, because the resource type is only provided via enum but handled as string value internally.
I provided a pull request for that enhancement: https://github.com/keycloak/keycloak/pull/5882

May anybody have a look on that review?

Best regards,
Sebastian




From sthorger at redhat.com  Wed Feb 20 05:42:20 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 20 Feb 2019 11:42:20 +0100
Subject: [keycloak-dev] Allow AdminEvents for custom resource types
In-Reply-To: <b15b7ae09d5343318384c9b2bfa052a5@BOSKGEXC01.boskg.local>
References: <b15b7ae09d5343318384c9b2bfa052a5@BOSKGEXC01.boskg.local>
Message-ID: <CAJgngAf_76NRtyzhb6-ecBPwviMK0bijooB=PEgGqOWjOhV8Qg@mail.gmail.com>

We can't accept the PR as is due to it breaking backwards compatibility of
the API.

Can you elaborate on your use-case? I'm far from convinced we should
support this level of customisation.

On Wed, 20 Feb 2019, 05:32 L?sch, Sebastian, <Sebastian.Loesch at governikus.de>
wrote:

> Hello devs,
>
> we implemented a custom resource type as an extension to keycloak.
> For traceability reasons we would like to track actions for this custom
> resource type via AdminEvents.
> Unfortunately the resource type is represented by the enum ResourceType.
> Therefore no AdminEvents for custom non standard resource types can be
> created.
> It would be nice if it is possible to specify the resource type as string
> value also.
>
> This is only a small change, because the resource type is only provided
> via enum but handled as string value internally.
> I provided a pull request for that enhancement:
> https://github.com/keycloak/keycloak/pull/5882
>
> May anybody have a look on that review?
>
> Best regards,
> Sebastian
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From Sebastian.Loesch at governikus.de  Wed Feb 20 06:39:47 2019
From: Sebastian.Loesch at governikus.de (=?utf-8?B?TMO2c2NoLCBTZWJhc3RpYW4=?=)
Date: Wed, 20 Feb 2019 11:39:47 +0000
Subject: [keycloak-dev] Allow AdminEvents for custom resource types
In-Reply-To: <CAJgngAf_76NRtyzhb6-ecBPwviMK0bijooB=PEgGqOWjOhV8Qg@mail.gmail.com>
References: <b15b7ae09d5343318384c9b2bfa052a5@BOSKGEXC01.boskg.local>
	<CAJgngAf_76NRtyzhb6-ecBPwviMK0bijooB=PEgGqOWjOhV8Qg@mail.gmail.com>
Message-ID: <d3ca8e635b09445d9f8a5a231863a602@BOSKGEXC01.boskg.local>

>We can't accept the PR as is due to it breaking backwards compatibility of the API.

Ah, I overlooked the EventListenerProvider interface. That?s the point where AdminEvent becomes public API, right?



Our use-case is as follows: we need to support user substitutions. User Jane goes for vacation and nominates John as her substitute in a defined time period. John has all of Janes Roles and is able to perform her tasks.

We implement this substitution as a keycloak extension. All substitutions must be tracked. We want to implement this using the AdminEvents.



Do you have any other suggestions how we can accomplish tracking?



Best regards,

Sebastian



Von: Stian Thorgersen <sthorger at redhat.com>
Gesendet: Mittwoch, 20. Februar 2019 11:42
An: L?sch, Sebastian <Sebastian.Loesch at governikus.de>
Cc: keycloak-dev <keycloak-dev at lists.jboss.org>
Betreff: Re: [keycloak-dev] Allow AdminEvents for custom resource types



We can't accept the PR as is due to it breaking backwards compatibility of the API.



Can you elaborate on your use-case? I'm far from convinced we should support this level of customisation.



On Wed, 20 Feb 2019, 05:32 L?sch, Sebastian, <Sebastian.Loesch at governikus.de<mailto:Sebastian.Loesch at governikus.de>> wrote:

   Hello devs,

   we implemented a custom resource type as an extension to keycloak.
   For traceability reasons we would like to track actions for this custom resource type via AdminEvents.
   Unfortunately the resource type is represented by the enum ResourceType. Therefore no AdminEvents for custom non standard resource types can be created.
   It would be nice if it is possible to specify the resource type as string value also.

   This is only a small change, because the resource type is only provided via enum but handled as string value internally.
   I provided a pull request for that enhancement: https://github.com/keycloak/keycloak/pull/5882

   May anybody have a look on that review?

   Best regards,
   Sebastian



   _______________________________________________
   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 mposolda at redhat.com  Wed Feb 20 08:03:46 2019
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 20 Feb 2019 14:03:46 +0100
Subject: [keycloak-dev] Improving support for LDAP backed Keycloak
In-Reply-To: <9695FE33-85A2-48BC-B440-D50452D070DF@adaptavist.com>
References: <9695FE33-85A2-48BC-B440-D50452D070DF@adaptavist.com>
Message-ID: <08405d13-3621-5ac2-3021-606295bc71c6@redhat.com>

On 18/02/2019 18:39, Dan Hardiker wrote:
> Hi All,
>
> Sorry for such a long first post. Here we go!
>
>
> TL;DR:
> I want to look at https://issues.jboss.org/browse/KEYCLOAK-5571 as it is impacting us. I?m happy to contribute code or write a blog on what configuration settings are needed to achieve this. While the SAGA has more context, here?s a few of my currently burning questions:
Cool!
>
> 1. What implements the org.keycloak.admin.client.resource.UserResource.update(UserRepresentation) and UserRepresentation ...toRepresentation() interface method? (from the integration/admin-client directory - I can?t find the business logic)
The implementation is "auto-generated" proxy class, which just invokes 
the particular admin REST endpoint - for example 
org.keycloak.admin.client.resource.UserResource.update is invoked the 
server-side REST endpoint 
org.keycloak.services.resources.admin.UserResource.updateUser
> 2. What would be the right approach to wire up the admin ui User Enabled toggle to a LDAP boolean field, and where in the codebase would that go? (if you can cite examples of similar that would be great)

UserAttributeLDAPStorageMapper is the class where you can look at. As you can see in the "proxy" method, the proxied model implements setFirstName, setLastNAme, setEmail .
It seems that few more things need to be added (EG. setEnabled, setEmailVerified)

The automated test may need to be added somewhere in LDAPProvidersIntegrationTest IMO.

> 3. What is the best way to go about setting up an IDE for development? Just importing the root POM into IDEA doesn?t seem to cut it.
Importing the root POM into IDEA works fine for me.
> 4. If I provide a patch for this, is this something that might be considered for pulling into master?

Yes. There needs to be few simple rules met when you want something to 
be considered into master. We're working on improving guidelines for 
contributors. See details in this PR: 
https://github.com/keycloak/keycloak/pull/5886/files . You just already 
started the discussion on keycloak-dev mailing list, which is nice 1st 
step. Good luck with moving forward on your contribution!

Marek

>
> I am interested in all of the features within KEYCLOAK-5571, as a few other requirements, but I?m happy to start here and treat the others as atomic suggested changes. They may include:
>
> * Supporting incremented default values for new users (the uidNumber must be unique and it should be 1 greater than the highest uidNumber that the system can see ? i.e. the next available UID).
> * Supporting out-of-band password recovery (where by a code is sent via a trusted path [text message, telephone call, in person conversation with the user] which can be used to reset their password - ideally in combination with another stored value, such as their employee id / tax id / post code / something else which is relatively static but relatively unknown) - this could be developed outside of Keycloak of course, but would ideally be within the same system.
>
> If addressing KEYCLOAK-5571 goes well, I would be interested in continuing to contribute down these paths.
>
> Thanks for your time, I would love to get involved ? I just need a bit of help.
>
>
> THE SAGA:
> Apologies if this message should be in keycloak-users, and if any of it seems incoherent. I?ve been fighting in circles all weekend and I have to admit that I?m not entirely sure I?m approaching the problem correctly. Please bear with me as I?m not entirely sure how to articulate things at this point, but I know I need help!
>
> Problem statement: we are currently using OpenLDAP to manage access to our systems. However, the administration interface is crude and it lacks SAML/OIDC support for integrating systems like Google Suite, AWS Console, Office 365 and others. It also lacks a self service console where users can mange their own accounts. Keycloak at first glance looks ideal - especially as it allows us to continue using OpenLDAP as the primary source of truth, with Keycloak used to enhance the user experience giving self service and integration with SAML/OIDC clients.
>
> As per the docs, some mapping is required to have OpenLDAP support the storage of Keycloak data within the OpenLDAP schemas. Unfortunately, I?ve not bee able to find documentation for what those fields names in Keycloak can be and how I should alter my OpenLDAP schema to support them. I found KEYCLOAK-5571 which appears to cover at least some of the issues I?m having. Amongst other things, I?m a Java developer, so I?m comfortable with working in code and submitting patches. Assuming that the answer isn?t configuration, is this something that would be valuable to contribute? If so, is there any advice that this list can offer on where to start?
>
> What follows is my journey as an outsider into trying to figure out things myself. This may or may not be of interest - but given this list gets indexed by Google, it might help someone in future. Seeing that issue (KEYCLOAK-5571) I figured the best place to start would be the admin ui where you enable/disable users. I thought that I would start at the browser and try to figure out what the enabled/disable user toggle did when saved, trace that into the server side endpoint that picked up that representation and hopefully find out where & why it didn?t make it through to LDAP.
>
> I noticed that there was a PUT to http://localhost/auth/admin/realms/master/users/f:$UUID:$USERNAME and as part of the JSON payload was ?enabled: false?. At this point I started grepping around in the Keycloak code. I figured that org.keycloak.admin.client.resource.UserResource.update(UserRepresentation) Interface was what was being called, but unfortunately when I opened up the root POM then IDEA only saw the files as plain text and none of the Intelisense worked, I could grep around the code though. When I opened up the integration/admin-client/pom.xml it recognise the Java files, however I wasn?t able to find what was implementing this. If found "public static UserRepresentation toRepresentation(KeycloakSession session, RealmModel realm, UserModel user)? in server-spi-private org.keycloak.models.util.ModelToRepresentation, but couldn?t find the glue which connects them together. I?m guessing there might be some WildFly or other magic going on which I?m not aware of?
>
> Seeing the ?enabled: false? lead me to think that I might be able to create a user-attribute-ldap-mapper from the user model attribute ?enabled? to an ?enabled? LDAP attribute I added to our schema to test. The LDAP attribute has SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 (a binary attribute) and I?ve checked I can set that to TRUE / FALSE appropriately. I set it to be mandatory in LDAP and set it to be a Binary Attribute - however when I save it says "Error! With Binary attribute enabled, the 'Always read value from LDAP' must be enabled too? - however there is no ?Always read value from LDAP? option! However, after enabling Import Users in the LDAP user federation settings, ?Always read value from LDAP? becomes available. It?s not clear if Binary Attributes are supported only in this configuration, but ideally I would like to not Import Users as I prefer LDAP to be the authoritative source. After this I can disabled Import Users and the configuration still seemingly remains valid without any errors in the logs. That said, it?s not erroring about not properly persisting the enabled state to LDAP...
>
> If I go across to the user in the admin ui, even though enabled is set to FALSE in LDAP, the toggle is showing as enabled in the UI. The JSON it gets for the UserRepresentation on the client side is ?enabled?:true which explains the state of the toggle. If I stick Wireshark locally, setup a Docker with OpenLDAP and configure it appropriately, sniffing traffic I can see that the enabled attribute for my user comes back as FALSE. So there is something going wrong when trying to build that UserRepresentation. I suspect at the root of the KEYCLOAK-5571 issue. If I change the toggle to false in the UI and save, then reload the page, the toggle is back to true - when it persists to the LDAP server, it?s sending enabled: FALSE - this doesn?t make sense, but it might be just repeating back to LDAP what it read in without changing that field. If I change the name as well, it does send those fields updated, but enabled remains FALSE in the LDAP server.
>
> Given that I didnt get very far with the UserRepresentation angle, I thought about going down the FederatedStorage - something must map the model into LDAP, as changes to the first name / last name, and the other attributes seem to be persisted and loaded in LDAP just fine. In my grepping around in server-spi I found a org.keycloak.models.UserModel Interface, which had a org.keycloak.storage.adapter.AbstractUserAdapterFederatedStorage implementation with a ENABLED_ATTRIBUTE = ?ENABLED? field and isEnabled / setEnabled methods which getFirstAttribute(ENABLED_ATTRIBUTE) / setSingleAttribute(ENABLED_ATTRIBUTE, Boolean.toString(enabled). The class comment has:
>
> * Assumes everything is managed by federated storage except for username.  getId() returns a default value
> * of "f:" + providerId + ":" + getUsername().  UserModel properties like enabled, firstName, lastName, email, etc. are all
> * stored as attributes in federated storage.
>
> I?m not sure how the case difference between ?enabled? in the UserModel properties and ?ENABLED? as listed in the class field is connected - but there must be a mapping somewhere, as ?firstName? is similarly ?FIRST_NAME? and that maps just fine. I found model/jpa contained org.keycloak.models.jpa.entities/UserEntity which had @Column(name = "ENABLED?) protected boolean enabled, perhaps this is the link and even with Import Users disabled it always goes through the database?
>
> I?ve yet to find the trigger which calls the mapper to run which persists into the database. Part of the problem is that I?m acutely aware my IDE is not setup to effectively jump around the code base, or to effectively attach my IDE as a debugger so I can add breakpoints and step through the code to figure out what happens where. I?ve just turned on trace logging - but this is giving me a wall of text which may take sometime to process. I?ve also yet to comb through the H2 DB to see if there?s cause there.
>
> Any assistance on this would be most welcome.
>
>
> ON ANOTHER NOTE:
> I checked out the code and ran the build as documented against Java 8 on my mac, but unfortunately it failed. I ignored it and progressed, but here?s some excerpts from the output:
> [INFO] Keycloak Integration TestSuite - deprecated ........ FAILURE [07:04 min]
>
> [ERROR] Errors:
> [ERROR]   OIDCKeyCloakServerBrokerBasicTest.testLogoutWorksWithTokenTimeout:131 ? Processing
> [ERROR]   OIDCKeycloakServerBrokerWithConsentTest.before:84 ? Processing java.lang.NoSuc...
> [ERROR]   BrokenUserStorageTest.testBootWithBadProviderId:118 ? Processing java.lang.NoS...
> [ERROR]   JaxrsBasicAuthTest.testBasic:120 ? NoSuchMethod org.apache.commons.io.output.D...
> [ERROR]   JaxrsFilterTest.testBasic:129 ? NoSuchMethod org.apache.commons.io.output.Defe...
> [ERROR] Tests run: 238, Failures: 0, Errors: 5, Skipped: 32
>
> I guess this shouldn?t happen on a fresh check out & a following of the instruction.
>
>
> If you made it this far - bravo!
>
> Thanks again,
>
>
> ?
> Dan Hardiker | Adaptavist
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



From mposolda at redhat.com  Wed Feb 20 08:12:09 2019
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 20 Feb 2019 14:12:09 +0100
Subject: [keycloak-dev] ClientDescriptionConverter
In-Reply-To: <CAHBgxzvDsNLGVgkrq878K0bARR+BDW2SDvbnnKcvODy9DDjfHg@mail.gmail.com>
References: <CAHBgxzvDsNLGVgkrq878K0bARR+BDW2SDvbnnKcvODy9DDjfHg@mail.gmail.com>
Message-ID: <b5a41b1d-66a7-8503-4fae-12e64305dbf7@redhat.com>

I am not sure I understand your question. ClientDescriptionConverter is 
the internal class in Keycloak (I assume you're talking about the 
interface org.keycloak.exportimport.ClientDescriptionConverter) and it 
is probably invoked under the covers when the REST endpoint for creating 
new client is invoked.

I think that everything, which is "invokable" by admin console can be 
invoked from kcadm as well. Both admin console and kcadm are using admin 
REST endpoints under the covers. So you can see what REST endpoint is 
invoked by admin console to be able to properly invoke it from kcadm.

Marek

On 18/02/2019 15:49, Brian Ward wrote:
> Is there any way to access this code through the kcadmin.sh CLI yet?  I
> want to import a SAML client the way the GUI does it.  I see the GUI uses
> ClientDescriptionConverter to parse the EntityDescriptor xml into a json
> object that the API uses.
>
> If this is not yet present, I'm happy to build it from the existing
> pieces.  I don't see it, but thought I'd get confirmation first that we
> don't have anything like this in the kcadmin or elsewhere.
>
> Thanks,
> Brian
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



From mposolda at redhat.com  Wed Feb 20 08:35:39 2019
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 20 Feb 2019 14:35:39 +0100
Subject: [keycloak-dev] Removing JaxrsBearerTokenFilter
Message-ID: <78951f7b-57b4-c64b-a1f4-9b7fdcae56af@redhat.com>

I wonder if we can remove JaxrsBearerTokenFilter?

Jut to add some context, the JaxrsBearerTokenFilter is the "adapter", 
which we have in the codebase and which allows to "secure" the JaxRS 
Application by adding the JaxrsFilter, which implements our OIDC 
adapter. Bill added this thing in the early days of Keycloak. I enhanced 
it a bit few years ago as someone wanted to secure the JaxRS application 
on Fuse. But this was before we had the proper Fuse adapter.

This thing was never documented and we never had any 
examples/quickstarts for it. We have just few automated tests (in the 
old testsuite). IMO it is very obsolete now as you can probably always 
secure your application through some other oficially supported way (HTTP 
Servlet filter or any of our other built-in adapters).

Does anyone have any reason why we shouldn't remove this?

If not, I wonder if we can remove it directly without "deprecation 
period"? Considering that this was never documented or announced, it 
probably can't be treated as a Keycloak feature, but rather an 
"implementation detail" or "prototype" and hence removing it directly 
may be fine? In this case, we won't need to migrate the tests from the 
old testsuite (which is my main motivation for writing this email :)

Marek


From slaskawi at redhat.com  Wed Feb 20 08:47:59 2019
From: slaskawi at redhat.com (Sebastian Laskawiec)
Date: Wed, 20 Feb 2019 14:47:59 +0100
Subject: [keycloak-dev] Trailing slash
Message-ID: <CAA9R9O4P7J-j4R=2bCVvAuBmYse-U0r81dQ9QDpT6fw-71hF0A@mail.gmail.com>

Hey guys,

I'm working on migrating Jetty adapters to our base testsuite at the moment
and I noticed an interesting problem.

The URLProvider is responsible for adjusting injected URLs into the Page
objects. One of the things it does is trimming the trailing slash out, so
that "http://localhost:8280/client-secret-jwt-secure-portal/" becomes "
http://localhost:8280/client-secret-jwt-secure-portal". We depend on this
functionality a lot in our testsuite when constructing all kind of
assertions that include myPage.getInjectedUrl().toString(). In other words,
if we inject a URL with a trailing slash, there will be quite a lot of test
that fail.

Trailing space at the end is not meaningless unfortunately. It is being
used by the container to find proper context. Here's one of the best
explanations I found so far [1].

Jetty enforces trailing slashes for Servlets deployed in the container. If
you hit a Servlet without a slash (
http://localhost:8280/client-secret-jwt-secure-portal for example), you
will be redirected (with HTTP 302) to a version that has it (
http://localhost:8280/client-secret-jwt-secure-portal/). This of course
breaks some of the tests in our testsuite (since the Resteasy HTTP Engine
doesn't follow redirects by default). It is also worth to mention, that
Arquillian also adds trailing slash at the end of the Servlet context [2].
So by default, it injects all URLs with trailing space.

My take on this is that we should not trim the trailing slash. Moreover, we
should never manipulate a raw string representation of a URL. What we
should do instead is to use URI#resolve method if we need to query
sub-contexts. Using URI instead of URL is extremely important when it comes
to equality (if you're interested more in this, please read [3]).

If you agree with me, I'll go ahead and create a JIRA for it.

Thanks,
Sebastian

[1]
https://stackoverflow.com/questions/37370407/how-to-remove-trailing-slash-from-embedded-jetty-urls/37485104#37485104
[2]
See org.jboss.arquillian.container.spi.client.protocol.metadata.Servlet#getBaseURIAsString
method
[3] http://blog.markfeeney.com/2010/11/java-uri-vs-url.html

From sthorger at redhat.com  Wed Feb 20 09:30:34 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 20 Feb 2019 15:30:34 +0100
Subject: [keycloak-dev] Allow AdminEvents for custom resource types
In-Reply-To: <d3ca8e635b09445d9f8a5a231863a602@BOSKGEXC01.boskg.local>
References: <b15b7ae09d5343318384c9b2bfa052a5@BOSKGEXC01.boskg.local>
	<CAJgngAf_76NRtyzhb6-ecBPwviMK0bijooB=PEgGqOWjOhV8Qg@mail.gmail.com>
	<d3ca8e635b09445d9f8a5a231863a602@BOSKGEXC01.boskg.local>
Message-ID: <CAJgngAfc9PcC37Y4n7onxhzr-FMCjhCrCG=4Zrs=jbjy5RbT5A@mail.gmail.com>

On Wed, 20 Feb 2019 at 12:40, L?sch, Sebastian <
Sebastian.Loesch at governikus.de> wrote:

> >We can't accept the PR as is due to it breaking backwards compatibility
> of the API.
>
> Ah, I overlooked the EventListenerProvider interface. That?s the point
> where AdminEvent becomes public API, right?
>

It's not really public, but loads of people still use it. So yes, that's
the main place.


>
>
> Our use-case is as follows: we need to support user substitutions. User
> Jane goes for vacation and nominates John as her substitute in a defined
> time period. John has all of Janes Roles and is able to perform her tasks.
>
> We implement this substitution as a keycloak extension. All substitutions
> must be tracked. We want to implement this using the AdminEvents.
>
>
>
> Do you have any other suggestions how we can accomplish tracking?
>

Contribute it directly to Keycloak? Depends obviously on how much changes
is needed, how it's designed, if can be properly documented and tested, etc.

Alternatively, you could find an alternative approach that is backwards
compatible. Perhaps ResourceType enum can be extended or somehow allowed to
add custom types to it?


>
>
> Best regards,
>
> Sebastian
>
>
>
> *Von:* Stian Thorgersen <sthorger at redhat.com>
> *Gesendet:* Mittwoch, 20. Februar 2019 11:42
> *An:* L?sch, Sebastian <Sebastian.Loesch at governikus.de>
> *Cc:* keycloak-dev <keycloak-dev at lists.jboss.org>
> *Betreff:* Re: [keycloak-dev] Allow AdminEvents for custom resource types
>
>
>
> We can't accept the PR as is due to it breaking backwards compatibility of
> the API.
>
>
>
> Can you elaborate on your use-case? I'm far from convinced we should
> support this level of customisation.
>
>
>
> On Wed, 20 Feb 2019, 05:32 L?sch, Sebastian, <
> Sebastian.Loesch at governikus.de> wrote:
>
> Hello devs,
>
> we implemented a custom resource type as an extension to keycloak.
> For traceability reasons we would like to track actions for this custom
> resource type via AdminEvents.
> Unfortunately the resource type is represented by the enum ResourceType.
> Therefore no AdminEvents for custom non standard resource types can be
> created.
> It would be nice if it is possible to specify the resource type as string
> value also.
>
> This is only a small change, because the resource type is only provided
> via enum but handled as string value internally.
> I provided a pull request for that enhancement:
> https://github.com/keycloak/keycloak/pull/5882
>
> May anybody have a look on that review?
>
> Best regards,
> Sebastian
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>

From sthorger at redhat.com  Wed Feb 20 09:32:01 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 20 Feb 2019 15:32:01 +0100
Subject: [keycloak-dev] Removing JaxrsBearerTokenFilter
In-Reply-To: <78951f7b-57b4-c64b-a1f4-9b7fdcae56af@redhat.com>
References: <78951f7b-57b4-c64b-a1f4-9b7fdcae56af@redhat.com>
Message-ID: <CAJgngAeYU8eEkznfGkNRHuyntwNkagxJY8VQ4FkjQZeWNtLVDA@mail.gmail.com>

+1 To just removing it as long if there's no mention of it in the
docs/examples/quickstarts

On Wed, 20 Feb 2019 at 14:44, Marek Posolda <mposolda at redhat.com> wrote:

> I wonder if we can remove JaxrsBearerTokenFilter?
>
> Jut to add some context, the JaxrsBearerTokenFilter is the "adapter",
> which we have in the codebase and which allows to "secure" the JaxRS
> Application by adding the JaxrsFilter, which implements our OIDC
> adapter. Bill added this thing in the early days of Keycloak. I enhanced
> it a bit few years ago as someone wanted to secure the JaxRS application
> on Fuse. But this was before we had the proper Fuse adapter.
>
> This thing was never documented and we never had any
> examples/quickstarts for it. We have just few automated tests (in the
> old testsuite). IMO it is very obsolete now as you can probably always
> secure your application through some other oficially supported way (HTTP
> Servlet filter or any of our other built-in adapters).
>
> Does anyone have any reason why we shouldn't remove this?
>
> If not, I wonder if we can remove it directly without "deprecation
> period"? Considering that this was never documented or announced, it
> probably can't be treated as a Keycloak feature, but rather an
> "implementation detail" or "prototype" and hence removing it directly
> may be fine? In this case, we won't need to migrate the tests from the
> old testsuite (which is my main motivation for writing this email :)
>
> Marek
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sthorger at redhat.com  Wed Feb 20 09:34:01 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 20 Feb 2019 15:34:01 +0100
Subject: [keycloak-dev] Trailing slash
In-Reply-To: <CAA9R9O4P7J-j4R=2bCVvAuBmYse-U0r81dQ9QDpT6fw-71hF0A@mail.gmail.com>
References: <CAA9R9O4P7J-j4R=2bCVvAuBmYse-U0r81dQ9QDpT6fw-71hF0A@mail.gmail.com>
Message-ID: <CAJgngAf-ugZeA7rDbgPucwfwRXapyif0SKzPqZqcD35yBiW96w@mail.gmail.com>

That is some strange behaviour and I agree "/path/" is not the same as
"/path" so this is an invalid rewrite of the URL.

On Wed, 20 Feb 2019 at 14:50, Sebastian Laskawiec <slaskawi at redhat.com>
wrote:

> Hey guys,
>
> I'm working on migrating Jetty adapters to our base testsuite at the moment
> and I noticed an interesting problem.
>
> The URLProvider is responsible for adjusting injected URLs into the Page
> objects. One of the things it does is trimming the trailing slash out, so
> that "http://localhost:8280/client-secret-jwt-secure-portal/" becomes "
> http://localhost:8280/client-secret-jwt-secure-portal". We depend on this
> functionality a lot in our testsuite when constructing all kind of
> assertions that include myPage.getInjectedUrl().toString(). In other words,
> if we inject a URL with a trailing slash, there will be quite a lot of test
> that fail.
>
> Trailing space at the end is not meaningless unfortunately. It is being
> used by the container to find proper context. Here's one of the best
> explanations I found so far [1].
>
> Jetty enforces trailing slashes for Servlets deployed in the container. If
> you hit a Servlet without a slash (
> http://localhost:8280/client-secret-jwt-secure-portal for example), you
> will be redirected (with HTTP 302) to a version that has it (
> http://localhost:8280/client-secret-jwt-secure-portal/). This of course
> breaks some of the tests in our testsuite (since the Resteasy HTTP Engine
> doesn't follow redirects by default). It is also worth to mention, that
> Arquillian also adds trailing slash at the end of the Servlet context [2].
> So by default, it injects all URLs with trailing space.
>
> My take on this is that we should not trim the trailing slash. Moreover, we
> should never manipulate a raw string representation of a URL. What we
> should do instead is to use URI#resolve method if we need to query
> sub-contexts. Using URI instead of URL is extremely important when it comes
> to equality (if you're interested more in this, please read [3]).
>
> If you agree with me, I'll go ahead and create a JIRA for it.
>
> Thanks,
> Sebastian
>
> [1]
>
> https://stackoverflow.com/questions/37370407/how-to-remove-trailing-slash-from-embedded-jetty-urls/37485104#37485104
> [2]
> See
> org.jboss.arquillian.container.spi.client.protocol.metadata.Servlet#getBaseURIAsString
> method
> [3] http://blog.markfeeney.com/2010/11/java-uri-vs-url.html
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sthorger at redhat.com  Wed Feb 20 09:34:27 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 20 Feb 2019 15:34:27 +0100
Subject: [keycloak-dev] Trailing slash
In-Reply-To: <CAJgngAf-ugZeA7rDbgPucwfwRXapyif0SKzPqZqcD35yBiW96w@mail.gmail.com>
References: <CAA9R9O4P7J-j4R=2bCVvAuBmYse-U0r81dQ9QDpT6fw-71hF0A@mail.gmail.com>
	<CAJgngAf-ugZeA7rDbgPucwfwRXapyif0SKzPqZqcD35yBiW96w@mail.gmail.com>
Message-ID: <CAJgngAeWK_FvZgaBGujgHc_Y-v_i2Gzpnwd7Zordfiza_fV=5g@mail.gmail.com>

That being said I have no clue why it was added and if it would break
something to fix it ;)

On Wed, 20 Feb 2019 at 15:34, Stian Thorgersen <sthorger at redhat.com> wrote:

> That is some strange behaviour and I agree "/path/" is not the same as
> "/path" so this is an invalid rewrite of the URL.
>
> On Wed, 20 Feb 2019 at 14:50, Sebastian Laskawiec <slaskawi at redhat.com>
> wrote:
>
>> Hey guys,
>>
>> I'm working on migrating Jetty adapters to our base testsuite at the
>> moment
>> and I noticed an interesting problem.
>>
>> The URLProvider is responsible for adjusting injected URLs into the Page
>> objects. One of the things it does is trimming the trailing slash out, so
>> that "http://localhost:8280/client-secret-jwt-secure-portal/" becomes "
>> http://localhost:8280/client-secret-jwt-secure-portal". We depend on this
>> functionality a lot in our testsuite when constructing all kind of
>> assertions that include myPage.getInjectedUrl().toString(). In other
>> words,
>> if we inject a URL with a trailing slash, there will be quite a lot of
>> test
>> that fail.
>>
>> Trailing space at the end is not meaningless unfortunately. It is being
>> used by the container to find proper context. Here's one of the best
>> explanations I found so far [1].
>>
>> Jetty enforces trailing slashes for Servlets deployed in the container. If
>> you hit a Servlet without a slash (
>> http://localhost:8280/client-secret-jwt-secure-portal for example), you
>> will be redirected (with HTTP 302) to a version that has it (
>> http://localhost:8280/client-secret-jwt-secure-portal/). This of course
>> breaks some of the tests in our testsuite (since the Resteasy HTTP Engine
>> doesn't follow redirects by default). It is also worth to mention, that
>> Arquillian also adds trailing slash at the end of the Servlet context [2].
>> So by default, it injects all URLs with trailing space.
>>
>> My take on this is that we should not trim the trailing slash. Moreover,
>> we
>> should never manipulate a raw string representation of a URL. What we
>> should do instead is to use URI#resolve method if we need to query
>> sub-contexts. Using URI instead of URL is extremely important when it
>> comes
>> to equality (if you're interested more in this, please read [3]).
>>
>> If you agree with me, I'll go ahead and create a JIRA for it.
>>
>> Thanks,
>> Sebastian
>>
>> [1]
>>
>> https://stackoverflow.com/questions/37370407/how-to-remove-trailing-slash-from-embedded-jetty-urls/37485104#37485104
>> [2]
>> See
>> org.jboss.arquillian.container.spi.client.protocol.metadata.Servlet#getBaseURIAsString
>> method
>> [3] http://blog.markfeeney.com/2010/11/java-uri-vs-url.html
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>

From mposolda at redhat.com  Wed Feb 20 13:45:18 2019
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 20 Feb 2019 19:45:18 +0100
Subject: [keycloak-dev] Removing JaxrsBearerTokenFilter
In-Reply-To: <CAJgngAeYU8eEkznfGkNRHuyntwNkagxJY8VQ4FkjQZeWNtLVDA@mail.gmail.com>
References: <78951f7b-57b4-c64b-a1f4-9b7fdcae56af@redhat.com>
	<CAJgngAeYU8eEkznfGkNRHuyntwNkagxJY8VQ4FkjQZeWNtLVDA@mail.gmail.com>
Message-ID: <87cc6282-0e8e-01df-4e6f-1e5d64f59234@redhat.com>

Thanks for the confirm! Will wait few more days if someone has any 
reason against removing it. If not, will likely send PR early next week 
for removing it.

Marek

On 20/02/2019 15:32, Stian Thorgersen wrote:
> +1 To just removing it as long if there's no mention of it in the 
> docs/examples/quickstarts
>
> On Wed, 20 Feb 2019 at 14:44, Marek Posolda <mposolda at redhat.com 
> <mailto:mposolda at redhat.com>> wrote:
>
>     I wonder if we can remove JaxrsBearerTokenFilter?
>
>     Jut to add some context, the JaxrsBearerTokenFilter is the "adapter",
>     which we have in the codebase and which allows to "secure" the JaxRS
>     Application by adding the JaxrsFilter, which implements our OIDC
>     adapter. Bill added this thing in the early days of Keycloak. I
>     enhanced
>     it a bit few years ago as someone wanted to secure the JaxRS
>     application
>     on Fuse. But this was before we had the proper Fuse adapter.
>
>     This thing was never documented and we never had any
>     examples/quickstarts for it. We have just few automated tests (in the
>     old testsuite). IMO it is very obsolete now as you can probably
>     always
>     secure your application through some other oficially supported way
>     (HTTP
>     Servlet filter or any of our other built-in adapters).
>
>     Does anyone have any reason why we shouldn't remove this?
>
>     If not, I wonder if we can remove it directly without "deprecation
>     period"? Considering that this was never documented or announced, it
>     probably can't be treated as a Keycloak feature, but rather an
>     "implementation detail" or "prototype" and hence removing it directly
>     may be fine? In this case, we won't need to migrate the tests from
>     the
>     old testsuite (which is my main motivation for writing this email :)
>
>     Marek
>
>     _______________________________________________
>     keycloak-dev mailing list
>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>


From sthorger at redhat.com  Wed Feb 20 15:25:32 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 20 Feb 2019 21:25:32 +0100
Subject: [keycloak-dev] Removing JaxrsBearerTokenFilter
In-Reply-To: <87cc6282-0e8e-01df-4e6f-1e5d64f59234@redhat.com>
References: <78951f7b-57b4-c64b-a1f4-9b7fdcae56af@redhat.com>
	<CAJgngAeYU8eEkznfGkNRHuyntwNkagxJY8VQ4FkjQZeWNtLVDA@mail.gmail.com>
	<87cc6282-0e8e-01df-4e6f-1e5d64f59234@redhat.com>
Message-ID: <CAJgngAcYTH7HWGzUaC=Ru+-hhDQHBXEMgudN2sZSjm4JYDa4aA@mail.gmail.com>

DId you send this to user mailing list as well? If not you should.

On Wed, 20 Feb 2019 at 19:45, Marek Posolda <mposolda at redhat.com> wrote:

> Thanks for the confirm! Will wait few more days if someone has any reason
> against removing it. If not, will likely send PR early next week for
> removing it.
>
> Marek
>
> On 20/02/2019 15:32, Stian Thorgersen wrote:
>
> +1 To just removing it as long if there's no mention of it in the
> docs/examples/quickstarts
>
> On Wed, 20 Feb 2019 at 14:44, Marek Posolda <mposolda at redhat.com> wrote:
>
>> I wonder if we can remove JaxrsBearerTokenFilter?
>>
>> Jut to add some context, the JaxrsBearerTokenFilter is the "adapter",
>> which we have in the codebase and which allows to "secure" the JaxRS
>> Application by adding the JaxrsFilter, which implements our OIDC
>> adapter. Bill added this thing in the early days of Keycloak. I enhanced
>> it a bit few years ago as someone wanted to secure the JaxRS application
>> on Fuse. But this was before we had the proper Fuse adapter.
>>
>> This thing was never documented and we never had any
>> examples/quickstarts for it. We have just few automated tests (in the
>> old testsuite). IMO it is very obsolete now as you can probably always
>> secure your application through some other oficially supported way (HTTP
>> Servlet filter or any of our other built-in adapters).
>>
>> Does anyone have any reason why we shouldn't remove this?
>>
>> If not, I wonder if we can remove it directly without "deprecation
>> period"? Considering that this was never documented or announced, it
>> probably can't be treated as a Keycloak feature, but rather an
>> "implementation detail" or "prototype" and hence removing it directly
>> may be fine? In this case, we won't need to migrate the tests from the
>> old testsuite (which is my main motivation for writing this email :)
>>
>> Marek
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>

From mposolda at redhat.com  Thu Feb 21 04:27:35 2019
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 21 Feb 2019 10:27:35 +0100
Subject: [keycloak-dev] Removing JaxrsBearerTokenFilter
In-Reply-To: <CAJgngAcYTH7HWGzUaC=Ru+-hhDQHBXEMgudN2sZSjm4JYDa4aA@mail.gmail.com>
References: <78951f7b-57b4-c64b-a1f4-9b7fdcae56af@redhat.com>
	<CAJgngAeYU8eEkznfGkNRHuyntwNkagxJY8VQ4FkjQZeWNtLVDA@mail.gmail.com>
	<87cc6282-0e8e-01df-4e6f-1e5d64f59234@redhat.com>
	<CAJgngAcYTH7HWGzUaC=Ru+-hhDQHBXEMgudN2sZSjm4JYDa4aA@mail.gmail.com>
Message-ID: <cabd26d6-3af9-128b-08b2-99a1ecfbc38d@redhat.com>


I've just sent it to keycloak-user.

But question is, if keycloak-user mailing list is good place for such 
things? I think most people use keycloak-user mailing list to search for 
solutions to their particular problem or send their particular issue 
with Keycloak. But not sure how much people read this mailing list 
regularly? IMO we should instruct community to monitor to keycloak-dev 
mailing list for general announcements from Keycloak team (EG. release 
announcements, questionnaires, ask for removing/deprecating some 
component) as in keycloak-user informations can be easily lost.

Marek

On 20/02/2019 21:25, Stian Thorgersen wrote:
> DId you send this to user mailing list as well? If not you should.
>
> On Wed, 20 Feb 2019 at 19:45, Marek Posolda <mposolda at redhat.com 
> <mailto:mposolda at redhat.com>> wrote:
>
>     Thanks for the confirm! Will wait few more days if someone has any
>     reason against removing it. If not, will likely send PR early next
>     week for removing it.
>
>     Marek
>
>     On 20/02/2019 15:32, Stian Thorgersen wrote:
>>     +1 To just removing it as long if there's no mention of it in the
>>     docs/examples/quickstarts
>>
>>     On Wed, 20 Feb 2019 at 14:44, Marek Posolda <mposolda at redhat.com
>>     <mailto:mposolda at redhat.com>> wrote:
>>
>>         I wonder if we can remove JaxrsBearerTokenFilter?
>>
>>         Jut to add some context, the JaxrsBearerTokenFilter is the
>>         "adapter",
>>         which we have in the codebase and which allows to "secure"
>>         the JaxRS
>>         Application by adding the JaxrsFilter, which implements our OIDC
>>         adapter. Bill added this thing in the early days of Keycloak.
>>         I enhanced
>>         it a bit few years ago as someone wanted to secure the JaxRS
>>         application
>>         on Fuse. But this was before we had the proper Fuse adapter.
>>
>>         This thing was never documented and we never had any
>>         examples/quickstarts for it. We have just few automated tests
>>         (in the
>>         old testsuite). IMO it is very obsolete now as you can
>>         probably always
>>         secure your application through some other oficially
>>         supported way (HTTP
>>         Servlet filter or any of our other built-in adapters).
>>
>>         Does anyone have any reason why we shouldn't remove this?
>>
>>         If not, I wonder if we can remove it directly without
>>         "deprecation
>>         period"? Considering that this was never documented or
>>         announced, it
>>         probably can't be treated as a Keycloak feature, but rather an
>>         "implementation detail" or "prototype" and hence removing it
>>         directly
>>         may be fine? In this case, we won't need to migrate the tests
>>         from the
>>         old testsuite (which is my main motivation for writing this
>>         email :)
>>
>>         Marek
>>
>>         _______________________________________________
>>         keycloak-dev mailing list
>>         keycloak-dev at lists.jboss.org
>>         <mailto:keycloak-dev at lists.jboss.org>
>>         https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>


From sthorger at redhat.com  Thu Feb 21 04:59:17 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 21 Feb 2019 10:59:17 +0100
Subject: [keycloak-dev] Feature freeze lifted
Message-ID: <CAJgngAdOmw7hB7t21nV9ksP5AeJj57vaFAOBKhWN1E3Js55_ew@mail.gmail.com>

Feature freeze is now lifted and we can start merging PRs for Keycloak 5.0.0

From slaskawi at redhat.com  Thu Feb 21 05:59:27 2019
From: slaskawi at redhat.com (Sebastian Laskawiec)
Date: Thu, 21 Feb 2019 11:59:27 +0100
Subject: [keycloak-dev] Trailing slash
In-Reply-To: <CAJgngAeWK_FvZgaBGujgHc_Y-v_i2Gzpnwd7Zordfiza_fV=5g@mail.gmail.com>
References: <CAA9R9O4P7J-j4R=2bCVvAuBmYse-U0r81dQ9QDpT6fw-71hF0A@mail.gmail.com>
	<CAJgngAf-ugZeA7rDbgPucwfwRXapyif0SKzPqZqcD35yBiW96w@mail.gmail.com>
	<CAJgngAeWK_FvZgaBGujgHc_Y-v_i2Gzpnwd7Zordfiza_fV=5g@mail.gmail.com>
Message-ID: <CAA9R9O7MRwT7xKnQTnAs_zBknDHwb7Xf+YJK0n4uROeOOzYv6w@mail.gmail.com>

I'm glad you agree with me.

@Hynek Mlnarik <hmlnarik at redhat.com> - The bad news is that I will need to
implement that for the Jetty adapter. I tried to avoid it but it turns out
that SAML tests force me to do this (since most of them use injected url to
construct SAML calls). There is also a good side of it though, all the code
I'm refactoring now will use UriBuilders. So we should never have this kind
of problems again.

On Wed, Feb 20, 2019 at 3:34 PM Stian Thorgersen <sthorger at redhat.com>
wrote:

> That being said I have no clue why it was added and if it would break
> something to fix it ;)
>
> On Wed, 20 Feb 2019 at 15:34, Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> That is some strange behaviour and I agree "/path/" is not the same as
>> "/path" so this is an invalid rewrite of the URL.
>>
>> On Wed, 20 Feb 2019 at 14:50, Sebastian Laskawiec <slaskawi at redhat.com>
>> wrote:
>>
>>> Hey guys,
>>>
>>> I'm working on migrating Jetty adapters to our base testsuite at the
>>> moment
>>> and I noticed an interesting problem.
>>>
>>> The URLProvider is responsible for adjusting injected URLs into the Page
>>> objects. One of the things it does is trimming the trailing slash out, so
>>> that "http://localhost:8280/client-secret-jwt-secure-portal/" becomes "
>>> http://localhost:8280/client-secret-jwt-secure-portal". We depend on
>>> this
>>> functionality a lot in our testsuite when constructing all kind of
>>> assertions that include myPage.getInjectedUrl().toString(). In other
>>> words,
>>> if we inject a URL with a trailing slash, there will be quite a lot of
>>> test
>>> that fail.
>>>
>>> Trailing space at the end is not meaningless unfortunately. It is being
>>> used by the container to find proper context. Here's one of the best
>>> explanations I found so far [1].
>>>
>>> Jetty enforces trailing slashes for Servlets deployed in the container.
>>> If
>>> you hit a Servlet without a slash (
>>> http://localhost:8280/client-secret-jwt-secure-portal for example), you
>>> will be redirected (with HTTP 302) to a version that has it (
>>> http://localhost:8280/client-secret-jwt-secure-portal/). This of course
>>> breaks some of the tests in our testsuite (since the Resteasy HTTP Engine
>>> doesn't follow redirects by default). It is also worth to mention, that
>>> Arquillian also adds trailing slash at the end of the Servlet context
>>> [2].
>>> So by default, it injects all URLs with trailing space.
>>>
>>> My take on this is that we should not trim the trailing slash. Moreover,
>>> we
>>> should never manipulate a raw string representation of a URL. What we
>>> should do instead is to use URI#resolve method if we need to query
>>> sub-contexts. Using URI instead of URL is extremely important when it
>>> comes
>>> to equality (if you're interested more in this, please read [3]).
>>>
>>> If you agree with me, I'll go ahead and create a JIRA for it.
>>>
>>> Thanks,
>>> Sebastian
>>>
>>> [1]
>>>
>>> https://stackoverflow.com/questions/37370407/how-to-remove-trailing-slash-from-embedded-jetty-urls/37485104#37485104
>>> [2]
>>> See
>>> org.jboss.arquillian.container.spi.client.protocol.metadata.Servlet#getBaseURIAsString
>>> method
>>> [3] http://blog.markfeeney.com/2010/11/java-uri-vs-url.html
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>

From sthorger at redhat.com  Thu Feb 21 06:45:16 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 21 Feb 2019 12:45:16 +0100
Subject: [keycloak-dev] Removing JaxrsBearerTokenFilter
In-Reply-To: <cabd26d6-3af9-128b-08b2-99a1ecfbc38d@redhat.com>
References: <78951f7b-57b4-c64b-a1f4-9b7fdcae56af@redhat.com>
	<CAJgngAeYU8eEkznfGkNRHuyntwNkagxJY8VQ4FkjQZeWNtLVDA@mail.gmail.com>
	<87cc6282-0e8e-01df-4e6f-1e5d64f59234@redhat.com>
	<CAJgngAcYTH7HWGzUaC=Ru+-hhDQHBXEMgudN2sZSjm4JYDa4aA@mail.gmail.com>
	<cabd26d6-3af9-128b-08b2-99a1ecfbc38d@redhat.com>
Message-ID: <CAJgngAcd_AcHL=9jbpFpZA4ftBGXYRMKh-8kPy-3yNwfxLS3Vg@mail.gmail.com>

-1

Keycloak User mailing list is for users of Keycloak

Keycloak Developer mailing list is for core team and contributors, let's
not encourage more non-contributors to join that list

On Thu, 21 Feb 2019 at 10:27, Marek Posolda <mposolda at redhat.com> wrote:

>
> I've just sent it to keycloak-user.
>
> But question is, if keycloak-user mailing list is good place for such
> things? I think most people use keycloak-user mailing list to search for
> solutions to their particular problem or send their particular issue with
> Keycloak. But not sure how much people read this mailing list regularly?
> IMO we should instruct community to monitor to keycloak-dev mailing list
> for general announcements from Keycloak team (EG. release announcements,
> questionnaires, ask for removing/deprecating some component) as in
> keycloak-user informations can be easily lost.
>
> Marek
>
> On 20/02/2019 21:25, Stian Thorgersen wrote:
>
> DId you send this to user mailing list as well? If not you should.
>
> On Wed, 20 Feb 2019 at 19:45, Marek Posolda <mposolda at redhat.com> wrote:
>
>> Thanks for the confirm! Will wait few more days if someone has any reason
>> against removing it. If not, will likely send PR early next week for
>> removing it.
>>
>> Marek
>>
>> On 20/02/2019 15:32, Stian Thorgersen wrote:
>>
>> +1 To just removing it as long if there's no mention of it in the
>> docs/examples/quickstarts
>>
>> On Wed, 20 Feb 2019 at 14:44, Marek Posolda <mposolda at redhat.com> wrote:
>>
>>> I wonder if we can remove JaxrsBearerTokenFilter?
>>>
>>> Jut to add some context, the JaxrsBearerTokenFilter is the "adapter",
>>> which we have in the codebase and which allows to "secure" the JaxRS
>>> Application by adding the JaxrsFilter, which implements our OIDC
>>> adapter. Bill added this thing in the early days of Keycloak. I enhanced
>>> it a bit few years ago as someone wanted to secure the JaxRS application
>>> on Fuse. But this was before we had the proper Fuse adapter.
>>>
>>> This thing was never documented and we never had any
>>> examples/quickstarts for it. We have just few automated tests (in the
>>> old testsuite). IMO it is very obsolete now as you can probably always
>>> secure your application through some other oficially supported way (HTTP
>>> Servlet filter or any of our other built-in adapters).
>>>
>>> Does anyone have any reason why we shouldn't remove this?
>>>
>>> If not, I wonder if we can remove it directly without "deprecation
>>> period"? Considering that this was never documented or announced, it
>>> probably can't be treated as a Keycloak feature, but rather an
>>> "implementation detail" or "prototype" and hence removing it directly
>>> may be fine? In this case, we won't need to migrate the tests from the
>>> old testsuite (which is my main motivation for writing this email :)
>>>
>>> Marek
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>>
>

From mposolda at redhat.com  Thu Feb 21 07:16:40 2019
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 21 Feb 2019 13:16:40 +0100
Subject: [keycloak-dev] Removing JaxrsBearerTokenFilter
In-Reply-To: <CAJgngAcd_AcHL=9jbpFpZA4ftBGXYRMKh-8kPy-3yNwfxLS3Vg@mail.gmail.com>
References: <78951f7b-57b4-c64b-a1f4-9b7fdcae56af@redhat.com>
	<CAJgngAeYU8eEkznfGkNRHuyntwNkagxJY8VQ4FkjQZeWNtLVDA@mail.gmail.com>
	<87cc6282-0e8e-01df-4e6f-1e5d64f59234@redhat.com>
	<CAJgngAcYTH7HWGzUaC=Ru+-hhDQHBXEMgudN2sZSjm4JYDa4aA@mail.gmail.com>
	<cabd26d6-3af9-128b-08b2-99a1ecfbc38d@redhat.com>
	<CAJgngAcd_AcHL=9jbpFpZA4ftBGXYRMKh-8kPy-3yNwfxLS3Vg@mail.gmail.com>
Message-ID: <a0029d91-539a-87bb-f23d-2abde28fcbe0@redhat.com>

I see. However my point still remains - I think that just quite small 
percentage of Keycloak users is regularly following keycloak-users 
mailing list. However I don't have any better idea where to announce 
those type of messages. Blog or "news channel" is probably not so great 
place for it. And any new ML like "keycloak-announcements" is likely 
also not so great thing as 3 mailing lists seem to be quite lot... I've 
just sent to keycloak-users as you mentioned.

Marek


On 21/02/2019 12:45, Stian Thorgersen wrote:
> -1
>
> Keycloak User mailing list is for users of Keycloak
>
> Keycloak Developer mailing list is for core team and contributors, 
> let's not encourage more non-contributors to join that list
>
> On Thu, 21 Feb 2019 at 10:27, Marek Posolda <mposolda at redhat.com 
> <mailto:mposolda at redhat.com>> wrote:
>
>
>     I've just sent it to keycloak-user.
>
>     But question is, if keycloak-user mailing list is good place for
>     such things? I think most people use keycloak-user mailing list to
>     search for solutions to their particular problem or send their
>     particular issue with Keycloak. But not sure how much people read
>     this mailing list regularly? IMO we should instruct community to
>     monitor to keycloak-dev mailing list for general announcements
>     from Keycloak team (EG. release announcements, questionnaires, ask
>     for removing/deprecating some component) as in keycloak-user
>     informations can be easily lost.
>
>     Marek
>
>     On 20/02/2019 21:25, Stian Thorgersen wrote:
>>     DId you send this to user mailing list as well? If not you should.
>>
>>     On Wed, 20 Feb 2019 at 19:45, Marek Posolda <mposolda at redhat.com
>>     <mailto:mposolda at redhat.com>> wrote:
>>
>>         Thanks for the confirm! Will wait few more days if someone
>>         has any reason against removing it. If not, will likely send
>>         PR early next week for removing it.
>>
>>         Marek
>>
>>         On 20/02/2019 15:32, Stian Thorgersen wrote:
>>>         +1 To just removing it as long if there's no mention of it
>>>         in the docs/examples/quickstarts
>>>
>>>         On Wed, 20 Feb 2019 at 14:44, Marek Posolda
>>>         <mposolda at redhat.com <mailto:mposolda at redhat.com>> wrote:
>>>
>>>             I wonder if we can remove JaxrsBearerTokenFilter?
>>>
>>>             Jut to add some context, the JaxrsBearerTokenFilter is
>>>             the "adapter",
>>>             which we have in the codebase and which allows to
>>>             "secure" the JaxRS
>>>             Application by adding the JaxrsFilter, which implements
>>>             our OIDC
>>>             adapter. Bill added this thing in the early days of
>>>             Keycloak. I enhanced
>>>             it a bit few years ago as someone wanted to secure the
>>>             JaxRS application
>>>             on Fuse. But this was before we had the proper Fuse adapter.
>>>
>>>             This thing was never documented and we never had any
>>>             examples/quickstarts for it. We have just few automated
>>>             tests (in the
>>>             old testsuite). IMO it is very obsolete now as you can
>>>             probably always
>>>             secure your application through some other oficially
>>>             supported way (HTTP
>>>             Servlet filter or any of our other built-in adapters).
>>>
>>>             Does anyone have any reason why we shouldn't remove this?
>>>
>>>             If not, I wonder if we can remove it directly without
>>>             "deprecation
>>>             period"? Considering that this was never documented or
>>>             announced, it
>>>             probably can't be treated as a Keycloak feature, but
>>>             rather an
>>>             "implementation detail" or "prototype" and hence
>>>             removing it directly
>>>             may be fine? In this case, we won't need to migrate the
>>>             tests from the
>>>             old testsuite (which is my main motivation for writing
>>>             this email :)
>>>
>>>             Marek
>>>
>>>             _______________________________________________
>>>             keycloak-dev mailing list
>>>             keycloak-dev at lists.jboss.org
>>>             <mailto:keycloak-dev at lists.jboss.org>
>>>             https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>


From sthorger at redhat.com  Thu Feb 21 07:47:11 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 21 Feb 2019 13:47:11 +0100
Subject: [keycloak-dev] Removing JaxrsBearerTokenFilter
In-Reply-To: <a0029d91-539a-87bb-f23d-2abde28fcbe0@redhat.com>
References: <78951f7b-57b4-c64b-a1f4-9b7fdcae56af@redhat.com>
	<CAJgngAeYU8eEkznfGkNRHuyntwNkagxJY8VQ4FkjQZeWNtLVDA@mail.gmail.com>
	<87cc6282-0e8e-01df-4e6f-1e5d64f59234@redhat.com>
	<CAJgngAcYTH7HWGzUaC=Ru+-hhDQHBXEMgudN2sZSjm4JYDa4aA@mail.gmail.com>
	<cabd26d6-3af9-128b-08b2-99a1ecfbc38d@redhat.com>
	<CAJgngAcd_AcHL=9jbpFpZA4ftBGXYRMKh-8kPy-3yNwfxLS3Vg@mail.gmail.com>
	<a0029d91-539a-87bb-f23d-2abde28fcbe0@redhat.com>
Message-ID: <CAJgngAfR7D9ysiP-6xsR4aG-rzT8CF-gqoGJwGkWuOJTTtuR6A@mail.gmail.com>

If this was important we could announce on blog and Twitter to reach a
slightly bigger audience. End of the day though I don't think it is so if
you ask on user mailing list and no-one replies within a week then I think
we can assume it's not much used.

On Thu, 21 Feb 2019 at 13:16, Marek Posolda <mposolda at redhat.com> wrote:

> I see. However my point still remains - I think that just quite small
> percentage of Keycloak users is regularly following keycloak-users mailing
> list. However I don't have any better idea where to announce those type of
> messages. Blog or "news channel" is probably not so great place for it. And
> any new ML like "keycloak-announcements" is likely also not so great thing
> as 3 mailing lists seem to be quite lot... I've just sent to keycloak-users
> as you mentioned.
>
> Marek
>
>
> On 21/02/2019 12:45, Stian Thorgersen wrote:
>
> -1
>
> Keycloak User mailing list is for users of Keycloak
>
> Keycloak Developer mailing list is for core team and contributors, let's
> not encourage more non-contributors to join that list
>
> On Thu, 21 Feb 2019 at 10:27, Marek Posolda <mposolda at redhat.com> wrote:
>
>>
>> I've just sent it to keycloak-user.
>>
>> But question is, if keycloak-user mailing list is good place for such
>> things? I think most people use keycloak-user mailing list to search for
>> solutions to their particular problem or send their particular issue with
>> Keycloak. But not sure how much people read this mailing list regularly?
>> IMO we should instruct community to monitor to keycloak-dev mailing list
>> for general announcements from Keycloak team (EG. release announcements,
>> questionnaires, ask for removing/deprecating some component) as in
>> keycloak-user informations can be easily lost.
>>
>> Marek
>>
>> On 20/02/2019 21:25, Stian Thorgersen wrote:
>>
>> DId you send this to user mailing list as well? If not you should.
>>
>> On Wed, 20 Feb 2019 at 19:45, Marek Posolda <mposolda at redhat.com> wrote:
>>
>>> Thanks for the confirm! Will wait few more days if someone has any
>>> reason against removing it. If not, will likely send PR early next week for
>>> removing it.
>>>
>>> Marek
>>>
>>> On 20/02/2019 15:32, Stian Thorgersen wrote:
>>>
>>> +1 To just removing it as long if there's no mention of it in the
>>> docs/examples/quickstarts
>>>
>>> On Wed, 20 Feb 2019 at 14:44, Marek Posolda <mposolda at redhat.com> wrote:
>>>
>>>> I wonder if we can remove JaxrsBearerTokenFilter?
>>>>
>>>> Jut to add some context, the JaxrsBearerTokenFilter is the "adapter",
>>>> which we have in the codebase and which allows to "secure" the JaxRS
>>>> Application by adding the JaxrsFilter, which implements our OIDC
>>>> adapter. Bill added this thing in the early days of Keycloak. I
>>>> enhanced
>>>> it a bit few years ago as someone wanted to secure the JaxRS
>>>> application
>>>> on Fuse. But this was before we had the proper Fuse adapter.
>>>>
>>>> This thing was never documented and we never had any
>>>> examples/quickstarts for it. We have just few automated tests (in the
>>>> old testsuite). IMO it is very obsolete now as you can probably always
>>>> secure your application through some other oficially supported way
>>>> (HTTP
>>>> Servlet filter or any of our other built-in adapters).
>>>>
>>>> Does anyone have any reason why we shouldn't remove this?
>>>>
>>>> If not, I wonder if we can remove it directly without "deprecation
>>>> period"? Considering that this was never documented or announced, it
>>>> probably can't be treated as a Keycloak feature, but rather an
>>>> "implementation detail" or "prototype" and hence removing it directly
>>>> may be fine? In this case, we won't need to migrate the tests from the
>>>> old testsuite (which is my main motivation for writing this email :)
>>>>
>>>> Marek
>>>>
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>>
>>>
>>
>

From sthorger at redhat.com  Thu Feb 21 08:05:54 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 21 Feb 2019 14:05:54 +0100
Subject: [keycloak-dev] Log username if user is not found?
Message-ID: <CAJgngAccm63mxDLLwF=Zt4BF9hSQBvxkTWzcs3mG_mdzHud=-A@mail.gmail.com>

If an invalid username or email is used during login the logs will include
the username.

This could potentially be an issue if a user mistakenly enters his
credentials into the username field. We had this
https://issues.jboss.org/browse/KEYCLOAK-9400 issue opened.

Personally I'm not convinced this is a real issue and I'm leaning towards
keeping it as is as having the username available can be useful when
debugging login issues.

Question is should we log the username or not?

From mposolda at redhat.com  Thu Feb 21 08:30:42 2019
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 21 Feb 2019 14:30:42 +0100
Subject: [keycloak-dev] Log username if user is not found?
In-Reply-To: <CAJgngAccm63mxDLLwF=Zt4BF9hSQBvxkTWzcs3mG_mdzHud=-A@mail.gmail.com>
References: <CAJgngAccm63mxDLLwF=Zt4BF9hSQBvxkTWzcs3mG_mdzHud=-A@mail.gmail.com>
Message-ID: <0b1762a3-dd16-a3bf-8398-17e88c3d8ff4@redhat.com>

Maybe we can log username just if it is username of existing user? But 
not sure, I would also rather keep as is as it looks more as theoretic 
issue. Considering that all browsers support "dots" in the password 
field, so user will probably very early recognize that he is trying to 
enter password into username field.

Marek

On 21/02/2019 14:05, Stian Thorgersen wrote:
> If an invalid username or email is used during login the logs will include
> the username.
>
> This could potentially be an issue if a user mistakenly enters his
> credentials into the username field. We had this
> https://issues.jboss.org/browse/KEYCLOAK-9400 issue opened.
>
> Personally I'm not convinced this is a real issue and I'm leaning towards
> keeping it as is as having the username available can be useful when
> debugging login issues.
>
> Question is should we log the username or not?
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



From bward at redhat.com  Thu Feb 21 08:43:07 2019
From: bward at redhat.com (Brian Ward)
Date: Thu, 21 Feb 2019 08:43:07 -0500
Subject: [keycloak-dev] ClientDescriptionConverter
In-Reply-To: <b5a41b1d-66a7-8503-4fae-12e64305dbf7@redhat.com>
References: <CAHBgxzvDsNLGVgkrq878K0bARR+BDW2SDvbnnKcvODy9DDjfHg@mail.gmail.com>
	<b5a41b1d-66a7-8503-4fae-12e64305dbf7@redhat.com>
Message-ID: <CAHBgxzv40tW0N9Sr6S18VMVesYi0cawawbsgJJTSsUa5_1fuSg@mail.gmail.com>

Thanks Marek. The objective is just to enable the kcadm.sh to take SAML
input (EntityDescriptor xml) to create a client.  Right now it appears the
kcadm.sh tool only takes JSON input before hitting the REST endpoint for
creating a client.  I'll do some research and see if I can hook into the
ClientDescriptionConverter from the kcadm.sh tool.

Brian



On Wed, Feb 20, 2019 at 8:12 AM Marek Posolda <mposolda at redhat.com> wrote:

> I am not sure I understand your question. ClientDescriptionConverter is
> the internal class in Keycloak (I assume you're talking about the
> interface org.keycloak.exportimport.ClientDescriptionConverter) and it
> is probably invoked under the covers when the REST endpoint for creating
> new client is invoked.
>
> I think that everything, which is "invokable" by admin console can be
> invoked from kcadm as well. Both admin console and kcadm are using admin
> REST endpoints under the covers. So you can see what REST endpoint is
> invoked by admin console to be able to properly invoke it from kcadm.
>
> Marek
>
> On 18/02/2019 15:49, Brian Ward wrote:
> > Is there any way to access this code through the kcadmin.sh CLI yet?  I
> > want to import a SAML client the way the GUI does it.  I see the GUI uses
> > ClientDescriptionConverter to parse the EntityDescriptor xml into a json
> > object that the API uses.
> >
> > If this is not yet present, I'm happy to build it from the existing
> > pieces.  I don't see it, but thought I'd get confirmation first that we
> > don't have anything like this in the kcadmin or elsewhere.
> >
> > Thanks,
> > Brian
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>

From dhardiker at adaptavist.com  Thu Feb 21 08:51:02 2019
From: dhardiker at adaptavist.com (Dan Hardiker)
Date: Thu, 21 Feb 2019 13:51:02 +0000
Subject: [keycloak-dev] Log username if user is not found?
In-Reply-To: <CAJgngAccm63mxDLLwF=Zt4BF9hSQBvxkTWzcs3mG_mdzHud=-A@mail.gmail.com>
References: <CAJgngAccm63mxDLLwF=Zt4BF9hSQBvxkTWzcs3mG_mdzHud=-A@mail.gmail.com>
Message-ID: <0CC2C3DC-EDE3-4295-A3FD-541D84763FFD@adaptavist.com>

(Unsure of whether this was generally aimed to all, or a subset of more seasoned contributors - however my thoughts are below)

In the case of the user entering their password in the correct field, it would be masked in the UI.
In the case of the user entering their password in the username field, it would be displayed in plain text in the UI.
I would suggest that this is feedback enough to enable the user to self correct.

Taking the issue at face value - with a user?s credential making it into the logs, what would one do with such information?
How would an attacker take the credential and utilise it - given they don?t know what user it was meant for?
Perhaps an attacker could iterate over the users and try the password on each.
Perhaps an attacker might see a subsequent successful login showing the actual user name (I?m not sure if that?s logged) - which would narrow the potential users to try in a lightly used system.

Finally, what privileges would someone who can access the logs have? Arguably they?d have escalated administrative privileges and thus be in a position of trust already.

Personally, I wouldn?t consider this a notable vector within my threat model. However, I?m only an interested party in the field of security, rather than an accredited security professional.


?
Dan Hardiker | Adaptavist
dhardiker at adaptavist.com
 
Winners of the Atlassian President's Award for Technical Excellence - http://bit.ly/techexc <http://bit.ly/techexc>

Adaptavist <http://adaptavist.com/>, Waterside, Unit 2, 44-48 Wharf Road, London, N1 7UX, United Kingdom.
Registered in England and Wales #5456785.

> On 21 Feb 2019, at 13:05, Stian Thorgersen <sthorger at redhat.com> wrote:
> 
> If an invalid username or email is used during login the logs will include
> the username.
> 
> This could potentially be an issue if a user mistakenly enters his
> credentials into the username field. We had this
> https://issues.jboss.org/browse/KEYCLOAK-9400 issue opened.
> 
> Personally I'm not convinced this is a real issue and I'm leaning towards
> keeping it as is as having the username available can be useful when
> debugging login issues.
> 
> Question is should we log the username or not?
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From sthorger at redhat.com  Thu Feb 21 15:10:01 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 21 Feb 2019 21:10:01 +0100
Subject: [keycloak-dev] Locale selection logic
Message-ID: <CAJgngAedjQvntSSzbKRCh6wBNMrMq2UQEBcyS+zfZ8=7jF6dYw@mail.gmail.com>

There has been a few issues reported around the logic of setting the
locale.

I've tried to add the issues to a single issue
https://issues.jboss.org/browse/KEYCLOAK-9632 where we can come up with a
new and improved logic. If you have observed other issues please comment on
the issue.

Something like this may work:

1. From authentication session if set
1. From user if set
2. From ui_locales if set
3. KEYCLOAK_LOCALE cookie if set
4. Browser header if set
5. Realm default
6. Fallback to en

When the locale is changed through the login pages the locale should be set
in authentication session as a note to update user locale. Note: ui_locales
should not update the users locale.

When user is authenticated update the users locale from authentication
session if set. If authenticated user has locale set, update
KEYCLOAK_LOCALE cookie.

From vramik at redhat.com  Fri Feb 22 06:48:42 2019
From: vramik at redhat.com (Vlasta Ramik)
Date: Fri, 22 Feb 2019 12:48:42 +0100
Subject: [keycloak-dev] What Jetty versions we want to support?
In-Reply-To: <CAJgngAfoKJh0q8X3fXztAdTQP9W+NUhYAzKm-T0wfxe9B6GhDw@mail.gmail.com>
References: <CAA9R9O5hqjn577MjtMfFT1hGQJxhYivFwPdOfd6dOuG76k+v7A@mail.gmail.com>
	<CAJgngAfA2YLWQ5R4EzidkUdQe0oq=pA__0k5tUQoXLrFGP_5-w@mail.gmail.com>
	<CAA9R9O4oqKfq8jOkwV2hQNiH2x=Ci7VQ9VYGMOpCU4kWQ6LdRQ@mail.gmail.com>
	<CAMvXD=EyCVC7C6sNwQLW+SmacKjpvibpr0fUndjEEN2H1FBGUA@mail.gmail.com>
	<CAA9R9O7Ku-A6y-sGT=+pnKqoLQGqBPXVFa+nu5wiGPBCR5kZQQ@mail.gmail.com>
	<CAA9R9O5babsso5WPswNYS9B2R71TVdRqRk_Lnfj72jFjY48UjA@mail.gmail.com>
	<CAJgngAfoKJh0q8X3fXztAdTQP9W+NUhYAzKm-T0wfxe9B6GhDw@mail.gmail.com>
Message-ID: <c891b5e0-58b5-3dfb-23fc-43eef2340b97@redhat.com>

But afaik Jetty 8.1 is used just for fuse6.2 which is no longer 
supported (we support just adapter for fuse6.3 where Jetty 9.2 is 
required).

On 2/18/19 10:19 AM, Stian Thorgersen wrote:
> EOL in community sure, but Fuse have longer support cadence than Jetty
> community releases. Jetty 8.1 needs to be supported until whatever Fuse
> version that uses it is EOL.
>
> On Mon, 18 Feb 2019 at 10:15, Sebastian Laskawiec <slaskawi at redhat.com>
> wrote:
>
>> One more thing to add - we may want to talk with Fuse guys about Jetty 8.1
>> since it's end of life [1].
>>
>> Can anyone contact of off-list and point out a contact on Fuse side to
>> talk about this?
>>
>> [1] https://wiki.eclipse.org/Jetty/Howto/Configure_JSP
>> etty 7 and Jetty 8 are now EOL (End of Life)
>> All development and stable releases are being performed with Jetty 9.
>> This wiki is now officially out of date and all content has been moved to
>> the Jetty Documentation Hub
>> Direct Link to updated documentation:
>> http://www.eclipse.org/jetty/documentation/current/configuring-jsp.html
>>
>> On Wed, Feb 13, 2019 at 2:55 PM Sebastian Laskawiec <slaskawi at redhat.com>
>> wrote:
>>
>>> So it seems we have our support matrix:
>>> - 8.1 (because of Fuse)
>>> - 9.2 (heavily used by the community and required by Fuse)
>>> - 9.3 (heavily used by the community)
>>> - 9.4 (it's the latest version)
>>>
>>> So we might consider dropping 9.3 at some point in favor of 9.4. But
>>> that's something to think of and probably not for now.
>>>
>>> On Tue, Feb 12, 2019 at 5:25 PM Hynek Mlnarik <hmlnarik at redhat.com>
>>> wrote:
>>>
>>>> For Fuse, we use 8.1 [1] and 9.2 [2].
>>>>
>>>> --Hynek
>>>>
>>>> [1]
>>>> https://github.com/keycloak/keycloak/blob/4.8.3.Final/distribution/adapters/osgi/features/src/main/resources/features.xml#L54
>>>> [2]
>>>> https://github.com/keycloak/keycloak/blob/4.8.3.Final/distribution/adapters/osgi/features/src/main/resources/features.xml#L63
>>>>
>>>> On Tue, Feb 12, 2019 at 12:05 PM Sebastian Laskawiec <
>>>> slaskawi at redhat.com> wrote:
>>>>
>>>>> Ok, understood! Thanks a lot for the info Stian!
>>>>>
>>>>> On Tue, Feb 12, 2019 at 11:48 AM Stian Thorgersen <sthorger at redhat.com>
>>>>> wrote:
>>>>>
>>>>>> We test them until we remove ;)
>>>>>>
>>>>>> 8.1 and 9.1 have already been removed from the community. We need to
>>>>>> confirm if these are needed by Fuse (we don't support Jetty directly
>>>>> for
>>>>>> RH-SSO, but rather only through Fuse). If Fuse relies on these we
>>>>> need to
>>>>>> continue testing them.
>>>>>>
>>>>>> 9.2 and 9.3 still has users in the community (25 dls of each the last
>>>>> 3
>>>>>> months, but that is only direct dls through website, not sure if
>>>>> folks also
>>>>>> use them from Maven central). We should keep these for now though and
>>>>>> consider deprecating at some point in the future.
>>>>>>
>>>>>> On Tue, 12 Feb 2019 at 10:24, Sebastian Laskawiec <
>>>>> slaskawi at redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hey guys,
>>>>>>>
>>>>>>> I'm working on moving Jetty adapter tests from the old testsuite
>>>>> into the
>>>>>>> new one. I can see we support this Jetty versions [1]:
>>>>>>> - 8.1
>>>>>>> - 9.1
>>>>>>> - 9.2
>>>>>>> - 9.3
>>>>>>> - 9.4
>>>>>>>
>>>>>>> Do we want to keep it this way or maybe concentrate on testing
>>>>> adapters
>>>>>>> against 8.1 and 9.4 only (the last major versions)?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Sebastian
>>>>>>>
>>>>>>> [1] grep -lir "keycloak-saml-jetty" --include="*.xml"
>>>>>>>
>>>>>> _______________________________________________
>>>>>>> keycloak-dev mailing list
>>>>>>> keycloak-dev at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>
>>>>> _______________________________________________
>>>>> keycloak-dev mailing list
>>>>> keycloak-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From dhardiker at adaptavist.com  Fri Feb 22 07:54:44 2019
From: dhardiker at adaptavist.com (Dan Hardiker)
Date: Fri, 22 Feb 2019 12:54:44 +0000
Subject: [keycloak-dev] Improving support for LDAP backed Keycloak
In-Reply-To: <08405d13-3621-5ac2-3021-606295bc71c6@redhat.com>
References: <9695FE33-85A2-48BC-B440-D50452D070DF@adaptavist.com>
	<08405d13-3621-5ac2-3021-606295bc71c6@redhat.com>
Message-ID: <8F7BE3E5-1836-4793-A85F-066ADB5BF062@adaptavist.com>

Hi All,

Thanks for the pointers. I was able to get Keycloak imported properly into IDEA (a bit of user error, needed a lot more patience). I?ve worked out how to get Keycloak running with a remote debugger, which has been a great help, but I?ve not managed to get Keycloak running from within IDEA itself. Is it standard to run it through mvn during development?

I?ve got a basic implementation working against a custom attribute I?ve set. It?s not tested, I?m first looking for validation on the approach taken. Can someone please have a look at https://github.com/dhardiker/keycloak/commit/e26ff98c2d4c55b98b743522d195226b94b4c8aa - all comments welcome, so I can make sure I?m on the right path. Tests will come before a PR is submitted.

Other questions:

1. Should I address the other KEYCLOAK-5571 issues too in the same branch of work?
2. I?ve found that boolean fields sometimes map inversely to common LDAP attributes one might choose to back Keycloak with (e.g. UserModel.enabled <> LDAPUser.loginDisabled). Would it be ok to add another setting to the UserAttributeLDAPStorageMapper which would be ?Invert boolean values? - so an UserModel.enabled == true maps to setting LDAPUser.loginDisabled = false? If so, any tips on where the areas to extend that in, beyond the Mapper itself (I?m thinking at least a theme or two?).

Thanks for the continued support, I?m starting to feel a little more comfortable with the Keycloak codebase.


?
Dan Hardiker | Adaptavist
dhardiker at adaptavist.com
 
Winners of the Atlassian President's Award for Technical Excellence - http://bit.ly/techexc <http://bit.ly/techexc>

Adaptavist <http://adaptavist.com/>, Waterside, Unit 2, 44-48 Wharf Road, London, N1 7UX, United Kingdom.
Registered in England and Wales #5456785.

> On 20 Feb 2019, at 13:03, Marek Posolda <mposolda at redhat.com> wrote:
> 
> On 18/02/2019 18:39, Dan Hardiker wrote:
>> Hi All,
>> 
>> Sorry for such a long first post. Here we go!
>> 
>> 
>> TL;DR:
>> I want to look at https://issues.jboss.org/browse/KEYCLOAK-5571 <https://issues.jboss.org/browse/KEYCLOAK-5571> as it is impacting us. I?m happy to contribute code or write a blog on what configuration settings are needed to achieve this. While the SAGA has more context, here?s a few of my currently burning questions:
> Cool!
>> 
>> 1. What implements the org.keycloak.admin.client.resource.UserResource.update(UserRepresentation) and UserRepresentation ...toRepresentation() interface method? (from the integration/admin-client directory - I can?t find the business logic)
> The implementation is "auto-generated" proxy class, which just invokes the particular admin REST endpoint - for example org.keycloak.admin.client.resource.UserResource.update is invoked the server-side REST endpoint org.keycloak.services.resources.admin.UserResource.updateUser
>> 
>> 2. What would be the right approach to wire up the admin ui User Enabled toggle to a LDAP boolean field, and where in the codebase would that go? (if you can cite examples of similar that would be great)
> 
> UserAttributeLDAPStorageMapper is the class where you can look at. As you can see in the "proxy" method, the proxied model implements setFirstName, setLastNAme, setEmail .
> It seems that few more things need to be added (EG. setEnabled, setEmailVerified)
> 
> The automated test may need to be added somewhere in LDAPProvidersIntegrationTest IMO.
>> 3. What is the best way to go about setting up an IDE for development? Just importing the root POM into IDEA doesn?t seem to cut it.
> Importing the root POM into IDEA works fine for me.
>> 4. If I provide a patch for this, is this something that might be considered for pulling into master?
> Yes. There needs to be few simple rules met when you want something to be considered into master. We're working on improving guidelines for contributors. See details in this PR: https://github.com/keycloak/keycloak/pull/5886/files <https://github.com/keycloak/keycloak/pull/5886/files> . You just already started the discussion on keycloak-dev mailing list, which is nice 1st step. Good luck with moving forward on your contribution!
> 
> Marek
> 
>> 
>> I am interested in all of the features within KEYCLOAK-5571, as a few other requirements, but I?m happy to start here and treat the others as atomic suggested changes. They may include:
>> 
>> * Supporting incremented default values for new users (the uidNumber must be unique and it should be 1 greater than the highest uidNumber that the system can see ? i.e. the next available UID).
>> * Supporting out-of-band password recovery (where by a code is sent via a trusted path [text message, telephone call, in person conversation with the user] which can be used to reset their password - ideally in combination with another stored value, such as their employee id / tax id / post code / something else which is relatively static but relatively unknown) - this could be developed outside of Keycloak of course, but would ideally be within the same system.
>> 
>> If addressing KEYCLOAK-5571 goes well, I would be interested in continuing to contribute down these paths.
>> 
>> Thanks for your time, I would love to get involved ? I just need a bit of help.
>> 
>> 
>> THE SAGA:
>> Apologies if this message should be in keycloak-users, and if any of it seems incoherent. I?ve been fighting in circles all weekend and I have to admit that I?m not entirely sure I?m approaching the problem correctly. Please bear with me as I?m not entirely sure how to articulate things at this point, but I know I need help!
>> 
>> Problem statement: we are currently using OpenLDAP to manage access to our systems. However, the administration interface is crude and it lacks SAML/OIDC support for integrating systems like Google Suite, AWS Console, Office 365 and others. It also lacks a self service console where users can mange their own accounts. Keycloak at first glance looks ideal - especially as it allows us to continue using OpenLDAP as the primary source of truth, with Keycloak used to enhance the user experience giving self service and integration with SAML/OIDC clients.
>> 
>> As per the docs, some mapping is required to have OpenLDAP support the storage of Keycloak data within the OpenLDAP schemas. Unfortunately, I?ve not bee able to find documentation for what those fields names in Keycloak can be and how I should alter my OpenLDAP schema to support them. I found KEYCLOAK-5571 which appears to cover at least some of the issues I?m having. Amongst other things, I?m a Java developer, so I?m comfortable with working in code and submitting patches. Assuming that the answer isn?t configuration, is this something that would be valuable to contribute? If so, is there any advice that this list can offer on where to start?
>> 
>> What follows is my journey as an outsider into trying to figure out things myself. This may or may not be of interest - but given this list gets indexed by Google, it might help someone in future. Seeing that issue (KEYCLOAK-5571) I figured the best place to start would be the admin ui where you enable/disable users. I thought that I would start at the browser and try to figure out what the enabled/disable user toggle did when saved, trace that into the server side endpoint that picked up that representation and hopefully find out where & why it didn?t make it through to LDAP.
>> 
>> I noticed that there was a PUT to http://localhost/auth/admin/realms/master/users/f:$UUID:$USERNAME <http://localhost/auth/admin/realms/master/users/f:$UUID:$USERNAME> and as part of the JSON payload was ?enabled: false?. At this point I started grepping around in the Keycloak code. I figured that org.keycloak.admin.client.resource.UserResource.update(UserRepresentation) Interface was what was being called, but unfortunately when I opened up the root POM then IDEA only saw the files as plain text and none of the Intelisense worked, I could grep around the code though. When I opened up the integration/admin-client/pom.xml it recognise the Java files, however I wasn?t able to find what was implementing this. If found "public static UserRepresentation toRepresentation(KeycloakSession session, RealmModel realm, UserModel user)? in server-spi-private org.keycloak.models.util.ModelToRepresentation, but couldn?t find the glue which connects them together. I?m guessing there might be some WildFly or other magic going on which I?m not aware of?
>> 
>> Seeing the ?enabled: false? lead me to think that I might be able to create a user-attribute-ldap-mapper from the user model attribute ?enabled? to an ?enabled? LDAP attribute I added to our schema to test. The LDAP attribute has SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 (a binary attribute) and I?ve checked I can set that to TRUE / FALSE appropriately. I set it to be mandatory in LDAP and set it to be a Binary Attribute - however when I save it says "Error! With Binary attribute enabled, the 'Always read value from LDAP' must be enabled too? - however there is no ?Always read value from LDAP? option! However, after enabling Import Users in the LDAP user federation settings, ?Always read value from LDAP? becomes available. It?s not clear if Binary Attributes are supported only in this configuration, but ideally I would like to not Import Users as I prefer LDAP to be the authoritative source. After this I can disabled Import Users and the configuration still seemingly remains valid without any errors in the logs. That said, it?s not erroring about not properly persisting the enabled state to LDAP...
>> 
>> If I go across to the user in the admin ui, even though enabled is set to FALSE in LDAP, the toggle is showing as enabled in the UI. The JSON it gets for the UserRepresentation on the client side is ?enabled?:true which explains the state of the toggle. If I stick Wireshark locally, setup a Docker with OpenLDAP and configure it appropriately, sniffing traffic I can see that the enabled attribute for my user comes back as FALSE. So there is something going wrong when trying to build that UserRepresentation. I suspect at the root of the KEYCLOAK-5571 issue. If I change the toggle to false in the UI and save, then reload the page, the toggle is back to true - when it persists to the LDAP server, it?s sending enabled: FALSE - this doesn?t make sense, but it might be just repeating back to LDAP what it read in without changing that field. If I change the name as well, it does send those fields updated, but enabled remains FALSE in the LDAP server.
>> 
>> Given that I didnt get very far with the UserRepresentation angle, I thought about going down the FederatedStorage - something must map the model into LDAP, as changes to the first name / last name, and the other attributes seem to be persisted and loaded in LDAP just fine. In my grepping around in server-spi I found a org.keycloak.models.UserModel Interface, which had a org.keycloak.storage.adapter.AbstractUserAdapterFederatedStorage implementation with a ENABLED_ATTRIBUTE = ?ENABLED? field and isEnabled / setEnabled methods which getFirstAttribute(ENABLED_ATTRIBUTE) / setSingleAttribute(ENABLED_ATTRIBUTE, Boolean.toString(enabled). The class comment has:
>> 
>> * Assumes everything is managed by federated storage except for username.  getId() returns a default value
>> * of "f:" + providerId + ":" + getUsername().  UserModel properties like enabled, firstName, lastName, email, etc. are all
>> * stored as attributes in federated storage.
>> 
>> I?m not sure how the case difference between ?enabled? in the UserModel properties and ?ENABLED? as listed in the class field is connected - but there must be a mapping somewhere, as ?firstName? is similarly ?FIRST_NAME? and that maps just fine. I found model/jpa contained org.keycloak.models.jpa.entities/UserEntity which had @Column(name = "ENABLED?) protected boolean enabled, perhaps this is the link and even with Import Users disabled it always goes through the database?
>> 
>> I?ve yet to find the trigger which calls the mapper to run which persists into the database. Part of the problem is that I?m acutely aware my IDE is not setup to effectively jump around the code base, or to effectively attach my IDE as a debugger so I can add breakpoints and step through the code to figure out what happens where. I?ve just turned on trace logging - but this is giving me a wall of text which may take sometime to process. I?ve also yet to comb through the H2 DB to see if there?s cause there.
>> 
>> Any assistance on this would be most welcome.
>> 
>> 
>> ON ANOTHER NOTE:
>> I checked out the code and ran the build as documented against Java 8 on my mac, but unfortunately it failed. I ignored it and progressed, but here?s some excerpts from the output:
>> [INFO] Keycloak Integration TestSuite - deprecated ........ FAILURE [07:04 min]
>> 
>> [ERROR] Errors:
>> [ERROR]   OIDCKeyCloakServerBrokerBasicTest.testLogoutWorksWithTokenTimeout:131 ? Processing
>> [ERROR]   OIDCKeycloakServerBrokerWithConsentTest.before:84 ? Processing java.lang.NoSuc...
>> [ERROR]   BrokenUserStorageTest.testBootWithBadProviderId:118 ? Processing java.lang.NoS...
>> [ERROR]   JaxrsBasicAuthTest.testBasic:120 ? NoSuchMethod org.apache.commons.io.output.D...
>> [ERROR]   JaxrsFilterTest.testBasic:129 ? NoSuchMethod org.apache.commons.io.output.Defe...
>> [ERROR] Tests run: 238, Failures: 0, Errors: 5, Skipped: 32
>> 
>> I guess this shouldn?t happen on a fresh check out & a following of the instruction.
>> 
>> 
>> If you made it this far - bravo!
>> 
>> Thanks again,
>> 
>> 
>> ?
>> Dan Hardiker | Adaptavist
>> 
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev <https://lists.jboss.org/mailman/listinfo/keycloak-dev>


From swetha.t at endurance.com  Sat Feb 23 09:29:11 2019
From: swetha.t at endurance.com (Swetha Talluri)
Date: Sat, 23 Feb 2019 19:59:11 +0530
Subject: [keycloak-dev] deploy custom spi on docker
Message-ID: <CAHAbs+GdZZeRoOKBiSFHMa+e2TbqKxUCEX7aTLaCFy_3LeShGA@mail.gmail.com>

Hi ,
I have a custom SPI required for custom rest end points using jpa , How
should i deploy this customSPI in docker , Please help.


Thanks,
Swetha.T

From sthorger at redhat.com  Mon Feb 25 04:14:18 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 25 Feb 2019 10:14:18 +0100
Subject: [keycloak-dev] deploy custom spi on docker
In-Reply-To: <CAHAbs+GdZZeRoOKBiSFHMa+e2TbqKxUCEX7aTLaCFy_3LeShGA@mail.gmail.com>
References: <CAHAbs+GdZZeRoOKBiSFHMa+e2TbqKxUCEX7aTLaCFy_3LeShGA@mail.gmail.com>
Message-ID: <CAJgngAfPm+0ok-J+hRkiF6cngrtHnjnb4okqEbYb2uhw=jp+WA@mail.gmail.com>

This mailing list is for core team members and contributors. For questions
and help please use the user mailing list.

On Sat, 23 Feb 2019 at 16:35, Swetha Talluri <swetha.t at endurance.com> wrote:

> Hi ,
> I have a custom SPI required for custom rest end points using jpa , How
> should i deploy this customSPI in docker , Please help.
>
>
> Thanks,
> Swetha.T
> _______________________________________________
> 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 Feb 25 06:16:05 2019
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Mon, 25 Feb 2019 12:16:05 +0100
Subject: [keycloak-dev] dockerimage for jboss/keycloak-examples seems to be
	broken
Message-ID: <CAK-7U1gDsRywH+sDVc20dNxotAyP_-C2hj9RALb5YfVKpuEUag@mail.gmail.com>

Hello,

just noticed that the jboss/keycloak-examples image doesn't start anymore,
see below:

Cheers,
Thomas

$ docker run -e KEYCLOAK_USER=admin -e KEYCLOAK_PASSWORD=admin
jboss/keycloak-examples
Unable to find image 'jboss/keycloak-examples:latest' locally
latest: Pulling from jboss/keycloak-examples
aeb7866da422: Already exists
157601a0b538: Already exists
642f4164f381: Already exists
ee2abcb9139a: Already exists
10f7cea861e1: Pull complete
276721013b76: Pull complete
1c8d22278e14: Pull complete
f1339a2aa9d9: Pull complete
d6446eeff2ef: Pull complete
Digest:
sha256:e141cdcd0634813b3d1c4ce1b3c6683088c332ffce5bf74a2a01b194db46b449
Status: Downloaded newer image for jboss/keycloak-examples:latest
=========================================================================

  JBoss Bootstrap Environment

  JBOSS_HOME: /opt/jboss/keycloak-demo/keycloak

  JAVA: /usr/lib/jvm/java/bin/java

  JAVA_OPTS:  -server -Xms64m -Xmx512m -XX:MetaspaceSize=96M
-XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true
-Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true

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

11:13:33,660 INFO  [org.jboss.modules] (main) JBoss Modules version
1.8.5.Final
11:13:33,841 INFO  [org.jboss.msc] (main) JBoss MSC version 1.4.2.Final
11:13:33,849 INFO  [org.jboss.threads] (main) JBoss Threads version
2.3.2.Final
11:13:33,932 INFO  [org.jboss.as] (MSC service thread 1-2) WFLYSRV0049:
WildFly Full 13.0.0.Final (WildFly Core 5.0.0.Final) starting
11:13:34,457 ERROR [org.jboss.as.controller] (Controller Boot Thread)

OPVDX001: Validation error in standalone.xml
-----------------------------------
|
|  32:     <extension module="org.wildfly.extension.security.manager"/>
|  33:     <extension module="org.wildfly.extension.undertow"/>
|  34:     <extension module="org.keycloak.keycloak-server-subsystem"
xmlns=""/>
|          ^^^^ 'extension' can't appear more than once within the
extensions element
|
|  35:     <extension module="org.keycloak.keycloak-adapter-subsystem"
xmlns=""/>
|  36:     <extension module="org.keycloak.keycloak-saml-adapter-subsystem"
xmlns=""/>
|  37: </extensions>
|
| A 'extension' element first appears here:
|
|  33:     <extension module="org.wildfly.extension.undertow"/>
|  34:     <extension module="org.keycloak.keycloak-server-subsystem"
xmlns=""/>
|  35:     <extension module="org.keycloak.keycloak-adapter-subsystem"
xmlns=""/>
|          ^^^^
|
|  36:     <extension module="org.keycloak.keycloak-saml-adapter-subsystem"
xmlns=""/>
|  37: </extensions>
|  38: <management>
|
| The primary underlying error message was:
| > ParseError at [row,col]:[34,9]
| > Message: WFLYCTL0198: Unexpected element 'extension' encountered
|
|-------------------------------------------------------------------------------

11:13:34,458 ERROR [org.jboss.as.server] (Controller Boot Thread)
WFLYSRV0055: Caught exception during boot:
org.jboss.as.controller.persistence.ConfigurationPersistenceException:
WFLYCTL0085: Failed to parse configuration
at
org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:143)
at org.jboss.as.server.ServerService.boot(ServerService.java:377)
at
org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:372)
at java.lang.Thread.run(Thread.java:748)

11:13:34,459 FATAL [org.jboss.as.server] (Controller Boot Thread)
WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting.
See previous messages for details.
11:13:34,470 INFO  [org.jboss.as] (MSC service thread 1-1) WFLYSRV0050:
WildFly Full 13.0.0.Final (WildFly Core 5.0.0.Final) stopped in 6ms

From pa at pauloangelo.com  Tue Feb 26 20:12:19 2019
From: pa at pauloangelo.com (Paulo Angelo)
Date: Tue, 26 Feb 2019 22:12:19 -0300
Subject: [keycloak-dev] Announce of the GuardianKey extension
Message-ID: <CAFjP4XQr5PSt_A9D-oH=A4=e-snnrzUBu_E9iaEPcuVWNSUX=g@mail.gmail.com>

Hi all,


We are glad to announce the first release of the GuardianKey extension for
KeyCloak.

In the opportunity, we would like to acknowledge that the KeyCloak's
community is very active and contributed a lot by providing directions for
the problems faced by us in this foray. We give a special thank you for
Al?xis Almeida, Dmitry Telegin, Stian Thorgersen, and Thomas Darimont.

GuardianKey is a solution to protect systems against authentication
attacks. We use Machine Learning to analyze the user's behavior, threat
intelligence, and psychometrics (or behavioral biometrics) and provide an
attack risk in real-time. The protected system (in the concrete case,
KeyCloak, via the extension) sends the events via REST for the GuardianKey
on each login attempt and can notify users or even block the high-risk
events. Also, there is a panel that presents dashboards about login
attempts. We have cloud and product versions. We note that there is a free
service for small environments. More info at [1].

The extension is available at [2], in which we also included documentation
(docs and video [3]) for its installation, configuration, and use.

We appreciate any suggestion or comment.

[1] https://guardiankey.io

[2] https://github.com/pauloangelo/guardiankey-plugin-keycloak

[3] https://youtu.be/R5QFcH4bXuA

Once again, thank you!

Best regards,

Paulo Angelo

https://www.linkedin.com/in/reddhatt/

From sthorger at redhat.com  Wed Feb 27 03:58:40 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 27 Feb 2019 09:58:40 +0100
Subject: [keycloak-dev] dockerimage for jboss/keycloak-examples seems to
 be broken
In-Reply-To: <CAK-7U1gDsRywH+sDVc20dNxotAyP_-C2hj9RALb5YfVKpuEUag@mail.gmail.com>
References: <CAK-7U1gDsRywH+sDVc20dNxotAyP_-C2hj9RALb5YfVKpuEUag@mail.gmail.com>
Message-ID: <CAJgngAf59mFeGnPzr3AcAJZo=797FbKGxqsax4TYJC9uR=tO6Q@mail.gmail.com>

Keycloak examples are deprecated and no longer maintained. We are now
focusing on the QuickStarts [1].

We should remove the example image as it really isn't a good showcase of
Keycloak due to the fact that it leverages Keycloak deployed to standard
WildFly server including JEE apps on the same container. This is not a
deployment we support and its also way to Java focused. Keycloak is a
solution for apps written any language, not just Java, but the fact that so
much of our examples/docs focus on Java has given the community a false
impression here.

[1] https://github.com/keycloak/keycloak-quickstarts

On Mon, 25 Feb 2019 at 12:18, Thomas Darimont <
thomas.darimont at googlemail.com> wrote:

> Hello,
>
> just noticed that the jboss/keycloak-examples image doesn't start anymore,
> see below:
>
> Cheers,
> Thomas
>
> $ docker run -e KEYCLOAK_USER=admin -e KEYCLOAK_PASSWORD=admin
> jboss/keycloak-examples
> Unable to find image 'jboss/keycloak-examples:latest' locally
> latest: Pulling from jboss/keycloak-examples
> aeb7866da422: Already exists
> 157601a0b538: Already exists
> 642f4164f381: Already exists
> ee2abcb9139a: Already exists
> 10f7cea861e1: Pull complete
> 276721013b76: Pull complete
> 1c8d22278e14: Pull complete
> f1339a2aa9d9: Pull complete
> d6446eeff2ef: Pull complete
> Digest:
> sha256:e141cdcd0634813b3d1c4ce1b3c6683088c332ffce5bf74a2a01b194db46b449
> Status: Downloaded newer image for jboss/keycloak-examples:latest
> =========================================================================
>
>   JBoss Bootstrap Environment
>
>   JBOSS_HOME: /opt/jboss/keycloak-demo/keycloak
>
>   JAVA: /usr/lib/jvm/java/bin/java
>
>   JAVA_OPTS:  -server -Xms64m -Xmx512m -XX:MetaspaceSize=96M
> -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true
> -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
>
> =========================================================================
>
> 11:13:33,660 INFO  [org.jboss.modules] (main) JBoss Modules version
> 1.8.5.Final
> 11:13:33,841 INFO  [org.jboss.msc] (main) JBoss MSC version 1.4.2.Final
> 11:13:33,849 INFO  [org.jboss.threads] (main) JBoss Threads version
> 2.3.2.Final
> 11:13:33,932 INFO  [org.jboss.as] (MSC service thread 1-2) WFLYSRV0049:
> WildFly Full 13.0.0.Final (WildFly Core 5.0.0.Final) starting
> 11:13:34,457 ERROR [org.jboss.as.controller] (Controller Boot Thread)
>
> OPVDX001: Validation error in standalone.xml
> -----------------------------------
> |
> |  32:     <extension module="org.wildfly.extension.security.manager"/>
> |  33:     <extension module="org.wildfly.extension.undertow"/>
> |  34:     <extension module="org.keycloak.keycloak-server-subsystem"
> xmlns=""/>
> |          ^^^^ 'extension' can't appear more than once within the
> extensions element
> |
> |  35:     <extension module="org.keycloak.keycloak-adapter-subsystem"
> xmlns=""/>
> |  36:     <extension module="org.keycloak.keycloak-saml-adapter-subsystem"
> xmlns=""/>
> |  37: </extensions>
> |
> | A 'extension' element first appears here:
> |
> |  33:     <extension module="org.wildfly.extension.undertow"/>
> |  34:     <extension module="org.keycloak.keycloak-server-subsystem"
> xmlns=""/>
> |  35:     <extension module="org.keycloak.keycloak-adapter-subsystem"
> xmlns=""/>
> |          ^^^^
> |
> |  36:     <extension module="org.keycloak.keycloak-saml-adapter-subsystem"
> xmlns=""/>
> |  37: </extensions>
> |  38: <management>
> |
> | The primary underlying error message was:
> | > ParseError at [row,col]:[34,9]
> | > Message: WFLYCTL0198: Unexpected element 'extension' encountered
> |
>
> |-------------------------------------------------------------------------------
>
> 11:13:34,458 ERROR [org.jboss.as.server] (Controller Boot Thread)
> WFLYSRV0055: Caught exception during boot:
> org.jboss.as.controller.persistence.ConfigurationPersistenceException:
> WFLYCTL0085: Failed to parse configuration
> at
>
> org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:143)
> at org.jboss.as.server.ServerService.boot(ServerService.java:377)
> at
>
> org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:372)
> at java.lang.Thread.run(Thread.java:748)
>
> 11:13:34,459 FATAL [org.jboss.as.server] (Controller Boot Thread)
> WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting.
> See previous messages for details.
> 11:13:34,470 INFO  [org.jboss.as] (MSC service thread 1-1) WFLYSRV0050:
> WildFly Full 13.0.0.Final (WildFly Core 5.0.0.Final) stopped in 6ms
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sthorger at redhat.com  Wed Feb 27 10:09:23 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 27 Feb 2019 16:09:23 +0100
Subject: [keycloak-dev] Application Initiated Actions
Message-ID: <CAJgngAeHYxNFRdAdYUJHGerDa06109O6uZWP7Aq5xQNPrW-QuA@mail.gmail.com>

Keycloak currently has required actions that are used to prompt the user to
perform an action associated with their account after authenticating, but
prior to being redirected to the application.

Examples include: configure OTP, update profile, validate email, etc.

One issue here is these actions have to be manually registered with the
users account, but can not be initiated by applications themselves. As an
example it may not be required by all users to verify their email, but only
when they use specific applications.

Keycloak also needs to initiate actions from the account management
console. Examples: updating email address should require verifying the
email, configuring OTP, etc.

With that in mind we are proposing to introduce Application Initiated
Actions. An Application Initiated Action behind the scenes is just a
Required Action, but it is initiated by an application and depending on the
action may be optional for the user to complete (where the user can select
cancel which would return the user back to the application).

No Application Initiated Actions should perform any updates to the users
account without prompting the user first. For example an application
initiated action that is used to link an existing account to a social
provider should ask the user first if they want to link to the provider.

To make it easy for applications to integrate these I would like to
leverage the standard OAuth flows that applications use to authenticate
users. So to initiate verify-email action the application would redirect to
the authentication endpoint and add kc_action=<action alias> query
parameter.

One open question I have right now is. Assuming all Application Initiated
Actions always prompt the user first do we need to add some mechanism in
place to restrict what clients/applications are permitted to initiate an
action? Requiring that would make it harder to use for applications.

One thing I would also like to add is the ability for an Application
Initiated Action to require the user to re-authenticate prior to performing
the action. For example update password should require the user to enter
the current password, while verify email should not (as it simply sends an
email with a link to continue).

From sthorger at redhat.com  Wed Feb 27 10:26:18 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 27 Feb 2019 16:26:18 +0100
Subject: [keycloak-dev] Request for someone to contribute an WebAuthn4j
	extension
Message-ID: <CAJgngAdCOusGh0Mf1yHO4TA9j54C9gG48WMi3Uba0+GvFDMs7Q@mail.gmail.com>

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://github.com/webauthn4j/webauthn4j

From sthorger at redhat.com  Wed Feb 27 14:00:50 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 27 Feb 2019 20:00:50 +0100
Subject: [keycloak-dev] Designs in the open starting with WebAuthn Two
	Factor experience
Message-ID: <CAJgngAfR=UxrV=h605n0yxC+_7wtkrrHSDFB9o4Rdz7EMgQ7Hg@mail.gmail.com>

Going forward when we are working on new larger features we will be
creating design documents (epic briefs, call it whatever you want) and
sharing them openly with the community.

I have setup a new repository on GitHub where we will create designs as
simple MarkDown files. This will make it easy for everyone to comment as
well as contribute to the designs.

In contrary to everything else using JIRA for issues, we will use GitHub
issues for issues associated with the designs. We also welcome PRs to
contribute to the designs.

First design to be available is for W3C Web Authentication focusing on the
Two Factor experience. The design is available here
https://github.com/keycloak/keycloak-community/blob/master/design/web-authn-two-factor.md
.

From sthorger at redhat.com  Wed Feb 27 14:34:16 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 27 Feb 2019 20:34:16 +0100
Subject: [keycloak-dev] Application Initiated Actions
In-Reply-To: <CAJgngAeHYxNFRdAdYUJHGerDa06109O6uZWP7Aq5xQNPrW-QuA@mail.gmail.com>
References: <CAJgngAeHYxNFRdAdYUJHGerDa06109O6uZWP7Aq5xQNPrW-QuA@mail.gmail.com>
Message-ID: <CAJgngAeMrMrjcKmQkem5sQzXGBNG=isxYh6PiMMEo7euZdAdUg@mail.gmail.com>

Design document:
https://github.com/keycloak/keycloak-community/blob/master/design/application-initiated-actions.md

On Wed, 27 Feb 2019 at 16:09, Stian Thorgersen <sthorger at redhat.com> wrote:

> Keycloak currently has required actions that are used to prompt the user
> to perform an action associated with their account after authenticating,
> but prior to being redirected to the application.
>
> Examples include: configure OTP, update profile, validate email, etc.
>
> One issue here is these actions have to be manually registered with the
> users account, but can not be initiated by applications themselves. As an
> example it may not be required by all users to verify their email, but only
> when they use specific applications.
>
> Keycloak also needs to initiate actions from the account management
> console. Examples: updating email address should require verifying the
> email, configuring OTP, etc.
>
> With that in mind we are proposing to introduce Application Initiated
> Actions. An Application Initiated Action behind the scenes is just a
> Required Action, but it is initiated by an application and depending on the
> action may be optional for the user to complete (where the user can select
> cancel which would return the user back to the application).
>
> No Application Initiated Actions should perform any updates to the users
> account without prompting the user first. For example an application
> initiated action that is used to link an existing account to a social
> provider should ask the user first if they want to link to the provider.
>
> To make it easy for applications to integrate these I would like to
> leverage the standard OAuth flows that applications use to authenticate
> users. So to initiate verify-email action the application would redirect to
> the authentication endpoint and add kc_action=<action alias> query
> parameter.
>
> One open question I have right now is. Assuming all Application Initiated
> Actions always prompt the user first do we need to add some mechanism in
> place to restrict what clients/applications are permitted to initiate an
> action? Requiring that would make it harder to use for applications.
>
> One thing I would also like to add is the ability for an Application
> Initiated Action to require the user to re-authenticate prior to performing
> the action. For example update password should require the user to enter
> the current password, while verify email should not (as it simply sends an
> email with a link to continue).
>

From yuichi.nakamura.fe at hitachi.com  Wed Feb 27 18:31:53 2019
From: yuichi.nakamura.fe at hitachi.com (=?iso-2022-jp?B?GyRCQ2ZCPE06MGwbKEIgLyBOQUtBTVVSQRskQiEkGyhCWVVVSUNISQ==?=)
Date: Wed, 27 Feb 2019 23:31:53 +0000
Subject: [keycloak-dev] Request for someone to contribute an WebAuthn4j
 extension
In-Reply-To: <CAJgngAdCOusGh0Mf1yHO4TA9j54C9gG48WMi3Uba0+GvFDMs7Q@mail.gmail.com>
References: <CAJgngAdCOusGh0Mf1yHO4TA9j54C9gG48WMi3Uba0+GvFDMs7Q@mail.gmail.com>
Message-ID: <TY2PR01MB4540BFE30A76A20F0CF2C8ECC9740@TY2PR01MB4540.jpnprd01.prod.outlook.com>

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: keycloak-dev-bounces at lists.jboss.org <keycloak-dev-bounces at lists.jboss.org> On Behalf Of Stian Thorgersen
Sent: Thursday, February 28, 2019 12:26 AM
To: keycloak-dev <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
keycloak-dev at lists.jboss.org
https://clicktime.symantec.com/35NVx3Bd41ZVjjssocqwjpK7Vc?u=https%3A%2F%2Flists.jboss.org%2Fmailman%2Flistinfo%2Fkeycloak-dev


From sthorger at redhat.com  Thu Feb 28 04:52:33 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 28 Feb 2019 10:52:33 +0100
Subject: [keycloak-dev] Request for someone to contribute an WebAuthn4j
	extension
In-Reply-To: <TY2PR01MB4540BFE30A76A20F0CF2C8ECC9740@TY2PR01MB4540.jpnprd01.prod.outlook.com>
References: <CAJgngAdCOusGh0Mf1yHO4TA9j54C9gG48WMi3Uba0+GvFDMs7Q@mail.gmail.com>
	<TY2PR01MB4540BFE30A76A20F0CF2C8ECC9740@TY2PR01MB4540.jpnprd01.prod.outlook.com>
Message-ID: <CAJgngAcJak=OEHW2YTyNQhUBc5S1FBJz+qNRFCFm=e8NXNbvQA@mail.gmail.com>

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 <
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: keycloak-dev-bounces at lists.jboss.org <
> keycloak-dev-bounces at lists.jboss.org> On Behalf Of Stian Thorgersen
> Sent: Thursday, February 28, 2019 12:26 AM
> To: keycloak-dev <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
> keycloak-dev at lists.jboss.org
>
> https://clicktime.symantec.com/35NVx3Bd41ZVjjssocqwjpK7Vc?u=https%3A%2F%2Flists.jboss.org%2Fmailman%2Flistinfo%2Fkeycloak-dev
>

From pskopek at redhat.com  Thu Feb 28 05:07:18 2019
From: pskopek at redhat.com (Peter Skopek)
Date: Thu, 28 Feb 2019 11:07:18 +0100
Subject: [keycloak-dev] Application Initiated Actions
In-Reply-To: <CAJgngAeHYxNFRdAdYUJHGerDa06109O6uZWP7Aq5xQNPrW-QuA@mail.gmail.com>
References: <CAJgngAeHYxNFRdAdYUJHGerDa06109O6uZWP7Aq5xQNPrW-QuA@mail.gmail.com>
Message-ID: <CAM01paboUsvHA_WR3TC455ByZV4V0m7r7JDKsi2xDvpZCDGZ-Q@mail.gmail.com>

Since there is no "silent" application initiated action (always
prompts user) possible and actions are predefined at keycloak I see no
need for the client/application restriction mechanism.

On Wed, Feb 27, 2019 at 4:23 PM Stian Thorgersen <sthorger at redhat.com> wrote:
>
> Keycloak currently has required actions that are used to prompt the user to
> perform an action associated with their account after authenticating, but
> prior to being redirected to the application.
>
> Examples include: configure OTP, update profile, validate email, etc.
>
> One issue here is these actions have to be manually registered with the
> users account, but can not be initiated by applications themselves. As an
> example it may not be required by all users to verify their email, but only
> when they use specific applications.
>
> Keycloak also needs to initiate actions from the account management
> console. Examples: updating email address should require verifying the
> email, configuring OTP, etc.
>
> With that in mind we are proposing to introduce Application Initiated
> Actions. An Application Initiated Action behind the scenes is just a
> Required Action, but it is initiated by an application and depending on the
> action may be optional for the user to complete (where the user can select
> cancel which would return the user back to the application).
>
> No Application Initiated Actions should perform any updates to the users
> account without prompting the user first. For example an application
> initiated action that is used to link an existing account to a social
> provider should ask the user first if they want to link to the provider.
>
> To make it easy for applications to integrate these I would like to
> leverage the standard OAuth flows that applications use to authenticate
> users. So to initiate verify-email action the application would redirect to
> the authentication endpoint and add kc_action=<action alias> query
> parameter.
>
> One open question I have right now is. Assuming all Application Initiated
> Actions always prompt the user first do we need to add some mechanism in
> place to restrict what clients/applications are permitted to initiate an
> action? Requiring that would make it harder to use for applications.
>
> One thing I would also like to add is the ability for an Application
> Initiated Action to require the user to re-authenticate prior to performing
> the action. For example update password should require the user to enter
> the current password, while verify email should not (as it simply sends an
> email with a link to continue).
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From mail at ynojima.net  Thu Feb 28 05:43:15 2019
From: mail at ynojima.net (Yoshikazu Nojima)
Date: Thu, 28 Feb 2019 19:43:15 +0900
Subject: [keycloak-dev] Request for someone to contribute an WebAuthn4j
	extension
In-Reply-To: <CAJgngAcJak=OEHW2YTyNQhUBc5S1FBJz+qNRFCFm=e8NXNbvQA@mail.gmail.com>
References: <CAJgngAdCOusGh0Mf1yHO4TA9j54C9gG48WMi3Uba0+GvFDMs7Q@mail.gmail.com>
	<TY2PR01MB4540BFE30A76A20F0CF2C8ECC9740@TY2PR01MB4540.jpnprd01.prod.outlook.com>
	<CAJgngAcJak=OEHW2YTyNQhUBc5S1FBJz+qNRFCFm=e8NXNbvQA@mail.gmail.com>
Message-ID: <CAGTtUd5yMRjz+jYgoEuudPBR0N2NzHyg7cw_83JTL-xcBpxGGQ@mail.gmail.com>

Hello,

I'm Noji, developing WebAuthn4J.

Thank you for the design doc.
I will tackle this feature too and work with Hitachi team.

2019?2?28?(?) 18:53 Stian Thorgersen <sthorger at redhat.com>:
>
> 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 <
> 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: keycloak-dev-bounces at lists.jboss.org <
> > keycloak-dev-bounces at lists.jboss.org> On Behalf Of Stian Thorgersen
> > Sent: Thursday, February 28, 2019 12:26 AM
> > To: keycloak-dev <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
> > 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://lists.jboss.org/mailman/listinfo/keycloak-dev


From thomas.darimont at googlemail.com  Thu Feb 28 14:01:41 2019
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Thu, 28 Feb 2019 20:01:41 +0100
Subject: [keycloak-dev] Support for more flexible SAML handling for
 Attribute, AttributeValue and AttributeStatement elements
Message-ID: <CAK-7U1gDChV0Qo_VpSE0xHEcfvL05F-W-vuECL4p5_=SjPBdzA@mail.gmail.com>

Hello,

In my current project I needed to support extensive customizations of SAML
"Attribute"-elements in Keycloak SAML responses.
Unfortunately keycloaks
"org.keycloak.protocol.saml.mappers.SAMLAttributeStatementMapper" was not
powerful enough to support
all required customizations.

Some features that were missing / problems I faced were:
- Support for custom AttributeValue types, c.f. "xsd:anyURI" to represent
urn:oid values
- Support for complex nested elements (see example below)
- SAMLAttributeStatementMapper's effectivenes is restricted by
org.keycloak.saml.processing.core.saml.v2.writers.BaseWriter.writeAttributeTypeWithoutRootTag
- Lacking support for custom core protocol implementations, like "saml"
- provider-id "saml" should not be used to identify the "protocol"

Here is an example "AttributeStatement" fragment that I needed to support.
...
        <AttributeStatement>
            <Attribute Name="Role"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
                <AttributeValue xmlns:xsi="
http://www.w3.org/2001/XMLSchema-instance"
xsi:type="xsd:string">dummy</AttributeValue>
            </Attribute>

            <Attribute FriendlyName="XSPA Organization ID"
                Name="urn:oasis:names:tc:xspa:1.0:subject:organization-id"

NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
                <AttributeValue xmlns:xsi="
http://www.w3.org/2001/XMLSchema-instance"
xsi:type="xsd:anyURI">urn:oid:1.2.3.4.5.6.7.8.9.10.11.12</AttributeValue>
            </Attribute>

            <Attribute FriendlyName="Acme Role"
Name="urn:oasis:names:tc:xacml:2.0:subject:role"

NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
                <AttributeValue xmlns:xsi="
http://www.w3.org/2001/XMLSchema-instance" xsi:type="xsd:anyType">
                <Role code="PRA" codeSystem="1.2.3.4.5.6.7.8.9.10.11.12"
                          codeSystemName="IHEXDShealthcareFacilityTypeCode"
displayName="Doctor's office" xmlns="urn:hl7-org:v3"/>
                </AttributeValue>
            </Attribute>
        </AttributeStatement>
...
a full example for a complete SAML response can be found here for
reference:
https://gist.github.com/thomasdarimont/02a7861562d0684861b213a1d16b7047

I eventually managed to customize the SAML responses as needed, but my
approach is probably not 100% future proof...
If anyone here knows a better way to do this, I'm all ears :)

Nevertheless, it would be great if Keycloaks support for custom SAML
attributes would be more flexible in the future.

Anyways, here is what I had to do in order to get the required SAML
customizations working:

- Create a "org.keycloak.protocol.LoginProtocolFactory" extension and
reference "CustomSamlProtocolFactory"
- Create class CustomSamlProtocolFactory extends SamlProtocolFactory
- Create class CustomSamlProtocol extends SamlProtocol and return a new
CustomSamlProtocol instance in CustomSamlProtocolFactory#create(..) (see
below)
- override
org.keycloak.protocol.saml.SamlProtocol#buildAuthenticatedResponse
  -> protected Response
buildAuthenticatedResponse(AuthenticatedClientSessionModel clientSession,
String redirectUri, Document samlDocument, JaxrsSAML2BindingBuilder
bindingBuilder)
  -> samlDocument contains the SAML document populated by Keycloak BEFORE
it is signed and encrypted
  -> clientSession gives you access to the current user etc.
  -> add custom SAML processing as needed
  -> call return super.buildAuthenticatedResponse(clientSession,
redirectUri, samlDocument, bindingBuilder); at the end, this potentially
signs and encrypts the SAML document
- Make keycloak aware of that extension... (tricky, read on)

Note that the "CustomSamlProtocolFactory" uses the same provider ID "saml"
as the "SamlProtocolFactory" does -> this leads to a name clash...
unfortunantely Keycloak currently doesn't support to have custom
implementations for core protocols.

Here comes the hack:
In order to let Keycloak pickup my "CustomSamlProtocolFactory"
implementation before it's own "SamlProtocolFactory", I needed to copy the
provider jar to
`$KEYCLOAK_HOME/modules/system/layers/keycloak/org/keycloak/keycloak-services/main`
and change the keycloak-services module.xml to:

    <resources>
        <resource-root
path="simple-custom-saml-protocol-1.0.0.0-SNAPSHOT.jar"/> <!-- added this
-->
        <resource-root path="keycloak-services-4.8.3.Final.jar"/>
    </resources>

With that change Keycloak picked up my custom "CustomSamlProtocolFactory"
first and I could adjust the SAML document as required.

Btw. you might be wondering why I didn't just create a new
"CustomSamlProtocolFactory" with a dedicated provider-id like "saml-custom"
and use that for clients. We'll that was my first try, but unfortunately
this is currently not possible, since the Admin-Console
UI for the SAML configuration seems to be hard-coded against the
provider-id "saml"... so I'm stuck with the current "solution".
It would be great if the "LoginProtocolFactory" SPI would support custom
protocol implementations, while reusing protocol configuration options and
the admin-console ui.

Cheers,
Thomas

Ps.:

FYI this is what a SAMLAttributeStatementMapper allows you to do currently
(Keycloak 4.8.3.Final):

// SimpleSamlMapper
...
    @Override
    public void transformAttributeStatement(AttributeStatementType
attributeStatement, ProtocolMapperModel mappingModel, KeycloakSession
session, UserSessionModel userSession, AuthenticatedClientSessionModel
clientSession) {

        // transform attributeStatement here
        LOGGER.infof("transformAttributeStatement");

        AttributeType bubu = new AttributeType("bubu");
        bubu.setFriendlyName("FriendlyBubu");

bubu.setNameFormat("urn:oasis:names:tc:SAML:2.0:attrname-format:basic");
        bubu.setName("Bubu");

        bubu.addAttributeValue("Object allowed but only Strings or
NameIDType supported here...");
        // see: bottom of
org.keycloak.saml.processing.core.saml.v2.writers.BaseWriter.writeAttributeTypeWithoutRootTag

        // would be great to have support for AttributeValue type
customizations, even if value is String.
        // would be great to have support for complex XML element as values

        attributeStatement.addAttribute(new
AttributeStatementType.ASTChoiceType(bubu));
    }
...

// CustomSamlProtocolFactory
import org.keycloak.models.KeycloakSession;
import org.keycloak.protocol.LoginProtocol;
import org.keycloak.protocol.saml.SamlProtocolFactory;

public class CustomSamlProtocolFactory extends SamlProtocolFactory {

    public LoginProtocol create(KeycloakSession session) {
        return (new CustomSamlProtocol()).setSession(session);
    }
}


// CustomSamlProtocol
import org.keycloak.models.AuthenticatedClientSessionModel;
import org.keycloak.protocol.saml.JaxrsSAML2BindingBuilder;
import org.keycloak.protocol.saml.SamlProtocol;
import org.keycloak.saml.common.constants.JBossSAMLURIConstants;
import org.keycloak.saml.common.exceptions.ConfigurationException;
import org.keycloak.saml.common.exceptions.ProcessingException;
import org.w3c.dom.Document;
import org.w3c.dom.Element;

import javax.ws.rs.core.Response;
import java.io.IOException;

public class CustomSamlProtocol extends SamlProtocol {

    protected Response
buildAuthenticatedResponse(AuthenticatedClientSessionModel clientSession,
String redirectUri, Document samlDocument, JaxrsSAML2BindingBuilder
bindingBuilder) throws ConfigurationException, ProcessingException,
IOException {

        // TODO use Keycloak provider information from this.session
        Element assertionElement = (Element)
samlDocument.getElementsByTagNameNS(JBossSAMLURIConstants.ASSERTION_NSURI.get(),
"Assertion").item(0);

        Element attributeStatementElement = (Element)
assertionElement.getElementsByTagNameNS(JBossSAMLURIConstants.ASSERTION_NSURI.get(),
"AttributeStatement").item(0);
        if (attributeStatementElement == null) {
            attributeStatementElement =
samlDocument.createElementNS(JBossSAMLURIConstants.ASSERTION_NSURI.get(),
"AttributeStatement");
            assertionElement.appendChild(attributeStatementElement);
        }
        // TODO pull information from user attributes

attributeStatementElement.appendChild(newSamlAttributeElement(samlDocument,
null, "Role", JBossSAMLURIConstants.ATTRIBUTE_FORMAT_BASIC.get(), "dummy",
"xsd:string"));

        // see: http://oid-info.com/get/

attributeStatementElement.appendChild(newSamlAttributeElement(samlDocument,
"XSPA Organization ID",
"urn:oasis:names:tc:xspa:1.0:subject:organization-id",
JBossSAMLURIConstants.ATTRIBUTE_FORMAT_URI.get(),
"urn:oid:1.2.3.4.5.6.7.8.9.10.11.12", "xsd:anyURI"));

        Element roleElement =
samlDocument.createElementNS("urn:hl7-org:v3", "Role");
        roleElement.setAttribute("code", "PRA");
        roleElement.setAttribute("codeSystem",
"1.2.3.4.5.6.7.8.9.10.11.12");
        roleElement.setAttribute("codeSystemName",
"IHEXDShealthcareFacilityTypeCode");
        roleElement.setAttribute("displayName", "Doctor's office");

attributeStatementElement.appendChild(newSamlAttributeElement(samlDocument,
"Acme Role", "urn:oasis:names:tc:xacml:2.0:subject:role",
JBossSAMLURIConstants.ATTRIBUTE_FORMAT_URI.get(), roleElement,
"xsd:anyType"));

        return super.buildAuthenticatedResponse(clientSession, redirectUri,
samlDocument, bindingBuilder);
    }

    private Element newSamlAttributeElement(Document samlDocument, String
friendlyName, String name, String nameFormat, Object value, String type) {

        Element targetSamlAttributeElement =
samlDocument.createElementNS(JBossSAMLURIConstants.ASSERTION_NSURI.get(),
"Attribute");

        if (friendlyName != null) {
            targetSamlAttributeElement.setAttribute("FriendlyName",
friendlyName);
        }
        targetSamlAttributeElement.setAttribute("Name", name);
        if (nameFormat != null) {
            targetSamlAttributeElement.setAttribute("NameFormat",
nameFormat);
        }

        Element samlAttributeValue =
samlDocument.createElementNS(JBossSAMLURIConstants.ASSERTION_NSURI.get(),
"AttributeValue");
        samlAttributeValue.setAttribute("xmlns:xsi", "
http://www.w3.org/2001/XMLSchema-instance");
        samlAttributeValue.setAttribute("xsi:type", type);
        targetSamlAttributeElement.appendChild(samlAttributeValue);

        if (value instanceof String) {
            samlAttributeValue.setTextContent((String) value);
        } else if (value instanceof Element) {
            samlAttributeValue.appendChild((Element) value);
        } else if (value != null) {
            samlAttributeValue.setTextContent(value.toString());
        } else {
            samlAttributeValue.setTextContent(String.valueOf(value));
        }

        return targetSamlAttributeElement;
    }
}

From yuichi.nakamura.fe at hitachi.com  Thu Feb 28 23:34:00 2019
From: yuichi.nakamura.fe at hitachi.com (=?utf-8?B?5Lit5p2R6ZuE5LiAIC8gTkFLQU1VUkHvvIxZVVVJQ0hJ?=)
Date: Fri, 1 Mar 2019 04:34:00 +0000
Subject: [keycloak-dev] Request for someone to contribute an WebAuthn4j
 extension
In-Reply-To: <CAJgngAcJak=OEHW2YTyNQhUBc5S1FBJz+qNRFCFm=e8NXNbvQA@mail.gmail.com>
References: <CAJgngAdCOusGh0Mf1yHO4TA9j54C9gG48WMi3Uba0+GvFDMs7Q@mail.gmail.com>
	<TY2PR01MB4540BFE30A76A20F0CF2C8ECC9740@TY2PR01MB4540.jpnprd01.prod.outlook.com>
	<CAJgngAcJak=OEHW2YTyNQhUBc5S1FBJz+qNRFCFm=e8NXNbvQA@mail.gmail.com>
Message-ID: <TY2PR01MB454004225E04FC9C4DF5450BC9760@TY2PR01MB4540.jpnprd01.prod.outlook.com>


> Do you have an idea on roughly when you can have a prototype ready?
It is difficult to estimate for now, but hopefully within this month (March).
We will tell you as soon as it is available.

Regards,
Yuichi Nakamura


From: Stian Thorgersen <sthorger at redhat.com> 
Sent: Thursday, February 28, 2019 6:53 PM
To: ???? / NAKAMURA?YUUICHI <yuichi.nakamura.fe at hitachi.com>
Cc: keycloak-dev <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: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:keycloak-dev-bounces at lists.jboss.org <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: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:keycloak-dev at lists.jboss.org
https://clicktime.symantec.com/35NVx3Bd41ZVjjssocqwjpK7Vc?u=https%3A%2F%2Flists.jboss.org%2Fmailman%2Flistinfo%2Fkeycloak-dev