From Shankar_Bhaskaran at infosys.com  Wed Feb  1 04:26:19 2017
From: Shankar_Bhaskaran at infosys.com (Shankar_Bhaskaran)
Date: Wed, 1 Feb 2017 09:26:19 +0000
Subject: [keycloak-dev] Keycloak on active MQ
In-Reply-To: <a57e7653-d9ed-a1a1-6ea3-2eebcd67e163@psynd.net>
References: <a57e7653-d9ed-a1a1-6ea3-2eebcd67e163@psynd.net>
Message-ID: <1485941179202.13544@infosys.com>

Hi ,

We are using keycloak as SSO in our organization. I would like to know if securing activemq using keycloak is a valid use case. Does keycloak allow us to validate jms requests to the queue or topic?

Regards,
Shankar

From mposolda at redhat.com  Wed Feb  1 06:50:30 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 1 Feb 2017 12:50:30 +0100
Subject: [keycloak-dev] Keycloak on active MQ
In-Reply-To: <1485941179202.13544@infosys.com>
References: <a57e7653-d9ed-a1a1-6ea3-2eebcd67e163@psynd.net>
	<1485941179202.13544@infosys.com>
Message-ID: <aa7b4591-62cb-cbc3-92a7-0da7759e91e4@redhat.com>

I didn't try that yet. However I think it should work as ActiveMQ has 
some support for JAAS. We have some JAAS login modules, which can be 
used to secure those kind of services. See docs for details 
https://keycloak.gitbooks.io/securing-client-applications-guide/content/v/latest/topics/oidc/java/jaas.html 
.

Marek

On 01/02/17 10:26, Shankar_Bhaskaran wrote:
> Hi ,
>
> We are using keycloak as SSO in our organization. I would like to know if securing activemq using keycloak is a valid use case. Does keycloak allow us to validate jms requests to the queue or topic?
>
> Regards,
> Shankar
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



From sthorger at redhat.com  Wed Feb  1 07:01:39 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 1 Feb 2017 13:01:39 +0100
Subject: [keycloak-dev] JIRA issues to review for 2.5.0 and 2.5.1
Message-ID: <CAJgngAfmqVD=e1y914D-D7Kyktt3xYad2vrJsBMXO-J4XBiwDg@mail.gmail.com>



From sthorger at redhat.com  Wed Feb  1 07:14:00 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 1 Feb 2017 13:14:00 +0100
Subject: [keycloak-dev] JIRA issues to review for 2.5.0 and 2.5.1
In-Reply-To: <CAJgngAfmqVD=e1y914D-D7Kyktt3xYad2vrJsBMXO-J4XBiwDg@mail.gmail.com>
References: <CAJgngAfmqVD=e1y914D-D7Kyktt3xYad2vrJsBMXO-J4XBiwDg@mail.gmail.com>
Message-ID: <CAJgngAe7-FCXZzpCuaYA-h+S3TRBgibG8uAOXDCBjyBUJA0x_g@mail.gmail.com>

Ignore that ;)

On 1 February 2017 at 13:01, Stian Thorgersen <sthorger at redhat.com> wrote:

>
>

From gaalvarez0910 at gmail.com  Wed Feb  1 08:04:58 2017
From: gaalvarez0910 at gmail.com (Gustavo Alvarez)
Date: Wed, 01 Feb 2017 13:04:58 +0000
Subject: [keycloak-dev] Keycloak and nginx reverse proxy error
Message-ID: <CAAhLkKOfE1Xmoxsy5w=oF90Awma0j_Jt9eACCo4mdRh56bfNfA@mail.gmail.com>

Hi all.

I am try configure ssl with nginx in public network (port:8443) and
keycloak 2.3.0.Final in private network (port: 8080).

1. The next is ssl configuration for nginx:

upstream keycloak {
    server localhost:8080;
}

server {
  listen 8443;
  server_name localhost;

  ssl on;
  ssl_certificate /etc/ssl/certs/nginx-selfsigned.crt;
  ssl_certificate_key /etc/ssl/private/nginx-selfsigned.key;

  ssl_session_timeout 5m;

  ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
  ssl_ciphers ALL:!ADH!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP;
  ssl_prefer_server_ciphers on;

  location / {
    proxy_http_version 1.1;
    proxy_set_header Connection "";
    proxy_set_header Host $host:$server_port;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto https;
    proxy_pass http://keycloak;
  }
}

2. I am deploy the keycloak in domain mode and set the next configuration:

<server name="default-server">
                    <http-listener name="default" socket-binding="http"
redirect-socket="https" proxy-address-forwarding="true"/>
                    <host name="default-host" alias="localhost">
                        <location name="/" handler="welcome-content"/>
                        <filter-ref name="server-header"/>
                        <filter-ref name="x-powered-by-header"/>
                    </host>
                </server>


But I get the next error in browser:

Blocked loading mixed active content ?
http://172.16.0.186:8443/auth/resources/2.3.0.final/admin/keycloak/lib/patternfly/css/patternfly.css
?

and others several resources loaded by keycloak.

Thanks for you help.

From psilva at redhat.com  Wed Feb  1 08:55:29 2017
From: psilva at redhat.com (Pedro Igor Silva)
Date: Wed, 1 Feb 2017 11:55:29 -0200
Subject: [keycloak-dev] The best place to get the Request Party Token
In-Reply-To: <CY1PR0501MB180439E142ED12829196F278A84A0@CY1PR0501MB1804.namprd05.prod.outlook.com>
References: <CY1PR0501MB180439E142ED12829196F278A84A0@CY1PR0501MB1804.namprd05.prod.outlook.com>
Message-ID: <CAJrcDBdBMYWoxug+g6ghHoqorPsnP_iR6KDv-uUXN=H1nifSuQ@mail.gmail.com>

Hi Mauricio,

Can you please send your question to keycloak-user mailing list ? I can
help you from there.

Regards.
Pedro Igor

On Tue, Jan 31, 2017 at 10:27 AM, Maur?cio Giacomini Penteado <
mauriciogiacomini at hotmail.com> wrote:

> Please, I am trying use policy enforcer on my project but I am not having
> successful.
>
> My app are loging correctly by the two codes:
>
> code 1)
> var initOptions = {
>      onLoad: 'check-sso',
>      responseMode: 'query',
>      flow: 'standard'
> };
> keycloak.init(initOptions).success(function (authenticated) { ... ... ...
> }
>
> ... and by an angular interceptor:
>
> code 2)
> factory('authInterceptor', ['$q', 'keycloak', function ($q, keycloak) {
>                 return {
>                     request: function (config) {
>                         var deferred = $q.defer();
>                         keycloak.updateToken(30).success(function () {
>                             config.headers = config.headers || {};
>                             config.headers.Authorization = 'Bearer ' +
> keycloak.token;
>                             deferred.resolve(config);
>                         }).error(function () {
>                             deferred.reject('Failed to refresh token');
>                         });
>                         return deferred.promise;
>                     }
>                 };
>             }])
>
> But, if I enable policy enforcer my service calls are unauthorazed.
>
> It seems to me the best option to use the policy enforcer, in the exact
> moment that I receive the access token I must change this by an rpt token
> and from this point forward all my protected service calls will have access
> to my rpt token.
>
> I have no difficulty using the keycloak-authz.js library to get the rpt
> token. However, to get this process up and running, I must send a protected
> resource call and intercept the "WWW-Authenticate" header. I do not see how
> I can get the rpt token with the codes listed above and If I try to force
> the rtp token as an authorization header my interceptor it runs and changes
> the header for my access to the token again.
>
> There is a way to get the rpt token where I am trying or do I have any
> misconceptions it can not be done in this place?
>
> I will be very grateful if anyone can help me.
>
> Kind regards,
> Maur?cio Penteado.
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sts at ono.at  Wed Feb  1 15:06:50 2017
From: sts at ono.at (Stefan Schlesinger)
Date: Wed, 1 Feb 2017 21:06:50 +0100
Subject: [keycloak-dev] Keycloak integration with mod_auth_openidc broken
Message-ID: <ECB40848-F149-467D-AF07-88469C270AE1@ono.at>

Hello,

it looks like its currently not possible to use mod_auth_openidc with Keycloak for authorization of legacy applications. The current workaround described by mod_auth_openidc is to use OpenID Connect for authentication and use the apache ldap module for authorization, which is a rather ugly workaround IMHO.

The problem currently is twofold:

 1) One can use mod_auth_openidc to verify claims, but it doesn?t come with JSON path support[1], so matching the claims in realm_access.roles isn?t possible, only arrays in a flat JSON tree are supported[2].

 2) This wouldn?t cause any issues, as Keycloak comes with a User Realm Role mapper, which is able to map roles to a different key (in my example below the key is ?roles?).

{
  "jti": "01667279-a161-47ae-a093-b08643a1b7b5",
  "exp": 1485977685,
   ?
  "realm_access": {
    "roles": [
      ?application_x",
      ?application_y",
      "uma_authorization",
    ]
  },
  "roles": ?[application_x, application_y, uma_authorization]",
}

The problem with the mapper is that the value of roles, is served as a string instead of an array and mod_auth_openidc cannot handle this properly[3].

Btw. the same thing goes for the User Client Role mapper! Which looks like this:

{
  "client_role": "[login]?
}

An issue for this has already been created: https://issues.jboss.org/browse/KEYCLOAK-4205

It would be so great to get this fixed in the next release!!

Best,

Stefan.


[1] https://groups.google.com/forum/#!topic/mod_auth_openidc/QOMMYeXt5Jc
[2] https://github.com/pingidentity/mod_auth_openidc/blob/master/src/authz.c#L85
[3] https://github.com/pingidentity/mod_auth_openidc/blob/master/src/authz.c#L67

From mposolda at redhat.com  Wed Feb  1 15:34:56 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 1 Feb 2017 21:34:56 +0100
Subject: [keycloak-dev] keycloak.json in directory "config" in quickstarts
Message-ID: <fbdc6a63-7156-3c0e-5252-0f2d43769738@redhat.com>

In quickstart examples, we want people to put keycloak.json into the 
"config" directory of particular quickstart. Then during build, 
keycloak.json is copyied to src/main/webapp/WEB-INF.

Is it good pattern to do it like this? Can't we just instruct people 
directly to put it into "WEB-INF" folder directly?

I personally found it a bit confusing as the adapter expects config in 
"WEB-INF" folder by default. People may do their own apps and create the 
"config/keycloak.json", but they they may forget to add the profile 
"json" to their pom.xml to copy the file at build time. Then they can 
see issues like "I have folder config and file keycloak.json in it. Why 
Keycloak doesn't secure my app?" etc.

But maybe it's just me?

Marek


From bruno at abstractj.org  Wed Feb  1 19:30:43 2017
From: bruno at abstractj.org (Bruno Oliveira)
Date: Wed, 1 Feb 2017 22:30:43 -0200
Subject: [keycloak-dev] keycloak.json in directory "config" in
	quickstarts
In-Reply-To: <fbdc6a63-7156-3c0e-5252-0f2d43769738@redhat.com>
References: <fbdc6a63-7156-3c0e-5252-0f2d43769738@redhat.com>
Message-ID: <20170202003043.GC14372@abstractj.org>

On 2017-02-01, Marek Posolda wrote:
> In quickstart examples, we want people to put keycloak.json into the
> "config" directory of particular quickstart. Then during build,
> keycloak.json is copyied to src/main/webapp/WEB-INF.
>
> Is it good pattern to do it like this? Can't we just instruct people
> directly to put it into "WEB-INF" folder directly?

Or maybe we can just instruct people to use kcreg? In this way we don't
need to worry about copying keycloak.json anymore.

>
> I personally found it a bit confusing as the adapter expects config in
> "WEB-INF" folder by default. People may do their own apps and create the
> "config/keycloak.json", but they they may forget to add the profile
> "json" to their pom.xml to copy the file at build time. Then they can
> see issues like "I have folder config and file keycloak.json in it. Why
> Keycloak doesn't secure my app?" etc.

I got the same impression, with the quickstarts. But at the same time,
it's easier for people to see what they did wrong. Instead of providing
it by default. I believe that's the reason why it wasn't added before.

>
> But maybe it's just me?
>
> Marek
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

--

abstractj

From bruno at abstractj.org  Wed Feb  1 19:34:36 2017
From: bruno at abstractj.org (Bruno Oliveira)
Date: Wed, 1 Feb 2017 22:34:36 -0200
Subject: [keycloak-dev] Error deploying Keycloak over MariaDB
In-Reply-To: <a57e7653-d9ed-a1a1-6ea3-2eebcd67e163@psynd.net>
References: <a57e7653-d9ed-a1a1-6ea3-2eebcd67e163@psynd.net>
Message-ID: <20170202003436.GD14372@abstractj.org>


This mailing list is exclusively dedicated to discussions around
Keycloak development.

Please resend your question to keycloak-user mailing list [1] which is a
place for any questions related to installing, setting up, and using
Keycloak.

[1] https://lists.jboss.org/mailman/listinfo/keycloak-user

On 2017-01-30, Tech wrote:
> Hello,
>
> I need to deploy keycloak over MariaDB:
>
> I downloaded the latest version of Keycloak, 2.5.1 and I want to connect
> to my DB running over MariaDB.
>
> I'm using the same JDBC driver that I also use for other applications:
>
> I start WildFly, I open the console and I go to Deployment.
>
> I load the mariadb-java-client-1.5.5.jar.
>
> The driver is correctly loaded.
>
> I shutdown the server, I edit the standalone.xml and I add:
>
>
> <datasource jndi-name="java:jboss/MariaDBDS" pool-name="MariaDBDS">
>     <connection-url>jdbc:mariadb://localhost:3306/KcTbs</connection-url>
>     <driver>mariadb-java-client-1.5.5.jar</driver>
>     <driver-class>org.mariadb.jdbc.Driver</driver-class>
>     <security>
>         <user-name>KcUsr</user-name>
>         <password>KcPwd</password>
>     </security>
>     <validation>
>         <valid-connection-checker
> class-name="org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLValidConnectionChecker"/>
>         <validate-on-match>true</validate-on-match>
>         <background-validation>false</background-validation>
>         <exception-sorter
> class-name="org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLExceptionSorter"/>
>     </validation>
> </datasource>
>
>
> I restart the server and I can see the new datasource.
>
> I open it, I go to "Connection" and I receive the following error when I
> try to test the connection:
>
>
> 12:12:51,248 ERROR [org.jboss.as.controller.management-operation]
> (management task-7) WFLYCTL0013: Operation ("test-connection-in-pool")
> failed - address: ([
>     ("subsystem" => "datasources"),
>     ("data-source" => "MariaDBDS")
> ]) - failure description: "WFLYJCA0040: failed to invoke operation:
> WFLYJCA0047: Connection is not valid"
>
> Any idea?
> _______________________________________________
> 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 Feb  2 01:06:24 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 2 Feb 2017 07:06:24 +0100
Subject: [keycloak-dev] keycloak.json in directory "config" in
	quickstarts
In-Reply-To: <fbdc6a63-7156-3c0e-5252-0f2d43769738@redhat.com>
References: <fbdc6a63-7156-3c0e-5252-0f2d43769738@redhat.com>
Message-ID: <CAJgngAfpHXwF5YZDkyEpZf2OmisMV7kC1XnCzXVF=Hyne8bBhA@mail.gmail.com>

I agree - we can just change the check for the profile to make sure
keycloak.json is in WEB-INF rather than config.

I'm sure there are loads of usability improvements we can do around the
quickstarts, but now is not the right time. So create a JIRA for it.

On 1 February 2017 at 21:34, Marek Posolda <mposolda at redhat.com> wrote:

> In quickstart examples, we want people to put keycloak.json into the
> "config" directory of particular quickstart. Then during build,
> keycloak.json is copyied to src/main/webapp/WEB-INF.
>
> Is it good pattern to do it like this? Can't we just instruct people
> directly to put it into "WEB-INF" folder directly?
>
> I personally found it a bit confusing as the adapter expects config in
> "WEB-INF" folder by default. People may do their own apps and create the
> "config/keycloak.json", but they they may forget to add the profile
> "json" to their pom.xml to copy the file at build time. Then they can
> see issues like "I have folder config and file keycloak.json in it. Why
> Keycloak doesn't secure my app?" etc.
>
> But maybe it's just me?
>
> Marek
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sthorger at redhat.com  Thu Feb  2 01:10:27 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 2 Feb 2017 07:10:27 +0100
Subject: [keycloak-dev] Keycloak integration with mod_auth_openidc broken
In-Reply-To: <ECB40848-F149-467D-AF07-88469C270AE1@ono.at>
References: <ECB40848-F149-467D-AF07-88469C270AE1@ono.at>
Message-ID: <CAJgngAdSwWEvWJiLUZke0dJPKpXsRpZkBYrKSbymPzriRxZNhg@mail.gmail.com>

It should support multi-valued and mapping to a array rather than a
comma-separated list.

On 1 February 2017 at 21:06, Stefan Schlesinger <sts at ono.at> wrote:

> Hello,
>
> it looks like its currently not possible to use mod_auth_openidc with
> Keycloak for authorization of legacy applications. The current workaround
> described by mod_auth_openidc is to use OpenID Connect for authentication
> and use the apache ldap module for authorization, which is a rather ugly
> workaround IMHO.
>
> The problem currently is twofold:
>
>  1) One can use mod_auth_openidc to verify claims, but it doesn?t come
> with JSON path support[1], so matching the claims in realm_access.roles
> isn?t possible, only arrays in a flat JSON tree are supported[2].
>
>  2) This wouldn?t cause any issues, as Keycloak comes with a User Realm
> Role mapper, which is able to map roles to a different key (in my example
> below the key is ?roles?).
>
> {
>   "jti": "01667279-a161-47ae-a093-b08643a1b7b5",
>   "exp": 1485977685,
>    ?
>   "realm_access": {
>     "roles": [
>       ?application_x",
>       ?application_y",
>       "uma_authorization",
>     ]
>   },
>   "roles": ?[application_x, application_y, uma_authorization]",
> }
>
> The problem with the mapper is that the value of roles, is served as a
> string instead of an array and mod_auth_openidc cannot handle this
> properly[3].
>
> Btw. the same thing goes for the User Client Role mapper! Which looks like
> this:
>
> {
>   "client_role": "[login]?
> }
>
> An issue for this has already been created: https://issues.jboss.org/
> browse/KEYCLOAK-4205
>
> It would be so great to get this fixed in the next release!!
>
> Best,
>
> Stefan.
>
>
> [1] https://groups.google.com/forum/#!topic/mod_auth_openidc/QOMMYeXt5Jc
> [2] https://github.com/pingidentity/mod_auth_openidc/
> blob/master/src/authz.c#L85
> [3] https://github.com/pingidentity/mod_auth_openidc/
> blob/master/src/authz.c#L67
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From sblanc at redhat.com  Thu Feb  2 01:24:02 2017
From: sblanc at redhat.com (Sebastien Blanc)
Date: Thu, 2 Feb 2017 07:24:02 +0100
Subject: [keycloak-dev] keycloak.json in directory "config" in
	quickstarts
In-Reply-To: <CAJgngAfpHXwF5YZDkyEpZf2OmisMV7kC1XnCzXVF=Hyne8bBhA@mail.gmail.com>
References: <fbdc6a63-7156-3c0e-5252-0f2d43769738@redhat.com>
	<CAJgngAfpHXwF5YZDkyEpZf2OmisMV7kC1XnCzXVF=Hyne8bBhA@mail.gmail.com>
Message-ID: <CAMZCGg-4LsqC+zEE1viShXyfD9_sR_YpGkqgaNrEVNt62fA7ug@mail.gmail.com>

+1 let's track this in a JIRA and I will be more than happy to work on that
after our testsuite tasks.

On Thu, Feb 2, 2017 at 7:06 AM, Stian Thorgersen <sthorger at redhat.com>
wrote:

> I agree - we can just change the check for the profile to make sure
> keycloak.json is in WEB-INF rather than config.
>
> I'm sure there are loads of usability improvements we can do around the
> quickstarts, but now is not the right time. So create a JIRA for it.
>
> On 1 February 2017 at 21:34, Marek Posolda <mposolda at redhat.com> wrote:
>
> > In quickstart examples, we want people to put keycloak.json into the
> > "config" directory of particular quickstart. Then during build,
> > keycloak.json is copyied to src/main/webapp/WEB-INF.
> >
> > Is it good pattern to do it like this? Can't we just instruct people
> > directly to put it into "WEB-INF" folder directly?
> >
> > I personally found it a bit confusing as the adapter expects config in
> > "WEB-INF" folder by default. People may do their own apps and create the
> > "config/keycloak.json", but they they may forget to add the profile
> > "json" to their pom.xml to copy the file at build time. Then they can
> > see issues like "I have folder config and file keycloak.json in it. Why
> > Keycloak doesn't secure my app?" etc.
> >
> > But maybe it's just me?
> >
> > 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 telekomunikacije at gmail.com  Thu Feb  2 06:25:09 2017
From: telekomunikacije at gmail.com (Gorazd)
Date: Thu, 2 Feb 2017 12:25:09 +0100
Subject: [keycloak-dev] Keycloak+dogtag or Keycloak+freeIPA
Message-ID: <CACfH7zxMCkg9-Wre0FQ28U48bRX0WSE-FHKVtAzPj+e-FNN__w@mail.gmail.com>

Hi to all,

still doing some decision making...could anyone know to recommend me if for
example KeyCloak (as identity and acces managment solution)+DogTag (as a
PKI infrastructure) be great solution also to cover or integrate with
enterprise scenarios, where possible AD is behind RADIUS server, or is it
better to go with combination of Keycloak and FreeIPA (IdM)?  Is Keycloak
real IdM, does it have it's own LDAP base or is it dependent on external
users/roles database and has just a simple internal database/storage to
safe user/passs?

Thank you in advance,
Gorazd

From hmlnarik at redhat.com  Thu Feb  2 10:53:36 2017
From: hmlnarik at redhat.com (Hynek Mlnarik)
Date: Thu, 2 Feb 2017 16:53:36 +0100
Subject: [keycloak-dev] Keycloak+dogtag or Keycloak+freeIPA
In-Reply-To: <CACfH7zxMCkg9-Wre0FQ28U48bRX0WSE-FHKVtAzPj+e-FNN__w@mail.gmail.com>
References: <CACfH7zxMCkg9-Wre0FQ28U48bRX0WSE-FHKVtAzPj+e-FNN__w@mail.gmail.com>
Message-ID: <CAMvXD=FzaK+nOnrX1mym7hQmcx8wcMsL=sf54yi7LboBJGG2KA@mail.gmail.com>

This mailing list is exclusively dedicated to discussions around
Keycloak development.

Please resend your question to keycloak-user mailing list [1] which is a
place for any questions related to installing, setting up, and using
Keycloak.

[1] https://lists.jboss.org/mailman/listinfo/keycloak-user

On Thu, Feb 2, 2017 at 12:25 PM, Gorazd <telekomunikacije at gmail.com> wrote:
> Hi to all,
>
> still doing some decision making...could anyone know to recommend me if for
> example KeyCloak (as identity and acces managment solution)+DogTag (as a
> PKI infrastructure) be great solution also to cover or integrate with
> enterprise scenarios, where possible AD is behind RADIUS server, or is it
> better to go with combination of Keycloak and FreeIPA (IdM)?  Is Keycloak
> real IdM, does it have it's own LDAP base or is it dependent on external
> users/roles database and has just a simple internal database/storage to
> safe user/passs?
>
> Thank you in advance,
> Gorazd
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



-- 

--Hynek

From frelibert at yahoo.com  Thu Feb  2 16:00:18 2017
From: frelibert at yahoo.com (frelibert at yahoo.com)
Date: Thu, 2 Feb 2017 21:00:18 +0000 (UTC)
Subject: [keycloak-dev] SAML 2.0 AttributeValue AnyType
References: <1259879611.540398.1486069218700.ref@mail.yahoo.com>
Message-ID: <1259879611.540398.1486069218700@mail.yahoo.com>

Hi,
I need to integrate my keycloak server with a SAML 2.0 identity provider which, for some attributes, returns values with complex content (AnyType, without specifying the type of the Element).
e.g.
<saml2:Attribute Name="attr:notype:element" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">? ? ? <saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">? ? ? ? <Name xml:lang="nl" xmlns="urn:be:fgov:complextype:v1">Hospitaal x</Name>? ? ? </saml2:AttributeValue>? ? ? <saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">? ? ? ? <Name xml:lang="fr" xmlns="urn:be:fgov:complextype:v1">hopital x</Name>? ? ? </saml2:AttributeValue>? ? </saml2:Attribute>
KeyCloak throws an exception when parsing such an AttributeValue in a received Assertion.That's not very friendly.It would be better to give a warning and just skip the AttributeValue so it doesn't block the whole process.But even better would be to actually support complex values, as the SAML 2.0 specs do so.There is actually an easy fix to this.I allready implemented this last year when I integrated that same Identity Provider using PicketLink, which had the same flaw.As PicketLink has become deprecated in favor of KeyCloak, we are trying to move on to KeyCloak.Are you prepared to add support for complex values?The infected class is actually completely the same (I suppose you integrated the code of PicketLink):
org.keycloak.saml.processing.core.parsers.util.SAMLParserUtil.parseAttributeValue(XMLEventReader)

My fix is to use the existing process flow if possible but to go for a default behaviour where now an exception is thrown:parse the content of the AttributeValue as a String, including the xmltags.For non-xml values, this will end up as a simple string, for complex xml values, this will end up as a string with xml tags in it.This prevents impact in other parts of the code as it is nothing more then a string.
I allready tested it in my local keycloak server and KeyCloak has no problems with it further down the road.
If the SAML attribute is mapped to a User attribute, it shows the xmlstring in the user attribute value.If the User Attribute is used in a response, the xmlstring is escaped in the resulting Assertion, which is ok.
I can create a pull request for this, it's actually one extra method in SAMLParserUtil.You can find the updated class in attachment.There are no other differences between the branch 2.5.x and the master.

From takashi.norimatsu.ws at hitachi.com  Fri Feb  3 02:52:45 2017
From: takashi.norimatsu.ws at hitachi.com (=?utf-8?B?5LmX5p2+6ZqG5b+XIC8gTk9SSU1BVFNV77yMVEFLQVNISQ==?=)
Date: Fri, 3 Feb 2017 07:52:45 +0000
Subject: [keycloak-dev] Proposal of RFC7636 (PKCE) support
In-Reply-To: <CAJgngAcirnixV+xkaR-A=z6JqMqDxR6CduY64AktBb8qSvV8Ow@mail.gmail.com>
References: <831D472326678942A9B4BB933AAA103D25F78054@GSjpTK1DCembx01.service.hitachi.net>
	<CAJgngAcirnixV+xkaR-A=z6JqMqDxR6CduY64AktBb8qSvV8Ow@mail.gmail.com>
Message-ID: <831D472326678942A9B4BB933AAA103D25F87968@GSjpTK1DCembx01.service.hitachi.net>

Hello.

I've sent the PR for RFC7636 (PKCE) supporting implementation both server side and client side (only for Servlet OAuth) along with arquillian test cases.

Besides, I'm now updating design documents. I'll report it after wrapping up them.

I've found you are currently busy for preraring Keycloak 3.x. Hope you'll review this PR afterward.

Best Regards
Takashi Norimatsu
Hitachi, Ltd.

----------

From: Stian Thorgersen [mailto:sthorger at redhat.com] 
Sent: Tuesday, January 17, 2017 4:39 PM
To: ???? / NORIMATSU?TAKASHI
Cc: keycloak-dev at lists.jboss.org
Subject: [!]Re: [keycloak-dev] Proposal of RFC7636 (PKCE) support

You can send the PR whenever it's ready from your POV and we'll review. FIY we can't accept this until we start on Keycloak 3.x, but that should be fairly soon (sometime in Feb probably).

On 17 January 2017 at 06:38, ???? / NORIMATSU?TAKASHI <takashi.norimatsu.ws at hitachi.com> wrote:
Thank you very much.

I'm now writing tests for the new testsuite(testsuite/integration-arquillian), refining documents and codes for a PR.
After completing these tasks, hopefully in this week, I'd like to post mail to ask you whether I can send a PR.

Best Regards
Takashi Norimatsu
Hitachi, Ltd.

> We'd welcome a contribution.
>
> Tests would need to be written and added to the new testsuite
> (testsuite/integration-arquillian). If you are able to send updates to
> documentation as well that'd be good.
>
> On 13 January 2017 at 11:59, ???? / NORIMATSU?TAKASHI <
>takashi.norimatsu.ws at hitachi.com> wrote:
>
>> Hello.
>>
>> I've been using keycloak 2.4.0.FINAL.
>> I've implemented codes for RFC 7636 for Proof Key Code Exchange
>> experimentally.
>> (https://tools.ietf.org/html/rfc7636)
>>
>> [Background: Why RFC7636 is necessary]
>>? ?RFC 7636 is important for industries where high level security is
>> required because it can prevent Authorization Code Interception and
>> Substitution attacks for OAuth2.0. For example, it is required for both
>> confidential and public clients in draft specification of Financial API of
>> OpenID foundation. By implementing RFC 7636, keycloak will be used more
>> widely.
>>
>> [Description of the implementation]
>> My implementation is about 90steps for Authorization Server, 90steps for
>> Client(only Servlet-OAuth), both excluded debug log codes in step counts.
>> Please see the detail in below links.
>> * The implementation:
>>? ?https://github.com/keycloak/keycloak/commit/
>> 9e3d2d1e5e8c3b30ddc9ccd5083ba18adcb4c564
>>? ?It is based on 2.4.0.FINAL. Hope we'll refine and rebase it onto master
>> branch for PR if you accept our implementation proposal.
>> * Design document:
>> https://github.com/Hitachi/contributions/wiki/Description-of-RFC7636-for-
>> keycloak
>> * PoC test:
>> I've validated my implementation and found worked well in following
>> scenarios.
>> [1]
>>? Flow:? ?Authorization Code Flow
>> Client: RFC 7636 not supported
>> [2]
>> Flow:? ?Authorization Code Flow
>> Client: RFC 7636 supported and operate properly
>> [3]
>> Flow:? ?Authorization Code Flow
>> Client: RFC 7636 supported but operate illegally
>>? ? ? ? (send invalid code_verifier to Token Endpoint)
>> For detail of PoC test, please see:
>> https://github.com/Hitachi/contributions/wiki/PoC-Test-Result-of-RFC7636
>>
>> I am also willing to add tests to community?s testsuites according to the
>> process as described in ?Hacking on Keycloak?.
>>
>> I've known that related ticket had already been issued as KEYCLOAK-2604.
>> https://issues.jboss.org/browse/KEYCLOAK-2604
>>
>> Would you mind if I contribute this RFC 7636 support to Keycloak related
>> with KEYCLOAK-2604 ticket ?
>>
>> Best Regards
>> Takashi Norimatsu
>> Hitachi, Ltd.
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>



From sthorger at redhat.com  Fri Feb  3 03:30:32 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 3 Feb 2017 09:30:32 +0100
Subject: [keycloak-dev] Proposal of RFC7636 (PKCE) support
In-Reply-To: <831D472326678942A9B4BB933AAA103D25F87968@GSjpTK1DCembx01.service.hitachi.net>
References: <831D472326678942A9B4BB933AAA103D25F78054@GSjpTK1DCembx01.service.hitachi.net>
	<CAJgngAcirnixV+xkaR-A=z6JqMqDxR6CduY64AktBb8qSvV8Ow@mail.gmail.com>
	<831D472326678942A9B4BB933AAA103D25F87968@GSjpTK1DCembx01.service.hitachi.net>
Message-ID: <CAJgngAec6vCJhMM7Bk9vbQ2UCTk4SWevST+wCbQnYj5XN+sxZA@mail.gmail.com>

Thanks for the PR - I will ask someone to review the PR, but it will take a
week or two.

On 3 February 2017 at 08:52, ???? / NORIMATSU?TAKASHI <
takashi.norimatsu.ws at hitachi.com> wrote:

> Hello.
>
> I've sent the PR for RFC7636 (PKCE) supporting implementation both server
> side and client side (only for Servlet OAuth) along with arquillian test
> cases.
>
> Besides, I'm now updating design documents. I'll report it after wrapping
> up them.
>
> I've found you are currently busy for preraring Keycloak 3.x. Hope you'll
> review this PR afterward.
>
> Best Regards
> Takashi Norimatsu
> Hitachi, Ltd.
>
> ----------
>
> From: Stian Thorgersen [mailto:sthorger at redhat.com]
> Sent: Tuesday, January 17, 2017 4:39 PM
> To: ???? / NORIMATSU?TAKASHI
> Cc: keycloak-dev at lists.jboss.org
> Subject: [!]Re: [keycloak-dev] Proposal of RFC7636 (PKCE) support
>
> You can send the PR whenever it's ready from your POV and we'll review.
> FIY we can't accept this until we start on Keycloak 3.x, but that should be
> fairly soon (sometime in Feb probably).
>
> On 17 January 2017 at 06:38, ???? / NORIMATSU?TAKASHI <
> takashi.norimatsu.ws at hitachi.com> wrote:
> Thank you very much.
>
> I'm now writing tests for the new testsuite(testsuite/integration-arquillian),
> refining documents and codes for a PR.
> After completing these tasks, hopefully in this week, I'd like to post
> mail to ask you whether I can send a PR.
>
> Best Regards
> Takashi Norimatsu
> Hitachi, Ltd.
>
> > We'd welcome a contribution.
> >
> > Tests would need to be written and added to the new testsuite
> > (testsuite/integration-arquillian). If you are able to send updates to
> > documentation as well that'd be good.
> >
> > On 13 January 2017 at 11:59, ???? / NORIMATSU?TAKASHI <
> >takashi.norimatsu.ws at hitachi.com> wrote:
> >
> >> Hello.
> >>
> >> I've been using keycloak 2.4.0.FINAL.
> >> I've implemented codes for RFC 7636 for Proof Key Code Exchange
> >> experimentally.
> >> (https://tools.ietf.org/html/rfc7636)
> >>
> >> [Background: Why RFC7636 is necessary]
> >>   RFC 7636 is important for industries where high level security is
> >> required because it can prevent Authorization Code Interception and
> >> Substitution attacks for OAuth2.0. For example, it is required for both
> >> confidential and public clients in draft specification of Financial API
> of
> >> OpenID foundation. By implementing RFC 7636, keycloak will be used more
> >> widely.
> >>
> >> [Description of the implementation]
> >> My implementation is about 90steps for Authorization Server, 90steps for
> >> Client(only Servlet-OAuth), both excluded debug log codes in step
> counts.
> >> Please see the detail in below links.
> >> * The implementation:
> >>   https://github.com/keycloak/keycloak/commit/
> >> 9e3d2d1e5e8c3b30ddc9ccd5083ba18adcb4c564
> >>   It is based on 2.4.0.FINAL. Hope we'll refine and rebase it onto
> master
> >> branch for PR if you accept our implementation proposal.
> >> * Design document:
> >> https://github.com/Hitachi/contributions/wiki/
> Description-of-RFC7636-for-
> >> keycloak
> >> * PoC test:
> >> I've validated my implementation and found worked well in following
> >> scenarios.
> >> [1]
> >>  Flow:   Authorization Code Flow
> >> Client: RFC 7636 not supported
> >> [2]
> >> Flow:   Authorization Code Flow
> >> Client: RFC 7636 supported and operate properly
> >> [3]
> >> Flow:   Authorization Code Flow
> >> Client: RFC 7636 supported but operate illegally
> >>        (send invalid code_verifier to Token Endpoint)
> >> For detail of PoC test, please see:
> >> https://github.com/Hitachi/contributions/wiki/PoC-Test-
> Result-of-RFC7636
> >>
> >> I am also willing to add tests to community?s testsuites according to
> the
> >> process as described in ?Hacking on Keycloak?.
> >>
> >> I've known that related ticket had already been issued as KEYCLOAK-2604.
> >> https://issues.jboss.org/browse/KEYCLOAK-2604
> >>
> >> Would you mind if I contribute this RFC 7636 support to Keycloak related
> >> with KEYCLOAK-2604 ticket ?
> >>
> >> 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 tech at psynd.net  Fri Feb  3 10:08:32 2017
From: tech at psynd.net (Tech)
Date: Fri, 3 Feb 2017 16:08:32 +0100
Subject: [keycloak-dev] OAuth Moodle integration
Message-ID: <3ea287cd-36f9-6b1b-e4c4-360f610dc2e9@psynd.net>

Dear experts,

did anyone try already to integrate KeyCloak with Moodle?

We saw that Moodle provides already some OAuth integration with php
here: https://docs.moodle.org/dev/Oauth2_authentication#Proposed_design
, but we don't understand how to integrate it with KeyCloak.

Thanks!


From takashi.norimatsu.ws at hitachi.com  Sun Feb  5 20:22:37 2017
From: takashi.norimatsu.ws at hitachi.com (=?utf-8?B?5LmX5p2+6ZqG5b+XIC8gTk9SSU1BVFNV77yMVEFLQVNISQ==?=)
Date: Mon, 6 Feb 2017 01:22:37 +0000
Subject: [keycloak-dev] Proposal of RFC7636 (PKCE) support
In-Reply-To: <CAJgngAec6vCJhMM7Bk9vbQ2UCTk4SWevST+wCbQnYj5XN+sxZA@mail.gmail.com>
References: <831D472326678942A9B4BB933AAA103D25F78054@GSjpTK1DCembx01.service.hitachi.net>
	<CAJgngAcirnixV+xkaR-A=z6JqMqDxR6CduY64AktBb8qSvV8Ow@mail.gmail.com>
	<831D472326678942A9B4BB933AAA103D25F87968@GSjpTK1DCembx01.service.hitachi.net>
	<CAJgngAec6vCJhMM7Bk9vbQ2UCTk4SWevST+wCbQnYj5XN+sxZA@mail.gmail.com>
Message-ID: <831D472326678942A9B4BB933AAA103D25F87BB1@GSjpTK1DCembx01.service.hitachi.net>

Hello.

I've finished updating design documents for RFC 7636 (PKCE) implementation whose PR is https://github.com/keycloak/keycloak/pull/3831 .

Kindly refer to https://github.com/Hitachi/contributions/wiki/Description-of-RFC7636-for-keycloak .

Best Regards
Takashi Norimatsu
Hitachi, Ltd.

----------

From: Stian Thorgersen [mailto:sthorger at redhat.com] 
Sent: Friday, February 03, 2017 5:31 PM
To: ???? / NORIMATSU?TAKASHI
Cc: keycloak-dev at lists.jboss.org
Subject: [!]Re: Re: [keycloak-dev] Proposal of RFC7636 (PKCE) support

Thanks for the PR - I will ask someone to review the PR, but it will take a week or two.

On 3 February 2017 at 08:52, ???? / NORIMATSU?TAKASHI <takashi.norimatsu.ws at hitachi.com> wrote:
Hello.

I've sent the PR for RFC7636 (PKCE) supporting implementation both server side and client side (only for Servlet OAuth) along with arquillian test cases.

Besides, I'm now updating design documents. I'll report it after wrapping up them.

I've found you are currently busy for preraring Keycloak 3.x. Hope you'll review this PR afterward.

Best Regards
Takashi Norimatsu
Hitachi, Ltd.

----------

From: Stian Thorgersen [mailto:sthorger at redhat.com]
Sent: Tuesday, January 17, 2017 4:39 PM
To: ???? / NORIMATSU?TAKASHI
Cc: keycloak-dev at lists.jboss.org
Subject: [!]Re: [keycloak-dev] Proposal of RFC7636 (PKCE) support

You can send the PR whenever it's ready from your POV and we'll review. FIY we can't accept this until we start on Keycloak 3.x, but that should be fairly soon (sometime in Feb probably).

On 17 January 2017 at 06:38, ???? / NORIMATSU?TAKASHI <takashi.norimatsu.ws at hitachi.com> wrote:
Thank you very much.

I'm now writing tests for the new testsuite(testsuite/integration-arquillian), refining documents and codes for a PR.
After completing these tasks, hopefully in this week, I'd like to post mail to ask you whether I can send a PR.

Best Regards
Takashi Norimatsu
Hitachi, Ltd.

> We'd welcome a contribution.
>
> Tests would need to be written and added to the new testsuite
> (testsuite/integration-arquillian). If you are able to send updates to
> documentation as well that'd be good.
>
> On 13 January 2017 at 11:59, ???? / NORIMATSU?TAKASHI <
>takashi.norimatsu.ws at hitachi.com> wrote:
>
>> Hello.
>>
>> I've been using keycloak 2.4.0.FINAL.
>> I've implemented codes for RFC 7636 for Proof Key Code Exchange
>> experimentally.
>> (https://tools.ietf.org/html/rfc7636)
>>
>> [Background: Why RFC7636 is necessary]
>>? ?RFC 7636 is important for industries where high level security is
>> required because it can prevent Authorization Code Interception and
>> Substitution attacks for OAuth2.0. For example, it is required for both
>> confidential and public clients in draft specification of Financial API of
>> OpenID foundation. By implementing RFC 7636, keycloak will be used more
>> widely.
>>
>> [Description of the implementation]
>> My implementation is about 90steps for Authorization Server, 90steps for
>> Client(only Servlet-OAuth), both excluded debug log codes in step counts.
>> Please see the detail in below links.
>> * The implementation:
>>? ?https://github.com/keycloak/keycloak/commit/
>> 9e3d2d1e5e8c3b30ddc9ccd5083ba18adcb4c564
>>? ?It is based on 2.4.0.FINAL. Hope we'll refine and rebase it onto master
>> branch for PR if you accept our implementation proposal.
>> * Design document:
>> https://github.com/Hitachi/contributions/wiki/Description-of-RFC7636-for-
>> keycloak
>> * PoC test:
>> I've validated my implementation and found worked well in following
>> scenarios.
>> [1]
>>? Flow:? ?Authorization Code Flow
>> Client: RFC 7636 not supported
>> [2]
>> Flow:? ?Authorization Code Flow
>> Client: RFC 7636 supported and operate properly
>> [3]
>> Flow:? ?Authorization Code Flow
>> Client: RFC 7636 supported but operate illegally
>>? ? ? ? (send invalid code_verifier to Token Endpoint)
>> For detail of PoC test, please see:
>> https://github.com/Hitachi/contributions/wiki/PoC-Test-Result-of-RFC7636
>>
>> I am also willing to add tests to community?s testsuites according to the
>> process as described in ?Hacking on Keycloak?.
>>
>> I've known that related ticket had already been issued as KEYCLOAK-2604.
>> https://issues.jboss.org/browse/KEYCLOAK-2604
>>
>> Would you mind if I contribute this RFC 7636 support to Keycloak related
>> with KEYCLOAK-2604 ticket ?
>>
>> Best Regards
>> Takashi Norimatsu
>> Hitachi, Ltd.
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>



From sthorger at redhat.com  Mon Feb  6 13:54:53 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 6 Feb 2017 19:54:53 +0100
Subject: [keycloak-dev] Removing Mongo support
Message-ID: <CAJgngAdPxO-1OS5+PgKiTCmvcjus5LfBfFJiT1Mk8V_DioZNGQ@mail.gmail.com>

At times you have to make hard decisions and this has been one of those. We
have decided to remove Mongo support from Keycloak. The primary motivation
behind this decision is that we simply don't have the resources to maintain
and further develop the back-end for both relational databases and Mongo.
Further, there are some fundamental issues with our current use of Mongo
that would require a large amount of work to become fully production ready.
This primarily boils down to the lack of ACID transactions in Mongo.

We hope that this decision won't result in too much trouble for those of
you that are currently using Mongo as the back-end for Keycloak. It should
be relatively painless to migrate to a relational database with our
export/import feature. If you do run into issues with this please let us
know on the mailing list and we will do whatever we can to help make the
transition as smooth as possible.

If anyone from the community would like to take over the Mongo support and
maintain it as a separate extension please let us know. We can help with
extracting the code and work together in making it easy to install it as an
extension.
Migrating from Mongo to relational database

First step is to export the full database. You can do this by stopping the
Keycloak server and running:
bin/standalone.sh -Dkeycloak.migration.action=export
-Dkeycloak.migration.provider=dir -Dkeycloak.migration.dir=backup

This will export all data from Mongo to JSON files within the directory
backup. For full details refer to the Server Administration Guide
<https://keycloak.gitbooks.io/server-adminstration-guide/content/topics/export-import.html>
.

Next step is to install a relational database and configure it in Keycloak.
Take your pick we support quite a few. For full details refer to the Server
Installation Guide
<https://keycloak.gitbooks.io/server-installation-and-configuration/content/topics/database.html>
.

Once you have the relational database ready and configured, you can start
Keycloak and import the data exported from Mongo. To do this run Keycloak
with:
bin/standalone.sh -Dkeycloak.migration.action=import
-Dkeycloak.migration.provider=dir -Dkeycloak.migration.dir=backup

Hopefully you're now up and running with all your realms and users migrated
to the relational database. If not, let us know on the user mailing list
and we'll help you out as soon as possible.

From tair.sabirgaliev at gmail.com  Wed Feb  8 20:34:23 2017
From: tair.sabirgaliev at gmail.com (Tair Sabirgaliev)
Date: Wed, 8 Feb 2017 17:34:23 -0800
Subject: [keycloak-dev] refactor angular2-product-app
Message-ID: <CAGU3vRdBN1VwwqKX9b1VH_rk9uDuCbmWr+d5vY3qSReobPoy2g@mail.gmail.com>

Hi!

We integrated Keycloak to our angular2 application and used
angular2-product-app as a starting point. We had some issues
with it, so digged into the implementation and found that it
can be simplified.

We refactored the code and would like to suggest a patch, are
you interested?

From ssilvert at redhat.com  Thu Feb  9 07:33:38 2017
From: ssilvert at redhat.com (Stan Silvert)
Date: Thu, 9 Feb 2017 07:33:38 -0500
Subject: [keycloak-dev] refactor angular2-product-app
In-Reply-To: <CAGU3vRdBN1VwwqKX9b1VH_rk9uDuCbmWr+d5vY3qSReobPoy2g@mail.gmail.com>
References: <CAGU3vRdBN1VwwqKX9b1VH_rk9uDuCbmWr+d5vY3qSReobPoy2g@mail.gmail.com>
Message-ID: <dfe0c9ee-7b52-8a90-3a7c-b8fe8d94fd24@redhat.com>

Yes, I'd love to see any feedback you have.  Please let us know about 
the issues and solutions.

Thanks,

Stan

On 2/8/2017 8:34 PM, Tair Sabirgaliev wrote:
> Hi!
>
> We integrated Keycloak to our angular2 application and used
> angular2-product-app as a starting point. We had some issues
> with it, so digged into the implementation and found that it
> can be simplified.
>
> We refactored the code and would like to suggest a patch, are
> you interested?
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From bburke at redhat.com  Thu Feb  9 10:32:58 2017
From: bburke at redhat.com (Bill Burke)
Date: Thu, 9 Feb 2017 10:32:58 -0500
Subject: [keycloak-dev] LDAP No Import in Master
Message-ID: <43ab01c6-d58b-8cbd-9054-8ede1d4378e8@redhat.com>

LDAP No Import in master.  I ended up creating a UserModel in-memory 
pojo, and passing it to the import command and that worked for most of 
situations.  There were some other minor fixes to get it to work.  The 
only issue I have now is that if there is no mapping for an update, no 
exception is thrown and the changes are just lost with no warning.  
Runtime should throw an error in this situation.  Not sure the best way 
to handle it for the moment, so I'm going to let it stew in my brain for 
a little while.

Also added "remoteImportedUsers" and "unlinkUsers" operations. This will 
allow people to migrate from import mode to no import mode.

Cheers,

Bill


From bburke at redhat.com  Thu Feb  9 15:10:15 2017
From: bburke at redhat.com (Bill Burke)
Date: Thu, 9 Feb 2017 15:10:15 -0500
Subject: [keycloak-dev] Auth SPI being refactored in 3.0
Message-ID: <edee2b4f-4f5f-8813-d15f-9cfb4b76b832@redhat.com>

The Authentication SPI is being refactored in 3.0.  Like what happened 
in Keycloak 2.x and the User Storage SPI, the Authentication SPI will be 
refactored and improved through various 3.x releases.  We'll clean up 
areas, rewrite certain areas, and get the SPI ready so that it can be 
stable and supportable for the foreseeable future.  We are also doing 
this work so that we can support things like step-up authentication and 
FIDO etc. although the latter is for much later down the road.

The first area that will be tackled will be the Form SPI.

Regards,

Bill


From mposolda at redhat.com  Thu Feb  9 15:33:43 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 9 Feb 2017 21:33:43 +0100
Subject: [keycloak-dev] LDAP No Import in Master
In-Reply-To: <43ab01c6-d58b-8cbd-9054-8ede1d4378e8@redhat.com>
References: <43ab01c6-d58b-8cbd-9054-8ede1d4378e8@redhat.com>
Message-ID: <7db9778e-1f45-e90e-bd57-70ed23a553c7@redhat.com>

On 09/02/17 16:32, Bill Burke wrote:
> LDAP No Import in master.  I ended up creating a UserModel in-memory
> pojo, and passing it to the import command and that worked for most of
> situations.  There were some other minor fixes to get it to work.  The
> only issue I have now is that if there is no mapping for an update, no
> exception is thrown and the changes are just lost with no warning.
> Runtime should throw an error in this situation.  Not sure the best way
> to handle it for the moment, so I'm going to let it stew in my brain for
> a little while.
What if UserStorageProvider has a method, which will return list of 
updateable attributes/properties for particular user? The non-supported 
attributes can be marked as read-only in the UI. LDAP provider will look 
for what attributes it has mappers and just those can be shown in UI as 
editable.

Marek

>
> Also added "remoteImportedUsers" and "unlinkUsers" operations. This will
> allow people to migrate from import mode to no import mode.
>
> Cheers,
>
> Bill
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



From bburke at redhat.com  Thu Feb  9 16:48:49 2017
From: bburke at redhat.com (Bill Burke)
Date: Thu, 9 Feb 2017 16:48:49 -0500
Subject: [keycloak-dev] LDAP No Import in Master
In-Reply-To: <7db9778e-1f45-e90e-bd57-70ed23a553c7@redhat.com>
References: <43ab01c6-d58b-8cbd-9054-8ede1d4378e8@redhat.com>
	<7db9778e-1f45-e90e-bd57-70ed23a553c7@redhat.com>
Message-ID: <8603d6a2-db1d-e89c-efd8-92a598835666@redhat.com>



On 2/9/17 3:33 PM, Marek Posolda wrote:
> On 09/02/17 16:32, Bill Burke wrote:
>> LDAP No Import in master.  I ended up creating a UserModel in-memory
>> pojo, and passing it to the import command and that worked for most of
>> situations.  There were some other minor fixes to get it to work.  The
>> only issue I have now is that if there is no mapping for an update, no
>> exception is thrown and the changes are just lost with no warning.
>> Runtime should throw an error in this situation.  Not sure the best way
>> to handle it for the moment, so I'm going to let it stew in my brain for
>> a little while.
> What if UserStorageProvider has a method, which will return list of 
> updateable attributes/properties for particular user? The 
> non-supported attributes can be marked as read-only in the UI. LDAP 
> provider will look for what attributes it has mappers and just those 
> can be shown in UI as editable.
>

I'm not doing any UI work.  Just want to make sure that if somebody 
performs an illegal update, they get notified its illegal.  I think what 
you're saying will work.  The information is there for attributes.  For 
group/role mappings is sort of, kind of is.

Bill

From gaalvarez0910 at gmail.com  Thu Feb  9 17:28:49 2017
From: gaalvarez0910 at gmail.com (Gustavo Alvarez)
Date: Thu, 09 Feb 2017 22:28:49 +0000
Subject: [keycloak-dev] Internationalization support for angular
	notifications and default values.
Message-ID: <CAAhLkKMk3Sb1gZObp2Mi6FbwxUfuspbz_+ja7yJYRebEBMbb-w@mail.gmail.com>

HI all.

I need to change all language of keycloak, almost all the information in
pages of console is in properties files except two things:

1. Notifications from angular: there is code as the next:
                 Notifications.success ("Role mappings updated.");

2. Default values in java services, for example the service that creates
client uses default values in DefaultAuthenticationFlows.java:

public static final String REGISTRATION_FLOW = "registration";
public static final String REGISTRATION_FORM_FLOW = "registration form";
public static final String BROWSER_FLOW = "browser";
public static final String DIRECT_GRANT_FLOW = "direct grant";
public static final String RESET_CREDENTIALS_FLOW = "reset credentials";
public static final String LOGIN_FORMS_FLOW = "forms";
public static final String SAML_ECP_FLOW = "saml ecp";

Someone is working on this now or or can you help me find a solution for
this situation?

Thanks for you help.

gaalvarez.

From tair.sabirgaliev at gmail.com  Thu Feb  9 18:19:31 2017
From: tair.sabirgaliev at gmail.com (Tair Sabirgaliev)
Date: Fri, 10 Feb 2017 05:19:31 +0600
Subject: [keycloak-dev] refactor angular2-product-app
In-Reply-To: <CAGU3vRdBN1VwwqKX9b1VH_rk9uDuCbmWr+d5vY3qSReobPoy2g@mail.gmail.com>
References: <CAGU3vRdBN1VwwqKX9b1VH_rk9uDuCbmWr+d5vY3qSReobPoy2g@mail.gmail.com>
Message-ID: <f79f2549-c459-dfd3-6c12-656c70d145fb@gmail.com>

1. The KeycloakHttp implementation overrides all the http methods, but 
in the
Http class they all forward to 'request(...)' method, so overriding
`request(...)` should be enough.

2. It is not obvious why the implementation uses Observable.merge.
AFAICT the idea is to:

     (1) obtain the token (and update it BTW),
     (2) put it in header,
     (3) forward to superclass implementation.

So we found that the whole KeycloakHttp implementation could be reduced 
to the following:

@Injectable()
export class KeycloakHttp extends Http {
     constructor(_backend: ConnectionBackend, _defaultOptions: 
RequestOptions, _keycloakService: KeycloakService) {
         super(_backend, _defaultOptions);
     }

     request(url: string | Request, options?: RequestOptionsArgs): 
Observable<Response> {
         const tokenPromise: Promise<string> = 
this._keycloakService.getToken();
         const tokenObservable: Observable<string> = 
Observable.fromPromise(tokenPromise);

         if (typeof url === 'string') {
             return tokenObservable.map(token => {
                 const authOptions = new RequestOptions({
                     headers: new Headers({'Authorization': 'Bearer ' + 
token})
                 });
                 return new 
RequestOptions().merge(options).merge(authOptions);
             }).concatMap(opts => super.request(url, opts));
         } else if (url instanceof Request) {
             return tokenObservable.map(token => {
                 url.headers.set('Authorization', 'Bearer ' + token);
                 return url;
             }).concatMap(request => super.request(request));
         }
     }

}


From ssilvert at redhat.com  Fri Feb 10 08:27:28 2017
From: ssilvert at redhat.com (Stan Silvert)
Date: Fri, 10 Feb 2017 08:27:28 -0500
Subject: [keycloak-dev] Internationalization support for angular
 notifications and default values.
In-Reply-To: <CAAhLkKMk3Sb1gZObp2Mi6FbwxUfuspbz_+ja7yJYRebEBMbb-w@mail.gmail.com>
References: <CAAhLkKMk3Sb1gZObp2Mi6FbwxUfuspbz_+ja7yJYRebEBMbb-w@mail.gmail.com>
Message-ID: <95b3c131-a76f-268b-db8c-7c412155b7db@redhat.com>

This is a known issue that we will need to revisit when we have the time 
and resources:
https://issues.jboss.org/browse/KEYCLOAK-2393
https://issues.jboss.org/browse/KEYCLOAK-2394

There are several places here and there in the console and the REST API 
that still need i18n support.  If you would like to help we'd love to 
get a contribution and we can help get you started with the implementation.

Stan

On 2/9/2017 5:28 PM, Gustavo Alvarez wrote:
> HI all.
>
> I need to change all language of keycloak, almost all the information in
> pages of console is in properties files except two things:
>
> 1. Notifications from angular: there is code as the next:
>                   Notifications.success ("Role mappings updated.");
>
> 2. Default values in java services, for example the service that creates
> client uses default values in DefaultAuthenticationFlows.java:
>
> public static final String REGISTRATION_FLOW = "registration";
> public static final String REGISTRATION_FORM_FLOW = "registration form";
> public static final String BROWSER_FLOW = "browser";
> public static final String DIRECT_GRANT_FLOW = "direct grant";
> public static final String RESET_CREDENTIALS_FLOW = "reset credentials";
> public static final String LOGIN_FORMS_FLOW = "forms";
> public static final String SAML_ECP_FLOW = "saml ecp";
>
> Someone is working on this now or or can you help me find a solution for
> this situation?
>
> Thanks for you help.
>
> gaalvarez.
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From ssilvert at redhat.com  Fri Feb 10 08:29:39 2017
From: ssilvert at redhat.com (Stan Silvert)
Date: Fri, 10 Feb 2017 08:29:39 -0500
Subject: [keycloak-dev] refactor angular2-product-app
In-Reply-To: <f79f2549-c459-dfd3-6c12-656c70d145fb@gmail.com>
References: <CAGU3vRdBN1VwwqKX9b1VH_rk9uDuCbmWr+d5vY3qSReobPoy2g@mail.gmail.com>
	<f79f2549-c459-dfd3-6c12-656c70d145fb@gmail.com>
Message-ID: <68f5ad93-74a6-fdc1-19c1-1ca02896a9e3@redhat.com>

Thanks Tair.  I'll be looking into this very soon.  Probably next week.

On 2/9/2017 6:19 PM, Tair Sabirgaliev wrote:
> 1. The KeycloakHttp implementation overrides all the http methods, but 
> in the
> Http class they all forward to 'request(...)' method, so overriding
> `request(...)` should be enough.
>
> 2. It is not obvious why the implementation uses Observable.merge.
> AFAICT the idea is to:
>
>     (1) obtain the token (and update it BTW),
>     (2) put it in header,
>     (3) forward to superclass implementation.
>
> So we found that the whole KeycloakHttp implementation could be 
> reduced to the following:
>
> @Injectable()
> export class KeycloakHttp extends Http {
>     constructor(_backend: ConnectionBackend, _defaultOptions: 
> RequestOptions, _keycloakService: KeycloakService) {
>         super(_backend, _defaultOptions);
>     }
>
>     request(url: string | Request, options?: RequestOptionsArgs): 
> Observable<Response> {
>         const tokenPromise: Promise<string> = 
> this._keycloakService.getToken();
>         const tokenObservable: Observable<string> = 
> Observable.fromPromise(tokenPromise);
>
>         if (typeof url === 'string') {
>             return tokenObservable.map(token => {
>                 const authOptions = new RequestOptions({
>                     headers: new Headers({'Authorization': 'Bearer ' + 
> token})
>                 });
>                 return new 
> RequestOptions().merge(options).merge(authOptions);
>             }).concatMap(opts => super.request(url, opts));
>         } else if (url instanceof Request) {
>             return tokenObservable.map(token => {
>                 url.headers.set('Authorization', 'Bearer ' + token);
>                 return url;
>             }).concatMap(request => super.request(request));
>         }
>     }
>
> }
>


From gaalvarez0910 at gmail.com  Fri Feb 10 09:18:42 2017
From: gaalvarez0910 at gmail.com (Gustavo Alvarez)
Date: Fri, 10 Feb 2017 14:18:42 +0000
Subject: [keycloak-dev] Internationalization support for angular
 notifications and default values.
In-Reply-To: <95b3c131-a76f-268b-db8c-7c412155b7db@redhat.com>
References: <CAAhLkKMk3Sb1gZObp2Mi6FbwxUfuspbz_+ja7yJYRebEBMbb-w@mail.gmail.com>
	<95b3c131-a76f-268b-db8c-7c412155b7db@redhat.com>
Message-ID: <CAAhLkKNowL+gTYgXJQF5C9GoUR-cSt_JwquD2Fe8AsaWfLVa9A@mail.gmail.com>

Hello Stan.

Can you help me with an example of i18n implementation in keycloak?

Thanks.

Gaalvarez.



On Fri, Feb 10, 2017 at 8:29 AM Stan Silvert <ssilvert at redhat.com> wrote:

> This is a known issue that we will need to revisit when we have the time
> and resources:
> https://issues.jboss.org/browse/KEYCLOAK-2393
> https://issues.jboss.org/browse/KEYCLOAK-2394
>
> There are several places here and there in the console and the REST API
> that still need i18n support.  If you would like to help we'd love to
> get a contribution and we can help get you started with the implementation.
>
> Stan
>
> On 2/9/2017 5:28 PM, Gustavo Alvarez wrote:
> > HI all.
> >
> > I need to change all language of keycloak, almost all the information in
> > pages of console is in properties files except two things:
> >
> > 1. Notifications from angular: there is code as the next:
> >                   Notifications.success ("Role mappings updated.");
> >
> > 2. Default values in java services, for example the service that creates
> > client uses default values in DefaultAuthenticationFlows.java:
> >
> > public static final String REGISTRATION_FLOW = "registration";
> > public static final String REGISTRATION_FORM_FLOW = "registration form";
> > public static final String BROWSER_FLOW = "browser";
> > public static final String DIRECT_GRANT_FLOW = "direct grant";
> > public static final String RESET_CREDENTIALS_FLOW = "reset credentials";
> > public static final String LOGIN_FORMS_FLOW = "forms";
> > public static final String SAML_ECP_FLOW = "saml ecp";
> >
> > Someone is working on this now or or can you help me find a solution for
> > this situation?
> >
> > Thanks for you help.
> >
> > gaalvarez.
> > _______________________________________________
> > 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 tair.sabirgaliev at gmail.com  Fri Feb 10 09:45:46 2017
From: tair.sabirgaliev at gmail.com (Tair Sabirgaliev)
Date: Fri, 10 Feb 2017 06:45:46 -0800
Subject: [keycloak-dev] refactor angular2-product-app
In-Reply-To: <68f5ad93-74a6-fdc1-19c1-1ca02896a9e3@redhat.com>
References: <CAGU3vRdBN1VwwqKX9b1VH_rk9uDuCbmWr+d5vY3qSReobPoy2g@mail.gmail.com>
	<f79f2549-c459-dfd3-6c12-656c70d145fb@gmail.com>
	<68f5ad93-74a6-fdc1-19c1-1ca02896a9e3@redhat.com>
Message-ID: <CAGU3vRcZy0t1Zk+=JnJqq1u8DZBe85VMwuA6n_xw4oKAgtH0gA@mail.gmail.com>

Here is the PR https://github.com/keycloak/keycloak/pull/3855

I don?t know how to properly QA demos, please give me some
guidance on that, and I would be happy to maintain Angular 2
integration code later on.

Here are some ideas I can work on:

? - upgrade to latest Angular
? - refactor Keycloak service to a non-static singleton (a proper service)
? - properly handle the session expiration in Keycloak service
? - use ng-cli
? - integration test the sample app
? - use Angular routes and guards to secure HTML5 navigation
? - experiment with alternative authentication flows

and more!

Why not have a real kitchensink-style Angular application a part of samples :)

Thank you!


On 10 February 2017 at 19:29:39, Stan Silvert
(ssilvert at redhat.com(mailto:ssilvert at redhat.com)) wrote:

> Thanks Tair. I'll be looking into this very soon. Probably next week.
>
> On 2/9/2017 6:19 PM, Tair Sabirgaliev wrote:
> > 1. The KeycloakHttp implementation overrides all the http methods, but
> > in the
> > Http class they all forward to 'request(...)' method, so overriding
> > `request(...)` should be enough.
> >
> > 2. It is not obvious why the implementation uses Observable.merge.
> > AFAICT the idea is to:
> >
> > (1) obtain the token (and update it BTW),
> > (2) put it in header,
> > (3) forward to superclass implementation.
> >
> > So we found that the whole KeycloakHttp implementation could be
> > reduced to the following:
> >
> > @Injectable()
> > export class KeycloakHttp extends Http {
> > constructor(_backend: ConnectionBackend, _defaultOptions:
> > RequestOptions, _keycloakService: KeycloakService) {
> > super(_backend, _defaultOptions);
> > }
> >
> > request(url: string | Request, options?: RequestOptionsArgs):
> > Observable {
> > const tokenPromise: Promise =
> > this._keycloakService.getToken();
> > const tokenObservable: Observable =
> > Observable.fromPromise(tokenPromise);
> >
> > if (typeof url === 'string') {
> > return tokenObservable.map(token => {
> > const authOptions = new RequestOptions({
> > headers: new Headers({'Authorization': 'Bearer ' +
> > token})
> > });
> > return new
> > RequestOptions().merge(options).merge(authOptions);
> > }).concatMap(opts => super.request(url, opts));
> > } else if (url instanceof Request) {
> > return tokenObservable.map(token => {
> > url.headers.set('Authorization', 'Bearer ' + token);
> > return url;
> > }).concatMap(request => super.request(request));
> > }
> > }
> >
> > }
> >
>


From ssilvert at redhat.com  Fri Feb 10 11:50:20 2017
From: ssilvert at redhat.com (Stan Silvert)
Date: Fri, 10 Feb 2017 11:50:20 -0500
Subject: [keycloak-dev] Internationalization support for angular
 notifications and default values.
In-Reply-To: <CAAhLkKNowL+gTYgXJQF5C9GoUR-cSt_JwquD2Fe8AsaWfLVa9A@mail.gmail.com>
References: <CAAhLkKMk3Sb1gZObp2Mi6FbwxUfuspbz_+ja7yJYRebEBMbb-w@mail.gmail.com>
	<95b3c131-a76f-268b-db8c-7c412155b7db@redhat.com>
	<CAAhLkKNowL+gTYgXJQF5C9GoUR-cSt_JwquD2Fe8AsaWfLVa9A@mail.gmail.com>
Message-ID: <a5507718-9eff-c0f2-5022-56bdda0b8bc4@redhat.com>

On 2/10/2017 9:18 AM, Gustavo Alvarez wrote:
> Hello Stan.
>
> Can you help me with an example of i18n implementation in keycloak?
Sure.  We are using angular-translate on the javascript side:
https://angular-translate.github.io/docs/#/guide

The localized messages live in *.properties files on the server. These 
are translated to json as they are fetched through the REST API.

So for instance, the first form you see in keycloak admin is realm-detail:
https://github.com/keycloak/keycloak/blob/master/themes/src/main/resources/theme/base/admin/resources/partials/realm-detail.html

You'll notice markup like this:
<label class="col-md-2 control-label" for="name">{{:: 'displayName' | 
translate}}</label>

Here, displayName is a key in a properties file that is localized. (For 
performance reasons make sure you do use the double-colon '::')
This key lives in 
https://github.com/keycloak/keycloak/blob/master/themes/src/main/resources/theme/base/admin/messages/admin-messages_en.properties

There is some i18n needed on the server side for error messages that are 
currently hard-coded.  For that you would use standard java message 
bundle API's.  I don't think we have any examples for that.

Also, I'm attaching a powerpoint that I prepared for the Keycloak team a 
long time ago.  It's mostly accurate with what we still do today, so you 
might find it helpful.

Stan

>
> Thanks.
>
> Gaalvarez.
>
>
>
> On Fri, Feb 10, 2017 at 8:29 AM Stan Silvert <ssilvert at redhat.com 
> <mailto:ssilvert at redhat.com>> wrote:
>
>     This is a known issue that we will need to revisit when we have
>     the time
>     and resources:
>     https://issues.jboss.org/browse/KEYCLOAK-2393
>     https://issues.jboss.org/browse/KEYCLOAK-2394
>
>     There are several places here and there in the console and the
>     REST API
>     that still need i18n support.  If you would like to help we'd love to
>     get a contribution and we can help get you started with the
>     implementation.
>
>     Stan
>
>     On 2/9/2017 5:28 PM, Gustavo Alvarez wrote:
>     > HI all.
>     >
>     > I need to change all language of keycloak, almost all the
>     information in
>     > pages of console is in properties files except two things:
>     >
>     > 1. Notifications from angular: there is code as the next:
>     >                   Notifications.success ("Role mappings updated.");
>     >
>     > 2. Default values in java services, for example the service that
>     creates
>     > client uses default values in DefaultAuthenticationFlows.java:
>     >
>     > public static final String REGISTRATION_FLOW = "registration";
>     > public static final String REGISTRATION_FORM_FLOW =
>     "registration form";
>     > public static final String BROWSER_FLOW = "browser";
>     > public static final String DIRECT_GRANT_FLOW = "direct grant";
>     > public static final String RESET_CREDENTIALS_FLOW = "reset
>     credentials";
>     > public static final String LOGIN_FORMS_FLOW = "forms";
>     > public static final String SAML_ECP_FLOW = "saml ecp";
>     >
>     > Someone is working on this now or or can you help me find a
>     solution for
>     > this situation?
>     >
>     > Thanks for you help.
>     >
>     > gaalvarez.
>     > _______________________________________________
>     > keycloak-dev mailing list
>     > keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>     _______________________________________________
>     keycloak-dev mailing list
>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>


From tkyjovsk at redhat.com  Fri Feb 10 11:50:58 2017
From: tkyjovsk at redhat.com (Tomas Kyjovsky)
Date: Fri, 10 Feb 2017 11:50:58 -0500 (EST)
Subject: [keycloak-dev] Handling exceptions thrown from user storage
	providers
In-Reply-To: <528402300.21727105.1486742691138.JavaMail.zimbra@redhat.com>
Message-ID: <857475172.21744721.1486745458264.JavaMail.zimbra@redhat.com>

Currently there isn't much handling of exceptions which may be thrown from User Storage SPI methods.

For example:

- when `UserStorageProvider.preRemove` throws an exception it's not possible to remove a group/role or realm in which the offending provider is registered

- when `UserLookupProvider.getUserByUsername` throws an exception this blocks all lower priority providers from looking up users

- exception from `UserStorageProviderFactory.create` blocks all providers from lookup, credential validation/updates, etc.

I can't decide whether this "fail fast" behavior is bug or feature. On one hand it lets the developer know there's a problem with the provider. On the other hand it destabilizes the other providers in the realm.

WDYT?


Tomas

From ssilvert at redhat.com  Fri Feb 10 12:43:37 2017
From: ssilvert at redhat.com (Stan Silvert)
Date: Fri, 10 Feb 2017 12:43:37 -0500
Subject: [keycloak-dev] refactor angular2-product-app
In-Reply-To: <CAGU3vRcZy0t1Zk+=JnJqq1u8DZBe85VMwuA6n_xw4oKAgtH0gA@mail.gmail.com>
References: <CAGU3vRdBN1VwwqKX9b1VH_rk9uDuCbmWr+d5vY3qSReobPoy2g@mail.gmail.com>
	<f79f2549-c459-dfd3-6c12-656c70d145fb@gmail.com>
	<68f5ad93-74a6-fdc1-19c1-1ca02896a9e3@redhat.com>
	<CAGU3vRcZy0t1Zk+=JnJqq1u8DZBe85VMwuA6n_xw4oKAgtH0gA@mail.gmail.com>
Message-ID: <3434b772-9d17-af29-c0fe-2d59d720b5fa@redhat.com>

Emillien Bondu has also done a lot of work in this area.  Have you see this?
https://github.com/ebondu/angular2-keycloak


On 2/10/2017 9:45 AM, Tair Sabirgaliev wrote:
> Here is the PR https://github.com/keycloak/keycloak/pull/3855
>
> I don?t know how to properly QA demos, please give me some
> guidance on that, and I would be happy to maintain Angular 2
> integration code later on.
>
> Here are some ideas I can work on:
>
>    - upgrade to latest Angular
>    - refactor Keycloak service to a non-static singleton (a proper service)
>    - properly handle the session expiration in Keycloak service
>    - use ng-cli
>    - integration test the sample app
>    - use Angular routes and guards to secure HTML5 navigation
>    - experiment with alternative authentication flows
>
> and more!
>
> Why not have a real kitchensink-style Angular application a part of samples :)
>
> Thank you!
>
>
> On 10 February 2017 at 19:29:39, Stan Silvert
> (ssilvert at redhat.com(mailto:ssilvert at redhat.com)) wrote:
>
>> Thanks Tair. I'll be looking into this very soon. Probably next week.
>>
>> On 2/9/2017 6:19 PM, Tair Sabirgaliev wrote:
>>> 1. The KeycloakHttp implementation overrides all the http methods, but
>>> in the
>>> Http class they all forward to 'request(...)' method, so overriding
>>> `request(...)` should be enough.
>>>
>>> 2. It is not obvious why the implementation uses Observable.merge.
>>> AFAICT the idea is to:
>>>
>>> (1) obtain the token (and update it BTW),
>>> (2) put it in header,
>>> (3) forward to superclass implementation.
>>>
>>> So we found that the whole KeycloakHttp implementation could be
>>> reduced to the following:
>>>
>>> @Injectable()
>>> export class KeycloakHttp extends Http {
>>> constructor(_backend: ConnectionBackend, _defaultOptions:
>>> RequestOptions, _keycloakService: KeycloakService) {
>>> super(_backend, _defaultOptions);
>>> }
>>>
>>> request(url: string | Request, options?: RequestOptionsArgs):
>>> Observable {
>>> const tokenPromise: Promise =
>>> this._keycloakService.getToken();
>>> const tokenObservable: Observable =
>>> Observable.fromPromise(tokenPromise);
>>>
>>> if (typeof url === 'string') {
>>> return tokenObservable.map(token => {
>>> const authOptions = new RequestOptions({
>>> headers: new Headers({'Authorization': 'Bearer ' +
>>> token})
>>> });
>>> return new
>>> RequestOptions().merge(options).merge(authOptions);
>>> }).concatMap(opts => super.request(url, opts));
>>> } else if (url instanceof Request) {
>>> return tokenObservable.map(token => {
>>> url.headers.set('Authorization', 'Bearer ' + token);
>>> return url;
>>> }).concatMap(request => super.request(request));
>>> }
>>> }
>>>
>>> }
>>>


From tair.sabirgaliev at gmail.com  Fri Feb 10 14:54:53 2017
From: tair.sabirgaliev at gmail.com (Tair Sabirgaliev)
Date: Fri, 10 Feb 2017 11:54:53 -0800
Subject: [keycloak-dev] refactor angular2-product-app
In-Reply-To: <3434b772-9d17-af29-c0fe-2d59d720b5fa@redhat.com>
References: <CAGU3vRdBN1VwwqKX9b1VH_rk9uDuCbmWr+d5vY3qSReobPoy2g@mail.gmail.com>
	<f79f2549-c459-dfd3-6c12-656c70d145fb@gmail.com>
	<68f5ad93-74a6-fdc1-19c1-1ca02896a9e3@redhat.com>
	<CAGU3vRcZy0t1Zk+=JnJqq1u8DZBe85VMwuA6n_xw4oKAgtH0gA@mail.gmail.com>
	<3434b772-9d17-af29-c0fe-2d59d720b5fa@redhat.com>
Message-ID: <CAGU3vRe-BCG9L6Upscw2THAby0rW-ycficUZNBXPGAXa7RWGbw@mail.gmail.com>

Looks great! I would happily join forces with Emillien. Most of the groundwork
is there.



On 10 February 2017 at 23:43:38, Stan Silvert
(ssilvert at redhat.com(mailto:ssilvert at redhat.com)) wrote:

> Emillien Bondu has also done a lot of work in this area. Have you see this?
> https://github.com/ebondu/angular2-keycloak
>
>
> On 2/10/2017 9:45 AM, Tair Sabirgaliev wrote:
> > Here is the PR https://github.com/keycloak/keycloak/pull/3855
> >
> > I don?t know how to properly QA demos, please give me some
> > guidance on that, and I would be happy to maintain Angular 2
> > integration code later on.
> >
> > Here are some ideas I can work on:
> >
> > - upgrade to latest Angular
> > - refactor Keycloak service to a non-static singleton (a proper service)
> > - properly handle the session expiration in Keycloak service
> > - use ng-cli
> > - integration test the sample app
> > - use Angular routes and guards to secure HTML5 navigation
> > - experiment with alternative authentication flows
> >
> > and more!
> >
> > Why not have a real kitchensink-style Angular application a part of samples :)
> >
> > Thank you!
> >
> >
> > On 10 February 2017 at 19:29:39, Stan Silvert
> > (ssilvert at redhat.com(mailto:ssilvert at redhat.com)) wrote:
> >
> >> Thanks Tair. I'll be looking into this very soon. Probably next week.
> >>
> >> On 2/9/2017 6:19 PM, Tair Sabirgaliev wrote:
> >>> 1. The KeycloakHttp implementation overrides all the http methods, but
> >>> in the
> >>> Http class they all forward to 'request(...)' method, so overriding
> >>> `request(...)` should be enough.
> >>>
> >>> 2. It is not obvious why the implementation uses Observable.merge.
> >>> AFAICT the idea is to:
> >>>
> >>> (1) obtain the token (and update it BTW),
> >>> (2) put it in header,
> >>> (3) forward to superclass implementation.
> >>>
> >>> So we found that the whole KeycloakHttp implementation could be
> >>> reduced to the following:
> >>>
> >>> @Injectable()
> >>> export class KeycloakHttp extends Http {
> >>> constructor(_backend: ConnectionBackend, _defaultOptions:
> >>> RequestOptions, _keycloakService: KeycloakService) {
> >>> super(_backend, _defaultOptions);
> >>> }
> >>>
> >>> request(url: string | Request, options?: RequestOptionsArgs):
> >>> Observable {
> >>> const tokenPromise: Promise =
> >>> this._keycloakService.getToken();
> >>> const tokenObservable: Observable =
> >>> Observable.fromPromise(tokenPromise);
> >>>
> >>> if (typeof url === 'string') {
> >>> return tokenObservable.map(token => {
> >>> const authOptions = new RequestOptions({
> >>> headers: new Headers({'Authorization': 'Bearer ' +
> >>> token})
> >>> });
> >>> return new
> >>> RequestOptions().merge(options).merge(authOptions);
> >>> }).concatMap(opts => super.request(url, opts));
> >>> } else if (url instanceof Request) {
> >>> return tokenObservable.map(token => {
> >>> url.headers.set('Authorization', 'Bearer ' + token);
> >>> return url;
> >>> }).concatMap(request => super.request(request));
> >>> }
> >>> }
> >>>
> >>> }
> >>>
>


From macmike at gmail.com  Fri Feb 10 18:55:53 2017
From: macmike at gmail.com (Michael Olshansky)
Date: Fri, 10 Feb 2017 15:55:53 -0800
Subject: [keycloak-dev] auth token caching in cluster mode
Message-ID: <CAJZuFwUzTp-L6zO7mAmhiMG5oeqjTt7y+2n43zp4--t_AbN7ig@mail.gmail.com>

I have set up a keycloak cluster using the domain config and have nodes
running in master/slave.

I noticed that the refresh tokens are cached across nodes, though the auth
tokens are not.

Are auth tokens supposed to be cached across nodes?

From frelibert at yahoo.com  Mon Feb 13 05:51:13 2017
From: frelibert at yahoo.com (frelibert at yahoo.com)
Date: Mon, 13 Feb 2017 10:51:13 +0000 (UTC)
Subject: [keycloak-dev] Adding IdentityProviderMappers
References: <2076035425.2968536.1486983073385.ref@mail.yahoo.com>
Message-ID: <2076035425.2968536.1486983073385@mail.yahoo.com>

Hi,
The identity-provider-mapper SPI is an internal one.Any chance you will make it public?
I'd like to use it to write our own mapper.I actually allready have.I know it is not recommended to depend on an internal spi but I have written a new mapper as I needed something with less work to configure the mapping of our brokered saml idp to user attributes.?Our idp returns a lot of attributes and configuring each and every attribute is quite some work.
Moreover, you currently can't export this config from one realm to another in the same environment.My mapper is quite similar to the UserAttributeMapper but not limited to one attribute.It basically takes the incoming assertion and maps every saml attribute it finds to a user attribute with the same name.It has 5 config fields:- optional regex in order to filter out some attribute(s) you don't want to map.- name of attribute to use as firstName property.- name of attribute to use as lastName property.- name of attribute to use as email property.
- option to use saml friendlyName instead of Name to map with the user attribute name.
If you are interested, I am willing to share it with you.I like Keycloak a lot :-)
Kind regards,
Frederik Libert

From sts at ono.at  Mon Feb 13 06:16:42 2017
From: sts at ono.at (Stefan Schlesinger)
Date: Mon, 13 Feb 2017 12:16:42 +0100
Subject: [keycloak-dev] Keycloak integration with mod_auth_openidc broken
In-Reply-To: <CAJgngAdSwWEvWJiLUZke0dJPKpXsRpZkBYrKSbymPzriRxZNhg@mail.gmail.com>
References: <ECB40848-F149-467D-AF07-88469C270AE1@ono.at>
	<CAJgngAdSwWEvWJiLUZke0dJPKpXsRpZkBYrKSbymPzriRxZNhg@mail.gmail.com>
Message-ID: <443B0144-133B-4E40-9B4C-83DAF0FDF170@ono.at>

Hi Stian,

is this something which could make it into one of the next 2.5 releases (especially,
because 2.5 should be a version included in redhat, IIRC)?

A working integration with mod_auth_openidc would be essential.

Best,

Stefan.

> On 02 Feb 2017, at 07:10, Stian Thorgersen <sthorger at redhat.com> wrote:
> 
> It should support multi-valued and mapping to a array rather than a comma-separated list.
> 
> On 1 February 2017 at 21:06, Stefan Schlesinger <sts at ono.at> wrote:
> Hello,
> 
> it looks like its currently not possible to use mod_auth_openidc with Keycloak for authorization of legacy applications. The current workaround described by mod_auth_openidc is to use OpenID Connect for authentication and use the apache ldap module for authorization, which is a rather ugly workaround IMHO.
> 
> The problem currently is twofold:
> 
>  1) One can use mod_auth_openidc to verify claims, but it doesn?t come with JSON path support[1], so matching the claims in realm_access.roles isn?t possible, only arrays in a flat JSON tree are supported[2].
> 
>  2) This wouldn?t cause any issues, as Keycloak comes with a User Realm Role mapper, which is able to map roles to a different key (in my example below the key is ?roles?).
> 
> {
>   "jti": "01667279-a161-47ae-a093-b08643a1b7b5",
>   "exp": 1485977685,
>    ?
>   "realm_access": {
>     "roles": [
>       ?application_x",
>       ?application_y",
>       "uma_authorization",
>     ]
>   },
>   "roles": ?[application_x, application_y, uma_authorization]",
> }
> 
> The problem with the mapper is that the value of roles, is served as a string instead of an array and mod_auth_openidc cannot handle this properly[3].
> 
> Btw. the same thing goes for the User Client Role mapper! Which looks like this:
> 
> {
>   "client_role": "[login]?
> }
> 
> An issue for this has already been created: https://issues.jboss.org/browse/KEYCLOAK-4205
> 
> It would be so great to get this fixed in the next release!!
> 
> Best,
> 
> Stefan.
> 
> 
> [1] https://groups.google.com/forum/#!topic/mod_auth_openidc/QOMMYeXt5Jc
> [2] https://github.com/pingidentity/mod_auth_openidc/blob/master/src/authz.c#L85
> [3] https://github.com/pingidentity/mod_auth_openidc/blob/master/src/authz.c#L67
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 



From sthorger at redhat.com  Mon Feb 13 07:36:56 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 13 Feb 2017 13:36:56 +0100
Subject: [keycloak-dev] Keycloak integration with mod_auth_openidc broken
In-Reply-To: <443B0144-133B-4E40-9B4C-83DAF0FDF170@ono.at>
References: <ECB40848-F149-467D-AF07-88469C270AE1@ono.at>
	<CAJgngAdSwWEvWJiLUZke0dJPKpXsRpZkBYrKSbymPzriRxZNhg@mail.gmail.com>
	<443B0144-133B-4E40-9B4C-83DAF0FDF170@ono.at>
Message-ID: <CAJgngAej=ejSLG4REoi+kqhzyR2_GO=68PM6KaSYbds22e2k9g@mail.gmail.com>

I'm afraid it's too late to include new things for 2.5.

On 13 February 2017 at 12:16, Stefan Schlesinger <sts at ono.at> wrote:

> Hi Stian,
>
> is this something which could make it into one of the next 2.5 releases
> (especially,
> because 2.5 should be a version included in redhat, IIRC)?
>
> A working integration with mod_auth_openidc would be essential.
>
> Best,
>
> Stefan.
>
> > On 02 Feb 2017, at 07:10, Stian Thorgersen <sthorger at redhat.com> wrote:
> >
> > It should support multi-valued and mapping to a array rather than a
> comma-separated list.
> >
> > On 1 February 2017 at 21:06, Stefan Schlesinger <sts at ono.at> wrote:
> > Hello,
> >
> > it looks like its currently not possible to use mod_auth_openidc with
> Keycloak for authorization of legacy applications. The current workaround
> described by mod_auth_openidc is to use OpenID Connect for authentication
> and use the apache ldap module for authorization, which is a rather ugly
> workaround IMHO.
> >
> > The problem currently is twofold:
> >
> >  1) One can use mod_auth_openidc to verify claims, but it doesn?t come
> with JSON path support[1], so matching the claims in realm_access.roles
> isn?t possible, only arrays in a flat JSON tree are supported[2].
> >
> >  2) This wouldn?t cause any issues, as Keycloak comes with a User Realm
> Role mapper, which is able to map roles to a different key (in my example
> below the key is ?roles?).
> >
> > {
> >   "jti": "01667279-a161-47ae-a093-b08643a1b7b5",
> >   "exp": 1485977685,
> >    ?
> >   "realm_access": {
> >     "roles": [
> >       ?application_x",
> >       ?application_y",
> >       "uma_authorization",
> >     ]
> >   },
> >   "roles": ?[application_x, application_y, uma_authorization]",
> > }
> >
> > The problem with the mapper is that the value of roles, is served as a
> string instead of an array and mod_auth_openidc cannot handle this
> properly[3].
> >
> > Btw. the same thing goes for the User Client Role mapper! Which looks
> like this:
> >
> > {
> >   "client_role": "[login]?
> > }
> >
> > An issue for this has already been created: https://issues.jboss.org/
> browse/KEYCLOAK-4205
> >
> > It would be so great to get this fixed in the next release!!
> >
> > Best,
> >
> > Stefan.
> >
> >
> > [1] https://groups.google.com/forum/#!topic/mod_auth_openidc/QOMMYeXt5Jc
> > [2] https://github.com/pingidentity/mod_auth_openidc/
> blob/master/src/authz.c#L85
> > [3] https://github.com/pingidentity/mod_auth_openidc/
> blob/master/src/authz.c#L67
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sthorger at redhat.com  Mon Feb 13 07:46:09 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 13 Feb 2017 13:46:09 +0100
Subject: [keycloak-dev] Keycloak integration with mod_auth_openidc broken
In-Reply-To: <CAJgngAej=ejSLG4REoi+kqhzyR2_GO=68PM6KaSYbds22e2k9g@mail.gmail.com>
References: <ECB40848-F149-467D-AF07-88469C270AE1@ono.at>
	<CAJgngAdSwWEvWJiLUZke0dJPKpXsRpZkBYrKSbymPzriRxZNhg@mail.gmail.com>
	<443B0144-133B-4E40-9B4C-83DAF0FDF170@ono.at>
	<CAJgngAej=ejSLG4REoi+kqhzyR2_GO=68PM6KaSYbds22e2k9g@mail.gmail.com>
Message-ID: <CAJgngAcCARVSkNQKxj7kPggqSrkn1bi7oeYoUMTnaYvQyFS=XA@mail.gmail.com>

Actually on reviewing it again, I'd say this is a bug rather than a
enhancement request. What version are you using though? I just tried this
out and it's mapping it correctly for me:

{
  ...,
  "test": [
    "create-realm",
    "offline_access",
    "admin",
    "uma_authorization"
  ]
}


On 13 February 2017 at 13:36, Stian Thorgersen <sthorger at redhat.com> wrote:

> I'm afraid it's too late to include new things for 2.5.
>
> On 13 February 2017 at 12:16, Stefan Schlesinger <sts at ono.at> wrote:
>
>> Hi Stian,
>>
>> is this something which could make it into one of the next 2.5 releases
>> (especially,
>> because 2.5 should be a version included in redhat, IIRC)?
>>
>> A working integration with mod_auth_openidc would be essential.
>>
>> Best,
>>
>> Stefan.
>>
>> > On 02 Feb 2017, at 07:10, Stian Thorgersen <sthorger at redhat.com> wrote:
>> >
>> > It should support multi-valued and mapping to a array rather than a
>> comma-separated list.
>> >
>> > On 1 February 2017 at 21:06, Stefan Schlesinger <sts at ono.at> wrote:
>> > Hello,
>> >
>> > it looks like its currently not possible to use mod_auth_openidc with
>> Keycloak for authorization of legacy applications. The current workaround
>> described by mod_auth_openidc is to use OpenID Connect for authentication
>> and use the apache ldap module for authorization, which is a rather ugly
>> workaround IMHO.
>> >
>> > The problem currently is twofold:
>> >
>> >  1) One can use mod_auth_openidc to verify claims, but it doesn?t come
>> with JSON path support[1], so matching the claims in realm_access.roles
>> isn?t possible, only arrays in a flat JSON tree are supported[2].
>> >
>> >  2) This wouldn?t cause any issues, as Keycloak comes with a User Realm
>> Role mapper, which is able to map roles to a different key (in my example
>> below the key is ?roles?).
>> >
>> > {
>> >   "jti": "01667279-a161-47ae-a093-b08643a1b7b5",
>> >   "exp": 1485977685,
>> >    ?
>> >   "realm_access": {
>> >     "roles": [
>> >       ?application_x",
>> >       ?application_y",
>> >       "uma_authorization",
>> >     ]
>> >   },
>> >   "roles": ?[application_x, application_y, uma_authorization]",
>> > }
>> >
>> > The problem with the mapper is that the value of roles, is served as a
>> string instead of an array and mod_auth_openidc cannot handle this
>> properly[3].
>> >
>> > Btw. the same thing goes for the User Client Role mapper! Which looks
>> like this:
>> >
>> > {
>> >   "client_role": "[login]?
>> > }
>> >
>> > An issue for this has already been created:
>> https://issues.jboss.org/browse/KEYCLOAK-4205
>> >
>> > It would be so great to get this fixed in the next release!!
>> >
>> > Best,
>> >
>> > Stefan.
>> >
>> >
>> > [1] https://groups.google.com/forum/#!topic/mod_auth_openidc/
>> QOMMYeXt5Jc
>> > [2] https://github.com/pingidentity/mod_auth_openidc/blob/
>> master/src/authz.c#L85
>> > [3] https://github.com/pingidentity/mod_auth_openidc/blob/
>> master/src/authz.c#L67
>> > _______________________________________________
>> > keycloak-dev mailing list
>> > keycloak-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> >
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>

From sthorger at redhat.com  Mon Feb 13 07:48:23 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 13 Feb 2017 13:48:23 +0100
Subject: [keycloak-dev] Keycloak integration with mod_auth_openidc broken
In-Reply-To: <CAJgngAcCARVSkNQKxj7kPggqSrkn1bi7oeYoUMTnaYvQyFS=XA@mail.gmail.com>
References: <ECB40848-F149-467D-AF07-88469C270AE1@ono.at>
	<CAJgngAdSwWEvWJiLUZke0dJPKpXsRpZkBYrKSbymPzriRxZNhg@mail.gmail.com>
	<443B0144-133B-4E40-9B4C-83DAF0FDF170@ono.at>
	<CAJgngAej=ejSLG4REoi+kqhzyR2_GO=68PM6KaSYbds22e2k9g@mail.gmail.com>
	<CAJgngAcCARVSkNQKxj7kPggqSrkn1bi7oeYoUMTnaYvQyFS=XA@mail.gmail.com>
Message-ID: <CAJgngAdJhWUeHBBQcotDdU+tPEbwCSyfkWMnaJ-MdXJ-jJhAWQ@mail.gmail.com>

Actually, if you create the mapper and don't select anything for "Claim
JSON Type" it maps it as an array. If you set the "Claim JSON Type" you
don't have the option to select anything but String, which results in a
single string rather than an array.

On 13 February 2017 at 13:46, Stian Thorgersen <sthorger at redhat.com> wrote:

> Actually on reviewing it again, I'd say this is a bug rather than a
> enhancement request. What version are you using though? I just tried this
> out and it's mapping it correctly for me:
>
> {
>   ...,
>   "test": [
>     "create-realm",
>     "offline_access",
>     "admin",
>     "uma_authorization"
>   ]
> }
>
>
> On 13 February 2017 at 13:36, Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> I'm afraid it's too late to include new things for 2.5.
>>
>> On 13 February 2017 at 12:16, Stefan Schlesinger <sts at ono.at> wrote:
>>
>>> Hi Stian,
>>>
>>> is this something which could make it into one of the next 2.5 releases
>>> (especially,
>>> because 2.5 should be a version included in redhat, IIRC)?
>>>
>>> A working integration with mod_auth_openidc would be essential.
>>>
>>> Best,
>>>
>>> Stefan.
>>>
>>> > On 02 Feb 2017, at 07:10, Stian Thorgersen <sthorger at redhat.com>
>>> wrote:
>>> >
>>> > It should support multi-valued and mapping to a array rather than a
>>> comma-separated list.
>>> >
>>> > On 1 February 2017 at 21:06, Stefan Schlesinger <sts at ono.at> wrote:
>>> > Hello,
>>> >
>>> > it looks like its currently not possible to use mod_auth_openidc with
>>> Keycloak for authorization of legacy applications. The current workaround
>>> described by mod_auth_openidc is to use OpenID Connect for authentication
>>> and use the apache ldap module for authorization, which is a rather ugly
>>> workaround IMHO.
>>> >
>>> > The problem currently is twofold:
>>> >
>>> >  1) One can use mod_auth_openidc to verify claims, but it doesn?t come
>>> with JSON path support[1], so matching the claims in realm_access.roles
>>> isn?t possible, only arrays in a flat JSON tree are supported[2].
>>> >
>>> >  2) This wouldn?t cause any issues, as Keycloak comes with a User
>>> Realm Role mapper, which is able to map roles to a different key (in my
>>> example below the key is ?roles?).
>>> >
>>> > {
>>> >   "jti": "01667279-a161-47ae-a093-b08643a1b7b5",
>>> >   "exp": 1485977685,
>>> >    ?
>>> >   "realm_access": {
>>> >     "roles": [
>>> >       ?application_x",
>>> >       ?application_y",
>>> >       "uma_authorization",
>>> >     ]
>>> >   },
>>> >   "roles": ?[application_x, application_y, uma_authorization]",
>>> > }
>>> >
>>> > The problem with the mapper is that the value of roles, is served as a
>>> string instead of an array and mod_auth_openidc cannot handle this
>>> properly[3].
>>> >
>>> > Btw. the same thing goes for the User Client Role mapper! Which looks
>>> like this:
>>> >
>>> > {
>>> >   "client_role": "[login]?
>>> > }
>>> >
>>> > An issue for this has already been created:
>>> https://issues.jboss.org/browse/KEYCLOAK-4205
>>> >
>>> > It would be so great to get this fixed in the next release!!
>>> >
>>> > Best,
>>> >
>>> > Stefan.
>>> >
>>> >
>>> > [1] https://groups.google.com/forum/#!topic/mod_auth_openidc/QOM
>>> MYeXt5Jc
>>> > [2] https://github.com/pingidentity/mod_auth_openidc/blob/master
>>> /src/authz.c#L85
>>> > [3] https://github.com/pingidentity/mod_auth_openidc/blob/master
>>> /src/authz.c#L67
>>> > _______________________________________________
>>> > keycloak-dev mailing list
>>> > keycloak-dev at lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>> >
>>>
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>>
>

From thomas.darimont at googlemail.com  Mon Feb 13 13:24:10 2017
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Mon, 13 Feb 2017 19:24:10 +0100
Subject: [keycloak-dev] Keycloak integration with mod_auth_openidc broken
In-Reply-To: <CAJgngAdJhWUeHBBQcotDdU+tPEbwCSyfkWMnaJ-MdXJ-jJhAWQ@mail.gmail.com>
References: <ECB40848-F149-467D-AF07-88469C270AE1@ono.at>
	<CAJgngAdSwWEvWJiLUZke0dJPKpXsRpZkBYrKSbymPzriRxZNhg@mail.gmail.com>
	<443B0144-133B-4E40-9B4C-83DAF0FDF170@ono.at>
	<CAJgngAej=ejSLG4REoi+kqhzyR2_GO=68PM6KaSYbds22e2k9g@mail.gmail.com>
	<CAJgngAcCARVSkNQKxj7kPggqSrkn1bi7oeYoUMTnaYvQyFS=XA@mail.gmail.com>
	<CAJgngAdJhWUeHBBQcotDdU+tPEbwCSyfkWMnaJ-MdXJ-jJhAWQ@mail.gmail.com>
Message-ID: <CAK-7U1hf_a_v-87BBEeFwGAE9dC5+8RByPuC9s3KYrzktoUGcQ@mail.gmail.com>

Hello,

I just added a proposal for a (backwards compatible) fix against the
current master branch.
I think this could be back-ported to 2.5.x easily.

Cheers,
Thomas

2017-02-13 13:48 GMT+01:00 Stian Thorgersen <sthorger at redhat.com>:

> Actually, if you create the mapper and don't select anything for "Claim
> JSON Type" it maps it as an array. If you set the "Claim JSON Type" you
> don't have the option to select anything but String, which results in a
> single string rather than an array.
>
> On 13 February 2017 at 13:46, Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
> > Actually on reviewing it again, I'd say this is a bug rather than a
> > enhancement request. What version are you using though? I just tried this
> > out and it's mapping it correctly for me:
> >
> > {
> >   ...,
> >   "test": [
> >     "create-realm",
> >     "offline_access",
> >     "admin",
> >     "uma_authorization"
> >   ]
> > }
> >
> >
> > On 13 February 2017 at 13:36, Stian Thorgersen <sthorger at redhat.com>
> > wrote:
> >
> >> I'm afraid it's too late to include new things for 2.5.
> >>
> >> On 13 February 2017 at 12:16, Stefan Schlesinger <sts at ono.at> wrote:
> >>
> >>> Hi Stian,
> >>>
> >>> is this something which could make it into one of the next 2.5 releases
> >>> (especially,
> >>> because 2.5 should be a version included in redhat, IIRC)?
> >>>
> >>> A working integration with mod_auth_openidc would be essential.
> >>>
> >>> Best,
> >>>
> >>> Stefan.
> >>>
> >>> > On 02 Feb 2017, at 07:10, Stian Thorgersen <sthorger at redhat.com>
> >>> wrote:
> >>> >
> >>> > It should support multi-valued and mapping to a array rather than a
> >>> comma-separated list.
> >>> >
> >>> > On 1 February 2017 at 21:06, Stefan Schlesinger <sts at ono.at> wrote:
> >>> > Hello,
> >>> >
> >>> > it looks like its currently not possible to use mod_auth_openidc with
> >>> Keycloak for authorization of legacy applications. The current
> workaround
> >>> described by mod_auth_openidc is to use OpenID Connect for
> authentication
> >>> and use the apache ldap module for authorization, which is a rather
> ugly
> >>> workaround IMHO.
> >>> >
> >>> > The problem currently is twofold:
> >>> >
> >>> >  1) One can use mod_auth_openidc to verify claims, but it doesn?t
> come
> >>> with JSON path support[1], so matching the claims in realm_access.roles
> >>> isn?t possible, only arrays in a flat JSON tree are supported[2].
> >>> >
> >>> >  2) This wouldn?t cause any issues, as Keycloak comes with a User
> >>> Realm Role mapper, which is able to map roles to a different key (in my
> >>> example below the key is ?roles?).
> >>> >
> >>> > {
> >>> >   "jti": "01667279-a161-47ae-a093-b08643a1b7b5",
> >>> >   "exp": 1485977685,
> >>> >    ?
> >>> >   "realm_access": {
> >>> >     "roles": [
> >>> >       ?application_x",
> >>> >       ?application_y",
> >>> >       "uma_authorization",
> >>> >     ]
> >>> >   },
> >>> >   "roles": ?[application_x, application_y, uma_authorization]",
> >>> > }
> >>> >
> >>> > The problem with the mapper is that the value of roles, is served as
> a
> >>> string instead of an array and mod_auth_openidc cannot handle this
> >>> properly[3].
> >>> >
> >>> > Btw. the same thing goes for the User Client Role mapper! Which looks
> >>> like this:
> >>> >
> >>> > {
> >>> >   "client_role": "[login]?
> >>> > }
> >>> >
> >>> > An issue for this has already been created:
> >>> https://issues.jboss.org/browse/KEYCLOAK-4205
> >>> >
> >>> > It would be so great to get this fixed in the next release!!
> >>> >
> >>> > Best,
> >>> >
> >>> > Stefan.
> >>> >
> >>> >
> >>> > [1] https://groups.google.com/forum/#!topic/mod_auth_openidc/QOM
> >>> MYeXt5Jc
> >>> > [2] https://github.com/pingidentity/mod_auth_openidc/blob/master
> >>> /src/authz.c#L85
> >>> > [3] https://github.com/pingidentity/mod_auth_openidc/blob/master
> >>> /src/authz.c#L67
> >>> > _______________________________________________
> >>> > keycloak-dev mailing list
> >>> > keycloak-dev at lists.jboss.org
> >>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>> >
> >>>
> >>>
> >>> _______________________________________________
> >>> keycloak-dev mailing list
> >>> keycloak-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>
> >>
> >>
> >
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sts at ono.at  Mon Feb 13 13:51:50 2017
From: sts at ono.at (Stefan Schlesinger)
Date: Mon, 13 Feb 2017 19:51:50 +0100
Subject: [keycloak-dev] Keycloak integration with mod_auth_openidc broken
In-Reply-To: <CAJgngAdJhWUeHBBQcotDdU+tPEbwCSyfkWMnaJ-MdXJ-jJhAWQ@mail.gmail.com>
References: <ECB40848-F149-467D-AF07-88469C270AE1@ono.at>
	<CAJgngAdSwWEvWJiLUZke0dJPKpXsRpZkBYrKSbymPzriRxZNhg@mail.gmail.com>
	<443B0144-133B-4E40-9B4C-83DAF0FDF170@ono.at>
	<CAJgngAej=ejSLG4REoi+kqhzyR2_GO=68PM6KaSYbds22e2k9g@mail.gmail.com>
	<CAJgngAcCARVSkNQKxj7kPggqSrkn1bi7oeYoUMTnaYvQyFS=XA@mail.gmail.com>
	<CAJgngAdJhWUeHBBQcotDdU+tPEbwCSyfkWMnaJ-MdXJ-jJhAWQ@mail.gmail.com>
Message-ID: <6A5F6010-D049-46B6-ABF6-9A86EB30DAE9@ono.at>

Hi Stian,

thank you! I can confirm this fixes it.

Thanks!

Stefan.


> On 13 Feb 2017, at 13:48, Stian Thorgersen <sthorger at redhat.com> wrote:
> 
> Actually, if you create the mapper and don't select anything for "Claim JSON Type" it maps it as an array. If you set the "Claim JSON Type" you don't have the option to select anything but String, which results in a single string rather than an array.



From bartosz at redhat.com  Tue Feb 14 20:43:52 2017
From: bartosz at redhat.com (Bartosz Majsak)
Date: Wed, 15 Feb 2017 02:43:52 +0100
Subject: [keycloak-dev] Openshift Identity Provider for KeyCloak
Message-ID: <CA+C8PfzhYjMKagUbR=_C3gP9Ru9CU0Q8O7DGdLmHSAJVZ1W1GA@mail.gmail.com>

Hi,

I've implemented Openshift Identity Provider for KeyCloak [1]. Would you be
interested in getting it upstream?

Cheers,
Bartosz.

[1] https://github.com/bartoszmajsak/keycloak-openshift-identity-provider

From bartosz at redhat.com  Tue Feb 14 20:46:12 2017
From: bartosz at redhat.com (Bartosz Majsak)
Date: Wed, 15 Feb 2017 02:46:12 +0100
Subject: [keycloak-dev] Openshift Identity Provider for KeyCloak
Message-ID: <CA+C8PfzrAnSOhMK39Tp0JouwqdgF1YsZ5akbr7zsO4bMdwC=gQ@mail.gmail.com>

Hi,

I've implemented Openshift Identity Provider for KeyCloak [1]. Would you be
interested in getting it upstream?

Cheers,
Bartosz.

[1] https://github.com/bartoszmajsak/keycloak-openshift-identity-provider

From sthorger at redhat.com  Wed Feb 15 02:40:44 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 15 Feb 2017 08:40:44 +0100
Subject: [keycloak-dev] Documentation moved to single repository
Message-ID: <CAJgngAf_F3D5-4OP0KgOnqPfhZ8wdbjKj4twwtiWjyfNvhdMig@mail.gmail.com>

All the documentation has been moved to a single Github repository:
https://github.com/keycloak/keycloak-documentation

There is also a single Gitbook now:
https://keycloak.gitbooks.io/documentation/content/

From sblanc at redhat.com  Wed Feb 15 02:59:11 2017
From: sblanc at redhat.com (Sebastien Blanc)
Date: Wed, 15 Feb 2017 08:59:11 +0100
Subject: [keycloak-dev] Openshift Identity Provider for KeyCloak
In-Reply-To: <CA+C8PfzhYjMKagUbR=_C3gP9Ru9CU0Q8O7DGdLmHSAJVZ1W1GA@mail.gmail.com>
References: <CA+C8PfzhYjMKagUbR=_C3gP9Ru9CU0Q8O7DGdLmHSAJVZ1W1GA@mail.gmail.com>
Message-ID: <CAMZCGg96RXi7KGpP6Y0a4chchSU2iibit_x8r7qrmnDpirq8EA@mail.gmail.com>

Hi Bartosz !

This is really cool and IMO it would make sense to add this to the upstream
project.

Sebi

On Wed, Feb 15, 2017 at 2:43 AM, Bartosz Majsak <bartosz at redhat.com> wrote:

> Hi,
>
> I've implemented Openshift Identity Provider for KeyCloak [1]. Would you be
> interested in getting it upstream?
>
> Cheers,
> Bartosz.
>
> [1] https://github.com/bartoszmajsak/keycloak-openshift-identity-provider
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From tech at psynd.net  Wed Feb 15 05:25:52 2017
From: tech at psynd.net (Tech)
Date: Wed, 15 Feb 2017 11:25:52 +0100
Subject: [keycloak-dev] How to protect a PHP page
Message-ID: <a5b532a6-13e8-f99c-957d-445a458a0921@psynd.net>

Dear experts,

We are currently working with an application called Moodle, written in
PHP, that already supports OIDC.

The PHP is running over a simple Apache HTTPD, therefore we cannot use
any of the Out Of The Box client adapters available for Keycloak.

What should we do in this case? Is there any documentation or guide that
we should follow?

Thanks!


From sthorger at redhat.com  Wed Feb 15 06:29:23 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 15 Feb 2017 12:29:23 +0100
Subject: [keycloak-dev] Openshift Identity Provider for KeyCloak
In-Reply-To: <CA+C8PfzrAnSOhMK39Tp0JouwqdgF1YsZ5akbr7zsO4bMdwC=gQ@mail.gmail.com>
References: <CA+C8PfzrAnSOhMK39Tp0JouwqdgF1YsZ5akbr7zsO4bMdwC=gQ@mail.gmail.com>
Message-ID: <CAJgngAf=acnxcnN_14hpKKtZkqZ7oMED8Rt8bU5hFBJC6QGWuw@mail.gmail.com>

Not sure to be honest. Strictly speaking it should be the other way around.
OpenShift should authenticate against Keycloak (or another IdP) at least
for on-prem installations. For OpenShift Online I see a use-case for this,
but in that case can it not just use the OIDC provider?

On 15 February 2017 at 02:46, Bartosz Majsak <bartosz at redhat.com> wrote:

> Hi,
>
> I've implemented Openshift Identity Provider for KeyCloak [1]. Would you be
> interested in getting it upstream?
>
> Cheers,
> Bartosz.
>
> [1] https://github.com/bartoszmajsak/keycloak-openshift-identity-provider
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From bartosz at redhat.com  Wed Feb 15 06:38:10 2017
From: bartosz at redhat.com (Bartosz Majsak)
Date: Wed, 15 Feb 2017 12:38:10 +0100
Subject: [keycloak-dev] Openshift Identity Provider for KeyCloak
In-Reply-To: <CAJgngAf=acnxcnN_14hpKKtZkqZ7oMED8Rt8bU5hFBJC6QGWuw@mail.gmail.com>
References: <CA+C8PfzrAnSOhMK39Tp0JouwqdgF1YsZ5akbr7zsO4bMdwC=gQ@mail.gmail.com>
	<CAJgngAf=acnxcnN_14hpKKtZkqZ7oMED8Rt8bU5hFBJC6QGWuw@mail.gmail.com>
Message-ID: <CA+C8Pfwv4r-dZFd0SOipQWmoqF7oz6w5p2NOsxrfMEiqJRkXrw@mail.gmail.com>

OpenShift should authenticate against Keycloak (or another IdP) at least
for on-prem installations.

This is intended primarily for OSO I believe.

For OpenShift Online I see a use-case for this, but in that case can it not
just use the OIDC provider?

One issue I can already point out is that when using OIDC provider
authorization URL created by an AbstractOAuth2IdentityProvider will result
in bad request from OpenShift OAuth server, as it doesn?t accept
redirect_uri as a valid request parameter. At least when tested against
minishift.
?

On Wed, Feb 15, 2017 at 12:29 PM, Stian Thorgersen <sthorger at redhat.com>
wrote:

> Not sure to be honest. Strictly speaking it should be the other way
> around. OpenShift should authenticate against Keycloak (or another IdP) at
> least for on-prem installations. For OpenShift Online I see a use-case for
> this, but in that case can it not just use the OIDC provider?
>
> On 15 February 2017 at 02:46, Bartosz Majsak <bartosz at redhat.com> wrote:
>
>> Hi,
>>
>> I've implemented Openshift Identity Provider for KeyCloak [1]. Would you
>> be
>> interested in getting it upstream?
>>
>> Cheers,
>> Bartosz.
>>
>> [1] https://github.com/bartoszmajsak/keycloak-openshift-identity-provider
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>

From martin.hardselius at gmail.com  Wed Feb 15 08:46:07 2017
From: martin.hardselius at gmail.com (Martin Hardselius)
Date: Wed, 15 Feb 2017 13:46:07 +0000
Subject: [keycloak-dev] acr and acr_values
Message-ID: <CAPJq0L_2RKXEy1DnAqOkCnATypyykOZv7aLoWP2V6ombhLUQ9w@mail.gmail.com>

We're in the process of adding support for different levels of assurance in
our custom installation, which means that proper support for acr and
acr_values is becoming more of a priority. What's the status on this? Can
we assist with a PR?

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

This might fit better into keycloak-user, but if you already have plans for
acr-stuff, or planned refactorings that would affect how this is
implemented, I'd be happy for some advice on how to proceed with a
temporary solution.

Regards,
Martin

From bburke at redhat.com  Wed Feb 15 09:30:10 2017
From: bburke at redhat.com (Bill Burke)
Date: Wed, 15 Feb 2017 09:30:10 -0500
Subject: [keycloak-dev] Openshift Identity Provider for KeyCloak
In-Reply-To: <CA+C8Pfwv4r-dZFd0SOipQWmoqF7oz6w5p2NOsxrfMEiqJRkXrw@mail.gmail.com>
References: <CA+C8PfzrAnSOhMK39Tp0JouwqdgF1YsZ5akbr7zsO4bMdwC=gQ@mail.gmail.com>
	<CAJgngAf=acnxcnN_14hpKKtZkqZ7oMED8Rt8bU5hFBJC6QGWuw@mail.gmail.com>
	<CA+C8Pfwv4r-dZFd0SOipQWmoqF7oz6w5p2NOsxrfMEiqJRkXrw@mail.gmail.com>
Message-ID: <a1b6e43b-6f05-51f3-419c-ab0cf0794ae4@redhat.com>

redirect_uri is part of the OAuth spec, so it should.  Without a 
redirect URI, the IDP is supposed to abort authentication as this URI is 
validated.  You don't want to deliver an access code to a rogue URL.


On 2/15/17 6:38 AM, Bartosz Majsak wrote:
> OpenShift should authenticate against Keycloak (or another IdP) at least
> for on-prem installations.
>
> This is intended primarily for OSO I believe.
>
> For OpenShift Online I see a use-case for this, but in that case can it not
> just use the OIDC provider?
>
> One issue I can already point out is that when using OIDC provider
> authorization URL created by an AbstractOAuth2IdentityProvider will result
> in bad request from OpenShift OAuth server, as it doesn?t accept
> redirect_uri as a valid request parameter. At least when tested against
> minishift.
> ?
>
> On Wed, Feb 15, 2017 at 12:29 PM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> Not sure to be honest. Strictly speaking it should be the other way
>> around. OpenShift should authenticate against Keycloak (or another IdP) at
>> least for on-prem installations. For OpenShift Online I see a use-case for
>> this, but in that case can it not just use the OIDC provider?
>>
>> On 15 February 2017 at 02:46, Bartosz Majsak <bartosz at redhat.com> wrote:
>>
>>> Hi,
>>>
>>> I've implemented Openshift Identity Provider for KeyCloak [1]. Would you
>>> be
>>> interested in getting it upstream?
>>>
>>> Cheers,
>>> Bartosz.
>>>
>>> [1] https://github.com/bartoszmajsak/keycloak-openshift-identity-provider
>>> _______________________________________________
>>> 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 tech at psynd.net  Thu Feb 16 03:09:45 2017
From: tech at psynd.net (Tech)
Date: Thu, 16 Feb 2017 09:09:45 +0100
Subject: [keycloak-dev] How to protect a PHP page
In-Reply-To: <bbaccbca-060b-418a-80eb-50266cb134b7@gmail.com>
References: <a5b532a6-13e8-f99c-957d-445a458a0921@psynd.net>
	<bbaccbca-060b-418a-80eb-50266cb134b7@gmail.com>
Message-ID: <fc471ea2-106c-4ff7-eb8a-6b7efc5e0e1f@psynd.net>

Hello Abhi,

thanks for your reply. Is there any specific example that I might use?

Thanks!



On 02/15/2017 08:15 PM, abhishek raghav wrote:
> You can use any of the apache mods e.g. mod_auth_openidc or mod_mellon 
> . These mods are agnostic to any programming language/platform and 
> keycloak has a very good support for them.
> Hope it will help you.
> via Newton Mail 
> <https://cloudmagic.com/k/d/mailapp?ct=pi&cv=9.4.52&pv=10.2.1&source=email_footer_2>
>
> On Wed, Feb 15, 2017 at 3:55 PM, Tech <tech at psynd.net> wrote:
>
>     Dear experts,
>
>     We are currently working with an application called Moodle, written in
>     PHP, that already supports OIDC.
>
>     The PHP is running over a simple Apache HTTPD, therefore we cannot use
>     any of the Out Of The Box client adapters available for Keycloak.
>
>     What should we do in this case? Is there any documentation or
>     guide that
>     we should follow?
>
>     Thanks!
>
>     _______________________________________________
>     keycloak-dev mailing list
>     keycloak-dev at lists.jboss.org
>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>


From sthorger at redhat.com  Thu Feb 16 03:21:22 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 16 Feb 2017 09:21:22 +0100
Subject: [keycloak-dev] acr and acr_values
In-Reply-To: <CAPJq0L_2RKXEy1DnAqOkCnATypyykOZv7aLoWP2V6ombhLUQ9w@mail.gmail.com>
References: <CAPJq0L_2RKXEy1DnAqOkCnATypyykOZv7aLoWP2V6ombhLUQ9w@mail.gmail.com>
Message-ID: <CAJgngAc9y5uQch6NYJZ2h1PSze7SG29uP0b_Lq1my=AjAGTx6A@mail.gmail.com>

Can you elaborate on your use-case?

We have some plans to introduce a step-up-authentication mechanism. The
main idea is to have the concept of authentication levels. In the
authentication flows there would be additional metadata that would set the
authentication level. This means the authentication level can be set
independently to authenticators and authenticators doesn't even have to be
aware of it.

In summary a login flow would look something like:

* Username/password form
* Set authentication level = 1
* OTP form
* Set authentication level = 2

Behind the covers the authentication processor would know at which point in
the flow it's possible to exit the flow depending on the level requested.
The level requested would be base on:

* Realm default
* Client default
* Client requested

It would also support the client being able to initially request for level
1 then later ask for level 2. The authentication processor would it that
case be able to skip the parts of the flow that was previously executed.

We also had an idea about allowing alternative flows depending on what
level you are going from and to. This could be relevant if authenticators
allow collecting more than one thing on a single form. For example there
could be alternative authenticators for username-only, username+password,
username+password+otp. This would be done by having conditions on which
flow to select.


On 15 February 2017 at 14:46, Martin Hardselius <martin.hardselius at gmail.com
> wrote:

> We're in the process of adding support for different levels of assurance in
> our custom installation, which means that proper support for acr and
> acr_values is becoming more of a priority. What's the status on this? Can
> we assist with a PR?
>
> https://issues.jboss.org/browse/KEYCLOAK-3314
>
> This might fit better into keycloak-user, but if you already have plans for
> acr-stuff, or planned refactorings that would affect how this is
> implemented, I'd be happy for some advice on how to proceed with a
> temporary solution.
>
> Regards,
> Martin
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sthorger at redhat.com  Thu Feb 16 03:28:21 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 16 Feb 2017 09:28:21 +0100
Subject: [keycloak-dev] Adding IdentityProviderMappers
In-Reply-To: <2076035425.2968536.1486983073385@mail.yahoo.com>
References: <2076035425.2968536.1486983073385.ref@mail.yahoo.com>
	<2076035425.2968536.1486983073385@mail.yahoo.com>
Message-ID: <CAJgngAffMwJyF=TRC5gfRiW4d1D0E4y+tad037FZ=eL6ne3Y=A@mail.gmail.com>

You can use the internal SPIs, but bear in mind that these are not
guaranteed to be backwards compatible. They are also not supported in Red
Hat Single Sign-On.

We are planning on refining and making more and more SPIs public and
backwards compatible. However, that's a big task and we have to do it
incrementally.

Could be handy to have a built-in mapper that copies everything, would like
to see it have both inclusion and exclusion though. Maybe it should support
space separate lists as well rather than just regex. To accept it we'd have
to have the same mapper for OIDC and SAML, it would also need to be fully
tested.

On 13 February 2017 at 11:51, <frelibert at yahoo.com> wrote:

> Hi,
> The identity-provider-mapper SPI is an internal one.Any chance you will
> make it public?
> I'd like to use it to write our own mapper.I actually allready have.I know
> it is not recommended to depend on an internal spi but I have written a new
> mapper as I needed something with less work to configure the mapping of our
> brokered saml idp to user attributes. Our idp returns a lot of attributes
> and configuring each and every attribute is quite some work.
> Moreover, you currently can't export this config from one realm to another
> in the same environment.My mapper is quite similar to the
> UserAttributeMapper but not limited to one attribute.It basically takes the
> incoming assertion and maps every saml attribute it finds to a user
> attribute with the same name.It has 5 config fields:- optional regex in
> order to filter out some attribute(s) you don't want to map.- name of
> attribute to use as firstName property.- name of attribute to use as
> lastName property.- name of attribute to use as email property.
> - option to use saml friendlyName instead of Name to map with the user
> attribute name.
> If you are interested, I am willing to share it with you.I like Keycloak a
> lot :-)
> Kind regards,
> Frederik Libert
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From martin.hardselius at gmail.com  Thu Feb 16 04:08:23 2017
From: martin.hardselius at gmail.com (Martin Hardselius)
Date: Thu, 16 Feb 2017 09:08:23 +0000
Subject: [keycloak-dev] acr and acr_values
In-Reply-To: <CAJgngAc9y5uQch6NYJZ2h1PSze7SG29uP0b_Lq1my=AjAGTx6A@mail.gmail.com>
References: <CAPJq0L_2RKXEy1DnAqOkCnATypyykOZv7aLoWP2V6ombhLUQ9w@mail.gmail.com>
	<CAJgngAc9y5uQch6NYJZ2h1PSze7SG29uP0b_Lq1my=AjAGTx6A@mail.gmail.com>
Message-ID: <CAPJq0L8FNityLye=sRQraS5e3efwXdAu8yQELyThQvbN528iLA@mail.gmail.com>

There's a bunch of different use-cases, but step-up authentication is
indeed one of them. In addition to email/uname + pwd, sms otp or TOTP we
need to support means of authentication with higher levels of assurance.
Like Norwegian BankID, Swedish BankID, Danish NemID, Finnish Tupas,
Estonian ESTEeID, etc. This is something that we could probably accomplish
with cunning use of query parameters and prompt=login, and it would
resemble the standard way to do it, but it would still be somewhat hackish.

Since this is also telco related, we're looking at Mobile Connect down the
road, and acr and acr_values are required by the Mobile Connect profile.

https://developer.mobileconnect.io/mobile-connect-profile-v1-2

The ideas you listed all look super relevant. One thing that I would find
useful is support for a "method portal" of sorts. The End-User would be
able to select her method of authentication. This is relevant when you have
several options on a single assurance level. Like in Norway, where we have
both BankID and Buypass.

I hope this made sense.

Martin

On Thu, 16 Feb 2017 at 09:21 Stian Thorgersen <sthorger at redhat.com> wrote:

> Can you elaborate on your use-case?
>
> We have some plans to introduce a step-up-authentication mechanism. The
> main idea is to have the concept of authentication levels. In the
> authentication flows there would be additional metadata that would set the
> authentication level. This means the authentication level can be set
> independently to authenticators and authenticators doesn't even have to be
> aware of it.
>
> In summary a login flow would look something like:
>
> * Username/password form
> * Set authentication level = 1
> * OTP form
> * Set authentication level = 2
>
> Behind the covers the authentication processor would know at which point
> in the flow it's possible to exit the flow depending on the level
> requested. The level requested would be base on:
>
> * Realm default
> * Client default
> * Client requested
>
> It would also support the client being able to initially request for level
> 1 then later ask for level 2. The authentication processor would it that
> case be able to skip the parts of the flow that was previously executed.
>
> We also had an idea about allowing alternative flows depending on what
> level you are going from and to. This could be relevant if authenticators
> allow collecting more than one thing on a single form. For example there
> could be alternative authenticators for username-only, username+password,
> username+password+otp. This would be done by having conditions on which
> flow to select.
>
>
> On 15 February 2017 at 14:46, Martin Hardselius <
> martin.hardselius at gmail.com> wrote:
>
> We're in the process of adding support for different levels of assurance in
> our custom installation, which means that proper support for acr and
> acr_values is becoming more of a priority. What's the status on this? Can
> we assist with a PR?
>
> https://issues.jboss.org/browse/KEYCLOAK-3314
>
> This might fit better into keycloak-user, but if you already have plans for
> acr-stuff, or planned refactorings that would affect how this is
> implemented, I'd be happy for some advice on how to proceed with a
> temporary solution.
>
> Regards,
> Martin
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>

From Sebastian.Schuster at bosch-si.com  Thu Feb 16 04:31:59 2017
From: Sebastian.Schuster at bosch-si.com (Schuster Sebastian (INST/ESY1))
Date: Thu, 16 Feb 2017 09:31:59 +0000
Subject: [keycloak-dev] acr and acr_values
In-Reply-To: <CAJgngAc9y5uQch6NYJZ2h1PSze7SG29uP0b_Lq1my=AjAGTx6A@mail.gmail.com>
References: <CAPJq0L_2RKXEy1DnAqOkCnATypyykOZv7aLoWP2V6ombhLUQ9w@mail.gmail.com>
	<CAJgngAc9y5uQch6NYJZ2h1PSze7SG29uP0b_Lq1my=AjAGTx6A@mail.gmail.com>
Message-ID: <41120688F6FCE840B172FD409300D9E82838E4A7@BE6PW2EXD01.bosch-si.com>

Hi all,

there is an upcoming standard on Levels of Assurance at NIST https://pages.nist.gov/800-63-3/.
Justin Richer blogged about it here https://medium.com/@justinsecurity/vectors-of-trust-ed52a57fe025#.c9eo8ihmx
Maybe that's interesting in this context.

Best regards,
Sebastian

-----Urspr?ngliche Nachricht-----
Von: keycloak-dev-bounces at lists.jboss.org [mailto:keycloak-dev-bounces at lists.jboss.org] Im Auftrag von Stian Thorgersen
Gesendet: Donnerstag, 16. Februar 2017 09:21
An: Martin Hardselius <martin.hardselius at gmail.com>
Cc: keycloak-dev <keycloak-dev at lists.jboss.org>
Betreff: Re: [keycloak-dev] acr and acr_values

Can you elaborate on your use-case?

We have some plans to introduce a step-up-authentication mechanism. The main idea is to have the concept of authentication levels. In the authentication flows there would be additional metadata that would set the authentication level. This means the authentication level can be set independently to authenticators and authenticators doesn't even have to be aware of it.

In summary a login flow would look something like:

* Username/password form
* Set authentication level = 1
* OTP form
* Set authentication level = 2

Behind the covers the authentication processor would know at which point in the flow it's possible to exit the flow depending on the level requested.
The level requested would be base on:

* Realm default
* Client default
* Client requested

It would also support the client being able to initially request for level
1 then later ask for level 2. The authentication processor would it that case be able to skip the parts of the flow that was previously executed.

We also had an idea about allowing alternative flows depending on what level you are going from and to. This could be relevant if authenticators allow collecting more than one thing on a single form. For example there could be alternative authenticators for username-only, username+password,
username+password+otp. This would be done by having conditions on which
flow to select.


On 15 February 2017 at 14:46, Martin Hardselius <martin.hardselius at gmail.com
> wrote:

> We're in the process of adding support for different levels of 
> assurance in our custom installation, which means that proper support 
> for acr and acr_values is becoming more of a priority. What's the 
> status on this? Can we assist with a PR?
>
> https://issues.jboss.org/browse/KEYCLOAK-3314
>
> This might fit better into keycloak-user, but if you already have 
> plans for acr-stuff, or planned refactorings that would affect how 
> this is implemented, I'd be happy for some advice on how to proceed 
> with a temporary solution.
>
> Regards,
> Martin
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
_______________________________________________
keycloak-dev mailing list
keycloak-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev


From sthorger at redhat.com  Thu Feb 16 04:50:57 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 16 Feb 2017 10:50:57 +0100
Subject: [keycloak-dev] MongoDB removed from master
Message-ID: <CAJgngAfs8Gm4dn2C9QvecfhHbLMUWtb44X9wMP=7fDrgepMXQw@mail.gmail.com>

MongoDB support is now removed from master

From sthorger at redhat.com  Thu Feb 16 08:10:46 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 16 Feb 2017 14:10:46 +0100
Subject: [keycloak-dev] acr and acr_values
In-Reply-To: <CAPJq0L8FNityLye=sRQraS5e3efwXdAu8yQELyThQvbN528iLA@mail.gmail.com>
References: <CAPJq0L_2RKXEy1DnAqOkCnATypyykOZv7aLoWP2V6ombhLUQ9w@mail.gmail.com>
	<CAJgngAc9y5uQch6NYJZ2h1PSze7SG29uP0b_Lq1my=AjAGTx6A@mail.gmail.com>
	<CAPJq0L8FNityLye=sRQraS5e3efwXdAu8yQELyThQvbN528iLA@mail.gmail.com>
Message-ID: <CAJgngAcMrsqjwqNNkk8skDTP6cQGYRHQb52mvO2pFKNpiAfbwQ@mail.gmail.com>

On 16 February 2017 at 10:08, Martin Hardselius <martin.hardselius at gmail.com
> wrote:

> There's a bunch of different use-cases, but step-up authentication is
> indeed one of them. In addition to email/uname + pwd, sms otp or TOTP we
> need to support means of authentication with higher levels of assurance.
> Like Norwegian BankID, Swedish BankID, Danish NemID, Finnish Tupas,
> Estonian ESTEeID, etc. This is something that we could probably accomplish
> with cunning use of query parameters and prompt=login, and it would
> resemble the standard way to do it, but it would still be somewhat hackish.
>

I think that would work just fine. Authentication levels (level of
assurance is more accurate term) could range from 0 to 100, they could also
have aliases associated with them. By introducing a level 4 that is
associated with things like BankID a client can request that level of
assurance simply by passing acr_values query param. If the user is already
authenticated with level 3 the user would be asked to input BankID (or
another means).

We've been planning to introduce ability for admins to select what two
factor mechanisms are supported for a realm and allow users to have one or
more two factor mechanisms. We'd probably need to extend on that idea to
also allow flexible primary means of authentication.

I guess the admin should be able to configure what credential types are
available for a realm. The various credential types would be associated
somehow with authenticators and authenticator/assurance levels. Then the
users can pick and choose which mechanisms they want to enable in their
account. They can also have multiple alternative types (for example OTP or
SMS, and BankID vs something else with the same level of assurance). We'd
also support pluggable credential types that would allow adding additional
screens to account management console and/or admin console for
configuration.


>
> Since this is also telco related, we're looking at Mobile Connect down the
> road, and acr and acr_values are required by the Mobile Connect profile.
>
> https://developer.mobileconnect.io/mobile-connect-profile-v1-2
>
> The ideas you listed all look super relevant. One thing that I would find
> useful is support for a "method portal" of sorts. The End-User would be
> able to select her method of authentication. This is relevant when you have
> several options on a single assurance level. Like in Norway, where we have
> both BankID and Buypass.
>
> I hope this made sense.
>
> Martin
>
> On Thu, 16 Feb 2017 at 09:21 Stian Thorgersen <sthorger at redhat.com> wrote:
>
>> Can you elaborate on your use-case?
>>
>> We have some plans to introduce a step-up-authentication mechanism. The
>> main idea is to have the concept of authentication levels. In the
>> authentication flows there would be additional metadata that would set the
>> authentication level. This means the authentication level can be set
>> independently to authenticators and authenticators doesn't even have to be
>> aware of it.
>>
>> In summary a login flow would look something like:
>>
>> * Username/password form
>> * Set authentication level = 1
>> * OTP form
>> * Set authentication level = 2
>>
>> Behind the covers the authentication processor would know at which point
>> in the flow it's possible to exit the flow depending on the level
>> requested. The level requested would be base on:
>>
>> * Realm default
>> * Client default
>> * Client requested
>>
>> It would also support the client being able to initially request for
>> level 1 then later ask for level 2. The authentication processor would it
>> that case be able to skip the parts of the flow that was previously
>> executed.
>>
>> We also had an idea about allowing alternative flows depending on what
>> level you are going from and to. This could be relevant if authenticators
>> allow collecting more than one thing on a single form. For example there
>> could be alternative authenticators for username-only, username+password,
>> username+password+otp. This would be done by having conditions on which
>> flow to select.
>>
>>
>> On 15 February 2017 at 14:46, Martin Hardselius <
>> martin.hardselius at gmail.com> wrote:
>>
>> We're in the process of adding support for different levels of assurance
>> in
>> our custom installation, which means that proper support for acr and
>> acr_values is becoming more of a priority. What's the status on this? Can
>> we assist with a PR?
>>
>> https://issues.jboss.org/browse/KEYCLOAK-3314
>>
>> This might fit better into keycloak-user, but if you already have plans
>> for
>> acr-stuff, or planned refactorings that would affect how this is
>> implemented, I'd be happy for some advice on how to proceed with a
>> temporary solution.
>>
>> Regards,
>> Martin
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>>

From bburke at redhat.com  Thu Feb 16 09:25:14 2017
From: bburke at redhat.com (Bill Burke)
Date: Thu, 16 Feb 2017 09:25:14 -0500
Subject: [keycloak-dev] acr and acr_values
In-Reply-To: <41120688F6FCE840B172FD409300D9E82838E4A7@BE6PW2EXD01.bosch-si.com>
References: <CAPJq0L_2RKXEy1DnAqOkCnATypyykOZv7aLoWP2V6ombhLUQ9w@mail.gmail.com>
	<CAJgngAc9y5uQch6NYJZ2h1PSze7SG29uP0b_Lq1my=AjAGTx6A@mail.gmail.com>
	<41120688F6FCE840B172FD409300D9E82838E4A7@BE6PW2EXD01.bosch-si.com>
Message-ID: <56761551-4d18-c428-d5ff-c2aaa86b8ea0@redhat.com>

We'll just be attacking authentication vector of trust.


On 2/16/17 4:31 AM, Schuster Sebastian (INST/ESY1) wrote:
> Hi all,
>
> there is an upcoming standard on Levels of Assurance at NIST https://pages.nist.gov/800-63-3/.
> Justin Richer blogged about it here https://medium.com/@justinsecurity/vectors-of-trust-ed52a57fe025#.c9eo8ihmx
> Maybe that's interesting in this context.
>
> Best regards,
> Sebastian
>
> -----Urspr?ngliche Nachricht-----
> Von: keycloak-dev-bounces at lists.jboss.org [mailto:keycloak-dev-bounces at lists.jboss.org] Im Auftrag von Stian Thorgersen
> Gesendet: Donnerstag, 16. Februar 2017 09:21
> An: Martin Hardselius <martin.hardselius at gmail.com>
> Cc: keycloak-dev <keycloak-dev at lists.jboss.org>
> Betreff: Re: [keycloak-dev] acr and acr_values
>
> Can you elaborate on your use-case?
>
> We have some plans to introduce a step-up-authentication mechanism. The main idea is to have the concept of authentication levels. In the authentication flows there would be additional metadata that would set the authentication level. This means the authentication level can be set independently to authenticators and authenticators doesn't even have to be aware of it.
>
> In summary a login flow would look something like:
>
> * Username/password form
> * Set authentication level = 1
> * OTP form
> * Set authentication level = 2
>
> Behind the covers the authentication processor would know at which point in the flow it's possible to exit the flow depending on the level requested.
> The level requested would be base on:
>
> * Realm default
> * Client default
> * Client requested
>
> It would also support the client being able to initially request for level
> 1 then later ask for level 2. The authentication processor would it that case be able to skip the parts of the flow that was previously executed.
>
> We also had an idea about allowing alternative flows depending on what level you are going from and to. This could be relevant if authenticators allow collecting more than one thing on a single form. For example there could be alternative authenticators for username-only, username+password,
> username+password+otp. This would be done by having conditions on which
> flow to select.
>
>
> On 15 February 2017 at 14:46, Martin Hardselius <martin.hardselius at gmail.com
>> wrote:
>> We're in the process of adding support for different levels of
>> assurance in our custom installation, which means that proper support
>> for acr and acr_values is becoming more of a priority. What's the
>> status on this? Can we assist with a PR?
>>
>> https://issues.jboss.org/browse/KEYCLOAK-3314
>>
>> This might fit better into keycloak-user, but if you already have
>> plans for acr-stuff, or planned refactorings that would affect how
>> this is implemented, I'd be happy for some advice on how to proceed
>> with a temporary solution.
>>
>> Regards,
>> Martin
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From psilva at redhat.com  Thu Feb 16 10:07:21 2017
From: psilva at redhat.com (Pedro Igor Silva)
Date: Thu, 16 Feb 2017 13:07:21 -0200
Subject: [keycloak-dev] OAuth2 JWT Secured Authorization Request (JAR)
Message-ID: <CAJrcDBdMhv9mmJN79qfbTctL=BQPrmQSjJBHGE0OB-eEyq1ovw@mail.gmail.com>

Really interesting spec to improve security to authorization requests [1]
sent to a AS.

Any similarity with SAML is just coincidence :)

[1] https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq

Regards.
Pedro Igor

From bburke at redhat.com  Thu Feb 16 10:18:32 2017
From: bburke at redhat.com (Bill Burke)
Date: Thu, 16 Feb 2017 10:18:32 -0500
Subject: [keycloak-dev] OAuth2 JWT Secured Authorization Request (JAR)
In-Reply-To: <CAJrcDBdMhv9mmJN79qfbTctL=BQPrmQSjJBHGE0OB-eEyq1ovw@mail.gmail.com>
References: <CAJrcDBdMhv9mmJN79qfbTctL=BQPrmQSjJBHGE0OB-eEyq1ovw@mail.gmail.com>
Message-ID: <4924177e-d937-f8b9-6d11-8fff99b2e52e@redhat.com>

I'm sure they'll create a POST binding next because the URLs will be too 
big.


On 2/16/17 10:07 AM, Pedro Igor Silva wrote:
> Really interesting spec to improve security to authorization requests [1]
> sent to a AS.
>
> Any similarity with SAML is just coincidence :)
>
> [1] https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq
>
> Regards.
> Pedro Igor
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From psilva at redhat.com  Thu Feb 16 12:32:49 2017
From: psilva at redhat.com (Pedro Igor Silva)
Date: Thu, 16 Feb 2017 15:32:49 -0200
Subject: [keycloak-dev] OAuth2 JWT Secured Authorization Request (JAR)
In-Reply-To: <4924177e-d937-f8b9-6d11-8fff99b2e52e@redhat.com>
References: <CAJrcDBdMhv9mmJN79qfbTctL=BQPrmQSjJBHGE0OB-eEyq1ovw@mail.gmail.com>
	<4924177e-d937-f8b9-6d11-8fff99b2e52e@redhat.com>
Message-ID: <CAJrcDBdExdSyRPp3J1hoOyX8WeDvnCFhdiYRMTQKbiej1js3yA@mail.gmail.com>

There is a spec for this already .... An OIDC one
https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html.

On Thu, Feb 16, 2017 at 1:18 PM, Bill Burke <bburke at redhat.com> wrote:

> I'm sure they'll create a POST binding next because the URLs will be too
> big.
>
>
> On 2/16/17 10:07 AM, Pedro Igor Silva wrote:
> > Really interesting spec to improve security to authorization requests [1]
> > sent to a AS.
> >
> > Any similarity with SAML is just coincidence :)
> >
> > [1] https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq
> >
> > Regards.
> > Pedro Igor
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From bartosz at redhat.com  Thu Feb 16 13:57:03 2017
From: bartosz at redhat.com (Bartosz Majsak)
Date: Thu, 16 Feb 2017 19:57:03 +0100
Subject: [keycloak-dev] Openshift Identity Provider for KeyCloak
In-Reply-To: <a1b6e43b-6f05-51f3-419c-ab0cf0794ae4@redhat.com>
References: <CA+C8PfzrAnSOhMK39Tp0JouwqdgF1YsZ5akbr7zsO4bMdwC=gQ@mail.gmail.com>
	<CAJgngAf=acnxcnN_14hpKKtZkqZ7oMED8Rt8bU5hFBJC6QGWuw@mail.gmail.com>
	<CA+C8Pfwv4r-dZFd0SOipQWmoqF7oz6w5p2NOsxrfMEiqJRkXrw@mail.gmail.com>
	<a1b6e43b-6f05-51f3-419c-ab0cf0794ae4@redhat.com>
Message-ID: <CA+C8PfzD+OMNJAQCNRQ-hRzxdyt47ARK65iWUXV9vVrGv+WNUQ@mail.gmail.com>

redirect_uri is part of the OAuth spec, so it should.

That?s totally correct. My bad, I must have been in a rabbit hole chasing
bunch of other issues in my code and somehow assumed that was the root
cause. In fact it works with and w/o it, as redirect uri is configured when
you register a client in Openshift [1].

But still, I cannot simply use OIDC as it adds openid to the scope and this
results in Openshift OAuth server complaining about the request - "Invalid
value: "openid": no scope handler found"

My implementation is based on AbstractOAuth2IdentityProvider and in fact it
only differs when it comes to extracting profile information (other changes
done in the project I shared in the opening mail are not feasible to make
it upstream).

To elaborate a bit on the use-case: our DevTools project will need to have
an access to user?s OSO resources such as projects and thus we need such
integration. We can live with SPI extension, but if you feel like it would
be beneficial to the project I?m more than happy to contribute this piece
(and improved based upon feedback from the PR).

Cheers,
Bartosz.

[1]
https://docs.openshift.org/latest/architecture/additional_concepts/authentication.html#oauth-clients
?

On Wed, Feb 15, 2017 at 3:30 PM, Bill Burke <bburke at redhat.com> wrote:

> redirect_uri is part of the OAuth spec, so it should.  Without a
> redirect URI, the IDP is supposed to abort authentication as this URI is
> validated.  You don't want to deliver an access code to a rogue URL.
>
>
> On 2/15/17 6:38 AM, Bartosz Majsak wrote:
> > OpenShift should authenticate against Keycloak (or another IdP) at least
> > for on-prem installations.
> >
> > This is intended primarily for OSO I believe.
> >
> > For OpenShift Online I see a use-case for this, but in that case can it
> not
> > just use the OIDC provider?
> >
> > One issue I can already point out is that when using OIDC provider
> > authorization URL created by an AbstractOAuth2IdentityProvider will
> result
> > in bad request from OpenShift OAuth server, as it doesn?t accept
> > redirect_uri as a valid request parameter. At least when tested against
> > minishift.
> > ?
> >
> > On Wed, Feb 15, 2017 at 12:29 PM, Stian Thorgersen <sthorger at redhat.com>
> > wrote:
> >
> >> Not sure to be honest. Strictly speaking it should be the other way
> >> around. OpenShift should authenticate against Keycloak (or another IdP)
> at
> >> least for on-prem installations. For OpenShift Online I see a use-case
> for
> >> this, but in that case can it not just use the OIDC provider?
> >>
> >> On 15 February 2017 at 02:46, Bartosz Majsak <bartosz at redhat.com>
> wrote:
> >>
> >>> Hi,
> >>>
> >>> I've implemented Openshift Identity Provider for KeyCloak [1]. Would
> you
> >>> be
> >>> interested in getting it upstream?
> >>>
> >>> Cheers,
> >>> Bartosz.
> >>>
> >>> [1] https://github.com/bartoszmajsak/keycloak-
> openshift-identity-provider
> >>> _______________________________________________
> >>> keycloak-dev mailing list
> >>> keycloak-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>
> >>
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From martin.hardselius at gmail.com  Fri Feb 17 03:12:27 2017
From: martin.hardselius at gmail.com (Martin Hardselius)
Date: Fri, 17 Feb 2017 08:12:27 +0000
Subject: [keycloak-dev] acr and acr_values
In-Reply-To: <56761551-4d18-c428-d5ff-c2aaa86b8ea0@redhat.com>
References: <CAPJq0L_2RKXEy1DnAqOkCnATypyykOZv7aLoWP2V6ombhLUQ9w@mail.gmail.com>
	<CAJgngAc9y5uQch6NYJZ2h1PSze7SG29uP0b_Lq1my=AjAGTx6A@mail.gmail.com>
	<41120688F6FCE840B172FD409300D9E82838E4A7@BE6PW2EXD01.bosch-si.com>
	<56761551-4d18-c428-d5ff-c2aaa86b8ea0@redhat.com>
Message-ID: <CAPJq0L931fQG4=yS3HVYq5V6QeyT-S4+RF0eT6z==7jSzzPvcA@mail.gmail.com>

Seems like there's a draft on VoT that applies to OpenID Connect:
https://tools.ietf.org/html/draft-richer-vectors-of-trust-04#section-4.2

On Thu, 16 Feb 2017 at 15:25 Bill Burke <bburke at redhat.com> wrote:

> We'll just be attacking authentication vector of trust.
>
>
> On 2/16/17 4:31 AM, Schuster Sebastian (INST/ESY1) wrote:
> > Hi all,
> >
> > there is an upcoming standard on Levels of Assurance at NIST
> https://pages.nist.gov/800-63-3/.
> > Justin Richer blogged about it here
> https://medium.com/@justinsecurity/vectors-of-trust-ed52a57fe025#.c9eo8ihmx
> > Maybe that's interesting in this context.
> >
> > Best regards,
> > Sebastian
> >
> > -----Urspr?ngliche Nachricht-----
> > Von: keycloak-dev-bounces at lists.jboss.org [mailto:
> keycloak-dev-bounces at lists.jboss.org] Im Auftrag von Stian Thorgersen
> > Gesendet: Donnerstag, 16. Februar 2017 09:21
> > An: Martin Hardselius <martin.hardselius at gmail.com>
> > Cc: keycloak-dev <keycloak-dev at lists.jboss.org>
> > Betreff: Re: [keycloak-dev] acr and acr_values
> >
> > Can you elaborate on your use-case?
> >
> > We have some plans to introduce a step-up-authentication mechanism. The
> main idea is to have the concept of authentication levels. In the
> authentication flows there would be additional metadata that would set the
> authentication level. This means the authentication level can be set
> independently to authenticators and authenticators doesn't even have to be
> aware of it.
> >
> > In summary a login flow would look something like:
> >
> > * Username/password form
> > * Set authentication level = 1
> > * OTP form
> > * Set authentication level = 2
> >
> > Behind the covers the authentication processor would know at which point
> in the flow it's possible to exit the flow depending on the level requested.
> > The level requested would be base on:
> >
> > * Realm default
> > * Client default
> > * Client requested
> >
> > It would also support the client being able to initially request for
> level
> > 1 then later ask for level 2. The authentication processor would it that
> case be able to skip the parts of the flow that was previously executed.
> >
> > We also had an idea about allowing alternative flows depending on what
> level you are going from and to. This could be relevant if authenticators
> allow collecting more than one thing on a single form. For example there
> could be alternative authenticators for username-only, username+password,
> > username+password+otp. This would be done by having conditions on which
> > flow to select.
> >
> >
> > On 15 February 2017 at 14:46, Martin Hardselius <
> martin.hardselius at gmail.com
> >> wrote:
> >> We're in the process of adding support for different levels of
> >> assurance in our custom installation, which means that proper support
> >> for acr and acr_values is becoming more of a priority. What's the
> >> status on this? Can we assist with a PR?
> >>
> >> https://issues.jboss.org/browse/KEYCLOAK-3314
> >>
> >> This might fit better into keycloak-user, but if you already have
> >> plans for acr-stuff, or planned refactorings that would affect how
> >> this is implemented, I'd be happy for some advice on how to proceed
> >> with a temporary solution.
> >>
> >> Regards,
> >> Martin
> >> _______________________________________________
> >> 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
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From mposolda at redhat.com  Fri Feb 17 16:12:05 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 17 Feb 2017 22:12:05 +0100
Subject: [keycloak-dev] Improving testsuite performance
Message-ID: <caa6c998-d04a-ef3a-7610-fb87baad7422@redhat.com>

ATM running tests in the new arquillian testsuite ( 
testsuite/integration-arquillian ) is significantly slower then running 
tests in the old testsuite ( testsuite/integration ). It was quite 
visible in some tests, which were around 3 times slower after they were 
migrated from the old testsuite.

We found that there are 2 major bottlenecks causing it:
- There is re-import of all the realms before each test method. In the 
old testsuite, it was just BeforeClass.
- The new testsuite uses phantomjs WebDriver by default. The old one 
used htmlUnit. I've checked that phantomjs is around 15-times slower 
than htmlUnit. The main reason is that htmlUnit talks directly with the 
tested server, when phantomJS (similarly like all other real browsers) 
uses remote selenium server, which adds significant overhead. For 
example all the simple operations like "driver.getTitle()" needs to send 
HTTP request to the selenium server.

Hence I've looked at the possibility to switch to htmlUnit by default 
and sent PR for it: https://github.com/keycloak/keycloak/pull/3876 .

New testsuite runs on my laptop in 21 minutes with htmlUnit, when 
previously it was 36 minutes.

However there is the disadvantage, that htmlUnit has limited javascript 
support and is not the best for angular apps. It seems that admin 
console tests won't run with it. I also needed to do some refactoring of 
few existing tests to have them pass with htmlUnit (eg. 
AbstractDemoServletsAdapterTest to use assertEvents instead of admin 
console etc).

However this won't be an issue as browser implementation can be 
overriden with: -Dbrowser=phantomjs

So it's possible to run console tests with proper browsers.

Anyone seeing issues with switch to htmlUnit by default?

I hope that after fix the import + maybe few other things (eg. share 
adminClient per class instead of test method etc), we will be able to 
run whole testsuite in less than 15 minutes!

Thanks,
Marek


From mposolda at redhat.com  Fri Feb 17 16:14:07 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 17 Feb 2017 22:14:07 +0100
Subject: [keycloak-dev] OAuth2 JWT Secured Authorization Request (JAR)
In-Reply-To: <CAJrcDBdExdSyRPp3J1hoOyX8WeDvnCFhdiYRMTQKbiej1js3yA@mail.gmail.com>
References: <CAJrcDBdMhv9mmJN79qfbTctL=BQPrmQSjJBHGE0OB-eEyq1ovw@mail.gmail.com>
	<4924177e-d937-f8b9-6d11-8fff99b2e52e@redhat.com>
	<CAJrcDBdExdSyRPp3J1hoOyX8WeDvnCFhdiYRMTQKbiej1js3yA@mail.gmail.com>
Message-ID: <7e99c117-6bb8-4f1d-736e-9bc0e8543732@redhat.com>

On 16/02/17 18:32, Pedro Igor Silva wrote:
> There is a spec for this already .... An OIDC one
> https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html.
And we already support that one on keycloak server side (no support in 
adapters ATM).

Marek
>
> On Thu, Feb 16, 2017 at 1:18 PM, Bill Burke <bburke at redhat.com> wrote:
>
>> I'm sure they'll create a POST binding next because the URLs will be too
>> big.
>>
>>
>> On 2/16/17 10:07 AM, Pedro Igor Silva wrote:
>>> Really interesting spec to improve security to authorization requests [1]
>>> sent to a AS.
>>>
>>> Any similarity with SAML is just coincidence :)
>>>
>>> [1] https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq
>>>
>>> Regards.
>>> Pedro Igor
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



From tair.sabirgaliev at gmail.com  Sat Feb 18 03:50:49 2017
From: tair.sabirgaliev at gmail.com (Tair Sabirgaliev)
Date: Sat, 18 Feb 2017 00:50:49 -0800
Subject: [keycloak-dev] Build keycloak
Message-ID: <CAGU3vRfH0OFHU50GxRU_W5mZ7px49xVaOvS-58nYs=0u1LESMw@mail.gmail.com>

Hi!

Is the documentation on hacking on Keycloak up to date? I can't successfully
build Keycloak from sources several days so far.

Here is what I tried per
https://github.com/keycloak/keycloak/blob/master/README.md:

$ mvn install
$ man install -Pdistribution
$ mvn install -Dmaven.test.skip=true -Pdistribution

All these commands fail on integration tests.

Here are my system details:

MacBook-Pro:~ tair$ git --version; java -version; mvn --version
git version 2.11.0
java version "1.8.0_111"
Java(TM) SE Runtime Environment (build 1.8.0_111-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.111-b14, mixed mode)
Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
2015-11-10T22:41:47+06:00)
Maven home: /opt/local/share/java/maven3
Java version: 1.8.0_111, vendor: Oracle Corporation
Java home: /Library/Java/JavaVirtualMachines/jdk1.8.0_111.jdk/Contents/Home/jre
Default locale: en_GB, platform encoding: UTF-8
OS name: "mac os x", version: "10.12.3", arch: "x86_64", family: ?mac"


From bartosz at redhat.com  Sat Feb 18 11:31:07 2017
From: bartosz at redhat.com (Bartosz Majsak)
Date: Sat, 18 Feb 2017 17:31:07 +0100
Subject: [keycloak-dev] Improving testsuite performance
In-Reply-To: <caa6c998-d04a-ef3a-7610-fb87baad7422@redhat.com>
References: <caa6c998-d04a-ef3a-7610-fb87baad7422@redhat.com>
Message-ID: <CA+C8PfxK+qaowVE1YmpUHmx0B7LVWvA6nBWdMTjNfJeJN5DWiQ@mail.gmail.com>

Hi Marek,

are you running drone tests in parallel? It could be possible to speed it
up with just tweaking surfire. In my last project we were using 8-12
parallel drones and this gave us quite an advantage.

I would be happy to help.

Cheers,
Bartosz.

On Fri, Feb 17, 2017 at 10:12 PM, Marek Posolda <mposolda at redhat.com> wrote:

> ATM running tests in the new arquillian testsuite (
> testsuite/integration-arquillian ) is significantly slower then running
> tests in the old testsuite ( testsuite/integration ). It was quite
> visible in some tests, which were around 3 times slower after they were
> migrated from the old testsuite.
>
> We found that there are 2 major bottlenecks causing it:
> - There is re-import of all the realms before each test method. In the
> old testsuite, it was just BeforeClass.
> - The new testsuite uses phantomjs WebDriver by default. The old one
> used htmlUnit. I've checked that phantomjs is around 15-times slower
> than htmlUnit. The main reason is that htmlUnit talks directly with the
> tested server, when phantomJS (similarly like all other real browsers)
> uses remote selenium server, which adds significant overhead. For
> example all the simple operations like "driver.getTitle()" needs to send
> HTTP request to the selenium server.
>
> Hence I've looked at the possibility to switch to htmlUnit by default
> and sent PR for it: https://github.com/keycloak/keycloak/pull/3876 .
>
> New testsuite runs on my laptop in 21 minutes with htmlUnit, when
> previously it was 36 minutes.
>
> However there is the disadvantage, that htmlUnit has limited javascript
> support and is not the best for angular apps. It seems that admin
> console tests won't run with it. I also needed to do some refactoring of
> few existing tests to have them pass with htmlUnit (eg.
> AbstractDemoServletsAdapterTest to use assertEvents instead of admin
> console etc).
>
> However this won't be an issue as browser implementation can be
> overriden with: -Dbrowser=phantomjs
>
> So it's possible to run console tests with proper browsers.
>
> Anyone seeing issues with switch to htmlUnit by default?
>
> I hope that after fix the import + maybe few other things (eg. share
> adminClient per class instead of test method etc), we will be able to
> run whole testsuite in less than 15 minutes!
>
> Thanks,
> Marek
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From gaalvarez0910 at gmail.com  Sun Feb 19 17:47:35 2017
From: gaalvarez0910 at gmail.com (Gustavo Alvarez)
Date: Sun, 19 Feb 2017 22:47:35 +0000
Subject: [keycloak-dev] Build keycloak
In-Reply-To: <CAGU3vRfH0OFHU50GxRU_W5mZ7px49xVaOvS-58nYs=0u1LESMw@mail.gmail.com>
References: <CAGU3vRfH0OFHU50GxRU_W5mZ7px49xVaOvS-58nYs=0u1LESMw@mail.gmail.com>
Message-ID: <CAAhLkKPwF27N41i4pcSBGW0P25_YWfNan=c8ZA_jDH+4gT1zvA@mail.gmail.com>

Hello Tair.

I had the same problem, I am using this command for build distribution
files:

    mvn clean install -B -DskipTests -Pdistribution

This information is in
https://github.com/keycloak/keycloak/blob/fc6d6ff7f7dae7fb25edf052659d18cd8de55a5f/testsuite/integration-arquillian/tests/other/sssd/README.md

This was useful for me, I hope for you too.

Gaalvarez.

On Sat, Feb 18, 2017 at 3:51 AM Tair Sabirgaliev <tair.sabirgaliev at gmail.com>
wrote:

> Hi!
>
> Is the documentation on hacking on Keycloak up to date? I can't
> successfully
> build Keycloak from sources several days so far.
>
> Here is what I tried per
> https://github.com/keycloak/keycloak/blob/master/README.md:
>
> $ mvn install
> $ man install -Pdistribution
> $ mvn install -Dmaven.test.skip=true -Pdistribution
>
> All these commands fail on integration tests.
>
> Here are my system details:
>
> MacBook-Pro:~ tair$ git --version; java -version; mvn --version
> git version 2.11.0
> java version "1.8.0_111"
> Java(TM) SE Runtime Environment (build 1.8.0_111-b14)
> Java HotSpot(TM) 64-Bit Server VM (build 25.111-b14, mixed mode)
> Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
> 2015-11-10T22:41:47+06:00)
> Maven home: /opt/local/share/java/maven3
> Java version: 1.8.0_111, vendor: Oracle Corporation
> Java home:
> /Library/Java/JavaVirtualMachines/jdk1.8.0_111.jdk/Contents/Home/jre
> Default locale: en_GB, platform encoding: UTF-8
> OS name: "mac os x", version: "10.12.3", arch: "x86_64", family: ?mac"
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From mposolda at redhat.com  Mon Feb 20 06:19:15 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 20 Feb 2017 12:19:15 +0100
Subject: [keycloak-dev] Improving testsuite performance
In-Reply-To: <CA+C8PfxK+qaowVE1YmpUHmx0B7LVWvA6nBWdMTjNfJeJN5DWiQ@mail.gmail.com>
References: <caa6c998-d04a-ef3a-7610-fb87baad7422@redhat.com>
	<CA+C8PfxK+qaowVE1YmpUHmx0B7LVWvA6nBWdMTjNfJeJN5DWiQ@mail.gmail.com>
Message-ID: <4281d342-075d-5943-f4e4-d930b3373951@redhat.com>

Hi Bartosz,

we are using parallel running tests on Travis (our CI). That allows test 
classes to be divided into groups and each group is running concurrently 
with other groups. Example script is here:
https://github.com/keycloak/keycloak/blob/master/travis-run-tests.sh

Did you mean something like that?

Thanks,
Marek

On 18/02/17 17:31, Bartosz Majsak wrote:
> Hi Marek,
>
> are you running drone tests in parallel? It could be possible to speed 
> it up with just tweaking surfire. In my last project we were using 
> 8-12 parallel drones and this gave us quite an advantage.
>
> I would be happy to help.
>
> Cheers,
> Bartosz.
>
> On Fri, Feb 17, 2017 at 10:12 PM, Marek Posolda <mposolda at redhat.com 
> <mailto:mposolda at redhat.com>> wrote:
>
>     ATM running tests in the new arquillian testsuite (
>     testsuite/integration-arquillian ) is significantly slower then
>     running
>     tests in the old testsuite ( testsuite/integration ). It was quite
>     visible in some tests, which were around 3 times slower after they
>     were
>     migrated from the old testsuite.
>
>     We found that there are 2 major bottlenecks causing it:
>     - There is re-import of all the realms before each test method. In the
>     old testsuite, it was just BeforeClass.
>     - The new testsuite uses phantomjs WebDriver by default. The old one
>     used htmlUnit. I've checked that phantomjs is around 15-times slower
>     than htmlUnit. The main reason is that htmlUnit talks directly
>     with the
>     tested server, when phantomJS (similarly like all other real browsers)
>     uses remote selenium server, which adds significant overhead. For
>     example all the simple operations like "driver.getTitle()" needs
>     to send
>     HTTP request to the selenium server.
>
>     Hence I've looked at the possibility to switch to htmlUnit by default
>     and sent PR for it: https://github.com/keycloak/keycloak/pull/3876
>     <https://github.com/keycloak/keycloak/pull/3876> .
>
>     New testsuite runs on my laptop in 21 minutes with htmlUnit, when
>     previously it was 36 minutes.
>
>     However there is the disadvantage, that htmlUnit has limited
>     javascript
>     support and is not the best for angular apps. It seems that admin
>     console tests won't run with it. I also needed to do some
>     refactoring of
>     few existing tests to have them pass with htmlUnit (eg.
>     AbstractDemoServletsAdapterTest to use assertEvents instead of admin
>     console etc).
>
>     However this won't be an issue as browser implementation can be
>     overriden with: -Dbrowser=phantomjs
>
>     So it's possible to run console tests with proper browsers.
>
>     Anyone seeing issues with switch to htmlUnit by default?
>
>     I hope that after fix the import + maybe few other things (eg. share
>     adminClient per class instead of test method etc), we will be able to
>     run whole testsuite in less than 15 minutes!
>
>     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
>     <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>
>


From bartosz at redhat.com  Mon Feb 20 06:35:04 2017
From: bartosz at redhat.com (Bartosz Majsak)
Date: Mon, 20 Feb 2017 12:35:04 +0100
Subject: [keycloak-dev] Improving testsuite performance
In-Reply-To: <4281d342-075d-5943-f4e4-d930b3373951@redhat.com>
References: <caa6c998-d04a-ef3a-7610-fb87baad7422@redhat.com>
	<CA+C8PfxK+qaowVE1YmpUHmx0B7LVWvA6nBWdMTjNfJeJN5DWiQ@mail.gmail.com>
	<4281d342-075d-5943-f4e4-d930b3373951@redhat.com>
Message-ID: <CA+C8Pfy+exapA-_fu-KjGuJa+--Eox1zZ=ow2TTST6B0+Af6yA@mail.gmail.com>

Hi Marek,

I meant running x browser tests in parallel with Drone. That can be
achieved with surefire/failsafe. Not sure how does phantomjs nor
htmlunit handles that, but I was successfully running drone tests using
chrome and firefox this way.

Cheers,
Bartosz.

On Mon, Feb 20, 2017 at 12:19 PM, Marek Posolda <mposolda at redhat.com> wrote:

> Hi Bartosz,
>
> we are using parallel running tests on Travis (our CI). That allows test
> classes to be divided into groups and each group is running concurrently
> with other groups. Example script is here:
> https://github.com/keycloak/keycloak/blob/master/travis-run-tests.sh
>
> Did you mean something like that?
>
> Thanks,
> Marek
>
>
> On 18/02/17 17:31, Bartosz Majsak wrote:
>
> Hi Marek,
>
> are you running drone tests in parallel? It could be possible to speed it
> up with just tweaking surfire. In my last project we were using 8-12
> parallel drones and this gave us quite an advantage.
>
> I would be happy to help.
>
> Cheers,
> Bartosz.
>
> On Fri, Feb 17, 2017 at 10:12 PM, Marek Posolda <mposolda at redhat.com>
> wrote:
>
>> ATM running tests in the new arquillian testsuite (
>> testsuite/integration-arquillian ) is significantly slower then running
>> tests in the old testsuite ( testsuite/integration ). It was quite
>> visible in some tests, which were around 3 times slower after they were
>> migrated from the old testsuite.
>>
>> We found that there are 2 major bottlenecks causing it:
>> - There is re-import of all the realms before each test method. In the
>> old testsuite, it was just BeforeClass.
>> - The new testsuite uses phantomjs WebDriver by default. The old one
>> used htmlUnit. I've checked that phantomjs is around 15-times slower
>> than htmlUnit. The main reason is that htmlUnit talks directly with the
>> tested server, when phantomJS (similarly like all other real browsers)
>> uses remote selenium server, which adds significant overhead. For
>> example all the simple operations like "driver.getTitle()" needs to send
>> HTTP request to the selenium server.
>>
>> Hence I've looked at the possibility to switch to htmlUnit by default
>> and sent PR for it: https://github.com/keycloak/keycloak/pull/3876 .
>>
>> New testsuite runs on my laptop in 21 minutes with htmlUnit, when
>> previously it was 36 minutes.
>>
>> However there is the disadvantage, that htmlUnit has limited javascript
>> support and is not the best for angular apps. It seems that admin
>> console tests won't run with it. I also needed to do some refactoring of
>> few existing tests to have them pass with htmlUnit (eg.
>> AbstractDemoServletsAdapterTest to use assertEvents instead of admin
>> console etc).
>>
>> However this won't be an issue as browser implementation can be
>> overriden with: -Dbrowser=phantomjs
>>
>> So it's possible to run console tests with proper browsers.
>>
>> Anyone seeing issues with switch to htmlUnit by default?
>>
>> I hope that after fix the import + maybe few other things (eg. share
>> adminClient per class instead of test method etc), we will be able to
>> run whole testsuite in less than 15 minutes!
>>
>> Thanks,
>> Marek
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
>

From tair.sabirgaliev at gmail.com  Mon Feb 20 06:54:32 2017
From: tair.sabirgaliev at gmail.com (Tair Sabirgaliev)
Date: Mon, 20 Feb 2017 11:54:32 +0000
Subject: [keycloak-dev] Build keycloak
In-Reply-To: <CAAhLkKPwF27N41i4pcSBGW0P25_YWfNan=c8ZA_jDH+4gT1zvA@mail.gmail.com>
References: <CAGU3vRfH0OFHU50GxRU_W5mZ7px49xVaOvS-58nYs=0u1LESMw@mail.gmail.com>
	<CAAhLkKPwF27N41i4pcSBGW0P25_YWfNan=c8ZA_jDH+4gT1zvA@mail.gmail.com>
Message-ID: <CAGU3vRezX8gSQe4LMkZuqf4fUDUDnp7ioHPJRxC84F7XBosx6w@mail.gmail.com>

Great, thanks! It helped!
On Mon, Feb 20, 2017 at 04:47 Gustavo Alvarez <gaalvarez0910 at gmail.com>
wrote:

> Hello Tair.
>
> I had the same problem, I am using this command for build distribution
> files:
>
>     mvn clean install -B -DskipTests -Pdistribution
>
> This information is in
> https://github.com/keycloak/keycloak/blob/fc6d6ff7f7dae7fb25edf052659d18cd8de55a5f/testsuite/integration-arquillian/tests/other/sssd/README.md
>
> This was useful for me, I hope for you too.
>
> Gaalvarez.
>
> On Sat, Feb 18, 2017 at 3:51 AM Tair Sabirgaliev <
> tair.sabirgaliev at gmail.com> wrote:
>
> Hi!
>
> Is the documentation on hacking on Keycloak up to date? I can't
> successfully
> build Keycloak from sources several days so far.
>
> Here is what I tried per
> https://github.com/keycloak/keycloak/blob/master/README.md:
>
> $ mvn install
> $ man install -Pdistribution
> $ mvn install -Dmaven.test.skip=true -Pdistribution
>
> All these commands fail on integration tests.
>
> Here are my system details:
>
> MacBook-Pro:~ tair$ git --version; java -version; mvn --version
> git version 2.11.0
> java version "1.8.0_111"
> Java(TM) SE Runtime Environment (build 1.8.0_111-b14)
> Java HotSpot(TM) 64-Bit Server VM (build 25.111-b14, mixed mode)
> Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
> 2015-11-10T22:41:47+06:00)
> Maven home: /opt/local/share/java/maven3
> Java version: 1.8.0_111, vendor: Oracle Corporation
> Java home:
> /Library/Java/JavaVirtualMachines/jdk1.8.0_111.jdk/Contents/Home/jre
> Default locale: en_GB, platform encoding: UTF-8
> OS name: "mac os x", version: "10.12.3", arch: "x86_64", family: ?mac"
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>

From sthorger at redhat.com  Mon Feb 20 08:08:14 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 20 Feb 2017 14:08:14 +0100
Subject: [keycloak-dev] Build keycloak
In-Reply-To: <CAGU3vRezX8gSQe4LMkZuqf4fUDUDnp7ioHPJRxC84F7XBosx6w@mail.gmail.com>
References: <CAGU3vRfH0OFHU50GxRU_W5mZ7px49xVaOvS-58nYs=0u1LESMw@mail.gmail.com>
	<CAAhLkKPwF27N41i4pcSBGW0P25_YWfNan=c8ZA_jDH+4gT1zvA@mail.gmail.com>
	<CAGU3vRezX8gSQe4LMkZuqf4fUDUDnp7ioHPJRxC84F7XBosx6w@mail.gmail.com>
Message-ID: <CAJgngAdHn74BpkKpqZNcc+f0+tT=xhRt2=z-FDD2b3V6pjr0Ew@mail.gmail.com>

Tests sometimes fails randomly - we're working on improving the tests to
make them more stable

On 20 February 2017 at 12:54, Tair Sabirgaliev <tair.sabirgaliev at gmail.com>
wrote:

> Great, thanks! It helped!
> On Mon, Feb 20, 2017 at 04:47 Gustavo Alvarez <gaalvarez0910 at gmail.com>
> wrote:
>
> > Hello Tair.
> >
> > I had the same problem, I am using this command for build distribution
> > files:
> >
> >     mvn clean install -B -DskipTests -Pdistribution
> >
> > This information is in
> > https://github.com/keycloak/keycloak/blob/fc6d6ff7f7dae7fb25edf052659d18
> cd8de55a5f/testsuite/integration-arquillian/tests/other/sssd/README.md
> >
> > This was useful for me, I hope for you too.
> >
> > Gaalvarez.
> >
> > On Sat, Feb 18, 2017 at 3:51 AM Tair Sabirgaliev <
> > tair.sabirgaliev at gmail.com> wrote:
> >
> > Hi!
> >
> > Is the documentation on hacking on Keycloak up to date? I can't
> > successfully
> > build Keycloak from sources several days so far.
> >
> > Here is what I tried per
> > https://github.com/keycloak/keycloak/blob/master/README.md:
> >
> > $ mvn install
> > $ man install -Pdistribution
> > $ mvn install -Dmaven.test.skip=true -Pdistribution
> >
> > All these commands fail on integration tests.
> >
> > Here are my system details:
> >
> > MacBook-Pro:~ tair$ git --version; java -version; mvn --version
> > git version 2.11.0
> > java version "1.8.0_111"
> > Java(TM) SE Runtime Environment (build 1.8.0_111-b14)
> > Java HotSpot(TM) 64-Bit Server VM (build 25.111-b14, mixed mode)
> > Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
> > 2015-11-10T22:41:47+06:00)
> > Maven home: /opt/local/share/java/maven3
> > Java version: 1.8.0_111, vendor: Oracle Corporation
> > Java home:
> > /Library/Java/JavaVirtualMachines/jdk1.8.0_111.jdk/Contents/Home/jre
> > Default locale: en_GB, platform encoding: UTF-8
> > OS name: "mac os x", version: "10.12.3", arch: "x86_64", family: ?mac"
> >
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> >
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sthorger at redhat.com  Mon Feb 20 08:16:57 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 20 Feb 2017 14:16:57 +0100
Subject: [keycloak-dev] Improving testsuite performance
In-Reply-To: <CA+C8Pfy+exapA-_fu-KjGuJa+--Eox1zZ=ow2TTST6B0+Af6yA@mail.gmail.com>
References: <caa6c998-d04a-ef3a-7610-fb87baad7422@redhat.com>
	<CA+C8PfxK+qaowVE1YmpUHmx0B7LVWvA6nBWdMTjNfJeJN5DWiQ@mail.gmail.com>
	<4281d342-075d-5943-f4e4-d930b3373951@redhat.com>
	<CA+C8Pfy+exapA-_fu-KjGuJa+--Eox1zZ=ow2TTST6B0+Af6yA@mail.gmail.com>
Message-ID: <CAJgngAeraQhyh+z93RCZ1wmkRbf2GbiNJ7skgD2dJ9nncVJzXw@mail.gmail.com>

Sounds very interesting, but do you not have to be incredibly careful that
tests don't conflict with each other? Can you mark tests that can be ran
paralellell and those that can't?

On 20 February 2017 at 12:35, Bartosz Majsak <bartosz at redhat.com> wrote:

> Hi Marek,
>
> I meant running x browser tests in parallel with Drone. That can be
> achieved with surefire/failsafe. Not sure how does phantomjs nor
> htmlunit handles that, but I was successfully running drone tests using
> chrome and firefox this way.
>
> Cheers,
> Bartosz.
>
> On Mon, Feb 20, 2017 at 12:19 PM, Marek Posolda <mposolda at redhat.com>
> wrote:
>
> > Hi Bartosz,
> >
> > we are using parallel running tests on Travis (our CI). That allows test
> > classes to be divided into groups and each group is running concurrently
> > with other groups. Example script is here:
> > https://github.com/keycloak/keycloak/blob/master/travis-run-tests.sh
> >
> > Did you mean something like that?
> >
> > Thanks,
> > Marek
> >
> >
> > On 18/02/17 17:31, Bartosz Majsak wrote:
> >
> > Hi Marek,
> >
> > are you running drone tests in parallel? It could be possible to speed it
> > up with just tweaking surfire. In my last project we were using 8-12
> > parallel drones and this gave us quite an advantage.
> >
> > I would be happy to help.
> >
> > Cheers,
> > Bartosz.
> >
> > On Fri, Feb 17, 2017 at 10:12 PM, Marek Posolda <mposolda at redhat.com>
> > wrote:
> >
> >> ATM running tests in the new arquillian testsuite (
> >> testsuite/integration-arquillian ) is significantly slower then running
> >> tests in the old testsuite ( testsuite/integration ). It was quite
> >> visible in some tests, which were around 3 times slower after they were
> >> migrated from the old testsuite.
> >>
> >> We found that there are 2 major bottlenecks causing it:
> >> - There is re-import of all the realms before each test method. In the
> >> old testsuite, it was just BeforeClass.
> >> - The new testsuite uses phantomjs WebDriver by default. The old one
> >> used htmlUnit. I've checked that phantomjs is around 15-times slower
> >> than htmlUnit. The main reason is that htmlUnit talks directly with the
> >> tested server, when phantomJS (similarly like all other real browsers)
> >> uses remote selenium server, which adds significant overhead. For
> >> example all the simple operations like "driver.getTitle()" needs to send
> >> HTTP request to the selenium server.
> >>
> >> Hence I've looked at the possibility to switch to htmlUnit by default
> >> and sent PR for it: https://github.com/keycloak/keycloak/pull/3876 .
> >>
> >> New testsuite runs on my laptop in 21 minutes with htmlUnit, when
> >> previously it was 36 minutes.
> >>
> >> However there is the disadvantage, that htmlUnit has limited javascript
> >> support and is not the best for angular apps. It seems that admin
> >> console tests won't run with it. I also needed to do some refactoring of
> >> few existing tests to have them pass with htmlUnit (eg.
> >> AbstractDemoServletsAdapterTest to use assertEvents instead of admin
> >> console etc).
> >>
> >> However this won't be an issue as browser implementation can be
> >> overriden with: -Dbrowser=phantomjs
> >>
> >> So it's possible to run console tests with proper browsers.
> >>
> >> Anyone seeing issues with switch to htmlUnit by default?
> >>
> >> I hope that after fix the import + maybe few other things (eg. share
> >> adminClient per class instead of test method etc), we will be able to
> >> run whole testsuite in less than 15 minutes!
> >>
> >> 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 sthorger at redhat.com  Mon Feb 20 08:38:12 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 20 Feb 2017 14:38:12 +0100
Subject: [keycloak-dev] Openshift Identity Provider for KeyCloak
In-Reply-To: <CA+C8PfzD+OMNJAQCNRQ-hRzxdyt47ARK65iWUXV9vVrGv+WNUQ@mail.gmail.com>
References: <CA+C8PfzrAnSOhMK39Tp0JouwqdgF1YsZ5akbr7zsO4bMdwC=gQ@mail.gmail.com>
	<CAJgngAf=acnxcnN_14hpKKtZkqZ7oMED8Rt8bU5hFBJC6QGWuw@mail.gmail.com>
	<CA+C8Pfwv4r-dZFd0SOipQWmoqF7oz6w5p2NOsxrfMEiqJRkXrw@mail.gmail.com>
	<a1b6e43b-6f05-51f3-419c-ab0cf0794ae4@redhat.com>
	<CA+C8PfzD+OMNJAQCNRQ-hRzxdyt47ARK65iWUXV9vVrGv+WNUQ@mail.gmail.com>
Message-ID: <CAJgngAdf5N=bS0Kgibq=A-3mhKRVNnrn=dF0i=koM_kNG_wNRg@mail.gmail.com>

Once OpenShift v3 online is up and running will it allow users to register
clients so they can use it as a "social login provider"? If so sure let's
add it and have it by default point to OpenShift Online. We need
documentation added as well as testing though.

Testing:
https://github.com/keycloak/keycloak/blob/master/testsuite/integration-arquillian/tests/base/src/test/java/org/keycloak/testsuite/broker/SocialLoginTest.java
https://github.com/keycloak/keycloak/blob/master/testsuite/integration-arquillian/HOW-TO-RUN.md

Docs:
https://keycloak.gitbooks.io/documentation/content/server_admin/topics/identity-broker/social-login.html

On 16 February 2017 at 19:57, Bartosz Majsak <bartosz at redhat.com> wrote:

> redirect_uri is part of the OAuth spec, so it should.
>
> That?s totally correct. My bad, I must have been in a rabbit hole chasing
> bunch of other issues in my code and somehow assumed that was the root
> cause. In fact it works with and w/o it, as redirect uri is configured when
> you register a client in Openshift [1].
>
> But still, I cannot simply use OIDC as it adds openid to the scope and this
> results in Openshift OAuth server complaining about the request - "Invalid
> value: "openid": no scope handler found"
>
> My implementation is based on AbstractOAuth2IdentityProvider and in fact it
> only differs when it comes to extracting profile information (other changes
> done in the project I shared in the opening mail are not feasible to make
> it upstream).
>
> To elaborate a bit on the use-case: our DevTools project will need to have
> an access to user?s OSO resources such as projects and thus we need such
> integration. We can live with SPI extension, but if you feel like it would
> be beneficial to the project I?m more than happy to contribute this piece
> (and improved based upon feedback from the PR).
>
> Cheers,
> Bartosz.
>
> [1]
> https://docs.openshift.org/latest/architecture/additional_concepts/
> authentication.html#oauth-clients
> ?
>
> On Wed, Feb 15, 2017 at 3:30 PM, Bill Burke <bburke at redhat.com> wrote:
>
> > redirect_uri is part of the OAuth spec, so it should.  Without a
> > redirect URI, the IDP is supposed to abort authentication as this URI is
> > validated.  You don't want to deliver an access code to a rogue URL.
> >
> >
> > On 2/15/17 6:38 AM, Bartosz Majsak wrote:
> > > OpenShift should authenticate against Keycloak (or another IdP) at
> least
> > > for on-prem installations.
> > >
> > > This is intended primarily for OSO I believe.
> > >
> > > For OpenShift Online I see a use-case for this, but in that case can it
> > not
> > > just use the OIDC provider?
> > >
> > > One issue I can already point out is that when using OIDC provider
> > > authorization URL created by an AbstractOAuth2IdentityProvider will
> > result
> > > in bad request from OpenShift OAuth server, as it doesn?t accept
> > > redirect_uri as a valid request parameter. At least when tested against
> > > minishift.
> > > ?
> > >
> > > On Wed, Feb 15, 2017 at 12:29 PM, Stian Thorgersen <
> sthorger at redhat.com>
> > > wrote:
> > >
> > >> Not sure to be honest. Strictly speaking it should be the other way
> > >> around. OpenShift should authenticate against Keycloak (or another
> IdP)
> > at
> > >> least for on-prem installations. For OpenShift Online I see a use-case
> > for
> > >> this, but in that case can it not just use the OIDC provider?
> > >>
> > >> On 15 February 2017 at 02:46, Bartosz Majsak <bartosz at redhat.com>
> > wrote:
> > >>
> > >>> Hi,
> > >>>
> > >>> I've implemented Openshift Identity Provider for KeyCloak [1]. Would
> > you
> > >>> be
> > >>> interested in getting it upstream?
> > >>>
> > >>> Cheers,
> > >>> Bartosz.
> > >>>
> > >>> [1] https://github.com/bartoszmajsak/keycloak-
> > openshift-identity-provider
> > >>> _______________________________________________
> > >>> 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
> >
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From mposolda at redhat.com  Mon Feb 20 11:08:49 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 20 Feb 2017 17:08:49 +0100
Subject: [keycloak-dev] Improving testsuite performance
In-Reply-To: <CA+C8Pfy+exapA-_fu-KjGuJa+--Eox1zZ=ow2TTST6B0+Af6yA@mail.gmail.com>
References: <caa6c998-d04a-ef3a-7610-fb87baad7422@redhat.com>
	<CA+C8PfxK+qaowVE1YmpUHmx0B7LVWvA6nBWdMTjNfJeJN5DWiQ@mail.gmail.com>
	<4281d342-075d-5943-f4e4-d930b3373951@redhat.com>
	<CA+C8Pfy+exapA-_fu-KjGuJa+--Eox1zZ=ow2TTST6B0+Af6yA@mail.gmail.com>
Message-ID: <faecde04-a65d-74fe-46ee-7848bb3b3e1b@redhat.com>

Thing is that we likely can't run various tests in parallel as tests 
against Keycloak DB would clash (various tests are changing DB and 
various tests require different data preconfigured in DB etc). It's more 
about the ability to have quicker testsuite run and also about quicker 
run of single test when executed from IDE or maven. But maybe we can 
reuse something like this in our travis environment. Do you have any 
example when you have this "in action" ?

Marek

On 20/02/17 12:35, Bartosz Majsak wrote:
> Hi Marek,
>
> I meant running x browser tests in parallel with Drone. That can be 
> achieved with surefire/failsafe. Not sure how does phantomjs nor 
> htmlunit handles that, but I was successfully running drone tests 
> using chrome and firefox this way.
>
> Cheers,
> Bartosz.
>
> On Mon, Feb 20, 2017 at 12:19 PM, Marek Posolda <mposolda at redhat.com 
> <mailto:mposolda at redhat.com>> wrote:
>
>     Hi Bartosz,
>
>     we are using parallel running tests on Travis (our CI). That
>     allows test classes to be divided into groups and each group is
>     running concurrently with other groups. Example script is here:
>     https://github.com/keycloak/keycloak/blob/master/travis-run-tests.sh
>     <https://github.com/keycloak/keycloak/blob/master/travis-run-tests.sh>
>
>     Did you mean something like that?
>
>     Thanks,
>     Marek
>
>
>     On 18/02/17 17:31, Bartosz Majsak wrote:
>>     Hi Marek,
>>
>>     are you running drone tests in parallel? It could be possible to
>>     speed it up with just tweaking surfire. In my last project we
>>     were using 8-12 parallel drones and this gave us quite an advantage.
>>
>>     I would be happy to help.
>>
>>     Cheers,
>>     Bartosz.
>>
>>     On Fri, Feb 17, 2017 at 10:12 PM, Marek Posolda
>>     <mposolda at redhat.com <mailto:mposolda at redhat.com>> wrote:
>>
>>         ATM running tests in the new arquillian testsuite (
>>         testsuite/integration-arquillian ) is significantly slower
>>         then running
>>         tests in the old testsuite ( testsuite/integration ). It was
>>         quite
>>         visible in some tests, which were around 3 times slower after
>>         they were
>>         migrated from the old testsuite.
>>
>>         We found that there are 2 major bottlenecks causing it:
>>         - There is re-import of all the realms before each test
>>         method. In the
>>         old testsuite, it was just BeforeClass.
>>         - The new testsuite uses phantomjs WebDriver by default. The
>>         old one
>>         used htmlUnit. I've checked that phantomjs is around 15-times
>>         slower
>>         than htmlUnit. The main reason is that htmlUnit talks
>>         directly with the
>>         tested server, when phantomJS (similarly like all other real
>>         browsers)
>>         uses remote selenium server, which adds significant overhead. For
>>         example all the simple operations like "driver.getTitle()"
>>         needs to send
>>         HTTP request to the selenium server.
>>
>>         Hence I've looked at the possibility to switch to htmlUnit by
>>         default
>>         and sent PR for it:
>>         https://github.com/keycloak/keycloak/pull/3876
>>         <https://github.com/keycloak/keycloak/pull/3876> .
>>
>>         New testsuite runs on my laptop in 21 minutes with htmlUnit, when
>>         previously it was 36 minutes.
>>
>>         However there is the disadvantage, that htmlUnit has limited
>>         javascript
>>         support and is not the best for angular apps. It seems that admin
>>         console tests won't run with it. I also needed to do some
>>         refactoring of
>>         few existing tests to have them pass with htmlUnit (eg.
>>         AbstractDemoServletsAdapterTest to use assertEvents instead
>>         of admin
>>         console etc).
>>
>>         However this won't be an issue as browser implementation can be
>>         overriden with: -Dbrowser=phantomjs
>>
>>         So it's possible to run console tests with proper browsers.
>>
>>         Anyone seeing issues with switch to htmlUnit by default?
>>
>>         I hope that after fix the import + maybe few other things
>>         (eg. share
>>         adminClient per class instead of test method etc), we will be
>>         able to
>>         run whole testsuite in less than 15 minutes!
>>
>>         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
>>         <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>
>>
>
>


From Sebastian.Schuster at bosch-si.com  Tue Feb 21 04:10:43 2017
From: Sebastian.Schuster at bosch-si.com (Schuster Sebastian (INST/ESY1))
Date: Tue, 21 Feb 2017 09:10:43 +0000
Subject: [keycloak-dev] Improving testsuite performance
In-Reply-To: <4281d342-075d-5943-f4e4-d930b3373951@redhat.com>
References: <caa6c998-d04a-ef3a-7610-fb87baad7422@redhat.com>
	<CA+C8PfxK+qaowVE1YmpUHmx0B7LVWvA6nBWdMTjNfJeJN5DWiQ@mail.gmail.com>
	<4281d342-075d-5943-f4e4-d930b3373951@redhat.com>
Message-ID: <41120688F6FCE840B172FD409300D9E82838E9EB@BE6PW2EXD01.bosch-si.com>

Hi all,

coming from the Rails-world, there it is possible to annotate the tests differently depending on the type of web driver they need.
Maybe that's also possible or if not, it might be worthwile to add that capability to the test framework...

Best regards,
Sebastian

-----Urspr?ngliche Nachricht-----
Von: keycloak-dev-bounces at lists.jboss.org [mailto:keycloak-dev-bounces at lists.jboss.org] Im Auftrag von Marek Posolda
Gesendet: Montag, 20. Februar 2017 12:19
An: Bartosz Majsak <bartosz at redhat.com>
Cc: keycloak-dev at lists.jboss.org
Betreff: Re: [keycloak-dev] Improving testsuite performance

Hi Bartosz,

we are using parallel running tests on Travis (our CI). That allows test classes to be divided into groups and each group is running concurrently with other groups. Example script is here:
https://github.com/keycloak/keycloak/blob/master/travis-run-tests.sh

Did you mean something like that?

Thanks,
Marek

On 18/02/17 17:31, Bartosz Majsak wrote:
> Hi Marek,
>
> are you running drone tests in parallel? It could be possible to speed 
> it up with just tweaking surfire. In my last project we were using
> 8-12 parallel drones and this gave us quite an advantage.
>
> I would be happy to help.
>
> Cheers,
> Bartosz.
>
> On Fri, Feb 17, 2017 at 10:12 PM, Marek Posolda <mposolda at redhat.com 
> <mailto:mposolda at redhat.com>> wrote:
>
>     ATM running tests in the new arquillian testsuite (
>     testsuite/integration-arquillian ) is significantly slower then
>     running
>     tests in the old testsuite ( testsuite/integration ). It was quite
>     visible in some tests, which were around 3 times slower after they
>     were
>     migrated from the old testsuite.
>
>     We found that there are 2 major bottlenecks causing it:
>     - There is re-import of all the realms before each test method. In the
>     old testsuite, it was just BeforeClass.
>     - The new testsuite uses phantomjs WebDriver by default. The old one
>     used htmlUnit. I've checked that phantomjs is around 15-times slower
>     than htmlUnit. The main reason is that htmlUnit talks directly
>     with the
>     tested server, when phantomJS (similarly like all other real browsers)
>     uses remote selenium server, which adds significant overhead. For
>     example all the simple operations like "driver.getTitle()" needs
>     to send
>     HTTP request to the selenium server.
>
>     Hence I've looked at the possibility to switch to htmlUnit by default
>     and sent PR for it: https://github.com/keycloak/keycloak/pull/3876
>     <https://github.com/keycloak/keycloak/pull/3876> .
>
>     New testsuite runs on my laptop in 21 minutes with htmlUnit, when
>     previously it was 36 minutes.
>
>     However there is the disadvantage, that htmlUnit has limited
>     javascript
>     support and is not the best for angular apps. It seems that admin
>     console tests won't run with it. I also needed to do some
>     refactoring of
>     few existing tests to have them pass with htmlUnit (eg.
>     AbstractDemoServletsAdapterTest to use assertEvents instead of admin
>     console etc).
>
>     However this won't be an issue as browser implementation can be
>     overriden with: -Dbrowser=phantomjs
>
>     So it's possible to run console tests with proper browsers.
>
>     Anyone seeing issues with switch to htmlUnit by default?
>
>     I hope that after fix the import + maybe few other things (eg. share
>     adminClient per class instead of test method etc), we will be able to
>     run whole testsuite in less than 15 minutes!
>
>     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
>     <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 DLustig at carbonite.com  Wed Feb 22 10:24:41 2017
From: DLustig at carbonite.com (David Lustig)
Date: Wed, 22 Feb 2017 15:24:41 +0000
Subject: [keycloak-dev] Captcha on Login Page
Message-ID: <SN2PR0601MB09737CC97D856F9A2B000C01AA500@SN2PR0601MB0973.namprd06.prod.outlook.com>

Hello,

I have recently been tasked with enhancing our Keycloak 2.5.1 login page with ReCaptcha functionality.  We currently are planning to use the default login page, and were originally under the impression that fields could be added to it using a FormAction provider.  It appears that login page is not compatible with the FormAction provider, though.  Various comments, including those on https://issues.jboss.org/browse/KEYCLOAK-4379 , have noted that the Authentication SPI should be used instead.  The problem I am running into is that it appears the Authentication SPI is only for adding new pages to the login flow; it does not appear to support modifying the existing login page, unless I'm missing something.  Is there a way to modify the existing login page and logic such that no attempts will be made to log the user in unless he enters the correct captcha, similar to the way ReCaptcha is implemented in the registration flow?

Thank you for your help,

David Lustig

From mbaluch at redhat.com  Wed Feb 22 11:02:31 2017
From: mbaluch at redhat.com (Marek Baluch)
Date: Wed, 22 Feb 2017 17:02:31 +0100
Subject: [keycloak-dev] Mark True - QE reinforcement
Message-ID: <CAKZHv8Z-YYrYECSceQeLZssS4N8X_JAnJQdXgPDTi5=_hV6Lyg@mail.gmail.com>

Hello team,

please join me in welcoming Mark True in the QE team. Mark has vast
experience testing from various companies and he is located in Westford so
from now on we have a permanent beacon also in the US :-).

Mark - Welcome - I'm really looking forward to work with you.

Regards!
Marek.

From drieden at redhat.com  Wed Feb 22 12:02:00 2017
From: drieden at redhat.com (Deborah Rieden)
Date: Wed, 22 Feb 2017 12:02:00 -0500
Subject: [keycloak-dev] [rh-sso-pm] Mark True - QE reinforcement
In-Reply-To: <CAF1-sp6SAatHX=ruD5VZk_qWhpmw2yL3Kqf0Er4UgGN_cxtYTg@mail.gmail.com>
References: <CAKZHv8Z-YYrYECSceQeLZssS4N8X_JAnJQdXgPDTi5=_hV6Lyg@mail.gmail.com>
	<CAF1-sp6SAatHX=ruD5VZk_qWhpmw2yL3Kqf0Er4UgGN_cxtYTg@mail.gmail.com>
Message-ID: <CAPyQrkOiUzVRROcsXx9G466E8Bpx0TsJOf+GMHnQJFTbKPg2Dg@mail.gmail.com>

Welcome Mark, glad to have you on board!

I sit in Westford on the 3rd floor.
Where are you?  It would be good to meet you in person.

Debi

On Wed, Feb 22, 2017 at 11:17 AM, Andrig Miller <anmiller at redhat.com> wrote:

> Welcome aboard Mark!
>
> Andy
>
> On Wed, Feb 22, 2017 at 9:02 AM, Marek Baluch <mbaluch at redhat.com> wrote:
>
>> Hello team,
>>
>> please join me in welcoming Mark True in the QE team. Mark has vast
>> experience testing from various companies and he is located in Westford so
>> from now on we have a permanent beacon also in the US :-).
>>
>> Mark - Welcome - I'm really looking forward to work with you.
>>
>> Regards!
>> Marek.
>>
>
>
>
> --
> Andrig (Andy) T. Miller
> Global Platform Director, Middleware
> Red Hat, Inc.
>

From sthorger at redhat.com  Wed Feb 22 13:35:41 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 22 Feb 2017 19:35:41 +0100
Subject: [keycloak-dev] [rh-sso-pm] Mark True - QE reinforcement
In-Reply-To: <CAKZHv8Z-YYrYECSceQeLZssS4N8X_JAnJQdXgPDTi5=_hV6Lyg@mail.gmail.com>
References: <CAKZHv8Z-YYrYECSceQeLZssS4N8X_JAnJQdXgPDTi5=_hV6Lyg@mail.gmail.com>
Message-ID: <CAJgngAdhxoM8CSSSBZeQ8r=swmBKQ8P2ieg7RiRYL26Pm7M=eA@mail.gmail.com>

Welcome Mark :)

On 22 February 2017 at 17:02, Marek Baluch <mbaluch at redhat.com> wrote:

> Hello team,
>
> please join me in welcoming Mark True in the QE team. Mark has vast
> experience testing from various companies and he is located in Westford so
> from now on we have a permanent beacon also in the US :-).
>
> Mark - Welcome - I'm really looking forward to work with you.
>
> Regards!
> Marek.
>

From sthorger at redhat.com  Wed Feb 22 13:39:19 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 22 Feb 2017 19:39:19 +0100
Subject: [keycloak-dev] Captcha on Login Page
In-Reply-To: <SN2PR0601MB09737CC97D856F9A2B000C01AA500@SN2PR0601MB0973.namprd06.prod.outlook.com>
References: <SN2PR0601MB09737CC97D856F9A2B000C01AA500@SN2PR0601MB0973.namprd06.prod.outlook.com>
Message-ID: <CAJgngAd_oQy9v0JVh32OG2tQGU18Gsq5BBWr1DWPPUOWwWBF3w@mail.gmail.com>

You'll need to extend the user/password authenticator implementation to add
the recaptcha stuff and at the same time add it to the freemarker template.
That's it.

On 22 February 2017 at 16:24, David Lustig <DLustig at carbonite.com> wrote:

> Hello,
>
> I have recently been tasked with enhancing our Keycloak 2.5.1 login page
> with ReCaptcha functionality.  We currently are planning to use the default
> login page, and were originally under the impression that fields could be
> added to it using a FormAction provider.  It appears that login page is not
> compatible with the FormAction provider, though.  Various comments,
> including those on https://issues.jboss.org/browse/KEYCLOAK-4379 , have
> noted that the Authentication SPI should be used instead.  The problem I am
> running into is that it appears the Authentication SPI is only for adding
> new pages to the login flow; it does not appear to support modifying the
> existing login page, unless I'm missing something.  Is there a way to
> modify the existing login page and logic such that no attempts will be made
> to log the user in unless he enters the correct captcha, similar to the way
> ReCaptcha is implemented in the registration flow?
>
> Thank you for your help,
>
> David Lustig
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From DLustig at carbonite.com  Wed Feb 22 16:23:21 2017
From: DLustig at carbonite.com (David Lustig)
Date: Wed, 22 Feb 2017 21:23:21 +0000
Subject: [keycloak-dev] Captcha on Login Page
In-Reply-To: <CAJgngAd_oQy9v0JVh32OG2tQGU18Gsq5BBWr1DWPPUOWwWBF3w@mail.gmail.com>
References: <SN2PR0601MB09737CC97D856F9A2B000C01AA500@SN2PR0601MB0973.namprd06.prod.outlook.com>
	<CAJgngAd_oQy9v0JVh32OG2tQGU18Gsq5BBWr1DWPPUOWwWBF3w@mail.gmail.com>
Message-ID: <SN2PR0601MB09738721CAA6582351A5151FAA500@SN2PR0601MB0973.namprd06.prod.outlook.com>

That did it!  Extending the UsernamePasswordForm (and associated Factory), integrating the ReCaptcha code from the registration form action, deploying the jar just like any other custom authenticator, and updating login.ftl with the ReCaptcha div did the trick.

Thank you very much.

David Lustig

From: Stian Thorgersen [mailto:sthorger at redhat.com]
Sent: Wednesday, February 22, 2017 1:39 PM
To: David Lustig <DLustig at carbonite.com>
Cc: keycloak-dev at lists.jboss.org
Subject: Re: [keycloak-dev] Captcha on Login Page

You'll need to extend the user/password authenticator implementation to add the recaptcha stuff and at the same time add it to the freemarker template. That's it.

On 22 February 2017 at 16:24, David Lustig <DLustig at carbonite.com<mailto:DLustig at carbonite.com>> wrote:
Hello,

I have recently been tasked with enhancing our Keycloak 2.5.1 login page with ReCaptcha functionality.  We currently are planning to use the default login page, and were originally under the impression that fields could be added to it using a FormAction provider.  It appears that login page is not compatible with the FormAction provider, though.  Various comments, including those on https://issues.jboss.org/browse/KEYCLOAK-4379 , have noted that the Authentication SPI should be used instead.  The problem I am running into is that it appears the Authentication SPI is only for adding new pages to the login flow; it does not appear to support modifying the existing login page, unless I'm missing something.  Is there a way to modify the existing login page and logic such that no attempts will be made to log the user in unless he enters the correct captcha, similar to the way ReCaptcha is implemented in the registration flow?

Thank you for your help,

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

From sthorger at redhat.com  Wed Feb 22 23:36:09 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 23 Feb 2017 05:36:09 +0100
Subject: [keycloak-dev] Keycloak 2.5.4.Final Released
Message-ID: <CAJgngAe7M=4k5S1RBGV_=Szku6YHcc=Y63tq=QB45g1rS67nuA@mail.gmail.com>

Keycloak 2.5.4.Final is out. There's nothing much except a handful bug
fixes, but it's still worth upgrading.

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

   - A few bug fixes

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

Before you upgrade remember to backup your database and check the migration
guide
<http://www.keycloak.org/docs/2.5/server_admin_guide/topics/MigrationFromOlderVersions.html>
.

From liam.maruff at gmail.com  Thu Feb 23 01:44:01 2017
From: liam.maruff at gmail.com (Liam Maruff)
Date: Thu, 23 Feb 2017 16:44:01 +1000
Subject: [keycloak-dev] Compiling Keycloak - Could not find artifact
Message-ID: <CADh+9Zw+Q78p8woi4hqKD77yXTfo7TFmKoP991yK_zxPJN_o6w@mail.gmail.com>

Hey Everyone,

I'm trying to compile Keycloak from Source using:

[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:2.18.1:test (default-test)
on project keycloak-testsuite-jetty92: There are test failures.


But am receiving:

[INFO] Keycloak Jetty 9.2.x Integration TestSuite ......... FAILURE


I've also tried the following:

mvn clean install -Dmaven.test.skip=true -U -Pdistribution


Instead receive:

[ERROR] Failed to execute goal on project
integration-arquillian-tests-sssd: Could not resolve dependencies for
project
org.keycloak.testsuite:integration-arquillian-tests-sssd:jar:3.0.0.CR1-SNAPSHOT:
Could not find artifact
org.keycloak.testsuite:integration-arquillian-tests-base:jar:tests:3.0.0.CR1-SNAPSHOT
in jboss (http://repository.jboss.org/nexus/content/groups/public/) ->
[Help 1]


Could you please suggest what may be done to correct this problem so that I
can compile and subsequently run Keycloak? Thanks.

From liam.maruff at gmail.com  Thu Feb 23 01:46:09 2017
From: liam.maruff at gmail.com (Liam Maruff)
Date: Thu, 23 Feb 2017 16:46:09 +1000
Subject: [keycloak-dev] Compiling Keycloak - Could not find artifact
In-Reply-To: <CADh+9Zw+Q78p8woi4hqKD77yXTfo7TFmKoP991yK_zxPJN_o6w@mail.gmail.com>
References: <CADh+9Zw+Q78p8woi4hqKD77yXTfo7TFmKoP991yK_zxPJN_o6w@mail.gmail.com>
Message-ID: <CADh+9ZzaR6L9E7b-Pay-rWEG9cQMvVG4nc3Fb2NH2oeJ7nguXA@mail.gmail.com>

Excuse me, hit send too quickly. When I use:

mvn install

I receive:

...
[INFO] Keycloak Jetty 9.2.x Integration TestSuite ......... FAILURE
...
[ERROR] Failed to execute goal org.apache.maven.plugins:
maven-surefire-plugin:2.18.1:test (default-test) on project
keycloak-testsuite-jetty92: There are test failures.


Regards, LM.

On Thu, Feb 23, 2017 at 4:44 PM, Liam Maruff <liam.maruff at gmail.com> wrote:

> Hey Everyone,
>
> I'm trying to compile Keycloak from Source using:
>
> [ERROR] Failed to execute goal org.apache.maven.plugins:
> maven-surefire-plugin:2.18.1:test (default-test) on project
> keycloak-testsuite-jetty92: There are test failures.
>
>
> But am receiving:
>
> [INFO] Keycloak Jetty 9.2.x Integration TestSuite ......... FAILURE
>
>
> I've also tried the following:
>
> mvn clean install -Dmaven.test.skip=true -U -Pdistribution
>
>
> Instead receive:
>
> [ERROR] Failed to execute goal on project integration-arquillian-tests-sssd:
> Could not resolve dependencies for project org.keycloak.testsuite:
> integration-arquillian-tests-sssd:jar:3.0.0.CR1-SNAPSHOT: Could not find
> artifact org.keycloak.testsuite:integration-arquillian-tests-
> base:jar:tests:3.0.0.CR1-SNAPSHOT in jboss (http://repository.jboss.org/
> nexus/content/groups/public/) -> [Help 1]
>
>
> Could you please suggest what may be done to correct this problem so that
> I can compile and subsequently run Keycloak? Thanks.
>

From tair.sabirgaliev at gmail.com  Thu Feb 23 03:12:51 2017
From: tair.sabirgaliev at gmail.com (Tair Sabirgaliev)
Date: Thu, 23 Feb 2017 00:12:51 -0800
Subject: [keycloak-dev] Compiling Keycloak - Could not find artifact
In-Reply-To: <CADh+9ZzaR6L9E7b-Pay-rWEG9cQMvVG4nc3Fb2NH2oeJ7nguXA@mail.gmail.com>
References: <CADh+9Zw+Q78p8woi4hqKD77yXTfo7TFmKoP991yK_zxPJN_o6w@mail.gmail.com>
	<CADh+9ZzaR6L9E7b-Pay-rWEG9cQMvVG4nc3Fb2NH2oeJ7nguXA@mail.gmail.com>
Message-ID: <CAGU3vRdbZd-vidXCdQj_LPHrHJaNMwGwe2SgtqztAXijz8zYgA@mail.gmail.com>

Try this:

mvn clean install -B -DskipTests -Pdistribution


On 23 February 2017 at 12:46:32, Liam Maruff (liam.maruff at gmail.com) wrote:

Excuse me, hit send too quickly. When I use:

mvn install

I receive:

...
[INFO] Keycloak Jetty 9.2.x Integration TestSuite ......... FAILURE
...
[ERROR] Failed to execute goal org.apache.maven.plugins:
maven-surefire-plugin:2.18.1:test (default-test) on project
keycloak-testsuite-jetty92: There are test failures.


Regards, LM.

On Thu, Feb 23, 2017 at 4:44 PM, Liam Maruff <liam.maruff at gmail.com> wrote:

> Hey Everyone,
>
> I'm trying to compile Keycloak from Source using:
>
> [ERROR] Failed to execute goal org.apache.maven.plugins:
> maven-surefire-plugin:2.18.1:test (default-test) on project
> keycloak-testsuite-jetty92: There are test failures.
>
>
> But am receiving:
>
> [INFO] Keycloak Jetty 9.2.x Integration TestSuite ......... FAILURE
>
>
> I've also tried the following:
>
> mvn clean install -Dmaven.test.skip=true -U -Pdistribution
>
>
> Instead receive:
>
> [ERROR] Failed to execute goal on project
integration-arquillian-tests-sssd:
> Could not resolve dependencies for project org.keycloak.testsuite:
> integration-arquillian-tests-sssd:jar:3.0.0.CR1-SNAPSHOT: Could not find
> artifact org.keycloak.testsuite:integration-arquillian-tests-
> base:jar:tests:3.0.0.CR1-SNAPSHOT in jboss (http://repository.jboss.org/
> nexus/content/groups/public/) -> [Help 1]
>
>
> Could you please suggest what may be done to correct this problem so that
> I can compile and subsequently run Keycloak? Thanks.
>
_______________________________________________
keycloak-dev mailing list
keycloak-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev

From bdawidow at redhat.com  Thu Feb 23 04:03:15 2017
From: bdawidow at redhat.com (Boleslaw Dawidowicz)
Date: Thu, 23 Feb 2017 10:03:15 +0100
Subject: [keycloak-dev] [rh-sso-pm] Mark True - QE reinforcement
In-Reply-To: <CAKZHv8Z-YYrYECSceQeLZssS4N8X_JAnJQdXgPDTi5=_hV6Lyg@mail.gmail.com>
References: <CAKZHv8Z-YYrYECSceQeLZssS4N8X_JAnJQdXgPDTi5=_hV6Lyg@mail.gmail.com>
Message-ID: <CABbwURGnbW=7qSvtuPSwD6GVsmtgQyqEDxZjHpsBT8sUy3DESQ@mail.gmail.com>

Welcome! Great to have you in our team!

On Wed, Feb 22, 2017 at 5:02 PM, Marek Baluch <mbaluch at redhat.com> wrote:
> Hello team,
>
> please join me in welcoming Mark True in the QE team. Mark has vast
> experience testing from various companies and he is located in Westford so
> from now on we have a permanent beacon also in the US :-).
>
> Mark - Welcome - I'm really looking forward to work with you.
>
> Regards!
> Marek.



-- 
Boles?aw Dawidowicz


From bruno at abstractj.org  Thu Feb 23 05:02:01 2017
From: bruno at abstractj.org (Bruno Oliveira)
Date: Thu, 23 Feb 2017 10:02:01 +0000
Subject: [keycloak-dev] [rh-sso-pm] Mark True - QE reinforcement
In-Reply-To: <CABbwURGnbW=7qSvtuPSwD6GVsmtgQyqEDxZjHpsBT8sUy3DESQ@mail.gmail.com>
References: <CAKZHv8Z-YYrYECSceQeLZssS4N8X_JAnJQdXgPDTi5=_hV6Lyg@mail.gmail.com>
	<CABbwURGnbW=7qSvtuPSwD6GVsmtgQyqEDxZjHpsBT8sUy3DESQ@mail.gmail.com>
Message-ID: <CAM5SUC4Xk24RwXLRtUu8Tc-TSxuduNq25Nf8Sqwc=Sca8D8Z=w@mail.gmail.com>

Welcome aboard Mark!

On Thu, Feb 23, 2017 at 6:03 AM Boleslaw Dawidowicz <bdawidow at redhat.com>
wrote:

> Welcome! Great to have you in our team!
>
> On Wed, Feb 22, 2017 at 5:02 PM, Marek Baluch <mbaluch at redhat.com> wrote:
> > Hello team,
> >
> > please join me in welcoming Mark True in the QE team. Mark has vast
> > experience testing from various companies and he is located in Westford
> so
> > from now on we have a permanent beacon also in the US :-).
> >
> > Mark - Welcome - I'm really looking forward to work with you.
> >
> > Regards!
> > Marek.
>
>
>
> --
> Boles?aw Dawidowicz
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From bburke at redhat.com  Thu Feb 23 12:49:15 2017
From: bburke at redhat.com (Bill Burke)
Date: Thu, 23 Feb 2017 12:49:15 -0500
Subject: [keycloak-dev] Who removed "default identity broker" config switch?
Message-ID: <ed077c40-26ac-68b8-f2b3-afed5fbfe692@redhat.com>

You used to be able to configure an identity broker as a default and 
Keycloak would always delegate to this broker without showing the login 
screen.  Who removed this and why?  Was it a mistake?


Thanks,

Bill


From mposolda at redhat.com  Thu Feb 23 15:58:05 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 23 Feb 2017 21:58:05 +0100
Subject: [keycloak-dev] Who removed "default identity broker" config
 switch?
In-Reply-To: <ed077c40-26ac-68b8-f2b3-afed5fbfe692@redhat.com>
References: <ed077c40-26ac-68b8-f2b3-afed5fbfe692@redhat.com>
Message-ID: <c800a957-a312-a494-9a2e-4bae847a94d9@redhat.com>

This was replaced by an IdentityProviderAuthenticator, which is in 
default "browser" flow.

AFAIR this was done because previously redirection to identity provider 
happened earlier than authentication with SSO cookie.

Marek

On 23/02/17 18:49, Bill Burke wrote:
> You used to be able to configure an identity broker as a default and
> Keycloak would always delegate to this broker without showing the login
> screen.  Who removed this and why?  Was it a mistake?
>
>
> Thanks,
>
> Bill
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



From mposolda at redhat.com  Thu Feb 23 15:59:03 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 23 Feb 2017 21:59:03 +0100
Subject: [keycloak-dev] Who removed "default identity broker" config
 switch?
In-Reply-To: <c800a957-a312-a494-9a2e-4bae847a94d9@redhat.com>
References: <ed077c40-26ac-68b8-f2b3-afed5fbfe692@redhat.com>
	<c800a957-a312-a494-9a2e-4bae847a94d9@redhat.com>
Message-ID: <403848d2-08ba-df3a-ed5c-96f6430a19e5@redhat.com>

JIRA with some details: https://issues.jboss.org/browse/KEYCLOAK-3342


On 23/02/17 21:58, Marek Posolda wrote:
> This was replaced by an IdentityProviderAuthenticator, which is in 
> default "browser" flow.
>
> AFAIR this was done because previously redirection to identity 
> provider happened earlier than authentication with SSO cookie.
>
> Marek
>
> On 23/02/17 18:49, Bill Burke wrote:
>> You used to be able to configure an identity broker as a default and
>> Keycloak would always delegate to this broker without showing the login
>> screen.  Who removed this and why?  Was it a mistake?
>>
>>
>> Thanks,
>>
>> Bill
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>


From bburke at redhat.com  Thu Feb 23 17:24:36 2017
From: bburke at redhat.com (Bill Burke)
Date: Thu, 23 Feb 2017 17:24:36 -0500
Subject: [keycloak-dev] client requested account linking
Message-ID: <21c78246-d9e8-c808-766b-a88c595a5210@redhat.com>

A customer has asked us to implement a feature in which there is a 
browser endpoint on keycloak.  This URL can be told to link to a 
specific identity broker provider (Google, Facebook, etc.) and then the 
browser would be redirected back to the client. Pretty much what exists 
in the Account Service console, but without having to look at the 
Account Service.  The reason for this is that they are doing integration 
with a specific social provider and don't want to have to go through the 
Account Service pages. Seems pretty reasonable and valid use case...  
I'm worried about a couple of things:

* The design of it

* The security implications.

The implementation would be simple enough, it would just extract code 
from the accoutn service.  The endpoint would take a "providerId" 
paramter that would be the idp linking to, a "clientId" for the client 
requesting the link, and a "redirect_uri" to redirect back to after the 
link is successful. Obviously the redirect_uri would be validated 
against the clientId.

Now comes the interesting part, the security implications. Account 
linking in the Account Service is fine and dandy and doesn't have any 
security holes because we guarantee that the Account Service initiated 
the linking via a CSRF check.  For this new Client-Requested-Linking 
feature, if we do nothing, and just model it as above, we cannot 
guarantee that the client initiated the linking request.  What are the 
implications of this?  This feature would be vulnerable to CSRF.  A 
rogue website could initiate account linking to a specific configured 
provider.  Is this bad?  I don't know.  We can guarantee that the 
redirect uri is valid.  The browser would never get back to the rogue 
website. So what can we do to improve this?

* We could do nothing and hope its ok that anybody can initiate a link.

* We could add a consent screen like this: "Application 'clientId' is 
requesting that you link your user account to 'providerId'.  Do you 
agree to this?  You will be redirected to this provider if you click 
ok.".  This of course relies on the user to actually read the page.  Is 
this good enough?

* My last thought would be OIDC specific.  We could use the POST binding 
trick that SAML does to do a browser redirect via a POST call.  THe POST 
would contain the access token the client has.  We match this token up 
against the browser cookie to make sure its the same session.  We also 
make sure that the access token has permission to request a link.  There 
are 2 downsides to this approach a) This requires some code on the 
client side to obtain the access token and then to package it up into an 
HTML document so the POST binding trick can be done.  b) This will only 
work for OIDC clients.  SAML clients will be left in the dust, although 
I guess we could allow SAML to push a signed assertion back.


Thoughts?



From srossillo at smartling.com  Thu Feb 23 18:42:32 2017
From: srossillo at smartling.com (Scott Rossillo)
Date: Thu, 23 Feb 2017 18:42:32 -0500
Subject: [keycloak-dev] client requested account linking
In-Reply-To: <21c78246-d9e8-c808-766b-a88c595a5210@redhat.com>
References: <21c78246-d9e8-c808-766b-a88c595a5210@redhat.com>
Message-ID: <83938437-3484-4FD1-8139-3663B9A2E8C4@smartling.com>

We implemented this for certain requests. I don?t see security issue as long as:

1. HTTPS is required
2. Keycloak validates the redirect URL is valid before redirecting to the IDP.

I can give more details if interested.

~ Scott

Scott Rossillo
Smartling | Senior Software Engineer
srossillo at smartling.com

> On Feb 23, 2017, at 5:24 PM, Bill Burke <bburke at redhat.com> wrote:
> 
> A customer has asked us to implement a feature in which there is a 
> browser endpoint on keycloak.  This URL can be told to link to a 
> specific identity broker provider (Google, Facebook, etc.) and then the 
> browser would be redirected back to the client. Pretty much what exists 
> in the Account Service console, but without having to look at the 
> Account Service.  The reason for this is that they are doing integration 
> with a specific social provider and don't want to have to go through the 
> Account Service pages. Seems pretty reasonable and valid use case...  
> I'm worried about a couple of things:
> 
> * The design of it
> 
> * The security implications.
> 
> The implementation would be simple enough, it would just extract code 
> from the accoutn service.  The endpoint would take a "providerId" 
> paramter that would be the idp linking to, a "clientId" for the client 
> requesting the link, and a "redirect_uri" to redirect back to after the 
> link is successful. Obviously the redirect_uri would be validated 
> against the clientId.
> 
> Now comes the interesting part, the security implications. Account 
> linking in the Account Service is fine and dandy and doesn't have any 
> security holes because we guarantee that the Account Service initiated 
> the linking via a CSRF check.  For this new Client-Requested-Linking 
> feature, if we do nothing, and just model it as above, we cannot 
> guarantee that the client initiated the linking request.  What are the 
> implications of this?  This feature would be vulnerable to CSRF.  A 
> rogue website could initiate account linking to a specific configured 
> provider.  Is this bad?  I don't know.  We can guarantee that the 
> redirect uri is valid.  The browser would never get back to the rogue 
> website. So what can we do to improve this?
> 
> * We could do nothing and hope its ok that anybody can initiate a link.
> 
> * We could add a consent screen like this: "Application 'clientId' is 
> requesting that you link your user account to 'providerId'.  Do you 
> agree to this?  You will be redirected to this provider if you click 
> ok.".  This of course relies on the user to actually read the page.  Is 
> this good enough?
> 
> * My last thought would be OIDC specific.  We could use the POST binding 
> trick that SAML does to do a browser redirect via a POST call.  THe POST 
> would contain the access token the client has.  We match this token up 
> against the browser cookie to make sure its the same session.  We also 
> make sure that the access token has permission to request a link.  There 
> are 2 downsides to this approach a) This requires some code on the 
> client side to obtain the access token and then to package it up into an 
> HTML document so the POST binding trick can be done.  b) This will only 
> work for OIDC clients.  SAML clients will be left in the dust, although 
> I guess we could allow SAML to push a signed assertion back.
> 
> 
> Thoughts?
> 
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From mposolda at redhat.com  Fri Feb 24 03:21:57 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 24 Feb 2017 09:21:57 +0100
Subject: [keycloak-dev] client requested account linking
In-Reply-To: <21c78246-d9e8-c808-766b-a88c595a5210@redhat.com>
References: <21c78246-d9e8-c808-766b-a88c595a5210@redhat.com>
Message-ID: <4a2f4af6-8329-fdae-89df-b22ba93c00cc@redhat.com>

Don't we have a plan to rewrite AccountService to use Angular+REST? If 
yes, then we are fine though. We will have REST endpoint for link 
broker, which can be invoked with the bearer token as long as the token 
has "manage-account" scope. We don't need to care about CSRF then.

I can see the only reason to keep support browser+cookie based flows - 
the case when client application doesn't have Keycloak token. But from 
what you mentioned in the last paragraph, it looks that their client has 
our access token?

Marek


On 23/02/17 23:24, Bill Burke wrote:
> A customer has asked us to implement a feature in which there is a
> browser endpoint on keycloak.  This URL can be told to link to a
> specific identity broker provider (Google, Facebook, etc.) and then the
> browser would be redirected back to the client. Pretty much what exists
> in the Account Service console, but without having to look at the
> Account Service.  The reason for this is that they are doing integration
> with a specific social provider and don't want to have to go through the
> Account Service pages. Seems pretty reasonable and valid use case...
> I'm worried about a couple of things:
>
> * The design of it
>
> * The security implications.
>
> The implementation would be simple enough, it would just extract code
> from the accoutn service.  The endpoint would take a "providerId"
> paramter that would be the idp linking to, a "clientId" for the client
> requesting the link, and a "redirect_uri" to redirect back to after the
> link is successful. Obviously the redirect_uri would be validated
> against the clientId.
>
> Now comes the interesting part, the security implications. Account
> linking in the Account Service is fine and dandy and doesn't have any
> security holes because we guarantee that the Account Service initiated
> the linking via a CSRF check.  For this new Client-Requested-Linking
> feature, if we do nothing, and just model it as above, we cannot
> guarantee that the client initiated the linking request.  What are the
> implications of this?  This feature would be vulnerable to CSRF.  A
> rogue website could initiate account linking to a specific configured
> provider.  Is this bad?  I don't know.  We can guarantee that the
> redirect uri is valid.  The browser would never get back to the rogue
> website. So what can we do to improve this?
>
> * We could do nothing and hope its ok that anybody can initiate a link.
>
> * We could add a consent screen like this: "Application 'clientId' is
> requesting that you link your user account to 'providerId'.  Do you
> agree to this?  You will be redirected to this provider if you click
> ok.".  This of course relies on the user to actually read the page.  Is
> this good enough?
>
> * My last thought would be OIDC specific.  We could use the POST binding
> trick that SAML does to do a browser redirect via a POST call.  THe POST
> would contain the access token the client has.  We match this token up
> against the browser cookie to make sure its the same session.  We also
> make sure that the access token has permission to request a link.  There
> are 2 downsides to this approach a) This requires some code on the
> client side to obtain the access token and then to package it up into an
> HTML document so the POST binding trick can be done.  b) This will only
> work for OIDC clients.  SAML clients will be left in the dust, although
> I guess we could allow SAML to push a signed assertion back.
>
>
> Thoughts?
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



From sthorger at redhat.com  Fri Feb 24 03:59:10 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 24 Feb 2017 09:59:10 +0100
Subject: [keycloak-dev] Who removed "default identity broker" config
	switch?
In-Reply-To: <ed077c40-26ac-68b8-f2b3-afed5fbfe692@redhat.com>
References: <ed077c40-26ac-68b8-f2b3-afed5fbfe692@redhat.com>
Message-ID: <CAJgngAfW1e-n5GrcRAm1w5us+DP=PyJ4d92UUWc9gTpS2c=Vhg@mail.gmail.com>

Did you not read the migration guide ;)

Fixes the issue https://issues.jboss.org/browse/KEYCLOAK-3342, but also
makes it possible to customize this behavior with a custom authentication
flow. For example if someone wants to direct to different IdPs based on
some other condition (client_id, redirect_uri, other query parameter,
etc.). It's just a better place for it now that we have the authentication
flwos.

On 23 February 2017 at 18:49, Bill Burke <bburke at redhat.com> wrote:

> You used to be able to configure an identity broker as a default and
> Keycloak would always delegate to this broker without showing the login
> screen.  Who removed this and why?  Was it a mistake?
>
>
> Thanks,
>
> Bill
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From mark.pardijs at topicus.nl  Fri Feb 24 07:14:10 2017
From: mark.pardijs at topicus.nl (Mark Pardijs)
Date: Fri, 24 Feb 2017 12:14:10 +0000
Subject: [keycloak-dev] client requested account linking
In-Reply-To: <4a2f4af6-8329-fdae-89df-b22ba93c00cc@redhat.com>
References: <21c78246-d9e8-c808-766b-a88c595a5210@redhat.com>
	<4a2f4af6-8329-fdae-89df-b22ba93c00cc@redhat.com>
Message-ID: <72A8E55F-5CFE-4876-AA8F-A82BD9F02A5B@topicus.nl>

We are currently implementing a similar feature, slightly different but maybe it helps:

Users are logging in via SAML IdP initiated SSO request, and if their realm has configured other IdPs, we are showing a page where they can log in to the other IdPs so in the end the Keycloak account is linked to the two external IdPs. 

We?ve managed to do this with custom first/post broker login authentication flows, with a custom authenticator which shows a .ftl with the buttons you would normally see on the login screen if you have external IdPs configured. 

> Op 24 feb. 2017, om 09:21 heeft Marek Posolda <mposolda at redhat.com> het volgende geschreven:
> 
> Don't we have a plan to rewrite AccountService to use Angular+REST? If 
> yes, then we are fine though. We will have REST endpoint for link 
> broker, which can be invoked with the bearer token as long as the token 
> has "manage-account" scope. We don't need to care about CSRF then.
> 
> I can see the only reason to keep support browser+cookie based flows - 
> the case when client application doesn't have Keycloak token. But from 
> what you mentioned in the last paragraph, it looks that their client has 
> our access token?
> 
> Marek
> 
> 
> On 23/02/17 23:24, Bill Burke wrote:
>> A customer has asked us to implement a feature in which there is a
>> browser endpoint on keycloak.  This URL can be told to link to a
>> specific identity broker provider (Google, Facebook, etc.) and then the
>> browser would be redirected back to the client. Pretty much what exists
>> in the Account Service console, but without having to look at the
>> Account Service.  The reason for this is that they are doing integration
>> with a specific social provider and don't want to have to go through the
>> Account Service pages. Seems pretty reasonable and valid use case...
>> I'm worried about a couple of things:
>> 
>> * The design of it
>> 
>> * The security implications.
>> 
>> The implementation would be simple enough, it would just extract code
>> from the accoutn service.  The endpoint would take a "providerId"
>> paramter that would be the idp linking to, a "clientId" for the client
>> requesting the link, and a "redirect_uri" to redirect back to after the
>> link is successful. Obviously the redirect_uri would be validated
>> against the clientId.
>> 
>> Now comes the interesting part, the security implications. Account
>> linking in the Account Service is fine and dandy and doesn't have any
>> security holes because we guarantee that the Account Service initiated
>> the linking via a CSRF check.  For this new Client-Requested-Linking
>> feature, if we do nothing, and just model it as above, we cannot
>> guarantee that the client initiated the linking request.  What are the
>> implications of this?  This feature would be vulnerable to CSRF.  A
>> rogue website could initiate account linking to a specific configured
>> provider.  Is this bad?  I don't know.  We can guarantee that the
>> redirect uri is valid.  The browser would never get back to the rogue
>> website. So what can we do to improve this?
>> 
>> * We could do nothing and hope its ok that anybody can initiate a link.
>> 
>> * We could add a consent screen like this: "Application 'clientId' is
>> requesting that you link your user account to 'providerId'.  Do you
>> agree to this?  You will be redirected to this provider if you click
>> ok.".  This of course relies on the user to actually read the page.  Is
>> this good enough?
>> 
>> * My last thought would be OIDC specific.  We could use the POST binding
>> trick that SAML does to do a browser redirect via a POST call.  THe POST
>> would contain the access token the client has.  We match this token up
>> against the browser cookie to make sure its the same session.  We also
>> make sure that the access token has permission to request a link.  There
>> are 2 downsides to this approach a) This requires some code on the
>> client side to obtain the access token and then to package it up into an
>> HTML document so the POST binding trick can be done.  b) This will only
>> work for OIDC clients.  SAML clients will be left in the dust, although
>> I guess we could allow SAML to push a signed assertion back.
>> 
>> 
>> Thoughts?
>> 
>> 
>> _______________________________________________
>> 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 dps.mobile.gpe at gmail.com  Fri Feb 24 07:18:09 2017
From: dps.mobile.gpe at gmail.com (DPS Mobile GPE)
Date: Fri, 24 Feb 2017 12:18:09 +0000
Subject: [keycloak-dev] Keycloak - Ionic 2 & Cordova - Persist login
	information
Message-ID: <CAEmD7NFD2BiJxuZjqpSG0JCedcgw=ERTeLOPXiX2tmzsH_w1ig@mail.gmail.com>

I'm building app with Ionic 2 & Cordova and using Keycloak for login/signup.

My problem is when exit the application without logging out, and open the
application again, the keycloak sends me to the login page again.

i'll trying add "offline_access" to scope options but get the error
'Access-Control-Allow-Origin'

XMLHttpRequest cannot load
https://my-keycloak-server/auth/realms/app/protocol/openid-connect/token.
No 'Access-Control-Allow-Origin' header is present on the requested
resource. Origin 'http://localhost:8100' is therefore not allowed access.
The response had HTTP status code 400.

My implementation is based on
https://github.com/keycloak/keycloak/tree/master/examples/demo-template/angular2-product-app


I'm doing something wrong? Another suggestion for this implementation?

From bburke at redhat.com  Fri Feb 24 09:10:34 2017
From: bburke at redhat.com (Bill Burke)
Date: Fri, 24 Feb 2017 09:10:34 -0500
Subject: [keycloak-dev] client requested account linking
In-Reply-To: <4a2f4af6-8329-fdae-89df-b22ba93c00cc@redhat.com>
References: <21c78246-d9e8-c808-766b-a88c595a5210@redhat.com>
	<4a2f4af6-8329-fdae-89df-b22ba93c00cc@redhat.com>
Message-ID: <0dff4598-db39-0661-0622-ce970ea5b7c1@redhat.com>

Account linking *MUST* be browser based as you need to delegate 
authentication to the IDP you are brokering with.


On 2/24/17 3:21 AM, Marek Posolda wrote:
> Don't we have a plan to rewrite AccountService to use Angular+REST? If 
> yes, then we are fine though. We will have REST endpoint for link 
> broker, which can be invoked with the bearer token as long as the 
> token has "manage-account" scope. We don't need to care about CSRF then.
>
> I can see the only reason to keep support browser+cookie based flows - 
> the case when client application doesn't have Keycloak token. But from 
> what you mentioned in the last paragraph, it looks that their client 
> has our access token?
>
> Marek
>
>
> On 23/02/17 23:24, Bill Burke wrote:
>> A customer has asked us to implement a feature in which there is a
>> browser endpoint on keycloak.  This URL can be told to link to a
>> specific identity broker provider (Google, Facebook, etc.) and then the
>> browser would be redirected back to the client. Pretty much what exists
>> in the Account Service console, but without having to look at the
>> Account Service.  The reason for this is that they are doing integration
>> with a specific social provider and don't want to have to go through the
>> Account Service pages. Seems pretty reasonable and valid use case...
>> I'm worried about a couple of things:
>>
>> * The design of it
>>
>> * The security implications.
>>
>> The implementation would be simple enough, it would just extract code
>> from the accoutn service.  The endpoint would take a "providerId"
>> paramter that would be the idp linking to, a "clientId" for the client
>> requesting the link, and a "redirect_uri" to redirect back to after the
>> link is successful. Obviously the redirect_uri would be validated
>> against the clientId.
>>
>> Now comes the interesting part, the security implications. Account
>> linking in the Account Service is fine and dandy and doesn't have any
>> security holes because we guarantee that the Account Service initiated
>> the linking via a CSRF check.  For this new Client-Requested-Linking
>> feature, if we do nothing, and just model it as above, we cannot
>> guarantee that the client initiated the linking request.  What are the
>> implications of this?  This feature would be vulnerable to CSRF.  A
>> rogue website could initiate account linking to a specific configured
>> provider.  Is this bad?  I don't know.  We can guarantee that the
>> redirect uri is valid.  The browser would never get back to the rogue
>> website. So what can we do to improve this?
>>
>> * We could do nothing and hope its ok that anybody can initiate a link.
>>
>> * We could add a consent screen like this: "Application 'clientId' is
>> requesting that you link your user account to 'providerId'.  Do you
>> agree to this?  You will be redirected to this provider if you click
>> ok.".  This of course relies on the user to actually read the page.  Is
>> this good enough?
>>
>> * My last thought would be OIDC specific.  We could use the POST binding
>> trick that SAML does to do a browser redirect via a POST call. THe POST
>> would contain the access token the client has.  We match this token up
>> against the browser cookie to make sure its the same session. We also
>> make sure that the access token has permission to request a link.  There
>> are 2 downsides to this approach a) This requires some code on the
>> client side to obtain the access token and then to package it up into an
>> HTML document so the POST binding trick can be done.  b) This will only
>> work for OIDC clients.  SAML clients will be left in the dust, although
>> I guess we could allow SAML to push a signed assertion back.
>>
>>
>> Thoughts?
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>


From bburke at redhat.com  Fri Feb 24 20:46:54 2017
From: bburke at redhat.com (Bill Burke)
Date: Fri, 24 Feb 2017 20:46:54 -0500
Subject: [keycloak-dev] client requested account linking
In-Reply-To: <0dff4598-db39-0661-0622-ce970ea5b7c1@redhat.com>
References: <21c78246-d9e8-c808-766b-a88c595a5210@redhat.com>
	<4a2f4af6-8329-fdae-89df-b22ba93c00cc@redhat.com>
	<0dff4598-db39-0661-0622-ce970ea5b7c1@redhat.com>
Message-ID: <33b3f8b2-7ab2-e99e-7992-6e79f11ba501@redhat.com>

Ok, option #3 where I would pass an access token to initiate the link 
won't work as the access token could be leaked by a CSRF attack on the 
client.  My new solution is to do a custom protocol.  The goal of this 
protocol is for the server to verify that the client initiated the 
account link and not some rogue site.

1. Client does a background bearer-token authenticated to the Keycloak 
operation /initiate-link using the access token it got from login.

2. /initiate-link gets the ClientSessionModel associated with the 
bearer-token. It generates a server-nonce and stores it within the 
ClientSessionModel.

3. keycloak /initiate-link returns a response that contains the server-nonce

4. Client generates its own client-nonce.  This client-nonce is stored 
in its HttpSession.

5. Client generates a nonce-hash of server-nonce + client-nonce + 
provider-id.

6. Client redirects the browser to Keycloak /link operation passing the 
client-nonce, nonce-hash, provider-id, client-id, and redirect-uri as 
query parameters.

7. Keycloak /link operation validates that the browser is logged in.  If 
the user is not logged, an error page is shown.  We DO NOT redirect back 
to the client when there is an error as this is an attack vector.

8. Keycloak verifies clientid, redirect uri, and provider id.

9. Keycloak loops through the browser's UserSessionModel looking for 
ClientSessionModels that match the clientId.  Checks to see if this 
ClientSession has a server-nonce within it.  If so, it validates the 
hash.  We DO NOT redirect back to the client when there is an error as 
this is an attack vector.  The server-nonce client session attribute is 
cleared so that it can only be used once.

10. Keycloak initiates the social provider login

11. Keycloak redirects back to the client using the redirect_uri

What isn't protected here is the client.  If the client is a traditional 
web app, the client is responsible for protecting itself from CSRF.  The 
Account Service does this with a cookie nonce plus the nonce in the 
rendered page links, and it also rejects any CORS requests.  The client 
app will have to do this too.  I don't think Javascript apps are 
affected unless there is a URL you can redirect to that triggers this flow.

Again, I'm not even sure we have to do this sort of thing.  All a CSRF 
attack could do is request that the user link their Keycloak account.  
The attacker can't get any information about the user.



On 2/24/17 9:10 AM, Bill Burke wrote:
> Account linking *MUST* be browser based as you need to delegate
> authentication to the IDP you are brokering with.
>
>
> On 2/24/17 3:21 AM, Marek Posolda wrote:
>> Don't we have a plan to rewrite AccountService to use Angular+REST? If
>> yes, then we are fine though. We will have REST endpoint for link
>> broker, which can be invoked with the bearer token as long as the
>> token has "manage-account" scope. We don't need to care about CSRF then.
>>
>> I can see the only reason to keep support browser+cookie based flows -
>> the case when client application doesn't have Keycloak token. But from
>> what you mentioned in the last paragraph, it looks that their client
>> has our access token?
>>
>> Marek
>>
>>
>> On 23/02/17 23:24, Bill Burke wrote:
>>> A customer has asked us to implement a feature in which there is a
>>> browser endpoint on keycloak.  This URL can be told to link to a
>>> specific identity broker provider (Google, Facebook, etc.) and then the
>>> browser would be redirected back to the client. Pretty much what exists
>>> in the Account Service console, but without having to look at the
>>> Account Service.  The reason for this is that they are doing integration
>>> with a specific social provider and don't want to have to go through the
>>> Account Service pages. Seems pretty reasonable and valid use case...
>>> I'm worried about a couple of things:
>>>
>>> * The design of it
>>>
>>> * The security implications.
>>>
>>> The implementation would be simple enough, it would just extract code
>>> from the accoutn service.  The endpoint would take a "providerId"
>>> paramter that would be the idp linking to, a "clientId" for the client
>>> requesting the link, and a "redirect_uri" to redirect back to after the
>>> link is successful. Obviously the redirect_uri would be validated
>>> against the clientId.
>>>
>>> Now comes the interesting part, the security implications. Account
>>> linking in the Account Service is fine and dandy and doesn't have any
>>> security holes because we guarantee that the Account Service initiated
>>> the linking via a CSRF check.  For this new Client-Requested-Linking
>>> feature, if we do nothing, and just model it as above, we cannot
>>> guarantee that the client initiated the linking request.  What are the
>>> implications of this?  This feature would be vulnerable to CSRF.  A
>>> rogue website could initiate account linking to a specific configured
>>> provider.  Is this bad?  I don't know.  We can guarantee that the
>>> redirect uri is valid.  The browser would never get back to the rogue
>>> website. So what can we do to improve this?
>>>
>>> * We could do nothing and hope its ok that anybody can initiate a link.
>>>
>>> * We could add a consent screen like this: "Application 'clientId' is
>>> requesting that you link your user account to 'providerId'.  Do you
>>> agree to this?  You will be redirected to this provider if you click
>>> ok.".  This of course relies on the user to actually read the page.  Is
>>> this good enough?
>>>
>>> * My last thought would be OIDC specific.  We could use the POST binding
>>> trick that SAML does to do a browser redirect via a POST call. THe POST
>>> would contain the access token the client has.  We match this token up
>>> against the browser cookie to make sure its the same session. We also
>>> make sure that the access token has permission to request a link.  There
>>> are 2 downsides to this approach a) This requires some code on the
>>> client side to obtain the access token and then to package it up into an
>>> HTML document so the POST binding trick can be done.  b) This will only
>>> work for OIDC clients.  SAML clients will be left in the dust, although
>>> I guess we could allow SAML to push a signed assertion back.
>>>
>>>
>>> Thoughts?
>>>
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From bburke at redhat.com  Sat Feb 25 09:42:24 2017
From: bburke at redhat.com (Bill Burke)
Date: Sat, 25 Feb 2017 09:42:24 -0500
Subject: [keycloak-dev] client requested account linking
In-Reply-To: <33b3f8b2-7ab2-e99e-7992-6e79f11ba501@redhat.com>
References: <21c78246-d9e8-c808-766b-a88c595a5210@redhat.com>
	<4a2f4af6-8329-fdae-89df-b22ba93c00cc@redhat.com>
	<0dff4598-db39-0661-0622-ce970ea5b7c1@redhat.com>
	<33b3f8b2-7ab2-e99e-7992-6e79f11ba501@redhat.com>
Message-ID: <fc497061-b077-679c-ba44-1cd8aa56b815@redhat.com>

Ok, I changed this again.  Any solution we come up with will require 
that the application protect itself from CSRF for this operation.  
There's nothing really the server can do. We can give guidelines on how 
to accomplish this.  So, instead of this handshake, there will only be 
one GET request to a link url that takes client_id, redirect_uri, nonce, 
and hash query parameters.

The nonce will be a random string sent by the client.  The hash will be 
a base64url encoded SHA_256 hash of nonce + clientSessionId.  The server 
will verify this hash by looking for an SSO cookie, matching it up with 
a UserSession, then looping through ClientSessionModels to find a 
matching clientId then creating and matching the hash.  This is combined 
with not allowing CORS preflight requests to this URL  (protects SSO 
cookie) as well as checking that any Origin header matches the client.  
I think this is enough to ensure that this server URL is protected from 
direct CSRF attacks.


On 2/24/17 8:46 PM, Bill Burke wrote:
> Ok, option #3 where I would pass an access token to initiate the link
> won't work as the access token could be leaked by a CSRF attack on the
> client.  My new solution is to do a custom protocol.  The goal of this
> protocol is for the server to verify that the client initiated the
> account link and not some rogue site.
>
> 1. Client does a background bearer-token authenticated to the Keycloak
> operation /initiate-link using the access token it got from login.
>
> 2. /initiate-link gets the ClientSessionModel associated with the
> bearer-token. It generates a server-nonce and stores it within the
> ClientSessionModel.
>
> 3. keycloak /initiate-link returns a response that contains the server-nonce
>
> 4. Client generates its own client-nonce.  This client-nonce is stored
> in its HttpSession.
>
> 5. Client generates a nonce-hash of server-nonce + client-nonce +
> provider-id.
>
> 6. Client redirects the browser to Keycloak /link operation passing the
> client-nonce, nonce-hash, provider-id, client-id, and redirect-uri as
> query parameters.
>
> 7. Keycloak /link operation validates that the browser is logged in.  If
> the user is not logged, an error page is shown.  We DO NOT redirect back
> to the client when there is an error as this is an attack vector.
>
> 8. Keycloak verifies clientid, redirect uri, and provider id.
>
> 9. Keycloak loops through the browser's UserSessionModel looking for
> ClientSessionModels that match the clientId.  Checks to see if this
> ClientSession has a server-nonce within it.  If so, it validates the
> hash.  We DO NOT redirect back to the client when there is an error as
> this is an attack vector.  The server-nonce client session attribute is
> cleared so that it can only be used once.
>
> 10. Keycloak initiates the social provider login
>
> 11. Keycloak redirects back to the client using the redirect_uri
>
> What isn't protected here is the client.  If the client is a traditional
> web app, the client is responsible for protecting itself from CSRF.  The
> Account Service does this with a cookie nonce plus the nonce in the
> rendered page links, and it also rejects any CORS requests.  The client
> app will have to do this too.  I don't think Javascript apps are
> affected unless there is a URL you can redirect to that triggers this flow.
>
> Again, I'm not even sure we have to do this sort of thing.  All a CSRF
> attack could do is request that the user link their Keycloak account.
> The attacker can't get any information about the user.
>
>
>
> On 2/24/17 9:10 AM, Bill Burke wrote:
>> Account linking *MUST* be browser based as you need to delegate
>> authentication to the IDP you are brokering with.
>>
>>
>> On 2/24/17 3:21 AM, Marek Posolda wrote:
>>> Don't we have a plan to rewrite AccountService to use Angular+REST? If
>>> yes, then we are fine though. We will have REST endpoint for link
>>> broker, which can be invoked with the bearer token as long as the
>>> token has "manage-account" scope. We don't need to care about CSRF then.
>>>
>>> I can see the only reason to keep support browser+cookie based flows -
>>> the case when client application doesn't have Keycloak token. But from
>>> what you mentioned in the last paragraph, it looks that their client
>>> has our access token?
>>>
>>> Marek
>>>
>>>
>>> On 23/02/17 23:24, Bill Burke wrote:
>>>> A customer has asked us to implement a feature in which there is a
>>>> browser endpoint on keycloak.  This URL can be told to link to a
>>>> specific identity broker provider (Google, Facebook, etc.) and then the
>>>> browser would be redirected back to the client. Pretty much what exists
>>>> in the Account Service console, but without having to look at the
>>>> Account Service.  The reason for this is that they are doing integration
>>>> with a specific social provider and don't want to have to go through the
>>>> Account Service pages. Seems pretty reasonable and valid use case...
>>>> I'm worried about a couple of things:
>>>>
>>>> * The design of it
>>>>
>>>> * The security implications.
>>>>
>>>> The implementation would be simple enough, it would just extract code
>>>> from the accoutn service.  The endpoint would take a "providerId"
>>>> paramter that would be the idp linking to, a "clientId" for the client
>>>> requesting the link, and a "redirect_uri" to redirect back to after the
>>>> link is successful. Obviously the redirect_uri would be validated
>>>> against the clientId.
>>>>
>>>> Now comes the interesting part, the security implications. Account
>>>> linking in the Account Service is fine and dandy and doesn't have any
>>>> security holes because we guarantee that the Account Service initiated
>>>> the linking via a CSRF check.  For this new Client-Requested-Linking
>>>> feature, if we do nothing, and just model it as above, we cannot
>>>> guarantee that the client initiated the linking request.  What are the
>>>> implications of this?  This feature would be vulnerable to CSRF.  A
>>>> rogue website could initiate account linking to a specific configured
>>>> provider.  Is this bad?  I don't know.  We can guarantee that the
>>>> redirect uri is valid.  The browser would never get back to the rogue
>>>> website. So what can we do to improve this?
>>>>
>>>> * We could do nothing and hope its ok that anybody can initiate a link.
>>>>
>>>> * We could add a consent screen like this: "Application 'clientId' is
>>>> requesting that you link your user account to 'providerId'.  Do you
>>>> agree to this?  You will be redirected to this provider if you click
>>>> ok.".  This of course relies on the user to actually read the page.  Is
>>>> this good enough?
>>>>
>>>> * My last thought would be OIDC specific.  We could use the POST binding
>>>> trick that SAML does to do a browser redirect via a POST call. THe POST
>>>> would contain the access token the client has.  We match this token up
>>>> against the browser cookie to make sure its the same session. We also
>>>> make sure that the access token has permission to request a link.  There
>>>> are 2 downsides to this approach a) This requires some code on the
>>>> client side to obtain the access token and then to package it up into an
>>>> HTML document so the POST binding trick can be done.  b) This will only
>>>> work for OIDC clients.  SAML clients will be left in the dust, although
>>>> I guess we could allow SAML to push a signed assertion back.
>>>>
>>>>
>>>> Thoughts?
>>>>
>>>>
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From srossillo at smartling.com  Sat Feb 25 18:58:42 2017
From: srossillo at smartling.com (Scott Rossillo)
Date: Sat, 25 Feb 2017 18:58:42 -0500
Subject: [keycloak-dev] client requested account linking
In-Reply-To: <fc497061-b077-679c-ba44-1cd8aa56b815@redhat.com>
References: <21c78246-d9e8-c808-766b-a88c595a5210@redhat.com>
	<4a2f4af6-8329-fdae-89df-b22ba93c00cc@redhat.com>
	<0dff4598-db39-0661-0622-ce970ea5b7c1@redhat.com>
	<33b3f8b2-7ab2-e99e-7992-6e79f11ba501@redhat.com>
	<fc497061-b077-679c-ba44-1cd8aa56b815@redhat.com>
Message-ID: <704E8EC9-D9DF-4E45-B6E4-D84EFF934994@smartling.com>

Bill,

Can you provide a browser flow of what you?re trying to accomplish?

Scott Rossillo
Smartling | Senior Software Engineer
srossillo at smartling.com

> On Feb 25, 2017, at 9:42 AM, Bill Burke <bburke at redhat.com> wrote:
> 
> Ok, I changed this again.  Any solution we come up with will require 
> that the application protect itself from CSRF for this operation.  
> There's nothing really the server can do. We can give guidelines on how 
> to accomplish this.  So, instead of this handshake, there will only be 
> one GET request to a link url that takes client_id, redirect_uri, nonce, 
> and hash query parameters.
> 
> The nonce will be a random string sent by the client.  The hash will be 
> a base64url encoded SHA_256 hash of nonce + clientSessionId.  The server 
> will verify this hash by looking for an SSO cookie, matching it up with 
> a UserSession, then looping through ClientSessionModels to find a 
> matching clientId then creating and matching the hash.  This is combined 
> with not allowing CORS preflight requests to this URL  (protects SSO 
> cookie) as well as checking that any Origin header matches the client.  
> I think this is enough to ensure that this server URL is protected from 
> direct CSRF attacks.
> 
> 
> On 2/24/17 8:46 PM, Bill Burke wrote:
>> Ok, option #3 where I would pass an access token to initiate the link
>> won't work as the access token could be leaked by a CSRF attack on the
>> client.  My new solution is to do a custom protocol.  The goal of this
>> protocol is for the server to verify that the client initiated the
>> account link and not some rogue site.
>> 
>> 1. Client does a background bearer-token authenticated to the Keycloak
>> operation /initiate-link using the access token it got from login.
>> 
>> 2. /initiate-link gets the ClientSessionModel associated with the
>> bearer-token. It generates a server-nonce and stores it within the
>> ClientSessionModel.
>> 
>> 3. keycloak /initiate-link returns a response that contains the server-nonce
>> 
>> 4. Client generates its own client-nonce.  This client-nonce is stored
>> in its HttpSession.
>> 
>> 5. Client generates a nonce-hash of server-nonce + client-nonce +
>> provider-id.
>> 
>> 6. Client redirects the browser to Keycloak /link operation passing the
>> client-nonce, nonce-hash, provider-id, client-id, and redirect-uri as
>> query parameters.
>> 
>> 7. Keycloak /link operation validates that the browser is logged in.  If
>> the user is not logged, an error page is shown.  We DO NOT redirect back
>> to the client when there is an error as this is an attack vector.
>> 
>> 8. Keycloak verifies clientid, redirect uri, and provider id.
>> 
>> 9. Keycloak loops through the browser's UserSessionModel looking for
>> ClientSessionModels that match the clientId.  Checks to see if this
>> ClientSession has a server-nonce within it.  If so, it validates the
>> hash.  We DO NOT redirect back to the client when there is an error as
>> this is an attack vector.  The server-nonce client session attribute is
>> cleared so that it can only be used once.
>> 
>> 10. Keycloak initiates the social provider login
>> 
>> 11. Keycloak redirects back to the client using the redirect_uri
>> 
>> What isn't protected here is the client.  If the client is a traditional
>> web app, the client is responsible for protecting itself from CSRF.  The
>> Account Service does this with a cookie nonce plus the nonce in the
>> rendered page links, and it also rejects any CORS requests.  The client
>> app will have to do this too.  I don't think Javascript apps are
>> affected unless there is a URL you can redirect to that triggers this flow.
>> 
>> Again, I'm not even sure we have to do this sort of thing.  All a CSRF
>> attack could do is request that the user link their Keycloak account.
>> The attacker can't get any information about the user.
>> 
>> 
>> 
>> On 2/24/17 9:10 AM, Bill Burke wrote:
>>> Account linking *MUST* be browser based as you need to delegate
>>> authentication to the IDP you are brokering with.
>>> 
>>> 
>>> On 2/24/17 3:21 AM, Marek Posolda wrote:
>>>> Don't we have a plan to rewrite AccountService to use Angular+REST? If
>>>> yes, then we are fine though. We will have REST endpoint for link
>>>> broker, which can be invoked with the bearer token as long as the
>>>> token has "manage-account" scope. We don't need to care about CSRF then.
>>>> 
>>>> I can see the only reason to keep support browser+cookie based flows -
>>>> the case when client application doesn't have Keycloak token. But from
>>>> what you mentioned in the last paragraph, it looks that their client
>>>> has our access token?
>>>> 
>>>> Marek
>>>> 
>>>> 
>>>> On 23/02/17 23:24, Bill Burke wrote:
>>>>> A customer has asked us to implement a feature in which there is a
>>>>> browser endpoint on keycloak.  This URL can be told to link to a
>>>>> specific identity broker provider (Google, Facebook, etc.) and then the
>>>>> browser would be redirected back to the client. Pretty much what exists
>>>>> in the Account Service console, but without having to look at the
>>>>> Account Service.  The reason for this is that they are doing integration
>>>>> with a specific social provider and don't want to have to go through the
>>>>> Account Service pages. Seems pretty reasonable and valid use case...
>>>>> I'm worried about a couple of things:
>>>>> 
>>>>> * The design of it
>>>>> 
>>>>> * The security implications.
>>>>> 
>>>>> The implementation would be simple enough, it would just extract code
>>>>> from the accoutn service.  The endpoint would take a "providerId"
>>>>> paramter that would be the idp linking to, a "clientId" for the client
>>>>> requesting the link, and a "redirect_uri" to redirect back to after the
>>>>> link is successful. Obviously the redirect_uri would be validated
>>>>> against the clientId.
>>>>> 
>>>>> Now comes the interesting part, the security implications. Account
>>>>> linking in the Account Service is fine and dandy and doesn't have any
>>>>> security holes because we guarantee that the Account Service initiated
>>>>> the linking via a CSRF check.  For this new Client-Requested-Linking
>>>>> feature, if we do nothing, and just model it as above, we cannot
>>>>> guarantee that the client initiated the linking request.  What are the
>>>>> implications of this?  This feature would be vulnerable to CSRF.  A
>>>>> rogue website could initiate account linking to a specific configured
>>>>> provider.  Is this bad?  I don't know.  We can guarantee that the
>>>>> redirect uri is valid.  The browser would never get back to the rogue
>>>>> website. So what can we do to improve this?
>>>>> 
>>>>> * We could do nothing and hope its ok that anybody can initiate a link.
>>>>> 
>>>>> * We could add a consent screen like this: "Application 'clientId' is
>>>>> requesting that you link your user account to 'providerId'.  Do you
>>>>> agree to this?  You will be redirected to this provider if you click
>>>>> ok.".  This of course relies on the user to actually read the page.  Is
>>>>> this good enough?
>>>>> 
>>>>> * My last thought would be OIDC specific.  We could use the POST binding
>>>>> trick that SAML does to do a browser redirect via a POST call. THe POST
>>>>> would contain the access token the client has.  We match this token up
>>>>> against the browser cookie to make sure its the same session. We also
>>>>> make sure that the access token has permission to request a link.  There
>>>>> are 2 downsides to this approach a) This requires some code on the
>>>>> client side to obtain the access token and then to package it up into an
>>>>> HTML document so the POST binding trick can be done.  b) This will only
>>>>> work for OIDC clients.  SAML clients will be left in the dust, although
>>>>> I guess we could allow SAML to push a signed assertion back.
>>>>> 
>>>>> 
>>>>> Thoughts?
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> 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
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From bburke at redhat.com  Sat Feb 25 19:45:39 2017
From: bburke at redhat.com (Bill Burke)
Date: Sat, 25 Feb 2017 19:45:39 -0500
Subject: [keycloak-dev] client requested account linking
In-Reply-To: <704E8EC9-D9DF-4E45-B6E4-D84EFF934994@smartling.com>
References: <21c78246-d9e8-c808-766b-a88c595a5210@redhat.com>
	<4a2f4af6-8329-fdae-89df-b22ba93c00cc@redhat.com>
	<0dff4598-db39-0661-0622-ce970ea5b7c1@redhat.com>
	<33b3f8b2-7ab2-e99e-7992-6e79f11ba501@redhat.com>
	<fc497061-b077-679c-ba44-1cd8aa56b815@redhat.com>
	<704E8EC9-D9DF-4E45-B6E4-D84EFF934994@smartling.com>
Message-ID: <cce62ead-7be6-29af-913a-357c6718218f@redhat.com>

You mean an keycloak auth flow?  I was thinking the same thing. Or do 
you want to know how the HTTP request flow is?

1. Redirect from client:

Location: 
https://keycloak/auth/realms/{realm}/broker/{providerId}/link?client_id={id}&redirect_uri={uri}&nonce={nonce}&hash={hash}

2. Server extracts SSO cookie from GET request to obtain UserSession.  
Validates client_id and redirect_uri.  Calculates and validates hashes.

3. Do regular account link logic that already exists

4. Redirect to social provider

5. Redirect Back to Keycloak

6. Redirect to "redirect_uri" provided in step #1


On 2/25/17 6:58 PM, Scott Rossillo wrote:
> Bill,
>
> Can you provide a browser flow of what you?re trying to accomplish?
>
> Scott Rossillo
> Smartling | Senior Software Engineer
> srossillo at smartling.com <mailto:srossillo at smartling.com>
>
>> On Feb 25, 2017, at 9:42 AM, Bill Burke <bburke at redhat.com 
>> <mailto:bburke at redhat.com>> wrote:
>>
>> Ok, I changed this again.  Any solution we come up with will require
>> that the application protect itself from CSRF for this operation.
>> There's nothing really the server can do. We can give guidelines on how
>> to accomplish this.  So, instead of this handshake, there will only be
>> one GET request to a link url that takes client_id, redirect_uri, nonce,
>> and hash query parameters.
>>
>> The nonce will be a random string sent by the client.  The hash will be
>> a base64url encoded SHA_256 hash of nonce + clientSessionId.  The server
>> will verify this hash by looking for an SSO cookie, matching it up with
>> a UserSession, then looping through ClientSessionModels to find a
>> matching clientId then creating and matching the hash.  This is combined
>> with not allowing CORS preflight requests to this URL  (protects SSO
>> cookie) as well as checking that any Origin header matches the client.
>> I think this is enough to ensure that this server URL is protected from
>> direct CSRF attacks.
>>
>>
>> On 2/24/17 8:46 PM, Bill Burke wrote:
>>> Ok, option #3 where I would pass an access token to initiate the link
>>> won't work as the access token could be leaked by a CSRF attack on the
>>> client.  My new solution is to do a custom protocol.  The goal of this
>>> protocol is for the server to verify that the client initiated the
>>> account link and not some rogue site.
>>>
>>> 1. Client does a background bearer-token authenticated to the Keycloak
>>> operation /initiate-link using the access token it got from login.
>>>
>>> 2. /initiate-link gets the ClientSessionModel associated with the
>>> bearer-token. It generates a server-nonce and stores it within the
>>> ClientSessionModel.
>>>
>>> 3. keycloak /initiate-link returns a response that contains the 
>>> server-nonce
>>>
>>> 4. Client generates its own client-nonce.  This client-nonce is stored
>>> in its HttpSession.
>>>
>>> 5. Client generates a nonce-hash of server-nonce + client-nonce +
>>> provider-id.
>>>
>>> 6. Client redirects the browser to Keycloak /link operation passing the
>>> client-nonce, nonce-hash, provider-id, client-id, and redirect-uri as
>>> query parameters.
>>>
>>> 7. Keycloak /link operation validates that the browser is logged in.  If
>>> the user is not logged, an error page is shown.  We DO NOT redirect back
>>> to the client when there is an error as this is an attack vector.
>>>
>>> 8. Keycloak verifies clientid, redirect uri, and provider id.
>>>
>>> 9. Keycloak loops through the browser's UserSessionModel looking for
>>> ClientSessionModels that match the clientId.  Checks to see if this
>>> ClientSession has a server-nonce within it.  If so, it validates the
>>> hash.  We DO NOT redirect back to the client when there is an error as
>>> this is an attack vector.  The server-nonce client session attribute is
>>> cleared so that it can only be used once.
>>>
>>> 10. Keycloak initiates the social provider login
>>>
>>> 11. Keycloak redirects back to the client using the redirect_uri
>>>
>>> What isn't protected here is the client.  If the client is a traditional
>>> web app, the client is responsible for protecting itself from CSRF.  The
>>> Account Service does this with a cookie nonce plus the nonce in the
>>> rendered page links, and it also rejects any CORS requests.  The client
>>> app will have to do this too.  I don't think Javascript apps are
>>> affected unless there is a URL you can redirect to that triggers 
>>> this flow.
>>>
>>> Again, I'm not even sure we have to do this sort of thing.  All a CSRF
>>> attack could do is request that the user link their Keycloak account.
>>> The attacker can't get any information about the user.
>>>
>>>
>>>
>>> On 2/24/17 9:10 AM, Bill Burke wrote:
>>>> Account linking *MUST* be browser based as you need to delegate
>>>> authentication to the IDP you are brokering with.
>>>>
>>>>
>>>> On 2/24/17 3:21 AM, Marek Posolda wrote:
>>>>> Don't we have a plan to rewrite AccountService to use Angular+REST? If
>>>>> yes, then we are fine though. We will have REST endpoint for link
>>>>> broker, which can be invoked with the bearer token as long as the
>>>>> token has "manage-account" scope. We don't need to care about CSRF 
>>>>> then.
>>>>>
>>>>> I can see the only reason to keep support browser+cookie based flows -
>>>>> the case when client application doesn't have Keycloak token. But from
>>>>> what you mentioned in the last paragraph, it looks that their client
>>>>> has our access token?
>>>>>
>>>>> Marek
>>>>>
>>>>>
>>>>> On 23/02/17 23:24, Bill Burke wrote:
>>>>>> A customer has asked us to implement a feature in which there is a
>>>>>> browser endpoint on keycloak.  This URL can be told to link to a
>>>>>> specific identity broker provider (Google, Facebook, etc.) and 
>>>>>> then the
>>>>>> browser would be redirected back to the client. Pretty much what 
>>>>>> exists
>>>>>> in the Account Service console, but without having to look at the
>>>>>> Account Service.  The reason for this is that they are doing 
>>>>>> integration
>>>>>> with a specific social provider and don't want to have to go 
>>>>>> through the
>>>>>> Account Service pages. Seems pretty reasonable and valid use case...
>>>>>> I'm worried about a couple of things:
>>>>>>
>>>>>> * The design of it
>>>>>>
>>>>>> * The security implications.
>>>>>>
>>>>>> The implementation would be simple enough, it would just extract code
>>>>>> from the accoutn service.  The endpoint would take a "providerId"
>>>>>> paramter that would be the idp linking to, a "clientId" for the 
>>>>>> client
>>>>>> requesting the link, and a "redirect_uri" to redirect back to 
>>>>>> after the
>>>>>> link is successful. Obviously the redirect_uri would be validated
>>>>>> against the clientId.
>>>>>>
>>>>>> Now comes the interesting part, the security implications. Account
>>>>>> linking in the Account Service is fine and dandy and doesn't have any
>>>>>> security holes because we guarantee that the Account Service 
>>>>>> initiated
>>>>>> the linking via a CSRF check.  For this new Client-Requested-Linking
>>>>>> feature, if we do nothing, and just model it as above, we cannot
>>>>>> guarantee that the client initiated the linking request.  What 
>>>>>> are the
>>>>>> implications of this?  This feature would be vulnerable to CSRF.  A
>>>>>> rogue website could initiate account linking to a specific configured
>>>>>> provider.  Is this bad?  I don't know.  We can guarantee that the
>>>>>> redirect uri is valid.  The browser would never get back to the rogue
>>>>>> website. So what can we do to improve this?
>>>>>>
>>>>>> * We could do nothing and hope its ok that anybody can initiate a 
>>>>>> link.
>>>>>>
>>>>>> * We could add a consent screen like this: "Application 'clientId' is
>>>>>> requesting that you link your user account to 'providerId'.  Do you
>>>>>> agree to this?  You will be redirected to this provider if you click
>>>>>> ok.".  This of course relies on the user to actually read the 
>>>>>> page.  Is
>>>>>> this good enough?
>>>>>>
>>>>>> * My last thought would be OIDC specific.  We could use the POST 
>>>>>> binding
>>>>>> trick that SAML does to do a browser redirect via a POST call. 
>>>>>> THe POST
>>>>>> would contain the access token the client has.  We match this 
>>>>>> token up
>>>>>> against the browser cookie to make sure its the same session. We also
>>>>>> make sure that the access token has permission to request a link. 
>>>>>>  There
>>>>>> are 2 downsides to this approach a) This requires some code on the
>>>>>> client side to obtain the access token and then to package it up 
>>>>>> into an
>>>>>> HTML document so the POST binding trick can be done.  b) This 
>>>>>> will only
>>>>>> work for OIDC clients.  SAML clients will be left in the dust, 
>>>>>> although
>>>>>> I guess we could allow SAML to push a signed assertion back.
>>>>>>
>>>>>>
>>>>>> Thoughts?
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>
>> _______________________________________________
>> 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 daviddd.kl at gmail.com  Mon Feb 27 08:00:38 2017
From: daviddd.kl at gmail.com (David Klassen)
Date: Mon, 27 Feb 2017 14:00:38 +0100
Subject: [keycloak-dev] KEYCLOAK-4315 - Remove dead code from SAML
	implementation
Message-ID: <CALnM2xgqxrBN5vRod_d1gAJSEpTeTPKVe1GSq7NUGphOTZBjCQ@mail.gmail.com>

Hello there,

I want to contribute to keycloak and currently searching for (beginner)
tasks that need to done. In Jira I found this ticket:
https://issues.jboss.org/browse/KEYCLOAK-4315 (Remove dead code from SAML
implementation)

As suggested in the "HackingOnKeycloak" guide I want to ask if this is a
wanted task and if there's something I need to keep in mind while removing
dead code.

regards,
David

From hmlnarik at redhat.com  Mon Feb 27 08:57:43 2017
From: hmlnarik at redhat.com (Hynek Mlnarik)
Date: Mon, 27 Feb 2017 14:57:43 +0100
Subject: [keycloak-dev] KEYCLOAK-4315 - Remove dead code from SAML
	implementation
In-Reply-To: <CALnM2xgqxrBN5vRod_d1gAJSEpTeTPKVe1GSq7NUGphOTZBjCQ@mail.gmail.com>
References: <CALnM2xgqxrBN5vRod_d1gAJSEpTeTPKVe1GSq7NUGphOTZBjCQ@mail.gmail.com>
Message-ID: <CAMvXD=HQNubncdxuFj30VmPHyvgjZaKapenyKEe=aq-s44bDGg@mail.gmail.com>

Hi David,

while this is a wanted task, I'm afraid it is not much of a beginner
task. If you are interested in SAML, it would be very helpful and
beneficial for getting familiar with code to start with implementation
of SAML tests, see e.g. subtasks of
https://issues.jboss.org/browse/KEYCLOAK-4317 or
https://issues.jboss.org/browse/KEYCLOAK-4297.

--Hynek

On Mon, Feb 27, 2017 at 2:00 PM, David Klassen <daviddd.kl at gmail.com> wrote:
> Hello there,
>
> I want to contribute to keycloak and currently searching for (beginner)
> tasks that need to done. In Jira I found this ticket:
> https://issues.jboss.org/browse/KEYCLOAK-4315 (Remove dead code from SAML
> implementation)
>
> As suggested in the "HackingOnKeycloak" guide I want to ask if this is a
> wanted task and if there's something I need to keep in mind while removing
> dead code.
>
> regards,
> David
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



-- 

--Hynek

From ya at slamail.org  Tue Feb 28 10:35:18 2017
From: ya at slamail.org (Yaacov Akiba Slama)
Date: Tue, 28 Feb 2017 17:35:18 +0200
Subject: [keycloak-dev] mysql and utfmb4 almost works
Message-ID: <4696c4d8-f4c2-a12c-15ca-930dd025fa15@slamail.org>

Hi,

I installed mysql 5.7.17 with innodb-large-prefix=1 and created a
database using utf8mb4 charset. Then I installed, configured and
launched keycloak-2.5.4

Everything almost "works". The only problem is the 1.9.1 database
change: jpa-changelog-1.9.1.xml

A workaround is to let keycloak fails (assuming initializeEmpty is
true), then change the charset of the table "REALM" to utf8, restart
keycloak then stop it after the database is ready.

Finally change back the charset of the table "REALM" to utf8mb4 and
restart keycloak.

The alternative is to use the patch below. I can also open a PR in github.

What do you think ?

Thanks.

diff --git
a/model/jpa/src/main/resources/META-INF/jpa-changelog-1.9.1-mysql.xml
b/model/jpa/src/main/resources/META-INF/jpa-changelog-1.9.1-mysql.xml
new file mode 100644
index 0000000000..55afffc5a4
--- /dev/null
+++ b/model/jpa/src/main/resources/META-INF/jpa-changelog-1.9.1-mysql.xml
@@ -0,0 +1,30 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!--
+  ~ Copyright 2016 Red Hat, Inc. and/or its affiliates
+  ~ and other contributors as indicated by the @author tags.
+  ~
+  ~ Licensed under the Apache License, Version 2.0 (the "License");
+  ~ you may not use this file except in compliance with the License.
+  ~ You may obtain a copy of the License at
+  ~
+  ~ http://www.apache.org/licenses/LICENSE-2.0
+  ~
+  ~ Unless required by applicable law or agreed to in writing, software
+  ~ distributed under the License is distributed on an "AS IS" BASIS,
+  ~ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied.
+  ~ See the License for the specific language governing permissions and
+  ~ limitations under the License.
+  -->
+
+<databaseChangeLog
logicalFilePath="META-INF/db2-jpa-changelog-1.9.1.xml"
xmlns="http://www.liquibase.org/xml/ns/dbchangelog"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog
http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-3.1.xsd">
+    <changeSet author="keycloak" id="1.9.1">
+        <preConditions onSqlOutput="TEST" onFail="MARK_RAN">
+            <dbms type="mysql" />
+        </preConditions>
+
+        <!-- Can't increase publicKey and certificate size on mysql
when utf8mb4 is used. Need to find better solution -->
+        <modifyDataType tableName="REALM" columnName="PRIVATE_KEY"
newDataType="VARCHAR(4000)"/>
+        <!--<modifyDataType tableName="REALM" columnName="PUBLIC_KEY"
newDataType="VARCHAR(4000)"/>-->
+        <!--<modifyDataType tableName="REALM" columnName="CERTIFICATE"
newDataType="VARCHAR(4000)"/>-->
+    </changeSet>
+</databaseChangeLog>
diff --git
a/model/jpa/src/main/resources/META-INF/jpa-changelog-1.9.1.xml
b/model/jpa/src/main/resources/META-INF/jpa-changelog-1.9.1.xml
index c083bc9a2b..d67f97b903 100755
--- a/model/jpa/src/main/resources/META-INF/jpa-changelog-1.9.1.xml
+++ b/model/jpa/src/main/resources/META-INF/jpa-changelog-1.9.1.xml
@@ -20,7 +20,10 @@
     <changeSet author="keycloak" id="1.9.1">
         <preConditions onSqlOutput="TEST" onFail="MARK_RAN">
             <not>
+                <or>
                 <dbms type="db2" />
+                <dbms type="mysql" />
+                </or>
             </not>
         </preConditions>
 


From ya at slamail.org  Tue Feb 28 10:41:24 2017
From: ya at slamail.org (Yaacov Akiba Slama)
Date: Tue, 28 Feb 2017 17:41:24 +0200
Subject: [keycloak-dev] mysql and utfmb4 almost works
In-Reply-To: <4696c4d8-f4c2-a12c-15ca-930dd025fa15@slamail.org>
References: <4696c4d8-f4c2-a12c-15ca-930dd025fa15@slamail.org>
Message-ID: <77702301-cc98-374f-3be2-fa8e6811ee01@slamail.org>

I am attaching the patch because it was mangled by the mail client.

On 28/02/17 17:35, Yaacov Akiba Slama wrote:
> Hi,
>
> I installed mysql 5.7.17 with innodb-large-prefix=1 and created a
> database using utf8mb4 charset. Then I installed, configured and
> launched keycloak-2.5.4
>
> Everything almost "works". The only problem is the 1.9.1 database
> change: jpa-changelog-1.9.1.xml
>
> A workaround is to let keycloak fails (assuming initializeEmpty is
> true), then change the charset of the table "REALM" to utf8, restart
> keycloak then stop it after the database is ready.
>
> Finally change back the charset of the table "REALM" to utf8mb4 and
> restart keycloak.
>
> The alternative is to use the patch below. I can also open a PR in github.
>
> What do you think ?
>
> Thanks.
>
> diff --git
> a/model/jpa/src/main/resources/META-INF/jpa-changelog-1.9.1-mysql.xml
> b/model/jpa/src/main/resources/META-INF/jpa-changelog-1.9.1-mysql.xml
> new file mode 100644
> index 0000000000..55afffc5a4
> --- /dev/null
> +++ b/model/jpa/src/main/resources/META-INF/jpa-changelog-1.9.1-mysql.xml
> @@ -0,0 +1,30 @@
> +<?xml version="1.0" encoding="UTF-8" standalone="no"?>
> +<!--
> +  ~ Copyright 2016 Red Hat, Inc. and/or its affiliates
> +  ~ and other contributors as indicated by the @author tags.
> +  ~
> +  ~ Licensed under the Apache License, Version 2.0 (the "License");
> +  ~ you may not use this file except in compliance with the License.
> +  ~ You may obtain a copy of the License at
> +  ~
> +  ~ http://www.apache.org/licenses/LICENSE-2.0
> +  ~
> +  ~ Unless required by applicable law or agreed to in writing, software
> +  ~ distributed under the License is distributed on an "AS IS" BASIS,
> +  ~ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
> implied.
> +  ~ See the License for the specific language governing permissions and
> +  ~ limitations under the License.
> +  -->
> +
> +<databaseChangeLog
> logicalFilePath="META-INF/db2-jpa-changelog-1.9.1.xml"
> xmlns="http://www.liquibase.org/xml/ns/dbchangelog"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog
> http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-3.1.xsd">
> +    <changeSet author="keycloak" id="1.9.1">
> +        <preConditions onSqlOutput="TEST" onFail="MARK_RAN">
> +            <dbms type="mysql" />
> +        </preConditions>
> +
> +        <!-- Can't increase publicKey and certificate size on mysql
> when utf8mb4 is used. Need to find better solution -->
> +        <modifyDataType tableName="REALM" columnName="PRIVATE_KEY"
> newDataType="VARCHAR(4000)"/>
> +        <!--<modifyDataType tableName="REALM" columnName="PUBLIC_KEY"
> newDataType="VARCHAR(4000)"/>-->
> +        <!--<modifyDataType tableName="REALM" columnName="CERTIFICATE"
> newDataType="VARCHAR(4000)"/>-->
> +    </changeSet>
> +</databaseChangeLog>
> diff --git
> a/model/jpa/src/main/resources/META-INF/jpa-changelog-1.9.1.xml
> b/model/jpa/src/main/resources/META-INF/jpa-changelog-1.9.1.xml
> index c083bc9a2b..d67f97b903 100755
> --- a/model/jpa/src/main/resources/META-INF/jpa-changelog-1.9.1.xml
> +++ b/model/jpa/src/main/resources/META-INF/jpa-changelog-1.9.1.xml
> @@ -20,7 +20,10 @@
>      <changeSet author="keycloak" id="1.9.1">
>          <preConditions onSqlOutput="TEST" onFail="MARK_RAN">
>              <not>
> +                <or>
>                  <dbms type="db2" />
> +                <dbms type="mysql" />
> +                </or>
>              </not>
>          </preConditions>
>  
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


-------------- next part --------------
diff --git a/model/jpa/src/main/resources/META-INF/jpa-changelog-1.9.1-mysql.xml b/model/jpa/src/main/resources/META-INF/jpa-changelog-1.9.1-mysql.xml
new file mode 100644
index 0000000000..55afffc5a4
--- /dev/null
+++ b/model/jpa/src/main/resources/META-INF/jpa-changelog-1.9.1-mysql.xml
@@ -0,0 +1,30 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!--
+  ~ Copyright 2016 Red Hat, Inc. and/or its affiliates
+  ~ and other contributors as indicated by the @author tags.
+  ~
+  ~ Licensed under the Apache License, Version 2.0 (the "License");
+  ~ you may not use this file except in compliance with the License.
+  ~ You may obtain a copy of the License at
+  ~
+  ~ http://www.apache.org/licenses/LICENSE-2.0
+  ~
+  ~ Unless required by applicable law or agreed to in writing, software
+  ~ distributed under the License is distributed on an "AS IS" BASIS,
+  ~ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+  ~ See the License for the specific language governing permissions and
+  ~ limitations under the License.
+  -->
+
+<databaseChangeLog logicalFilePath="META-INF/db2-jpa-changelog-1.9.1.xml" xmlns="http://www.liquibase.org/xml/ns/dbchangelog" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-3.1.xsd">
+    <changeSet author="keycloak" id="1.9.1">
+        <preConditions onSqlOutput="TEST" onFail="MARK_RAN">
+            <dbms type="mysql" />
+        </preConditions>
+
+        <!-- Can't increase publicKey and certificate size on mysql when utf8mb4 is used. Need to find better solution -->
+        <modifyDataType tableName="REALM" columnName="PRIVATE_KEY" newDataType="VARCHAR(4000)"/>
+        <!--<modifyDataType tableName="REALM" columnName="PUBLIC_KEY" newDataType="VARCHAR(4000)"/>-->
+        <!--<modifyDataType tableName="REALM" columnName="CERTIFICATE" newDataType="VARCHAR(4000)"/>-->
+    </changeSet>
+</databaseChangeLog>
diff --git a/model/jpa/src/main/resources/META-INF/jpa-changelog-1.9.1.xml b/model/jpa/src/main/resources/META-INF/jpa-changelog-1.9.1.xml
index c083bc9a2b..d67f97b903 100755
--- a/model/jpa/src/main/resources/META-INF/jpa-changelog-1.9.1.xml
+++ b/model/jpa/src/main/resources/META-INF/jpa-changelog-1.9.1.xml
@@ -20,7 +20,10 @@
     <changeSet author="keycloak" id="1.9.1">
         <preConditions onSqlOutput="TEST" onFail="MARK_RAN">
             <not>
+                <or>
                 <dbms type="db2" />
+                <dbms type="mysql" />
+                </or>
             </not>
         </preConditions>