From sthorger at redhat.com  Wed Jan  2 05:13:25 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 2 Jan 2019 11:13:25 +0100
Subject: [keycloak-dev] [keycloak-user] Keycloak 4.8.0.Final released
In-Reply-To: <CAHzT=q86VGa=2Q2XOnaswPiQ4dh7y==8PwvPyE4sCR5d1-8XKg@mail.gmail.com>
References: <CAJgngAeOAQMEO32P8aUfjX3rN1QovhcY0VMqcfQQU3N_M2c7+Q@mail.gmail.com>
	<CAHzT=q86VGa=2Q2XOnaswPiQ4dh7y==8PwvPyE4sCR5d1-8XKg@mail.gmail.com>
Message-ID: <CAJgngAfa9ZXcB2gXrKXWApjNxohVyUUvJrSHbJ8GNF8SY_LbcQ@mail.gmail.com>

In the past we didn't disable preview features (or make it obvious that
they where preview) in the Keycloak releases. In RH-SSO releases we did
make all these preview. To make it consistent and also to better
communicate with the community what may not be fully production ready we
decided to make it consistent.

Preview doesn't mean it is buggy, but rather that the feature may be
incomplete and may be drastically changed in the future (even completely
removed) and that there are no guarantees for a seamless upgrade between
releases if you use tech preview features.

On Mon, 17 Dec 2018 at 13:21, Geoffrey Cleaves <geoff at opticks.io> wrote:

> Thanks for the update. I see more and more features being labeled as tech
> preview and disabled by default. I guess that this means the features have
> bugs or negatively impact performance? Any further insight would be
> appreciated.
>
> On Mon, 17 Dec 2018 at 12:59, Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> To download the release go to the Keycloak homepage
>> <http://www.keycloak.org/downloads>.
>>
>> For details on what is included in the release check out the Release notes
>> <https://www.keycloak.org/docs/latest/release_notes/index.html>
>>
>> The full list of resolved issues is available in JIRA
>> <
>> https://issues.jboss.org/issues/?jql=project%20%3D%20keycloak%20and%20fixVersion%20%3D%204.8.0.Final
>> >
>> .
>>
>> Before you upgrade remember to backup your database and check the upgrade
>> guide <http://www.keycloak.org/docs/latest/upgrading/index.html> for
>> anything that may have changed.
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>
>
> --
>
> Regards,
> Geoffrey Cleaves
>
>
>
>
>
>

From sthorger at redhat.com  Wed Jan  2 05:20:35 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 2 Jan 2019 11:20:35 +0100
Subject: [keycloak-dev] Questions about adding new identity providers
In-Reply-To: <2014743213.11302.1545217252214@office.mailbox.org>
References: <2014743213.11302.1545217252214@office.mailbox.org>
Message-ID: <CAJgngAeugKh59qozMgfNVEFB-wPbxyO2_cCjE7gjT_KUtY7PUg@mail.gmail.com>

There's already support for generic OIDC providers. Generic OAuth2 doesn't
make all that much sense as it doesn't provide standard ways to obtain user
profiles or do logouts. Does vk.com support OIDC (ID token and userinfo
endpoint)? If so you can already use it with Keycloak without adding a
custom provider for it.

We've not had any requests for vk.com until now so we would probably not
accept it into the core Keycloak codebase. This is simply down to
maintenance. If you want to develop a plugin though we can link to it from
the extensions list on keycloak.org.

On Wed, 19 Dec 2018 at 12:03, Wladislaw Mitzel <mitzel at tawadi.de> wrote:

> Hi all,
>
> How is the addition of new identity providers handled in this project? I'd
> love to have a vk.com integration in keycloak. After some search, I've
> found this pull request [1] which adds PayPal as a new IdP. I think it's a
> pretty good "blueprint" of how to add a new IdP. I plan to give it a try
> and implement vk.com. This raises the following questions:
>
> 1) Is this implementation of a vk.com IdP something the project is
> interested in?
>
> 2) Does the answer to 1) apply to all IdPs? I mean vk.com is a quite
> large social network. What about some less known websites providing OAuth2
> authentication. Would *any* IdP be added to the project? Are there certain
> criteria from which you can decide?
>
> 3) What do you think about a feature which would enable to "configure"
> arbitrary OAuth2 Providers as IdP using the Admin Console? To me most of
> the implementations of
> org.keycloak.broker.oidc.AbstractOAuth2IdentityProvider look pretty
> similar. The main differences are how to interpret the responses of the
> IdP: I wonder whether this could be generalised.
>
> I look forward to your answers,
>
> Kind Regards,
> Wladislaw
>
> [1] https://github.com/keycloak/keycloak/pull/4449
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From nhariprasad2018.2 at gmail.com  Wed Jan  2 10:26:20 2019
From: nhariprasad2018.2 at gmail.com (Hari Prasad)
Date: Wed, 2 Jan 2019 20:56:20 +0530
Subject: [keycloak-dev] Fwd: Realm Custom Attributes
In-Reply-To: <CAPtTC63X8LB=PEr1K5VgbvAQpDt_MMUQ5HEVWEGiqpC8XhVNnQ@mail.gmail.com>
References: <CAPtTC63X8LB=PEr1K5VgbvAQpDt_MMUQ5HEVWEGiqpC8XhVNnQ@mail.gmail.com>
Message-ID: <CAPtTC61h_saDVn1qUxBp5b8KqbtHb1TLSXUVoHKCpHAOfrK_6g@mail.gmail.com>

Hi All,

Can we add realm level custom attributes.

Regards
Hari Prasad N.

---------- Forwarded message ---------
From: Hari Prasad <nhariprasad2018.2 at gmail.com>
Date: Wed, Jan 2, 2019 at 7:01 PM
Subject: Realm Custom Attributes
To: <keycloak-user at lists.jboss.org>


Hi All,

Can we add realm level custom attributes.

Regards
Hari Prasad N.

From nhariprasad2018.2 at gmail.com  Wed Jan  2 10:27:29 2019
From: nhariprasad2018.2 at gmail.com (Hari Prasad)
Date: Wed, 2 Jan 2019 20:57:29 +0530
Subject: [keycloak-dev] Fwd: Authorization in Angular
In-Reply-To: <CAPtTC63iLMhxwBzfOO9Zis8Nce=LcneVCKDnsKO4=rnRUwHAnA@mail.gmail.com>
References: <CAPtTC63iLMhxwBzfOO9Zis8Nce=LcneVCKDnsKO4=rnRUwHAnA@mail.gmail.com>
Message-ID: <CAPtTC60=YQjPAcG-UQnXPEZNka0u=xLfrFR0tG0rUFGg_wy5VQ@mail.gmail.com>

Hi All,

I am using keycloak-angular to integrate our Angular App to keycloak.
Authentication is working fine but authorization not working with angular.
Authorization working fine with spring boot and normal java webapps.
Please help to resolve authorization problem with angular.


Regards
Hari Prasad N

---------- Forwarded message ---------
From: Hari Prasad <nhariprasad2018.2 at gmail.com>
Date: Wed, Jan 2, 2019 at 7:11 PM
Subject: Authorization in Angular
To: <keycloak-user at lists.jboss.org>


Hi All,

I am using keycloak-angular to integrate our Angular App to keycloak.
Authentication is working fine but authorization not working with angular.
Authorization working fine with spring boot and normal java webapps.
Please help to resolve authorization problem with angular.


Regards
Hari Prasad N

From nhariprasad2018.2 at gmail.com  Wed Jan  2 10:28:15 2019
From: nhariprasad2018.2 at gmail.com (Hari Prasad)
Date: Wed, 2 Jan 2019 20:58:15 +0530
Subject: [keycloak-dev] Fwd: Dynamic realm choose for REST API.
In-Reply-To: <CAPtTC60wrCiVXGUzRZc-xYk-i4rKVkYC+bLo=QVQPa3Xy7y7vQ@mail.gmail.com>
References: <CAPtTC63C9xPCCb1wjXxfzLkJ=O2drrki1Kh0nQSAxeEZumHxNQ@mail.gmail.com>
	<CAPtTC60wrCiVXGUzRZc-xYk-i4rKVkYC+bLo=QVQPa3Xy7y7vQ@mail.gmail.com>
Message-ID: <CAPtTC61GrU5MU021z1V55o1hi3XPfbNXGVoGvUa5Ho3=Uqnoew@mail.gmail.com>

Hi All,

I have bearer-only client for one of out Rest API Application. I am able to
get Bearer token from UI app and pass to Rest API and consume services.
The backend Rest API takes config data from keycloak.json, but i want to
change realm name dynamically because the Bearer tokens may be of different
relam dynamically.

Regards
Hari Prasad N.

---------- Forwarded message ---------
From: Hari Prasad <nhariprasad2018.2 at gmail.com>
Date: Wed, Jan 2, 2019 at 8:54 PM
Subject: Re: Dynamic realm choose for REST API.
To: <keycloak-user at lists.jboss.org>


Hi All,

I have bearer-only client for one of out Rest API Application. I am able to
get Bearer token from UI app and pass to Rest API and consume services.
The backend Rest API takes config data from keycloak.json, but i want to
change realm name dynamically because the Bearer tokens may be of different
relam dynamically.

Regards
Hari Prasad N.

On Wed, Jan 2, 2019 at 7:16 PM Hari Prasad <nhariprasad2018.2 at gmail.com>
wrote:

> Hi All,
>
> I have bearer-only client for one of out Rest API Application. I am able
> to get Bearer token from UI app and pass to Rest API and consume services.
> The backend Rest API takes config data from keycloak.json, but i want to
> change realm name dynamically because the Bearer tokens may be of different
> relam dynamically.
>
> Regards
> Hari Prasad N.
>
>

From sthorger at redhat.com  Wed Jan  2 10:38:14 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 2 Jan 2019 16:38:14 +0100
Subject: [keycloak-dev] Fwd: Dynamic realm choose for REST API.
In-Reply-To: <CAPtTC61GrU5MU021z1V55o1hi3XPfbNXGVoGvUa5Ho3=Uqnoew@mail.gmail.com>
References: <CAPtTC63C9xPCCb1wjXxfzLkJ=O2drrki1Kh0nQSAxeEZumHxNQ@mail.gmail.com>
	<CAPtTC60wrCiVXGUzRZc-xYk-i4rKVkYC+bLo=QVQPa3Xy7y7vQ@mail.gmail.com>
	<CAPtTC61GrU5MU021z1V55o1hi3XPfbNXGVoGvUa5Ho3=Uqnoew@mail.gmail.com>
Message-ID: <CAJgngAfkW7mr2jcGn7v9YrevtonLg-R+_dKVOZLC=vdwqj6s1Q@mail.gmail.com>

This list is only for Keycloak developers and contributors. For general
help and questions please use the user mailing list.

On Wed, 2 Jan 2019 at 16:35, Hari Prasad <nhariprasad2018.2 at gmail.com>
wrote:

> Hi All,
>
> I have bearer-only client for one of out Rest API Application. I am able to
> get Bearer token from UI app and pass to Rest API and consume services.
> The backend Rest API takes config data from keycloak.json, but i want to
> change realm name dynamically because the Bearer tokens may be of different
> relam dynamically.
>
> Regards
> Hari Prasad N.
>
> ---------- Forwarded message ---------
> From: Hari Prasad <nhariprasad2018.2 at gmail.com>
> Date: Wed, Jan 2, 2019 at 8:54 PM
> Subject: Re: Dynamic realm choose for REST API.
> To: <keycloak-user at lists.jboss.org>
>
>
> Hi All,
>
> I have bearer-only client for one of out Rest API Application. I am able to
> get Bearer token from UI app and pass to Rest API and consume services.
> The backend Rest API takes config data from keycloak.json, but i want to
> change realm name dynamically because the Bearer tokens may be of different
> relam dynamically.
>
> Regards
> Hari Prasad N.
>
> On Wed, Jan 2, 2019 at 7:16 PM Hari Prasad <nhariprasad2018.2 at gmail.com>
> wrote:
>
> > Hi All,
> >
> > I have bearer-only client for one of out Rest API Application. I am able
> > to get Bearer token from UI app and pass to Rest API and consume
> services.
> > The backend Rest API takes config data from keycloak.json, but i want to
> > change realm name dynamically because the Bearer tokens may be of
> different
> > relam dynamically.
> >
> > Regards
> > Hari Prasad N.
> >
> >
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sthorger at redhat.com  Wed Jan  2 10:38:26 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 2 Jan 2019 16:38:26 +0100
Subject: [keycloak-dev] Fwd: Authorization in Angular
In-Reply-To: <CAPtTC60=YQjPAcG-UQnXPEZNka0u=xLfrFR0tG0rUFGg_wy5VQ@mail.gmail.com>
References: <CAPtTC63iLMhxwBzfOO9Zis8Nce=LcneVCKDnsKO4=rnRUwHAnA@mail.gmail.com>
	<CAPtTC60=YQjPAcG-UQnXPEZNka0u=xLfrFR0tG0rUFGg_wy5VQ@mail.gmail.com>
Message-ID: <CAJgngAevcGaem+TuXaNcM34s0ODZz=PqfVSK6Fuz2k+=pv1Knw@mail.gmail.com>

This list is only for Keycloak developers and contributors. For general
help and questions please use the user mailing list.

On Wed, 2 Jan 2019 at 16:35, Hari Prasad <nhariprasad2018.2 at gmail.com>
wrote:

> Hi All,
>
> I am using keycloak-angular to integrate our Angular App to keycloak.
> Authentication is working fine but authorization not working with angular.
> Authorization working fine with spring boot and normal java webapps.
> Please help to resolve authorization problem with angular.
>
>
> Regards
> Hari Prasad N
>
> ---------- Forwarded message ---------
> From: Hari Prasad <nhariprasad2018.2 at gmail.com>
> Date: Wed, Jan 2, 2019 at 7:11 PM
> Subject: Authorization in Angular
> To: <keycloak-user at lists.jboss.org>
>
>
> Hi All,
>
> I am using keycloak-angular to integrate our Angular App to keycloak.
> Authentication is working fine but authorization not working with angular.
> Authorization working fine with spring boot and normal java webapps.
> Please help to resolve authorization problem with angular.
>
>
> Regards
> Hari Prasad N
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sthorger at redhat.com  Wed Jan  2 10:38:32 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 2 Jan 2019 16:38:32 +0100
Subject: [keycloak-dev] Fwd: Realm Custom Attributes
In-Reply-To: <CAPtTC61h_saDVn1qUxBp5b8KqbtHb1TLSXUVoHKCpHAOfrK_6g@mail.gmail.com>
References: <CAPtTC63X8LB=PEr1K5VgbvAQpDt_MMUQ5HEVWEGiqpC8XhVNnQ@mail.gmail.com>
	<CAPtTC61h_saDVn1qUxBp5b8KqbtHb1TLSXUVoHKCpHAOfrK_6g@mail.gmail.com>
Message-ID: <CAJgngAe3cTuiH5iDUhXPfeWTKX98geysef8QJc=q_uSSmw3vTg@mail.gmail.com>

This list is only for Keycloak developers and contributors. For general
help and questions please use the user mailing list.

On Wed, 2 Jan 2019 at 16:35, Hari Prasad <nhariprasad2018.2 at gmail.com>
wrote:

> Hi All,
>
> Can we add realm level custom attributes.
>
> Regards
> Hari Prasad N.
>
> ---------- Forwarded message ---------
> From: Hari Prasad <nhariprasad2018.2 at gmail.com>
> Date: Wed, Jan 2, 2019 at 7:01 PM
> Subject: Realm Custom Attributes
> To: <keycloak-user at lists.jboss.org>
>
>
> Hi All,
>
> Can we add realm level custom attributes.
>
> Regards
> Hari Prasad N.
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From slaskawi at redhat.com  Mon Jan  7 07:36:00 2019
From: slaskawi at redhat.com (Sebastian Laskawiec)
Date: Mon, 7 Jan 2019 13:36:00 +0100
Subject: [keycloak-dev] User TLS client certificate authentication -
 inconsistent DN string representation with LDAP
In-Reply-To: <5D9D597A-206A-4E7C-96E9-DB3368842117@mitre.org>
References: <5D9D597A-206A-4E7C-96E9-DB3368842117@mitre.org>
Message-ID: <CAA9R9O71Gmg7Vicsxqw9yTivGUpic7fWO6b=WdM44cQVhtcC_Q@mail.gmail.com>

Hey Michael,

Adding +Sebastien Blanc <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> 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/authenticators/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/LDAPDn.java
> b/federation/ldap/src/main/
> index 39e7d97..2f8c805 100644
> ---
> a/federation/ldap/src/main/java/org/keycloak/storage/ldap/idm/model/LDAPDn.java
> +++
> b/federation/ldap/src/main/java/org/keycloak/storage/ldap/idm/model/LDAPDn.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
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From tim.hedlund at outlook.com  Tue Jan  8 03:23:05 2019
From: tim.hedlund at outlook.com (Tim Hedlund)
Date: Tue, 8 Jan 2019 08:23:05 +0000
Subject: [keycloak-dev] Hardcoded port 8443
Message-ID: <SN4PR0801MB3821D5722B19ED5082AF85A1F88A0@SN4PR0801MB3821.namprd08.prod.outlook.com>

Hi All,

I noticed that when I tried to set the OpenID java adapter configuration parameter "ssl-required" to "all" I started to get port 8443 in the redirect_uri:

response_type=code&client_id=skf.com&redirect_uri=https%3A%2F%2Flocalhost%3A8443%2Fgroup%2index.html&state=ee8e8b59-f10a-4d13-b2d6-ff8b507850b2&login=true&scope=opened

I was curious to why I got the port 8443 and I found it being hardcoded here: https://github.com/keycloak/keycloak/blob/c3fa471223e102e740425f166415eb1823b8d888/adapters/oidc/servlet-filter/src/main/java/org/keycloak/adapters/servlet/KeycloakOIDCFilter.java#L194

Is this intentionally?

Regards
Tim

From Patrice.Amiel at gemalto.com  Tue Jan  8 03:35:26 2019
From: Patrice.Amiel at gemalto.com (AMIEL Patrice)
Date: Tue, 8 Jan 2019 08:35:26 +0000
Subject: [keycloak-dev] Defining several Password Policies within a Realm
Message-ID: <PR1PR01MB4939AE7E0BE3C820C1360755F68A0@PR1PR01MB4939.eurprd01.prod.exchangelabs.com>

Hi all,

We are currently working on adding the capability to define several Password Policies for a given realm.
The rationale is that in our systems, within a given realm, we have different "types" of accounts that have different constraints on password management. For instance:

-          Administrators shall have long and complex passwords, with a very short password expiration time

-          Regular users have a "normal" :P password strength, and medium expiration time

-          Accounts for technical/automated access to the system shall never expire and have very long passwords
All these Users shall be part of the same Realm.
Obviously, these 3 types are only an example and there might be a need of more types or less types of accounts for other deployments => the number of Password Policies is not fixed in advance.

We would definitely like to push the work as a PR, but before doing that, we'd like to be sure that we are going on the good tracks so that this PR could be accepted.
The idea is consequently, from Web UI perspectives:

-          To update the Password Policy pane so that we have first a list of what we could call "Password Policy Groups". Within this pane, an initial list would allow to list, create and edit the Password Policy Groups.

-          When creating or editing one of the available Password Policy Groups, a sub pane would allow to select the individual Password Policies to be added to the Group.

-          Then, on Users management section, a new drop-down field of the User edition page would enable to select the Password Policy Group to be applied to this specific User

-          The Password Policy Group page might remain under the Authentication menu area... but it might also be eligible to be moved to a dedicated area similar to the current "Group" area (indeed, we would then have a "Roles Groups" area (this is indeed what the current "Group" area is) and a "Password Policy Groups" area...)

Note that it would maybe be more convenient to attach a Password Policy Group to a "Group" rather than to an individual User, but as Users may belong to several Groups, then it would generate conflicts when applying the individual Password Policies if they are conflicting (for example, one saying that the min password length is 10 characters while the other saying it is 15).

Impacts are:

-          On the DB model and JPA classes to support a list of Password Policies (i.e. Password Policy Groups),

-          On the User classes to support attachment of a User to a Password Policy Group

-          On the GUI, as described above

-          On the authentication process, to select the right Password Policy

-          On the change password process, to select the right Password Policy

-          On the REST API

Does this proposal make sense to you (any concern or recommendation) ?

Thanks for your feedbacks

Best regards,
Patrice


________________________________
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 fredbi at yahoo.com  Tue Jan  8 09:14:49 2019
From: fredbi at yahoo.com (BIDON Frederic)
Date: Tue, 8 Jan 2019 14:14:49 +0000 (UTC)
Subject: [keycloak-dev] [keycloak-gatekeeper][KEYCLOAK-7175] upgrade from
	coreos/go-oidc.v1
References: <1883555636.14874786.1546956889973.ref@mail.yahoo.com>
Message-ID: <1883555636.14874786.1546956889973@mail.yahoo.com>


Relying on a stale package such as `github.com/coreos/go-oidc.v1` is really annoying for a security product.

Moreover, this library has no support for tokens with an EC signature.

I've tried a bit to remove this but I felt like the choice of a proper library should be discussed.

Here is my two cents:
   
   - coreos/go-oidc.v2 does not add much compared to stdlib `x/oauth2`: there is remote JWKS fetcher which might be useful, although this is in fact `square/go-jose` that does the heavy lifting here
   - I found `square/go-jose` good enough for JWK and JWKS, but rather unpractical for JWT. I found `dgrijalva/jwt-go` much handier when it comes to manipulate JWT

Any ideas / challenges around for a proper choice of dependencies here?
 
Cheers,

Fr?d?ric
??frederic.bidon at yahoo.com?

From guilhem.lucas at actility.com  Tue Jan  8 10:38:30 2019
From: guilhem.lucas at actility.com (Guilhem Lucas)
Date: Tue, 8 Jan 2019 16:38:30 +0100
Subject: [keycloak-dev] Make theme properties available in email
	templates
In-Reply-To: <CAJgngAeZrT2MpbhDr4XeHHcjBHJn+GKEoCnDXCW1Nehksvht6g@mail.gmail.com>
References: <CACdt9SD4B-ra6vHYTPFOJX7W6gNOHa_U2Hcf2nU3pRg4Lz7v+w@mail.gmail.com>
	<CAJgngAeZrT2MpbhDr4XeHHcjBHJn+GKEoCnDXCW1Nehksvht6g@mail.gmail.com>
Message-ID: <CACdt9SDjHrPyMXTFNRosb2dP6KtYKc_q0gkVFiwfTgbdeoZ8jQ@mail.gmail.com>

Indeed, it's already available in login forms and I have implemented it the
same way.

Do I need to create a Jira issue before submitting a PR?

Regards,

Guilhem

Le lun. 10 d?c. 2018 ? 11:02, Stian Thorgersen <sthorger at redhat.com> a
?crit :

> If I remember correctly these are already available to the login forms, so
> I have no issue with a PR for this as long as it's done consistently to how
> it's done in login forms.
>
> On Fri, 7 Dec 2018 at 11:42, Guilhem Lucas <guilhem.lucas at actility.com>
> wrote:
>
>> Hello,
>>
>> I need to have theme properties available in Freemarker email templates
>> (like in login and account theme).
>>
>> I overrided FreeMarkerEmailTemplateProvider to add them in a new attribute
>> "properties", but I think it could be useful to have it by default in
>> Keycloak.
>>
>> Is it possible to do it? If necessary I can create a pull request.
>>
>> Thank you.
>>
>> Guilhem Lucas
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>

-- 


*Guilhem Lucas*R&D Software Engineer

guilhem.lucas at actility.com

From pnalyvayko at agi.com  Tue Jan  8 17:02:17 2019
From: pnalyvayko at agi.com (Nalyvayko, Peter)
Date: Tue, 8 Jan 2019 22:02:17 +0000
Subject: [keycloak-dev] User TLS client certificate authentication -
 inconsistent DN string representation with LDAP
In-Reply-To: <CAA9R9O71Gmg7Vicsxqw9yTivGUpic7fWO6b=WdM44cQVhtcC_Q@mail.gmail.com>
References: <5D9D597A-206A-4E7C-96E9-DB3368842117@mitre.org>
	<CAA9R9O71Gmg7Vicsxqw9yTivGUpic7fWO6b=WdM44cQVhtcC_Q@mail.gmail.com>
Message-ID: <BL0PR07MB5009EDA268DBC0E082743001DA8A0@BL0PR07MB5009.namprd07.prod.outlook.com>

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?

Kindly,
Peter


-----Original Message-----
From: keycloak-dev-bounces at lists.jboss.org <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>; sblanc at redhat.com
Cc: 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> 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> 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
> 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 Jan  8 18:19:40 2019
From: jdennis at redhat.com (John Dennis)
Date: Tue, 8 Jan 2019 18:19:40 -0500
Subject: [keycloak-dev] User TLS client certificate authentication -
 inconsistent DN string representation with LDAP
In-Reply-To: <BL0PR07MB5009EDA268DBC0E082743001DA8A0@BL0PR07MB5009.namprd07.prod.outlook.com>
References: <5D9D597A-206A-4E7C-96E9-DB3368842117@mitre.org>
	<CAA9R9O71Gmg7Vicsxqw9yTivGUpic7fWO6b=WdM44cQVhtcC_Q@mail.gmail.com>
	<BL0PR07MB5009EDA268DBC0E082743001DA8A0@BL0PR07MB5009.namprd07.prod.outlook.com>
Message-ID: <6d2958f3-da03-bbc7-d37e-3c42bb76d188@redhat.com>

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?

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 <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>; sblanc at redhat.com
> Cc: 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> 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> 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
>> 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
> 


-- 
John Dennis

From info at jcoder.de  Wed Jan  9 08:37:44 2019
From: info at jcoder.de (JCoder)
Date: Wed, 09 Jan 2019 14:37:44 +0100
Subject: [keycloak-dev] Deputy for users
In-Reply-To: <F20A27A3-8989-4A23-B2F1-54FD8D9DE5CD@jcoder.de>
References: <b4c5f6151a4d4c4c808efb999685ed20@BOSKGEXC01.boskg.local>
	<F20A27A3-8989-4A23-B2F1-54FD8D9DE5CD@jcoder.de>
Message-ID: <329439FD-9846-4594-93F1-AC75C2798954@jcoder.de>



Hello,

I kindly ask to implement the deputy feature in keycloak.

Example: Before a user leaves for vacation, for a dedicated period of
time she can assign her groups to another user (the deputy).  The
deputy then has access to that groups - but only for the specified
period of time. Tough after the vacation the information about the
deputy regulation will remain in the database and can only be
explicitly deleted by the user.

Validations:
- The begin date for the deputy regulation is today or in the future
- The end date for the deputy regulation is not before the begin date
I'm excited about your opinion.

Cheers,
Yusuf


From slaskawi at redhat.com  Wed Jan  9 10:11:23 2019
From: slaskawi at redhat.com (Sebastian Laskawiec)
Date: Wed, 9 Jan 2019 16:11:23 +0100
Subject: [keycloak-dev] User TLS client certificate authentication -
 inconsistent DN string representation with LDAP
In-Reply-To: <6d2958f3-da03-bbc7-d37e-3c42bb76d188@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>
Message-ID: <CAA9R9O6KShp_SyXNe6usPg0mFY18_AsbytFkBQvC+m5AKRnzDg@mail.gmail.com>

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> 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 <
> 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>; sblanc at redhat.com
> > Cc: 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> 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> 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
> >> 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
> >
>
>
> --
> John Dennis
>

From jdennis at redhat.com  Wed Jan  9 10:43:41 2019
From: jdennis at redhat.com (John Dennis)
Date: Wed, 9 Jan 2019 10:43:41 -0500
Subject: [keycloak-dev] User TLS client certificate authentication -
 inconsistent DN string representation with LDAP
In-Reply-To: <CAA9R9O6KShp_SyXNe6usPg0mFY18_AsbytFkBQvC+m5AKRnzDg@mail.gmail.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>
Message-ID: <0d6257c6-6c6f-bdf7-8ec1-406a246fe0d4@redhat.com>

On 1/9/19 10:11 AM, Sebastian Laskawiec wrote:
> RFC?1779 (A String Representation of Distinguished Names) also mentions 

RFC 1779 is obsolete, please do not implement according to deprecated 
standards. See https://ldap.com/ldap-related-rfcs/

RFC 4514 is the current standard for the string representation of 
distinguished names.

I don't normally code in Java, but I'm sure there are multiple classes 
in standard jars which already implement DN parsing and comparison.

-- 
John Dennis

From pnalyvayko at agi.com  Wed Jan  9 21:18:59 2019
From: pnalyvayko at agi.com (Nalyvayko, Peter)
Date: Thu, 10 Jan 2019 02:18:59 +0000
Subject: [keycloak-dev] User TLS client certificate authentication -
 inconsistent DN string representation with LDAP
In-Reply-To: <CAA9R9O6KShp_SyXNe6usPg0mFY18_AsbytFkBQvC+m5AKRnzDg@mail.gmail.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>
Message-ID: <BL0PR07MB50091823826745DD5210B5FBDA840@BL0PR07MB5009.namprd07.prod.outlook.com>

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]
Sent: Wednesday, January 9, 2019 10:11 AM
To: John Dennis
Cc: Nalyvayko, Peter; Peck, Michael A; sblanc at redhat.com; 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>> 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> <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>>; sblanc at redhat.com<mailto:sblanc at redhat.com>
> Cc: 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>> 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>> 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>
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org<mailto:keycloak-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org<mailto:keycloak-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>


--
John Dennis


From sthorger at redhat.com  Fri Jan 11 04:17:54 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 11 Jan 2019 09:17:54 +0000
Subject: [keycloak-dev] Deputy for users
In-Reply-To: <329439FD-9846-4594-93F1-AC75C2798954@jcoder.de>
References: <b4c5f6151a4d4c4c808efb999685ed20@BOSKGEXC01.boskg.local>
	<F20A27A3-8989-4A23-B2F1-54FD8D9DE5CD@jcoder.de>
	<329439FD-9846-4594-93F1-AC75C2798954@jcoder.de>
Message-ID: <CAJgngAcZt+_c30Y6M+dAHuTuUh7VnZPteMXU1E-LMJ513_hNTQ@mail.gmail.com>

I believe this is the first time this feature has been requested and it
wouldn't be the most straightforward thing to implement. Do you have an
idea of the effort required to implement and how you would do it?

Is there anyone else out there interested in this capability? If not it may
be better to do this as an extension (or a completely separate app).

On Wed, 9 Jan 2019, 13:43 JCoder <info at jcoder.de wrote:

>
>
> Hello,
>
> I kindly ask to implement the deputy feature in keycloak.
>
> Example: Before a user leaves for vacation, for a dedicated period of
> time she can assign her groups to another user (the deputy).  The
> deputy then has access to that groups - but only for the specified
> period of time. Tough after the vacation the information about the
> deputy regulation will remain in the database and can only be
> explicitly deleted by the user.
>
> Validations:
> - The begin date for the deputy regulation is today or in the future
> - The end date for the deputy regulation is not before the begin date
> I'm excited about your opinion.
>
> Cheers,
> Yusuf
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sthorger at redhat.com  Fri Jan 11 04:18:35 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 11 Jan 2019 09:18:35 +0000
Subject: [keycloak-dev] Make theme properties available in email
	templates
In-Reply-To: <CACdt9SDjHrPyMXTFNRosb2dP6KtYKc_q0gkVFiwfTgbdeoZ8jQ@mail.gmail.com>
References: <CACdt9SD4B-ra6vHYTPFOJX7W6gNOHa_U2Hcf2nU3pRg4Lz7v+w@mail.gmail.com>
	<CAJgngAeZrT2MpbhDr4XeHHcjBHJn+GKEoCnDXCW1Nehksvht6g@mail.gmail.com>
	<CACdt9SDjHrPyMXTFNRosb2dP6KtYKc_q0gkVFiwfTgbdeoZ8jQ@mail.gmail.com>
Message-ID: <CAJgngAcZEaDAh1mzAtoBP_F7pFGK84cGFUT76jxY2f8k9jccPA@mail.gmail.com>

Yes, please create a Jira.

On Tue, 8 Jan 2019, 15:39 Guilhem Lucas <guilhem.lucas at actility.com wrote:

> Indeed, it's already available in login forms and I have implemented it
> the same way.
>
> Do I need to create a Jira issue before submitting a PR?
>
> Regards,
>
> Guilhem
>
> Le lun. 10 d?c. 2018 ? 11:02, Stian Thorgersen <sthorger at redhat.com> a
> ?crit :
>
>> If I remember correctly these are already available to the login forms,
>> so I have no issue with a PR for this as long as it's done consistently to
>> how it's done in login forms.
>>
>> On Fri, 7 Dec 2018 at 11:42, Guilhem Lucas <guilhem.lucas at actility.com>
>> wrote:
>>
>>> Hello,
>>>
>>> I need to have theme properties available in Freemarker email templates
>>> (like in login and account theme).
>>>
>>> I overrided FreeMarkerEmailTemplateProvider to add them in a new
>>> attribute
>>> "properties", but I think it could be useful to have it by default in
>>> Keycloak.
>>>
>>> Is it possible to do it? If necessary I can create a pull request.
>>>
>>> Thank you.
>>>
>>> Guilhem Lucas
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>
> --
>
>
> *Guilhem Lucas*R&D Software Engineer
>
> guilhem.lucas at actility.com
>
>
>
>

From thomas.darimont at googlemail.com  Fri Jan 11 09:15:11 2019
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Fri, 11 Jan 2019 15:15:11 +0100
Subject: [keycloak-dev] token_introspection_endpoint ==
	introspection_endpoint ? in .well-known/openid-configuration
Message-ID: <CAK-7U1jP-5s0M0Wrd4eiK7mS0x33ZGhhqtrHVwe+cwucKAPnxg@mail.gmail.com>

Hello,

I just noticed that the .well-known/openid-configuration contains 2 links
for the token_introspection_endpoint is this a bug?

Cheers,
Thomas

{
"issuer": "https://sso.example.com/auth/realms/master",
"authorization_endpoint": "
https://sso.example.com/auth/realms/master/protocol/openid-connect/auth",
"token_endpoint": "
https://sso.example.com/auth/realms/master/protocol/openid-connect/token",
* "token_introspection_endpoint": "
https://sso.example.com/auth/realms/master/protocol/openid-connect/token/introspect
",
"userinfo_endpoint": "
https://sso.example.com/auth/realms/master/protocol/openid-connect/userinfo
",
"end_session_endpoint": "
https://sso.example.com/auth/realms/master/protocol/openid-connect/logout",
"jwks_uri": "
https://sso.example.com/auth/realms/master/protocol/openid-connect/certs",
"check_session_iframe": "
https://sso.example.com/auth/realms/master/protocol/openid-connect/login-status-iframe.html
",
...
"tls_client_certificate_bound_access_tokens": true,
* "introspection_endpoint": "
https://sso.example.com/auth/realms/master/protocol/openid-connect/token/introspect
"
}

From sthorger at redhat.com  Mon Jan 14 02:44:14 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 14 Jan 2019 08:44:14 +0100
Subject: [keycloak-dev] token_introspection_endpoint ==
 introspection_endpoint ? in .well-known/openid-configuration
In-Reply-To: <CAK-7U1jP-5s0M0Wrd4eiK7mS0x33ZGhhqtrHVwe+cwucKAPnxg@mail.gmail.com>
References: <CAK-7U1jP-5s0M0Wrd4eiK7mS0x33ZGhhqtrHVwe+cwucKAPnxg@mail.gmail.com>
Message-ID: <CAJgngAeNakOaXAqct37K0bbF9hc-p5jWaDMhT2Zo2GDZqv2iOA@mail.gmail.com>

I'd say so. Token introspection endpoint is not listed in OpenID Connect
Discovery, but is in OAuth Discovery as introspection_endpoint [1]. So we
should remove token_introspection_endpoint.

[1] https://tools.ietf.org/html/draft-ietf-oauth-discovery-06

On Fri, 11 Jan 2019 at 15:24, Thomas Darimont <
thomas.darimont at googlemail.com> wrote:

> Hello,
>
> I just noticed that the .well-known/openid-configuration contains 2 links
> for the token_introspection_endpoint is this a bug?
>
> Cheers,
> Thomas
>
> {
> "issuer": "https://sso.example.com/auth/realms/master",
> "authorization_endpoint": "
> https://sso.example.com/auth/realms/master/protocol/openid-connect/auth",
> "token_endpoint": "
> https://sso.example.com/auth/realms/master/protocol/openid-connect/token",
> * "token_introspection_endpoint": "
>
> https://sso.example.com/auth/realms/master/protocol/openid-connect/token/introspect
> ",
> "userinfo_endpoint": "
> https://sso.example.com/auth/realms/master/protocol/openid-connect/userinfo
> ",
> "end_session_endpoint": "
> https://sso.example.com/auth/realms/master/protocol/openid-connect/logout
> ",
> "jwks_uri": "
> https://sso.example.com/auth/realms/master/protocol/openid-connect/certs",
> "check_session_iframe": "
>
> https://sso.example.com/auth/realms/master/protocol/openid-connect/login-status-iframe.html
> ",
> ...
> "tls_client_certificate_bound_access_tokens": true,
> * "introspection_endpoint": "
>
> https://sso.example.com/auth/realms/master/protocol/openid-connect/token/introspect
> "
> }
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sthorger at redhat.com  Mon Jan 14 02:45:11 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 14 Jan 2019 08:45:11 +0100
Subject: [keycloak-dev] [keycloak-gatekeeper][KEYCLOAK-7175] upgrade
	from coreos/go-oidc.v1
In-Reply-To: <1883555636.14874786.1546956889973@mail.yahoo.com>
References: <1883555636.14874786.1546956889973.ref@mail.yahoo.com>
	<1883555636.14874786.1546956889973@mail.yahoo.com>
Message-ID: <CAJgngAc8no6QXcr=YGWa9oe=rq9+3sYyZujqDq9x_yvag52LBQ@mail.gmail.com>

Bruno - can you reply to this please?

On Tue, 8 Jan 2019 at 15:19, BIDON Frederic <fredbi at yahoo.com> wrote:

>
> Relying on a stale package such as `github.com/coreos/go-oidc.v1`
> <http://github.com/coreos/go-oidc.v1> is really annoying for a security
> product.
>
> Moreover, this library has no support for tokens with an EC signature.
>
> I've tried a bit to remove this but I felt like the choice of a proper
> library should be discussed.
>
> Here is my two cents:
>
>    - coreos/go-oidc.v2 does not add much compared to stdlib `x/oauth2`:
> there is remote JWKS fetcher which might be useful, although this is in
> fact `square/go-jose` that does the heavy lifting here
>    - I found `square/go-jose` good enough for JWK and JWKS, but rather
> unpractical for JWT. I found `dgrijalva/jwt-go` much handier when it comes
> to manipulate JWT
>
> Any ideas / challenges around for a proper choice of dependencies here?
>
> Cheers,
>
> Fr?d?ric
>   frederic.bidon at yahoo.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From sthorger at redhat.com  Mon Jan 14 02:51:11 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 14 Jan 2019 08:51:11 +0100
Subject: [keycloak-dev] Defining several Password Policies within a Realm
In-Reply-To: <PR1PR01MB4939AE7E0BE3C820C1360755F68A0@PR1PR01MB4939.eurprd01.prod.exchangelabs.com>
References: <PR1PR01MB4939AE7E0BE3C820C1360755F68A0@PR1PR01MB4939.eurprd01.prod.exchangelabs.com>
Message-ID: <CAJgngAftS+U3kn1yr89LwaQK6BqoAydLGKY=LYTtO3Eja9q7DQ@mail.gmail.com>

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.

On Tue, 8 Jan 2019 at 09:37, AMIEL Patrice <Patrice.Amiel at gemalto.com>
wrote:

> Hi all,
>
> We are currently working on adding the capability to define several
> Password Policies for a given realm.
> The rationale is that in our systems, within a given realm, we have
> different "types" of accounts that have different constraints on password
> management. For instance:
>
> -          Administrators shall have long and complex passwords, with a
> very short password expiration time
>
> -          Regular users have a "normal" :P password strength, and medium
> expiration time
>
> -          Accounts for technical/automated access to the system shall
> never expire and have very long passwords
> All these Users shall be part of the same Realm.
> Obviously, these 3 types are only an example and there might be a need of
> more types or less types of accounts for other deployments => the number of
> Password Policies is not fixed in advance.
>
> We would definitely like to push the work as a PR, but before doing that,
> we'd like to be sure that we are going on the good tracks so that this PR
> could be accepted.
> The idea is consequently, from Web UI perspectives:
>
> -          To update the Password Policy pane so that we have first a list
> of what we could call "Password Policy Groups". Within this pane, an
> initial list would allow to list, create and edit the Password Policy
> Groups.
>
> -          When creating or editing one of the available Password Policy
> Groups, a sub pane would allow to select the individual Password Policies
> to be added to the Group.
>
> -          Then, on Users management section, a new drop-down field of the
> User edition page would enable to select the Password Policy Group to be
> applied to this specific User
>
> -          The Password Policy Group page might remain under the
> Authentication menu area... but it might also be eligible to be moved to a
> dedicated area similar to the current "Group" area (indeed, we would then
> have a "Roles Groups" area (this is indeed what the current "Group" area
> is) and a "Password Policy Groups" area...)
>
> Note that it would maybe be more convenient to attach a Password Policy
> Group to a "Group" rather than to an individual User, but as Users may
> belong to several Groups, then it would generate conflicts when applying
> the individual Password Policies if they are conflicting (for example, one
> saying that the min password length is 10 characters while the other saying
> it is 15).
>
> Impacts are:
>
> -          On the DB model and JPA classes to support a list of Password
> Policies (i.e. Password Policy Groups),
>
> -          On the User classes to support attachment of a User to a
> Password Policy Group
>
> -          On the GUI, as described above
>
> -          On the authentication process, to select the right Password
> Policy
>
> -          On the change password process, to select the right Password
> Policy
>
> -          On the REST API
>
> Does this proposal make sense to you (any concern or recommendation) ?
>
> Thanks for your feedbacks
>
> Best regards,
> Patrice
>
>
> ________________________________
> 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
>

From bruno at abstractj.org  Mon Jan 14 04:52:39 2019
From: bruno at abstractj.org (Bruno Oliveira)
Date: Mon, 14 Jan 2019 07:52:39 -0200
Subject: [keycloak-dev] [keycloak-gatekeeper][KEYCLOAK-7175] upgrade
 from coreos/go-oidc.v1
In-Reply-To: <CAJgngAc8no6QXcr=YGWa9oe=rq9+3sYyZujqDq9x_yvag52LBQ@mail.gmail.com>
References: <1883555636.14874786.1546956889973.ref@mail.yahoo.com>
	<1883555636.14874786.1546956889973@mail.yahoo.com>
	<CAJgngAc8no6QXcr=YGWa9oe=rq9+3sYyZujqDq9x_yvag52LBQ@mail.gmail.com>
Message-ID: <20190114095239.GA23688@abstractj.org>



On 2019-01-14, Stian Thorgersen wrote:
> Bruno - can you reply to this please?

Of course, we discussed this some time ago https://github.com/keycloak/keycloak-gatekeeper/pull/407#issuecomment-409207544. But just in case, it was missed, I'm adding some answers/questions inline.

> 
> On Tue, 8 Jan 2019 at 15:19, BIDON Frederic <fredbi at yahoo.com> wrote:
> 
> >
> > Relying on a stale package such as `github.com/coreos/go-oidc.v1`
> > <http://github.com/coreos/go-oidc.v1> is really annoying for a security
> > product.

Hi Frederic, I understand your concern, if you found some
security issue, please do not hesitate to send us an e-mail to
keycloak-security mailing list with all the details https://www.keycloak.org/security.html.

We had to remove all the forks from gambol99 repository and move to the official repositories. Do a full upgrade of dependencies would take a considerable time, due to the break of API compatibility.

That's the reason why we decided to postpone it. 

> >
> > Moreover, this library has no support for tokens with an EC signature.

You are correct, that's our plan to upgrade all the dependencies soon.

> >
> > I've tried a bit to remove this but I felt like the choice of a proper
> > library should be discussed.
> >
> > Here is my two cents:
> >
> >    - coreos/go-oidc.v2 does not add much compared to stdlib `x/oauth2`:
> > there is remote JWKS fetcher which might be useful, although this is in
> > fact `square/go-jose` that does the heavy lifting here
> >    - I found `square/go-jose` good enough for JWK and JWKS, but rather
> > unpractical for JWT. I found `dgrijalva/jwt-go` much handier when it comes
> > to manipulate JWT

Could you please elaborate more on why do you think it's unpractical?

> >
> > Any ideas / challenges around for a proper choice of dependencies here?

The initial idea is to upgrade the following dependencies:

* From coreos/go-oidc/oauth2 to golang/x/oauth2
* From coreos/go-oidc/jose to square/go-jose
* From coreos/go-oidc/oidc to coreos/go-oidc (v2)

Also, the work on this was not started yet, so absolutely nothing is set in stone.

> >
> > Cheers,
> >
> > Fr?d?ric
> >   frederic.bidon at yahoo.com
> > _______________________________________________
> > 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 psilva at redhat.com  Mon Jan 14 06:29:03 2019
From: psilva at redhat.com (Pedro Igor Silva)
Date: Mon, 14 Jan 2019 09:29:03 -0200
Subject: [keycloak-dev] token_introspection_endpoint ==
 introspection_endpoint ? in .well-known/openid-configuration
In-Reply-To: <CAJgngAeNakOaXAqct37K0bbF9hc-p5jWaDMhT2Zo2GDZqv2iOA@mail.gmail.com>
References: <CAK-7U1jP-5s0M0Wrd4eiK7mS0x33ZGhhqtrHVwe+cwucKAPnxg@mail.gmail.com>
	<CAJgngAeNakOaXAqct37K0bbF9hc-p5jWaDMhT2Zo2GDZqv2iOA@mail.gmail.com>
Message-ID: <CAJrcDBcYiARGeaVyF=cXcEPUfYUEUVYVV9-Nckvkxc1JriCSwA@mail.gmail.com>

introspection_endpoint was added to align with specs. While the
token_introspection_endpoint was kept to keep backward compatibility. We
should consider removing it in the future.

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

On Mon, Jan 14, 2019 at 5:47 AM Stian Thorgersen <sthorger at redhat.com>
wrote:

> I'd say so. Token introspection endpoint is not listed in OpenID Connect
> Discovery, but is in OAuth Discovery as introspection_endpoint [1]. So we
> should remove token_introspection_endpoint.
>
> [1] https://tools.ietf.org/html/draft-ietf-oauth-discovery-06
>
> On Fri, 11 Jan 2019 at 15:24, Thomas Darimont <
> thomas.darimont at googlemail.com> wrote:
>
> > Hello,
> >
> > I just noticed that the .well-known/openid-configuration contains 2 links
> > for the token_introspection_endpoint is this a bug?
> >
> > Cheers,
> > Thomas
> >
> > {
> > "issuer": "https://sso.example.com/auth/realms/master",
> > "authorization_endpoint": "
> > https://sso.example.com/auth/realms/master/protocol/openid-connect/auth
> ",
> > "token_endpoint": "
> > https://sso.example.com/auth/realms/master/protocol/openid-connect/token
> ",
> > * "token_introspection_endpoint": "
> >
> >
> https://sso.example.com/auth/realms/master/protocol/openid-connect/token/introspect
> > ",
> > "userinfo_endpoint": "
> >
> https://sso.example.com/auth/realms/master/protocol/openid-connect/userinfo
> > ",
> > "end_session_endpoint": "
> >
> https://sso.example.com/auth/realms/master/protocol/openid-connect/logout
> > ",
> > "jwks_uri": "
> > https://sso.example.com/auth/realms/master/protocol/openid-connect/certs
> ",
> > "check_session_iframe": "
> >
> >
> https://sso.example.com/auth/realms/master/protocol/openid-connect/login-status-iframe.html
> > ",
> > ...
> > "tls_client_certificate_bound_access_tokens": true,
> > * "introspection_endpoint": "
> >
> >
> https://sso.example.com/auth/realms/master/protocol/openid-connect/token/introspect
> > "
> > }
> > _______________________________________________
> > 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 felix.meissner at hanko.io  Mon Jan 14 06:46:04 2019
From: felix.meissner at hanko.io (=?UTF-8?Q?Felix_Mei=C3=9Fner?=)
Date: Mon, 14 Jan 2019 12:46:04 +0100
Subject: [keycloak-dev] Transaction approval via OpenID Connect User
	Questioning API
Message-ID: <CAC6ftk2oWfMtbOcj4Nx727j9wCd41sRFUxGxmh6LNFgfDGkLYw@mail.gmail.com>

Hi everyone,

recently, I have been investigating how to integrate transaction approval
in an OpenID Connect based environment.

It seems to me, the OpenID Connect User Questioning API is the perfect
match, but as far as I can see, Keycloak is currently not implementing this
API, right? Also, I cannot fond any issue at JBoss regarding this feature.

Are there any reasons to not implement the User Questioning API in
Keycloak, or has there just not yet been a feature request / someone
willing to implement this? Or are there any other ways to aquire the user's
consent via Keycloak?

At Hanko, we are developing a Keycloak plugin that allows to use FIDO2 as
well as UAF and U2F devices as second or multi-factor authentication
devices in Keycloak with help of our API. Now, we are looking for a way to
integrate signed transactions based on FIDO in Keycloak.

Thank you for your comments!

Viele Gr??e / Best regards
Felix Mei?ner

Hanko.io ? Convenient and Secure Authentication

Hanko GmbH
Ringstr. 19 | 24114 Kiel | Germany

Email: felix.meissner at hanko.io
Phone: +49 431 908 929 25

From james.p.campbell at gmail.com  Mon Jan 14 21:40:18 2019
From: james.p.campbell at gmail.com (James Campbell)
Date: Mon, 14 Jan 2019 21:40:18 -0500
Subject: [keycloak-dev] OIDC Discovery-enabled IdentityProvider
Message-ID: <00aa01d4ac7b$a7767460$f6635d20$@gmail.com>

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

 

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


From alex.chatziparaskewas at trapezegroup.com  Tue Jan 15 05:31:14 2019
From: alex.chatziparaskewas at trapezegroup.com (Alex Chatziparaskewas)
Date: Tue, 15 Jan 2019 10:31:14 +0000
Subject: [keycloak-dev] Session Expiry & Remember Me
Message-ID: <3579c14b49c34e5692cb8b866c577d08@VOL-SLO-EXCH3.vgnet.volgrp.com>

Hi All,

I am trying to get the remember me functionality running having the problem that my sessions are expired by keycloak - in my eyes - prematurely. I started digging through keycloak code and stumbled over the following:

class UserSessionPredicate, method 'test':

        ...    
        if (entity.isRememberMe()) {
            if (expiredRememberMe != null && expiredRefreshRememberMe != null && entity.getStarted() > ###expiredRefreshRememberMe### && entity.getLastSessionRefresh() > expiredRefreshRememberMe) {
                return false;
            }
        }
        else {
            if (expired != null && expiredRefresh != null && entity.getStarted() > expired && entity.getLastSessionRefresh() > expiredRefresh) {
                return false;
            }
        }
        ...    

The marked (###) 'expiredRefreshRememberMe' in the second if statement, should that not be 'expiredRememberMe'?

Thanks & Regards,
Alex





From hmlnarik at redhat.com  Tue Jan 15 05:59:33 2019
From: hmlnarik at redhat.com (Hynek Mlnarik)
Date: Tue, 15 Jan 2019 11:59:33 +0100
Subject: [keycloak-dev] User TLS client certificate authentication -
 inconsistent DN string representation with LDAP
In-Reply-To: <BL0PR07MB50091823826745DD5210B5FBDA840@BL0PR07MB5009.namprd07.prod.outlook.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>
Message-ID: <CAMvXD=HdLyzPhNMV0vzg2Bm9iJFNSB0r0rqFzeTJjUk+GGPreg@mail.gmail.com>

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> 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]
> Sent: Wednesday, January 9, 2019 10:11 AM
> To: John Dennis
> Cc: Nalyvayko, Peter; Peck, Michael A; sblanc at redhat.com;
> 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>> 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> <
> 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>>;
> sblanc at redhat.com<mailto:sblanc at redhat.com>
> > Cc: 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>>
> 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>> 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>
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org<mailto:keycloak-dev at lists.jboss.org>
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org<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
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sguilhen at redhat.com  Tue Jan 15 07:22:26 2019
From: sguilhen at redhat.com (Stefan Guilhen)
Date: Tue, 15 Jan 2019 10:22:26 -0200
Subject: [keycloak-dev] Session Expiry & Remember Me
In-Reply-To: <3579c14b49c34e5692cb8b866c577d08@VOL-SLO-EXCH3.vgnet.volgrp.com>
References: <3579c14b49c34e5692cb8b866c577d08@VOL-SLO-EXCH3.vgnet.volgrp.com>
Message-ID: <CA+7ohfkzj4eYy75Hto1SE+d5dMSua_9NroR3NswGKFjAfEk_8g@mail.gmail.com>

Yes, you are absolutely right, that expression should be using the
expiredRememberMe value in that spot. I'll work on the fix.

Best regards,
Stefan

On Tue, Jan 15, 2019 at 8:33 AM Alex Chatziparaskewas <
alex.chatziparaskewas at trapezegroup.com> wrote:

> Hi All,
>
> I am trying to get the remember me functionality running having the
> problem that my sessions are expired by keycloak - in my eyes -
> prematurely. I started digging through keycloak code and stumbled over the
> following:
>
> class UserSessionPredicate, method 'test':
>
>         ...
>         if (entity.isRememberMe()) {
>             if (expiredRememberMe != null && expiredRefreshRememberMe !=
> null && entity.getStarted() > ###expiredRefreshRememberMe### &&
> entity.getLastSessionRefresh() > expiredRefreshRememberMe) {
>                 return false;
>             }
>         }
>         else {
>             if (expired != null && expiredRefresh != null &&
> entity.getStarted() > expired && entity.getLastSessionRefresh() >
> expiredRefresh) {
>                 return false;
>             }
>         }
>         ...
>
> The marked (###) 'expiredRefreshRememberMe' in the second if statement,
> should that not be 'expiredRememberMe'?
>
> Thanks & Regards,
> Alex
>
>
>
>
> _______________________________________________
> 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 tkyjovsk at redhat.com  Tue Jan 15 09:25:53 2019
From: tkyjovsk at redhat.com (Tomas Kyjovsky)
Date: Tue, 15 Jan 2019 09:25:53 -0500 (EST)
Subject: [keycloak-dev] OIDC Discovery-enabled IdentityProvider
In-Reply-To: <00aa01d4ac7b$a7767460$f6635d20$@gmail.com>
References: <00aa01d4ac7b$a7767460$f6635d20$@gmail.com>
Message-ID: <1914838141.50603473.1547562353763.JavaMail.zimbra@redhat.com>

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

From alex.chatziparaskewas at trapezegroup.com  Tue Jan 15 09:38:47 2019
From: alex.chatziparaskewas at trapezegroup.com (Alex Chatziparaskewas)
Date: Tue, 15 Jan 2019 14:38:47 +0000
Subject: [keycloak-dev] Session Expiry & Remember Me
In-Reply-To: <CA+7ohfkzj4eYy75Hto1SE+d5dMSua_9NroR3NswGKFjAfEk_8g@mail.gmail.com>
References: <3579c14b49c34e5692cb8b866c577d08@VOL-SLO-EXCH3.vgnet.volgrp.com>
	<CA+7ohfkzj4eYy75Hto1SE+d5dMSua_9NroR3NswGKFjAfEk_8g@mail.gmail.com>
Message-ID: <9b13d2b8f8914f22a58b38c21ff37982@VOL-SLO-EXCH3.vgnet.volgrp.com>

Many thanks!

From: Stefan Guilhen [mailto:sguilhen at redhat.com]
Sent: 15 January 2019 13:22
To: Alex Chatziparaskewas <alex.chatziparaskewas at trapezegroup.com>
Cc: keycloak-dev at lists.jboss.org
Subject: Re: [keycloak-dev] Session Expiry & Remember Me

Yes, you are absolutely right, that expression should be using the expiredRememberMe value in that spot. I'll work on the fix.

Best regards,
Stefan

On Tue, Jan 15, 2019 at 8:33 AM Alex Chatziparaskewas <alex.chatziparaskewas at trapezegroup.com<mailto:alex.chatziparaskewas at trapezegroup.com>> wrote:
Hi All,

I am trying to get the remember me functionality running having the problem that my sessions are expired by keycloak - in my eyes - prematurely. I started digging through keycloak code and stumbled over the following:

class UserSessionPredicate, method 'test':

        ...
        if (entity.isRememberMe()) {
            if (expiredRememberMe != null && expiredRefreshRememberMe != null && entity.getStarted() > ###expiredRefreshRememberMe### && entity.getLastSessionRefresh() > expiredRefreshRememberMe) {
                return false;
            }
        }
        else {
            if (expired != null && expiredRefresh != null && entity.getStarted() > expired && entity.getLastSessionRefresh() > expiredRefresh) {
                return false;
            }
        }
        ...

The marked (###) 'expiredRefreshRememberMe' in the second if statement, should that not be 'expiredRememberMe'?

Thanks & Regards,
Alex




_______________________________________________
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://www.redhat.com/files/brand/email/sig-redhat.png]<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 tkyjovsk at redhat.com  Tue Jan 15 10:31:41 2019
From: tkyjovsk at redhat.com (Tomas Kyjovsky)
Date: Tue, 15 Jan 2019 10:31:41 -0500 (EST)
Subject: [keycloak-dev] OIDC Discovery-enabled IdentityProvider
In-Reply-To: <1914838141.50603473.1547562353763.JavaMail.zimbra@redhat.com>
References: <00aa01d4ac7b$a7767460$f6635d20$@gmail.com>
	<1914838141.50603473.1547562353763.JavaMail.zimbra@redhat.com>
Message-ID: <38415268.50625497.1547566301029.JavaMail.zimbra@redhat.com>

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
> 

From james.p.campbell at gmail.com  Tue Jan 15 11:39:17 2019
From: james.p.campbell at gmail.com (James Campbell)
Date: Tue, 15 Jan 2019 11:39:17 -0500
Subject: [keycloak-dev] OIDC Discovery-enabled IdentityProvider
In-Reply-To: <38415268.50625497.1547566301029.JavaMail.zimbra@redhat.com>
References: <00aa01d4ac7b$a7767460$f6635d20$@gmail.com>
	<1914838141.50603473.1547562353763.JavaMail.zimbra@redhat.com>
	<38415268.50625497.1547566301029.JavaMail.zimbra@redhat.com>
Message-ID: <CA+AQu3yKjkTU2XCaiE1-xbfyn3idiswk5OWSsLxNnZRKsMFJWA@mail.gmail.com>

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

From sthorger at redhat.com  Wed Jan 16 01:52:05 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 16 Jan 2019 07:52:05 +0100
Subject: [keycloak-dev] OIDC Discovery-enabled IdentityProvider
In-Reply-To: <CA+AQu3yKjkTU2XCaiE1-xbfyn3idiswk5OWSsLxNnZRKsMFJWA@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>
Message-ID: <CAJgngAccFbcFOE4Dt4v=R-WXky9mdmGPZqzDvwi3AthrBLOjvQ@mail.gmail.com>

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
>

From sthorger at redhat.com  Wed Jan 16 01:58:10 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 16 Jan 2019 07:58:10 +0100
Subject: [keycloak-dev] Transaction approval via OpenID Connect User
 Questioning API
In-Reply-To: <CAC6ftk2oWfMtbOcj4Nx727j9wCd41sRFUxGxmh6LNFgfDGkLYw@mail.gmail.com>
References: <CAC6ftk2oWfMtbOcj4Nx727j9wCd41sRFUxGxmh6LNFgfDGkLYw@mail.gmail.com>
Message-ID: <CAJgngAdZw28R6L+wyDqstQw7whwhFDFFV=-j6oTTseBRvyFw5g@mail.gmail.com>

Looks quite interesting and useful. Haven't seen much request for it though.

Doesn't look like it would be to much effort to implement, nor to much
burden to maintain. Have you considered how this could be implemented in
Keycloak?

On Mon, 14 Jan 2019 at 12:49, Felix Mei?ner <felix.meissner at hanko.io> wrote:

> Hi everyone,
>
> recently, I have been investigating how to integrate transaction approval
> in an OpenID Connect based environment.
>
> It seems to me, the OpenID Connect User Questioning API is the perfect
> match, but as far as I can see, Keycloak is currently not implementing this
> API, right? Also, I cannot fond any issue at JBoss regarding this feature.
>
> Are there any reasons to not implement the User Questioning API in
> Keycloak, or has there just not yet been a feature request / someone
> willing to implement this? Or are there any other ways to aquire the user's
> consent via Keycloak?
>
> At Hanko, we are developing a Keycloak plugin that allows to use FIDO2 as
> well as UAF and U2F devices as second or multi-factor authentication
> devices in Keycloak with help of our API. Now, we are looking for a way to
> integrate signed transactions based on FIDO in Keycloak.
>
> Thank you for your comments!
>
> Viele Gr??e / Best regards
> Felix Mei?ner
>
> Hanko.io ? Convenient and Secure Authentication
>
> Hanko GmbH
> Ringstr. 19 | 24114 Kiel | Germany
>
> Email: felix.meissner at hanko.io
> Phone: +49 431 908 929 25
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From takashi.norimatsu.ws at hitachi.com  Wed Jan 16 03:01:51 2019
From: takashi.norimatsu.ws at hitachi.com (=?iso-2022-jp?B?GyRCPmg+Pk40O1YbKEIgLyBOT1JJTUFUU1UbJEIhJBsoQlRBS0FTSEk=?=)
Date: Wed, 16 Jan 2019 08:01:51 +0000
Subject: [keycloak-dev] Multiple user login on the same browser for Account
 Aggregation application
Message-ID: <OSBPR01MB397452F5DE52AB2FE04D96CCCE820@OSBPR01MB3974.jpnprd01.prod.outlook.com>

Hello,

I've used keycloak for such the client application that collect a user's information via API provided by a resource server (e.g. collect balance from bank?s API).

If the user has multiple accounts in the resource server, the client application must collect information on all these accounts. In order to do this, the client application let the user conduct an authentication and authorization flow for each account on the same browser consecutively.


The current keycloak implementation cannot allow a user to login multiple accounts consecutively and simultaneously on the same browser. Therefore, the user must terminate and restart the browser every time she or he login on one of his or him accounts, which is not good for UX perspective. I?ve opened JIRA (https://issues.jboss.org/browse/KEYCLOAK-9332).

I have an idea to resolve it and contribute its realization hopefully. However, I'm not sure this idea is appropriate or not. So, I am happy to get some suggestions and advices on it.

[Idea]
The current (keycloak-4.8.2.Final) keycloak's implementation seems to be as follows:
RootAuthenticationSessionModel class instance has several AuthenticationSessionModel class instances.
Browser is bounded to RootAuthenticationSessionModel by AUTH_SESSION_ID Cookie and realm.
AuthenticationSessionModel is bounded to Browser's tab by RootAuthenticationSessionModel, client id, and tab id.

It seems that keycloak allows a user on the same browser to login on the same account for several clients per browser's tab, and it is good for Web SSO use case. However, it does not work good for Account Aggregation use case.

My proposal is that suppressing (expiring explicitly) AUTH_SESSION_ID Cookie and its related Cookies on the client side (not the server side) at the end of an authentication and authorization flow make the browser new to logging-in onto keycloak every time. Also, adding a switch to change the operation mode from the ordinal Web SSO mode to the proposed one (like Securing API mode).

Best Regards
Takashi Norimatsu
Hitachi, Ltd.


From felix.meissner at hanko.io  Wed Jan 16 04:30:40 2019
From: felix.meissner at hanko.io (=?UTF-8?Q?Felix_Mei=C3=9Fner?=)
Date: Wed, 16 Jan 2019 10:30:40 +0100
Subject: [keycloak-dev] Transaction approval via OpenID Connect User
 Questioning API
In-Reply-To: <CAJgngAdZw28R6L+wyDqstQw7whwhFDFFV=-j6oTTseBRvyFw5g@mail.gmail.com>
References: <CAC6ftk2oWfMtbOcj4Nx727j9wCd41sRFUxGxmh6LNFgfDGkLYw@mail.gmail.com>
	<CAJgngAdZw28R6L+wyDqstQw7whwhFDFFV=-j6oTTseBRvyFw5g@mail.gmail.com>
Message-ID: <CAC6ftk08-dPvaNKEr_0imYPcBd7oagADCPrBk2M7bT+f+WKMBw@mail.gmail.com>

Hi Stian,

thanks for your feedback. Nice to hear that you consider the User
Questioning API a fitting feature for Keycloak.

For now, we will implement this feature as a plugin to get a working proof
of concept. We would be happy to contribute any common code to Keycloak.

Intuitively, I would start implementing the endpoints as a REST Resource.
To allow for different methods of questioning (via a screen displayed by
Keycloak or via our API) we would have to extract a common interface, I
think.

Viele Gr??e / Best regards
Felix Mei?ner

Hanko.io ? Convenient and Secure Authentication

Hanko GmbH
Ringstr. 19 | 24114 Kiel | Germany

Email: felix.meissner at hanko.io
Phone: +49 431 908 929 25


Am Mi., 16. Jan. 2019 um 07:58 Uhr schrieb Stian Thorgersen <
sthorger at redhat.com>:

> Looks quite interesting and useful. Haven't seen much request for it
> though.
>
> Doesn't look like it would be to much effort to implement, nor to much
> burden to maintain. Have you considered how this could be implemented in
> Keycloak?
>
> On Mon, 14 Jan 2019 at 12:49, Felix Mei?ner <felix.meissner at hanko.io>
> wrote:
>
>> Hi everyone,
>>
>> recently, I have been investigating how to integrate transaction approval
>> in an OpenID Connect based environment.
>>
>> It seems to me, the OpenID Connect User Questioning API is the perfect
>> match, but as far as I can see, Keycloak is currently not implementing
>> this
>> API, right? Also, I cannot fond any issue at JBoss regarding this feature.
>>
>> Are there any reasons to not implement the User Questioning API in
>> Keycloak, or has there just not yet been a feature request / someone
>> willing to implement this? Or are there any other ways to aquire the
>> user's
>> consent via Keycloak?
>>
>> At Hanko, we are developing a Keycloak plugin that allows to use FIDO2 as
>> well as UAF and U2F devices as second or multi-factor authentication
>> devices in Keycloak with help of our API. Now, we are looking for a way to
>> integrate signed transactions based on FIDO in Keycloak.
>>
>> Thank you for your comments!
>>
>> Viele Gr??e / Best regards
>> Felix Mei?ner
>>
>> Hanko.io ? Convenient and Secure Authentication
>>
>> Hanko GmbH
>> Ringstr. 19 | 24114 Kiel | Germany
>>
>> Email: felix.meissner at hanko.io
>> Phone: +49 431 908 929 25
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>

From gvincent at redhat.com  Wed Jan 16 09:53:14 2019
From: gvincent at redhat.com (Guillaume Vincent)
Date: Wed, 16 Jan 2019 15:53:14 +0100
Subject: [keycloak-dev] Javascript adapater tests
Message-ID: <CAJbDe2tVnSd7WXSMjU-nXPvmkmevo0HObDUB7QAePbVfrLLMPw@mail.gmail.com>

Hello Keycloak dev list,

in a previous post I raised the problem that the JavaScript adapter did not
have JavaScript tests.

In a couple of hours I created a simple example for Keycloak with unit and
functional tests https://github.com/guillaumevincent/keycloak-lite

You can see tests in this file
https://github.com/guillaumevincent/keycloak-lite/blob/master/test.js

I also created a blog post on IMO How to test JavaScript code:
https://guillaumevincent.com/2019/01/15/test-in-javascript.html

Maybe we can open the discussion on how keycloak.js should be tested.
Without any fast and automated tests, in JavaScript, the refactor of the
keycloak adapter will not be easy at all.

wdyt?

-- 
Guillaume Vincent
Senior Software Engineer

From Patrice.Amiel at gemalto.com  Wed Jan 16 11:00:41 2019
From: Patrice.Amiel at gemalto.com (AMIEL Patrice)
Date: Wed, 16 Jan 2019 16:00:41 +0000
Subject: [keycloak-dev] Defining several Password Policies within a Realm
In-Reply-To: <CAJgngAftS+U3kn1yr89LwaQK6BqoAydLGKY=LYTtO3Eja9q7DQ@mail.gmail.com>
References: <PR1PR01MB4939AE7E0BE3C820C1360755F68A0@PR1PR01MB4939.eurprd01.prod.exchangelabs.com>
	<CAJgngAftS+U3kn1yr89LwaQK6BqoAydLGKY=LYTtO3Eja9q7DQ@mail.gmail.com>
Message-ID: <PR1PR01MB49396153A2F07E00B26E0A44F6820@PR1PR01MB4939.eurprd01.prod.exchangelabs.com>

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.

From ssilvert at redhat.com  Wed Jan 16 11:18:11 2019
From: ssilvert at redhat.com (Stan Silvert)
Date: Wed, 16 Jan 2019 11:18:11 -0500
Subject: [keycloak-dev] Javascript adapater tests
In-Reply-To: <CAJbDe2tVnSd7WXSMjU-nXPvmkmevo0HObDUB7QAePbVfrLLMPw@mail.gmail.com>
References: <CAJbDe2tVnSd7WXSMjU-nXPvmkmevo0HObDUB7QAePbVfrLLMPw@mail.gmail.com>
Message-ID: <c5ea80a7-4ca8-5a68-ab71-c30241634920@redhat.com>

On 1/16/2019 9:53 AM, Guillaume Vincent wrote:
> Hello Keycloak dev list,
>
> in a previous post I raised the problem that the JavaScript adapter did not
> have JavaScript tests.
>
> In a couple of hours I created a simple example for Keycloak with unit and
> functional tests https://github.com/guillaumevincent/keycloak-lite
>
> You can see tests in this file
> https://github.com/guillaumevincent/keycloak-lite/blob/master/test.js
>
> I also created a blog post on IMO How to test JavaScript code:
> https://guillaumevincent.com/2019/01/15/test-in-javascript.html
>
> Maybe we can open the discussion on how keycloak.js should be tested.
> Without any fast and automated tests, in JavaScript, the refactor of the
> keycloak adapter will not be easy at all.
>
> wdyt?
Several thoughts:

  * Basically, I agree.? It makes sense to test javascript with
    javascript.? I like where you are going with this.
  * An important point in any discussion of testing is that the only
    useful test is a test that uncovers a bug.? We never write tests
    just to say we have lots of tests.? Coverage is what matters.? I'm
    not criticizing your blog.? It's just something I like to keep in mind.
  * You mention TypeScript in your blog, but test.js appears to be
    written in plain javascript.? IMO, any javascript we write (with the
    possible exception of keycloak.js) should be written in TypeScript.?
    Both internally and externally, developers are moving more and more
    to TypeScript.? Also, the Java developers on our team will be much
    more comfortable and confident with a strongly typed language that
    works well with an IDE.
  * We need to know a little more about the current test coverage of the
    javascript adapter.? Much of it is tested through indirect means.
  * We need to understand how javascript tests will integrate into our
    builds.
  * We need to standardize on a javascript test package.? I don't want
    the adapter to be tested with one library while the new account
    management console is tested with another.




From gideonray at gmail.com  Wed Jan 16 11:33:43 2019
From: gideonray at gmail.com (Gideon Caranzo)
Date: Wed, 16 Jan 2019 10:33:43 -0600
Subject: [keycloak-dev] passing SAML extensions and context to custom
	authenticators
Message-ID: <CAFTOGtd-ReFnVXf8v_0N8RxzUx-mXx+H=D_7FJP97PyxHy2Chw@mail.gmail.com>

Hi All,

I'd like to propose a feature that allows custom authenticators to handle
SAML extensions, authentication context and other request attributes.

Right now in OIDC, all request claims are passed to custom authenticators
which allows for customized behavior depending on the claims.
However, this is not the case for SAML. Only attributes that are explicitly
set (e.g. NameID) in the auth session are passed to custom authenticators.

Information like SAML extension and authentication context are not
available which limits the ability to define custom behaviors. In the past,
we ran into similar limitation and we had to update keycloak core to add
support for NameID attribute.

To solve this, we can have an optional hook that pre-process SAML login
request right before authentication. The hook can then extract the needed
attributes and set it accordingly for custom authenticators to process.

The pre-processing will be done in
*SamlService.BindingProtocol.loginRequest()*:

*public* *class* SamlService *extends* AuthorizationEndpointBase {

    *. . .*

    *public* *abstract* *class* BindingProtocol {

        . . .

        *protected* Response loginRequest(String relayState,
AuthnRequestType requestAbstractType, ClientModel client) {

            . . .

            SamlAuthenticationPreprocessor preProcessor = session
.getProvider(SamlAuthenticationPreprocessor.*class*);

            *if* (preProcessor != *null*) {

              preProcessor.process(requestAbstractType, authSession);

            }



            *return* newBrowserAuthentication(authSession,
requestAbstractType.isIsPassive(), redirectToAuthentication);

       }


Let me know what you think. Thanks.

Best regards,
Gideon

From youssef.elhouti at gmail.com  Wed Jan 16 12:33:25 2019
From: youssef.elhouti at gmail.com (Youssef EL HOUTI)
Date: Wed, 16 Jan 2019 18:33:25 +0100
Subject: [keycloak-dev] Impersonation extention
Message-ID: <CAMZkV7w9nd+sdGXb+YONM+4BeDk=d2bDgQzURn0hpSWo6vo2SA@mail.gmail.com>

Hey guys,

Just so you know, I have been working on extension that would allow a user
with impersonation role to retrieve and access/refresh token for another
user. (instead of the builtin behavior that uses cookies). you can find it
here: https://github.com/elhoutico/keycloak-impersonation

May be it could be added to the list of extensions:
https://www.keycloak.org/extensions.html

Cheers

From gvincent at redhat.com  Wed Jan 16 12:58:33 2019
From: gvincent at redhat.com (Guillaume Vincent)
Date: Wed, 16 Jan 2019 18:58:33 +0100
Subject: [keycloak-dev] Javascript adapater tests
In-Reply-To: <c5ea80a7-4ca8-5a68-ab71-c30241634920@redhat.com>
References: <CAJbDe2tVnSd7WXSMjU-nXPvmkmevo0HObDUB7QAePbVfrLLMPw@mail.gmail.com>
	<c5ea80a7-4ca8-5a68-ab71-c30241634920@redhat.com>
Message-ID: <CAJbDe2uXJuEKkJaDOBLbRozZz4md46vHNFiEVYokitj=70GfVw@mail.gmail.com>

> Coverage is what matters.

I like to tests features and add regression tests for each bugs.
Coverage is not a good metric, you can call your function with no
assertion, you will have 100% code coverage.
But I think we are agree that every function in the adapter (init(),
login() refreshToken(), etc) should be tested.

> should be written in TypeScript.

Totally agree, as I said I created the experience in a couple of hours.
But yes JS adapter should be written in typescript

I see 2 strategies to implement tests and upgrade the JS adapter:

 1/ write a new lib in Typescript near the old one, add some tests for
every function and test new and old implementation together with automated
tests.
 2/ split actual code (each method in a file for example) set up a blunder
to build the js adapter and then add unit and functional tests one by one
for every function. Then migrate code to Typescript

I can try a POC on the first one if you want




On Wed, Jan 16, 2019 at 5:43 PM Stan Silvert <ssilvert at redhat.com> wrote:

> On 1/16/2019 9:53 AM, Guillaume Vincent wrote:
> > Hello Keycloak dev list,
> >
> > in a previous post I raised the problem that the JavaScript adapter did
> not
> > have JavaScript tests.
> >
> > In a couple of hours I created a simple example for Keycloak with unit
> and
> > functional tests https://github.com/guillaumevincent/keycloak-lite
> >
> > You can see tests in this file
> > https://github.com/guillaumevincent/keycloak-lite/blob/master/test.js
> >
> > I also created a blog post on IMO How to test JavaScript code:
> > https://guillaumevincent.com/2019/01/15/test-in-javascript.html
> >
> > Maybe we can open the discussion on how keycloak.js should be tested.
> > Without any fast and automated tests, in JavaScript, the refactor of the
> > keycloak adapter will not be easy at all.
> >
> > wdyt?
> Several thoughts:
>
>   * Basically, I agree.  It makes sense to test javascript with
>     javascript.  I like where you are going with this.
>   * An important point in any discussion of testing is that the only
>     useful test is a test that uncovers a bug.  We never write tests
>     just to say we have lots of tests.  Coverage is what matters.  I'm
>     not criticizing your blog.  It's just something I like to keep in mind.
>   * You mention TypeScript in your blog, but test.js appears to be
>     written in plain javascript.  IMO, any javascript we write (with the
>     possible exception of keycloak.js) should be written in TypeScript.
>     Both internally and externally, developers are moving more and more
>     to TypeScript.  Also, the Java developers on our team will be much
>     more comfortable and confident with a strongly typed language that
>     works well with an IDE.
>   * We need to know a little more about the current test coverage of the
>     javascript adapter.  Much of it is tested through indirect means.
>   * We need to understand how javascript tests will integrate into our
>     builds.
>   * We need to standardize on a javascript test package.  I don't want
>     the adapter to be tested with one library while the new account
>     management console is tested with another.
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



-- 
Guillaume Vincent
Senior Software Engineer

From ssilvert at redhat.com  Wed Jan 16 14:22:38 2019
From: ssilvert at redhat.com (Stan Silvert)
Date: Wed, 16 Jan 2019 14:22:38 -0500
Subject: [keycloak-dev] Javascript adapater tests
In-Reply-To: <CAJbDe2uXJuEKkJaDOBLbRozZz4md46vHNFiEVYokitj=70GfVw@mail.gmail.com>
References: <CAJbDe2tVnSd7WXSMjU-nXPvmkmevo0HObDUB7QAePbVfrLLMPw@mail.gmail.com>
	<c5ea80a7-4ca8-5a68-ab71-c30241634920@redhat.com>
	<CAJbDe2uXJuEKkJaDOBLbRozZz4md46vHNFiEVYokitj=70GfVw@mail.gmail.com>
Message-ID: <276bdeda-3745-7350-41ee-9bc6f0cb7359@redhat.com>

On 1/16/2019 12:58 PM, Guillaume Vincent wrote:
> > Coverage is what matters.
>
> I like to tests features and add regression tests for each bugs.
> Coverage is not a good metric, you can call your function with no 
> assertion, you will have 100% code coverage.
> But I think we are agree that every function in the adapter (init(), 
> login() refreshToken(), etc) should be tested.
Yeah, I'm not talking about code coverage or path coverage.? I'm talking 
about coverage in a broader sense, as in, "the test suite covers 
everything the system is designed to do".
>
> > should be written in TypeScript.
>
> Totally agree, as I said I created the experience in a couple of hours.
> But yes JS adapter should be written in typescript
>
> I see 2 strategies to implement tests and upgrade the JS adapter:
>
> ?1/ write a new lib in Typescript near the old one, add some tests for 
> every function and test new and old implementation together with 
> automated tests.
> ?2/ split actual code (each method in a file for example) set up a 
> blunder to build the js adapter and then add unit and functional tests 
> one by one for every function. Then migrate code to Typescript
>
> I can try a POC on the first one if you want
Somebody did a POC as part of this project:
https://github.com/ebondu/angular2-keycloak

The idea was that we would end up with both a javascript adapter and a 
TypeScript adapter.? I was opposed to that at the time.? It's easy 
enough to just wrap the javascript adapter and use the type definition 
file for TypeScript.

But there would be advantages to */replacing /*the javascript adapter 
with TypeScript.? One is that we would no longer need a type def file 
that gets out of sync with the javascript adapter.? And you would get 
all the usual TypeScript goodness as we further develop the adapter.? It 
would result in better, more maintainable code.

The main technical hurdle would be that the interface would need to be 
backward compatible to support users who currently have code calling the 
javascript adapter directly.? We would need to continue supporting code 
that calls the adapter with plain javascript.

Stian, can you think of technical reasons why we should not do this?? I 
know there are probably many non-technical reasons.
>
>
>
> On Wed, Jan 16, 2019 at 5:43 PM Stan Silvert <ssilvert at redhat.com 
> <mailto:ssilvert at redhat.com>> wrote:
>
>     On 1/16/2019 9:53 AM, Guillaume Vincent wrote:
>     > Hello Keycloak dev list,
>     >
>     > in a previous post I raised the problem that the JavaScript
>     adapter did not
>     > have JavaScript tests.
>     >
>     > In a couple of hours I created a simple example for Keycloak
>     with unit and
>     > functional tests https://github.com/guillaumevincent/keycloak-lite
>     >
>     > You can see tests in this file
>     >
>     https://github.com/guillaumevincent/keycloak-lite/blob/master/test.js
>     >
>     > I also created a blog post on IMO How to test JavaScript code:
>     > https://guillaumevincent.com/2019/01/15/test-in-javascript.html
>     >
>     > Maybe we can open the discussion on how keycloak.js should be
>     tested.
>     > Without any fast and automated tests, in JavaScript, the
>     refactor of the
>     > keycloak adapter will not be easy at all.
>     >
>     > wdyt?
>     Several thoughts:
>
>     ? * Basically, I agree.? It makes sense to test javascript with
>     ? ? javascript.? I like where you are going with this.
>     ? * An important point in any discussion of testing is that the only
>     ? ? useful test is a test that uncovers a bug.? We never write tests
>     ? ? just to say we have lots of tests.? Coverage is what matters.? I'm
>     ? ? not criticizing your blog.? It's just something I like to keep
>     in mind.
>     ? * You mention TypeScript in your blog, but test.js appears to be
>     ? ? written in plain javascript.? IMO, any javascript we write
>     (with the
>     ? ? possible exception of keycloak.js) should be written in
>     TypeScript.
>     ? ? Both internally and externally, developers are moving more and
>     more
>     ? ? to TypeScript.? Also, the Java developers on our team will be much
>     ? ? more comfortable and confident with a strongly typed language that
>     ? ? works well with an IDE.
>     ? * We need to know a little more about the current test coverage
>     of the
>     ? ? javascript adapter.? Much of it is tested through indirect means.
>     ? * We need to understand how javascript tests will integrate into our
>     ? ? builds.
>     ? * We need to standardize on a javascript test package.? I don't want
>     ? ? the adapter to be tested with one library while the new account
>     ? ? management console is tested with another.
>
>
>
>     _______________________________________________
>     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
>
>
>
> -- 
> Guillaume Vincent
> Senior Software Engineer



From bruno at abstractj.org  Wed Jan 16 14:23:53 2019
From: bruno at abstractj.org (Bruno Oliveira)
Date: Wed, 16 Jan 2019 17:23:53 -0200
Subject: [keycloak-dev] Javascript adapater tests
In-Reply-To: <CAJbDe2uXJuEKkJaDOBLbRozZz4md46vHNFiEVYokitj=70GfVw@mail.gmail.com>
References: <CAJbDe2tVnSd7WXSMjU-nXPvmkmevo0HObDUB7QAePbVfrLLMPw@mail.gmail.com>
	<c5ea80a7-4ca8-5a68-ab71-c30241634920@redhat.com>
	<CAJbDe2uXJuEKkJaDOBLbRozZz4md46vHNFiEVYokitj=70GfVw@mail.gmail.com>
Message-ID: <CAM5SUC5C449wsBejBwTr6WBvDvrnejpEv_R62=yH2xu1zFDYSw@mail.gmail.com>

That's great Guillaume, and I agree with Stan about TypeScript. One
thing to keep in mind is the fact that most of our tests today are
integration tests.

Stan knows more than me about this. But talking about what was done
for the Node.js adapter[1], what we did was to write an app[2] which
was able to "exercise" some parts of the code.

Maybe we can do something similar for the JavaScript adapter? If this
is something which you would like to take a look, I'd suggest to
create an enhancement into Jira. In this way people will be aware that
you're on it.

[1] - https://github.com/keycloak/keycloak-nodejs-connect
[2] - https://github.com/keycloak/keycloak-nodejs-connect/tree/master/test/fixtures

On Wed, Jan 16, 2019 at 4:16 PM Guillaume Vincent <gvincent at redhat.com> wrote:
>
> > Coverage is what matters.
>
> I like to tests features and add regression tests for each bugs.
> Coverage is not a good metric, you can call your function with no
> assertion, you will have 100% code coverage.
> But I think we are agree that every function in the adapter (init(),
> login() refreshToken(), etc) should be tested.
>
> > should be written in TypeScript.
>
> Totally agree, as I said I created the experience in a couple of hours.
> But yes JS adapter should be written in typescript
>
> I see 2 strategies to implement tests and upgrade the JS adapter:
>
>  1/ write a new lib in Typescript near the old one, add some tests for
> every function and test new and old implementation together with automated
> tests.
>  2/ split actual code (each method in a file for example) set up a blunder
> to build the js adapter and then add unit and functional tests one by one
> for every function. Then migrate code to Typescript
>
> I can try a POC on the first one if you want
>
>
>
>
> On Wed, Jan 16, 2019 at 5:43 PM Stan Silvert <ssilvert at redhat.com> wrote:
>
> > On 1/16/2019 9:53 AM, Guillaume Vincent wrote:
> > > Hello Keycloak dev list,
> > >
> > > in a previous post I raised the problem that the JavaScript adapter did
> > not
> > > have JavaScript tests.
> > >
> > > In a couple of hours I created a simple example for Keycloak with unit
> > and
> > > functional tests https://github.com/guillaumevincent/keycloak-lite
> > >
> > > You can see tests in this file
> > > https://github.com/guillaumevincent/keycloak-lite/blob/master/test.js
> > >
> > > I also created a blog post on IMO How to test JavaScript code:
> > > https://guillaumevincent.com/2019/01/15/test-in-javascript.html
> > >
> > > Maybe we can open the discussion on how keycloak.js should be tested.
> > > Without any fast and automated tests, in JavaScript, the refactor of the
> > > keycloak adapter will not be easy at all.
> > >
> > > wdyt?
> > Several thoughts:
> >
> >   * Basically, I agree.  It makes sense to test javascript with
> >     javascript.  I like where you are going with this.
> >   * An important point in any discussion of testing is that the only
> >     useful test is a test that uncovers a bug.  We never write tests
> >     just to say we have lots of tests.  Coverage is what matters.  I'm
> >     not criticizing your blog.  It's just something I like to keep in mind.
> >   * You mention TypeScript in your blog, but test.js appears to be
> >     written in plain javascript.  IMO, any javascript we write (with the
> >     possible exception of keycloak.js) should be written in TypeScript.
> >     Both internally and externally, developers are moving more and more
> >     to TypeScript.  Also, the Java developers on our team will be much
> >     more comfortable and confident with a strongly typed language that
> >     works well with an IDE.
> >   * We need to know a little more about the current test coverage of the
> >     javascript adapter.  Much of it is tested through indirect means.
> >   * We need to understand how javascript tests will integrate into our
> >     builds.
> >   * We need to standardize on a javascript test package.  I don't want
> >     the adapter to be tested with one library while the new account
> >     management console is tested with another.
> >
> >
> >
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
> --
> Guillaume Vincent
> Senior Software Engineer
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



-- 
- abstractj

From sthorger at redhat.com  Thu Jan 17 02:55:20 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 17 Jan 2019 08:55:20 +0100
Subject: [keycloak-dev] Switching to Native JavaScript promise by default
Message-ID: <CAJgngAekhwKAa24cNgEY_vgq2HZsbM3tUog0z0FnvkSmTa35KA@mail.gmail.com>

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.

From sthorger at redhat.com  Thu Jan 17 04:22:39 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 17 Jan 2019 10:22:39 +0100
Subject: [keycloak-dev] Javascript adapater tests
In-Reply-To: <CAM5SUC5C449wsBejBwTr6WBvDvrnejpEv_R62=yH2xu1zFDYSw@mail.gmail.com>
References: <CAJbDe2tVnSd7WXSMjU-nXPvmkmevo0HObDUB7QAePbVfrLLMPw@mail.gmail.com>
	<c5ea80a7-4ca8-5a68-ab71-c30241634920@redhat.com>
	<CAJbDe2uXJuEKkJaDOBLbRozZz4md46vHNFiEVYokitj=70GfVw@mail.gmail.com>
	<CAM5SUC5C449wsBejBwTr6WBvDvrnejpEv_R62=yH2xu1zFDYSw@mail.gmail.com>
Message-ID: <CAJgngAeoe3iCzFqPX4nHz61NXjch=msX-FXP6fRJRuDQaxWF9A@mail.gmail.com>

With regards to converting to TypeScript I agree that is the way forward.

With regards to testing I see no value in unit tests for the JavaScript
adapter. The adapter itself provides very little logic and it's mostly
about invoking the Keycloak server. As a rule Keycloak requires
functional/integration tests, while unit tests are optional.

I am open to suggestions on how to write integration tests with JavaScript
frameworks instead of Arquillian. Couple things to point out. It has to be
integration tests using a real Keycloak server and it has to support
browser testing using Sellenium.


On Wed, 16 Jan 2019 at 20:36, Bruno Oliveira <bruno at abstractj.org> wrote:

> That's great Guillaume, and I agree with Stan about TypeScript. One
> thing to keep in mind is the fact that most of our tests today are
> integration tests.
>
> Stan knows more than me about this. But talking about what was done
> for the Node.js adapter[1], what we did was to write an app[2] which
> was able to "exercise" some parts of the code.
>
> Maybe we can do something similar for the JavaScript adapter? If this
> is something which you would like to take a look, I'd suggest to
> create an enhancement into Jira. In this way people will be aware that
> you're on it.
>
> [1] - https://github.com/keycloak/keycloak-nodejs-connect
> [2] -
> https://github.com/keycloak/keycloak-nodejs-connect/tree/master/test/fixtures
>
> On Wed, Jan 16, 2019 at 4:16 PM Guillaume Vincent <gvincent at redhat.com>
> wrote:
> >
> > > Coverage is what matters.
> >
> > I like to tests features and add regression tests for each bugs.
> > Coverage is not a good metric, you can call your function with no
> > assertion, you will have 100% code coverage.
> > But I think we are agree that every function in the adapter (init(),
> > login() refreshToken(), etc) should be tested.
> >
> > > should be written in TypeScript.
> >
> > Totally agree, as I said I created the experience in a couple of hours.
> > But yes JS adapter should be written in typescript
> >
> > I see 2 strategies to implement tests and upgrade the JS adapter:
> >
> >  1/ write a new lib in Typescript near the old one, add some tests for
> > every function and test new and old implementation together with
> automated
> > tests.
> >  2/ split actual code (each method in a file for example) set up a
> blunder
> > to build the js adapter and then add unit and functional tests one by one
> > for every function. Then migrate code to Typescript
> >
> > I can try a POC on the first one if you want
> >
> >
> >
> >
> > On Wed, Jan 16, 2019 at 5:43 PM Stan Silvert <ssilvert at redhat.com>
> wrote:
> >
> > > On 1/16/2019 9:53 AM, Guillaume Vincent wrote:
> > > > Hello Keycloak dev list,
> > > >
> > > > in a previous post I raised the problem that the JavaScript adapter
> did
> > > not
> > > > have JavaScript tests.
> > > >
> > > > In a couple of hours I created a simple example for Keycloak with
> unit
> > > and
> > > > functional tests https://github.com/guillaumevincent/keycloak-lite
> > > >
> > > > You can see tests in this file
> > > >
> https://github.com/guillaumevincent/keycloak-lite/blob/master/test.js
> > > >
> > > > I also created a blog post on IMO How to test JavaScript code:
> > > > https://guillaumevincent.com/2019/01/15/test-in-javascript.html
> > > >
> > > > Maybe we can open the discussion on how keycloak.js should be tested.
> > > > Without any fast and automated tests, in JavaScript, the refactor of
> the
> > > > keycloak adapter will not be easy at all.
> > > >
> > > > wdyt?
> > > Several thoughts:
> > >
> > >   * Basically, I agree.  It makes sense to test javascript with
> > >     javascript.  I like where you are going with this.
> > >   * An important point in any discussion of testing is that the only
> > >     useful test is a test that uncovers a bug.  We never write tests
> > >     just to say we have lots of tests.  Coverage is what matters.  I'm
> > >     not criticizing your blog.  It's just something I like to keep in
> mind.
> > >   * You mention TypeScript in your blog, but test.js appears to be
> > >     written in plain javascript.  IMO, any javascript we write (with
> the
> > >     possible exception of keycloak.js) should be written in TypeScript.
> > >     Both internally and externally, developers are moving more and more
> > >     to TypeScript.  Also, the Java developers on our team will be much
> > >     more comfortable and confident with a strongly typed language that
> > >     works well with an IDE.
> > >   * We need to know a little more about the current test coverage of
> the
> > >     javascript adapter.  Much of it is tested through indirect means.
> > >   * We need to understand how javascript tests will integrate into our
> > >     builds.
> > >   * We need to standardize on a javascript test package.  I don't want
> > >     the adapter to be tested with one library while the new account
> > >     management console is tested with another.
> > >
> > >
> > >
> > > _______________________________________________
> > > keycloak-dev mailing list
> > > keycloak-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> >
> >
> > --
> > Guillaume Vincent
> > Senior Software Engineer
> > _______________________________________________
> > 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 gvincent at redhat.com  Thu Jan 17 04:40:33 2019
From: gvincent at redhat.com (Guillaume Vincent)
Date: Thu, 17 Jan 2019 10:40:33 +0100
Subject: [keycloak-dev] Javascript adapater tests
In-Reply-To: <CAJgngAeoe3iCzFqPX4nHz61NXjch=msX-FXP6fRJRuDQaxWF9A@mail.gmail.com>
References: <CAJbDe2tVnSd7WXSMjU-nXPvmkmevo0HObDUB7QAePbVfrLLMPw@mail.gmail.com>
	<c5ea80a7-4ca8-5a68-ab71-c30241634920@redhat.com>
	<CAJbDe2uXJuEKkJaDOBLbRozZz4md46vHNFiEVYokitj=70GfVw@mail.gmail.com>
	<CAM5SUC5C449wsBejBwTr6WBvDvrnejpEv_R62=yH2xu1zFDYSw@mail.gmail.com>
	<CAJgngAeoe3iCzFqPX4nHz61NXjch=msX-FXP6fRJRuDQaxWF9A@mail.gmail.com>
Message-ID: <CAJbDe2u0Jjh8+aozJQyMWzoaCP4jUL_AM9Vg3dqKRcduXqt-1A@mail.gmail.com>

Hello,

> With regards to testing I see no value in unit tests for the JavaScript
adapter.

Without unit and functional tests, JavaScript developers can't refactor the
internal structure of the code.
Testing is about feedback, and the feedback loop must be short.
Integration tests take a long time to write, maintain and run.
Integration tests are needed, but also and above all, we need automated and
fast javascript tests.

Once again, I do not think we have the same vision of what the Javascript
adapter should be.
I think we have a fundamental problem.

When I see the size and quality of the code, the number of bugs in all the
wrappers for each framework, the time it takes to fix simple bugs, the
complicated use of the library.
This make me sad, and I loose a lot of time using this library.

> I am open to suggestions on how to write integration tests with
JavaScript frameworks

I let you do it, I think you are going in the wrong direction. Tell me when
you have changed your mind.

Cheers


On Thu, Jan 17, 2019 at 10:22 AM Stian Thorgersen <sthorger at redhat.com>
wrote:

> With regards to converting to TypeScript I agree that is the way forward.
>
> With regards to testing I see no value in unit tests for the JavaScript
> adapter. The adapter itself provides very little logic and it's mostly
> about invoking the Keycloak server. As a rule Keycloak requires
> functional/integration tests, while unit tests are optional.
>
> I am open to suggestions on how to write integration tests with JavaScript
> frameworks instead of Arquillian. Couple things to point out. It has to be
> integration tests using a real Keycloak server and it has to support
> browser testing using Sellenium.
>
>
> On Wed, 16 Jan 2019 at 20:36, Bruno Oliveira <bruno at abstractj.org> wrote:
>
>> That's great Guillaume, and I agree with Stan about TypeScript. One
>> thing to keep in mind is the fact that most of our tests today are
>> integration tests.
>>
>> Stan knows more than me about this. But talking about what was done
>> for the Node.js adapter[1], what we did was to write an app[2] which
>> was able to "exercise" some parts of the code.
>>
>> Maybe we can do something similar for the JavaScript adapter? If this
>> is something which you would like to take a look, I'd suggest to
>> create an enhancement into Jira. In this way people will be aware that
>> you're on it.
>>
>> [1] - https://github.com/keycloak/keycloak-nodejs-connect
>> [2] -
>> https://github.com/keycloak/keycloak-nodejs-connect/tree/master/test/fixtures
>>
>> On Wed, Jan 16, 2019 at 4:16 PM Guillaume Vincent <gvincent at redhat.com>
>> wrote:
>> >
>> > > Coverage is what matters.
>> >
>> > I like to tests features and add regression tests for each bugs.
>> > Coverage is not a good metric, you can call your function with no
>> > assertion, you will have 100% code coverage.
>> > But I think we are agree that every function in the adapter (init(),
>> > login() refreshToken(), etc) should be tested.
>> >
>> > > should be written in TypeScript.
>> >
>> > Totally agree, as I said I created the experience in a couple of hours.
>> > But yes JS adapter should be written in typescript
>> >
>> > I see 2 strategies to implement tests and upgrade the JS adapter:
>> >
>> >  1/ write a new lib in Typescript near the old one, add some tests for
>> > every function and test new and old implementation together with
>> automated
>> > tests.
>> >  2/ split actual code (each method in a file for example) set up a
>> blunder
>> > to build the js adapter and then add unit and functional tests one by
>> one
>> > for every function. Then migrate code to Typescript
>> >
>> > I can try a POC on the first one if you want
>> >
>> >
>> >
>> >
>> > On Wed, Jan 16, 2019 at 5:43 PM Stan Silvert <ssilvert at redhat.com>
>> wrote:
>> >
>> > > On 1/16/2019 9:53 AM, Guillaume Vincent wrote:
>> > > > Hello Keycloak dev list,
>> > > >
>> > > > in a previous post I raised the problem that the JavaScript adapter
>> did
>> > > not
>> > > > have JavaScript tests.
>> > > >
>> > > > In a couple of hours I created a simple example for Keycloak with
>> unit
>> > > and
>> > > > functional tests https://github.com/guillaumevincent/keycloak-lite
>> > > >
>> > > > You can see tests in this file
>> > > >
>> https://github.com/guillaumevincent/keycloak-lite/blob/master/test.js
>> > > >
>> > > > I also created a blog post on IMO How to test JavaScript code:
>> > > > https://guillaumevincent.com/2019/01/15/test-in-javascript.html
>> > > >
>> > > > Maybe we can open the discussion on how keycloak.js should be
>> tested.
>> > > > Without any fast and automated tests, in JavaScript, the refactor
>> of the
>> > > > keycloak adapter will not be easy at all.
>> > > >
>> > > > wdyt?
>> > > Several thoughts:
>> > >
>> > >   * Basically, I agree.  It makes sense to test javascript with
>> > >     javascript.  I like where you are going with this.
>> > >   * An important point in any discussion of testing is that the only
>> > >     useful test is a test that uncovers a bug.  We never write tests
>> > >     just to say we have lots of tests.  Coverage is what matters.  I'm
>> > >     not criticizing your blog.  It's just something I like to keep in
>> mind.
>> > >   * You mention TypeScript in your blog, but test.js appears to be
>> > >     written in plain javascript.  IMO, any javascript we write (with
>> the
>> > >     possible exception of keycloak.js) should be written in
>> TypeScript.
>> > >     Both internally and externally, developers are moving more and
>> more
>> > >     to TypeScript.  Also, the Java developers on our team will be much
>> > >     more comfortable and confident with a strongly typed language that
>> > >     works well with an IDE.
>> > >   * We need to know a little more about the current test coverage of
>> the
>> > >     javascript adapter.  Much of it is tested through indirect means.
>> > >   * We need to understand how javascript tests will integrate into our
>> > >     builds.
>> > >   * We need to standardize on a javascript test package.  I don't want
>> > >     the adapter to be tested with one library while the new account
>> > >     management console is tested with another.
>> > >
>> > >
>> > >
>> > > _______________________________________________
>> > > keycloak-dev mailing list
>> > > keycloak-dev at lists.jboss.org
>> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> >
>> >
>> >
>> > --
>> > Guillaume Vincent
>> > Senior Software Engineer
>> > _______________________________________________
>> > 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
>>
>

-- 
Guillaume Vincent
Senior Software Engineer

From sthorger at redhat.com  Thu Jan 17 05:01:05 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 17 Jan 2019 11:01:05 +0100
Subject: [keycloak-dev] Javascript adapater tests
In-Reply-To: <CAJbDe2u0Jjh8+aozJQyMWzoaCP4jUL_AM9Vg3dqKRcduXqt-1A@mail.gmail.com>
References: <CAJbDe2tVnSd7WXSMjU-nXPvmkmevo0HObDUB7QAePbVfrLLMPw@mail.gmail.com>
	<c5ea80a7-4ca8-5a68-ab71-c30241634920@redhat.com>
	<CAJbDe2uXJuEKkJaDOBLbRozZz4md46vHNFiEVYokitj=70GfVw@mail.gmail.com>
	<CAM5SUC5C449wsBejBwTr6WBvDvrnejpEv_R62=yH2xu1zFDYSw@mail.gmail.com>
	<CAJgngAeoe3iCzFqPX4nHz61NXjch=msX-FXP6fRJRuDQaxWF9A@mail.gmail.com>
	<CAJbDe2u0Jjh8+aozJQyMWzoaCP4jUL_AM9Vg3dqKRcduXqt-1A@mail.gmail.com>
Message-ID: <CAJgngAc5kLQJswmajHbTPn5kzkWMnf6e6t3mLn3jZhepkri7OA@mail.gmail.com>

Unit tests can be helpful during development and especially refactoring.
However, they do not prove that it is working until you have integration
tests. Unit tests can be added for sure, but we can't accept a larger
rewrite of the adapter until there is proper integration testing in place.
There is some coverage today, but it is not good enough to do a big rewrite.

The code itself has grown to a point where it is becoming hard to manage.
However, you are over stressing this point. We have a large number of happy
users of the adapters as well as many contributors that have had no issue
in contributing to the code. All in all it is not that complicated and
there are tradeoffs with bringing in Typescript, modules, etc. that may
just not be worth the effort for what is in essence a fairly simple library.

On Thu, 17 Jan 2019 at 10:41, Guillaume Vincent <gvincent at redhat.com> wrote:

> Hello,
>
> > With regards to testing I see no value in unit tests for the JavaScript
> adapter.
>
> Without unit and functional tests, JavaScript developers can't refactor
> the internal structure of the code.
> Testing is about feedback, and the feedback loop must be short.
> Integration tests take a long time to write, maintain and run.
> Integration tests are needed, but also and above all, we need automated
> and fast javascript tests.
>
> Once again, I do not think we have the same vision of what the Javascript
> adapter should be.
> I think we have a fundamental problem.
>
> When I see the size and quality of the code, the number of bugs in all the
> wrappers for each framework, the time it takes to fix simple bugs, the
> complicated use of the library.
> This make me sad, and I loose a lot of time using this library.
>
> > I am open to suggestions on how to write integration tests with
> JavaScript frameworks
>
> I let you do it, I think you are going in the wrong direction. Tell me
> when you have changed your mind.
>
> Cheers
>
>
> On Thu, Jan 17, 2019 at 10:22 AM Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> With regards to converting to TypeScript I agree that is the way forward.
>>
>> With regards to testing I see no value in unit tests for the JavaScript
>> adapter. The adapter itself provides very little logic and it's mostly
>> about invoking the Keycloak server. As a rule Keycloak requires
>> functional/integration tests, while unit tests are optional.
>>
>> I am open to suggestions on how to write integration tests with
>> JavaScript frameworks instead of Arquillian. Couple things to point out. It
>> has to be integration tests using a real Keycloak server and it has to
>> support browser testing using Sellenium.
>>
>>
>> On Wed, 16 Jan 2019 at 20:36, Bruno Oliveira <bruno at abstractj.org> wrote:
>>
>>> That's great Guillaume, and I agree with Stan about TypeScript. One
>>> thing to keep in mind is the fact that most of our tests today are
>>> integration tests.
>>>
>>> Stan knows more than me about this. But talking about what was done
>>> for the Node.js adapter[1], what we did was to write an app[2] which
>>> was able to "exercise" some parts of the code.
>>>
>>> Maybe we can do something similar for the JavaScript adapter? If this
>>> is something which you would like to take a look, I'd suggest to
>>> create an enhancement into Jira. In this way people will be aware that
>>> you're on it.
>>>
>>> [1] - https://github.com/keycloak/keycloak-nodejs-connect
>>> [2] -
>>> https://github.com/keycloak/keycloak-nodejs-connect/tree/master/test/fixtures
>>>
>>> On Wed, Jan 16, 2019 at 4:16 PM Guillaume Vincent <gvincent at redhat.com>
>>> wrote:
>>> >
>>> > > Coverage is what matters.
>>> >
>>> > I like to tests features and add regression tests for each bugs.
>>> > Coverage is not a good metric, you can call your function with no
>>> > assertion, you will have 100% code coverage.
>>> > But I think we are agree that every function in the adapter (init(),
>>> > login() refreshToken(), etc) should be tested.
>>> >
>>> > > should be written in TypeScript.
>>> >
>>> > Totally agree, as I said I created the experience in a couple of hours.
>>> > But yes JS adapter should be written in typescript
>>> >
>>> > I see 2 strategies to implement tests and upgrade the JS adapter:
>>> >
>>> >  1/ write a new lib in Typescript near the old one, add some tests for
>>> > every function and test new and old implementation together with
>>> automated
>>> > tests.
>>> >  2/ split actual code (each method in a file for example) set up a
>>> blunder
>>> > to build the js adapter and then add unit and functional tests one by
>>> one
>>> > for every function. Then migrate code to Typescript
>>> >
>>> > I can try a POC on the first one if you want
>>> >
>>> >
>>> >
>>> >
>>> > On Wed, Jan 16, 2019 at 5:43 PM Stan Silvert <ssilvert at redhat.com>
>>> wrote:
>>> >
>>> > > On 1/16/2019 9:53 AM, Guillaume Vincent wrote:
>>> > > > Hello Keycloak dev list,
>>> > > >
>>> > > > in a previous post I raised the problem that the JavaScript
>>> adapter did
>>> > > not
>>> > > > have JavaScript tests.
>>> > > >
>>> > > > In a couple of hours I created a simple example for Keycloak with
>>> unit
>>> > > and
>>> > > > functional tests https://github.com/guillaumevincent/keycloak-lite
>>> > > >
>>> > > > You can see tests in this file
>>> > > >
>>> https://github.com/guillaumevincent/keycloak-lite/blob/master/test.js
>>> > > >
>>> > > > I also created a blog post on IMO How to test JavaScript code:
>>> > > > https://guillaumevincent.com/2019/01/15/test-in-javascript.html
>>> > > >
>>> > > > Maybe we can open the discussion on how keycloak.js should be
>>> tested.
>>> > > > Without any fast and automated tests, in JavaScript, the refactor
>>> of the
>>> > > > keycloak adapter will not be easy at all.
>>> > > >
>>> > > > wdyt?
>>> > > Several thoughts:
>>> > >
>>> > >   * Basically, I agree.  It makes sense to test javascript with
>>> > >     javascript.  I like where you are going with this.
>>> > >   * An important point in any discussion of testing is that the only
>>> > >     useful test is a test that uncovers a bug.  We never write tests
>>> > >     just to say we have lots of tests.  Coverage is what matters.
>>> I'm
>>> > >     not criticizing your blog.  It's just something I like to keep
>>> in mind.
>>> > >   * You mention TypeScript in your blog, but test.js appears to be
>>> > >     written in plain javascript.  IMO, any javascript we write (with
>>> the
>>> > >     possible exception of keycloak.js) should be written in
>>> TypeScript.
>>> > >     Both internally and externally, developers are moving more and
>>> more
>>> > >     to TypeScript.  Also, the Java developers on our team will be
>>> much
>>> > >     more comfortable and confident with a strongly typed language
>>> that
>>> > >     works well with an IDE.
>>> > >   * We need to know a little more about the current test coverage of
>>> the
>>> > >     javascript adapter.  Much of it is tested through indirect means.
>>> > >   * We need to understand how javascript tests will integrate into
>>> our
>>> > >     builds.
>>> > >   * We need to standardize on a javascript test package.  I don't
>>> want
>>> > >     the adapter to be tested with one library while the new account
>>> > >     management console is tested with another.
>>> > >
>>> > >
>>> > >
>>> > > _______________________________________________
>>> > > keycloak-dev mailing list
>>> > > keycloak-dev at lists.jboss.org
>>> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>> >
>>> >
>>> >
>>> > --
>>> > Guillaume Vincent
>>> > Senior Software Engineer
>>> > _______________________________________________
>>> > 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
>>>
>>
>
> --
> Guillaume Vincent
> Senior Software Engineer
>

From mposolda at redhat.com  Thu Jan 17 06:28:16 2019
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 17 Jan 2019 12:28:16 +0100
Subject: [keycloak-dev] Impersonation extention
In-Reply-To: <CAMZkV7w9nd+sdGXb+YONM+4BeDk=d2bDgQzURn0hpSWo6vo2SA@mail.gmail.com>
References: <CAMZkV7w9nd+sdGXb+YONM+4BeDk=d2bDgQzURn0hpSWo6vo2SA@mail.gmail.com>
Message-ID: <6fff8536-bb17-2d81-da21-80277626c0b3@redhat.com>

Hi,

I think we already have this provided by token exchange. See especially 
7.4 and 7.5 here: 
https://www.keycloak.org/docs/latest/securing_apps/index.html#impersonation

Did you look at it? Or is your use-case different?

Marek

On 16/01/2019 18:33, Youssef EL HOUTI wrote:
> Hey guys,
>
> Just so you know, I have been working on extension that would allow a user
> with impersonation role to retrieve and access/refresh token for another
> user. (instead of the builtin behavior that uses cookies). you can find it
> here: https://github.com/elhoutico/keycloak-impersonation
>
> May be it could be added to the list of extensions:
> https://www.keycloak.org/extensions.html
>
> Cheers
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



From sthorger at redhat.com  Thu Jan 17 10:53:03 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 17 Jan 2019 16:53:03 +0100
Subject: [keycloak-dev] Multiple user login on the same browser for
 Account Aggregation application
In-Reply-To: <OSBPR01MB397452F5DE52AB2FE04D96CCCE820@OSBPR01MB3974.jpnprd01.prod.outlook.com>
References: <OSBPR01MB397452F5DE52AB2FE04D96CCCE820@OSBPR01MB3974.jpnprd01.prod.outlook.com>
Message-ID: <CAJgngAfMJqQB=f3C2jYiPgQu5p=nR0utVPxBwcsLM8xFUDCsiw@mail.gmail.com>

Not sure I fully understand what you are after.

Are you basically talking about what Google provides where you can login to
multiple accounts at the same time from the browser with the ability to
select accounts when logging into an application as well as ability to
switch between logged-in accounts from within the application itself?

In case you don't know how Google does it, I'll explain it here:

* Login to Gmail first time
* Gmail has an icon that displays your account details and sign out. This
icon also provides an option to add additional accounts
* Clicking add account redirects to login screen and you can now login
using an additional account
* When using a new application and you are logged-in from multiple accounts
Google displays an account selector where you can select which of the
logged-in accounts to use

If this is what you are after and it's implemented as a complete feature we
can consider it, but if it's something else we need to have further
discussions and see if it is something Keycloak should support or if you
should use a custom authentication flow to achieve it.

On Wed, 16 Jan 2019 at 09:03, ???? / NORIMATSU?TAKASHI <
takashi.norimatsu.ws at hitachi.com> wrote:

> Hello,
>
> I've used keycloak for such the client application that collect a user's
> information via API provided by a resource server (e.g. collect balance
> from bank?s API).
>
> If the user has multiple accounts in the resource server, the client
> application must collect information on all these accounts. In order to do
> this, the client application let the user conduct an authentication and
> authorization flow for each account on the same browser consecutively.
>
>
> The current keycloak implementation cannot allow a user to login multiple
> accounts consecutively and simultaneously on the same browser. Therefore,
> the user must terminate and restart the browser every time she or he login
> on one of his or him accounts, which is not good for UX perspective. I?ve
> opened JIRA (https://issues.jboss.org/browse/KEYCLOAK-9332).
>
> I have an idea to resolve it and contribute its realization hopefully.
> However, I'm not sure this idea is appropriate or not. So, I am happy to
> get some suggestions and advices on it.
>
> [Idea]
> The current (keycloak-4.8.2.Final) keycloak's implementation seems to be
> as follows:
> RootAuthenticationSessionModel class instance has several
> AuthenticationSessionModel class instances.
> Browser is bounded to RootAuthenticationSessionModel by AUTH_SESSION_ID
> Cookie and realm.
> AuthenticationSessionModel is bounded to Browser's tab by
> RootAuthenticationSessionModel, client id, and tab id.
>
> It seems that keycloak allows a user on the same browser to login on the
> same account for several clients per browser's tab, and it is good for Web
> SSO use case. However, it does not work good for Account Aggregation use
> case.
>
> My proposal is that suppressing (expiring explicitly) AUTH_SESSION_ID
> Cookie and its related Cookies on the client side (not the server side) at
> the end of an authentication and authorization flow make the browser new to
> logging-in onto keycloak every time. Also, adding a switch to change the
> operation mode from the ordinal Web SSO mode to the proposed one (like
> Securing API mode).
>
> Best Regards
> Takashi Norimatsu
> Hitachi, Ltd.
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sguilhen at redhat.com  Thu Jan 17 12:11:52 2019
From: sguilhen at redhat.com (Stefan Guilhen)
Date: Thu, 17 Jan 2019 15:11:52 -0200
Subject: [keycloak-dev] Session Expiry & Remember Me
In-Reply-To: <9b13d2b8f8914f22a58b38c21ff37982@VOL-SLO-EXCH3.vgnet.volgrp.com>
References: <3579c14b49c34e5692cb8b866c577d08@VOL-SLO-EXCH3.vgnet.volgrp.com>
	<CA+7ohfkzj4eYy75Hto1SE+d5dMSua_9NroR3NswGKFjAfEk_8g@mail.gmail.com>
	<9b13d2b8f8914f22a58b38c21ff37982@VOL-SLO-EXCH3.vgnet.volgrp.com>
Message-ID: <CA+7ohfn_8gPeQ=mGp5tHEvBQmAFV8ZhzgJVyOJmaRYiqEkc7bg@mail.gmail.com>

Alex, I've created a Jira (https://issues.jboss.org/browse/KEYCLOAK-9371)
to track this. PR has been opened and once it is reviewed/merged I will
update the Jira.

On Tue, Jan 15, 2019 at 12:38 PM Alex Chatziparaskewas <
alex.chatziparaskewas at trapezegroup.com> wrote:

> Many thanks!
>
>
>
> *From:* Stefan Guilhen [mailto:sguilhen at redhat.com]
> *Sent:* 15 January 2019 13:22
> *To:* Alex Chatziparaskewas <alex.chatziparaskewas at trapezegroup.com>
> *Cc:* keycloak-dev at lists.jboss.org
> *Subject:* Re: [keycloak-dev] Session Expiry & Remember Me
>
>
>
> Yes, you are absolutely right, that expression should be using the
> expiredRememberMe value in that spot. I'll work on the fix.
>
>
>
> Best regards,
>
> Stefan
>
>
>
> On Tue, Jan 15, 2019 at 8:33 AM Alex Chatziparaskewas <
> alex.chatziparaskewas at trapezegroup.com> wrote:
>
> Hi All,
>
> I am trying to get the remember me functionality running having the
> problem that my sessions are expired by keycloak - in my eyes -
> prematurely. I started digging through keycloak code and stumbled over the
> following:
>
> class UserSessionPredicate, method 'test':
>
>         ...
>         if (entity.isRememberMe()) {
>             if (expiredRememberMe != null && expiredRefreshRememberMe !=
> null && entity.getStarted() > ###expiredRefreshRememberMe### &&
> entity.getLastSessionRefresh() > expiredRefreshRememberMe) {
>                 return false;
>             }
>         }
>         else {
>             if (expired != null && expiredRefresh != null &&
> entity.getStarted() > expired && entity.getLastSessionRefresh() >
> expiredRefresh) {
>                 return false;
>             }
>         }
>         ...
>
> The marked (###) 'expiredRefreshRememberMe' in the second if statement,
> should that not be 'expiredRememberMe'?
>
> Thanks & Regards,
> Alex
>
>
>
>
> _______________________________________________
> 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>
>


-- 

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 ssilvert at redhat.com  Thu Jan 17 14:23:48 2019
From: ssilvert at redhat.com (Stan Silvert)
Date: Thu, 17 Jan 2019 14:23:48 -0500
Subject: [keycloak-dev] Switching to Native JavaScript promise by default
In-Reply-To: <CAJgngAekhwKAa24cNgEY_vgq2HZsbM3tUog0z0FnvkSmTa35KA@mail.gmail.com>
References: <CAJgngAekhwKAa24cNgEY_vgq2HZsbM3tUog0z0FnvkSmTa35KA@mail.gmail.com>
Message-ID: <99d53985-74f2-6a14-7186-5cc5d627ea0b@redhat.com>

+1

On 1/17/2019 2:55 AM, 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-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



From bruno at abstractj.org  Thu Jan 17 15:16:56 2019
From: bruno at abstractj.org (Bruno Oliveira)
Date: Thu, 17 Jan 2019 18:16:56 -0200
Subject: [keycloak-dev] [keycloak-user] Switching to Native JavaScript
	promise by default
In-Reply-To: <CAJgngAekhwKAa24cNgEY_vgq2HZsbM3tUog0z0FnvkSmTa35KA@mail.gmail.com>
References: <CAJgngAekhwKAa24cNgEY_vgq2HZsbM3tUog0z0FnvkSmTa35KA@mail.gmail.com>
Message-ID: <CAM5SUC5UPT2BH0O3haJJS3+Lba12YTqQyAExMbjAS_RM9BO+KA@mail.gmail.com>

+1

On Thu, Jan 17, 2019 at 5:55 AM Stian Thorgersen <sthorger at redhat.com> 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



-- 
- abstractj

From youssef.elhouti at gmail.com  Thu Jan 17 20:50:41 2019
From: youssef.elhouti at gmail.com (Youssef EL HOUTI)
Date: Fri, 18 Jan 2019 02:50:41 +0100
Subject: [keycloak-dev] Impersonation extention
In-Reply-To: <6fff8536-bb17-2d81-da21-80277626c0b3@redhat.com>
References: <CAMZkV7w9nd+sdGXb+YONM+4BeDk=d2bDgQzURn0hpSWo6vo2SA@mail.gmail.com>
	<6fff8536-bb17-2d81-da21-80277626c0b3@redhat.com>
Message-ID: <CAMZkV7y+6j26814tLFxbWJptWvNK0Lx6kjKPwUDS6rOGjPmUyw@mail.gmail.com>

Thanks Marek,

Totally my bad, it works great on the latest version and covers my use
case. Switching to it.

On Thu, Jan 17, 2019 at 12:28 PM Marek Posolda <mposolda at redhat.com> wrote:

> Hi,
>
> I think we already have this provided by token exchange. See especially
> 7.4 and 7.5 here:
> https://www.keycloak.org/docs/latest/securing_apps/index.html#impersonation
>
> Did you look at it? Or is your use-case different?
>
> Marek
>
> On 16/01/2019 18:33, Youssef EL HOUTI wrote:
> > Hey guys,
> >
> > Just so you know, I have been working on extension that would allow a
> user
> > with impersonation role to retrieve and access/refresh token for another
> > user. (instead of the builtin behavior that uses cookies). you can find
> it
> > here: https://github.com/elhoutico/keycloak-impersonation
> >
> > May be it could be added to the list of extensions:
> > https://www.keycloak.org/extensions.html
> >
> > Cheers
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>

From takashi.norimatsu.ws at hitachi.com  Fri Jan 18 00:09:25 2019
From: takashi.norimatsu.ws at hitachi.com (=?utf-8?B?5LmX5p2+6ZqG5b+XIC8gTk9SSU1BVFNV77yMVEFLQVNISQ==?=)
Date: Fri, 18 Jan 2019 05:09:25 +0000
Subject: [keycloak-dev] Multiple user login on the same browser for
 Account Aggregation application
In-Reply-To: <CAJgngAfMJqQB=f3C2jYiPgQu5p=nR0utVPxBwcsLM8xFUDCsiw@mail.gmail.com>
References: <OSBPR01MB397452F5DE52AB2FE04D96CCCE820@OSBPR01MB3974.jpnprd01.prod.outlook.com>
	<CAJgngAfMJqQB=f3C2jYiPgQu5p=nR0utVPxBwcsLM8xFUDCsiw@mail.gmail.com>
Message-ID: <OSBPR01MB39746110E432DE125FC01B0BCE9C0@OSBPR01MB3974.jpnprd01.prod.outlook.com>

Thank you for comments. I'm afraid it is not relevant to an external identity provider directly nor selecting from multiple accounts.

To say shortly, our considering user case is as follows:

In Japan(maybe other countries), there is such the fintech client application that accesses APIs provided by financial institutions to retrieve some information like transaction records and balance, and provide its user some useful services like online automatic housekeeping book, personal financial management, and so on.

It is the case that the user her or himself has multiple accounts on the same bank (Checking Account, Savings Account, Time Deposit Account, and so on), or the user manages her or his family member's accounts on the same bank.

If such the user uses this fintech client application for the first time, for this application to get an access token that is granted, she or he opens a browser, start Authz Code flow, do authentication and authorization per each account.



In this use case, we need not SSO. We use keycloak only to let a client application get an access token that is granted by an end user.

For example, a customer (say, Alice) has multiple accounts (say AliceEin, AliceZwei, AliceDrei) on the keycloak, and want to make the client application (say ClientApp) get access tokens for each of these accounts (namely, access token granted by AliceEin, access token granted by AliceZwei, access token granted by AliceDrei).

To do so, this customer opens a browser, start Authz Code flow, do authentication and authorization per each account. We hope to do it without closing and restarting the browser.

Procedure is as follows:
1. invoke a browser
2. accesses ClientApp
3. start Authz code flow
4. on keycloak, login as AliceEin
5. tokens for user account "AliceEin" are issued to ClienApp
6. on the same browser, start Authz code flow again
7. on keycloak, login as AliceZwei
8. tokens for user account "AliceZwei" are issued to ClienApp
9. on the same browser, start Authz code flow again
10. on keycloak, login as AliceDrei
11. tokens for user account "AliceDrei" are issued to ClienApp

The expectation is the following:
ClientApp got all in-active access tokens for each user account "AliceEin", "AliceZwei", and "AliceDrei".

The actual result is the following:
at the procedure 7, keycloak returned the error page saying;
You are already authenticated as different user AliceEin in this session. Please logout first.
If logout, the access token granted by AliceEin is revoked.
Considering some workaround, Alice close and restart the browser, or use another browser.

I've recognized that keycloak inherently try to achieve Web SSO, therefore, the result above is reasonable.
However, in our user case not requiring Web SSO, we would like to achieve the expectation above.

From: Stian Thorgersen <sthorger at redhat.com>
Sent: Friday, January 18, 2019 12:53 AM
To: ???? / NORIMATSU?TAKASHI <takashi.norimatsu.ws at hitachi.com>
Cc: keycloak-dev at lists.jboss.org
Subject: [!]Re: [keycloak-dev] Multiple user login on the same browser for Account Aggregation application

Not sure I fully understand what you are after.

Are you basically talking about what Google provides where you can login to multiple accounts at the same time from the browser with the ability to select accounts when logging into an application as well as ability to switch between logged-in accounts from within the application itself?

In case you don't know how Google does it, I'll explain it here:

* Login to Gmail first time
* Gmail has an icon that displays your account details and sign out. This icon also provides an option to add additional accounts
* Clicking add account redirects to login screen and you can now login using an additional account
* When using a new application and you are logged-in from multiple accounts Google displays an account selector where you can select which of the logged-in accounts to use

If this is what you are after and it's implemented as a complete feature we can consider it, but if it's something else we need to have further discussions and see if it is something Keycloak should support or if you should use a custom authentication flow to achieve it.

On Wed, 16 Jan 2019 at 09:03, ???? / NORIMATSU?TAKASHI <takashi.norimatsu.ws at hitachi.com<mailto:takashi.norimatsu.ws at hitachi.com>> wrote:
Hello,

I've used keycloak for such the client application that collect a user's information via API provided by a resource server (e.g. collect balance from bank?s API).

If the user has multiple accounts in the resource server, the client application must collect information on all these accounts. In order to do this, the client application let the user conduct an authentication and authorization flow for each account on the same browser consecutively.


The current keycloak implementation cannot allow a user to login multiple accounts consecutively and simultaneously on the same browser. Therefore, the user must terminate and restart the browser every time she or he login on one of his or him accounts, which is not good for UX perspective. I?ve opened JIRA (https://issues.jboss.org/browse/KEYCLOAK-9332<https://clicktime.symantec.com/3Lvd7ed2QRdLsEq6ziXbHvg7Vc?u=https%3A%2F%2Fissues.jboss.org%2Fbrowse%2FKEYCLOAK-9332>).

I have an idea to resolve it and contribute its realization hopefully. However, I'm not sure this idea is appropriate or not. So, I am happy to get some suggestions and advices on it.

[Idea]
The current (keycloak-4.8.2.Final) keycloak's implementation seems to be as follows:
RootAuthenticationSessionModel class instance has several AuthenticationSessionModel class instances.
Browser is bounded to RootAuthenticationSessionModel by AUTH_SESSION_ID Cookie and realm.
AuthenticationSessionModel is bounded to Browser's tab by RootAuthenticationSessionModel, client id, and tab id.

It seems that keycloak allows a user on the same browser to login on the same account for several clients per browser's tab, and it is good for Web SSO use case. However, it does not work good for Account Aggregation use case.

My proposal is that suppressing (expiring explicitly) AUTH_SESSION_ID Cookie and its related Cookies on the client side (not the server side) at the end of an authentication and authorization flow make the browser new to logging-in onto keycloak every time. Also, adding a switch to change the operation mode from the ordinal Web SSO mode to the proposed one (like Securing API mode).

Best Regards
Takashi Norimatsu
Hitachi, Ltd.

_______________________________________________
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://clicktime.symantec.com/3W4zNBtUkGecLAcJy5U61t97Vc?u=https%3A%2F%2Flists.jboss.org%2Fmailman%2Flistinfo%2Fkeycloak-dev>

From sthorger at redhat.com  Fri Jan 18 03:01:48 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 18 Jan 2019 09:01:48 +0100
Subject: [keycloak-dev] Transaction approval via OpenID Connect User
 Questioning API
In-Reply-To: <CAC6ftk08-dPvaNKEr_0imYPcBd7oagADCPrBk2M7bT+f+WKMBw@mail.gmail.com>
References: <CAC6ftk2oWfMtbOcj4Nx727j9wCd41sRFUxGxmh6LNFgfDGkLYw@mail.gmail.com>
	<CAJgngAdZw28R6L+wyDqstQw7whwhFDFFV=-j6oTTseBRvyFw5g@mail.gmail.com>
	<CAC6ftk08-dPvaNKEr_0imYPcBd7oagADCPrBk2M7bT+f+WKMBw@mail.gmail.com>
Message-ID: <CAJgngAfwnJzyq+hR=Ga3M8q9z87gW5W6Mr5HgO6-L4_pA4zsjQ@mail.gmail.com>

On Wed, 16 Jan 2019 at 10:33, Felix Mei?ner <felix.meissner at hanko.io> wrote:

> Hi Stian,
>
> thanks for your feedback. Nice to hear that you consider the User
> Questioning API a fitting feature for Keycloak.
>
> For now, we will implement this feature as a plugin to get a working proof
> of concept. We would be happy to contribute any common code to Keycloak.
>
> Intuitively, I would start implementing the endpoints as a REST Resource.
> To allow for different methods of questioning (via a screen displayed by
> Keycloak or via our API) we would have to extract a common interface, I
> think.
>

Can you elaborate on what you mean about different methods of questioning?
>From briefly reading the spec it looks like the client sends the request to
the OP. Then the user should interact with the OP.

For the user interaction with the OP I would assume this means the OP is
responsible to display any screens (or send emails) to get the users
statement.


>
> Viele Gr??e / Best regards
> Felix Mei?ner
>
> Hanko.io ? Convenient and Secure Authentication
>
> Hanko GmbH
> Ringstr. 19 | 24114 Kiel | Germany
>
> Email: felix.meissner at hanko.io
> Phone: +49 431 908 929 25
>
>
> Am Mi., 16. Jan. 2019 um 07:58 Uhr schrieb Stian Thorgersen <
> sthorger at redhat.com>:
>
> > Looks quite interesting and useful. Haven't seen much request for it
> > though.
> >
> > Doesn't look like it would be to much effort to implement, nor to much
> > burden to maintain. Have you considered how this could be implemented in
> > Keycloak?
> >
> > On Mon, 14 Jan 2019 at 12:49, Felix Mei?ner <felix.meissner at hanko.io>
> > wrote:
> >
> >> Hi everyone,
> >>
> >> recently, I have been investigating how to integrate transaction
> approval
> >> in an OpenID Connect based environment.
> >>
> >> It seems to me, the OpenID Connect User Questioning API is the perfect
> >> match, but as far as I can see, Keycloak is currently not implementing
> >> this
> >> API, right? Also, I cannot fond any issue at JBoss regarding this
> feature.
> >>
> >> Are there any reasons to not implement the User Questioning API in
> >> Keycloak, or has there just not yet been a feature request / someone
> >> willing to implement this? Or are there any other ways to aquire the
> >> user's
> >> consent via Keycloak?
> >>
> >> At Hanko, we are developing a Keycloak plugin that allows to use FIDO2
> as
> >> well as UAF and U2F devices as second or multi-factor authentication
> >> devices in Keycloak with help of our API. Now, we are looking for a way
> to
> >> integrate signed transactions based on FIDO in Keycloak.
> >>
> >> Thank you for your comments!
> >>
> >> Viele Gr??e / Best regards
> >> Felix Mei?ner
> >>
> >> Hanko.io ? Convenient and Secure Authentication
> >>
> >> Hanko GmbH
> >> Ringstr. 19 | 24114 Kiel | Germany
> >>
> >> Email: felix.meissner at hanko.io
> >> Phone: +49 431 908 929 25
> >> _______________________________________________
> >> 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  Fri Jan 18 03:09:36 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 18 Jan 2019 09:09:36 +0100
Subject: [keycloak-dev] Defining several Password Policies within a Realm
In-Reply-To: <PR1PR01MB49396153A2F07E00B26E0A44F6820@PR1PR01MB4939.eurprd01.prod.exchangelabs.com>
References: <PR1PR01MB4939AE7E0BE3C820C1360755F68A0@PR1PR01MB4939.eurprd01.prod.exchangelabs.com>
	<CAJgngAftS+U3kn1yr89LwaQK6BqoAydLGKY=LYTtO3Eja9q7DQ@mail.gmail.com>
	<PR1PR01MB49396153A2F07E00B26E0A44F6820@PR1PR01MB4939.eurprd01.prod.exchangelabs.com>
Message-ID: <CAJgngAe8nb-6iib40q1LuOVk_kJcCnCHdqGRQi_u1h0C+ezp0g@mail.gmail.com>

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

From sthorger at redhat.com  Fri Jan 18 03:17:18 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 18 Jan 2019 09:17:18 +0100
Subject: [keycloak-dev] Multiple user login on the same browser for
 Account Aggregation application
In-Reply-To: <OSBPR01MB39746110E432DE125FC01B0BCE9C0@OSBPR01MB3974.jpnprd01.prod.outlook.com>
References: <OSBPR01MB397452F5DE52AB2FE04D96CCCE820@OSBPR01MB3974.jpnprd01.prod.outlook.com>
	<CAJgngAfMJqQB=f3C2jYiPgQu5p=nR0utVPxBwcsLM8xFUDCsiw@mail.gmail.com>
	<OSBPR01MB39746110E432DE125FC01B0BCE9C0@OSBPR01MB3974.jpnprd01.prod.outlook.com>
Message-ID: <CAJgngAfsz6kiREnWpQJU-fVDfHz00se=en+ncZDQU5cjTGoRYA@mail.gmail.com>

I can see Keycloak adding support for:

* Always requiring login to a specific client, not relying on SSO session.
This can already supported through login=prompt and maximum authentication
time and probably doesn't need anything specific.
* Login to Keycloak with multiple accounts with a way to switch accounts

I don't think what you are after is something we should add directly to
Keycloak, but I believe you can achieve it reasonably easily with a custom
authentication flow.

Keycloak recently added support for the ability to specify a separate flow
for specific clients. That means you can create a new browser flow without
the cookie authenticator and associate with with "ClientApp". This means
that ClientApp will prompt the user for username and password, ignoring the
cookie, while other clients would continue to use the SSO cookie. I think
this will just work as is without any changes needed to Keycloak. It's
probably going to look a bit strange from what open sessions the users has
though.

On Fri, 18 Jan 2019 at 06:09, ???? / NORIMATSU?TAKASHI <
takashi.norimatsu.ws at hitachi.com> wrote:

> Thank you for comments. I'm afraid it is not relevant to an external
> identity provider directly nor selecting from multiple accounts.
>
>
>
> To say shortly, our considering user case is as follows:
>
>
>
> In Japan(maybe other countries), there is such the fintech client
> application that accesses APIs provided by financial institutions to
> retrieve some information like transaction records and balance, and provide
> its user some useful services like online automatic housekeeping book,
> personal financial management, and so on.
>
>
>
> It is the case that the user her or himself has multiple accounts on the
> same bank (Checking Account, Savings Account, Time Deposit Account, and so
> on), or the user manages her or his family member's accounts on the same
> bank.
>
>
>
> If such the user uses this fintech client application for the first time,
> for this application to get an access token that is granted, she or he
> opens a browser, start Authz Code flow, do authentication and authorization
> per each account.
>
>
>
>
>
>
>
> In this use case, we need not SSO. We use keycloak only to let a client
> application get an access token that is granted by an end user.
>
>
>
> For example, a customer (say, Alice) has multiple accounts (say AliceEin,
> AliceZwei, AliceDrei) on the keycloak, and want to make the client
> application (say ClientApp) get access tokens for each of these accounts
> (namely, access token granted by AliceEin, access token granted by
> AliceZwei, access token granted by AliceDrei).
>
>
>
> To do so, this customer opens a browser, start Authz Code flow, do
> authentication and authorization per each account. We hope to do it without
> closing and restarting the browser.
>
>
>
> Procedure is as follows:
>
> 1. invoke a browser
>
> 2. accesses ClientApp
>
> 3. start Authz code flow
>
> 4. on keycloak, login as AliceEin
>
> 5. tokens for user account "AliceEin" are issued to ClienApp
>
> 6. on the same browser, start Authz code flow again
>
> 7. on keycloak, login as AliceZwei
>
> 8. tokens for user account "AliceZwei" are issued to ClienApp
>
> 9. on the same browser, start Authz code flow again
>
> 10. on keycloak, login as AliceDrei
>
> 11. tokens for user account "AliceDrei" are issued to ClienApp
>
>
>
> The expectation is the following:
>
> ClientApp got all in-active access tokens for each user account
> "AliceEin", "AliceZwei", and "AliceDrei".
>
>
>
> The actual result is the following:
>
> at the procedure 7, keycloak returned the error page saying;
>
> You are already authenticated as different user AliceEin in this session.
> Please logout first.
>
> If logout, the access token granted by AliceEin is revoked.
>
> Considering some workaround, Alice close and restart the browser, or use
> another browser.
>
>
>
> I've recognized that keycloak inherently try to achieve Web SSO,
> therefore, the result above is reasonable.
>
> However, in our user case not requiring Web SSO, we would like to achieve
> the expectation above.
>
>
>
> *From:* Stian Thorgersen <sthorger at redhat.com>
> *Sent:* Friday, January 18, 2019 12:53 AM
> *To:* ???? / NORIMATSU?TAKASHI <takashi.norimatsu.ws at hitachi.com>
> *Cc:* keycloak-dev at lists.jboss.org
> *Subject:* [!]Re: [keycloak-dev] Multiple user login on the same browser
> for Account Aggregation application
>
>
>
> Not sure I fully understand what you are after.
>
>
>
> Are you basically talking about what Google provides where you can login
> to multiple accounts at the same time from the browser with the ability to
> select accounts when logging into an application as well as ability to
> switch between logged-in accounts from within the application itself?
>
>
>
> In case you don't know how Google does it, I'll explain it here:
>
>
>
> * Login to Gmail first time
>
> * Gmail has an icon that displays your account details and sign out. This
> icon also provides an option to add additional accounts
>
> * Clicking add account redirects to login screen and you can now login
> using an additional account
>
> * When using a new application and you are logged-in from multiple
> accounts Google displays an account selector where you can select which of
> the logged-in accounts to use
>
>
>
> If this is what you are after and it's implemented as a complete feature
> we can consider it, but if it's something else we need to have further
> discussions and see if it is something Keycloak should support or if you
> should use a custom authentication flow to achieve it.
>
>
>
> On Wed, 16 Jan 2019 at 09:03, ???? / NORIMATSU?TAKASHI <
> takashi.norimatsu.ws at hitachi.com> wrote:
>
> Hello,
>
> I've used keycloak for such the client application that collect a user's
> information via API provided by a resource server (e.g. collect balance
> from bank?s API).
>
> If the user has multiple accounts in the resource server, the client
> application must collect information on all these accounts. In order to do
> this, the client application let the user conduct an authentication and
> authorization flow for each account on the same browser consecutively.
>
>
> The current keycloak implementation cannot allow a user to login multiple
> accounts consecutively and simultaneously on the same browser. Therefore,
> the user must terminate and restart the browser every time she or he login
> on one of his or him accounts, which is not good for UX perspective. I?ve
> opened JIRA (https://issues.jboss.org/browse/KEYCLOAK-9332
> <https://clicktime.symantec.com/3Lvd7ed2QRdLsEq6ziXbHvg7Vc?u=https%3A%2F%2Fissues.jboss.org%2Fbrowse%2FKEYCLOAK-9332>
> ).
>
> I have an idea to resolve it and contribute its realization hopefully.
> However, I'm not sure this idea is appropriate or not. So, I am happy to
> get some suggestions and advices on it.
>
> [Idea]
> The current (keycloak-4.8.2.Final) keycloak's implementation seems to be
> as follows:
> RootAuthenticationSessionModel class instance has several
> AuthenticationSessionModel class instances.
> Browser is bounded to RootAuthenticationSessionModel by AUTH_SESSION_ID
> Cookie and realm.
> AuthenticationSessionModel is bounded to Browser's tab by
> RootAuthenticationSessionModel, client id, and tab id.
>
> It seems that keycloak allows a user on the same browser to login on the
> same account for several clients per browser's tab, and it is good for Web
> SSO use case. However, it does not work good for Account Aggregation use
> case.
>
> My proposal is that suppressing (expiring explicitly) AUTH_SESSION_ID
> Cookie and its related Cookies on the client side (not the server side) at
> the end of an authentication and authorization flow make the browser new to
> logging-in onto keycloak every time. Also, adding a switch to change the
> operation mode from the ordinal Web SSO mode to the proposed one (like
> Securing API mode).
>
> Best Regards
> Takashi Norimatsu
> Hitachi, Ltd.
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> <https://clicktime.symantec.com/3W4zNBtUkGecLAcJy5U61t97Vc?u=https%3A%2F%2Flists.jboss.org%2Fmailman%2Flistinfo%2Fkeycloak-dev>
>
>

From dt at acutus.pro  Fri Jan 18 17:06:43 2019
From: dt at acutus.pro (Dmitry Telegin)
Date: Sat, 19 Jan 2019 01:06:43 +0300
Subject: [keycloak-dev] Defining several Password Policies within a Realm
In-Reply-To: <CAJgngAe8nb-6iib40q1LuOVk_kJcCnCHdqGRQi_u1h0C+ezp0g@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>
Message-ID: <1547849203.13934.6.camel@acutus.pro>

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

From pnalyvayko at agi.com  Fri Jan 18 23:04:06 2019
From: pnalyvayko at agi.com (Nalyvayko, Peter)
Date: Sat, 19 Jan 2019 04:04:06 +0000
Subject: [keycloak-dev] User TLS client certificate authentication -
 inconsistent DN string representation with LDAP
In-Reply-To: <CAMvXD=HdLyzPhNMV0vzg2Bm9iJFNSB0r0rqFzeTJjUk+GGPreg@mail.gmail.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>
Message-ID: <BL0PR07MB500945357DB3FB151ED6C20DDA9D0@BL0PR07MB5009.namprd07.prod.outlook.com>

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


________________________________________
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


From takashi.norimatsu.ws at hitachi.com  Mon Jan 21 03:17:08 2019
From: takashi.norimatsu.ws at hitachi.com (=?utf-8?B?5LmX5p2+6ZqG5b+XIC8gTk9SSU1BVFNV77yMVEFLQVNISQ==?=)
Date: Mon, 21 Jan 2019 08:17:08 +0000
Subject: [keycloak-dev] Multiple user login on the same browser for
 Account Aggregation application
In-Reply-To: <CAJgngAfsz6kiREnWpQJU-fVDfHz00se=en+ncZDQU5cjTGoRYA@mail.gmail.com>
References: <OSBPR01MB397452F5DE52AB2FE04D96CCCE820@OSBPR01MB3974.jpnprd01.prod.outlook.com>
	<CAJgngAfMJqQB=f3C2jYiPgQu5p=nR0utVPxBwcsLM8xFUDCsiw@mail.gmail.com>
	<OSBPR01MB39746110E432DE125FC01B0BCE9C0@OSBPR01MB3974.jpnprd01.prod.outlook.com>
	<CAJgngAfsz6kiREnWpQJU-fVDfHz00se=en+ncZDQU5cjTGoRYA@mail.gmail.com>
Message-ID: <OSBPR01MB3974D399AB1E561D9C46A0E8CE9F0@OSBPR01MB3974.jpnprd01.prod.outlook.com>

Thanks a lot for your advice.

I followed what you had said, but unfortunately, it did not work as what I would like to do.

- On Browser authentication flow, I made "Cookie" authenticator disabled.
- "login=prompt" was added as the authorization code request's query parameter.
- After login as AliceEin, I tried to login as AliceZwei on the same browser, AuthenticationProcessor.attachSession returned the error saying "You are already authenticated as different user 'AliceEin' in this session. Please logout first.".

I think that this feature is important for securing API access use case. Therefore, I would like to implement and contribute this feature onto keycloak without interfering with existing features (e.g. Web SSO).

----------
From: Stian Thorgersen <sthorger at redhat.com> 
Sent: Friday, January 18, 2019 5:17 PM
To: ???? / NORIMATSU?TAKASHI <takashi.norimatsu.ws at hitachi.com>
Cc: keycloak-dev at lists.jboss.org
Subject: [!]Re: Re: [keycloak-dev] Multiple user login on the same browser for Account Aggregation application

I can see Keycloak adding support for:

* Always requiring login to a specific client, not relying on SSO session. This can already supported through login=prompt and maximum authentication time and probably doesn't need anything specific.
* Login to Keycloak with multiple accounts with a way to switch accounts

I don't think what you are after is something we should add directly to Keycloak, but I believe you can achieve it reasonably easily with a custom authentication flow.

Keycloak recently added support for the ability to specify a separate flow for specific clients. That means you can create a new browser flow without the cookie authenticator and associate with with "ClientApp". This means that ClientApp will prompt the user for username and password, ignoring the cookie, while other clients would continue to use the SSO cookie. I think this will just work as is without any changes needed to Keycloak. It's probably going to look a bit strange from what open sessions the users has though.

On Fri, 18 Jan 2019 at 06:09, ???? / NORIMATSU?TAKASHI <mailto:takashi.norimatsu.ws at hitachi.com> wrote:
Thank you for comments. I'm afraid it is not relevant to an external identity provider directly nor selecting from multiple accounts.
?
To say shortly, our considering user case is as follows:
?
In Japan(maybe other countries), there is such the fintech client application that accesses APIs provided by financial institutions to retrieve some information like transaction records and balance, and provide its user some useful services like online automatic housekeeping book, personal financial management, and so on.
?
It is the case that the user her or himself has multiple accounts on the same bank (Checking Account, Savings Account, Time Deposit Account, and so on), or the user manages her or his family member's accounts on the same bank.
?
If such the user uses this fintech client application for the first time, for this application to get an access token that is granted, she or he opens a browser, start Authz Code flow, do authentication and authorization per each account.
?
?
?
In this use case, we need not SSO. We use keycloak only to let a client application get an access token that is granted by an end user.
?
For example, a customer (say, Alice) has multiple accounts (say AliceEin, AliceZwei, AliceDrei) on the keycloak, and want to make the client application (say ClientApp) get access tokens for each of these accounts (namely, access token granted by AliceEin, access token granted by AliceZwei, access token granted by AliceDrei).
?
To do so, this customer opens a browser, start Authz Code flow, do authentication and authorization per each account. We hope to do it without closing and restarting the browser.
?
Procedure is as follows:
1. invoke a browser
2. accesses ClientApp
3. start Authz code flow
4. on keycloak, login as AliceEin
5. tokens for user account "AliceEin" are issued to ClienApp
6. on the same browser, start Authz code flow again
7. on keycloak, login as AliceZwei
8. tokens for user account "AliceZwei" are issued to ClienApp
9. on the same browser, start Authz code flow again
10. on keycloak, login as AliceDrei
11. tokens for user account "AliceDrei" are issued to ClienApp
?
The expectation is the following:
ClientApp got all in-active access tokens for each user account "AliceEin", "AliceZwei", and "AliceDrei".
?
The actual result is the following:
at the procedure 7, keycloak returned the error page saying;
You are already authenticated as different user AliceEin in this session. Please logout first.
If logout, the access token granted by AliceEin is revoked.
Considering some workaround, Alice close and restart the browser, or use another browser.
?
I've recognized that keycloak inherently try to achieve Web SSO, therefore, the result above is reasonable. 
However, in our user case not requiring Web SSO, we would like to achieve the expectation above.
?
From: Stian Thorgersen <mailto:sthorger at redhat.com> 
Sent: Friday, January 18, 2019 12:53 AM
To: ???? / NORIMATSU?TAKASHI <mailto:takashi.norimatsu.ws at hitachi.com>
Cc: mailto:keycloak-dev at lists.jboss.org
Subject: [!]Re: [keycloak-dev] Multiple user login on the same browser for Account Aggregation application
?
Not sure I fully understand what you are after.
?
Are you basically talking about what Google provides where you can login to multiple accounts at the same time from the browser with the ability to select accounts when logging into an application as well as ability to switch between logged-in accounts from within the application itself?
?
In case you don't know how Google does it, I'll explain it here:
?
* Login to Gmail first time
* Gmail has an icon that displays your account details and sign out. This icon also provides an option to add additional accounts
* Clicking add account redirects to login screen and you can now login using an additional account
* When using a new application and you are logged-in from multiple accounts Google displays an account selector where you can select which of the logged-in accounts to use
?
If this is what you are after and it's implemented as a complete feature we can consider it, but if it's something else we need to have further discussions and see if it is something Keycloak should support or if you should use a custom authentication flow to achieve it.
?
On Wed, 16 Jan 2019 at 09:03, ???? / NORIMATSU?TAKASHI <mailto:takashi.norimatsu.ws at hitachi.com> wrote:
Hello,

I've used keycloak for such the client application that collect a user's information via API provided by a resource server (e.g. collect balance from bank?s API).

If the user has multiple accounts in the resource server, the client application must collect information on all these accounts. In order to do this, the client application let the user conduct an authentication and authorization flow for each account on the same browser consecutively.


The current keycloak implementation cannot allow a user to login multiple accounts consecutively and simultaneously on the same browser. Therefore, the user must terminate and restart the browser every time she or he login on one of his or him accounts, which is not good for UX perspective. I?ve opened JIRA (https://clicktime.symantec.com/3Lvd7ed2QRdLsEq6ziXbHvg7Vc?u=https%3A%2F%2Fissues.jboss.org%2Fbrowse%2FKEYCLOAK-9332).

I have an idea to resolve it and contribute its realization hopefully. However, I'm not sure this idea is appropriate or not. So, I am happy to get some suggestions and advices on it.

[Idea]
The current (keycloak-4.8.2.Final) keycloak's implementation seems to be as follows:
RootAuthenticationSessionModel class instance has several AuthenticationSessionModel class instances.
Browser is bounded to RootAuthenticationSessionModel by AUTH_SESSION_ID Cookie and realm.
AuthenticationSessionModel is bounded to Browser's tab by RootAuthenticationSessionModel, client id, and tab id.

It seems that keycloak allows a user on the same browser to login on the same account for several clients per browser's tab, and it is good for Web SSO use case. However, it does not work good for Account Aggregation use case.

My proposal is that suppressing (expiring explicitly) AUTH_SESSION_ID Cookie and its related Cookies on the client side (not the server side) at the end of an authentication and authorization flow make the browser new to logging-in onto keycloak every time. Also, adding a switch to change the operation mode from the ordinal Web SSO mode to the proposed one (like Securing API mode).

Best Regards
Takashi Norimatsu
Hitachi, Ltd.

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


From sthorger at redhat.com  Mon Jan 21 03:21:04 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 21 Jan 2019 09:21:04 +0100
Subject: [keycloak-dev] Defining several Password Policies within a Realm
In-Reply-To: <1547849203.13934.6.camel@acutus.pro>
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>
Message-ID: <CAJgngAd-zWz+sgwCe7QW2DGNtnYCFMRVGC5xYwzjsgdPi82qhQ@mail.gmail.com>

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
>

From sthorger at redhat.com  Mon Jan 21 03:24:26 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 21 Jan 2019 09:24:26 +0100
Subject: [keycloak-dev] Multiple user login on the same browser for
 Account Aggregation application
In-Reply-To: <OSBPR01MB3974D399AB1E561D9C46A0E8CE9F0@OSBPR01MB3974.jpnprd01.prod.outlook.com>
References: <OSBPR01MB397452F5DE52AB2FE04D96CCCE820@OSBPR01MB3974.jpnprd01.prod.outlook.com>
	<CAJgngAfMJqQB=f3C2jYiPgQu5p=nR0utVPxBwcsLM8xFUDCsiw@mail.gmail.com>
	<OSBPR01MB39746110E432DE125FC01B0BCE9C0@OSBPR01MB3974.jpnprd01.prod.outlook.com>
	<CAJgngAfsz6kiREnWpQJU-fVDfHz00se=en+ncZDQU5cjTGoRYA@mail.gmail.com>
	<OSBPR01MB3974D399AB1E561D9C46A0E8CE9F0@OSBPR01MB3974.jpnprd01.prod.outlook.com>
Message-ID: <CAJgngAdxWqqqy_apwDUiOWC+EYKDoDVm-3ky+CpkSXTmQAaWig@mail.gmail.com>

At this point I don't see any reason why this should be a feature in
Keycloak. If you can't point me to anything that shows this is generically
needed/uses please do. I believe an account select mechanism like I
described would be able to fill your use-case and also be something that is
useful to others.

If there are smaller tweaks that can be made to allow you to create a
custom flow for what you need that can be considered, but we need to
understand the changes required.

On Mon, 21 Jan 2019 at 09:17, ???? / NORIMATSU?TAKASHI <
takashi.norimatsu.ws at hitachi.com> wrote:

> Thanks a lot for your advice.
>
> I followed what you had said, but unfortunately, it did not work as what I
> would like to do.
>
> - On Browser authentication flow, I made "Cookie" authenticator disabled.
> - "login=prompt" was added as the authorization code request's query
> parameter.
> - After login as AliceEin, I tried to login as AliceZwei on the same
> browser, AuthenticationProcessor.attachSession returned the error saying
> "You are already authenticated as different user 'AliceEin' in this
> session. Please logout first.".
>
> I think that this feature is important for securing API access use case.
> Therefore, I would like to implement and contribute this feature onto
> keycloak without interfering with existing features (e.g. Web SSO).
>
> ----------
> From: Stian Thorgersen <sthorger at redhat.com>
> Sent: Friday, January 18, 2019 5:17 PM
> To: ???? / NORIMATSU?TAKASHI <takashi.norimatsu.ws at hitachi.com>
> Cc: keycloak-dev at lists.jboss.org
> Subject: [!]Re: Re: [keycloak-dev] Multiple user login on the same browser
> for Account Aggregation application
>
> I can see Keycloak adding support for:
>
> * Always requiring login to a specific client, not relying on SSO session.
> This can already supported through login=prompt and maximum authentication
> time and probably doesn't need anything specific.
> * Login to Keycloak with multiple accounts with a way to switch accounts
>
> I don't think what you are after is something we should add directly to
> Keycloak, but I believe you can achieve it reasonably easily with a custom
> authentication flow.
>
> Keycloak recently added support for the ability to specify a separate flow
> for specific clients. That means you can create a new browser flow without
> the cookie authenticator and associate with with "ClientApp". This means
> that ClientApp will prompt the user for username and password, ignoring the
> cookie, while other clients would continue to use the SSO cookie. I think
> this will just work as is without any changes needed to Keycloak. It's
> probably going to look a bit strange from what open sessions the users has
> though.
>
> On Fri, 18 Jan 2019 at 06:09, ???? / NORIMATSU?TAKASHI <mailto:
> takashi.norimatsu.ws at hitachi.com> wrote:
> Thank you for comments. I'm afraid it is not relevant to an external
> identity provider directly nor selecting from multiple accounts.
>
> To say shortly, our considering user case is as follows:
>
> In Japan(maybe other countries), there is such the fintech client
> application that accesses APIs provided by financial institutions to
> retrieve some information like transaction records and balance, and provide
> its user some useful services like online automatic housekeeping book,
> personal financial management, and so on.
>
> It is the case that the user her or himself has multiple accounts on the
> same bank (Checking Account, Savings Account, Time Deposit Account, and so
> on), or the user manages her or his family member's accounts on the same
> bank.
>
> If such the user uses this fintech client application for the first time,
> for this application to get an access token that is granted, she or he
> opens a browser, start Authz Code flow, do authentication and authorization
> per each account.
>
>
>
> In this use case, we need not SSO. We use keycloak only to let a client
> application get an access token that is granted by an end user.
>
> For example, a customer (say, Alice) has multiple accounts (say AliceEin,
> AliceZwei, AliceDrei) on the keycloak, and want to make the client
> application (say ClientApp) get access tokens for each of these accounts
> (namely, access token granted by AliceEin, access token granted by
> AliceZwei, access token granted by AliceDrei).
>
> To do so, this customer opens a browser, start Authz Code flow, do
> authentication and authorization per each account. We hope to do it without
> closing and restarting the browser.
>
> Procedure is as follows:
> 1. invoke a browser
> 2. accesses ClientApp
> 3. start Authz code flow
> 4. on keycloak, login as AliceEin
> 5. tokens for user account "AliceEin" are issued to ClienApp
> 6. on the same browser, start Authz code flow again
> 7. on keycloak, login as AliceZwei
> 8. tokens for user account "AliceZwei" are issued to ClienApp
> 9. on the same browser, start Authz code flow again
> 10. on keycloak, login as AliceDrei
> 11. tokens for user account "AliceDrei" are issued to ClienApp
>
> The expectation is the following:
> ClientApp got all in-active access tokens for each user account
> "AliceEin", "AliceZwei", and "AliceDrei".
>
> The actual result is the following:
> at the procedure 7, keycloak returned the error page saying;
> You are already authenticated as different user AliceEin in this session.
> Please logout first.
> If logout, the access token granted by AliceEin is revoked.
> Considering some workaround, Alice close and restart the browser, or use
> another browser.
>
> I've recognized that keycloak inherently try to achieve Web SSO,
> therefore, the result above is reasonable.
> However, in our user case not requiring Web SSO, we would like to achieve
> the expectation above.
>
> From: Stian Thorgersen <mailto:sthorger at redhat.com>
> Sent: Friday, January 18, 2019 12:53 AM
> To: ???? / NORIMATSU?TAKASHI <mailto:takashi.norimatsu.ws at hitachi.com>
> Cc: mailto:keycloak-dev at lists.jboss.org
> Subject: [!]Re: [keycloak-dev] Multiple user login on the same browser for
> Account Aggregation application
>
> Not sure I fully understand what you are after.
>
> Are you basically talking about what Google provides where you can login
> to multiple accounts at the same time from the browser with the ability to
> select accounts when logging into an application as well as ability to
> switch between logged-in accounts from within the application itself?
>
> In case you don't know how Google does it, I'll explain it here:
>
> * Login to Gmail first time
> * Gmail has an icon that displays your account details and sign out. This
> icon also provides an option to add additional accounts
> * Clicking add account redirects to login screen and you can now login
> using an additional account
> * When using a new application and you are logged-in from multiple
> accounts Google displays an account selector where you can select which of
> the logged-in accounts to use
>
> If this is what you are after and it's implemented as a complete feature
> we can consider it, but if it's something else we need to have further
> discussions and see if it is something Keycloak should support or if you
> should use a custom authentication flow to achieve it.
>
> On Wed, 16 Jan 2019 at 09:03, ???? / NORIMATSU?TAKASHI <mailto:
> takashi.norimatsu.ws at hitachi.com> wrote:
> Hello,
>
> I've used keycloak for such the client application that collect a user's
> information via API provided by a resource server (e.g. collect balance
> from bank?s API).
>
> If the user has multiple accounts in the resource server, the client
> application must collect information on all these accounts. In order to do
> this, the client application let the user conduct an authentication and
> authorization flow for each account on the same browser consecutively.
>
>
> The current keycloak implementation cannot allow a user to login multiple
> accounts consecutively and simultaneously on the same browser. Therefore,
> the user must terminate and restart the browser every time she or he login
> on one of his or him accounts, which is not good for UX perspective. I?ve
> opened JIRA (
> https://clicktime.symantec.com/3Lvd7ed2QRdLsEq6ziXbHvg7Vc?u=https%3A%2F%2Fissues.jboss.org%2Fbrowse%2FKEYCLOAK-9332
> ).
>
> I have an idea to resolve it and contribute its realization hopefully.
> However, I'm not sure this idea is appropriate or not. So, I am happy to
> get some suggestions and advices on it.
>
> [Idea]
> The current (keycloak-4.8.2.Final) keycloak's implementation seems to be
> as follows:
> RootAuthenticationSessionModel class instance has several
> AuthenticationSessionModel class instances.
> Browser is bounded to RootAuthenticationSessionModel by AUTH_SESSION_ID
> Cookie and realm.
> AuthenticationSessionModel is bounded to Browser's tab by
> RootAuthenticationSessionModel, client id, and tab id.
>
> It seems that keycloak allows a user on the same browser to login on the
> same account for several clients per browser's tab, and it is good for Web
> SSO use case. However, it does not work good for Account Aggregation use
> case.
>
> My proposal is that suppressing (expiring explicitly) AUTH_SESSION_ID
> Cookie and its related Cookies on the client side (not the server side) at
> the end of an authentication and authorization flow make the browser new to
> logging-in onto keycloak every time. Also, adding a switch to change the
> operation mode from the ordinal Web SSO mode to the proposed one (like
> Securing API mode).
>
> Best Regards
> Takashi Norimatsu
> Hitachi, Ltd.
>
> _______________________________________________
> keycloak-dev mailing list
> mailto:keycloak-dev at lists.jboss.org
>
> https://clicktime.symantec.com/3W4zNBtUkGecLAcJy5U61t97Vc?u=https%3A%2F%2Flists.jboss.org%2Fmailman%2Flistinfo%2Fkeycloak-dev
>

From s.berthier at bee-buzziness.com  Mon Jan 21 03:50:47 2019
From: s.berthier at bee-buzziness.com (Sebastien SB. BERTHIER)
Date: Mon, 21 Jan 2019 08:50:47 +0000
Subject: [keycloak-dev] External role to role idp mapper update brokered
 user behavior buggy ?
Message-ID: <1962f8d44e0340749993c45a02ebda81@BBUZ-EXCH02.bbuzg.net>

Hi,

Some months ago, I reported a strange behavior about external role to role idp mapper.
https://issues.jboss.org/browse/KEYCLOAK-8690

It concernes particularly the update method.
- When a user (with local role) leaves external token role, then the mapped role is remove from local keycloak user.
- But when a user (without local role) gains the external token role, then the mapped role is not added to local keycloak user.

For me and Stian (see comments), it seems to be a bug.  What is your opinion ?

S?bastien B.?


From hmlnarik at redhat.com  Thu Jan 24 02:58:07 2019
From: hmlnarik at redhat.com (Hynek Mlnarik)
Date: Thu, 24 Jan 2019 08:58:07 +0100
Subject: [keycloak-dev] passing SAML extensions and context to custom
	authenticators
In-Reply-To: <CAFTOGtd-ReFnVXf8v_0N8RxzUx-mXx+H=D_7FJP97PyxHy2Chw@mail.gmail.com>
References: <CAFTOGtd-ReFnVXf8v_0N8RxzUx-mXx+H=D_7FJP97PyxHy2Chw@mail.gmail.com>
Message-ID: <CAMvXD=H=gjwOGY3yZ+o7WESvq3foOVPtN3ZkT-NZyPeJ_KbbOQ@mail.gmail.com>

Hi Gideon,

thanks for the idea. Something like that would be a useful enhancement. The
implementation would need to cover also the broker endpoint, other SAML
message types (extensions are part of message types other than AuthnRequest
as well), and count on several implementations of the hypothetical
SamlAuthenticationPreprocessor. Could you please file an "Enhancement" JIRA?

--Hynek

On Wed, Jan 16, 2019 at 5:49 PM Gideon Caranzo <gideonray at gmail.com> wrote:

> Hi All,
>
> I'd like to propose a feature that allows custom authenticators to handle
> SAML extensions, authentication context and other request attributes.
>
> Right now in OIDC, all request claims are passed to custom authenticators
> which allows for customized behavior depending on the claims.
> However, this is not the case for SAML. Only attributes that are explicitly
> set (e.g. NameID) in the auth session are passed to custom authenticators.
>
> Information like SAML extension and authentication context are not
> available which limits the ability to define custom behaviors. In the past,
> we ran into similar limitation and we had to update keycloak core to add
> support for NameID attribute.
>
> To solve this, we can have an optional hook that pre-process SAML login
> request right before authentication. The hook can then extract the needed
> attributes and set it accordingly for custom authenticators to process.
>
> The pre-processing will be done in
> *SamlService.BindingProtocol.loginRequest()*:
>
> *public* *class* SamlService *extends* AuthorizationEndpointBase {
>
>     *. . .*
>
>     *public* *abstract* *class* BindingProtocol {
>
>         . . .
>
>         *protected* Response loginRequest(String relayState,
> AuthnRequestType requestAbstractType, ClientModel client) {
>
>             . . .
>
>             SamlAuthenticationPreprocessor preProcessor = session
> .getProvider(SamlAuthenticationPreprocessor.*class*);
>
>             *if* (preProcessor != *null*) {
>
>               preProcessor.process(requestAbstractType, authSession);
>
>             }
>
>
>
>             *return* newBrowserAuthentication(authSession,
> requestAbstractType.isIsPassive(), redirectToAuthentication);
>
>        }
>
>
> Let me know what you think. Thanks.
>
> Best regards,
> Gideon
> _______________________________________________
> 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 Jan 24 10:57:42 2019
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Thu, 24 Jan 2019 16:57:42 +0100
Subject: [keycloak-dev] More robust datasource configuration in Keycloak
	docker images
Message-ID: <CAK-7U1hRECsxJG1MLxGaVcoo+NEBgQazmcWeJM1bCiGgQMcOiQ@mail.gmail.com>

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.

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

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

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

From dt at acutus.pro  Mon Jan 28 01:17:53 2019
From: dt at acutus.pro (Dmitry Telegin)
Date: Mon, 28 Jan 2019 09:17:53 +0300
Subject: [keycloak-dev] [keycloak-user] Switching to Native JavaScript
 promise by default
In-Reply-To: <CAJgngAekhwKAa24cNgEY_vgq2HZsbM3tUog0z0FnvkSmTa35KA@mail.gmail.com>
References: <CAJgngAekhwKAa24cNgEY_vgq2HZsbM3tUog0z0FnvkSmTa35KA@mail.gmail.com>
Message-ID: <1548656273.19952.1.camel@acutus.pro>

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 swetha.t at endurance.com  Mon Jan 28 02:24:14 2019
From: swetha.t at endurance.com (Swetha Talluri)
Date: Mon, 28 Jan 2019 12:54:14 +0530
Subject: [keycloak-dev] Enable or disable otp from external application
	integrated to keycloak
Message-ID: <CAHAbs+G0X=xDc4UF443UESDk27D7brFAv4V9bvFkN35nfvfqng@mail.gmail.com>

Hi ,
We have a legacy application to which we are planning to integrate keycloak
for otp flows . We so far have otps sent through mobile , we need to
replace that flow with keycloak google auth otp.
Do we have anyway to replace in our legacy application ?
When user toogles button of enabling 2fa on our application , we should be
able to see keycloak barcode for that user and update the user entry in our
database.
Similar flows for disabling 2fa , we need keycloak page to enter otp and
then disable user's 2fa flow.

Thanks,
Swetha.T

From mposolda at redhat.com  Tue Jan 29 05:38:56 2019
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 29 Jan 2019 11:38:56 +0100
Subject: [keycloak-dev] External role to role idp mapper update brokered
 user behavior buggy ?
In-Reply-To: <1962f8d44e0340749993c45a02ebda81@BBUZ-EXCH02.bbuzg.net>
References: <1962f8d44e0340749993c45a02ebda81@BBUZ-EXCH02.bbuzg.net>
Message-ID: <8c7b88f6-2f9f-cdc2-59ab-2462d96d1478@redhat.com>

+1 that this is a bug. I added a comment to the JIRA with some 
suggestions for the PR. In shortuct, it will be good to:

- Have an automated test for this
- Ensure that "user.grantRole" is called in "updateBrokeredUser" just in 
case that user is not yet member of that role. Otherwise it will be DB 
call and cache invalidation during each login of the user (Bad for 
performance...)

Marek

On 21/01/2019 09:50, Sebastien SB. BERTHIER wrote:
> Hi,
>
> Some months ago, I reported a strange behavior about external role to role idp mapper.
> https://issues.jboss.org/browse/KEYCLOAK-8690
>
> It concernes particularly the update method.
> - When a user (with local role) leaves external token role, then the mapped role is remove from local keycloak user.
> - But when a user (without local role) gains the external token role, then the mapped role is not added to local keycloak user.
>
> For me and Stian (see comments), it seems to be a bug.  What is your opinion ?
>
> S?bastien B.?
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



From mposolda at redhat.com  Tue Jan 29 06:30:46 2019
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 29 Jan 2019 12:30:46 +0100
Subject: [keycloak-dev] User TLS client certificate authentication -
 inconsistent DN string representation with LDAP
In-Reply-To: <BL0PR07MB500945357DB3FB151ED6C20DDA9D0@BL0PR07MB5009.namprd07.prod.outlook.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>
Message-ID: <079961fe-e298-1ea7-d946-f32729785b17@redhat.com>

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 mposolda at redhat.com  Tue Jan 29 06:34:56 2019
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 29 Jan 2019 12:34:56 +0100
Subject: [keycloak-dev] Better support for "scope" in adapters
Message-ID: <3030a267-b2b6-7a76-3020-42959ef344c5@redhat.com>

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


From psilva at redhat.com  Tue Jan 29 13:49:18 2019
From: psilva at redhat.com (Pedro Igor Silva)
Date: Tue, 29 Jan 2019 16:49:18 -0200
Subject: [keycloak-dev] Better support for "scope" in adapters
In-Reply-To: <3030a267-b2b6-7a76-3020-42959ef344c5@redhat.com>
References: <3030a267-b2b6-7a76-3020-42959ef344c5@redhat.com>
Message-ID: <CAJrcDBep7ScX4O7G5fSh5oPhsbT9B5-ekqhF01MKiikZXB9ywg@mail.gmail.com>

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. And the backend by itself is free to
exchange tokens to call other services (service chaining).

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 ?

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

From mposolda at redhat.com  Wed Jan 30 02:25:12 2019
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 30 Jan 2019 08:25:12 +0100
Subject: [keycloak-dev] Better support for "scope" in adapters
In-Reply-To: <CAJrcDBep7ScX4O7G5fSh5oPhsbT9B5-ekqhF01MKiikZXB9ywg@mail.gmail.com>
References: <3030a267-b2b6-7a76-3020-42959ef344c5@redhat.com>
	<CAJrcDBep7ScX4O7G5fSh5oPhsbT9B5-ekqhF01MKiikZXB9ywg@mail.gmail.com>
Message-ID: <e01a6dc8-3163-f132-835b-713b8cfdfc62@redhat.com>

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.

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

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

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
>


From mposolda at redhat.com  Wed Jan 30 05:37:11 2019
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 30 Jan 2019 11:37:11 +0100
Subject: [keycloak-dev] Authz services feedback
Message-ID: <eb9f0892-df6f-204a-ea3a-520590cc34b2@redhat.com>

I recently have a chance to play a bit more with authz services when 
preparing for the devconf demo. Great stuff and cudos to Pedro and all 
the others who contributed to authorization services!

I just have few questions and possible suggestions to improve in the 
future :) Also based on some questions and discussion I had after the talk:

- My REST service was SpringBoot based and protected by policy enforced 
configured in the applications.properties like this 
https://github.com/mposolda/devconf2019-authz/blob/master/devconf2019-service/src/main/resources/application.properties#L23-L32 
. However I was stuck when I wanted to enable UserManagedAccess for my 
service. The PolicyEnforcerConfig.UserManagedAccessConfig is an empty 
class and I couldn't figure how to properly add it in the 
application.properties file. I've tried to add various things in 
application.properties like this, but none of them helped:

keycloak.policy-enforcer-config.user-managed-access
keycloak.policy-enforcer-config.user-managed-access=
keycloak.policy-enforcer-config.user-managed-access= (Just left single 
space here after equals character)

As a workaround, I ended with having separate bean to do it 
programatically - 
https://github.com/mposolda/devconf2019-authz/blob/master/devconf2019-service/src/main/java/org/keycloak/quickstarts/devconf2019/config/KeycloakUMAConfigResolver.java 
. Is it a bug or is it just me doing something stupid?


- I wonder about possible improvements of keycloak-authz.js and if 
usability can be a bit improved? More specifically I mean this:
-- Handling of the 401 response with UMA ticket from resource-server - 
Can this be done "automatically"? I meant the flow described here: 
https://www.keycloak.org/docs/latest/authorization_services/index.html#handling-authorization-responses-from-a-uma-protected-resource-server 
. Maybe the keycloak-authz itself can just handle the response from 
resource server, then send the AuthorizationRequest to KC with the UMA 
ticket and then possibly re-send the request to resource-server with new 
RPT and do this "automatically" without a need to manually handle it by 
the application like this: 
https://github.com/keycloak/keycloak-quickstarts/blob/latest/app-authz-uma-photoz/photoz-html5-client/src/main/webapp/js/app.js#L154-L208 
. WDYT?

-- Another thing is refreshing of RPT. It looks that RPT response 
contains the refresh token, so refreshing of RPTs is possible. However 
the keycloak-authz.js client doesn't have any support for automatically 
refreshing RPT token. I mean something similar, which is provided by 
keycloak.js itself (method "keycloak.updateToken" which automatically 
refreshes the token if needed). Due this limitation, it seems there is a 
bug in our quickstart. When you try the quickstart 
"app-authz-uma-photoz" and you go through the flow like this:
- Open http://localhost:8080/photoz-html5-client and login as jdoe
- Create some album
- Wait 10 minutes (RPT expiration is same like AccessTokenLifespan, so 5 
minutes by default)
- Try to create some album again - now fails with 403 due the RPT 
expired and no support for refreshing it in the keycloak-authz.js or the 
application itself.
Should I create JIRA for this?


- It seems we don't have any Java based adapter for the frontend clients 
written in Java? We have Java based authorization client, but that 
provides just sending REST requests. It doesn't provide things like I 
mentioned above though (Storing RPT, automatically refreshing RPT, 
Automatically handling 401 response with the UMA ticket from 
resource-server and sending the request to KC etc). Any plan to have this?

Marek


From psilva at redhat.com  Wed Jan 30 06:29:31 2019
From: psilva at redhat.com (Pedro Igor Silva)
Date: Wed, 30 Jan 2019 09:29:31 -0200
Subject: [keycloak-dev] Authz services feedback
In-Reply-To: <eb9f0892-df6f-204a-ea3a-520590cc34b2@redhat.com>
References: <eb9f0892-df6f-204a-ea3a-520590cc34b2@redhat.com>
Message-ID: <CAJrcDBft7awbeby96aJdTOQpVJJaaYTCuxeBF72_3kJHMUVVFQ@mail.gmail.com>

Thanks for the feedback, Marek. Kudos to you too for talking about this
stuff.

Answers inline.

On Wed, Jan 30, 2019 at 8:39 AM Marek Posolda <mposolda at redhat.com> wrote:

> I recently have a chance to play a bit more with authz services when
> preparing for the devconf demo. Great stuff and cudos to Pedro and all
> the others who contributed to authorization services!
>
> I just have few questions and possible suggestions to improve in the
> future :) Also based on some questions and discussion I had after the talk:
>
> - My REST service was SpringBoot based and protected by policy enforced
> configured in the applications.properties like this
>
> https://github.com/mposolda/devconf2019-authz/blob/master/devconf2019-service/src/main/resources/application.properties#L23-L32
> . However I was stuck when I wanted to enable UserManagedAccess for my
> service. The PolicyEnforcerConfig.UserManagedAccessConfig is an empty
> class and I couldn't figure how to properly add it in the
> application.properties file. I've tried to add various things in
> application.properties like this, but none of them helped:
>
> keycloak.policy-enforcer-config.user-managed-access
> keycloak.policy-enforcer-config.user-managed-access=
> keycloak.policy-enforcer-config.user-managed-access= (Just left single
> space here after equals character)


> As a workaround, I ended with having separate bean to do it
> programatically -
>
> https://github.com/mposolda/devconf2019-authz/blob/master/devconf2019-service/src/main/java/org/keycloak/quickstarts/devconf2019/config/KeycloakUMAConfigResolver.java
> . Is it a bug or is it just me doing something stupid?
>

He had some feedback in the past about that too, but the workaround you did
is what people are doing. I've created
https://issues.jboss.org/browse/KEYCLOAK-9458.

Similar issue we have when you just want to enable the policy-enforcer
without any configuration. You need to specify at least one property of
policy-enforcer (or create a bean).


>
>
> - I wonder about possible improvements of keycloak-authz.js and if
> usability can be a bit improved? More specifically I mean this:
> -- Handling of the 401 response with UMA ticket from resource-server -
> Can this be done "automatically"? I meant the flow described here:
>
> https://www.keycloak.org/docs/latest/authorization_services/index.html#handling-authorization-responses-from-a-uma-protected-resource-server
> . Maybe the keycloak-authz itself can just handle the response from
> resource server, then send the AuthorizationRequest to KC with the UMA
> ticket and then possibly re-send the request to resource-server with new
> RPT and do this "automatically" without a need to manually handle it by
> the application like this:
>
> https://github.com/keycloak/keycloak-quickstarts/blob/latest/app-authz-uma-photoz/photoz-html5-client/src/main/webapp/js/app.js#L154-L208
> . WDYT?
>

We had that before, but due to some changes in UMA specs, I decided to
remove this capability from the adapter. We can discuss to get it back
again.


>
> -- Another thing is refreshing of RPT. It looks that RPT response
> contains the refresh token, so refreshing of RPTs is possible. However
> the keycloak-authz.js client doesn't have any support for automatically
> refreshing RPT token. I mean something similar, which is provided by
> keycloak.js itself (method "keycloak.updateToken" which automatically
> refreshes the token if needed). Due this limitation, it seems there is a
> bug in our quickstart. When you try the quickstart
> "app-authz-uma-photoz" and you go through the flow like this:
> - Open http://localhost:8080/photoz-html5-client and login as jdoe
> - Create some album
> - Wait 10 minutes (RPT expiration is same like AccessTokenLifespan, so 5
> minutes by default)
> - Try to create some album again - now fails with 403 due the RPT
> expired and no support for refreshing it in the keycloak-authz.js or the
> application itself.
> Should I create JIRA for this?
>

Yes, please.


>
>
> - It seems we don't have any Java based adapter for the frontend clients
> written in Java? We have Java based authorization client, but that
> provides just sending REST requests. It doesn't provide things like I
> mentioned above though (Storing RPT, automatically refreshing RPT,
> Automatically handling 401 response with the UMA ticket from
> resource-server and sending the request to KC etc). Any plan to have this?
>

Could we leverage the authz client for that ? If you could create a JIRA
with more details about the scenarios we are trying to support, we can
start thinking about a solution.

Thanks !


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

From psilva at redhat.com  Wed Jan 30 08:40:49 2019
From: psilva at redhat.com (Pedro Igor Silva)
Date: Wed, 30 Jan 2019 11:40:49 -0200
Subject: [keycloak-dev] Better support for "scope" in adapters
In-Reply-To: <e01a6dc8-3163-f132-835b-713b8cfdfc62@redhat.com>
References: <3030a267-b2b6-7a76-3020-42959ef344c5@redhat.com>
	<CAJrcDBep7ScX4O7G5fSh5oPhsbT9B5-ekqhF01MKiikZXB9ywg@mail.gmail.com>
	<e01a6dc8-3163-f132-835b-713b8cfdfc62@redhat.com>
Message-ID: <CAJrcDBfNE8_8wSDCSrhvcnDa80w1=q=Ngm8wOae5pi9YERKqig@mail.gmail.com>

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.

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

From Gideon.Caranzo at gemalto.com  Wed Jan 30 15:10:02 2019
From: Gideon.Caranzo at gemalto.com (Caranzo Gideon)
Date: Wed, 30 Jan 2019 20:10:02 +0000
Subject: [keycloak-dev] passing SAML extensions and context to custom
 authenticators
Message-ID: <DB6PR01MB376549A18375D1C794EE96FA86900@DB6PR01MB3765.eurprd01.prod.exchangelabs.com>

Hi Hynek,

Thank you for your response. Yes, I agree with you. It would be good to have this mechanism in those areas as well.

I already have a PR ready for just the SAML login portion. Is it fine with you if I submit this first so that we can use it as early as possible? We can create a separate ticket to implement similar mechanism for other SAML messages and broker endpoint which can be done in near future.

Thanks,
Gideon

-----Original Message-----
From: keycloak-dev-bounces at lists.jboss.org [mailto:keycloak-dev-bounces at lists.jboss.org] On Behalf Of Hynek Mlnarik
Sent: Thursday, January 24, 2019 1:58 AM
To: Gideon Caranzo <gideonray at gmail.com>
Cc: keycloak-dev <keycloak-dev at lists.jboss.org>
Subject: Re: [keycloak-dev] passing SAML extensions and context to custom authenticators

Hi Gideon,

thanks for the idea. Something like that would be a useful enhancement. The implementation would need to cover also the broker endpoint, other SAML message types (extensions are part of message types other than AuthnRequest as well), and count on several implementations of the hypothetical SamlAuthenticationPreprocessor. Could you please file an "Enhancement" JIRA?

--Hynek

On Wed, Jan 16, 2019 at 5:49 PM Gideon Caranzo <gideonray at gmail.com> wrote:

> Hi All,
>
> I'd like to propose a feature that allows custom authenticators to
> handle SAML extensions, authentication context and other request attributes.
>
> Right now in OIDC, all request claims are passed to custom
> authenticators which allows for customized behavior depending on the claims.
> However, this is not the case for SAML. Only attributes that are
> explicitly set (e.g. NameID) in the auth session are passed to custom authenticators.
>
> Information like SAML extension and authentication context are not
> available which limits the ability to define custom behaviors. In the
> past, we ran into similar limitation and we had to update keycloak
> core to add support for NameID attribute.
>
> To solve this, we can have an optional hook that pre-process SAML
> login request right before authentication. The hook can then extract
> the needed attributes and set it accordingly for custom authenticators to process.
>
> The pre-processing will be done in
> *SamlService.BindingProtocol.loginRequest()*:
>
> *public* *class* SamlService *extends* AuthorizationEndpointBase {
>
>     *. . .*
>
>     *public* *abstract* *class* BindingProtocol {
>
>         . . .
>
>         *protected* Response loginRequest(String relayState,
> AuthnRequestType requestAbstractType, ClientModel client) {
>
>             . . .
>
>             SamlAuthenticationPreprocessor preProcessor = session
> .getProvider(SamlAuthenticationPreprocessor.*class*);
>
>             *if* (preProcessor != *null*) {
>
>               preProcessor.process(requestAbstractType, authSession);
>
>             }
>
>
>
>             *return* newBrowserAuthentication(authSession,
> requestAbstractType.isIsPassive(), redirectToAuthentication);
>
>        }
>
>
> Let me know what you think. Thanks.
>
> Best regards,
> Gideon
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flis
> ts.jboss.org%2Fmailman%2Flistinfo%2Fkeycloak-dev&amp;data=02%7C01%7Cgi
> deon.caranzo%40gemalto.com%7C6f947d88676b4f788b2108d681d1d529%7C37d0a9
> db7c464096bfe31add5b495d6d%7C0%7C0%7C636839135555784466&amp;sdata=Yhpx
> 28KFJWJGa1kv1ROWWqJd3nt60YvAb0YmeKUU5Mg%3D&amp;reserved=0
>
_______________________________________________
keycloak-dev mailing list
keycloak-dev at lists.jboss.org
https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.jboss.org%2Fmailman%2Flistinfo%2Fkeycloak-dev&amp;data=02%7C01%7Cgideon.caranzo%40gemalto.com%7C6f947d88676b4f788b2108d681d1d529%7C37d0a9db7c464096bfe31add5b495d6d%7C0%7C0%7C636839135555784466&amp;sdata=Yhpx28KFJWJGa1kv1ROWWqJd3nt60YvAb0YmeKUU5Mg%3D&amp;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 mposolda at redhat.com  Wed Jan 30 15:23:51 2019
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 30 Jan 2019 21:23:51 +0100
Subject: [keycloak-dev] Authz services feedback
In-Reply-To: <CAJrcDBft7awbeby96aJdTOQpVJJaaYTCuxeBF72_3kJHMUVVFQ@mail.gmail.com>
References: <eb9f0892-df6f-204a-ea3a-520590cc34b2@redhat.com>
	<CAJrcDBft7awbeby96aJdTOQpVJJaaYTCuxeBF72_3kJHMUVVFQ@mail.gmail.com>
Message-ID: <c7d446ef-6267-16de-9935-e24ea65ae36a@redhat.com>

On 30/01/2019 12:29, Pedro Igor Silva wrote:
> Thanks for the feedback, Marek. Kudos to you too for talking about 
> this stuff.
>
> Answers inline.
>
> On Wed, Jan 30, 2019 at 8:39 AM Marek Posolda <mposolda at redhat.com 
> <mailto:mposolda at redhat.com>> wrote:
>
>     I recently have a chance to play a bit more with authz services when
>     preparing for the devconf demo. Great stuff and cudos to Pedro and
>     all
>     the others who contributed to authorization services!
>
>     I just have few questions and possible suggestions to improve in the
>     future :) Also based on some questions and discussion I had after
>     the talk:
>
>     - My REST service was SpringBoot based and protected by policy
>     enforced
>     configured in the applications.properties like this
>     https://github.com/mposolda/devconf2019-authz/blob/master/devconf2019-service/src/main/resources/application.properties#L23-L32
>
>     . However I was stuck when I wanted to enable UserManagedAccess
>     for my
>     service. The PolicyEnforcerConfig.UserManagedAccessConfig is an empty
>     class and I couldn't figure how to properly add it in the
>     application.properties file. I've tried to add various things in
>     application.properties like this, but none of them helped:
>
>     keycloak.policy-enforcer-config.user-managed-access
>     keycloak.policy-enforcer-config.user-managed-access=
>     keycloak.policy-enforcer-config.user-managed-access= (Just left
>     single
>     space here after equals character) 
>
>
>     As a workaround, I ended with having separate bean to do it
>     programatically -
>     https://github.com/mposolda/devconf2019-authz/blob/master/devconf2019-service/src/main/java/org/keycloak/quickstarts/devconf2019/config/KeycloakUMAConfigResolver.java
>
>     . Is it a bug or is it just me doing something stupid?
>
>
> He had some feedback in the past about that too, but the workaround 
> you did is what people are doing. I've created 
> https://issues.jboss.org/browse/KEYCLOAK-9458.
>
> Similar issue we have when you just want to enable the policy-enforcer 
> without any configuration. You need to specify at least one property 
> of policy-enforcer (or create a bean).
>
>
>
>     - I wonder about possible improvements of keycloak-authz.js and if
>     usability can be a bit improved? More specifically I mean this:
>     -- Handling of the 401 response with UMA ticket from
>     resource-server -
>     Can this be done "automatically"? I meant the flow described here:
>     https://www.keycloak.org/docs/latest/authorization_services/index.html#handling-authorization-responses-from-a-uma-protected-resource-server
>
>     . Maybe the keycloak-authz itself can just handle the response from
>     resource server, then send the AuthorizationRequest to KC with the
>     UMA
>     ticket and then possibly re-send the request to resource-server
>     with new
>     RPT and do this "automatically" without a need to manually handle
>     it by
>     the application like this:
>     https://github.com/keycloak/keycloak-quickstarts/blob/latest/app-authz-uma-photoz/photoz-html5-client/src/main/webapp/js/app.js#L154-L208
>
>     . WDYT?
>
>
> We had that before, but due to some changes in UMA specs, I decided to 
> remove this capability from the adapter. We can discuss to get it back 
> again.

I was thinking that adapter can provide some utility, which will provide 
refreshing of RPT tokens (in case they are expired) and also exchanging 
UMA tickets, which were returned from resource-server for new RPT.

For example adapter can have some utility like "rptProvider", which will 
do something like this (it will be better to have proper state diagram, 
but hopefully you won't be lost in those conditions. Imagine that from 
the point 1, you can go to 1.1 or 1.2):

1) check if there is existing RPT stored. If yes, it will:
1.1) Check if existing RPT is expired. If yes, it will:
1.1.1) try to refresh RPT. If refresh success, then adapter will store 
refreshed RPT and go to (1.2)
1.1.2) If refresh fails, adapter will delete the existing RPT and go to 
step 2
1.2) If existing RPT is not expired, adapter will just call that 
particular "onSuccess" callback method with the RPT
2) If there is no RPT, adapter will use it's accessToken to call 
authorization API
2.1) If calling authorization API fails, there should be "onAuthzError" 
callback called with the error message sent to it as argument (For 
example "request_submitted", so that caller is aware that request was 
saved on KC side to be approved by the resource owner)
2.2) If calling authorization API succeeds, we will store RPT and go to 
(1.2)

--- The "onSuccess" callback will usually invoke the REST service with 
RPT, but service can return UMA ticket in case that RPT is missing some 
permissions. In that case, it should call some builtin function provided 
by the authz client, which will:
3) Try to "parse" the UMA ticket from the response.
3.1) If it's not there, we need to call some "onOtherError" callback method
3.2) If it's there, we will use that UMA ticket to call authorization 
API - hence go again to step 2


Some pseudo-code how the usage of it can look like:

var rptProvider = keycloakAuthzClient.getRptProvider();

// This is the maximum timeout allowed before "rpt" needs to be refreshed
rptProvider.setTokenMinimumTimeToLive(10);

// The "rpt" is guaranteed to NOT be expired. However it may not contain 
permissions needed to invoke resource-server
rptProvider.onSuccess = function(rpt) {
 ??? // Just call the REST service
 ??? var url = 'http://localhost:8080/resource-server';

 ??? var req = new XMLHttpRequest();
 ??? req.open('GET', url, true);
 ??? req.setRequestHeader('Accept', 'application/json');
 ??? req.setRequestHeader('Authorization', 'Bearer ' + rpt);

 ??? req.onreadystatechange = function () {
 ??????? if (req.readyState == 4) {
 ??????????? if (req.status == 200) {
 ??????????????? alert('Success');
 ??????????? } else if (req.status == 401) {
 ??????????????? // We MAY have UMA ticket in the response. Let's just 
call "rptProvider.setUmaResponse" and then re-call "run" .
 ??????????????? // Internally, the adapter will try to parse UMA ticket 
from the response and exchange this UMA ticket for the RPT from KC server
 ??????????????? rptProvider.setUmaResponse(req);
 ??????????????? rptProvider.run();
 ??????????? }
 ??????? }
 ??? }

 ??? req.send();

});

// This callback is called when the call to KC authorization API failed.
// The authzError can be for example "request_submitted", so the caller 
is aware that request was created on Keycloak side and needs to be 
approved by the resource owner
rptProvider.onAuthzError(function(authzError) {

});

// This callback is called on any other error. For example when 
resource-server returns some other error response than "401" with UMA ticket
rptProvider.onOtherError(function(errorDetails) {

});

// This will trigger the described flow
rptProvider.run();


>
>     -- Another thing is refreshing of RPT. It looks that RPT response
>     contains the refresh token, so refreshing of RPTs is possible.
>     However
>     the keycloak-authz.js client doesn't have any support for
>     automatically
>     refreshing RPT token. I mean something similar, which is provided by
>     keycloak.js itself (method "keycloak.updateToken" which automatically
>     refreshes the token if needed). Due this limitation, it seems
>     there is a
>     bug in our quickstart. When you try the quickstart
>     "app-authz-uma-photoz" and you go through the flow like this:
>     - Open http://localhost:8080/photoz-html5-client and login as jdoe
>     - Create some album
>     - Wait 10 minutes (RPT expiration is same like
>     AccessTokenLifespan, so 5
>     minutes by default)
>     - Try to create some album again - now fails with 403 due the RPT
>     expired and no support for refreshing it in the keycloak-authz.js
>     or the
>     application itself.
>     Should I create JIRA for this?
>
>
> Yes, please.
Created https://issues.jboss.org/browse/KEYCLOAK-9464
>
>
>
>     - It seems we don't have any Java based adapter for the frontend
>     clients
>     written in Java? We have Java based authorization client, but that
>     provides just sending REST requests. It doesn't provide things like I
>     mentioned above though (Storing RPT, automatically refreshing RPT,
>     Automatically handling 401 response with the UMA ticket from
>     resource-server and sending the request to KC etc). Any plan to
>     have this?
>
>
> Could we leverage the authz client for that ? If you could create a 
> JIRA with more details about the scenarios we are trying to support, 
> we can start thinking about a solution.

I was thinking about something quite similar like the javascript client 
(keycloak-authz.js) will provide. If we agree on the javascript client, 
hopefully java can have something similar.

Marek

>
> Thanks !
>
>
>     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 psilva at redhat.com  Wed Jan 30 15:40:01 2019
From: psilva at redhat.com (Pedro Igor Silva)
Date: Wed, 30 Jan 2019 18:40:01 -0200
Subject: [keycloak-dev] Authz services feedback
In-Reply-To: <c7d446ef-6267-16de-9935-e24ea65ae36a@redhat.com>
References: <eb9f0892-df6f-204a-ea3a-520590cc34b2@redhat.com>
	<CAJrcDBft7awbeby96aJdTOQpVJJaaYTCuxeBF72_3kJHMUVVFQ@mail.gmail.com>
	<c7d446ef-6267-16de-9935-e24ea65ae36a@redhat.com>
Message-ID: <CAJrcDBe=PF4oW_Bp1ZL7si2g-NziDa9TdHL_AWEUX6BSJtVTvQ@mail.gmail.com>

+1 for keycloak-authz.js related changes.

Regarding the java adapter, I think we could leverage our java authz client
for that. So, +1 for a JIRA.

On Wed, Jan 30, 2019 at 6:23 PM Marek Posolda <mposolda at redhat.com> wrote:

> On 30/01/2019 12:29, Pedro Igor Silva wrote:
>
> Thanks for the feedback, Marek. Kudos to you too for talking about this
> stuff.
>
> Answers inline.
>
> On Wed, Jan 30, 2019 at 8:39 AM Marek Posolda <mposolda at redhat.com> wrote:
>
>> I recently have a chance to play a bit more with authz services when
>> preparing for the devconf demo. Great stuff and cudos to Pedro and all
>> the others who contributed to authorization services!
>>
>> I just have few questions and possible suggestions to improve in the
>> future :) Also based on some questions and discussion I had after the
>> talk:
>>
>> - My REST service was SpringBoot based and protected by policy enforced
>> configured in the applications.properties like this
>>
>> https://github.com/mposolda/devconf2019-authz/blob/master/devconf2019-service/src/main/resources/application.properties#L23-L32
>> . However I was stuck when I wanted to enable UserManagedAccess for my
>> service. The PolicyEnforcerConfig.UserManagedAccessConfig is an empty
>> class and I couldn't figure how to properly add it in the
>> application.properties file. I've tried to add various things in
>> application.properties like this, but none of them helped:
>>
>> keycloak.policy-enforcer-config.user-managed-access
>> keycloak.policy-enforcer-config.user-managed-access=
>> keycloak.policy-enforcer-config.user-managed-access= (Just left single
>> space here after equals character)
>
>
>> As a workaround, I ended with having separate bean to do it
>> programatically -
>>
>> https://github.com/mposolda/devconf2019-authz/blob/master/devconf2019-service/src/main/java/org/keycloak/quickstarts/devconf2019/config/KeycloakUMAConfigResolver.java
>> . Is it a bug or is it just me doing something stupid?
>>
>
> He had some feedback in the past about that too, but the workaround you
> did is what people are doing. I've created
> https://issues.jboss.org/browse/KEYCLOAK-9458.
>
> Similar issue we have when you just want to enable the policy-enforcer
> without any configuration. You need to specify at least one property of
> policy-enforcer (or create a bean).
>
>
>>
>>
>> - I wonder about possible improvements of keycloak-authz.js and if
>> usability can be a bit improved? More specifically I mean this:
>> -- Handling of the 401 response with UMA ticket from resource-server -
>> Can this be done "automatically"? I meant the flow described here:
>>
>> https://www.keycloak.org/docs/latest/authorization_services/index.html#handling-authorization-responses-from-a-uma-protected-resource-server
>> . Maybe the keycloak-authz itself can just handle the response from
>> resource server, then send the AuthorizationRequest to KC with the UMA
>> ticket and then possibly re-send the request to resource-server with new
>> RPT and do this "automatically" without a need to manually handle it by
>> the application like this:
>>
>> https://github.com/keycloak/keycloak-quickstarts/blob/latest/app-authz-uma-photoz/photoz-html5-client/src/main/webapp/js/app.js#L154-L208
>> . WDYT?
>>
>
> We had that before, but due to some changes in UMA specs, I decided to
> remove this capability from the adapter. We can discuss to get it back
> again.
>
> I was thinking that adapter can provide some utility, which will provide
> refreshing of RPT tokens (in case they are expired) and also exchanging UMA
> tickets, which were returned from resource-server for new RPT.
>
> For example adapter can have some utility like "rptProvider", which will
> do something like this (it will be better to have proper state diagram, but
> hopefully you won't be lost in those conditions. Imagine that from the
> point 1, you can go to 1.1 or 1.2):
>
> 1) check if there is existing RPT stored. If yes, it will:
> 1.1) Check if existing RPT is expired. If yes, it will:
> 1.1.1) try to refresh RPT. If refresh success, then adapter will store
> refreshed RPT and go to (1.2)
> 1.1.2) If refresh fails, adapter will delete the existing RPT and go to
> step 2
> 1.2) If existing RPT is not expired, adapter will just call that
> particular "onSuccess" callback method with the RPT
> 2) If there is no RPT, adapter will use it's accessToken to call
> authorization API
> 2.1) If calling authorization API fails, there should be "onAuthzError"
> callback called with the error message sent to it as argument (For example
> "request_submitted", so that caller is aware that request was saved on KC
> side to be approved by the resource owner)
> 2.2) If calling authorization API succeeds, we will store RPT and go to
> (1.2)
>
> --- The "onSuccess" callback will usually invoke the REST service with
> RPT, but service can return UMA ticket in case that RPT is missing some
> permissions. In that case, it should call some builtin function provided by
> the authz client, which will:
> 3) Try to "parse" the UMA ticket from the response.
> 3.1) If it's not there, we need to call some "onOtherError" callback method
> 3.2) If it's there, we will use that UMA ticket to call authorization API
> - hence go again to step 2
>
>
> Some pseudo-code how the usage of it can look like:
>
> var rptProvider = keycloakAuthzClient.getRptProvider();
>
> // This is the maximum timeout allowed before "rpt" needs to be refreshed
> rptProvider.setTokenMinimumTimeToLive(10);
>
> // The "rpt" is guaranteed to NOT be expired. However it may not contain
> permissions needed to invoke resource-server
> rptProvider.onSuccess = function(rpt) {
>     // Just call the REST service
>     var url = 'http://localhost:8080/resource-server';
>
>     var req = new XMLHttpRequest();
>     req.open('GET', url, true);
>     req.setRequestHeader('Accept', 'application/json');
>     req.setRequestHeader('Authorization', 'Bearer ' + rpt);
>
>     req.onreadystatechange = function () {
>         if (req.readyState == 4) {
>             if (req.status == 200) {
>                 alert('Success');
>             } else if (req.status == 401) {
>                 // We MAY have UMA ticket in the response. Let's just call
> "rptProvider.setUmaResponse" and then re-call "run" .
>                 // Internally, the adapter will try to parse UMA ticket
> from the response and exchange this UMA ticket for the RPT from KC server
>                 rptProvider.setUmaResponse(req);
>                 rptProvider.run();
>             }
>         }
>     }
>
>     req.send();
>
> });
>
> // This callback is called when the call to KC authorization API failed.
> // The authzError can be for example "request_submitted", so the caller is
> aware that request was created on Keycloak side and needs to be approved by
> the resource owner
> rptProvider.onAuthzError(function(authzError) {
>
> });
>
> // This callback is called on any other error. For example when
> resource-server returns some other error response than "401" with UMA ticket
> rptProvider.onOtherError(function(errorDetails) {
>
> });
>
> // This will trigger the described flow
> rptProvider.run();
>
>
>
>
>>
>> -- Another thing is refreshing of RPT. It looks that RPT response
>> contains the refresh token, so refreshing of RPTs is possible. However
>> the keycloak-authz.js client doesn't have any support for automatically
>> refreshing RPT token. I mean something similar, which is provided by
>> keycloak.js itself (method "keycloak.updateToken" which automatically
>> refreshes the token if needed). Due this limitation, it seems there is a
>> bug in our quickstart. When you try the quickstart
>> "app-authz-uma-photoz" and you go through the flow like this:
>> - Open http://localhost:8080/photoz-html5-client and login as jdoe
>> - Create some album
>> - Wait 10 minutes (RPT expiration is same like AccessTokenLifespan, so 5
>> minutes by default)
>> - Try to create some album again - now fails with 403 due the RPT
>> expired and no support for refreshing it in the keycloak-authz.js or the
>> application itself.
>> Should I create JIRA for this?
>>
>
> Yes, please.
>
> Created https://issues.jboss.org/browse/KEYCLOAK-9464
>
>
>
>>
>>
>> - It seems we don't have any Java based adapter for the frontend clients
>> written in Java? We have Java based authorization client, but that
>> provides just sending REST requests. It doesn't provide things like I
>> mentioned above though (Storing RPT, automatically refreshing RPT,
>> Automatically handling 401 response with the UMA ticket from
>> resource-server and sending the request to KC etc). Any plan to have this?
>>
>
> Could we leverage the authz client for that ? If you could create a JIRA
> with more details about the scenarios we are trying to support, we can
> start thinking about a solution.
>
> I was thinking about something quite similar like the javascript client
> (keycloak-authz.js) will provide. If we agree on the javascript client,
> hopefully java can have something similar.
>
> Marek
>
>
> Thanks !
>
>
>>
>> Marek
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>

From priyadarshini.chandra at gmail.com  Wed Jan 30 16:59:45 2019
From: priyadarshini.chandra at gmail.com (Priyadarshini Chandra)
Date: Wed, 30 Jan 2019 13:59:45 -0800
Subject: [keycloak-dev] IDP initiated flow redirect not working
Message-ID: <CAL4NoYbBWOL8KgAcchqkkd6OR7_TrkK=hx11kH3uz7nU9q9MmQ@mail.gmail.com>

I am trying to implement below workflow for SAML auth using Keycloak:

1. User is logged-in to external website.
2. User clicks on the link for Service Provider which redirects the user to
Keycloak for SAML authentication. It is a HTTP POST Request with
SAMLResponse and RelayState.
3. Keycloak should validate the SAML token ,create session etc and redirect
the user to the Service provider application.

I have tried the IDP initiated Login flow and Client creation steps.
1.Created one IDP - idp1
2.Created a client - client1, master SAML points to idp1 endpoint.
3.Sending the HTTP Request with
SAMLResponse:"../broker/idp1/endpoint/clients/client1"
 RelayState: Service provider application page.
We are stuck at the point where getting error "You are already
authenticated as different user 'testuser' in this session. Please logout
first."
It looks like session and user is getting created.
What should be the correct flow.

From dt at acutus.pro  Thu Jan 31 04:59:48 2019
From: dt at acutus.pro (Dmitry Telegin)
Date: Thu, 31 Jan 2019 12:59:48 +0300
Subject: [keycloak-dev] Authz services feedback
In-Reply-To: <CAJrcDBft7awbeby96aJdTOQpVJJaaYTCuxeBF72_3kJHMUVVFQ@mail.gmail.com>
References: <eb9f0892-df6f-204a-ea3a-520590cc34b2@redhat.com>
	<CAJrcDBft7awbeby96aJdTOQpVJJaaYTCuxeBF72_3kJHMUVVFQ@mail.gmail.com>
Message-ID: <1548928788.3759.3.camel@acutus.pro>

My 2?: I've been recently tasked with creating a Spring Boot + Keycloak authz PoC. Somehow I've overlooked the existing app-authz-rest-springboot and did everything from scratch, which allowed me to discover many surprising bugs/features/snags (hope you'll help me to tell one from another).

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.

2. When configuring path-based resource, I have automatically put double quotes around the path like this:

keycloak.policy-enforcer-config.paths[0].path="/path"

Then I've killed some hours debugging the adapter trying to figure out why this wouldn't work, only to discover that the quotes are passed to the variables verbatim, i.e. including quotes. I think this is not something?Keycloak specific, but maybe it could be worth mentioning in the docs,?in order to help folks avoid frustrating experiences like mine.

3. {request.body[...]} pushed claim is totally broken. It drains out the servlet input stream before the control is passed to the underlying service, so when the service tries to process the request (which is, ehm, what services normally do) you will get something like "org.springframework.http.converter.HttpMessageNotReadableException: Required request body is missing". It's a well-known issue that servlet input streams are not rewindable, so I don't see any?other solution than caching the whole request body in the memory and passing down a request wrapper.

As a cherry on top, it fails to recognize JSON request body, since it tries matching against "application/json" constant (RequestPlaceHolderResolver.java:125), and the browser would normally send something like "application/json; charset=UTF-8".

4. In JavaScript policies, $evaluation.context.identity.attributes has different meaning depending on whether the policy is used in authz or fine-grained permissions. In the first case it maps to the token claims, in the second to the custom attributes. Is this by design? It would be nice to have a unified API for both claims and attributes.

5. Let's say we need to implement a fine-grained permission for groups, which can be expressed as "a group admin is a user who 1) is a direct member of this group, 2) has a specific role, like group-admin". The first part can be implemented as a JS policy, but in order to obtain a GroupModel we'll need to parse resource name (which will be like "group.resource.e14f96e4-e06e-411f-bbdf-507e264dc33d"), extract group ID and finally call $evaluation.authorizationProvider.realm.getGroupById().

For authz resources used in fine-grained permissions, can we have a kind of link to the model object, or something like unwrap() method that would return the same?

Sorry for lengthy message, and again thanks a lot Pedro! Authorization services is a real power feature, and your contribution has been invaluable.

Kind regards,
Dmitry Telegin
CTO, Acutus s.r.o.

On Wed, 2019-01-30 at 09:29 -0200, Pedro Igor Silva wrote:
> Thanks for the feedback, Marek. Kudos to you too for talking about this
> stuff.
> 
> Answers inline.
> 
> > On Wed, Jan 30, 2019 at 8:39 AM Marek Posolda <mposolda at redhat.com> wrote:
> 
> > I recently have a chance to play a bit more with authz services when
> > preparing for the devconf demo. Great stuff and cudos to Pedro and all
> > the others who contributed to authorization services!
> > 
> > I just have few questions and possible suggestions to improve in the
> > future :) Also based on some questions and discussion I had after the talk:
> > 
> > - My REST service was SpringBoot based and protected by policy enforced
> > configured in the applications.properties like this
> > 
> > https://github.com/mposolda/devconf2019-authz/blob/master/devconf2019-service/src/main/resources/application.properties#L23-L32
> > . However I was stuck when I wanted to enable UserManagedAccess for my
> > service. The PolicyEnforcerConfig.UserManagedAccessConfig is an empty
> > class and I couldn't figure how to properly add it in the
> > application.properties file. I've tried to add various things in
> > application.properties like this, but none of them helped:
> > 
> > keycloak.policy-enforcer-config.user-managed-access
> > keycloak.policy-enforcer-config.user-managed-access=
> > keycloak.policy-enforcer-config.user-managed-access= (Just left single
> > space here after equals character)
> 
> 
> > As a workaround, I ended with having separate bean to do it
> > programatically -
> > 
> > https://github.com/mposolda/devconf2019-authz/blob/master/devconf2019-service/src/main/java/org/keycloak/quickstarts/devconf2019/config/KeycloakUMAConfigResolver.java
> > . Is it a bug or is it just me doing something stupid?
> > 
> 
> He had some feedback in the past about that too, but the workaround you did
> is what people are doing. I've created
> https://issues.jboss.org/browse/KEYCLOAK-9458.
> 
> Similar issue we have when you just want to enable the policy-enforcer
> without any configuration. You need to specify at least one property of
> policy-enforcer (or create a bean).
> 
> 
> > 
> > 
> > - I wonder about possible improvements of keycloak-authz.js and if
> > usability can be a bit improved? More specifically I mean this:
> > -- Handling of the 401 response with UMA ticket from resource-server -
> > Can this be done "automatically"? I meant the flow described here:
> > 
> > https://www.keycloak.org/docs/latest/authorization_services/index.html#handling-authorization-responses-from-a-uma-protected-resource-server
> > . Maybe the keycloak-authz itself can just handle the response from
> > resource server, then send the AuthorizationRequest to KC with the UMA
> > ticket and then possibly re-send the request to resource-server with new
> > RPT and do this "automatically" without a need to manually handle it by
> > the application like this:
> > 
> > https://github.com/keycloak/keycloak-quickstarts/blob/latest/app-authz-uma-photoz/photoz-html5-client/src/main/webapp/js/app.js#L154-L208
> > . WDYT?
> > 
> 
> We had that before, but due to some changes in UMA specs, I decided to
> remove this capability from the adapter. We can discuss to get it back
> again.
> 
> 
> > 
> > -- Another thing is refreshing of RPT. It looks that RPT response
> > contains the refresh token, so refreshing of RPTs is possible. However
> > the keycloak-authz.js client doesn't have any support for automatically
> > refreshing RPT token. I mean something similar, which is provided by
> > keycloak.js itself (method "keycloak.updateToken" which automatically
> > refreshes the token if needed). Due this limitation, it seems there is a
> > bug in our quickstart. When you try the quickstart
> > "app-authz-uma-photoz" and you go through the flow like this:
> > > > - Open http://localhost:8080/photoz-html5-client and login as jdoe
> > - Create some album
> > - Wait 10 minutes (RPT expiration is same like AccessTokenLifespan, so 5
> > minutes by default)
> > - Try to create some album again - now fails with 403 due the RPT
> > expired and no support for refreshing it in the keycloak-authz.js or the
> > application itself.
> > Should I create JIRA for this?
> > 
> 
> Yes, please.
> 
> 
> > 
> > 
> > - It seems we don't have any Java based adapter for the frontend clients
> > written in Java? We have Java based authorization client, but that
> > provides just sending REST requests. It doesn't provide things like I
> > mentioned above though (Storing RPT, automatically refreshing RPT,
> > Automatically handling 401 response with the UMA ticket from
> > resource-server and sending the request to KC etc). Any plan to have this?
> > 
> 
> Could we leverage the authz client for that ? If you could create a JIRA
> with more details about the scenarios we are trying to support, we can
> start thinking about a solution.
> 
> Thanks !
> 
> 
> > 
> > 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 mposolda at redhat.com  Thu Jan 31 05:47:59 2019
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 31 Jan 2019 11:47:59 +0100
Subject: [keycloak-dev] Authz services feedback
In-Reply-To: <1548928788.3759.3.camel@acutus.pro>
References: <eb9f0892-df6f-204a-ea3a-520590cc34b2@redhat.com>
	<CAJrcDBft7awbeby96aJdTOQpVJJaaYTCuxeBF72_3kJHMUVVFQ@mail.gmail.com>
	<1548928788.3759.3.camel@acutus.pro>
Message-ID: <54b32a06-aa98-1876-8666-9c92b56bba00@redhat.com>

On 31/01/2019 10:59, Dmitry Telegin wrote:
> My 2?: I've been recently tasked with creating a Spring Boot + Keycloak authz PoC. Somehow I've overlooked the existing app-authz-rest-springboot and did everything from scratch, which allowed me to discover many surprising bugs/features/snags (hope you'll help me to tell one from another).
>
> 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.

hmmm... Did you try enforcement-mode PERMISSIVE? I think that with that 
setting, the enforcer will check just those URLs, which are mentioned 
there. For all the other URLs, policy enforcer just "ignores" them and 
hence just the "default" adapter checking is used (security constraint 
and hence simple RBAC based protection).

For example when I had configuration like this 
(https://github.com/mposolda/devconf2019-authz/blob/master/devconf2019-service/src/main/resources/application.properties#L23-L26 
- assume that everything from line 28 down was commented), then enforcer 
just protected "/cars/create" URL, but all the others like "/cars/view" 
were ignored by policy enforcer.

Marek

>
> 2. When configuring path-based resource, I have automatically put double quotes around the path like this:
>
> keycloak.policy-enforcer-config.paths[0].path="/path"
>
> Then I've killed some hours debugging the adapter trying to figure out why this wouldn't work, only to discover that the quotes are passed to the variables verbatim, i.e. including quotes. I think this is not something?Keycloak specific, but maybe it could be worth mentioning in the docs,?in order to help folks avoid frustrating experiences like mine.
>
> 3. {request.body[...]} pushed claim is totally broken. It drains out the servlet input stream before the control is passed to the underlying service, so when the service tries to process the request (which is, ehm, what services normally do) you will get something like "org.springframework.http.converter.HttpMessageNotReadableException: Required request body is missing". It's a well-known issue that servlet input streams are not rewindable, so I don't see any?other solution than caching the whole request body in the memory and passing down a request wrapper.
>
> As a cherry on top, it fails to recognize JSON request body, since it tries matching against "application/json" constant (RequestPlaceHolderResolver.java:125), and the browser would normally send something like "application/json; charset=UTF-8".
>
> 4. In JavaScript policies, $evaluation.context.identity.attributes has different meaning depending on whether the policy is used in authz or fine-grained permissions. In the first case it maps to the token claims, in the second to the custom attributes. Is this by design? It would be nice to have a unified API for both claims and attributes.
>
> 5. Let's say we need to implement a fine-grained permission for groups, which can be expressed as "a group admin is a user who 1) is a direct member of this group, 2) has a specific role, like group-admin". The first part can be implemented as a JS policy, but in order to obtain a GroupModel we'll need to parse resource name (which will be like "group.resource.e14f96e4-e06e-411f-bbdf-507e264dc33d"), extract group ID and finally call $evaluation.authorizationProvider.realm.getGroupById().
>
> For authz resources used in fine-grained permissions, can we have a kind of link to the model object, or something like unwrap() method that would return the same?
>
> Sorry for lengthy message, and again thanks a lot Pedro! Authorization services is a real power feature, and your contribution has been invaluable.
>
> Kind regards,
> Dmitry Telegin
> CTO, Acutus s.r.o.
>
> On Wed, 2019-01-30 at 09:29 -0200, Pedro Igor Silva wrote:
>> Thanks for the feedback, Marek. Kudos to you too for talking about this
>> stuff.
>>
>> Answers inline.
>>
>>> On Wed, Jan 30, 2019 at 8:39 AM Marek Posolda <mposolda at redhat.com> wrote:
>>> I recently have a chance to play a bit more with authz services when
>>> preparing for the devconf demo. Great stuff and cudos to Pedro and all
>>> the others who contributed to authorization services!
>>>
>>> I just have few questions and possible suggestions to improve in the
>>> future :) Also based on some questions and discussion I had after the talk:
>>>
>>> - My REST service was SpringBoot based and protected by policy enforced
>>> configured in the applications.properties like this
>>>
>>> https://github.com/mposolda/devconf2019-authz/blob/master/devconf2019-service/src/main/resources/application.properties#L23-L32
>>> . However I was stuck when I wanted to enable UserManagedAccess for my
>>> service. The PolicyEnforcerConfig.UserManagedAccessConfig is an empty
>>> class and I couldn't figure how to properly add it in the
>>> application.properties file. I've tried to add various things in
>>> application.properties like this, but none of them helped:
>>>
>>> keycloak.policy-enforcer-config.user-managed-access
>>> keycloak.policy-enforcer-config.user-managed-access=
>>> keycloak.policy-enforcer-config.user-managed-access= (Just left single
>>> space here after equals character)
>>
>>> As a workaround, I ended with having separate bean to do it
>>> programatically -
>>>
>>> https://github.com/mposolda/devconf2019-authz/blob/master/devconf2019-service/src/main/java/org/keycloak/quickstarts/devconf2019/config/KeycloakUMAConfigResolver.java
>>> . Is it a bug or is it just me doing something stupid?
>>>
>> He had some feedback in the past about that too, but the workaround you did
>> is what people are doing. I've created
>> https://issues.jboss.org/browse/KEYCLOAK-9458.
>>
>> Similar issue we have when you just want to enable the policy-enforcer
>> without any configuration. You need to specify at least one property of
>> policy-enforcer (or create a bean).
>>
>>
>>>
>>> - I wonder about possible improvements of keycloak-authz.js and if
>>> usability can be a bit improved? More specifically I mean this:
>>> -- Handling of the 401 response with UMA ticket from resource-server -
>>> Can this be done "automatically"? I meant the flow described here:
>>>
>>> https://www.keycloak.org/docs/latest/authorization_services/index.html#handling-authorization-responses-from-a-uma-protected-resource-server
>>> . Maybe the keycloak-authz itself can just handle the response from
>>> resource server, then send the AuthorizationRequest to KC with the UMA
>>> ticket and then possibly re-send the request to resource-server with new
>>> RPT and do this "automatically" without a need to manually handle it by
>>> the application like this:
>>>
>>> https://github.com/keycloak/keycloak-quickstarts/blob/latest/app-authz-uma-photoz/photoz-html5-client/src/main/webapp/js/app.js#L154-L208
>>> . WDYT?
>>>
>> We had that before, but due to some changes in UMA specs, I decided to
>> remove this capability from the adapter. We can discuss to get it back
>> again.
>>
>>
>>> -- Another thing is refreshing of RPT. It looks that RPT response
>>> contains the refresh token, so refreshing of RPTs is possible. However
>>> the keycloak-authz.js client doesn't have any support for automatically
>>> refreshing RPT token. I mean something similar, which is provided by
>>> keycloak.js itself (method "keycloak.updateToken" which automatically
>>> refreshes the token if needed). Due this limitation, it seems there is a
>>> bug in our quickstart. When you try the quickstart
>>> "app-authz-uma-photoz" and you go through the flow like this:
>>>>> - Open http://localhost:8080/photoz-html5-client and login as jdoe
>>> - Create some album
>>> - Wait 10 minutes (RPT expiration is same like AccessTokenLifespan, so 5
>>> minutes by default)
>>> - Try to create some album again - now fails with 403 due the RPT
>>> expired and no support for refreshing it in the keycloak-authz.js or the
>>> application itself.
>>> Should I create JIRA for this?
>>>
>> Yes, please.
>>
>>
>>>
>>> - It seems we don't have any Java based adapter for the frontend clients
>>> written in Java? We have Java based authorization client, but that
>>> provides just sending REST requests. It doesn't provide things like I
>>> mentioned above though (Storing RPT, automatically refreshing RPT,
>>> Automatically handling 401 response with the UMA ticket from
>>> resource-server and sending the request to KC etc). Any plan to have this?
>>>
>> Could we leverage the authz client for that ? If you could create a JIRA
>> with more details about the scenarios we are trying to support, we can
>> start thinking about a solution.
>>
>> Thanks !
>>
>>
>>> 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 dt at acutus.pro  Thu Jan 31 06:59:03 2019
From: dt at acutus.pro (Dmitry Telegin)
Date: Thu, 31 Jan 2019 14:59:03 +0300
Subject: [keycloak-dev] Authz services feedback
In-Reply-To: <54b32a06-aa98-1876-8666-9c92b56bba00@redhat.com>
References: <eb9f0892-df6f-204a-ea3a-520590cc34b2@redhat.com>
	<CAJrcDBft7awbeby96aJdTOQpVJJaaYTCuxeBF72_3kJHMUVVFQ@mail.gmail.com>
	<1548928788.3759.3.camel@acutus.pro>
	<54b32a06-aa98-1876-8666-9c92b56bba00@redhat.com>
Message-ID: <1548935943.3759.6.camel@acutus.pro>

Hi Marek,

Setting enforcement-mode=PERMISSIVE was the first thing I've tried, obviously :)

By "public endpoint" I mean completely unsecured (i.e. not mentioned under adapter's security constraints), so in the context of your example that would be something like "/bikes".

Dmitry

On Thu, 2019-01-31 at 11:47 +0100, Marek Posolda wrote:
> On 31/01/2019 10:59, Dmitry Telegin wrote:
> > My 2?: I've been recently tasked with creating a Spring Boot + Keycloak authz PoC. Somehow I've overlooked the existing app-authz-rest-springboot and did everything from scratch, which allowed me to discover many surprising bugs/features/snags (hope you'll help me to tell one from another).
> > 
> > 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.
> 
> hmmm... Did you try enforcement-mode PERMISSIVE? I think that with that?
> setting, the enforcer will check just those URLs, which are mentioned?
> there. For all the other URLs, policy enforcer just "ignores" them and?
> hence just the "default" adapter checking is used (security constraint?
> and hence simple RBAC based protection).
> 
> For example when I had configuration like this?
> (https://github.com/mposolda/devconf2019-authz/blob/master/devconf2019-service/src/main/resources/application.properties#L23-L26?
> - assume that everything from line 28 down was commented), then enforcer?
> just protected "/cars/create" URL, but all the others like "/cars/view"?
> were ignored by policy enforcer.
> 
> Marek
> 
> > 
> > 2. When configuring path-based resource, I have automatically put double quotes around the path like this:
> > 
> > keycloak.policy-enforcer-config.paths[0].path="/path"
> > 
> > Then I've killed some hours debugging the adapter trying to figure out why this wouldn't work, only to discover that the quotes are passed to the variables verbatim, i.e. including quotes. I think this is not something?Keycloak specific, but maybe it could be worth mentioning in the docs,?in order to help folks avoid frustrating experiences like mine.
> > 
> > 3. {request.body[...]} pushed claim is totally broken. It drains out the servlet input stream before the control is passed to the underlying service, so when the service tries to process the request (which is, ehm, what services normally do) you will get something like "org.springframework.http.converter.HttpMessageNotReadableException: Required request body is missing". It's a well-known issue that servlet input streams are not rewindable, so I don't see any?other solution than caching the whole request body in the memory and passing down a request wrapper.
> > 
> > As a cherry on top, it fails to recognize JSON request body, since it tries matching against "application/json" constant (RequestPlaceHolderResolver.java:125), and the browser would normally send something like "application/json; charset=UTF-8".
> > 
> > 4. In JavaScript policies, $evaluation.context.identity.attributes has different meaning depending on whether the policy is used in authz or fine-grained permissions. In the first case it maps to the token claims, in the second to the custom attributes. Is this by design? It would be nice to have a unified API for both claims and attributes.
> > 
> > 5. Let's say we need to implement a fine-grained permission for groups, which can be expressed as "a group admin is a user who 1) is a direct member of this group, 2) has a specific role, like group-admin". The first part can be implemented as a JS policy, but in order to obtain a GroupModel we'll need to parse resource name (which will be like "group.resource.e14f96e4-e06e-411f-bbdf-507e264dc33d"), extract group ID and finally call $evaluation.authorizationProvider.realm.getGroupById().
> > 
> > For authz resources used in fine-grained permissions, can we have a kind of link to the model object, or something like unwrap() method that would return the same?
> > 
> > Sorry for lengthy message, and again thanks a lot Pedro! Authorization services is a real power feature, and your contribution has been invaluable.
> > 
> > Kind regards,
> > Dmitry Telegin
> > CTO, Acutus s.r.o.
> > 
> > On Wed, 2019-01-30 at 09:29 -0200, Pedro Igor Silva wrote:
> > > Thanks for the feedback, Marek. Kudos to you too for talking about this
> > > stuff.
> > > 
> > > Answers inline.
> > > 
> > > > On Wed, Jan 30, 2019 at 8:39 AM Marek Posolda <mposolda at redhat.com> wrote:
> > > > I recently have a chance to play a bit more with authz services when
> > > > preparing for the devconf demo. Great stuff and cudos to Pedro and all
> > > > the others who contributed to authorization services!
> > > > 
> > > > I just have few questions and possible suggestions to improve in the
> > > > future :) Also based on some questions and discussion I had after the talk:
> > > > 
> > > > - My REST service was SpringBoot based and protected by policy enforced
> > > > configured in the applications.properties like this
> > > > 
> > > > https://github.com/mposolda/devconf2019-authz/blob/master/devconf2019-service/src/main/resources/application.properties#L23-L32
> > > > . However I was stuck when I wanted to enable UserManagedAccess for my
> > > > service. The PolicyEnforcerConfig.UserManagedAccessConfig is an empty
> > > > class and I couldn't figure how to properly add it in the
> > > > application.properties file. I've tried to add various things in
> > > > application.properties like this, but none of them helped:
> > > > 
> > > > keycloak.policy-enforcer-config.user-managed-access
> > > > keycloak.policy-enforcer-config.user-managed-access=
> > > > keycloak.policy-enforcer-config.user-managed-access= (Just left single
> > > > space here after equals character)
> > > > As a workaround, I ended with having separate bean to do it
> > > > programatically -
> > > > 
> > > > https://github.com/mposolda/devconf2019-authz/blob/master/devconf2019-service/src/main/java/org/keycloak/quickstarts/devconf2019/config/KeycloakUMAConfigResolver.java
> > > > . Is it a bug or is it just me doing something stupid?
> > > > 
> > > 
> > > He had some feedback in the past about that too, but the workaround you did
> > > is what people are doing. I've created
> > > https://issues.jboss.org/browse/KEYCLOAK-9458.
> > > 
> > > Similar issue we have when you just want to enable the policy-enforcer
> > > without any configuration. You need to specify at least one property of
> > > policy-enforcer (or create a bean).
> > > 
> > > 
> > > > 
> > > > - I wonder about possible improvements of keycloak-authz.js and if
> > > > usability can be a bit improved? More specifically I mean this:
> > > > -- Handling of the 401 response with UMA ticket from resource-server -
> > > > Can this be done "automatically"? I meant the flow described here:
> > > > 
> > > > https://www.keycloak.org/docs/latest/authorization_services/index.html#handling-authorization-responses-from-a-uma-protected-resource-server
> > > > . Maybe the keycloak-authz itself can just handle the response from
> > > > resource server, then send the AuthorizationRequest to KC with the UMA
> > > > ticket and then possibly re-send the request to resource-server with new
> > > > RPT and do this "automatically" without a need to manually handle it by
> > > > the application like this:
> > > > 
> > > > https://github.com/keycloak/keycloak-quickstarts/blob/latest/app-authz-uma-photoz/photoz-html5-client/src/main/webapp/js/app.js#L154-L208
> > > > . WDYT?
> > > > 
> > > 
> > > We had that before, but due to some changes in UMA specs, I decided to
> > > remove this capability from the adapter. We can discuss to get it back
> > > again.
> > > 
> > > 
> > > > -- Another thing is refreshing of RPT. It looks that RPT response
> > > > contains the refresh token, so refreshing of RPTs is possible. However
> > > > the keycloak-authz.js client doesn't have any support for automatically
> > > > refreshing RPT token. I mean something similar, which is provided by
> > > > keycloak.js itself (method "keycloak.updateToken" which automatically
> > > > refreshes the token if needed). Due this limitation, it seems there is a
> > > > bug in our quickstart. When you try the quickstart
> > > > "app-authz-uma-photoz" and you go through the flow like this:
> > > > > > - Open http://localhost:8080/photoz-html5-client and login as jdoe
> > > > 
> > > > - Create some album
> > > > - Wait 10 minutes (RPT expiration is same like AccessTokenLifespan, so 5
> > > > minutes by default)
> > > > - Try to create some album again - now fails with 403 due the RPT
> > > > expired and no support for refreshing it in the keycloak-authz.js or the
> > > > application itself.
> > > > Should I create JIRA for this?
> > > > 
> > > 
> > > Yes, please.
> > > 
> > > 
> > > > 
> > > > - It seems we don't have any Java based adapter for the frontend clients
> > > > written in Java? We have Java based authorization client, but that
> > > > provides just sending REST requests. It doesn't provide things like I
> > > > mentioned above though (Storing RPT, automatically refreshing RPT,
> > > > Automatically handling 401 response with the UMA ticket from
> > > > resource-server and sending the request to KC etc). Any plan to have this?
> > > > 
> > > 
> > > Could we leverage the authz client for that ? If you could create a JIRA
> > > with more details about the scenarios we are trying to support, we can
> > > start thinking about a solution.
> > > 
> > > Thanks !
> > > 
> > > 
> > > > 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 psilva at redhat.com  Thu Jan 31 07:19:05 2019
From: psilva at redhat.com (Pedro Igor Silva)
Date: Thu, 31 Jan 2019 10:19:05 -0200
Subject: [keycloak-dev] Authz services feedback
In-Reply-To: <1548928788.3759.3.camel@acutus.pro>
References: <eb9f0892-df6f-204a-ea3a-520590cc34b2@redhat.com>
	<CAJrcDBft7awbeby96aJdTOQpVJJaaYTCuxeBF72_3kJHMUVVFQ@mail.gmail.com>
	<1548928788.3759.3.camel@acutus.pro>
Message-ID: <CAJrcDBdR6MzY6nvp6DBcWsWMYMzkketdxOWOGz9wOiTf3h2kWQ@mail.gmail.com>

I appreciate the feedback, Dmitry. Answers in line.

Overall, I think some if the things you mentioned are related with the fact
that we don't have proper tests in our testsuite for SB/SS adapters. That
is something we discussed internally and should be focusing this year.

On Thu, Jan 31, 2019 at 8:00 AM Dmitry Telegin <dt at acutus.pro> wrote:

> My 2?: I've been recently tasked with creating a Spring Boot + Keycloak
> authz PoC. Somehow I've overlooked the existing app-authz-rest-springboot
> and did everything from scratch, which allowed me to discover many
> surprising bugs/features/snags (hope you'll help me to tell one from
> another).
>
> 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.


>
> 2. When configuring path-based resource, I have automatically put double
> quotes around the path like this:
>
> keycloak.policy-enforcer-config.paths[0].path="/path"
>
> Then I've killed some hours debugging the adapter trying to figure out why
> this wouldn't work, only to discover that the quotes are passed to the
> variables verbatim, i.e. including quotes. I think this is not
> something Keycloak specific, but maybe it could be worth mentioning in the
> docs, in order to help folks avoid frustrating experiences like mine.
>

Does this work for properties other than policy-enforcer related ones ?


>
> 3. {request.body[...]} pushed claim is totally broken. It drains out the
> servlet input stream before the control is passed to the underlying
> service, so when the service tries to process the request (which is, ehm,
> what services normally do) you will get something like
> "org.springframework.http.converter.HttpMessageNotReadableException:
> Required request body is missing". It's a well-known issue that servlet
> input streams are not rewindable, so I don't see any other solution than
> caching the whole request body in the memory and passing down a request
> wrapper.


> As a cherry on top, it fails to recognize JSON request body, since it
> tries matching against "application/json" constant
> (RequestPlaceHolderResolver.java:125), and the browser would normally send
> something like "application/json; charset=UTF-8".
>

Other adapters should be fine as we are testing this and for these
adapters, I think we are properly managing the inputstream. Would you mind
creating a JIRA ?


>
> 4. In JavaScript policies, $evaluation.context.identity.attributes has
> different meaning depending on whether the policy is used in authz or
> fine-grained permissions. In the first case it maps to the token claims, in
> the second to the custom attributes. Is this by design? It would be nice to
> have a unified API for both claims and attributes.
>

Not really by design, but a consequence of lack of alignment between these
two capabilites. Being admin permissions based on authz. There is a JIRA
[1] for that.

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


>
> 5. Let's say we need to implement a fine-grained permission for groups,
> which can be expressed as "a group admin is a user who 1) is a direct
> member of this group, 2) has a specific role, like group-admin". The first
> part can be implemented as a JS policy, but in order to obtain a GroupModel
> we'll need to parse resource name (which will be like
> "group.resource.e14f96e4-e06e-411f-bbdf-507e264dc33d"), extract group ID
> and finally call $evaluation.authorizationProvider.realm.getGroupById().
>
> For authz resources used in fine-grained permissions, can we have a kind
> of link to the model object, or something like unwrap() method that would
> return the same?
>

Do you mean provide some method to return the actual instance backed by a
resource (e.g: group, role, client, user, etc) ? Considering that this is
specific to fine-grained permissions in admin console ....

If so, I think we could do so. Could you also create a RFE for this one ?


>
> Sorry for lengthy message, and again thanks a lot Pedro! Authorization
> services is a real power feature, and your contribution has been invaluable.
>

That is the beauty of open source ... Collaboration and sharing of ideas :)

Thank you.


>
> Kind regards,
> Dmitry Telegin
> CTO, Acutus s.r.o.
>
> On Wed, 2019-01-30 at 09:29 -0200, Pedro Igor Silva wrote:
> > Thanks for the feedback, Marek. Kudos to you too for talking about this
> > stuff.
> >
> > Answers inline.
> >
> > > On Wed, Jan 30, 2019 at 8:39 AM Marek Posolda <mposolda at redhat.com>
> wrote:
> >
> > > I recently have a chance to play a bit more with authz services when
> > > preparing for the devconf demo. Great stuff and cudos to Pedro and all
> > > the others who contributed to authorization services!
> > >
> > > I just have few questions and possible suggestions to improve in the
> > > future :) Also based on some questions and discussion I had after the
> talk:
> > >
> > > - My REST service was SpringBoot based and protected by policy enforced
> > > configured in the applications.properties like this
> > >
> > >
> https://github.com/mposolda/devconf2019-authz/blob/master/devconf2019-service/src/main/resources/application.properties#L23-L32
> > > . However I was stuck when I wanted to enable UserManagedAccess for my
> > > service. The PolicyEnforcerConfig.UserManagedAccessConfig is an empty
> > > class and I couldn't figure how to properly add it in the
> > > application.properties file. I've tried to add various things in
> > > application.properties like this, but none of them helped:
> > >
> > > keycloak.policy-enforcer-config.user-managed-access
> > > keycloak.policy-enforcer-config.user-managed-access=
> > > keycloak.policy-enforcer-config.user-managed-access= (Just left single
> > > space here after equals character)
> >
> >
> > > As a workaround, I ended with having separate bean to do it
> > > programatically -
> > >
> > >
> https://github.com/mposolda/devconf2019-authz/blob/master/devconf2019-service/src/main/java/org/keycloak/quickstarts/devconf2019/config/KeycloakUMAConfigResolver.java
> > > . Is it a bug or is it just me doing something stupid?
> > >
> >
> > He had some feedback in the past about that too, but the workaround you
> did
> > is what people are doing. I've created
> > https://issues.jboss.org/browse/KEYCLOAK-9458.
> >
> > Similar issue we have when you just want to enable the policy-enforcer
> > without any configuration. You need to specify at least one property of
> > policy-enforcer (or create a bean).
> >
> >
> > >
> > >
> > > - I wonder about possible improvements of keycloak-authz.js and if
> > > usability can be a bit improved? More specifically I mean this:
> > > -- Handling of the 401 response with UMA ticket from resource-server -
> > > Can this be done "automatically"? I meant the flow described here:
> > >
> > >
> https://www.keycloak.org/docs/latest/authorization_services/index.html#handling-authorization-responses-from-a-uma-protected-resource-server
> > > . Maybe the keycloak-authz itself can just handle the response from
> > > resource server, then send the AuthorizationRequest to KC with the UMA
> > > ticket and then possibly re-send the request to resource-server with
> new
> > > RPT and do this "automatically" without a need to manually handle it by
> > > the application like this:
> > >
> > >
> https://github.com/keycloak/keycloak-quickstarts/blob/latest/app-authz-uma-photoz/photoz-html5-client/src/main/webapp/js/app.js#L154-L208
> > > . WDYT?
> > >
> >
> > We had that before, but due to some changes in UMA specs, I decided to
> > remove this capability from the adapter. We can discuss to get it back
> > again.
> >
> >
> > >
> > > -- Another thing is refreshing of RPT. It looks that RPT response
> > > contains the refresh token, so refreshing of RPTs is possible. However
> > > the keycloak-authz.js client doesn't have any support for automatically
> > > refreshing RPT token. I mean something similar, which is provided by
> > > keycloak.js itself (method "keycloak.updateToken" which automatically
> > > refreshes the token if needed). Due this limitation, it seems there is
> a
> > > bug in our quickstart. When you try the quickstart
> > > "app-authz-uma-photoz" and you go through the flow like this:
> > > > > - Open http://localhost:8080/photoz-html5-client and login as jdoe
> > > - Create some album
> > > - Wait 10 minutes (RPT expiration is same like AccessTokenLifespan, so
> 5
> > > minutes by default)
> > > - Try to create some album again - now fails with 403 due the RPT
> > > expired and no support for refreshing it in the keycloak-authz.js or
> the
> > > application itself.
> > > Should I create JIRA for this?
> > >
> >
> > Yes, please.
> >
> >
> > >
> > >
> > > - It seems we don't have any Java based adapter for the frontend
> clients
> > > written in Java? We have Java based authorization client, but that
> > > provides just sending REST requests. It doesn't provide things like I
> > > mentioned above though (Storing RPT, automatically refreshing RPT,
> > > Automatically handling 401 response with the UMA ticket from
> > > resource-server and sending the request to KC etc). Any plan to have
> this?
> > >
> >
> > Could we leverage the authz client for that ? If you could create a JIRA
> > with more details about the scenarios we are trying to support, we can
> > start thinking about a solution.
> >
> > Thanks !
> >
> >
> > >
> > > 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 alexis.almeida at gmail.com  Thu Jan 31 07:21:09 2019
From: alexis.almeida at gmail.com (Alexis Almeida)
Date: Thu, 31 Jan 2019 10:21:09 -0200
Subject: [keycloak-dev] Improve search by a specific user in the admin
	console
Message-ID: <CA+H6wMw6o3rYTbSDfOqOq4QzOy4pdjSOopruWRdYsDKWxs4tbg@mail.gmail.com>

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 {

From mposolda at redhat.com  Thu Jan 31 07:26:53 2019
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 31 Jan 2019 13:26:53 +0100
Subject: [keycloak-dev] Authz services feedback
In-Reply-To: <CAJrcDBe=PF4oW_Bp1ZL7si2g-NziDa9TdHL_AWEUX6BSJtVTvQ@mail.gmail.com>
References: <eb9f0892-df6f-204a-ea3a-520590cc34b2@redhat.com>
	<CAJrcDBft7awbeby96aJdTOQpVJJaaYTCuxeBF72_3kJHMUVVFQ@mail.gmail.com>
	<c7d446ef-6267-16de-9935-e24ea65ae36a@redhat.com>
	<CAJrcDBe=PF4oW_Bp1ZL7si2g-NziDa9TdHL_AWEUX6BSJtVTvQ@mail.gmail.com>
Message-ID: <62893849-3070-83a8-ee08-ae9ca6db4766@redhat.com>

Cool, so I created:
https://issues.jboss.org/browse/KEYCLOAK-9468 - Improve 
keycloak-authz.js to automatically exchange UMA tickets and refresh tokens
https://issues.jboss.org/browse/KEYCLOAK-9469 - Improve authorization 
java client to support automatically exchange UMA tickets and refresh 
RPT tokens

Already created yesterday for a bug in quickstarts (cased by expired 
RPT): https://issues.jboss.org/browse/KEYCLOAK-9464 app-authz-uma-photoz 
quickstart doesn't handle expired RPT

Marek

On 30/01/2019 21:40, Pedro Igor Silva wrote:
> +1 for keycloak-authz.js related changes.
>
> Regarding the java adapter, I think we could leverage our 
> java?authz?client for that. So,?+1 for a JIRA.
>
> On Wed, Jan 30, 2019 at 6:23 PM Marek Posolda <mposolda at redhat.com 
> <mailto:mposolda at redhat.com>> wrote:
>
>     On 30/01/2019 12:29, Pedro Igor Silva wrote:
>>     Thanks for the feedback, Marek. Kudos to you too for talking
>>     about this stuff.
>>
>>     Answers inline.
>>
>>     On Wed, Jan 30, 2019 at 8:39 AM Marek Posolda
>>     <mposolda at redhat.com <mailto:mposolda at redhat.com>> wrote:
>>
>>         I recently have a chance to play a bit more with authz
>>         services when
>>         preparing for the devconf demo. Great stuff and cudos to
>>         Pedro and all
>>         the others who contributed to authorization services!
>>
>>         I just have few questions and possible suggestions to improve
>>         in the
>>         future :) Also based on some questions and discussion I had
>>         after the talk:
>>
>>         - My REST service was SpringBoot based and protected by
>>         policy enforced
>>         configured in the applications.properties like this
>>         https://github.com/mposolda/devconf2019-authz/blob/master/devconf2019-service/src/main/resources/application.properties#L23-L32
>>
>>         . However I was stuck when I wanted to enable
>>         UserManagedAccess for my
>>         service. The PolicyEnforcerConfig.UserManagedAccessConfig is
>>         an empty
>>         class and I couldn't figure how to properly add it in the
>>         application.properties file. I've tried to add various things in
>>         application.properties like this, but none of them helped:
>>
>>         keycloak.policy-enforcer-config.user-managed-access
>>         keycloak.policy-enforcer-config.user-managed-access=
>>         keycloak.policy-enforcer-config.user-managed-access= (Just
>>         left single
>>         space here after equals character) 
>>
>>
>>         As a workaround, I ended with having separate bean to do it
>>         programatically -
>>         https://github.com/mposolda/devconf2019-authz/blob/master/devconf2019-service/src/main/java/org/keycloak/quickstarts/devconf2019/config/KeycloakUMAConfigResolver.java
>>
>>         . Is it a bug or is it just me doing something stupid?
>>
>>
>>     He had some feedback in the past about that too, but the
>>     workaround you did is what people are doing. I've created
>>     https://issues.jboss.org/browse/KEYCLOAK-9458.
>>
>>     Similar issue we have when you just want to enable the
>>     policy-enforcer without any configuration. You need to specify at
>>     least one property of policy-enforcer (or create a bean).
>>
>>
>>
>>         - I wonder about possible improvements of keycloak-authz.js
>>         and if
>>         usability can be a bit improved? More specifically I mean this:
>>         -- Handling of the 401 response with UMA ticket from
>>         resource-server -
>>         Can this be done "automatically"? I meant the flow described
>>         here:
>>         https://www.keycloak.org/docs/latest/authorization_services/index.html#handling-authorization-responses-from-a-uma-protected-resource-server
>>
>>         . Maybe the keycloak-authz itself can just handle the
>>         response from
>>         resource server, then send the AuthorizationRequest to KC
>>         with the UMA
>>         ticket and then possibly re-send the request to
>>         resource-server with new
>>         RPT and do this "automatically" without a need to manually
>>         handle it by
>>         the application like this:
>>         https://github.com/keycloak/keycloak-quickstarts/blob/latest/app-authz-uma-photoz/photoz-html5-client/src/main/webapp/js/app.js#L154-L208
>>
>>         . WDYT?
>>
>>
>>     We had that before, but due to some changes in UMA specs, I
>>     decided to remove this capability from the adapter. We can
>>     discuss to get it back again.
>
>     I was thinking that adapter can provide some utility, which will
>     provide refreshing of RPT tokens (in case they are expired) and
>     also exchanging UMA tickets, which were returned from
>     resource-server for new RPT.
>
>     For example adapter can have some utility like "rptProvider",
>     which will do something like this (it will be better to have
>     proper state diagram, but hopefully you won't be lost in those
>     conditions. Imagine that from the point 1, you can go to 1.1 or 1.2):
>
>     1) check if there is existing RPT stored. If yes, it will:
>     1.1) Check if existing RPT is expired. If yes, it will:
>     1.1.1) try to refresh RPT. If refresh success, then adapter will
>     store refreshed RPT and go to (1.2)
>     1.1.2) If refresh fails, adapter will delete the existing RPT and
>     go to step 2
>     1.2) If existing RPT is not expired, adapter will just call that
>     particular "onSuccess" callback method with the RPT
>     2) If there is no RPT, adapter will use it's accessToken to call
>     authorization API
>     2.1) If calling authorization API fails, there should be
>     "onAuthzError" callback called with the error message sent to it
>     as argument (For example "request_submitted", so that caller is
>     aware that request was saved on KC side to be approved by the
>     resource owner)
>     2.2) If calling authorization API succeeds, we will store RPT and
>     go to (1.2)
>
>     --- The "onSuccess" callback will usually invoke the REST service
>     with RPT, but service can return UMA ticket in case that RPT is
>     missing some permissions. In that case, it should call some
>     builtin function provided by the authz client, which will:
>     3) Try to "parse" the UMA ticket from the response.
>     3.1) If it's not there, we need to call some "onOtherError"
>     callback method
>     3.2) If it's there, we will use that UMA ticket to call
>     authorization API - hence go again to step 2
>
>
>     Some pseudo-code how the usage of it can look like:
>
>     var rptProvider = keycloakAuthzClient.getRptProvider();
>
>     // This is the maximum timeout allowed before "rpt" needs to be
>     refreshed
>     rptProvider.setTokenMinimumTimeToLive(10);
>
>     // The "rpt" is guaranteed to NOT be expired. However it may not
>     contain permissions needed to invoke resource-server
>     rptProvider.onSuccess = function(rpt) {
>     ??? // Just call the REST service
>     ??? var url = 'http://localhost:8080/resource-server';
>
>     ??? var req = new XMLHttpRequest();
>     ??? req.open('GET', url, true);
>     ??? req.setRequestHeader('Accept', 'application/json');
>     ??? req.setRequestHeader('Authorization', 'Bearer ' + rpt);
>
>     ??? req.onreadystatechange = function () {
>     ??????? if (req.readyState == 4) {
>     ??????????? if (req.status == 200) {
>     ??????????????? alert('Success');
>     ??????????? } else if (req.status == 401) {
>     ??????????????? // We MAY have UMA ticket in the response. Let's
>     just call "rptProvider.setUmaResponse" and then re-call "run" .
>     ??????????????? // Internally, the adapter will try to parse UMA
>     ticket from the response and exchange this UMA ticket for the RPT
>     from KC server
>     ??????????????? rptProvider.setUmaResponse(req);
>     ??????????????? rptProvider.run();
>     ??????????? }
>     ??????? }
>     ??? }
>
>     ??? req.send();
>
>     });
>
>     // This callback is called when the call to KC authorization API
>     failed.
>     // The authzError can be for example "request_submitted", so the
>     caller is aware that request was created on Keycloak side and
>     needs to be approved by the resource owner
>     rptProvider.onAuthzError(function(authzError) {
>
>     });
>
>     // This callback is called on any other error. For example when
>     resource-server returns some other error response than "401" with
>     UMA ticket
>     rptProvider.onOtherError(function(errorDetails) {
>
>     });
>
>     // This will trigger the described flow
>     rptProvider.run();
>
>
>>
>>         -- Another thing is refreshing of RPT. It looks that RPT
>>         response
>>         contains the refresh token, so refreshing of RPTs is
>>         possible. However
>>         the keycloak-authz.js client doesn't have any support for
>>         automatically
>>         refreshing RPT token. I mean something similar, which is
>>         provided by
>>         keycloak.js itself (method "keycloak.updateToken" which
>>         automatically
>>         refreshes the token if needed). Due this limitation, it seems
>>         there is a
>>         bug in our quickstart. When you try the quickstart
>>         "app-authz-uma-photoz" and you go through the flow like this:
>>         - Open http://localhost:8080/photoz-html5-client and login as
>>         jdoe
>>         - Create some album
>>         - Wait 10 minutes (RPT expiration is same like
>>         AccessTokenLifespan, so 5
>>         minutes by default)
>>         - Try to create some album again - now fails with 403 due the
>>         RPT
>>         expired and no support for refreshing it in the
>>         keycloak-authz.js or the
>>         application itself.
>>         Should I create JIRA for this?
>>
>>
>>     Yes, please.
>     Created https://issues.jboss.org/browse/KEYCLOAK-9464
>>
>>
>>
>>         - It seems we don't have any Java based adapter for the
>>         frontend clients
>>         written in Java? We have Java based authorization client, but
>>         that
>>         provides just sending REST requests. It doesn't provide
>>         things like I
>>         mentioned above though (Storing RPT, automatically refreshing
>>         RPT,
>>         Automatically handling 401 response with the UMA ticket from
>>         resource-server and sending the request to KC etc). Any plan
>>         to have this?
>>
>>
>>     Could we leverage the authz client for that ? If you could create
>>     a JIRA with more details about the scenarios we are trying to
>>     support, we can start thinking about a solution.
>
>     I was thinking about something quite similar like the javascript
>     client (keycloak-authz.js) will provide. If we agree on the
>     javascript client, hopefully java can have something similar.
>
>     Marek
>
>>
>>     Thanks !
>>
>>
>>         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 mposolda at redhat.com  Thu Jan 31 07:43:39 2019
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 31 Jan 2019 13:43:39 +0100
Subject: [keycloak-dev] Better support for "scope" in adapters
In-Reply-To: <CAJrcDBfNE8_8wSDCSrhvcnDa80w1=q=Ngm8wOae5pi9YERKqig@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>
Message-ID: <a57ed42b-3f80-21e2-f4e6-7f434030bef4@redhat.com>

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


From ssilvert at redhat.com  Thu Jan 31 07:46:43 2019
From: ssilvert at redhat.com (Stan Silvert)
Date: Thu, 31 Jan 2019 07:46:43 -0500
Subject: [keycloak-dev] Improve search by a specific user in the admin
 console
In-Reply-To: <CA+H6wMw6o3rYTbSDfOqOq4QzOy4pdjSOopruWRdYsDKWxs4tbg@mail.gmail.com>
References: <CA+H6wMw6o3rYTbSDfOqOq4QzOy4pdjSOopruWRdYsDKWxs4tbg@mail.gmail.com>
Message-ID: <c7809c72-348b-b984-f3e9-8c8714e4c31d@redhat.com>

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 psilva at redhat.com  Thu Jan 31 08:07:38 2019
From: psilva at redhat.com (Pedro Igor Silva)
Date: Thu, 31 Jan 2019 11:07:38 -0200
Subject: [keycloak-dev] Better support for "scope" in adapters
In-Reply-To: <a57ed42b-3f80-21e2-f4e6-7f434030bef4@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>
Message-ID: <CAJrcDBcUuiuD4sm5UaXh-BTy70mf+ipR10oHFq08jTS7ntxeUQ@mail.gmail.com>

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.


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

From psilva at redhat.com  Thu Jan 31 08:08:03 2019
From: psilva at redhat.com (Pedro Igor Silva)
Date: Thu, 31 Jan 2019 11:08:03 -0200
Subject: [keycloak-dev] Authz services feedback
In-Reply-To: <62893849-3070-83a8-ee08-ae9ca6db4766@redhat.com>
References: <eb9f0892-df6f-204a-ea3a-520590cc34b2@redhat.com>
	<CAJrcDBft7awbeby96aJdTOQpVJJaaYTCuxeBF72_3kJHMUVVFQ@mail.gmail.com>
	<c7d446ef-6267-16de-9935-e24ea65ae36a@redhat.com>
	<CAJrcDBe=PF4oW_Bp1ZL7si2g-NziDa9TdHL_AWEUX6BSJtVTvQ@mail.gmail.com>
	<62893849-3070-83a8-ee08-ae9ca6db4766@redhat.com>
Message-ID: <CAJrcDBdP5maWQ1OZAzf97AKG=B8wW2dtbeHbYdHpg3M74_G3Ag@mail.gmail.com>

Thanks!

On Thu, Jan 31, 2019 at 10:26 AM Marek Posolda <mposolda at redhat.com> wrote:

> Cool, so I created:
> https://issues.jboss.org/browse/KEYCLOAK-9468 - Improve keycloak-authz.js
> to automatically exchange UMA tickets and refresh tokens
> https://issues.jboss.org/browse/KEYCLOAK-9469 - Improve authorization
> java client to support automatically exchange UMA tickets and refresh RPT
> tokens
>
> Already created yesterday for a bug in quickstarts (cased by expired RPT):
> https://issues.jboss.org/browse/KEYCLOAK-9464 app-authz-uma-photoz
> quickstart doesn't handle expired RPT
>
> Marek
>
> On 30/01/2019 21:40, Pedro Igor Silva wrote:
>
> +1 for keycloak-authz.js related changes.
>
> Regarding the java adapter, I think we could leverage our
> java authz client for that. So, +1 for a JIRA.
>
> On Wed, Jan 30, 2019 at 6:23 PM Marek Posolda <mposolda at redhat.com> wrote:
>
>> On 30/01/2019 12:29, Pedro Igor Silva wrote:
>>
>> Thanks for the feedback, Marek. Kudos to you too for talking about this
>> stuff.
>>
>> Answers inline.
>>
>> On Wed, Jan 30, 2019 at 8:39 AM Marek Posolda <mposolda at redhat.com>
>> wrote:
>>
>>> I recently have a chance to play a bit more with authz services when
>>> preparing for the devconf demo. Great stuff and cudos to Pedro and all
>>> the others who contributed to authorization services!
>>>
>>> I just have few questions and possible suggestions to improve in the
>>> future :) Also based on some questions and discussion I had after the
>>> talk:
>>>
>>> - My REST service was SpringBoot based and protected by policy enforced
>>> configured in the applications.properties like this
>>>
>>> https://github.com/mposolda/devconf2019-authz/blob/master/devconf2019-service/src/main/resources/application.properties#L23-L32
>>> . However I was stuck when I wanted to enable UserManagedAccess for my
>>> service. The PolicyEnforcerConfig.UserManagedAccessConfig is an empty
>>> class and I couldn't figure how to properly add it in the
>>> application.properties file. I've tried to add various things in
>>> application.properties like this, but none of them helped:
>>>
>>> keycloak.policy-enforcer-config.user-managed-access
>>> keycloak.policy-enforcer-config.user-managed-access=
>>> keycloak.policy-enforcer-config.user-managed-access= (Just left single
>>> space here after equals character)
>>
>>
>>> As a workaround, I ended with having separate bean to do it
>>> programatically -
>>>
>>> https://github.com/mposolda/devconf2019-authz/blob/master/devconf2019-service/src/main/java/org/keycloak/quickstarts/devconf2019/config/KeycloakUMAConfigResolver.java
>>> . Is it a bug or is it just me doing something stupid?
>>>
>>
>> He had some feedback in the past about that too, but the workaround you
>> did is what people are doing. I've created
>> https://issues.jboss.org/browse/KEYCLOAK-9458.
>>
>> Similar issue we have when you just want to enable the policy-enforcer
>> without any configuration. You need to specify at least one property of
>> policy-enforcer (or create a bean).
>>
>>
>>>
>>>
>>> - I wonder about possible improvements of keycloak-authz.js and if
>>> usability can be a bit improved? More specifically I mean this:
>>> -- Handling of the 401 response with UMA ticket from resource-server -
>>> Can this be done "automatically"? I meant the flow described here:
>>>
>>> https://www.keycloak.org/docs/latest/authorization_services/index.html#handling-authorization-responses-from-a-uma-protected-resource-server
>>> . Maybe the keycloak-authz itself can just handle the response from
>>> resource server, then send the AuthorizationRequest to KC with the UMA
>>> ticket and then possibly re-send the request to resource-server with new
>>> RPT and do this "automatically" without a need to manually handle it by
>>> the application like this:
>>>
>>> https://github.com/keycloak/keycloak-quickstarts/blob/latest/app-authz-uma-photoz/photoz-html5-client/src/main/webapp/js/app.js#L154-L208
>>> . WDYT?
>>>
>>
>> We had that before, but due to some changes in UMA specs, I decided to
>> remove this capability from the adapter. We can discuss to get it back
>> again.
>>
>> I was thinking that adapter can provide some utility, which will provide
>> refreshing of RPT tokens (in case they are expired) and also exchanging UMA
>> tickets, which were returned from resource-server for new RPT.
>>
>> For example adapter can have some utility like "rptProvider", which will
>> do something like this (it will be better to have proper state diagram, but
>> hopefully you won't be lost in those conditions. Imagine that from the
>> point 1, you can go to 1.1 or 1.2):
>>
>> 1) check if there is existing RPT stored. If yes, it will:
>> 1.1) Check if existing RPT is expired. If yes, it will:
>> 1.1.1) try to refresh RPT. If refresh success, then adapter will store
>> refreshed RPT and go to (1.2)
>> 1.1.2) If refresh fails, adapter will delete the existing RPT and go to
>> step 2
>> 1.2) If existing RPT is not expired, adapter will just call that
>> particular "onSuccess" callback method with the RPT
>> 2) If there is no RPT, adapter will use it's accessToken to call
>> authorization API
>> 2.1) If calling authorization API fails, there should be "onAuthzError"
>> callback called with the error message sent to it as argument (For example
>> "request_submitted", so that caller is aware that request was saved on KC
>> side to be approved by the resource owner)
>> 2.2) If calling authorization API succeeds, we will store RPT and go to
>> (1.2)
>>
>> --- The "onSuccess" callback will usually invoke the REST service with
>> RPT, but service can return UMA ticket in case that RPT is missing some
>> permissions. In that case, it should call some builtin function provided by
>> the authz client, which will:
>> 3) Try to "parse" the UMA ticket from the response.
>> 3.1) If it's not there, we need to call some "onOtherError" callback
>> method
>> 3.2) If it's there, we will use that UMA ticket to call authorization API
>> - hence go again to step 2
>>
>>
>> Some pseudo-code how the usage of it can look like:
>>
>> var rptProvider = keycloakAuthzClient.getRptProvider();
>>
>> // This is the maximum timeout allowed before "rpt" needs to be refreshed
>> rptProvider.setTokenMinimumTimeToLive(10);
>>
>> // The "rpt" is guaranteed to NOT be expired. However it may not contain
>> permissions needed to invoke resource-server
>> rptProvider.onSuccess = function(rpt) {
>>     // Just call the REST service
>>     var url = 'http://localhost:8080/resource-server';
>>
>>     var req = new XMLHttpRequest();
>>     req.open('GET', url, true);
>>     req.setRequestHeader('Accept', 'application/json');
>>     req.setRequestHeader('Authorization', 'Bearer ' + rpt);
>>
>>     req.onreadystatechange = function () {
>>         if (req.readyState == 4) {
>>             if (req.status == 200) {
>>                 alert('Success');
>>             } else if (req.status == 401) {
>>                 // We MAY have UMA ticket in the response. Let's just
>> call "rptProvider.setUmaResponse" and then re-call "run" .
>>                 // Internally, the adapter will try to parse UMA ticket
>> from the response and exchange this UMA ticket for the RPT from KC server
>>                 rptProvider.setUmaResponse(req);
>>                 rptProvider.run();
>>             }
>>         }
>>     }
>>
>>     req.send();
>>
>> });
>>
>> // This callback is called when the call to KC authorization API failed.
>> // The authzError can be for example "request_submitted", so the caller
>> is aware that request was created on Keycloak side and needs to be approved
>> by the resource owner
>> rptProvider.onAuthzError(function(authzError) {
>>
>> });
>>
>> // This callback is called on any other error. For example when
>> resource-server returns some other error response than "401" with UMA ticket
>> rptProvider.onOtherError(function(errorDetails) {
>>
>> });
>>
>> // This will trigger the described flow
>> rptProvider.run();
>>
>>
>>
>>
>>>
>>> -- Another thing is refreshing of RPT. It looks that RPT response
>>> contains the refresh token, so refreshing of RPTs is possible. However
>>> the keycloak-authz.js client doesn't have any support for automatically
>>> refreshing RPT token. I mean something similar, which is provided by
>>> keycloak.js itself (method "keycloak.updateToken" which automatically
>>> refreshes the token if needed). Due this limitation, it seems there is a
>>> bug in our quickstart. When you try the quickstart
>>> "app-authz-uma-photoz" and you go through the flow like this:
>>> - Open http://localhost:8080/photoz-html5-client and login as jdoe
>>> - Create some album
>>> - Wait 10 minutes (RPT expiration is same like AccessTokenLifespan, so 5
>>> minutes by default)
>>> - Try to create some album again - now fails with 403 due the RPT
>>> expired and no support for refreshing it in the keycloak-authz.js or the
>>> application itself.
>>> Should I create JIRA for this?
>>>
>>
>> Yes, please.
>>
>> Created https://issues.jboss.org/browse/KEYCLOAK-9464
>>
>>
>>
>>>
>>>
>>> - It seems we don't have any Java based adapter for the frontend clients
>>> written in Java? We have Java based authorization client, but that
>>> provides just sending REST requests. It doesn't provide things like I
>>> mentioned above though (Storing RPT, automatically refreshing RPT,
>>> Automatically handling 401 response with the UMA ticket from
>>> resource-server and sending the request to KC etc). Any plan to have
>>> this?
>>>
>>
>> Could we leverage the authz client for that ? If you could create a JIRA
>> with more details about the scenarios we are trying to support, we can
>> start thinking about a solution.
>>
>> I was thinking about something quite similar like the javascript client
>> (keycloak-authz.js) will provide. If we agree on the javascript client,
>> hopefully java can have something similar.
>>
>> Marek
>>
>>
>> Thanks !
>>
>>
>>>
>>> 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 Jan 31 08:14:53 2019
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 31 Jan 2019 14:14:53 +0100
Subject: [keycloak-dev] Better support for "scope" in adapters
In-Reply-To: <CAJrcDBcUuiuD4sm5UaXh-BTy70mf+ipR10oHFq08jTS7ntxeUQ@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>
Message-ID: <27b5cb1e-cbc0-e79d-03f8-2203cddcf9e3@redhat.com>

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


From dt at acutus.pro  Thu Jan 31 08:28:28 2019
From: dt at acutus.pro (Dmitry Telegin)
Date: Thu, 31 Jan 2019 16:28:28 +0300
Subject: [keycloak-dev] Authz services feedback
In-Reply-To: <CAJrcDBdR6MzY6nvp6DBcWsWMYMzkketdxOWOGz9wOiTf3h2kWQ@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>
Message-ID: <1548941308.3759.10.camel@acutus.pro>

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 psilva at redhat.com  Thu Jan 31 10:39:47 2019
From: psilva at redhat.com (Pedro Igor Silva)
Date: Thu, 31 Jan 2019 13:39:47 -0200
Subject: [keycloak-dev] Authz services feedback
In-Reply-To: <1548941308.3759.10.camel@acutus.pro>
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>
Message-ID: <CAJrcDBecMn3uhta7T4sBFs19Y25qWOqe+Ge-iH5fhjXGTCsvdg@mail.gmail.com>

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 psilva at redhat.com  Thu Jan 31 10:44:34 2019
From: psilva at redhat.com (Pedro Igor Silva)
Date: Thu, 31 Jan 2019 13:44:34 -0200
Subject: [keycloak-dev] Better support for "scope" in adapters
In-Reply-To: <27b5cb1e-cbc0-e79d-03f8-2203cddcf9e3@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>
Message-ID: <CAJrcDBcyu+OD4KH0NZ1C=Z81bi+s7GtaTE+Fv8zNSCyOSWLU7A@mail.gmail.com>

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