From christian.d.battaglia at gmail.com  Mon Jul  2 15:01:10 2018
From: christian.d.battaglia at gmail.com (Christian Battaglia)
Date: Mon, 2 Jul 2018 15:01:10 -0400
Subject: [keycloak-dev] KEYCLOAK_IDENTITY encoding choose between HMAC and
	RSA
Message-ID: <CAGCf-JYr9pNjFP4kx6Qa21Y3KCqfUTrr9G16En+2Aom88T7HcQ@mail.gmail.com>

"encodeToken" method from
"services/src/main/java/org/keycloak/services/managers/AuthenticationManager.java
" specifically uses hmac256 for its encoding and I get that this is done
for speed but I would argue that this should be a choice in the
configuration.

So my use case sort of breaks outside the walls of Keycloak but I think
this would be a great point to extend. I would like to make use of this JWT
on the NGINX network layer to cryptographically verify against the RSA
public key found at
"/auth/realms/<realm-name>/.well-known/openid-configuration".

This would be sort of a broad level scope authentication used for things
like CDN assets.

I get this looks kind of nasty as far as security concerns but how else
could I include a cookie for a specific client purpose and at a specific
subdomain without first adding in a minimal client frontend with the
Keycloak js iframe check that then adds a cookie for that domain and then
redirects them back to the URL? It seems kind of dumb this couldn't be done
on a realm wide level.

Thoughts?

- Christian

From Sebastian.Loesch at governikus.de  Tue Jul  3 01:36:35 2018
From: Sebastian.Loesch at governikus.de (=?iso-8859-1?Q?L=F6sch=2C_Sebastian?=)
Date: Tue, 3 Jul 2018 05:36:35 +0000
Subject: [keycloak-dev] Introduce role attributes
Message-ID: <f290648bf6f24a3994138d5529891d63@BOSKGEXC01.boskg.local>

Hi developers,

we are currently setting up a project using keycloak and need to model:
- representative roles, i.e. roles that are given temporarily from one user to another e.g. in holiday times
- roles contain entitlements on business objects

The current role object in keycloak is not sufficent for our use cases. Searching for a solution I stumbled over
https://issues.jboss.org/browse/KEYCLOAK-961
Introducing role attributes would solve my challenges. Also this fits well in the keycloak data model, as there are already user attributes, group attributes, realm attributes.

So I would like to add role attributes to keycloak in the style of group attributes.
What do you think?

Best regards,
Sebastian


From Sebastian.Loesch at governikus.de  Tue Jul  3 03:00:53 2018
From: Sebastian.Loesch at governikus.de (=?iso-8859-1?Q?L=F6sch=2C_Sebastian?=)
Date: Tue, 3 Jul 2018 07:00:53 +0000
Subject: [keycloak-dev] Introduce lastModified property on UserModel
Message-ID: <9139119d072b40bd8d1ea1bd765bcda8@BOSKGEXC01.boskg.local>

Hi developers,

we are currently setting up a project using keycloak and have the need to show the last mofication date of a user, similar to SCIM lastModified (see https://tools.ietf.org/html/rfc7643#section-3.1).

What do you think adding this as a new property on UserModel?

Best regards,
Sebastian


From thomas.darimont at googlemail.com  Tue Jul  3 07:22:16 2018
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Tue, 3 Jul 2018 13:22:16 +0200
Subject: [keycloak-dev] Some feature suggestions for Identity Provider
	support
Message-ID: <CAK-7U1jikTB-q7rSBK603zCjMDLukuNSCXXSMux7m9o25CBX1g@mail.gmail.com>

Hello Keycloak-Team,

for a integration scenario with a big german internet provider I needed to
implement
a custom OAuth2 based IdentityProvider.
It worked out quite well but I encountered some things which currently
require
custom coding that could be provided out of the box.

- Default roles for users that come via Identity Provider
I need to assign some realm- / client-roles to users that come via that IdP.
Users that come via that IdP should be able to access certain client
applications by default.
Of course one could programmatically add appropriate roles to newly created
broker users,
but it would be nicer to be able to configure a set of default roles on IdP
level, like roles / scopes
for Clients / Service Accounts.

- Allow multiple IdP definitions of the same type with different names
(google-test, google-staging)
At the moment it seems that one can only have one IdP per IdP-type (e.g.
just one google, one twitter etc.).
However for testing it would be handy to be able to define multiple IdP
definitions of the same type
with different identifiers.
A workaround for this would be to use different realms for this but if one
needs to work with multiple
testing / staging environments this becomes complicated quickly.

WDYT?

Cheers,
Thomas

From pkboucher801 at gmail.com  Tue Jul  3 10:20:38 2018
From: pkboucher801 at gmail.com (pkboucher801 at gmail.com)
Date: Tue, 3 Jul 2018 10:20:38 -0400
Subject: [keycloak-dev] Global "reporting" role like admin but read-only?
Message-ID: <000801d412d9$047a63c0$0d6f2b40$@gmail.com>

According to
https://www.keycloak.org/docs/latest/server_admin/index.html#global-roles
there are two global roles, admin and create-realm, but we would like to add
a third one, call it reporting, that has read-only access to all settings in
every realm (so all of the view- and query- permissions).

 

We can create the role as a composite with permissions over every realm, but
if a new realm is added later, the reporting role has no access unless we
explicitly grant it.

 

Is it possible for us to add a global role by creating a new realm role in
the master realm, and giving it a particular configuration and/or set of
permissions?

 

Thanks!

 

Regards,

Peter K. Boucher

 


From mposolda at redhat.com  Wed Jul  4 16:05:57 2018
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 4 Jul 2018 22:05:57 +0200
Subject: [keycloak-dev] Keycloak 4.1.0.Final released!
Message-ID: <3a2d3f3d-6440-7e26-6a30-b75767b92b51@redhat.com>

See details on the blog: 
http://blog.keycloak.org/2018/07/keycloak-410final-released.html


From thomas.darimont at googlemail.com  Sat Jul  7 10:26:12 2018
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Sat, 7 Jul 2018 16:26:12 +0200
Subject: [keycloak-dev] Token revocation support
Message-ID: <CAK-7U1gEToAL=BvOoh-UOqDzH-kf9BuKC9NR=n3ME_3RWOG6vg@mail.gmail.com>

Hello Keycloak Team,

whilst comparing the output of googles .well-known/openid-configuration
with that of Keycloak
I noticed that the .well-known/openid-configuration endpoint in Keycloak
does not expose a "revocation_endpoint".
See below...

I just stumbled upon the old keycloak-dev ML thread where this was
mentioned already.
http://lists.jboss.org/pipermail/keycloak-dev/2016-April/007054.html

Are there any plans to support token revocation with a
`revocation_endpoint`?

RFC7009 mentions that an implementation MUST provide token revocation for
refresh_tokens
and SHOULD provide support for access_tokens, perhaps only supporting
refresh_tokens would be a good start.

It seems that token revocation is currently handled by updating the
"notBefore" timestamp
of a realm and ensuring that only tokens with issuedAt timestamp >
notBefore are considered valid.
A naive way of supporting the revocation_endpoint could just be to update
the realms notBefore timestamp.

However I think this might be a bit too coarse-grained since it might
invalidate a bunch of tokens at once,
which could potentially require many/all clients/users to request new
tokens.

A more fine-grained approach could be to record the hash of a revoked
refresh_token value in a
database table like revoked_tokens (id, token_hash, issued_at, token_type).
When a new token is requested with a refresh_token, then one could try to
lookup an entry in the
revoked_tokens table with the token_hash of the current token.
If nothing was found then the token was not revoked and can be used.
Otherwise, the token was revoked and no new
tokens should be issued with the given refresh_token, which means that the
user / client must reauthenticate again.
Table entries could be cleared once the associated refresh tokens have
timed out.

OAuth2 Token Revocation Overview:
https://connect2id.com/blog/token-revocation
OAuth2 Token Revocation RFC: https://tools.ietf.org/html/rfc7009

Cheers,
Thomas

This is the output of googles .well-known/openid-configuration endpoint:
https://accounts.google.com/.well-known/openid-configuration
{
    "issuer": "https://accounts.google.com",
    "authorization_endpoint": "https://accounts.google.com/o/oauth2/v2/auth
",
    "token_endpoint": "https://www.googleapis.com/oauth2/v4/token",
    "userinfo_endpoint": "https://www.googleapis.com/oauth2/v3/userinfo",
    "revocation_endpoint": "https://accounts.google.com/o/oauth2/revoke",
    "jwks_uri": "https://www.googleapis.com/oauth2/v3/certs",
    "response_types_supported": [
        "code",
        "token",
        "id_token",
        "code token",
        "code id_token",
        "token id_token",
        "code token id_token",
        "none"
    ],
    "subject_types_supported": [
        "public"
    ],
    "id_token_signing_alg_values_supported": [
        "RS256"
    ],
    "scopes_supported": [
        "openid",
        "email",
        "profile"
    ],
    "token_endpoint_auth_methods_supported": [
        "client_secret_post",
        "client_secret_basic"
    ],
    "claims_supported": [
        "aud",
        "email",
        "email_verified",
        "exp",
        "family_name",
        "given_name",
        "iat",
        "iss",
        "locale",
        "name",
        "picture",
        "sub"
    ],
    "code_challenge_methods_supported": [
        "plain",
        "S256"
    ]
}

This is the output of Keycloaks .well-known/openid-configuration endpoint
(Keycloak 4.1.0.Final)
http://iam.tdlabs.local:8080/auth/realms/concourseci/.well-known/openid-configuration
{
    "issuer": "http://iam.tdlabs.local:8080/auth/realms/concourseci",
    "authorization_endpoint": "
http://iam.tdlabs.local:8080/auth/realms/concourseci/protocol/openid-connect/auth
",
    "token_endpoint": "
http://iam.tdlabs.local:8080/auth/realms/concourseci/protocol/openid-connect/token
",
    "token_introspection_endpoint": "
http://iam.tdlabs.local:8080/auth/realms/concourseci/protocol/openid-connect/token/introspect
",
    "userinfo_endpoint": "
http://iam.tdlabs.local:8080/auth/realms/concourseci/protocol/openid-connect/userinfo
",
    "end_session_endpoint": "
http://iam.tdlabs.local:8080/auth/realms/concourseci/protocol/openid-connect/logout
",
    "jwks_uri": "
http://iam.tdlabs.local:8080/auth/realms/concourseci/protocol/openid-connect/certs
",
    "check_session_iframe": "
http://iam.tdlabs.local:8080/auth/realms/concourseci/protocol/openid-connect/login-status-iframe.html
",
    "grant_types_supported": [
        "authorization_code",
        "implicit",
        "refresh_token",
        "password",
        "client_credentials"
    ],
    "response_types_supported": [
        "code",
        "none",
        "id_token",
        "token",
        "id_token token",
        "code id_token",
        "code token",
        "code id_token token"
    ],
    "subject_types_supported": [
        "public",
        "pairwise"
    ],
    "id_token_signing_alg_values_supported": [
        "RS256"
    ],
    "userinfo_signing_alg_values_supported": [
        "RS256"
    ],
    "request_object_signing_alg_values_supported": [
        "none",
        "RS256"
    ],
    "response_modes_supported": [
        "query",
        "fragment",
        "form_post"
    ],
    "registration_endpoint": "
http://iam.tdlabs.local:8080/auth/realms/concourseci/clients-registrations/openid-connect
",
    "token_endpoint_auth_methods_supported": [
        "private_key_jwt",
        "client_secret_basic",
        "client_secret_post",
        "client_secret_jwt"
    ],
    "token_endpoint_auth_signing_alg_values_supported": [
        "RS256"
    ],
    "claims_supported": [
        "sub",
        "iss",
        "auth_time",
        "name",
        "given_name",
        "family_name",
        "preferred_username",
        "email"
    ],
    "claim_types_supported": [
        "normal"
    ],
    "claims_parameter_supported": false,
    "scopes_supported": [
        "openid",
        "address",
        "concourse.main",
        "email",
        "offline_access",
        "phone",
        "profile",
        "read"
    ],
    "request_parameter_supported": true,
    "request_uri_parameter_supported": true,
    "code_challenge_methods_supported": [
        "plain",
        "S256"
    ],
    "tls_client_certificate_bound_access_tokens": true
}

From ddtxra at gmail.com  Mon Jul  9 09:37:44 2018
From: ddtxra at gmail.com (Daniel Teixeira)
Date: Mon, 9 Jul 2018 15:37:44 +0200
Subject: [keycloak-dev] SAML LogoutRequest (NameQualifer and SPNameQualifier
	missing)
Message-ID: <CAHvCgvzf6em_7rN5QPgT0CfjzYEk+4ws6e-gKKsp+fkR=zeY6A@mail.gmail.com>

Dear Keycloak dev team,
Seems like Keycloak does not send the NameQualifer and SPNameQualifier in a
SAML LogoutRequest. See this issue in Shibboleth:
https://issues.shibboleth.net/jira/browse/IDP-1297

Are you able to confirm that?
Is it something you could fix in a next release?


Thanks in advance,
Daniel

From thomas.darimont at googlemail.com  Tue Jul 10 02:04:43 2018
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Tue, 10 Jul 2018 08:04:43 +0200
Subject: [keycloak-dev] Security Event Token
Message-ID: <CAK-7U1ijAM_fKBF68XHfjE_10v6uwGX3K6s13H4Fwm288YsWsw@mail.gmail.com>

Hello Keycloak Team,

just stumbled upon the RFC and thought that it might be a good fit for
Keycloak.

Security Event Token (SET), RFC 8417! Standardizes a method of using JWT
(with optional JWS signing, and JWE encryption) to describe a statement of
fact about a security subject.
https://tools.ietf.org/html/rfc8417

Cheers,
Thomas

From gambol99 at gmail.com  Tue Jul 10 09:17:07 2018
From: gambol99 at gmail.com (gambol)
Date: Tue, 10 Jul 2018 14:17:07 +0100
Subject: [keycloak-dev] Outage Issue
In-Reply-To: <CA+AP+fNhVi7hLmuSqXRmSURnZnynT+AWxG++2O7A4sQ6HFOfDQ@mail.gmail.com>
References: <CA+AP+fOJJ1hSpEFuiikmiVyoo=NWzh5F8aL=Ni=WDdsDa8Dkbw@mail.gmail.com>
	<CAA9R9O6AVP9x92zkFtiTARHKntNzun-7AgO1ZhjEL4qAgf1Vbg@mail.gmail.com>
	<CA+AP+fNhVi7hLmuSqXRmSURnZnynT+AWxG++2O7A4sQ6HFOfDQ@mail.gmail.com>
Message-ID: <CA+AP+fNvTovHB9UqUPAFd9TwJh5o=+s1-Awtn99yuhUMCNqseA@mail.gmail.com>

I did notice this morning the following warning on startup

"The node-identifier attribute on the /subsystem=transactions is set to the
default value. This is a danger for environments running multiple servers.
Please make sure the attribute value is unique"

Sound related??

Rohith



On Fri, Jun 29, 2018 at 10:50 AM gambol <gambol99 at gmail.com> wrote:

> Hi Sebastian
>
> The keycloak version is 3.4.3.Final though we've also experienced the
> issue on 3.1 as well.
>
> Next time, though I hope there won't be a next time :-) .. I'll grab a
> thread dump and running transactions
>
> Rohith
>
> On Wed, Jun 27, 2018 at 10:57 AM Sebastian Laskawiec <slaskawi at redhat.com>
> wrote:
>
>> From your description and the logs I guess it might be a problem with
>> some transaction.
>>
>> Would you be able to tell us more about the Keycloak version you're
>> running? Also, a Thread dump would be helpful and you might investigate if
>> there are any long running transactions in the DB [1].
>>
>> Thanks,
>> Sebastian
>>
>> [1]
>> https://www.psce.com/en/blog/2015/01/22/tracking-mysql-query-history-in-long-running-transactions/
>>
>> On Thu, Jun 21, 2018 at 3:45 PM gambol <gambol99 at gmail.com> wrote:
>>
>>> Hiya
>>>
>>> I was wondering if anyone has come across this before. We have Keycloak
>>> running in a kubernetes cluster, a mysql RDS, and standalone-ha setup
>>> using
>>> two gossip servers, each running behind a kube service and passed in via
>>> environment variables
>>>
>>> <protocol type="TCPGOSSIP">
>>>   <property name="initial_hosts">${env.GOSSIP_ROUTER_HOST}</property>
>>> </protocol>
>>>
>>> Cluster appears to work fine, a new node added makes a change to topology
>>> and so forth. We do however out of the blue get the following error on
>>> occasion, every couple of weeks... Shortly after the rest of the replicas
>>> become affected, the health check on the /auth fails and or login
>>> attempts
>>> begin to timeout .. At present the only solution is to completely cycle
>>> the
>>> cluster.
>>>
>>> 13:07:52,451 WARN  [com.arjuna.ats.arjuna] (Transaction Reaper Worker 0)
>>> ARJUNA012108: CheckedAction::check - atomic action
>>> 0:ffff0a0a8b0a:-6d4f7aec:5b0ef057:47876e aborting with 1 threads active!
>>> 13:07:52,451 WARN
>>>
>>> [org.hibernate.resource.transaction.backend.jta.internal.synchronization.SynchronizationCallbackCoordinatorTrackingImpl]
>>> (Transaction Reaper Worker 0) HHH000451: Transaction afterCompletion
>>> called
>>> by a background thread; delaying afterCompletion processing until the
>>> original thread can handle it. [status=4]
>>> 13:07:52,451 WARN  [com.arjuna.ats.arjuna] (Transaction Reaper Worker 0)
>>> ARJUNA012121: TransactionReaper::doCancellations worker
>>> Thread[Transaction
>>> Reaper Worker 0,5,main] successfully canceled TX
>>> 0:ffff0a0a8b0a:-6d4f7aec:5b0ef057:47876e
>>> 13:07:55,475 WARN  [com.arjuna.ats.arjuna] (Transaction Reaper)
>>> ARJUNA012117: TransactionReaper::check timeout for TX
>>> 0:ffff0a0a8b0a:-6d4f7aec:5b0ef057:4787b9 in state  RUN
>>> 13:07:55,476 WARN  [com.arjuna.ats.arjuna] (Transaction Reaper Worker 0)
>>> ARJUNA012095: Abort of action id 0:ffff0a0a8b0a:-6d4f7aec:5b0ef057:4787b9
>>> invoked while multiple threads active within it.
>>> 13:07:55,480 WARN  [com.arjuna.ats.arjuna] (Transaction Reaper Worker 0)
>>> ARJUNA012381: Action id 0:ffff0a0a8b0a:-6d4f7aec:5b0ef057:4787b9
>>> completed
>>> with multiple threads - thread default task-64 was in progress with
>>> sun.misc.Unsafe.park(Native Method)
>>> java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>>>
>>> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
>>> org.apache.http.pool.PoolEntryFuture.await(PoolEntryFuture.java:138)
>>>
>>> org.apache.http.pool.AbstractConnPool.getPoolEntryBlocking(AbstractConnPool.java:306)
>>>
>>> org.apache.http.pool.AbstractConnPool.access$000(AbstractConnPool.java:64)
>>>
>>> org.apache.http.pool.AbstractConnPool$2.getPoolEntry(AbstractConnPool.java:192)
>>>
>>> org.apache.http.pool.AbstractConnPool$2.getPoolEntry(AbstractConnPool.java:185)
>>> org.apache.http.pool.PoolEntryFuture.get(PoolEntryFuture.java:107)
>>>
>>> org.apache.http.impl.conn.PoolingHttpClientConnectionManager.leaseConnection(PoolingHttpClientConnectionManager.java:276)
>>>
>>> org.apache.http.impl.conn.PoolingHttpClientConnectionManager$1.get(PoolingHttpClientConnectionManager.java:263)
>>>
>>> org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:190)
>>>
>>> org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184)
>>> org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88)
>>>
>>> org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
>>>
>>> org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184)
>>>
>>> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
>>>
>>> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:107)
>>>
>>> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:55)
>>>
>>> org.keycloak.broker.provider.util.SimpleHttp.makeRequest(SimpleHttp.java:185)
>>>
>>> org.keycloak.broker.provider.util.SimpleHttp.asResponse(SimpleHttp.java:154)
>>>
>>> org.keycloak.broker.provider.util.SimpleHttp.asString(SimpleHttp.java:146)
>>>
>>> org.keycloak.broker.oidc.AbstractOAuth2IdentityProvider$Endpoint.authResponse(AbstractOAuth2IdentityProvider.java:397)
>>> sun.reflect.GeneratedMethodAccessor994.invoke(Unknown Source)
>>>
>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>> java.lang.reflect.Method.invoke(Method.java:498)
>>>
>>> org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:140)
>>>
>>> org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295)
>>>
>>> org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249)
>>>
>>> org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:138)
>>>
>>> org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:107)
>>>
>>> org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:133)
>>>
>>> org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:101)
>>>
>>> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:406)
>>>
>>> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:213)
>>>
>>> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:228)
>>>
>>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
>>>
>>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
>>> javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
>>>
>>> io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
>>>
>>> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
>>>
>>> org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:90)
>>> io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
>>>
>>> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
>>>
>>> io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
>>>
>>> io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
>>>
>>> io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
>>>
>>> org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
>>>
>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>>>
>>> io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
>>>
>>> io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
>>>
>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>>>
>>> io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
>>>
>>> io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
>>>
>>> io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
>>>
>>> io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
>>>
>>> io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
>>>
>>> io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
>>>
>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>>>
>>> org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
>>>
>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>>>
>>> org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
>>>
>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>>>
>>> io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
>>>
>>> io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
>>>
>>> io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
>>>
>>> io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
>>>
>>> io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
>>>
>>> io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
>>>
>>> org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
>>>
>>> org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction$$Lambda$1243/578097420.call(Unknown
>>> Source)
>>>
>>> org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
>>>
>>> org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$1244/197032188.call(Unknown
>>> Source)
>>>
>>> org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
>>>
>>> org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$1244/197032188.call(Unknown
>>> Source)
>>>
>>> org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
>>>
>>> org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$1244/197032188.call(Unknown
>>> Source)
>>>
>>> org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
>>>
>>> org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$1244/197032188.call(Unknown
>>> Source)
>>>
>>> io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
>>>
>>> io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
>>>
>>> io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
>>> io.undertow.server.Connectors.executeRootHandler(Connectors.java:326)
>>> io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:812)
>>>
>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>>>
>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>>> java.lang.Thread.run(Thread.java:748)
>>>
>>> Repeating over and over ... Just before is
>>>
>>> 11:26:08,882 WARN  [org.keycloak.events] (default task-166)
>>> type=CODE_TO_TOKEN_ERROR, realmId=XXX, clientId=XXXX, userId=null,
>>> ipAddress=XXXXXXXXXX , error=invalid_code, grant_type=authorization_code,
>>> code_id=XXXXXXXX , client_auth_method=client-secret
>>> 11:30:04,172 WARN  [org.keycloak.services.managers.AuthenticationManager]
>>> (default task-100) Some clients have been not been logged out for user
>>> XXXXXXXXXXXXXXXXXXX   in hod-ci realm: XXXXX
>>> 11:30:04,203 WARN  [org.keycloak.events] (default task-92)
>>> type=IDENTITY_PROVIDER_LOGIN_ERROR, realmId=HOD-CI, clientId=null,
>>> userId=null, ipAddress=213.251.23.186, error=expired_code,
>>> identity_provider=O365, restart_after_timeout=true
>>> 11:38:13,851 WARN
>>> [org.keycloak.forms.login.freemarker.model.ProfileBean]
>>> (default task-88) There are more values for attribute 'group' of user
>>> 'XXXX\XXXXXX' . Will display just first value
>>> 11:43:37,370 WARN  [org.keycloak.events] (default task-36)
>>> type=LOGIN_ERROR, realmId=lev, clientId=lev-web, userId=null,
>>> ipAddress=XXXXXXXX, error=user_not_found, auth_method=openid-connect,
>>> auth_type=code, redirect_uri=
>>> https://lev.homeoffice.gov.uk/oauth/callback,
>>> code_id=5a08f532-1051-4805-8dd6-d71362303521, username=XXXXXXXXX
>>> 11:47:01,018 WARN  [com.arjuna.ats.arjuna] (Transaction Reaper)
>>> ARJUNA012117: TransactionReaper::check timeout for TX
>>> 0:ffff0a0a8b0a:-6d4f7aec:5b0ef057:46efe0 in state  RUN
>>> 11:47:01,019 WARN  [com.arjuna.ats.arjuna] (Transaction Reaper Worker 0)
>>> ARJUNA012095: Abort of action id 0:ffff0a0a8b0a:-6d4f7aec:5b0ef057:46efe0
>>> invoked while multiple threads active within it.
>>> 11:47:01,022 WARN  [com.arjuna.ats.arjuna] (Transaction Reaper Worker 0)
>>> ARJUNA012381: Action id 0:ffff0a0a8b0a:-6d4f7aec:5b0ef057:46efe0
>>> completed
>>> with multiple threads - thread default task-165 was in progress with
>>> sun.misc.Unsafe.park(Native Method)
>>> java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>>>
>>> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
>>> org.apache.http.pool.PoolEntryFuture.await(PoolEntryFuture.java:138)
>>>
>>> org.apache.http.pool.AbstractConnPool.getPoolEntryBlocking(AbstractConnPool.java:306)
>>>
>>> org.apache.http.pool.AbstractConnPool.access$000(AbstractConnPool.java:64)
>>>
>>> org.apache.http.pool.AbstractConnPool$2.getPoolEntry(AbstractConnPool.java:192)
>>>
>>> org.apache.http.pool.AbstractConnPool$2.getPoolEntry(AbstractConnPool.java:185)
>>> org.apache.http.pool.PoolEntryFuture.get(PoolEntryFuture.java:107)
>>>
>>> org.apache.http.impl.conn.PoolingHttpClientConnectionManager.leaseConnection(PoolingHttpClientConnectionManager.java:276)
>>>
>>> org.apache.http.impl.conn.PoolingHttpClientConnectionManager$1.get(PoolingHttpClientConnectionManager.java:263)
>>>
>>> org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:190)
>>>
>>> org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184)
>>> org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88)
>>>
>>> org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
>>>
>>> org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184)
>>>
>>> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
>>>
>>> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:107)
>>>
>>> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:55)
>>>
>>> org.keycloak.broker.provider.util.SimpleHttp.makeRequest(SimpleHttp.java:185)
>>>
>>> org.keycloak.broker.provider.util.SimpleHttp.asResponse(SimpleHttp.java:154)
>>>
>>> org.keycloak.broker.provider.util.SimpleHttp.asString(SimpleHttp.java:146)
>>>
>>> org.keycloak.broker.oidc.AbstractOAuth2IdentityProvider$Endpoint.authResponse(AbstractOAuth2IdentityProvider.java:397)
>>> sun.reflect.GeneratedMethodAccessor994.invoke(Unknown Source)
>>>
>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>> java.lang.reflect.Method.invoke(Method.java:498)
>>>
>>> org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:140)
>>>
>>> org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295)
>>>
>>> org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249)
>>>
>>> org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:138)
>>>
>>> org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:107)
>>>
>>> org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:133)
>>>
>>> org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:101)
>>>
>>> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:406)
>>>
>>> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:213)
>>>
>>> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:228)
>>>
>>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
>>>
>>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
>>> javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
>>>
>>> io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
>>>
>>> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
>>>
>>> org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:90)
>>> io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
>>>
>>> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
>>>
>>> io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
>>>
>>> io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
>>>
>>> io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
>>>
>>> org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
>>>
>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>>>
>>> io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
>>>
>>> io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
>>>
>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>>>
>>> io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
>>>
>>> io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
>>>
>>> io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
>>>
>>> io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
>>>
>>> io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
>>>
>>> io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
>>>
>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>>>
>>> org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
>>>
>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>>>
>>> org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
>>>
>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>>>
>>> io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
>>>
>>> io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
>>>
>>> io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
>>>
>>> io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
>>>
>>> io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
>>>
>>> io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
>>>
>>> org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
>>>
>>> org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction$$Lambda$1243/578097420.call(Unknown
>>> Source)
>>>
>>> org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
>>>
>>> org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$1244/197032188.call(Unknown
>>> Source)
>>>
>>> org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
>>>
>>> org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$1244/197032188.call(Unknown
>>> Source)
>>>
>>> org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
>>>
>>> org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$1244/197032188.call(Unknown
>>> Source)
>>>
>>> org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
>>>
>>> org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$1244/197032188.call(Unknown
>>> Source)
>>>
>>> io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
>>>
>>> io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
>>>
>>> io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
>>> io.undertow.server.Connectors.executeRootHandler(Connectors.java:326)
>>> io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:812)
>>>
>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>>>
>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>>> java.lang.Thread.run(Thread.java:748)
>>>
>>> Rohith
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>

From slaskawi at redhat.com  Tue Jul 10 09:36:12 2018
From: slaskawi at redhat.com (Sebastian Laskawiec)
Date: Tue, 10 Jul 2018 15:36:12 +0200
Subject: [keycloak-dev] Outage Issue
In-Reply-To: <CA+AP+fNvTovHB9UqUPAFd9TwJh5o=+s1-Awtn99yuhUMCNqseA@mail.gmail.com>
References: <CA+AP+fOJJ1hSpEFuiikmiVyoo=NWzh5F8aL=Ni=WDdsDa8Dkbw@mail.gmail.com>
	<CAA9R9O6AVP9x92zkFtiTARHKntNzun-7AgO1ZhjEL4qAgf1Vbg@mail.gmail.com>
	<CA+AP+fNhVi7hLmuSqXRmSURnZnynT+AWxG++2O7A4sQ6HFOfDQ@mail.gmail.com>
	<CA+AP+fNvTovHB9UqUPAFd9TwJh5o=+s1-Awtn99yuhUMCNqseA@mail.gmail.com>
Message-ID: <CAA9R9O6B8PgMF0vfzU2Nbd-19Z2VbMWAtdHBwr9n8oTCDbgm6w@mail.gmail.com>

I can't tell for sure but this might be related.

I already asked Wildfly folks to enhance this in Transaction Subsystem [1].
I hope it will get implemented soon and it will propagate into other
WF-based projects. In the meantime, please add a node identifier to the
transaction subsystem. If you're using this in Kubernetes/OpenShift, you
might use a hostname. If not - please use anything that is unique.

[1] http://lists.jboss.org/pipermail/wildfly-dev/2018-May/006516.html

On Tue, Jul 10, 2018 at 3:17 PM gambol <gambol99 at gmail.com> wrote:

> I did notice this morning the following warning on startup
>
> "The node-identifier attribute on the /subsystem=transactions is set to
> the default value. This is a danger for environments running multiple
> servers. Please make sure the attribute value is unique"
>
> Sound related??
>
> Rohith
>
>
>
> On Fri, Jun 29, 2018 at 10:50 AM gambol <gambol99 at gmail.com> wrote:
>
>> Hi Sebastian
>>
>> The keycloak version is 3.4.3.Final though we've also experienced the
>> issue on 3.1 as well.
>>
>> Next time, though I hope there won't be a next time :-) .. I'll grab a
>> thread dump and running transactions
>>
>> Rohith
>>
>> On Wed, Jun 27, 2018 at 10:57 AM Sebastian Laskawiec <slaskawi at redhat.com>
>> wrote:
>>
>>> From your description and the logs I guess it might be a problem with
>>> some transaction.
>>>
>>> Would you be able to tell us more about the Keycloak version you're
>>> running? Also, a Thread dump would be helpful and you might investigate if
>>> there are any long running transactions in the DB [1].
>>>
>>> Thanks,
>>> Sebastian
>>>
>>> [1]
>>> https://www.psce.com/en/blog/2015/01/22/tracking-mysql-query-history-in-long-running-transactions/
>>>
>>> On Thu, Jun 21, 2018 at 3:45 PM gambol <gambol99 at gmail.com> wrote:
>>>
>>>> Hiya
>>>>
>>>> I was wondering if anyone has come across this before. We have Keycloak
>>>> running in a kubernetes cluster, a mysql RDS, and standalone-ha setup
>>>> using
>>>> two gossip servers, each running behind a kube service and passed in via
>>>> environment variables
>>>>
>>>> <protocol type="TCPGOSSIP">
>>>>   <property name="initial_hosts">${env.GOSSIP_ROUTER_HOST}</property>
>>>> </protocol>
>>>>
>>>> Cluster appears to work fine, a new node added makes a change to
>>>> topology
>>>> and so forth. We do however out of the blue get the following error on
>>>> occasion, every couple of weeks... Shortly after the rest of the
>>>> replicas
>>>> become affected, the health check on the /auth fails and or login
>>>> attempts
>>>> begin to timeout .. At present the only solution is to completely cycle
>>>> the
>>>> cluster.
>>>>
>>>> 13:07:52,451 WARN  [com.arjuna.ats.arjuna] (Transaction Reaper Worker 0)
>>>> ARJUNA012108: CheckedAction::check - atomic action
>>>> 0:ffff0a0a8b0a:-6d4f7aec:5b0ef057:47876e aborting with 1 threads active!
>>>> 13:07:52,451 WARN
>>>>
>>>> [org.hibernate.resource.transaction.backend.jta.internal.synchronization.SynchronizationCallbackCoordinatorTrackingImpl]
>>>> (Transaction Reaper Worker 0) HHH000451: Transaction afterCompletion
>>>> called
>>>> by a background thread; delaying afterCompletion processing until the
>>>> original thread can handle it. [status=4]
>>>> 13:07:52,451 WARN  [com.arjuna.ats.arjuna] (Transaction Reaper Worker 0)
>>>> ARJUNA012121: TransactionReaper::doCancellations worker
>>>> Thread[Transaction
>>>> Reaper Worker 0,5,main] successfully canceled TX
>>>> 0:ffff0a0a8b0a:-6d4f7aec:5b0ef057:47876e
>>>> 13:07:55,475 WARN  [com.arjuna.ats.arjuna] (Transaction Reaper)
>>>> ARJUNA012117: TransactionReaper::check timeout for TX
>>>> 0:ffff0a0a8b0a:-6d4f7aec:5b0ef057:4787b9 in state  RUN
>>>> 13:07:55,476 WARN  [com.arjuna.ats.arjuna] (Transaction Reaper Worker 0)
>>>> ARJUNA012095: Abort of action id
>>>> 0:ffff0a0a8b0a:-6d4f7aec:5b0ef057:4787b9
>>>> invoked while multiple threads active within it.
>>>> 13:07:55,480 WARN  [com.arjuna.ats.arjuna] (Transaction Reaper Worker 0)
>>>> ARJUNA012381: Action id 0:ffff0a0a8b0a:-6d4f7aec:5b0ef057:4787b9
>>>> completed
>>>> with multiple threads - thread default task-64 was in progress with
>>>> sun.misc.Unsafe.park(Native Method)
>>>> java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>>>>
>>>> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
>>>> org.apache.http.pool.PoolEntryFuture.await(PoolEntryFuture.java:138)
>>>>
>>>> org.apache.http.pool.AbstractConnPool.getPoolEntryBlocking(AbstractConnPool.java:306)
>>>>
>>>> org.apache.http.pool.AbstractConnPool.access$000(AbstractConnPool.java:64)
>>>>
>>>> org.apache.http.pool.AbstractConnPool$2.getPoolEntry(AbstractConnPool.java:192)
>>>>
>>>> org.apache.http.pool.AbstractConnPool$2.getPoolEntry(AbstractConnPool.java:185)
>>>> org.apache.http.pool.PoolEntryFuture.get(PoolEntryFuture.java:107)
>>>>
>>>> org.apache.http.impl.conn.PoolingHttpClientConnectionManager.leaseConnection(PoolingHttpClientConnectionManager.java:276)
>>>>
>>>> org.apache.http.impl.conn.PoolingHttpClientConnectionManager$1.get(PoolingHttpClientConnectionManager.java:263)
>>>>
>>>> org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:190)
>>>>
>>>> org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184)
>>>> org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88)
>>>>
>>>> org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
>>>>
>>>> org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184)
>>>>
>>>> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
>>>>
>>>> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:107)
>>>>
>>>> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:55)
>>>>
>>>> org.keycloak.broker.provider.util.SimpleHttp.makeRequest(SimpleHttp.java:185)
>>>>
>>>> org.keycloak.broker.provider.util.SimpleHttp.asResponse(SimpleHttp.java:154)
>>>>
>>>> org.keycloak.broker.provider.util.SimpleHttp.asString(SimpleHttp.java:146)
>>>>
>>>> org.keycloak.broker.oidc.AbstractOAuth2IdentityProvider$Endpoint.authResponse(AbstractOAuth2IdentityProvider.java:397)
>>>> sun.reflect.GeneratedMethodAccessor994.invoke(Unknown Source)
>>>>
>>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>> java.lang.reflect.Method.invoke(Method.java:498)
>>>>
>>>> org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:140)
>>>>
>>>> org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295)
>>>>
>>>> org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249)
>>>>
>>>> org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:138)
>>>>
>>>> org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:107)
>>>>
>>>> org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:133)
>>>>
>>>> org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:101)
>>>>
>>>> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:406)
>>>>
>>>> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:213)
>>>>
>>>> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:228)
>>>>
>>>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
>>>>
>>>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
>>>> javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
>>>>
>>>> io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
>>>>
>>>> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
>>>>
>>>> org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:90)
>>>> io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
>>>>
>>>> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
>>>>
>>>> io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
>>>>
>>>> io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
>>>>
>>>> io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
>>>>
>>>> org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
>>>>
>>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>>>>
>>>> io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
>>>>
>>>> io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
>>>>
>>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>>>>
>>>> io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
>>>>
>>>> io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
>>>>
>>>> io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
>>>>
>>>> io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
>>>>
>>>> io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
>>>>
>>>> io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
>>>>
>>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>>>>
>>>> org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
>>>>
>>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>>>>
>>>> org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
>>>>
>>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>>>>
>>>> io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
>>>>
>>>> io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
>>>>
>>>> io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
>>>>
>>>> io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
>>>>
>>>> io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
>>>>
>>>> io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
>>>>
>>>> org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
>>>>
>>>> org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction$$Lambda$1243/578097420.call(Unknown
>>>> Source)
>>>>
>>>> org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
>>>>
>>>> org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$1244/197032188.call(Unknown
>>>> Source)
>>>>
>>>> org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
>>>>
>>>> org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$1244/197032188.call(Unknown
>>>> Source)
>>>>
>>>> org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
>>>>
>>>> org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$1244/197032188.call(Unknown
>>>> Source)
>>>>
>>>> org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
>>>>
>>>> org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$1244/197032188.call(Unknown
>>>> Source)
>>>>
>>>> io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
>>>>
>>>> io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
>>>>
>>>> io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
>>>> io.undertow.server.Connectors.executeRootHandler(Connectors.java:326)
>>>> io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:812)
>>>>
>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>>>>
>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>>>> java.lang.Thread.run(Thread.java:748)
>>>>
>>>> Repeating over and over ... Just before is
>>>>
>>>> 11:26:08,882 WARN  [org.keycloak.events] (default task-166)
>>>> type=CODE_TO_TOKEN_ERROR, realmId=XXX, clientId=XXXX, userId=null,
>>>> ipAddress=XXXXXXXXXX , error=invalid_code,
>>>> grant_type=authorization_code,
>>>> code_id=XXXXXXXX , client_auth_method=client-secret
>>>> 11:30:04,172 WARN
>>>> [org.keycloak.services.managers.AuthenticationManager]
>>>> (default task-100) Some clients have been not been logged out for user
>>>> XXXXXXXXXXXXXXXXXXX   in hod-ci realm: XXXXX
>>>> 11:30:04,203 WARN  [org.keycloak.events] (default task-92)
>>>> type=IDENTITY_PROVIDER_LOGIN_ERROR, realmId=HOD-CI, clientId=null,
>>>> userId=null, ipAddress=213.251.23.186, error=expired_code,
>>>> identity_provider=O365, restart_after_timeout=true
>>>> 11:38:13,851 WARN
>>>> [org.keycloak.forms.login.freemarker.model.ProfileBean]
>>>> (default task-88) There are more values for attribute 'group' of user
>>>> 'XXXX\XXXXXX' . Will display just first value
>>>> 11:43:37,370 WARN  [org.keycloak.events] (default task-36)
>>>> type=LOGIN_ERROR, realmId=lev, clientId=lev-web, userId=null,
>>>> ipAddress=XXXXXXXX, error=user_not_found, auth_method=openid-connect,
>>>> auth_type=code, redirect_uri=
>>>> https://lev.homeoffice.gov.uk/oauth/callback,
>>>> code_id=5a08f532-1051-4805-8dd6-d71362303521, username=XXXXXXXXX
>>>> 11:47:01,018 WARN  [com.arjuna.ats.arjuna] (Transaction Reaper)
>>>> ARJUNA012117: TransactionReaper::check timeout for TX
>>>> 0:ffff0a0a8b0a:-6d4f7aec:5b0ef057:46efe0 in state  RUN
>>>> 11:47:01,019 WARN  [com.arjuna.ats.arjuna] (Transaction Reaper Worker 0)
>>>> ARJUNA012095: Abort of action id
>>>> 0:ffff0a0a8b0a:-6d4f7aec:5b0ef057:46efe0
>>>> invoked while multiple threads active within it.
>>>> 11:47:01,022 WARN  [com.arjuna.ats.arjuna] (Transaction Reaper Worker 0)
>>>> ARJUNA012381: Action id 0:ffff0a0a8b0a:-6d4f7aec:5b0ef057:46efe0
>>>> completed
>>>> with multiple threads - thread default task-165 was in progress with
>>>> sun.misc.Unsafe.park(Native Method)
>>>> java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>>>>
>>>> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
>>>> org.apache.http.pool.PoolEntryFuture.await(PoolEntryFuture.java:138)
>>>>
>>>> org.apache.http.pool.AbstractConnPool.getPoolEntryBlocking(AbstractConnPool.java:306)
>>>>
>>>> org.apache.http.pool.AbstractConnPool.access$000(AbstractConnPool.java:64)
>>>>
>>>> org.apache.http.pool.AbstractConnPool$2.getPoolEntry(AbstractConnPool.java:192)
>>>>
>>>> org.apache.http.pool.AbstractConnPool$2.getPoolEntry(AbstractConnPool.java:185)
>>>> org.apache.http.pool.PoolEntryFuture.get(PoolEntryFuture.java:107)
>>>>
>>>> org.apache.http.impl.conn.PoolingHttpClientConnectionManager.leaseConnection(PoolingHttpClientConnectionManager.java:276)
>>>>
>>>> org.apache.http.impl.conn.PoolingHttpClientConnectionManager$1.get(PoolingHttpClientConnectionManager.java:263)
>>>>
>>>> org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:190)
>>>>
>>>> org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184)
>>>> org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88)
>>>>
>>>> org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
>>>>
>>>> org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184)
>>>>
>>>> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
>>>>
>>>> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:107)
>>>>
>>>> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:55)
>>>>
>>>> org.keycloak.broker.provider.util.SimpleHttp.makeRequest(SimpleHttp.java:185)
>>>>
>>>> org.keycloak.broker.provider.util.SimpleHttp.asResponse(SimpleHttp.java:154)
>>>>
>>>> org.keycloak.broker.provider.util.SimpleHttp.asString(SimpleHttp.java:146)
>>>>
>>>> org.keycloak.broker.oidc.AbstractOAuth2IdentityProvider$Endpoint.authResponse(AbstractOAuth2IdentityProvider.java:397)
>>>> sun.reflect.GeneratedMethodAccessor994.invoke(Unknown Source)
>>>>
>>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>> java.lang.reflect.Method.invoke(Method.java:498)
>>>>
>>>> org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:140)
>>>>
>>>> org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295)
>>>>
>>>> org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249)
>>>>
>>>> org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:138)
>>>>
>>>> org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:107)
>>>>
>>>> org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:133)
>>>>
>>>> org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:101)
>>>>
>>>> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:406)
>>>>
>>>> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:213)
>>>>
>>>> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:228)
>>>>
>>>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
>>>>
>>>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
>>>> javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
>>>>
>>>> io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
>>>>
>>>> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
>>>>
>>>> org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:90)
>>>> io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
>>>>
>>>> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
>>>>
>>>> io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
>>>>
>>>> io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
>>>>
>>>> io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
>>>>
>>>> org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
>>>>
>>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>>>>
>>>> io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
>>>>
>>>> io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
>>>>
>>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>>>>
>>>> io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
>>>>
>>>> io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
>>>>
>>>> io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
>>>>
>>>> io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
>>>>
>>>> io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
>>>>
>>>> io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
>>>>
>>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>>>>
>>>> org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
>>>>
>>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>>>>
>>>> org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
>>>>
>>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>>>>
>>>> io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
>>>>
>>>> io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
>>>>
>>>> io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
>>>>
>>>> io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
>>>>
>>>> io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
>>>>
>>>> io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
>>>>
>>>> org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
>>>>
>>>> org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction$$Lambda$1243/578097420.call(Unknown
>>>> Source)
>>>>
>>>> org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
>>>>
>>>> org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$1244/197032188.call(Unknown
>>>> Source)
>>>>
>>>> org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
>>>>
>>>> org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$1244/197032188.call(Unknown
>>>> Source)
>>>>
>>>> org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
>>>>
>>>> org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$1244/197032188.call(Unknown
>>>> Source)
>>>>
>>>> org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
>>>>
>>>> org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$1244/197032188.call(Unknown
>>>> Source)
>>>>
>>>> io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
>>>>
>>>> io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
>>>>
>>>> io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
>>>> io.undertow.server.Connectors.executeRootHandler(Connectors.java:326)
>>>> io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:812)
>>>>
>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>>>>
>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>>>> java.lang.Thread.run(Thread.java:748)
>>>>
>>>> Rohith
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>>

From hmlnarik at redhat.com  Wed Jul 11 05:38:50 2018
From: hmlnarik at redhat.com (Hynek Mlnarik)
Date: Wed, 11 Jul 2018 11:38:50 +0200
Subject: [keycloak-dev] Introduce lastModified property on UserModel
In-Reply-To: <9139119d072b40bd8d1ea1bd765bcda8@BOSKGEXC01.boskg.local>
References: <9139119d072b40bd8d1ea1bd765bcda8@BOSKGEXC01.boskg.local>
Message-ID: <CAMvXD=F+Af6P-eiEpU8-bUh3DZWBBQOqz9w2o5pvdwf4bruvFg@mail.gmail.com>

This is a difficult question we tackled some time ago within the team,
exactly with the same attribute. The User Storage SPI [1] would be affected
by this change, and at the same time the SPI is fully supported and should
be hence preserved as is. Hence we decided not to change it.

Can you just store it as a user attribute?

[1]
https://access.redhat.com/documentation/en-us/red_hat_single_sign-on/7.1/html/server_developer_guide/user-storage-spi#model_interfaces

On Tue, Jul 3, 2018 at 9:01 AM L?sch, Sebastian <
Sebastian.Loesch at governikus.de> wrote:

> Hi developers,
>
> we are currently setting up a project using keycloak and have the need to
> show the last mofication date of a user, similar to SCIM lastModified (see
> https://tools.ietf.org/html/rfc7643#section-3.1).
>
> What do you think adding this as a new property on UserModel?
>
> Best regards,
> Sebastian
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From hmlnarik at redhat.com  Wed Jul 11 05:43:56 2018
From: hmlnarik at redhat.com (Hynek Mlnarik)
Date: Wed, 11 Jul 2018 11:43:56 +0200
Subject: [keycloak-dev] SAML LogoutRequest (NameQualifer and
 SPNameQualifier missing)
In-Reply-To: <CAHvCgvzf6em_7rN5QPgT0CfjzYEk+4ws6e-gKKsp+fkR=zeY6A@mail.gmail.com>
References: <CAHvCgvzf6em_7rN5QPgT0CfjzYEk+4ws6e-gKKsp+fkR=zeY6A@mail.gmail.com>
Message-ID: <CAMvXD=GB4VPRxiXWG-TgddsXV2Gjk1i9rDkq2hth+caSJW9H1w@mail.gmail.com>

The optional attributes are not sent but I can see from the linked issue
that Shibboleth is unable to fix it on their side either. Feel free to file
an enhancement JIRA and continue the discussion there.

On Mon, Jul 9, 2018 at 3:45 PM Daniel Teixeira <ddtxra at gmail.com> wrote:

> Dear Keycloak dev team,
> Seems like Keycloak does not send the NameQualifer and SPNameQualifier in a
> SAML LogoutRequest. See this issue in Shibboleth:
> https://issues.shibboleth.net/jira/browse/IDP-1297
>
> Are you able to confirm that?
> Is it something you could fix in a next release?
>
>
> Thanks in advance,
> Daniel
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From ddtxra at gmail.com  Wed Jul 11 08:55:32 2018
From: ddtxra at gmail.com (Daniel Teixeira)
Date: Wed, 11 Jul 2018 14:55:32 +0200
Subject: [keycloak-dev] SAML LogoutRequest (NameQualifer and
 SPNameQualifier missing)
In-Reply-To: <CAMvXD=GB4VPRxiXWG-TgddsXV2Gjk1i9rDkq2hth+caSJW9H1w@mail.gmail.com>
References: <CAHvCgvzf6em_7rN5QPgT0CfjzYEk+4ws6e-gKKsp+fkR=zeY6A@mail.gmail.com>
	<CAMvXD=GB4VPRxiXWG-TgddsXV2Gjk1i9rDkq2hth+caSJW9H1w@mail.gmail.com>
Message-ID: <CAHvCgvxOYE2LunPCU2mg0BZb3aT9N6gGYf6oKav9kToCh7s+xA@mail.gmail.com>

Thank you Hynek,
Issue was created in here:
https://issues.jboss.org/browse/KEYCLOAK-7820


On Wed, Jul 11, 2018 at 11:43 AM, Hynek Mlnarik <hmlnarik at redhat.com> wrote:

> The optional attributes are not sent but I can see from the linked issue
> that Shibboleth is unable to fix it on their side either. Feel free to file
> an enhancement JIRA and continue the discussion there.
>
> On Mon, Jul 9, 2018 at 3:45 PM Daniel Teixeira <ddtxra at gmail.com> wrote:
>
>> Dear Keycloak dev team,
>> Seems like Keycloak does not send the NameQualifer and SPNameQualifier in
>> a
>> SAML LogoutRequest. See this issue in Shibboleth:
>> https://issues.shibboleth.net/jira/browse/IDP-1297
>>
>> Are you able to confirm that?
>> Is it something you could fix in a next release?
>>
>>
>> Thanks in advance,
>> Daniel
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>


-- 
Daniel Teixeira

From dt at acutus.pro  Wed Jul 11 13:29:31 2018
From: dt at acutus.pro (Dmitry Telegin)
Date: Wed, 11 Jul 2018 20:29:31 +0300
Subject: [keycloak-dev] Keycloak servlet filter adapter on OSGi,
	first impressions
Message-ID: <1531330171.2179.7.camel@acutus.pro>

Hi,

We are working on integrating Apache Sling with Keycloak (see my
posting from June 12). It was suggested that we'd stick to servlet
filter adapter as the most generic one (unlike Keycloak OSGi
adapter which is more of a JBoss Fuse adapter).

The first step was to convert keycloak-servlet-filter-adapter and
required keycloak-servlet-adapter-spi to OSGi bundles. This went OK,
I've just added OSGi bundling to the respective POMs. However there
were two major issues when deploying and running the code:

1. Bogus dependency on?org.apache.http.*

Several Keycloak modules the adapter depends on, namely?keycloak-authz-client and keycloak-adapter-core, declare bogus?"Import-Package: org.apache.http.*;version=4.5.2" dependency.

This comes from the following lines in the POM:

        <keycloak.osgi.import>
            org.keycloak.*;version="${project.version}",
            org.apache.http.*;version=${apache.httpcomponents.version},
            ...
        </keycloak.osgi.import>

org.apache.http.* is exported by org.apache.httpcomponents:httpcore-osgi, which uses its own versioning scheme (4.4.9 is the latest version ATM). Thus, deploying the bundle to OSGi runtime fails due to unsatisfied dependency.

Later, I've discovered there's keycloak-osgi-thirdparty bundle that provides required dependencies (however, they don't become less bogus because of that).

I'm OK with this workaround, but generally speaking, is keycloak-osgi-thirdparty still needed?
I've got an impression it was created at a time when not every dependency was available as OSGi bundle.

Current version of?keycloak-osgi-thirdparty contains merged httpclient and httpcore, which are available as org.apache.httpcomponents:httpclient-osgi and org.apache.httpcomponents:httpcore-osgi, respectively.

So to me it seems like a candidate for deprecation and removal. If so, the bogus dependency issue, obviously, should be tackled with first.

2. Split package org.keycloak.adapters.servlet

> In standard Java programming, packages are generally treated as
> split; the Java class path??approach merges all packages from
> different JAR files on the class path into one big??soup. This is
> anathema to OSGi?s modularization model, where packages are treated
> as atomic (that is, they can?t be split).

http://web.ist.utl.pt/ist162500/?p=65

In Keycloak, the package org.keycloak.adapters.servlet is split between
keycloak-servlet-adapter-spi and keycloak-servlet-filter-adapter. This
leads to seemingly inexplicable NoClassDefFoundError's, when e.g.
KeycloakOIDCFilter cannot find its neighbor OIDCServletHttpFacade. The
recipe provided by the above article (create dummy bundle, prohibit
direct imports etc.) is rather cumbersome, so I've just created
org.keycloak.adapters.servlet.spi package and moved there the two
classes from keycloak-servlet-adapter-spi.

After that, I was finally able to wire Keycloak filter to a test
servlet, and it worked pretty well. There was a redirect to Keycloak's
login screen, then redirect back, and the servlet was able to obtain
valid KeycloakPrincipal with JWT token.

To sum up, I'm eager to contribute changes required to make Keycloak
servlet filter adapter a valid and working OSGi bundle. That would
include OSGi bundling for two modules and split package refactoring.
The first issue (bogus deps) IMO should require further discussion.

Let me know what you think,

Dmitry Telegin
CTO, Acutus s.r.o.

From ddtxra at gmail.com  Wed Jul 11 14:19:03 2018
From: ddtxra at gmail.com (Daniel Teixeira)
Date: Wed, 11 Jul 2018 20:19:03 +0200
Subject: [keycloak-dev] Spring Security Adapter resource_access roles missing
Message-ID: <CAHvCgvzE77zyZ2xKpGowib0OwvTfN-nmvL7o3HwRx3W1scV_ug@mail.gmail.com>

Hello,
I have noticed that roles belonging to realm_access are present in the
Authentication object. But roles belonging to other client applications
(resource_access) are missing in the Authentication Java object.

Would it make sense to include them?

I am not sure if it makes sense to change it
in KeycloakAuthenticationProvider
https://github.com/keycloak/keycloak/blob/master/adapters/oidc/spring-security/src/main/java/org/keycloak/adapters/springsecurity/authentication/KeycloakAuthenticationProvider.java#L51

Or when creating the SimpleKeycloakAccount using AdapterUtils?
https://github.com/keycloak/keycloak/blob/master/adapters/oidc/adapter-core/src/main/java/org/keycloak/adapters/AdapterUtils.java#L52

Cheers,
Daniel

From h2-wada at nri.co.jp  Thu Jul 12 02:16:50 2018
From: h2-wada at nri.co.jp (Hiroyuki Wada)
Date: Thu, 12 Jul 2018 15:16:50 +0900
Subject: [keycloak-dev] Support for updating user with credentials in admin
	endpoints
Message-ID: <5B46F252.5090208@nri.co.jp>

Hello,

Currently the Admin REST API ignores credentials when updating the user.
I found the similar issue & discussion in the following links.
It was accepted but it only supports creating method.

https://issues.jboss.org/browse/KEYCLOAK-5026
http://lists.jboss.org/pipermail/keycloak-dev/2017-June/009552.html

In our case, we'd like to update users profile including any credentials from 
an external ID system.
Could I send a pull request for supporting it?

Best Regards

-- 
Hiroyuki Wada
Nomura Research Institute, Ltd.
h2-wada at nri.co.jp

--------------------------------------------------------------------
PLEASE READ:This e-mail is confidential and intended for
the named recipient only. If you are not an intended recipient,
please notify the sender and delete this e-mail.
--------------------------------------------------------------------

From hmlnarik at redhat.com  Thu Jul 12 05:10:20 2018
From: hmlnarik at redhat.com (Hynek Mlnarik)
Date: Thu, 12 Jul 2018 11:10:20 +0200
Subject: [keycloak-dev] Keycloak servlet filter adapter on OSGi,
	first impressions
In-Reply-To: <1531330171.2179.7.camel@acutus.pro>
References: <1531330171.2179.7.camel@acutus.pro>
Message-ID: <CAMvXD=HuB2G+AhXwVj42W8KE5h_TnTN5k43L6uiz3hw8C7jw4g@mail.gmail.com>

Hi Dmitri,

thank you for the updates.

The 1. (dependencies on Apache HTTP Components) has been resolved in the
latest master already and the -thirdparty module has been removed.
Hopefully this addresses your concerns completely.

Ad 2. we have taken approach with OSGi fragment when resolving similar
situation with server-specific implementation, see e.g. [1]. This is
preferrable to moving classes to different packages. Could you take this
approach?

[1]
https://github.com/keycloak/keycloak/blob/master/adapters/spi/undertow-adapter-spi/pom.xml#L119


On Wed, Jul 11, 2018 at 7:36 PM Dmitry Telegin <dt at acutus.pro> wrote:

> Hi,
>
> We are working on integrating Apache Sling with Keycloak (see my
> posting from June 12). It was suggested that we'd stick to servlet
> filter adapter as the most generic one (unlike Keycloak OSGi
> adapter which is more of a JBoss Fuse adapter).
>
> The first step was to convert keycloak-servlet-filter-adapter and
> required keycloak-servlet-adapter-spi to OSGi bundles. This went OK,
> I've just added OSGi bundling to the respective POMs. However there
> were two major issues when deploying and running the code:
>
> 1. Bogus dependency on org.apache.http.*
>
> Several Keycloak modules the adapter depends on,
> namely keycloak-authz-client and keycloak-adapter-core, declare
> bogus "Import-Package: org.apache.http.*;version=4.5.2" dependency.
>
> This comes from the following lines in the POM:
>
>         <keycloak.osgi.import>
>             org.keycloak.*;version="${project.version}",
>             org.apache.http.*;version=${apache.httpcomponents.version},
>             ...
>         </keycloak.osgi.import>
>
> org.apache.http.* is exported by org.apache.httpcomponents:httpcore-osgi,
> which uses its own versioning scheme (4.4.9 is the latest version ATM).
> Thus, deploying the bundle to OSGi runtime fails due to unsatisfied
> dependency.
>
> Later, I've discovered there's keycloak-osgi-thirdparty bundle that
> provides required dependencies (however, they don't become less bogus
> because of that).
>
> I'm OK with this workaround, but generally speaking, is
> keycloak-osgi-thirdparty still needed?
> I've got an impression it was created at a time when not every dependency
> was available as OSGi bundle.
>
> Current version of keycloak-osgi-thirdparty contains merged httpclient and
> httpcore, which are available as org.apache.httpcomponents:httpclient-osgi
> and org.apache.httpcomponents:httpcore-osgi, respectively.
>
> So to me it seems like a candidate for deprecation and removal. If so, the
> bogus dependency issue, obviously, should be tackled with first.
>
> 2. Split package org.keycloak.adapters.servlet
>
> > In standard Java programming, packages are generally treated as
> > split; the Java class path  approach merges all packages from
> > different JAR files on the class path into one big  soup. This is
> > anathema to OSGi?s modularization model, where packages are treated
> > as atomic (that is, they can?t be split).
>
> http://web.ist.utl.pt/ist162500/?p=65
>
> In Keycloak, the package org.keycloak.adapters.servlet is split between
> keycloak-servlet-adapter-spi and keycloak-servlet-filter-adapter. This
> leads to seemingly inexplicable NoClassDefFoundError's, when e.g.
> KeycloakOIDCFilter cannot find its neighbor OIDCServletHttpFacade. The
> recipe provided by the above article (create dummy bundle, prohibit
> direct imports etc.) is rather cumbersome, so I've just created
> org.keycloak.adapters.servlet.spi package and moved there the two
> classes from keycloak-servlet-adapter-spi.
>
> After that, I was finally able to wire Keycloak filter to a test
> servlet, and it worked pretty well. There was a redirect to Keycloak's
> login screen, then redirect back, and the servlet was able to obtain
> valid KeycloakPrincipal with JWT token.
>
> To sum up, I'm eager to contribute changes required to make Keycloak
> servlet filter adapter a valid and working OSGi bundle. That would
> include OSGi bundling for two modules and split package refactoring.
> The first issue (bogus deps) IMO should require further discussion.
>
> Let me know what you think,
>
> Dmitry Telegin
> CTO, Acutus s.r.o.
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From thomas.darimont at googlemail.com  Thu Jul 12 05:35:43 2018
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Thu, 12 Jul 2018 11:35:43 +0200
Subject: [keycloak-dev] Support for updating user with credentials in
 admin endpoints
In-Reply-To: <5B46F252.5090208@nri.co.jp>
References: <5B46F252.5090208@nri.co.jp>
Message-ID: <CAK-7U1j3XxJZF9NBrSByh9O8HO0v_Ak7gNH0njRqPmKh77RCdQ@mail.gmail.com>

Hello,

you can change the password a user via the keycloak admin-client with the
resetPassword(...) method.
   userRessource.get(userId).resetPassword(passwordCred);
See:
https://gist.github.com/thomasdarimont/c4e739c5a319cf78a4cff3b87173a84b#file-keycloakadminclientexample-java-L94

Cheers,
Thomas

On Thu, Jul 12, 2018 at 8:18 AM Hiroyuki Wada <h2-wada at nri.co.jp> wrote:

> Hello,
>
> Currently the Admin REST API ignores credentials when updating the user.
> I found the similar issue & discussion in the following links.
> It was accepted but it only supports creating method.
>
> https://issues.jboss.org/browse/KEYCLOAK-5026
> http://lists.jboss.org/pipermail/keycloak-dev/2017-June/009552.html
>
> In our case, we'd like to update users profile including any credentials
> from
> an external ID system.
> Could I send a pull request for supporting it?
>
> Best Regards
>
> --
> Hiroyuki Wada
> Nomura Research Institute, Ltd.
> h2-wada at nri.co.jp
>
> --------------------------------------------------------------------
> PLEASE READ:This e-mail is confidential and intended for
> the named recipient only. If you are not an intended recipient,
> please notify the sender and delete this e-mail.
> --------------------------------------------------------------------
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From h2-wada at nri.co.jp  Thu Jul 12 06:13:32 2018
From: h2-wada at nri.co.jp (Hiroyuki Wada)
Date: Thu, 12 Jul 2018 19:13:32 +0900
Subject: [keycloak-dev] Support for updating user with credentials in
 admin endpoints
In-Reply-To: <CAK-7U1j3XxJZF9NBrSByh9O8HO0v_Ak7gNH0njRqPmKh77RCdQ@mail.gmail.com>
References: <5B46F252.5090208@nri.co.jp>
	<CAK-7U1j3XxJZF9NBrSByh9O8HO0v_Ak7gNH0njRqPmKh77RCdQ@mail.gmail.com>
Message-ID: <5B4729CC.4040801@nri.co.jp>

Hello,

Thanks for your comment.
I know we can use the reset-password endpoint for changing password, but
I want to update the user profile including credentials with single request.
Also current reset-password endpoint only supports 'password' type credential.
We also want to update other type credentials too.

Best Regards

On 2018/07/12 18:35, Thomas Darimont wrote:
> Hello,
>
> you can change the password a user via the keycloak admin-client with the
> resetPassword(...) method.
>     userRessource.get(userId).resetPassword(passwordCred);
> See:
> https://gist.github.com/thomasdarimont/c4e739c5a319cf78a4cff3b87173a84b#file-keycloakadminclientexample-java-L94
>
> Cheers,
> Thomas
>
> On Thu, Jul 12, 2018 at 8:18 AM Hiroyuki Wada <h2-wada at nri.co.jp> wrote:
>
>> Hello,
>>
>> Currently the Admin REST API ignores credentials when updating the user.
>> I found the similar issue & discussion in the following links.
>> It was accepted but it only supports creating method.
>>
>> https://issues.jboss.org/browse/KEYCLOAK-5026
>> http://lists.jboss.org/pipermail/keycloak-dev/2017-June/009552.html
>>
>> In our case, we'd like to update users profile including any credentials
>> from
>> an external ID system.
>> Could I send a pull request for supporting it?
>>
>> Best Regards
>>
>> --
>> Hiroyuki Wada
>> Nomura Research Institute, Ltd.
>> h2-wada at nri.co.jp
>>
>> --------------------------------------------------------------------
>> PLEASE READ:This e-mail is confidential and intended for
>> the named recipient only. If you are not an intended recipient,
>> please notify the sender and delete this e-mail.
>> --------------------------------------------------------------------
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>

-- 
Hiroyuki Wada
Nomura Research Institute, Ltd.
h2-wada at nri.co.jp

--------------------------------------------------------------------
PLEASE READ:This e-mail is confidential and intended for
the named recipient only. If you are not an intended recipient,
please notify the sender and delete this e-mail.
--------------------------------------------------------------------

From dt at acutus.pro  Thu Jul 12 20:24:01 2018
From: dt at acutus.pro (Dmitry Telegin)
Date: Fri, 13 Jul 2018 03:24:01 +0300
Subject: [keycloak-dev] Keycloak servlet filter adapter on OSGi,
 first impressions
In-Reply-To: <CAMvXD=HuB2G+AhXwVj42W8KE5h_TnTN5k43L6uiz3hw8C7jw4g@mail.gmail.com>
References: <1531330171.2179.7.camel@acutus.pro>
	<CAMvXD=HuB2G+AhXwVj42W8KE5h_TnTN5k43L6uiz3hw8C7jw4g@mail.gmail.com>
Message-ID: <1531441441.10591.3.camel@acutus.pro>

Hi Hynek,
Thanks for the OSGi fragment tip, it worked perfectly. Also glad to
hear the HTTP Components dependency issue has been resolved.
So OK for JIRA/PR for servlet filter adapter OSGi bundling? And, by the
way, should we document how to use this adapter on OSGi? Installing a
bundle is not sufficient, the filter should be registered with OSGi
HTTP Service, and there are at least two ways of doing it (via
BundleContext::registerService or via a @Component that extends the
filter class). What do you think?
Dmitry
On Thu, 2018-07-12 at 11:10 +0200, Hynek Mlnarik wrote:
> Hi Dmitri,
> thank you for the updates.
> 
> The 1. (dependencies on Apache HTTP Components) has been resolved in
> the latest master already and the -thirdparty module has been
> removed. Hopefully this addresses your concerns completely.
> 
> Ad 2. we have taken approach with OSGi fragment when resolving
> similar situation with server-specific implementation, see e.g. [1].
> This is preferrable to moving classes to different packages. Could
> you take this approach?
> 
> [1]?https://github.com/keycloak/keycloak/blob/master/adapters/spi/und
> ertow-adapter-spi/pom.xml#L119
> ?
> On Wed, Jul 11, 2018 at 7:36 PM Dmitry Telegin <dt at acutus.pro> wrote:
> > Hi,
> > 
> > 
> > 
> > We are working on integrating Apache Sling with Keycloak (see my
> > 
> > posting from June 12). It was suggested that we'd stick to servlet
> > 
> > filter adapter as the most generic one (unlike Keycloak OSGi
> > 
> > adapter which is more of a JBoss Fuse adapter).
> > 
> > 
> > 
> > The first step was to convert keycloak-servlet-filter-adapter and
> > 
> > required keycloak-servlet-adapter-spi to OSGi bundles. This went
> > OK,
> > 
> > I've just added OSGi bundling to the respective POMs. However there
> > 
> > were two major issues when deploying and running the code:
> > 
> > 
> > 
> > 1. Bogus dependency on?org.apache.http.*
> > 
> > 
> > 
> > Several Keycloak modules the adapter depends on, namely?keycloak-
> > authz-client and keycloak-adapter-core, declare bogus?"Import-
> > Package: org.apache.http.*;version=4.5.2" dependency.
> > 
> > 
> > 
> > This comes from the following lines in the POM:
> > 
> > 
> > 
> > ? ? ? ? <keycloak.osgi.import>
> > 
> > ? ? ? ? ? ? org.keycloak.*;version="${project.version}",
> > 
> > ? ? ? ? ? ?
> > org.apache.http.*;version=${apache.httpcomponents.version},
> > 
> > ? ? ? ? ? ? ...
> > 
> > ? ? ? ? </keycloak.osgi.import>
> > 
> > 
> > 
> > org.apache.http.* is exported by
> > org.apache.httpcomponents:httpcore-osgi, which uses its own
> > versioning scheme (4.4.9 is the latest version ATM). Thus,
> > deploying the bundle to OSGi runtime fails due to unsatisfied
> > dependency.
> > 
> > 
> > 
> > Later, I've discovered there's keycloak-osgi-thirdparty bundle that
> > provides required dependencies (however, they don't become less
> > bogus because of that).
> > 
> > 
> > 
> > I'm OK with this workaround, but generally speaking, is keycloak-
> > osgi-thirdparty still needed?
> > 
> > I've got an impression it was created at a time when not every
> > dependency was available as OSGi bundle.
> > 
> > 
> > 
> > Current version of?keycloak-osgi-thirdparty contains merged
> > httpclient and httpcore, which are available as
> > org.apache.httpcomponents:httpclient-osgi and
> > org.apache.httpcomponents:httpcore-osgi, respectively.
> > 
> > 
> > 
> > So to me it seems like a candidate for deprecation and removal. If
> > so, the bogus dependency issue, obviously, should be tackled with
> > first.
> > 
> > 
> > 
> > 2. Split package org.keycloak.adapters.servlet
> > 
> > 
> > 
> > > In standard Java programming, packages are generally treated as
> > 
> > > split; the Java class path??approach merges all packages from
> > 
> > > different JAR files on the class path into one big??soup. This is
> > 
> > > anathema to OSGi?s modularization model, where packages are
> > treated
> > 
> > > as atomic (that is, they can?t be split).
> > 
> > 
> > 
> > http://web.ist.utl.pt/ist162500/?p=65
> > 
> > 
> > 
> > In Keycloak, the package org.keycloak.adapters.servlet is split
> > between
> > 
> > keycloak-servlet-adapter-spi and keycloak-servlet-filter-adapter.
> > This
> > 
> > leads to seemingly inexplicable NoClassDefFoundError's, when e.g.
> > 
> > KeycloakOIDCFilter cannot find its neighbor OIDCServletHttpFacade.
> > The
> > 
> > recipe provided by the above article (create dummy bundle, prohibit
> > 
> > direct imports etc.) is rather cumbersome, so I've just created
> > 
> > org.keycloak.adapters.servlet.spi package and moved there the two
> > 
> > classes from keycloak-servlet-adapter-spi.
> > 
> > 
> > 
> > After that, I was finally able to wire Keycloak filter to a test
> > 
> > servlet, and it worked pretty well. There was a redirect to
> > Keycloak's
> > 
> > login screen, then redirect back, and the servlet was able to
> > obtain
> > 
> > valid KeycloakPrincipal with JWT token.
> > 
> > 
> > 
> > To sum up, I'm eager to contribute changes required to make
> > Keycloak
> > 
> > servlet filter adapter a valid and working OSGi bundle. That would
> > 
> > include OSGi bundling for two modules and split package
> > refactoring.
> > 
> > The first issue (bogus deps) IMO should require further discussion.
> > 
> > 
> > 
> > Let me know what you think,
> > 
> > 
> > 
> > Dmitry Telegin
> > 
> > CTO, Acutus s.r.o.
> > 
> > _______________________________________________
> > 
> > keycloak-dev mailing list
> > 
> > keycloak-dev at lists.jboss.org
> > 
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev

From hmlnarik at redhat.com  Fri Jul 13 09:36:23 2018
From: hmlnarik at redhat.com (Hynek Mlnarik)
Date: Fri, 13 Jul 2018 15:36:23 +0200
Subject: [keycloak-dev] Keycloak servlet filter adapter on OSGi,
	first impressions
In-Reply-To: <1531441441.10591.3.camel@acutus.pro>
References: <1531330171.2179.7.camel@acutus.pro>
	<CAMvXD=HuB2G+AhXwVj42W8KE5h_TnTN5k43L6uiz3hw8C7jw4g@mail.gmail.com>
	<1531441441.10591.3.camel@acutus.pro>
Message-ID: <CAMvXD=GX+1QnP7h6456Up2SgOMq=aL3zvZMnRZRHaKBavq1L+w@mail.gmail.com>

Excellent. JIRA + PR for OSGi bundling would be welcome. Re the
documentation, yes please, it will be necessary. It looks like the way you
would describe would be applicable to any OSGi-compliant container,
correct? Which OSGi release?

Thanks,

--Hynek

On Fri, Jul 13, 2018 at 2:24 AM Dmitry Telegin <dt at acutus.pro> wrote:

> Hi Hynek,
>
> Thanks for the OSGi fragment tip, it worked perfectly. Also glad to hear
> the HTTP Components dependency issue has been resolved.
>
> So OK for JIRA/PR for servlet filter adapter OSGi bundling? And, by the
> way, should we document how to use this adapter on OSGi? Installing a
> bundle is not sufficient, the filter should be registered with OSGi HTTP
> Service, and there are at least two ways of doing it (via
> BundleContext::registerService or via a @Component that extends the filter
> class). What do you think?
>
> Dmitry
>
> On Thu, 2018-07-12 at 11:10 +0200, Hynek Mlnarik wrote:
>
> Hi Dmitri,
>
> thank you for the updates.
>
> The 1. (dependencies on Apache HTTP Components) has been resolved in the
> latest master already and the -thirdparty module has been removed.
> Hopefully this addresses your concerns completely.
>
> Ad 2. we have taken approach with OSGi fragment when resolving similar
> situation with server-specific implementation, see e.g. [1]. This is
> preferrable to moving classes to different packages. Could you take this
> approach?
>
> [1]
> https://github.com/keycloak/keycloak/blob/master/adapters/spi/undertow-adapter-spi/pom.xml#L119
>
>
> On Wed, Jul 11, 2018 at 7:36 PM Dmitry Telegin <dt at acutus.pro> wrote:
>
> Hi,
>
> We are working on integrating Apache Sling with Keycloak (see my
> posting from June 12). It was suggested that we'd stick to servlet
> filter adapter as the most generic one (unlike Keycloak OSGi
> adapter which is more of a JBoss Fuse adapter).
>
> The first step was to convert keycloak-servlet-filter-adapter and
> required keycloak-servlet-adapter-spi to OSGi bundles. This went OK,
> I've just added OSGi bundling to the respective POMs. However there
> were two major issues when deploying and running the code:
>
> 1. Bogus dependency on org.apache.http.*
>
> Several Keycloak modules the adapter depends on,
> namely keycloak-authz-client and keycloak-adapter-core, declare
> bogus "Import-Package: org.apache.http.*;version=4.5.2" dependency.
>
> This comes from the following lines in the POM:
>
>         <keycloak.osgi.import>
>             org.keycloak.*;version="${project.version}",
>             org.apache.http.*;version=${apache.httpcomponents.version},
>             ...
>         </keycloak.osgi.import>
>
> org.apache.http.* is exported by org.apache.httpcomponents:httpcore-osgi,
> which uses its own versioning scheme (4.4.9 is the latest version ATM).
> Thus, deploying the bundle to OSGi runtime fails due to unsatisfied
> dependency.
>
> Later, I've discovered there's keycloak-osgi-thirdparty bundle that
> provides required dependencies (however, they don't become less bogus
> because of that).
>
> I'm OK with this workaround, but generally speaking, is
> keycloak-osgi-thirdparty still needed?
> I've got an impression it was created at a time when not every dependency
> was available as OSGi bundle.
>
> Current version of keycloak-osgi-thirdparty contains merged httpclient and
> httpcore, which are available as org.apache.httpcomponents:httpclient-osgi
> and org.apache.httpcomponents:httpcore-osgi, respectively.
>
> So to me it seems like a candidate for deprecation and removal. If so, the
> bogus dependency issue, obviously, should be tackled with first.
>
> 2. Split package org.keycloak.adapters.servlet
>
> > In standard Java programming, packages are generally treated as
> > split; the Java class path  approach merges all packages from
> > different JAR files on the class path into one big  soup. This is
> > anathema to OSGi?s modularization model, where packages are treated
> > as atomic (that is, they can?t be split).
>
> http://web.ist.utl.pt/ist162500/?p=65
>
> In Keycloak, the package org.keycloak.adapters.servlet is split between
> keycloak-servlet-adapter-spi and keycloak-servlet-filter-adapter. This
> leads to seemingly inexplicable NoClassDefFoundError's, when e.g.
> KeycloakOIDCFilter cannot find its neighbor OIDCServletHttpFacade. The
> recipe provided by the above article (create dummy bundle, prohibit
> direct imports etc.) is rather cumbersome, so I've just created
> org.keycloak.adapters.servlet.spi package and moved there the two
> classes from keycloak-servlet-adapter-spi.
>
> After that, I was finally able to wire Keycloak filter to a test
> servlet, and it worked pretty well. There was a redirect to Keycloak's
> login screen, then redirect back, and the servlet was able to obtain
> valid KeycloakPrincipal with JWT token.
>
> To sum up, I'm eager to contribute changes required to make Keycloak
> servlet filter adapter a valid and working OSGi bundle. That would
> include OSGi bundling for two modules and split package refactoring.
> The first issue (bogus deps) IMO should require further discussion.
>
> Let me know what you think,
>
> Dmitry Telegin
> CTO, Acutus s.r.o.
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>

From ebenzacar at gmail.com  Fri Jul 13 14:10:42 2018
From: ebenzacar at gmail.com (Eric B)
Date: Fri, 13 Jul 2018 14:10:42 -0400
Subject: [keycloak-dev] Any reason why the DefaultBruteForceProtector
	success() method is private?
Message-ID: <CA+T+PjGiZEY2CsiVqYV13tNh1dQFX0NRcVjcPom-2uTCab16RA@mail.gmail.com>

Hi.

I'm looking at producing an extended implementation of the
DefaultBruteForceProtector implementation, but for some reason the
success() method in the class is the only private method which is
prohibiting me of simply extending the DefaultBruteForceProtector class and
adding some additional logic to the methods.

Is there a particular reason why the visibility for these methods are as
follows?
- public void failure()
- private void success()

Why is success() private, whereas failure is public()?  Was this just an
oversight?  Can sucess() be changed to public?

Thanks,

Eric

From torsten.juergeleit at gmail.com  Sun Jul 15 17:03:00 2018
From: torsten.juergeleit at gmail.com (=?utf-8?Q?J=C3=BCrgeleit_Torsten?=)
Date: Sun, 15 Jul 2018 23:03:00 +0200
Subject: [keycloak-dev] New feature implementation: Namespace support for
 LDAP group mapper by storing the groups synced from LDAP provider within a
 customizable path
Message-ID: <D2C0F8EE-C28A-4703-9880-9C647CA230B4@gmail.com>

Hi Keycloak Team,

we?re using MSAD group memberships for provisioning roles in different applications (JIRA, SonarQube, GitLab, ?). The required information (application, project, role) is encoded in the MSAD group name via patterns like ?<prefix>_<app>_<project>_<role>?, e.g. ?G_APPL_JIRA_PR1_Developer?. Currently in every application the corresponding MSAD group memberships are retrieved via an LDAP query (with filter using the application-specific prefix) and stored the application?s internal user access management system.

Now we would like to introduce Keycloak as the central IdP for these applications. But currently Keycloak only supports syncing groups from LDAP federation provider as top-level KC groups. This approach has some limitations:
If using multiple group mappers then there?s no way to isolate the KC groups synched by each group mapper.
If the option "Drop non-existing groups during sync? is activated then all KC groups (including the manually created ones) are deleted.
There?s no way to inherit roles from a parent KC group.

Therefore I would like to propose adding some kind of namespace support to GroupLDAPStorageMapper. This could be implemented by an additional config property for a Keycloak group path where the groups synched from LDAP provider are stored (defaults to ?/? for top-level groups).

An implementation of this approach can be found in commit baa76c6 <https://github.com/tjuerge/keycloak/commit/baa76c6d591a0be1b16612470030f675b41ac93c> of my fork. To test this implementation modified copies of existing integration tests are used (here the groups are stored within the path "/Applications/App1? instead of ?/?). 

WDYT?

Cheers,
Torsten

From dt at acutus.pro  Sun Jul 15 20:54:07 2018
From: dt at acutus.pro (Dmitry Telegin)
Date: Mon, 16 Jul 2018 03:54:07 +0300
Subject: [keycloak-dev] Keycloak servlet filter adapter on OSGi,
 first impressions
In-Reply-To: <CAMvXD=GX+1QnP7h6456Up2SgOMq=aL3zvZMnRZRHaKBavq1L+w@mail.gmail.com>
References: <1531330171.2179.7.camel@acutus.pro>
	<CAMvXD=HuB2G+AhXwVj42W8KE5h_TnTN5k43L6uiz3hw8C7jw4g@mail.gmail.com>
	<1531441441.10591.3.camel@acutus.pro>
	<CAMvXD=GX+1QnP7h6456Up2SgOMq=aL3zvZMnRZRHaKBavq1L+w@mail.gmail.com>
Message-ID: <1531702447.11875.1.camel@acutus.pro>

Hi,
https://issues.jboss.org/browse/KEYCLOAK-7858https://github.com/keycloa
k/keycloak/pull/5383
As for documentation, I'm experienced in technical writing, however
I'll still need supervisor/reviewer since I'll be contributing to
Keycloak docs for the first time.
Idea: we could have (one day) something kind of "OSGi extras" for
servlet filter adapter, containing bundle activator to install a filter
+ config resolver that would integrate with OSGi Config Admin Service.
WDYT?
Dmitry
On Fri, 2018-07-13 at 15:36 +0200, Hynek Mlnarik wrote:
> Excellent. JIRA?+ PR for OSGi bundling would be welcome. Re the
> documentation, yes please, it will be necessary. It looks like the
> way you would describe would be applicable to any OSGi-compliant
> container, correct? Which OSGi release?
> Thanks,
> 
> --Hynek
> On Fri, Jul 13, 2018 at 2:24 AM Dmitry Telegin <dt at acutus.pro> wrote:
> > Hi Hynek,
> > Thanks for the OSGi fragment tip, it worked perfectly. Also glad to
> > hear the HTTP Components dependency issue has been resolved.
> > So OK for JIRA/PR for servlet filter adapter OSGi bundling? And, by
> > the way, should we document how to use this adapter on OSGi?
> > Installing a bundle is not sufficient, the filter should be
> > registered with OSGi HTTP Service, and there are at least two ways
> > of doing it (via BundleContext::registerService or via a @Component
> > that extends the filter class). What do you think?
> > Dmitry
> > On Thu, 2018-07-12 at 11:10 +0200, Hynek Mlnarik wrote:
> > > Hi Dmitri,
> > > thank you for the updates.
> > > 
> > > The 1. (dependencies on Apache HTTP Components) has been resolved
> > > in the latest master already and the -thirdparty module has been
> > > removed. Hopefully this addresses your concerns completely.
> > > 
> > > Ad 2. we have taken approach with OSGi fragment when resolving
> > > similar situation with server-specific implementation, see e.g.
> > > [1]. This is preferrable to moving classes to different packages.
> > > Could you take this approach?
> > > 
> > > [1]?https://github.com/keycloak/keycloak/blob/master/adapters/spi
> > > /undertow-adapter-spi/pom.xml#L119
> > > ?
> > > On Wed, Jul 11, 2018 at 7:36 PM Dmitry Telegin <dt at acutus.pro>
> > > wrote:
> > > > Hi,
> > > > 
> > > > 
> > > > 
> > > > We are working on integrating Apache Sling with Keycloak (see
> > > > my
> > > > 
> > > > posting from June 12). It was suggested that we'd stick to
> > > > servlet
> > > > 
> > > > filter adapter as the most generic one (unlike Keycloak OSGi
> > > > 
> > > > adapter which is more of a JBoss Fuse adapter).
> > > > 
> > > > 
> > > > 
> > > > The first step was to convert keycloak-servlet-filter-adapter
> > > > and
> > > > 
> > > > required keycloak-servlet-adapter-spi to OSGi bundles. This
> > > > went OK,
> > > > 
> > > > I've just added OSGi bundling to the respective POMs. However
> > > > there
> > > > 
> > > > were two major issues when deploying and running the code:
> > > > 
> > > > 
> > > > 
> > > > 1. Bogus dependency on?org.apache.http.*
> > > > 
> > > > 
> > > > 
> > > > Several Keycloak modules the adapter depends on,
> > > > namely?keycloak-authz-client and keycloak-adapter-core, declare
> > > > bogus?"Import-Package: org.apache.http.*;version=4.5.2"
> > > > dependency.
> > > > 
> > > > 
> > > > 
> > > > This comes from the following lines in the POM:
> > > > 
> > > > 
> > > > 
> > > > ? ? ? ? <keycloak.osgi.import>
> > > > 
> > > > ? ? ? ? ? ? org.keycloak.*;version="${project.version}",
> > > > 
> > > > ? ? ? ? ? ?
> > > > org.apache.http.*;version=${apache.httpcomponents.version},
> > > > 
> > > > ? ? ? ? ? ? ...
> > > > 
> > > > ? ? ? ? </keycloak.osgi.import>
> > > > 
> > > > 
> > > > 
> > > > org.apache.http.* is exported by
> > > > org.apache.httpcomponents:httpcore-osgi, which uses its own
> > > > versioning scheme (4.4.9 is the latest version ATM). Thus,
> > > > deploying the bundle to OSGi runtime fails due to unsatisfied
> > > > dependency.
> > > > 
> > > > 
> > > > 
> > > > Later, I've discovered there's keycloak-osgi-thirdparty bundle
> > > > that provides required dependencies (however, they don't become
> > > > less bogus because of that).
> > > > 
> > > > 
> > > > 
> > > > I'm OK with this workaround, but generally speaking, is
> > > > keycloak-osgi-thirdparty still needed?
> > > > 
> > > > I've got an impression it was created at a time when not every
> > > > dependency was available as OSGi bundle.
> > > > 
> > > > 
> > > > 
> > > > Current version of?keycloak-osgi-thirdparty contains merged
> > > > httpclient and httpcore, which are available as
> > > > org.apache.httpcomponents:httpclient-osgi and
> > > > org.apache.httpcomponents:httpcore-osgi, respectively.
> > > > 
> > > > 
> > > > 
> > > > So to me it seems like a candidate for deprecation and removal.
> > > > If so, the bogus dependency issue, obviously, should be tackled
> > > > with first.
> > > > 
> > > > 
> > > > 
> > > > 2. Split package org.keycloak.adapters.servlet
> > > > 
> > > > 
> > > > 
> > > > > In standard Java programming, packages are generally treated
> > > > as
> > > > 
> > > > > split; the Java class path??approach merges all packages from
> > > > 
> > > > > different JAR files on the class path into one big??soup.
> > > > This is
> > > > 
> > > > > anathema to OSGi?s modularization model, where packages are
> > > > treated
> > > > 
> > > > > as atomic (that is, they can?t be split).
> > > > 
> > > > 
> > > > 
> > > > http://web.ist.utl.pt/ist162500/?p=65
> > > > 
> > > > 
> > > > 
> > > > In Keycloak, the package org.keycloak.adapters.servlet is split
> > > > between
> > > > 
> > > > keycloak-servlet-adapter-spi and keycloak-servlet-filter-
> > > > adapter. This
> > > > 
> > > > leads to seemingly inexplicable NoClassDefFoundError's, when
> > > > e.g.
> > > > 
> > > > KeycloakOIDCFilter cannot find its neighbor
> > > > OIDCServletHttpFacade. The
> > > > 
> > > > recipe provided by the above article (create dummy bundle,
> > > > prohibit
> > > > 
> > > > direct imports etc.) is rather cumbersome, so I've just created
> > > > 
> > > > org.keycloak.adapters.servlet.spi package and moved there the
> > > > two
> > > > 
> > > > classes from keycloak-servlet-adapter-spi.
> > > > 
> > > > 
> > > > 
> > > > After that, I was finally able to wire Keycloak filter to a
> > > > test
> > > > 
> > > > servlet, and it worked pretty well. There was a redirect to
> > > > Keycloak's
> > > > 
> > > > login screen, then redirect back, and the servlet was able to
> > > > obtain
> > > > 
> > > > valid KeycloakPrincipal with JWT token.
> > > > 
> > > > 
> > > > 
> > > > To sum up, I'm eager to contribute changes required to make
> > > > Keycloak
> > > > 
> > > > servlet filter adapter a valid and working OSGi bundle. That
> > > > would
> > > > 
> > > > include OSGi bundling for two modules and split package
> > > > refactoring.
> > > > 
> > > > The first issue (bogus deps) IMO should require further
> > > > discussion.
> > > > 
> > > > 
> > > > 
> > > > Let me know what you think,
> > > > 
> > > > 
> > > > 
> > > > Dmitry Telegin
> > > > 
> > > > CTO, Acutus s.r.o.
> > > > 
> > > > _______________________________________________
> > > > 
> > > > keycloak-dev mailing list
> > > > 
> > > > keycloak-dev at lists.jboss.org
> > > > 
> > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev

From hmlnarik at redhat.com  Mon Jul 16 02:56:13 2018
From: hmlnarik at redhat.com (Hynek Mlnarik)
Date: Mon, 16 Jul 2018 08:56:13 +0200
Subject: [keycloak-dev] Keycloak servlet filter adapter on OSGi,
	first impressions
In-Reply-To: <1531702447.11875.1.camel@acutus.pro>
References: <1531330171.2179.7.camel@acutus.pro>
	<CAMvXD=HuB2G+AhXwVj42W8KE5h_TnTN5k43L6uiz3hw8C7jw4g@mail.gmail.com>
	<1531441441.10591.3.camel@acutus.pro>
	<CAMvXD=GX+1QnP7h6456Up2SgOMq=aL3zvZMnRZRHaKBavq1L+w@mail.gmail.com>
	<1531702447.11875.1.camel@acutus.pro>
Message-ID: <CAMvXD=GzdL97Mxd9edE2Vq7UWW52wWXsBKA72MT38Ncsq=trGA@mail.gmail.com>

Thanks for the PR.

Ad the documentation - the best suitable place would be [1]. Since this
would currently be for community only, please enclose it into similar
if-endif like here [2]. The PR would be submitted under the same KEYCLOAK
issue as implementation, i.e. KEYCLOAK-7858. And no worries, we will be
happy to help shaping up the documentation in the PR, just send what you
would have and we'll help out.

Thank you

--Hynek

[1]
https://github.com/keycloak/keycloak-documentation/blob/master/securing_apps/topics/oidc/java/servlet-filter-adapter.adoc
[2]
https://github.com/keycloak/keycloak-documentation/blame/master/securing_apps/topics/oidc/java/application-clustering.adoc#L4

On Mon, Jul 16, 2018 at 2:54 AM Dmitry Telegin <dt at acutus.pro> wrote:

> Hi,
>
> https://issues.jboss.org/browse/KEYCLOAK-7858
> https://github.com/keycloak/keycloak/pull/5383
>
> As for documentation, I'm experienced in technical writing, however I'll
> still need supervisor/reviewer since I'll be contributing to Keycloak docs
> for the first time.
>
> Idea: we could have (one day) something kind of "OSGi extras" for servlet
> filter adapter, containing bundle activator to install a filter + config
> resolver that would integrate with OSGi Config Admin Service. WDYT?
>
> Dmitry
>
> On Fri, 2018-07-13 at 15:36 +0200, Hynek Mlnarik wrote:
>
> Excellent. JIRA + PR for OSGi bundling would be welcome. Re the
> documentation, yes please, it will be necessary. It looks like the way you
> would describe would be applicable to any OSGi-compliant container,
> correct? Which OSGi release?
>
> Thanks,
>
> --Hynek
>
> On Fri, Jul 13, 2018 at 2:24 AM Dmitry Telegin <dt at acutus.pro> wrote:
>
> Hi Hynek,
>
> Thanks for the OSGi fragment tip, it worked perfectly. Also glad to hear
> the HTTP Components dependency issue has been resolved.
>
> So OK for JIRA/PR for servlet filter adapter OSGi bundling? And, by the
> way, should we document how to use this adapter on OSGi? Installing a
> bundle is not sufficient, the filter should be registered with OSGi HTTP
> Service, and there are at least two ways of doing it (via
> BundleContext::registerService or via a @Component that extends the filter
> class). What do you think?
>
> Dmitry
>
> On Thu, 2018-07-12 at 11:10 +0200, Hynek Mlnarik wrote:
>
> Hi Dmitri,
>
> thank you for the updates.
>
> The 1. (dependencies on Apache HTTP Components) has been resolved in the
> latest master already and the -thirdparty module has been removed.
> Hopefully this addresses your concerns completely.
>
> Ad 2. we have taken approach with OSGi fragment when resolving similar
> situation with server-specific implementation, see e.g. [1]. This is
> preferrable to moving classes to different packages. Could you take this
> approach?
>
> [1]
> https://github.com/keycloak/keycloak/blob/master/adapters/spi/undertow-adapter-spi/pom.xml#L119
>
>
> On Wed, Jul 11, 2018 at 7:36 PM Dmitry Telegin <dt at acutus.pro> wrote:
>
> Hi,
>
> We are working on integrating Apache Sling with Keycloak (see my
> posting from June 12). It was suggested that we'd stick to servlet
> filter adapter as the most generic one (unlike Keycloak OSGi
> adapter which is more of a JBoss Fuse adapter).
>
> The first step was to convert keycloak-servlet-filter-adapter and
> required keycloak-servlet-adapter-spi to OSGi bundles. This went OK,
> I've just added OSGi bundling to the respective POMs. However there
> were two major issues when deploying and running the code:
>
> 1. Bogus dependency on org.apache.http.*
>
> Several Keycloak modules the adapter depends on,
> namely keycloak-authz-client and keycloak-adapter-core, declare
> bogus "Import-Package: org.apache.http.*;version=4.5.2" dependency.
>
> This comes from the following lines in the POM:
>
>         <keycloak.osgi.import>
>             org.keycloak.*;version="${project.version}",
>             org.apache.http.*;version=${apache.httpcomponents.version},
>             ...
>         </keycloak.osgi.import>
>
> org.apache.http.* is exported by org.apache.httpcomponents:httpcore-osgi,
> which uses its own versioning scheme (4.4.9 is the latest version ATM).
> Thus, deploying the bundle to OSGi runtime fails due to unsatisfied
> dependency.
>
> Later, I've discovered there's keycloak-osgi-thirdparty bundle that
> provides required dependencies (however, they don't become less bogus
> because of that).
>
> I'm OK with this workaround, but generally speaking, is
> keycloak-osgi-thirdparty still needed?
> I've got an impression it was created at a time when not every dependency
> was available as OSGi bundle.
>
> Current version of keycloak-osgi-thirdparty contains merged httpclient and
> httpcore, which are available as org.apache.httpcomponents:httpclient-osgi
> and org.apache.httpcomponents:httpcore-osgi, respectively.
>
> So to me it seems like a candidate for deprecation and removal. If so, the
> bogus dependency issue, obviously, should be tackled with first.
>
> 2. Split package org.keycloak.adapters.servlet
>
> > In standard Java programming, packages are generally treated as
> > split; the Java class path  approach merges all packages from
> > different JAR files on the class path into one big  soup. This is
> > anathema to OSGi?s modularization model, where packages are treated
> > as atomic (that is, they can?t be split).
>
> http://web.ist.utl.pt/ist162500/?p=65
>
> In Keycloak, the package org.keycloak.adapters.servlet is split between
> keycloak-servlet-adapter-spi and keycloak-servlet-filter-adapter. This
> leads to seemingly inexplicable NoClassDefFoundError's, when e.g.
> KeycloakOIDCFilter cannot find its neighbor OIDCServletHttpFacade. The
> recipe provided by the above article (create dummy bundle, prohibit
> direct imports etc.) is rather cumbersome, so I've just created
> org.keycloak.adapters.servlet.spi package and moved there the two
> classes from keycloak-servlet-adapter-spi.
>
> After that, I was finally able to wire Keycloak filter to a test
> servlet, and it worked pretty well. There was a redirect to Keycloak's
> login screen, then redirect back, and the servlet was able to obtain
> valid KeycloakPrincipal with JWT token.
>
> To sum up, I'm eager to contribute changes required to make Keycloak
> servlet filter adapter a valid and working OSGi bundle. That would
> include OSGi bundling for two modules and split package refactoring.
> The first issue (bogus deps) IMO should require further discussion.
>
> Let me know what you think,
>
> Dmitry Telegin
> CTO, Acutus s.r.o.
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>

From sthorger at redhat.com  Mon Jul 16 09:00:50 2018
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 16 Jul 2018 15:00:50 +0200
Subject: [keycloak-dev] KEYCLOAK_IDENTITY encoding choose between HMAC
	and RSA
In-Reply-To: <CAGCf-JYr9pNjFP4kx6Qa21Y3KCqfUTrr9G16En+2Aom88T7HcQ@mail.gmail.com>
References: <CAGCf-JYr9pNjFP4kx6Qa21Y3KCqfUTrr9G16En+2Aom88T7HcQ@mail.gmail.com>
Message-ID: <CAJgngAeQ+Cj=tZ71_+9hXDToLpBDEBB5HPoNiFx3ivYbLLb5_g@mail.gmail.com>

The identity cookie should only be used by Keycloak to check if the user
has a session. It's not a generic cookie that should be used in NGINX to
check what permissions a user has to different applications.

On Mon, 2 Jul 2018 at 21:18, Christian Battaglia <
christian.d.battaglia at gmail.com> wrote:

> "encodeToken" method from
>
> "services/src/main/java/org/keycloak/services/managers/AuthenticationManager.java
> " specifically uses hmac256 for its encoding and I get that this is done
> for speed but I would argue that this should be a choice in the
> configuration.
>
> So my use case sort of breaks outside the walls of Keycloak but I think
> this would be a great point to extend. I would like to make use of this JWT
> on the NGINX network layer to cryptographically verify against the RSA
> public key found at
> "/auth/realms/<realm-name>/.well-known/openid-configuration".
>
> This would be sort of a broad level scope authentication used for things
> like CDN assets.
>
> I get this looks kind of nasty as far as security concerns but how else
> could I include a cookie for a specific client purpose and at a specific
> subdomain without first adding in a minimal client frontend with the
> Keycloak js iframe check that then adds a cookie for that domain and then
> redirects them back to the URL? It seems kind of dumb this couldn't be done
> on a realm wide level.
>
> Thoughts?
>
> - Christian
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From ddtxra at gmail.com  Mon Jul 16 11:26:38 2018
From: ddtxra at gmail.com (Daniel Teixeira)
Date: Mon, 16 Jul 2018 17:26:38 +0200
Subject: [keycloak-dev] Spring Security Adapter resource_access roles
	missing
In-Reply-To: <CAHvCgvzE77zyZ2xKpGowib0OwvTfN-nmvL7o3HwRx3W1scV_ug@mail.gmail.com>
References: <CAHvCgvzE77zyZ2xKpGowib0OwvTfN-nmvL7o3HwRx3W1scV_ug@mail.gmail.com>
Message-ID: <CAHvCgvwYJ=ydMfsefU-rwAu4RXRQDdf44+ZjvRp_WkyS0Uniaw@mail.gmail.com>

My bad, I forgot to set the keycloak property !

keycloak.use-resource-role-mappings=true

It is well set in here:
https://github.com/keycloak/keycloak/blob/master/adapters/oidc/adapter-core/src/main/java/org/keycloak/adapters/AdapterUtils.java#L46

And the documentation describes it as well:
https://www.keycloak.org/docs/latest/securing_apps/index.html#_spring_security_adapter



On Wed, Jul 11, 2018 at 8:19 PM, Daniel Teixeira <ddtxra at gmail.com> wrote:

> Hello,
> I have noticed that roles belonging to realm_access are present in the
> Authentication object. But roles belonging to other client applications
> (resource_access) are missing in the Authentication Java object.
>
> Would it make sense to include them?
>
> I am not sure if it makes sense to change it in
> KeycloakAuthenticationProvider
> https://github.com/keycloak/keycloak/blob/master/adapters/
> oidc/spring-security/src/main/java/org/keycloak/adapters/
> springsecurity/authentication/KeycloakAuthenticationProvider.java#L51
>
> Or when creating the SimpleKeycloakAccount using AdapterUtils?
> https://github.com/keycloak/keycloak/blob/master/adapters/
> oidc/adapter-core/src/main/java/org/keycloak/adapters/
> AdapterUtils.java#L52
>
> Cheers,
> Daniel
>



-- 
Daniel Teixeira

From sthorger at redhat.com  Mon Jul 16 14:26:40 2018
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 16 Jul 2018 20:26:40 +0200
Subject: [keycloak-dev] Introduce role attributes
In-Reply-To: <f290648bf6f24a3994138d5529891d63@BOSKGEXC01.boskg.local>
References: <f290648bf6f24a3994138d5529891d63@BOSKGEXC01.boskg.local>
Message-ID: <CAJgngAfsEfBuaEdAtnpMQjdk4O6oN_5w740Q5D=RnAZ8jNrqxQ@mail.gmail.com>

I don't think we should add attributes to roles. It would introduce
complexity and also potentially have performance/memory impacts.

I also struggle to see how you would use attributes associated with roles.
Are you thinking that would be mapped into the token together with the role
name?

On Tue, 3 Jul 2018 at 07:37, L?sch, Sebastian <
Sebastian.Loesch at governikus.de> wrote:

> Hi developers,
>
> we are currently setting up a project using keycloak and need to model:
> - representative roles, i.e. roles that are given temporarily from one
> user to another e.g. in holiday times
> - roles contain entitlements on business objects
>
> The current role object in keycloak is not sufficent for our use cases.
> Searching for a solution I stumbled over
> https://issues.jboss.org/browse/KEYCLOAK-961
> Introducing role attributes would solve my challenges. Also this fits well
> in the keycloak data model, as there are already user attributes, group
> attributes, realm attributes.
>
> So I would like to add role attributes to keycloak in the style of group
> attributes.
> What do you think?
>
> Best regards,
> Sebastian
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sthorger at redhat.com  Mon Jul 16 14:28:49 2018
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 16 Jul 2018 20:28:49 +0200
Subject: [keycloak-dev] Some feature suggestions for Identity Provider
	support
In-Reply-To: <CAK-7U1jikTB-q7rSBK603zCjMDLukuNSCXXSMux7m9o25CBX1g@mail.gmail.com>
References: <CAK-7U1jikTB-q7rSBK603zCjMDLukuNSCXXSMux7m9o25CBX1g@mail.gmail.com>
Message-ID: <CAJgngAe3=ugpGKiY-q_1Kdt2EZ6Y6CHT+4fq3Q9zvs-xeFnX-g@mail.gmail.com>

On Tue, 3 Jul 2018 at 13:46, Thomas Darimont <thomas.darimont at googlemail.com>
wrote:

> Hello Keycloak-Team,
>
> for a integration scenario with a big german internet provider I needed to
> implement
> a custom OAuth2 based IdentityProvider.
> It worked out quite well but I encountered some things which currently
> require
> custom coding that could be provided out of the box.
>
> - Default roles for users that come via Identity Provider
> I need to assign some realm- / client-roles to users that come via that
> IdP.
> Users that come via that IdP should be able to access certain client
> applications by default.
> Of course one could programmatically add appropriate roles to newly created
> broker users,
> but it would be nicer to be able to configure a set of default roles on IdP
> level, like roles / scopes
> for Clients / Service Accounts.
>

Is that already possible with mappers on the identity provider?


>
> - Allow multiple IdP definitions of the same type with different names
> (google-test, google-staging)
> At the moment it seems that one can only have one IdP per IdP-type (e.g.
> just one google, one twitter etc.).
> However for testing it would be handy to be able to define multiple IdP
> definitions of the same type
> with different identifiers.
> A workaround for this would be to use different realms for this but if one
> needs to work with multiple
> testing / staging environments this becomes complicated quickly.
>

It's only the social providers that are limited to a single instance. Not
sure I see the need to have more than one Google or Twitter provider for
the same realm.


>
> WDYT?
>
> Cheers,
> Thomas
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sthorger at redhat.com  Mon Jul 16 14:36:13 2018
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 16 Jul 2018 20:36:13 +0200
Subject: [keycloak-dev] Token revocation support
In-Reply-To: <CAK-7U1gEToAL=BvOoh-UOqDzH-kf9BuKC9NR=n3ME_3RWOG6vg@mail.gmail.com>
References: <CAK-7U1gEToAL=BvOoh-UOqDzH-kf9BuKC9NR=n3ME_3RWOG6vg@mail.gmail.com>
Message-ID: <CAJgngAfvN2efeU5P9=V96LeH3hsiC1ycn4W-KMxin1KMFHgyGw@mail.gmail.com>

We currently don't have any support for https://tools.ietf.org/html/rfc7009.

For offline tokens it would be fairly easy to implement as it can simply
remove the offline session. For refresh tokens I guess it could remove the
client session under the user session. For access tokens as we have today
with short expiration time I don't see it being all that useful and could
open up the doors to some really bad performance as we'd have to record the
revoked token id. It could be useful if we add support for opaque
long-expiration access tokens where the applications are required to invoke
the token introspection endpoint to validate the token.

On Sat, 7 Jul 2018 at 16:28, Thomas Darimont <thomas.darimont at googlemail.com>
wrote:

> Hello Keycloak Team,
>
> whilst comparing the output of googles .well-known/openid-configuration
> with that of Keycloak
> I noticed that the .well-known/openid-configuration endpoint in Keycloak
> does not expose a "revocation_endpoint".
> See below...
>
> I just stumbled upon the old keycloak-dev ML thread where this was
> mentioned already.
> http://lists.jboss.org/pipermail/keycloak-dev/2016-April/007054.html
>
> Are there any plans to support token revocation with a
> `revocation_endpoint`?
>
> RFC7009 mentions that an implementation MUST provide token revocation for
> refresh_tokens
> and SHOULD provide support for access_tokens, perhaps only supporting
> refresh_tokens would be a good start.
>
> It seems that token revocation is currently handled by updating the
> "notBefore" timestamp
> of a realm and ensuring that only tokens with issuedAt timestamp >
> notBefore are considered valid.
> A naive way of supporting the revocation_endpoint could just be to update
> the realms notBefore timestamp.
>
> However I think this might be a bit too coarse-grained since it might
> invalidate a bunch of tokens at once,
> which could potentially require many/all clients/users to request new
> tokens.
>
> A more fine-grained approach could be to record the hash of a revoked
> refresh_token value in a
> database table like revoked_tokens (id, token_hash, issued_at, token_type).
> When a new token is requested with a refresh_token, then one could try to
> lookup an entry in the
> revoked_tokens table with the token_hash of the current token.
> If nothing was found then the token was not revoked and can be used.
> Otherwise, the token was revoked and no new
> tokens should be issued with the given refresh_token, which means that the
> user / client must reauthenticate again.
> Table entries could be cleared once the associated refresh tokens have
> timed out.
>
> OAuth2 Token Revocation Overview:
> https://connect2id.com/blog/token-revocation
> OAuth2 Token Revocation RFC: https://tools.ietf.org/html/rfc7009
>
> Cheers,
> Thomas
>
> This is the output of googles .well-known/openid-configuration endpoint:
> https://accounts.google.com/.well-known/openid-configuration
> {
>     "issuer": "https://accounts.google.com",
>     "authorization_endpoint": "
> https://accounts.google.com/o/oauth2/v2/auth
> ",
>     "token_endpoint": "https://www.googleapis.com/oauth2/v4/token",
>     "userinfo_endpoint": "https://www.googleapis.com/oauth2/v3/userinfo",
>     "revocation_endpoint": "https://accounts.google.com/o/oauth2/revoke",
>     "jwks_uri": "https://www.googleapis.com/oauth2/v3/certs",
>     "response_types_supported": [
>         "code",
>         "token",
>         "id_token",
>         "code token",
>         "code id_token",
>         "token id_token",
>         "code token id_token",
>         "none"
>     ],
>     "subject_types_supported": [
>         "public"
>     ],
>     "id_token_signing_alg_values_supported": [
>         "RS256"
>     ],
>     "scopes_supported": [
>         "openid",
>         "email",
>         "profile"
>     ],
>     "token_endpoint_auth_methods_supported": [
>         "client_secret_post",
>         "client_secret_basic"
>     ],
>     "claims_supported": [
>         "aud",
>         "email",
>         "email_verified",
>         "exp",
>         "family_name",
>         "given_name",
>         "iat",
>         "iss",
>         "locale",
>         "name",
>         "picture",
>         "sub"
>     ],
>     "code_challenge_methods_supported": [
>         "plain",
>         "S256"
>     ]
> }
>
> This is the output of Keycloaks .well-known/openid-configuration endpoint
> (Keycloak 4.1.0.Final)
>
> http://iam.tdlabs.local:8080/auth/realms/concourseci/.well-known/openid-configuration
> {
>     "issuer": "http://iam.tdlabs.local:8080/auth/realms/concourseci",
>     "authorization_endpoint": "
>
> http://iam.tdlabs.local:8080/auth/realms/concourseci/protocol/openid-connect/auth
> ",
>     "token_endpoint": "
>
> http://iam.tdlabs.local:8080/auth/realms/concourseci/protocol/openid-connect/token
> ",
>     "token_introspection_endpoint": "
>
> http://iam.tdlabs.local:8080/auth/realms/concourseci/protocol/openid-connect/token/introspect
> ",
>     "userinfo_endpoint": "
>
> http://iam.tdlabs.local:8080/auth/realms/concourseci/protocol/openid-connect/userinfo
> ",
>     "end_session_endpoint": "
>
> http://iam.tdlabs.local:8080/auth/realms/concourseci/protocol/openid-connect/logout
> ",
>     "jwks_uri": "
>
> http://iam.tdlabs.local:8080/auth/realms/concourseci/protocol/openid-connect/certs
> ",
>     "check_session_iframe": "
>
> http://iam.tdlabs.local:8080/auth/realms/concourseci/protocol/openid-connect/login-status-iframe.html
> ",
>     "grant_types_supported": [
>         "authorization_code",
>         "implicit",
>         "refresh_token",
>         "password",
>         "client_credentials"
>     ],
>     "response_types_supported": [
>         "code",
>         "none",
>         "id_token",
>         "token",
>         "id_token token",
>         "code id_token",
>         "code token",
>         "code id_token token"
>     ],
>     "subject_types_supported": [
>         "public",
>         "pairwise"
>     ],
>     "id_token_signing_alg_values_supported": [
>         "RS256"
>     ],
>     "userinfo_signing_alg_values_supported": [
>         "RS256"
>     ],
>     "request_object_signing_alg_values_supported": [
>         "none",
>         "RS256"
>     ],
>     "response_modes_supported": [
>         "query",
>         "fragment",
>         "form_post"
>     ],
>     "registration_endpoint": "
>
> http://iam.tdlabs.local:8080/auth/realms/concourseci/clients-registrations/openid-connect
> ",
>     "token_endpoint_auth_methods_supported": [
>         "private_key_jwt",
>         "client_secret_basic",
>         "client_secret_post",
>         "client_secret_jwt"
>     ],
>     "token_endpoint_auth_signing_alg_values_supported": [
>         "RS256"
>     ],
>     "claims_supported": [
>         "sub",
>         "iss",
>         "auth_time",
>         "name",
>         "given_name",
>         "family_name",
>         "preferred_username",
>         "email"
>     ],
>     "claim_types_supported": [
>         "normal"
>     ],
>     "claims_parameter_supported": false,
>     "scopes_supported": [
>         "openid",
>         "address",
>         "concourse.main",
>         "email",
>         "offline_access",
>         "phone",
>         "profile",
>         "read"
>     ],
>     "request_parameter_supported": true,
>     "request_uri_parameter_supported": true,
>     "code_challenge_methods_supported": [
>         "plain",
>         "S256"
>     ],
>     "tls_client_certificate_bound_access_tokens": true
> }
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sthorger at redhat.com  Mon Jul 16 14:37:21 2018
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 16 Jul 2018 20:37:21 +0200
Subject: [keycloak-dev] Introduce lastModified property on UserModel
In-Reply-To: <CAMvXD=F+Af6P-eiEpU8-bUh3DZWBBQOqz9w2o5pvdwf4bruvFg@mail.gmail.com>
References: <9139119d072b40bd8d1ea1bd765bcda8@BOSKGEXC01.boskg.local>
	<CAMvXD=F+Af6P-eiEpU8-bUh3DZWBBQOqz9w2o5pvdwf4bruvFg@mail.gmail.com>
Message-ID: <CAJgngAe7Uxa3vEa-piZEHw+r2HZ=qzgRZ2o7aYTznwfCyAmLMQ@mail.gmail.com>

+1 to just storing as a user attribute

On Wed, 11 Jul 2018 at 11:43, Hynek Mlnarik <hmlnarik at redhat.com> wrote:

> This is a difficult question we tackled some time ago within the team,
> exactly with the same attribute. The User Storage SPI [1] would be affected
> by this change, and at the same time the SPI is fully supported and should
> be hence preserved as is. Hence we decided not to change it.
>
> Can you just store it as a user attribute?
>
> [1]
>
> https://access.redhat.com/documentation/en-us/red_hat_single_sign-on/7.1/html/server_developer_guide/user-storage-spi#model_interfaces
>
> On Tue, Jul 3, 2018 at 9:01 AM L?sch, Sebastian <
> Sebastian.Loesch at governikus.de> wrote:
>
> > Hi developers,
> >
> > we are currently setting up a project using keycloak and have the need to
> > show the last mofication date of a user, similar to SCIM lastModified
> (see
> > https://tools.ietf.org/html/rfc7643#section-3.1).
> >
> > What do you think adding this as a new property on UserModel?
> >
> > Best regards,
> > Sebastian
> >
> > _______________________________________________
> > 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 Jul 16 14:39:23 2018
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 16 Jul 2018 20:39:23 +0200
Subject: [keycloak-dev] Support for updating user with credentials in
 admin endpoints
In-Reply-To: <5B4729CC.4040801@nri.co.jp>
References: <5B46F252.5090208@nri.co.jp>
	<CAK-7U1j3XxJZF9NBrSByh9O8HO0v_Ak7gNH0njRqPmKh77RCdQ@mail.gmail.com>
	<5B4729CC.4040801@nri.co.jp>
Message-ID: <CAJgngAehdcXd9a0p1y4DFyrrNA7GkkpnYA6NzGXSh-r5GREMGw@mail.gmail.com>

I don't see any issues with adding support for what you want. A PR would be
welcome as long as it comes with proper level of testing.

On Thu, 12 Jul 2018 at 12:29, Hiroyuki Wada <h2-wada at nri.co.jp> wrote:

> Hello,
>
> Thanks for your comment.
> I know we can use the reset-password endpoint for changing password, but
> I want to update the user profile including credentials with single
> request.
> Also current reset-password endpoint only supports 'password' type
> credential.
> We also want to update other type credentials too.
>
> Best Regards
>
> On 2018/07/12 18:35, Thomas Darimont wrote:
> > Hello,
> >
> > you can change the password a user via the keycloak admin-client with the
> > resetPassword(...) method.
> >     userRessource.get(userId).resetPassword(passwordCred);
> > See:
> >
> https://gist.github.com/thomasdarimont/c4e739c5a319cf78a4cff3b87173a84b#file-keycloakadminclientexample-java-L94
> >
> > Cheers,
> > Thomas
> >
> > On Thu, Jul 12, 2018 at 8:18 AM Hiroyuki Wada <h2-wada at nri.co.jp> wrote:
> >
> >> Hello,
> >>
> >> Currently the Admin REST API ignores credentials when updating the user.
> >> I found the similar issue & discussion in the following links.
> >> It was accepted but it only supports creating method.
> >>
> >> https://issues.jboss.org/browse/KEYCLOAK-5026
> >> http://lists.jboss.org/pipermail/keycloak-dev/2017-June/009552.html
> >>
> >> In our case, we'd like to update users profile including any credentials
> >> from
> >> an external ID system.
> >> Could I send a pull request for supporting it?
> >>
> >> Best Regards
> >>
> >> --
> >> Hiroyuki Wada
> >> Nomura Research Institute, Ltd.
> >> h2-wada at nri.co.jp
> >>
> >> --------------------------------------------------------------------
> >> PLEASE READ:This e-mail is confidential and intended for
> >> the named recipient only. If you are not an intended recipient,
> >> please notify the sender and delete this e-mail.
> >> --------------------------------------------------------------------
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> >
>
> --
> Hiroyuki Wada
> Nomura Research Institute, Ltd.
> h2-wada at nri.co.jp
>
> --------------------------------------------------------------------
> PLEASE READ:This e-mail is confidential and intended for
> the named recipient only. If you are not an intended recipient,
> please notify the sender and delete this e-mail.
> --------------------------------------------------------------------
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sthorger at redhat.com  Mon Jul 16 14:41:12 2018
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 16 Jul 2018 20:41:12 +0200
Subject: [keycloak-dev] Any reason why the DefaultBruteForceProtector
 success() method is private?
In-Reply-To: <CA+T+PjGiZEY2CsiVqYV13tNh1dQFX0NRcVjcPom-2uTCab16RA@mail.gmail.com>
References: <CA+T+PjGiZEY2CsiVqYV13tNh1dQFX0NRcVjcPom-2uTCab16RA@mail.gmail.com>
Message-ID: <CAJgngAftZ8a5vxQAQ2ZUMVzk=AYTqnLOs3xA7mh7qO--TY4k3g@mail.gmail.com>

I don't see any issues with changing it to public. Just remember that only
SPIs/APIs in server-spi will have backwards compatibility/deprecation
period.

On Fri, 13 Jul 2018 at 20:17, Eric B <ebenzacar at gmail.com> wrote:

> Hi.
>
> I'm looking at producing an extended implementation of the
> DefaultBruteForceProtector implementation, but for some reason the
> success() method in the class is the only private method which is
> prohibiting me of simply extending the DefaultBruteForceProtector class and
> adding some additional logic to the methods.
>
> Is there a particular reason why the visibility for these methods are as
> follows?
> - public void failure()
> - private void success()
>
> Why is success() private, whereas failure is public()?  Was this just an
> oversight?  Can sucess() be changed to public?
>
> Thanks,
>
> Eric
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From dt at acutus.pro  Mon Jul 16 19:54:56 2018
From: dt at acutus.pro (Dmitry Telegin)
Date: Tue, 17 Jul 2018 02:54:56 +0300
Subject: [keycloak-dev] Keycloak servlet filter adapter on OSGi,
 first impressions
In-Reply-To: <CAMvXD=GzdL97Mxd9edE2Vq7UWW52wWXsBKA72MT38Ncsq=trGA@mail.gmail.com>
References: <1531330171.2179.7.camel@acutus.pro>
	<CAMvXD=HuB2G+AhXwVj42W8KE5h_TnTN5k43L6uiz3hw8C7jw4g@mail.gmail.com>
	<1531441441.10591.3.camel@acutus.pro>
	<CAMvXD=GX+1QnP7h6456Up2SgOMq=aL3zvZMnRZRHaKBavq1L+w@mail.gmail.com>
	<1531702447.11875.1.camel@acutus.pro>
	<CAMvXD=GzdL97Mxd9edE2Vq7UWW52wWXsBKA72MT38Ncsq=trGA@mail.gmail.com>
Message-ID: <1531785296.4364.7.camel@acutus.pro>

Hi Hynek,
Thx, got it, will submit the draft soon.?
And I'm sorry for having forgotten to answer to your previous?question:
> > > > It looks like the way you would describe would be applicable to
> > > > any OSGi-compliant container, correct? Which OSGi release?

In theory that should be suitable for every OSGi-compliant runtime with
HttpService. We have yet tested it on Apache Felix 5.6.10 (both
standalone and as a part of?Apache Karaf 4.2.0), so that's OSGi
R6.Haven't tested on either Equinox or Knopflerfish though, will
probably need volunteers for that.
Dmitry
On Mon, 2018-07-16 at 08:56 +0200, Hynek Mlnarik wrote:
> Thanks for the PR.
> Ad the documentation - the best suitable place would be [1]. Since
> this would?currently be for community only, please enclose it into
> similar if-endif like here [2]. The PR would be submitted under the
> same KEYCLOAK issue as implementation, i.e. KEYCLOAK-7858. And no
> worries, we will be happy to help shaping up the documentation in the
> PR, just send what you would have and we'll help out.
> 
> Thank you
> 
> --Hynek
> 
> [1]?https://github.com/keycloak/keycloak-documentation/blob/master/se
> curing_apps/topics/oidc/java/servlet-filter-adapter.adoc
> [2]?https://github.com/keycloak/keycloak-documentation/blame/master/s
> ecuring_apps/topics/oidc/java/application-clustering.adoc#L4
> On Mon, Jul 16, 2018 at 2:54 AM Dmitry Telegin <dt at acutus.pro> wrote:
> > Hi,
> > https://issues.jboss.org/browse/KEYCLOAK-7858https://github.com/key
> > cloak/keycloak/pull/5383
> > As for documentation, I'm experienced in technical writing, however
> > I'll still need supervisor/reviewer since I'll be contributing to
> > Keycloak docs for the first time.
> > Idea: we could have (one day) something kind of "OSGi extras" for
> > servlet filter adapter, containing bundle activator to install a
> > filter + config resolver that would integrate with OSGi Config
> > Admin Service. WDYT?
> > Dmitry
> > On Fri, 2018-07-13 at 15:36 +0200, Hynek Mlnarik wrote:
> > > Excellent. JIRA?+ PR for OSGi bundling would be welcome. Re the
> > > documentation, yes please, it will be necessary. It looks like
> > > the way you would describe would be applicable to any OSGi-
> > > compliant container, correct? Which OSGi release?
> > > Thanks,
> > > 
> > > --Hynek
> > > On Fri, Jul 13, 2018 at 2:24 AM Dmitry Telegin <dt at acutus.pro>
> > > wrote:
> > > > Hi Hynek,
> > > > Thanks for the OSGi fragment tip, it worked perfectly. Also
> > > > glad to hear the HTTP Components dependency issue has been
> > > > resolved.
> > > > So OK for JIRA/PR for servlet filter adapter OSGi bundling?
> > > > And, by the way, should we document how to use this adapter on
> > > > OSGi? Installing a bundle is not sufficient, the filter should
> > > > be registered with OSGi HTTP Service, and there are at least
> > > > two ways of doing it (via BundleContext::registerService or via
> > > > a @Component that extends the filter class). What do you think?
> > > > Dmitry
> > > > On Thu, 2018-07-12 at 11:10 +0200, Hynek Mlnarik wrote:
> > > > > Hi Dmitri,
> > > > > thank you for the updates.
> > > > > 
> > > > > The 1. (dependencies on Apache HTTP Components) has been
> > > > > resolved in the latest master already and the -thirdparty
> > > > > module has been removed. Hopefully this addresses your
> > > > > concerns completely.
> > > > > 
> > > > > Ad 2. we have taken approach with OSGi fragment when
> > > > > resolving similar situation with server-specific
> > > > > implementation, see e.g. [1]. This is preferrable to moving
> > > > > classes to different packages. Could you take this approach?
> > > > > 
> > > > > [1]?https://github.com/keycloak/keycloak/blob/master/adapters
> > > > > /spi/undertow-adapter-spi/pom.xml#L119
> > > > > ?
> > > > > On Wed, Jul 11, 2018 at 7:36 PM Dmitry Telegin <dt at acutus.pro
> > > > > > wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > We are working on integrating Apache Sling with Keycloak
> > > > > > (see my
> > > > > > 
> > > > > > posting from June 12). It was suggested that we'd stick to
> > > > > > servlet
> > > > > > 
> > > > > > filter adapter as the most generic one (unlike Keycloak
> > > > > > OSGi
> > > > > > 
> > > > > > adapter which is more of a JBoss Fuse adapter).
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > The first step was to convert keycloak-servlet-filter-
> > > > > > adapter and
> > > > > > 
> > > > > > required keycloak-servlet-adapter-spi to OSGi bundles. This
> > > > > > went OK,
> > > > > > 
> > > > > > I've just added OSGi bundling to the respective POMs.
> > > > > > However there
> > > > > > 
> > > > > > were two major issues when deploying and running the code:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 1. Bogus dependency on?org.apache.http.*
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > Several Keycloak modules the adapter depends on,
> > > > > > namely?keycloak-authz-client and keycloak-adapter-core,
> > > > > > declare bogus?"Import-Package:
> > > > > > org.apache.http.*;version=4.5.2" dependency.
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > This comes from the following lines in the POM:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > ? ? ? ? <keycloak.osgi.import>
> > > > > > 
> > > > > > ? ? ? ? ? ? org.keycloak.*;version="${project.version}",
> > > > > > 
> > > > > > ? ? ? ? ? ?
> > > > > > org.apache.http.*;version=${apache.httpcomponents.version},
> > > > > > 
> > > > > > ? ? ? ? ? ? ...
> > > > > > 
> > > > > > ? ? ? ? </keycloak.osgi.import>
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > org.apache.http.* is exported by
> > > > > > org.apache.httpcomponents:httpcore-osgi, which uses its own
> > > > > > versioning scheme (4.4.9 is the latest version ATM). Thus,
> > > > > > deploying the bundle to OSGi runtime fails due to
> > > > > > unsatisfied dependency.
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > Later, I've discovered there's keycloak-osgi-thirdparty
> > > > > > bundle that provides required dependencies (however, they
> > > > > > don't become less bogus because of that).
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > I'm OK with this workaround, but generally speaking, is
> > > > > > keycloak-osgi-thirdparty still needed?
> > > > > > 
> > > > > > I've got an impression it was created at a time when not
> > > > > > every dependency was available as OSGi bundle.
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > Current version of?keycloak-osgi-thirdparty contains merged
> > > > > > httpclient and httpcore, which are available as
> > > > > > org.apache.httpcomponents:httpclient-osgi and
> > > > > > org.apache.httpcomponents:httpcore-osgi, respectively.
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > So to me it seems like a candidate for deprecation and
> > > > > > removal. If so, the bogus dependency issue, obviously,
> > > > > > should be tackled with first.
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 2. Split package org.keycloak.adapters.servlet
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > > In standard Java programming, packages are generally
> > > > > > treated as
> > > > > > 
> > > > > > > split; the Java class path??approach merges all packages
> > > > > > from
> > > > > > 
> > > > > > > different JAR files on the class path into one big??soup.
> > > > > > This is
> > > > > > 
> > > > > > > anathema to OSGi?s modularization model, where packages
> > > > > > are treated
> > > > > > 
> > > > > > > as atomic (that is, they can?t be split).
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > http://web.ist.utl.pt/ist162500/?p=65
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > In Keycloak, the package org.keycloak.adapters.servlet is
> > > > > > split between
> > > > > > 
> > > > > > keycloak-servlet-adapter-spi and keycloak-servlet-filter-
> > > > > > adapter. This
> > > > > > 
> > > > > > leads to seemingly inexplicable NoClassDefFoundError's,
> > > > > > when e.g.
> > > > > > 
> > > > > > KeycloakOIDCFilter cannot find its neighbor
> > > > > > OIDCServletHttpFacade. The
> > > > > > 
> > > > > > recipe provided by the above article (create dummy bundle,
> > > > > > prohibit
> > > > > > 
> > > > > > direct imports etc.) is rather cumbersome, so I've just
> > > > > > created
> > > > > > 
> > > > > > org.keycloak.adapters.servlet.spi package and moved there
> > > > > > the two
> > > > > > 
> > > > > > classes from keycloak-servlet-adapter-spi.
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > After that, I was finally able to wire Keycloak filter to a
> > > > > > test
> > > > > > 
> > > > > > servlet, and it worked pretty well. There was a redirect to
> > > > > > Keycloak's
> > > > > > 
> > > > > > login screen, then redirect back, and the servlet was able
> > > > > > to obtain
> > > > > > 
> > > > > > valid KeycloakPrincipal with JWT token.
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > To sum up, I'm eager to contribute changes required to make
> > > > > > Keycloak
> > > > > > 
> > > > > > servlet filter adapter a valid and working OSGi bundle.
> > > > > > That would
> > > > > > 
> > > > > > include OSGi bundling for two modules and split package
> > > > > > refactoring.
> > > > > > 
> > > > > > The first issue (bogus deps) IMO should require further
> > > > > > discussion.
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > Let me know what you think,
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > Dmitry Telegin
> > > > > > 
> > > > > > CTO, Acutus s.r.o.
> > > > > > 
> > > > > > _______________________________________________
> > > > > > 
> > > > > > keycloak-dev mailing list
> > > > > > 
> > > > > > keycloak-dev at lists.jboss.org
> > > > > > 
> > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev

From wim.vandenhaute at gmail.com  Tue Jul 17 08:35:51 2018
From: wim.vandenhaute at gmail.com (Wim Vandenhaute)
Date: Tue, 17 Jul 2018 14:35:51 +0200
Subject: [keycloak-dev] https://issues.jboss.org/browse/KEYCLOAK-4251
Message-ID: <CAAmmoOp88hFCQPLYwVV5eSQM5NCjjjfqi72p2Jr+Onn0CZuY=A@mail.gmail.com>

I had the same issue as described in issue
https://issues.jboss.org/browse/KEYCLOAK-4251 and would like to ask for the
argument of having different behavior for this use case happening from the
browser vs via direct access grants.

I can understand the argument in not wanting to leak too much information
to possible attackers regarding user account status, but at least then this
behavior should be aligned in both situations which is not the case here so
in my opinion the issue is valid.
Either the login form should change or the direct access grant should
change imo

Browser: Username already exists
Direct access grant: "Invalid user credentials"

Thoughts?

From felix.meissner at hanko.io  Wed Jul 18 02:37:44 2018
From: felix.meissner at hanko.io (=?UTF-8?Q?Felix_Mei=C3=9Fner?=)
Date: Wed, 18 Jul 2018 08:37:44 +0200
Subject: [keycloak-dev] html encoded url in form actions - bug or feature?
Message-ID: <CAC6ftk2u6dZhMwBOLoajqgAk8uEkdpNbr6H-=H=1WGO_H8evaA@mail.gmail.com>

Hi all,

I just discovered that the action url of the login-form seems to get HTML
encoded and I woundered, if thats a bug or a feature.

In
https://github.com/keycloak/keycloak/blob/4.1.0.Final/themes/src/main/resources/theme/base/login/login.ftl
you can see the following line:

<form id="kc-form-login" onsubmit="login.disabled = true; return true;"
action="${url.loginAction}" method="post">

On my instance, this resolves to something similar to this:

<form id="kc-form-login" onsubmit="login.disabled = true; return true;"
action="
https://xx.xx.xx.xx:8443/auth/realms/master/login-actions/authenticate?session_code=tyvLn2J3QkM4YJhPzjYKnNLSG4ej89Xabvspm7nmubc&amp;execution=5c933fb0-b637-4462-a603-bf9ffb601220&amp;client_id=security-admin-console&amp;tab_id=2tJInt2M5NE"
method="post">

All "&" are encoded as &amp;. This became an issue for me, when I tried to
call the url via JavaScripts fetch method. With the same URL, I got a
sevrer error. When changing the URL to:

fetch("${url.loginAction?no_esc}", ...)

it finally worked.

Shouldn't all form-urls and href-urls not be escacped? What makes me wonder
is, that the same URL just works for regular post requests! For
documentation on escaping you can find more information here:
https://freemarker.apache.org/docs/dgui_quickstart_template.html#dgui_quickstart_template_autoescaping

Greetings,
Felix

-- 
Ein Produkt der?Cap3 GmbH, Ringstr. 19, 24114 Kiel, Deutschland

Registergericht: Amtsgericht Kiel, HRB 13257
Gesch?ftsf?hrung: Felix 
Magedanz, Nicolas G?nther, Bettual Richter, S?ren Fenner

From ssilvert at redhat.com  Wed Jul 18 19:38:27 2018
From: ssilvert at redhat.com (Stan Silvert)
Date: Wed, 18 Jul 2018 19:38:27 -0400
Subject: [keycloak-dev] html encoded url in form actions - bug or
	feature?
In-Reply-To: <CAC6ftk2u6dZhMwBOLoajqgAk8uEkdpNbr6H-=H=1WGO_H8evaA@mail.gmail.com>
References: <CAC6ftk2u6dZhMwBOLoajqgAk8uEkdpNbr6H-=H=1WGO_H8evaA@mail.gmail.com>
Message-ID: <977ae8fd-78b1-d8ed-56c0-988c413d76d7@redhat.com>

On 7/18/2018 2:37 AM, Felix Mei?ner wrote:
> Hi all,
>
> I just discovered that the action url of the login-form seems to get HTML
> encoded and I woundered, if thats a bug or a feature.
It's a security feature.? We take advantage of FreeMarker's "escape by 
default" feature.? As you discovered, you can use ?no_esc to turn this off.

I'm kind of interested in why fetch() didn't work.? The escaped version 
should be valid as a URL.

>
> In
> https://github.com/keycloak/keycloak/blob/4.1.0.Final/themes/src/main/resources/theme/base/login/login.ftl
> you can see the following line:
>
> <form id="kc-form-login" onsubmit="login.disabled = true; return true;"
> action="${url.loginAction}" method="post">
>
> On my instance, this resolves to something similar to this:
>
> <form id="kc-form-login" onsubmit="login.disabled = true; return true;"
> action="
> https://xx.xx.xx.xx:8443/auth/realms/master/login-actions/authenticate?session_code=tyvLn2J3QkM4YJhPzjYKnNLSG4ej89Xabvspm7nmubc&amp;execution=5c933fb0-b637-4462-a603-bf9ffb601220&amp;client_id=security-admin-console&amp;tab_id=2tJInt2M5NE"
> method="post">
>
> All "&" are encoded as &amp;. This became an issue for me, when I tried to
> call the url via JavaScripts fetch method. With the same URL, I got a
> sevrer error. When changing the URL to:
>
> fetch("${url.loginAction?no_esc}", ...)
>
> it finally worked.
>
> Shouldn't all form-urls and href-urls not be escacped? What makes me wonder
> is, that the same URL just works for regular post requests! For
> documentation on escaping you can find more information here:
> https://freemarker.apache.org/docs/dgui_quickstart_template.html#dgui_quickstart_template_autoescaping
>
> Greetings,
> Felix
>


From felix.meissner at hanko.io  Thu Jul 19 04:44:28 2018
From: felix.meissner at hanko.io (=?UTF-8?Q?Felix_Mei=C3=9Fner?=)
Date: Thu, 19 Jul 2018 10:44:28 +0200
Subject: [keycloak-dev] html encoded url in form actions - bug or
	feature?
In-Reply-To: <977ae8fd-78b1-d8ed-56c0-988c413d76d7@redhat.com>
References: <CAC6ftk2u6dZhMwBOLoajqgAk8uEkdpNbr6H-=H=1WGO_H8evaA@mail.gmail.com>
	<977ae8fd-78b1-d8ed-56c0-988c413d76d7@redhat.com>
Message-ID: <CAC6ftk2R4PKRsP_fGM+zEMF4ujexGBTsUqs=sX3oQmtf8jVsFw@mail.gmail.com>

I expected URLs to be URL encoded, not HTML encoded. Nonetheless, I cannot
find any facts on how URLs should be encoded inside HTML, so maybe I am
wrong.
The problem occured, when I used a HTML-encoded URL inside JavaScript.
There, the URL will not be decoded before its sent to the server. When used
in a form however, the browser will decode the URL before sending it.

2018-07-19 1:38 GMT+02:00 Stan Silvert <ssilvert at redhat.com>:

> On 7/18/2018 2:37 AM, Felix Mei?ner wrote:
> > Hi all,
> >
> > I just discovered that the action url of the login-form seems to get HTML
> > encoded and I woundered, if thats a bug or a feature.
> It's a security feature.  We take advantage of FreeMarker's "escape by
> default" feature.  As you discovered, you can use ?no_esc to turn this off.
>
> I'm kind of interested in why fetch() didn't work.  The escaped version
> should be valid as a URL.
>
> >
> > In
> > https://github.com/keycloak/keycloak/blob/4.1.0.Final/
> themes/src/main/resources/theme/base/login/login.ftl
> > you can see the following line:
> >
> > <form id="kc-form-login" onsubmit="login.disabled = true; return true;"
> > action="${url.loginAction}" method="post">
> >
> > On my instance, this resolves to something similar to this:
> >
> > <form id="kc-form-login" onsubmit="login.disabled = true; return true;"
> > action="
> > https://xx.xx.xx.xx:8443/auth/realms/master/login-actions/
> authenticate?session_code=tyvLn2J3QkM4YJhPzjYKnNLSG4ej89
> Xabvspm7nmubc&amp;execution=5c933fb0-b637-4462-a603-
> bf9ffb601220&amp;client_id=security-admin-console&amp;tab_id=2tJInt2M5NE"
> > method="post">
> >
> > All "&" are encoded as &amp;. This became an issue for me, when I tried
> to
> > call the url via JavaScripts fetch method. With the same URL, I got a
> > sevrer error. When changing the URL to:
> >
> > fetch("${url.loginAction?no_esc}", ...)
> >
> > it finally worked.
> >
> > Shouldn't all form-urls and href-urls not be escacped? What makes me
> wonder
> > is, that the same URL just works for regular post requests! For
> > documentation on escaping you can find more information here:
> > https://freemarker.apache.org/docs/dgui_quickstart_template.
> html#dgui_quickstart_template_autoescaping
> >
> > Greetings,
> > Felix
> >
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

-- 
Ein Produkt der?Cap3 GmbH, Ringstr. 19, 24114 Kiel, Deutschland

Registergericht: Amtsgericht Kiel, HRB 13257
Gesch?ftsf?hrung: Felix 
Magedanz, Nicolas G?nther, Bettual Richter, S?ren Fenner

From eivind at jotta.no  Fri Jul 20 03:56:56 2018
From: eivind at jotta.no (Eivind Larsen)
Date: Fri, 20 Jul 2018 03:56:56 -0400
Subject: [keycloak-dev] Exception on logout
Message-ID: <CAF4REn62Tkz_JdpFoPSUS4fgidtRFY+cKuqbaRmnXja6U1tO6w@mail.gmail.com>

Hi Keycloak Devs!

We are running Keycloak 3.4.3.Final in a 3 node cluster.

A few times per hour we see this exception in the logs:

java.lang.NullPointerException
	at org.keycloak.services.DefaultKeycloakSession.getProvider(DefaultKeycloakSession.java:171)
			5 lines skipped for [sun., com.sun, org.jboss, java.lang.reflect.Method]
	at org.keycloak.services.managers.AuthenticationManager.finishBrowserLogout(AuthenticationManager.java:518)
	at org.keycloak.services.managers.AuthenticationManager.browserLogout(AuthenticationManager.java:484)
	at org.keycloak.protocol.oidc.endpoints.LogoutEndpoint.logout(LogoutEndpoint.java:137)
			16 lines skipped for [javax.servlet, sun., org.jboss,
java.lang.reflect.Method]
	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
	at org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:90)
	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
	at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
	at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
	at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
	at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
	at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
	at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
	at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
	at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
	at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
	at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:326)
	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:812)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at java.lang.Thread.run(Thread.java:748)



It looks like a bug as the session provider probably should not be
null, and it breaks the logout flow for the user.

Is this a known issue?

- Eivind

From sthorger at redhat.com  Fri Jul 20 06:28:00 2018
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 20 Jul 2018 12:28:00 +0200
Subject: [keycloak-dev] html encoded url in form actions - bug or
	feature?
In-Reply-To: <CAC6ftk2R4PKRsP_fGM+zEMF4ujexGBTsUqs=sX3oQmtf8jVsFw@mail.gmail.com>
References: <CAC6ftk2u6dZhMwBOLoajqgAk8uEkdpNbr6H-=H=1WGO_H8evaA@mail.gmail.com>
	<977ae8fd-78b1-d8ed-56c0-988c413d76d7@redhat.com>
	<CAC6ftk2R4PKRsP_fGM+zEMF4ujexGBTsUqs=sX3oQmtf8jVsFw@mail.gmail.com>
Message-ID: <CAJgngAexwQ-LhgDqNv=mRWa5wo1iy70HBN4FmsUQUMKZytFBtw@mail.gmail.com>

What are you actually trying to do? Are you scraping the url from the login
form? That's not really something you should be doing.

On Thu, 19 Jul 2018 at 10:46, Felix Mei?ner <felix.meissner at hanko.io> wrote:

> I expected URLs to be URL encoded, not HTML encoded. Nonetheless, I cannot
> find any facts on how URLs should be encoded inside HTML, so maybe I am
> wrong.
> The problem occured, when I used a HTML-encoded URL inside JavaScript.
> There, the URL will not be decoded before its sent to the server. When used
> in a form however, the browser will decode the URL before sending it.
>
> 2018-07-19 1:38 GMT+02:00 Stan Silvert <ssilvert at redhat.com>:
>
> > On 7/18/2018 2:37 AM, Felix Mei?ner wrote:
> > > Hi all,
> > >
> > > I just discovered that the action url of the login-form seems to get
> HTML
> > > encoded and I woundered, if thats a bug or a feature.
> > It's a security feature.  We take advantage of FreeMarker's "escape by
> > default" feature.  As you discovered, you can use ?no_esc to turn this
> off.
> >
> > I'm kind of interested in why fetch() didn't work.  The escaped version
> > should be valid as a URL.
> >
> > >
> > > In
> > > https://github.com/keycloak/keycloak/blob/4.1.0.Final/
> > themes/src/main/resources/theme/base/login/login.ftl
> > > you can see the following line:
> > >
> > > <form id="kc-form-login" onsubmit="login.disabled = true; return true;"
> > > action="${url.loginAction}" method="post">
> > >
> > > On my instance, this resolves to something similar to this:
> > >
> > > <form id="kc-form-login" onsubmit="login.disabled = true; return true;"
> > > action="
> > > https://xx.xx.xx.xx:8443/auth/realms/master/login-actions/
> > authenticate?session_code=tyvLn2J3QkM4YJhPzjYKnNLSG4ej89
> > Xabvspm7nmubc&amp;execution=5c933fb0-b637-4462-a603-
> > bf9ffb601220&amp;client_id=security-admin-console&amp;tab_id=2tJInt2M5NE"
> > > method="post">
> > >
> > > All "&" are encoded as &amp;. This became an issue for me, when I tried
> > to
> > > call the url via JavaScripts fetch method. With the same URL, I got a
> > > sevrer error. When changing the URL to:
> > >
> > > fetch("${url.loginAction?no_esc}", ...)
> > >
> > > it finally worked.
> > >
> > > Shouldn't all form-urls and href-urls not be escacped? What makes me
> > wonder
> > > is, that the same URL just works for regular post requests! For
> > > documentation on escaping you can find more information here:
> > > https://freemarker.apache.org/docs/dgui_quickstart_template.
> > html#dgui_quickstart_template_autoescaping
> > >
> > > Greetings,
> > > Felix
> > >
> >
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
> --
> Ein Produkt der Cap3 GmbH, Ringstr. 19, 24114 Kiel, Deutschland
>
> Registergericht: Amtsgericht Kiel, HRB 13257
> Gesch?ftsf?hrung: Felix
> Magedanz, Nicolas G?nther, Bettual Richter, S?ren Fenner
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From thomas.darimont at googlemail.com  Sun Jul 22 16:48:44 2018
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Sun, 22 Jul 2018 22:48:44 +0200
Subject: [keycloak-dev] haveibeenpwned.com password policy provider
Message-ID: <CAK-7U1gSb3VWbL4iSiEDEGnjSgBgWH7uFMohfHG4PROwxcCKZw@mail.gmail.com>

Hello Keycloak Team,

yesterday I implemented a password policy provider [0] for Keycloak
which checks
if a given password is contained in the password breach database
haveibeenpwned.com.

The policy provider uses their range based password search API [1] which uses
a "k-Anonymity model" [2] which allows a password to be looked up by
partial hash.

The real password is never revealed to the service, only the first few bytes
of the SHA-1 hash is used for the search which then returns a list of
password hashes with
the given prefix.
Those hashes are then checked by the provider to see if the actual password was
contained in the database and how often it occurred.

Do you guys think that this could be something interesting to add to Keycloak?

Cheers,
Thomas

[0] https://github.com/thomasdarimont/keycloak/tree/issue/KEYCLOAK-XXX-haveibeenpwned-password-policy
[1] https://haveibeenpwned.com/API/v2#SearchingPwnedPasswordsByRange
[2] https://en.wikipedia.org/wiki/K-anonymity

From cpitman at redhat.com  Sun Jul 22 18:26:35 2018
From: cpitman at redhat.com (Chris Pitman)
Date: Sun, 22 Jul 2018 18:26:35 -0400
Subject: [keycloak-dev] haveibeenpwned.com password policy provider
In-Reply-To: <CAK-7U1gSb3VWbL4iSiEDEGnjSgBgWH7uFMohfHG4PROwxcCKZw@mail.gmail.com>
References: <CAK-7U1gSb3VWbL4iSiEDEGnjSgBgWH7uFMohfHG4PROwxcCKZw@mail.gmail.com>
Message-ID: <CACf1j=cTLj-=-4AYoH7WjMRNzhXdFe8K+ckS8FY58921zzQ4Zg@mail.gmail.com>

I personally think this is great. In many ways it covers the need for any
minimum complexity requirements, since most "obvious" passwords are in the
database if people use them. Also covers the much more common case now of
taking leaked passwords and attempting them on other sites.

On Sun, Jul 22, 2018 at 5:32 PM Thomas Darimont <
thomas.darimont at googlemail.com> wrote:

> Hello Keycloak Team,
>
> yesterday I implemented a password policy provider [0] for Keycloak
> which checks
> if a given password is contained in the password breach database
> haveibeenpwned.com.
>
> The policy provider uses their range based password search API [1] which
> uses
> a "k-Anonymity model" [2] which allows a password to be looked up by
> partial hash.
>
> The real password is never revealed to the service, only the first few
> bytes
> of the SHA-1 hash is used for the search which then returns a list of
> password hashes with
> the given prefix.
> Those hashes are then checked by the provider to see if the actual
> password was
> contained in the database and how often it occurred.
>
> Do you guys think that this could be something interesting to add to
> Keycloak?
>
> Cheers,
> Thomas
>
> [0]
> https://github.com/thomasdarimont/keycloak/tree/issue/KEYCLOAK-XXX-haveibeenpwned-password-policy
> [1] https://haveibeenpwned.com/API/v2#SearchingPwnedPasswordsByRange
> [2] https://en.wikipedia.org/wiki/K-anonymity
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>


-- 
Chris Pitman
Senior Architect, Red Hat Consulting

From h2-wada at nri.co.jp  Mon Jul 23 02:48:01 2018
From: h2-wada at nri.co.jp (Hiroyuki Wada)
Date: Mon, 23 Jul 2018 15:48:01 +0900
Subject: [keycloak-dev] Support for updating user with credentials in
 admin endpoints
In-Reply-To: <CAJgngAehdcXd9a0p1y4DFyrrNA7GkkpnYA6NzGXSh-r5GREMGw@mail.gmail.com>
References: <5B46F252.5090208@nri.co.jp>
	<CAK-7U1j3XxJZF9NBrSByh9O8HO0v_Ak7gNH0njRqPmKh77RCdQ@mail.gmail.com>
	<5B4729CC.4040801@nri.co.jp>
	<CAJgngAehdcXd9a0p1y4DFyrrNA7GkkpnYA6NzGXSh-r5GREMGw@mail.gmail.com>
Message-ID: <5B557A21.60904@nri.co.jp>

Thanks, I created a JIRA ticket and I'll submit a PR with tests.

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

Best Regards,

-- 
Hiroyuki Wada
Nomura Research Institute, Ltd.
h2-wada at nri.co.jp

--------------------------------------------------------------------
PLEASE READ:This e-mail is confidential and intended for
the named recipient only. If you are not an intended recipient,
please notify the sender and delete this e-mail.
--------------------------------------------------------------------


On 2018/07/17 3:39, Stian Thorgersen wrote:
> I don't see any issues with adding support for what you want. A PR would be
> welcome as long as it comes with proper level of testing.
>
> On Thu, 12 Jul 2018 at 12:29, Hiroyuki Wada <h2-wada at nri.co.jp> wrote:
>
>> Hello,
>>
>> Thanks for your comment.
>> I know we can use the reset-password endpoint for changing password, but
>> I want to update the user profile including credentials with single
>> request.
>> Also current reset-password endpoint only supports 'password' type
>> credential.
>> We also want to update other type credentials too.
>>
>> Best Regards
>>
>> On 2018/07/12 18:35, Thomas Darimont wrote:
>>> Hello,
>>>
>>> you can change the password a user via the keycloak admin-client with the
>>> resetPassword(...) method.
>>>      userRessource.get(userId).resetPassword(passwordCred);
>>> See:
>>>
>> https://gist.github.com/thomasdarimont/c4e739c5a319cf78a4cff3b87173a84b#file-keycloakadminclientexample-java-L94
>>>
>>> Cheers,
>>> Thomas
>>>
>>> On Thu, Jul 12, 2018 at 8:18 AM Hiroyuki Wada <h2-wada at nri.co.jp> wrote:
>>>
>>>> Hello,
>>>>
>>>> Currently the Admin REST API ignores credentials when updating the user.
>>>> I found the similar issue & discussion in the following links.
>>>> It was accepted but it only supports creating method.
>>>>
>>>> https://issues.jboss.org/browse/KEYCLOAK-5026
>>>> http://lists.jboss.org/pipermail/keycloak-dev/2017-June/009552.html
>>>>
>>>> In our case, we'd like to update users profile including any credentials
>>>> from
>>>> an external ID system.
>>>> Could I send a pull request for supporting it?
>>>>
>>>> Best Regards
>>>>
>>>> --
>>>> Hiroyuki Wada
>>>> Nomura Research Institute, Ltd.
>>>> h2-wada at nri.co.jp
>>>>
>>>> --------------------------------------------------------------------
>>>> PLEASE READ:This e-mail is confidential and intended for
>>>> the named recipient only. If you are not an intended recipient,
>>>> please notify the sender and delete this e-mail.
>>>> --------------------------------------------------------------------
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>>
>>
>> --
>> Hiroyuki Wada
>> Nomura Research Institute, Ltd.
>> h2-wada at nri.co.jp
>>
>> --------------------------------------------------------------------
>> PLEASE READ:This e-mail is confidential and intended for
>> the named recipient only. If you are not an intended recipient,
>> please notify the sender and delete this e-mail.
>> --------------------------------------------------------------------
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>

From felix.meissner at hanko.io  Mon Jul 23 06:32:10 2018
From: felix.meissner at hanko.io (=?UTF-8?Q?Felix_Mei=C3=9Fner?=)
Date: Mon, 23 Jul 2018 12:32:10 +0200
Subject: [keycloak-dev] html encoded url in form actions - bug or
	feature?
In-Reply-To: <CAJgngAexwQ-LhgDqNv=mRWa5wo1iy70HBN4FmsUQUMKZytFBtw@mail.gmail.com>
References: <CAC6ftk2u6dZhMwBOLoajqgAk8uEkdpNbr6H-=H=1WGO_H8evaA@mail.gmail.com>
	<977ae8fd-78b1-d8ed-56c0-988c413d76d7@redhat.com>
	<CAC6ftk2R4PKRsP_fGM+zEMF4ujexGBTsUqs=sX3oQmtf8jVsFw@mail.gmail.com>
	<CAJgngAexwQ-LhgDqNv=mRWa5wo1iy70HBN4FmsUQUMKZytFBtw@mail.gmail.com>
Message-ID: <CAC6ftk3+jBcW9hhmKv8D981h4DuXbA3FRf=BqMbV13=jTDif5Q@mail.gmail.com>

Thanks for pointing that out! I am trying to build a plugin that enables
out-of-band authentication with a FIDO UAF client on a mobile phone.
This video shows the behavior that we are trying to integrate into
keycloak: https://www.youtube.com/watch?v=aQFwvyDSOSM

I extend AbstractUsernameFormAuthenticator and make a blocking HTTP call
inside the action(AuthenticationFlowContext context)-method.
At UI side, I use Javascript to call the action method automatically when
the page opens. I can't submit the whole page as I need to provide a
working cancel button. When the call finishes, I follow the redirect
manually in javascript.

This is all work in progress and still quite hacky, comments and help are
very welcome. We plan to publish the source code when we finished our
prototype.

The escaped URLs are not an issue here, its just something I came along and
wanted to share.

Greetings, Felix


2018-07-20 12:28 GMT+02:00 Stian Thorgersen <sthorger at redhat.com>:

> What are you actually trying to do? Are you scraping the url from the
> login form? That's not really something you should be doing.
>
> On Thu, 19 Jul 2018 at 10:46, Felix Mei?ner <felix.meissner at hanko.io>
> wrote:
>
>> I expected URLs to be URL encoded, not HTML encoded. Nonetheless, I cannot
>> find any facts on how URLs should be encoded inside HTML, so maybe I am
>> wrong.
>> The problem occured, when I used a HTML-encoded URL inside JavaScript.
>> There, the URL will not be decoded before its sent to the server. When
>> used
>> in a form however, the browser will decode the URL before sending it.
>>
>> 2018-07-19 1:38 GMT+02:00 Stan Silvert <ssilvert at redhat.com>:
>>
>> > On 7/18/2018 2:37 AM, Felix Mei?ner wrote:
>> > > Hi all,
>> > >
>> > > I just discovered that the action url of the login-form seems to get
>> HTML
>> > > encoded and I woundered, if thats a bug or a feature.
>> > It's a security feature.  We take advantage of FreeMarker's "escape by
>> > default" feature.  As you discovered, you can use ?no_esc to turn this
>> off.
>> >
>> > I'm kind of interested in why fetch() didn't work.  The escaped version
>> > should be valid as a URL.
>> >
>> > >
>> > > In
>> > > https://github.com/keycloak/keycloak/blob/4.1.0.Final/
>> > themes/src/main/resources/theme/base/login/login.ftl
>> > > you can see the following line:
>> > >
>> > > <form id="kc-form-login" onsubmit="login.disabled = true; return
>> true;"
>> > > action="${url.loginAction}" method="post">
>> > >
>> > > On my instance, this resolves to something similar to this:
>> > >
>> > > <form id="kc-form-login" onsubmit="login.disabled = true; return
>> true;"
>> > > action="
>> > > https://xx.xx.xx.xx:8443/auth/realms/master/login-actions/
>> > authenticate?session_code=tyvLn2J3QkM4YJhPzjYKnNLSG4ej89
>> > Xabvspm7nmubc&amp;execution=5c933fb0-b637-4462-a603-
>> > bf9ffb601220&amp;client_id=security-admin-console&amp;
>> tab_id=2tJInt2M5NE"
>> > > method="post">
>> > >
>> > > All "&" are encoded as &amp;. This became an issue for me, when I
>> tried
>> > to
>> > > call the url via JavaScripts fetch method. With the same URL, I got a
>> > > sevrer error. When changing the URL to:
>> > >
>> > > fetch("${url.loginAction?no_esc}", ...)
>> > >
>> > > it finally worked.
>> > >
>> > > Shouldn't all form-urls and href-urls not be escacped? What makes me
>> > wonder
>> > > is, that the same URL just works for regular post requests! For
>> > > documentation on escaping you can find more information here:
>> > > https://freemarker.apache.org/docs/dgui_quickstart_template.
>> > html#dgui_quickstart_template_autoescaping
>> > >
>> > > Greetings,
>> > > Felix
>> > >
>> >
>> > _______________________________________________
>> > keycloak-dev mailing list
>> > keycloak-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>> --
>> Ein Produkt der Cap3 GmbH, Ringstr. 19, 24114 Kiel, Deutschland
>>
>> Registergericht: Amtsgericht Kiel, HRB 13257
>> Gesch?ftsf?hrung: Felix
>> Magedanz, Nicolas G?nther, Bettual Richter, S?ren Fenner
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>

-- 
Ein Produkt der?Cap3 GmbH, Ringstr. 19, 24114 Kiel, Deutschland

Registergericht: Amtsgericht Kiel, HRB 13257
Gesch?ftsf?hrung: Felix 
Magedanz, Nicolas G?nther, Bettual Richter, S?ren Fenner

From slaskawi at redhat.com  Wed Jul 25 07:20:39 2018
From: slaskawi at redhat.com (Sebastian Laskawiec)
Date: Wed, 25 Jul 2018 13:20:39 +0200
Subject: [keycloak-dev] Proposal - use Ant Plugin for generating JKS files
Message-ID: <CAA9R9O6Q+xTcngkFEkS7WSXzRxh=Vj5cS8Ou32-LqAZqdKaEAw@mail.gmail.com>

Hey,

Together with Sebi we are working on Certificate-based authentication for
the clients. Our work will require adding at least 2-3 keystores to the
codebase with different DNs and I think this might be a good opportunity to
revisit the way we handle JKS files in the tests.

Currently we push JKS files directly into our repo, which has a couple of
drawbacks:
- it is hard to figure out what's inside the JKS, it requires looking up
for password (usually in some JSON configuration file or hardcoded in the
test) and using keytool (or some similar one) to explore its content.
- It is not git-friendly. Every time we update JKS content we effectively
store another binary file (git doesn't understand binary file changes and
can not diff it).
- we use many different naming and password schemes in our tests.
- it is hard to migrate all keystores to pkcs12 at the same time (JKS
format is deprecated) [0]

I believe most of the issues could be addressed by generating JKS files on
the fly - during the build. In Infinispan we did it with Maven Ant Plugin
[1]. I already created a very limited POC for Keycloak and you can check it
out here [2]. Unfortunately, the process of reverse engineering all those
files is quite time-consuming, so I would like to know your opinion before
moving on.

Of course, generating JKS files on the fly has some drawbacks:
- It increases build time (~1s per keytool invocation, and we probably will
have more than 30 of them).
- it makes testing from IDE a bit harder, you need to run Maven and process
test resources before doing anything. A common workaround is to use `mvn
clean install -DskipTests` and then opening your IntelliJ.

Please let me know what you think.

Thanks,
Sebastian

[0]
https://blogs.oracle.com/jtc/jdk9-keytool-transitions-default-keystore-to-pkcs12
[1]
https://github.com/infinispan/infinispan/blob/master/server/integration/testsuite/pom.xml#L460
[2] https://github.com/keycloak/keycloak/pull/5410

From pskopek at redhat.com  Wed Jul 25 08:07:01 2018
From: pskopek at redhat.com (Peter Skopek)
Date: Wed, 25 Jul 2018 14:07:01 +0200
Subject: [keycloak-dev] Proposal - use Ant Plugin for generating JKS
	files
In-Reply-To: <CAA9R9O6Q+xTcngkFEkS7WSXzRxh=Vj5cS8Ou32-LqAZqdKaEAw@mail.gmail.com>
References: <CAA9R9O6Q+xTcngkFEkS7WSXzRxh=Vj5cS8Ou32-LqAZqdKaEAw@mail.gmail.com>
Message-ID: <CAM01paZgQCsvo72HPnvDG1fv3vSUfzHt6i2e4c3Oker0Z1fjEw@mail.gmail.com>

Hi Sebastian,

I think that generation of Keystore on the fly is the only way to go.
You can use Java Keystore API generate it entirely from Java code (no
need to run maven).

Here [1] is an example of utility class used in wildfly testsuite to
generate Vault (basically just keystore).
It will be easy to strip vault related stuff and use it in our testsuite.

Note that there is one more drawback of storing generated JKS files,
which is that in some cases they are not binary compatible between
different JDK (particularly Oracle and IBM).

HTH,
Peter

[1] https://github.com/wildfly/wildfly/blob/master/testsuite/shared/src/main/java/org/jboss/as/test/integration/security/common/VaultHandler.java
On Wed, Jul 25, 2018 at 1:23 PM Sebastian Laskawiec <slaskawi at redhat.com> wrote:
>
> Hey,
>
> Together with Sebi we are working on Certificate-based authentication for
> the clients. Our work will require adding at least 2-3 keystores to the
> codebase with different DNs and I think this might be a good opportunity to
> revisit the way we handle JKS files in the tests.
>
> Currently we push JKS files directly into our repo, which has a couple of
> drawbacks:
> - it is hard to figure out what's inside the JKS, it requires looking up
> for password (usually in some JSON configuration file or hardcoded in the
> test) and using keytool (or some similar one) to explore its content.
> - It is not git-friendly. Every time we update JKS content we effectively
> store another binary file (git doesn't understand binary file changes and
> can not diff it).
> - we use many different naming and password schemes in our tests.
> - it is hard to migrate all keystores to pkcs12 at the same time (JKS
> format is deprecated) [0]
>
> I believe most of the issues could be addressed by generating JKS files on
> the fly - during the build. In Infinispan we did it with Maven Ant Plugin
> [1]. I already created a very limited POC for Keycloak and you can check it
> out here [2]. Unfortunately, the process of reverse engineering all those
> files is quite time-consuming, so I would like to know your opinion before
> moving on.
>
> Of course, generating JKS files on the fly has some drawbacks:
> - It increases build time (~1s per keytool invocation, and we probably will
> have more than 30 of them).
> - it makes testing from IDE a bit harder, you need to run Maven and process
> test resources before doing anything. A common workaround is to use `mvn
> clean install -DskipTests` and then opening your IntelliJ.
>
> Please let me know what you think.
>
> Thanks,
> Sebastian
>
> [0]
> https://blogs.oracle.com/jtc/jdk9-keytool-transitions-default-keystore-to-pkcs12
> [1]
> https://github.com/infinispan/infinispan/blob/master/server/integration/testsuite/pom.xml#L460
> [2] https://github.com/keycloak/keycloak/pull/5410
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From slaskawi at redhat.com  Wed Jul 25 09:22:59 2018
From: slaskawi at redhat.com (Sebastian Laskawiec)
Date: Wed, 25 Jul 2018 15:22:59 +0200
Subject: [keycloak-dev] Proposal - use Ant Plugin for generating JKS
	files
In-Reply-To: <CAM01paZgQCsvo72HPnvDG1fv3vSUfzHt6i2e4c3Oker0Z1fjEw@mail.gmail.com>
References: <CAA9R9O6Q+xTcngkFEkS7WSXzRxh=Vj5cS8Ou32-LqAZqdKaEAw@mail.gmail.com>
	<CAM01paZgQCsvo72HPnvDG1fv3vSUfzHt6i2e4c3Oker0Z1fjEw@mail.gmail.com>
Message-ID: <CAA9R9O4OkbROORp1zncWFN4rs49H6BcPZ7vv91KH=wNZ=MmtmA@mail.gmail.com>

Thanks Darran and Peter for the insight!

I've just noticed that generating JKS files is one thing but we will also
need to pre-process RealmRepresentation and replace all private/public keys
(like this one for example [1]) with values from keystores/truststores.

At the moment I'm thinking about replacing [1] with something like this:
"jwt.credential.certificate" :
"certificate:keystore=classpath:keystore.jks,password=password,alias=secure-portal,type=pkcs12"
similarly to private keys (if needed):
"privateKey" :
"private-key:keystore=classpath:keystore.jks,password=password,alias=secure-portal,type=pkcs12"

Later on, while converting JSON to RealmRepresentation I plan to traverse
all nodes and replace replace those which start with private-key or
certificate.

Let me know if you have a better idea.

[1]
https://github.com/keycloak/keycloak/blob/master/testsuite/integration-arquillian/tests/base/src/test/resources/adapter-test/demorealm.json#L231

On Wed, Jul 25, 2018 at 2:07 PM Peter Skopek <pskopek at redhat.com> wrote:

> Hi Sebastian,
>
> I think that generation of Keystore on the fly is the only way to go.
> You can use Java Keystore API generate it entirely from Java code (no
> need to run maven).
>
> Here [1] is an example of utility class used in wildfly testsuite to
> generate Vault (basically just keystore).
> It will be easy to strip vault related stuff and use it in our testsuite.
>
> Note that there is one more drawback of storing generated JKS files,
> which is that in some cases they are not binary compatible between
> different JDK (particularly Oracle and IBM).
>
> HTH,
> Peter
>
> [1]
> https://github.com/wildfly/wildfly/blob/master/testsuite/shared/src/main/java/org/jboss/as/test/integration/security/common/VaultHandler.java
> On Wed, Jul 25, 2018 at 1:23 PM Sebastian Laskawiec <slaskawi at redhat.com>
> wrote:
> >
> > Hey,
> >
> > Together with Sebi we are working on Certificate-based authentication for
> > the clients. Our work will require adding at least 2-3 keystores to the
> > codebase with different DNs and I think this might be a good opportunity
> to
> > revisit the way we handle JKS files in the tests.
> >
> > Currently we push JKS files directly into our repo, which has a couple of
> > drawbacks:
> > - it is hard to figure out what's inside the JKS, it requires looking up
> > for password (usually in some JSON configuration file or hardcoded in the
> > test) and using keytool (or some similar one) to explore its content.
> > - It is not git-friendly. Every time we update JKS content we effectively
> > store another binary file (git doesn't understand binary file changes and
> > can not diff it).
> > - we use many different naming and password schemes in our tests.
> > - it is hard to migrate all keystores to pkcs12 at the same time (JKS
> > format is deprecated) [0]
> >
> > I believe most of the issues could be addressed by generating JKS files
> on
> > the fly - during the build. In Infinispan we did it with Maven Ant Plugin
> > [1]. I already created a very limited POC for Keycloak and you can check
> it
> > out here [2]. Unfortunately, the process of reverse engineering all those
> > files is quite time-consuming, so I would like to know your opinion
> before
> > moving on.
> >
> > Of course, generating JKS files on the fly has some drawbacks:
> > - It increases build time (~1s per keytool invocation, and we probably
> will
> > have more than 30 of them).
> > - it makes testing from IDE a bit harder, you need to run Maven and
> process
> > test resources before doing anything. A common workaround is to use `mvn
> > clean install -DskipTests` and then opening your IntelliJ.
> >
> > Please let me know what you think.
> >
> > Thanks,
> > Sebastian
> >
> > [0]
> >
> https://blogs.oracle.com/jtc/jdk9-keytool-transitions-default-keystore-to-pkcs12
> > [1]
> >
> https://github.com/infinispan/infinispan/blob/master/server/integration/testsuite/pom.xml#L460
> > [2] https://github.com/keycloak/keycloak/pull/5410
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sthorger at redhat.com  Wed Jul 25 09:50:25 2018
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 25 Jul 2018 15:50:25 +0200
Subject: [keycloak-dev] Proposal - use Ant Plugin for generating JKS
	files
In-Reply-To: <CAA9R9O4OkbROORp1zncWFN4rs49H6BcPZ7vv91KH=wNZ=MmtmA@mail.gmail.com>
References: <CAA9R9O6Q+xTcngkFEkS7WSXzRxh=Vj5cS8Ou32-LqAZqdKaEAw@mail.gmail.com>
	<CAM01paZgQCsvo72HPnvDG1fv3vSUfzHt6i2e4c3Oker0Z1fjEw@mail.gmail.com>
	<CAA9R9O4OkbROORp1zncWFN4rs49H6BcPZ7vv91KH=wNZ=MmtmA@mail.gmail.com>
Message-ID: <CAJgngAc2Y4bwgNPumnvPrf9wW7eH4GjR6FT2QE+541peYOOFuA@mail.gmail.com>

Sounds like this could be a time-consuming task and the tests are working
at the moment. So not sure I see a need to start a bulk refactoring here.
The json file you're mentioning has a cert in pem format in the json file
that is then stored in the DB. This doesn't have anything to do with
keystores/truststores. We expect Keycloak to be able to handle a cert
provided in the json file (or through admin endpoints) and store it in the
DB.

Now for SSL tests with the server itself I can see the value in what you
are proposing. Keystore/truststore for Keycloak https connections and
truststores for mutual SSL could probably be improved. However, it seems to
be working at the moment, so not sure this is required.

On Wed, 25 Jul 2018 at 15:30, Sebastian Laskawiec <slaskawi at redhat.com>
wrote:

> Thanks Darran and Peter for the insight!
>
> I've just noticed that generating JKS files is one thing but we will also
> need to pre-process RealmRepresentation and replace all private/public keys
> (like this one for example [1]) with values from keystores/truststores.
>
> At the moment I'm thinking about replacing [1] with something like this:
> "jwt.credential.certificate" :
>
> "certificate:keystore=classpath:keystore.jks,password=password,alias=secure-portal,type=pkcs12"
> similarly to private keys (if needed):
> "privateKey" :
>
> "private-key:keystore=classpath:keystore.jks,password=password,alias=secure-portal,type=pkcs12"
>
> Later on, while converting JSON to RealmRepresentation I plan to traverse
> all nodes and replace replace those which start with private-key or
> certificate.
>
> Let me know if you have a better idea.
>
> [1]
>
> https://github.com/keycloak/keycloak/blob/master/testsuite/integration-arquillian/tests/base/src/test/resources/adapter-test/demorealm.json#L231
>
> On Wed, Jul 25, 2018 at 2:07 PM Peter Skopek <pskopek at redhat.com> wrote:
>
> > Hi Sebastian,
> >
> > I think that generation of Keystore on the fly is the only way to go.
> > You can use Java Keystore API generate it entirely from Java code (no
> > need to run maven).
> >
> > Here [1] is an example of utility class used in wildfly testsuite to
> > generate Vault (basically just keystore).
> > It will be easy to strip vault related stuff and use it in our testsuite.
> >
> > Note that there is one more drawback of storing generated JKS files,
> > which is that in some cases they are not binary compatible between
> > different JDK (particularly Oracle and IBM).
> >
> > HTH,
> > Peter
> >
> > [1]
> >
> https://github.com/wildfly/wildfly/blob/master/testsuite/shared/src/main/java/org/jboss/as/test/integration/security/common/VaultHandler.java
> > On Wed, Jul 25, 2018 at 1:23 PM Sebastian Laskawiec <slaskawi at redhat.com
> >
> > wrote:
> > >
> > > Hey,
> > >
> > > Together with Sebi we are working on Certificate-based authentication
> for
> > > the clients. Our work will require adding at least 2-3 keystores to the
> > > codebase with different DNs and I think this might be a good
> opportunity
> > to
> > > revisit the way we handle JKS files in the tests.
> > >
> > > Currently we push JKS files directly into our repo, which has a couple
> of
> > > drawbacks:
> > > - it is hard to figure out what's inside the JKS, it requires looking
> up
> > > for password (usually in some JSON configuration file or hardcoded in
> the
> > > test) and using keytool (or some similar one) to explore its content.
> > > - It is not git-friendly. Every time we update JKS content we
> effectively
> > > store another binary file (git doesn't understand binary file changes
> and
> > > can not diff it).
> > > - we use many different naming and password schemes in our tests.
> > > - it is hard to migrate all keystores to pkcs12 at the same time (JKS
> > > format is deprecated) [0]
> > >
> > > I believe most of the issues could be addressed by generating JKS files
> > on
> > > the fly - during the build. In Infinispan we did it with Maven Ant
> Plugin
> > > [1]. I already created a very limited POC for Keycloak and you can
> check
> > it
> > > out here [2]. Unfortunately, the process of reverse engineering all
> those
> > > files is quite time-consuming, so I would like to know your opinion
> > before
> > > moving on.
> > >
> > > Of course, generating JKS files on the fly has some drawbacks:
> > > - It increases build time (~1s per keytool invocation, and we probably
> > will
> > > have more than 30 of them).
> > > - it makes testing from IDE a bit harder, you need to run Maven and
> > process
> > > test resources before doing anything. A common workaround is to use
> `mvn
> > > clean install -DskipTests` and then opening your IntelliJ.
> > >
> > > Please let me know what you think.
> > >
> > > Thanks,
> > > Sebastian
> > >
> > > [0]
> > >
> >
> https://blogs.oracle.com/jtc/jdk9-keytool-transitions-default-keystore-to-pkcs12
> > > [1]
> > >
> >
> https://github.com/infinispan/infinispan/blob/master/server/integration/testsuite/pom.xml#L460
> > > [2] https://github.com/keycloak/keycloak/pull/5410
> > > _______________________________________________
> > > keycloak-dev mailing list
> > > keycloak-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From Sebastian.Schuster at bosch-si.com  Wed Jul 25 10:02:16 2018
From: Sebastian.Schuster at bosch-si.com (Schuster Sebastian (INST/ESY1))
Date: Wed, 25 Jul 2018 14:02:16 +0000
Subject: [keycloak-dev] Introduce role attributes
In-Reply-To: <CAJgngAfsEfBuaEdAtnpMQjdk4O6oN_5w740Q5D=RnAZ8jNrqxQ@mail.gmail.com>
References: <f290648bf6f24a3994138d5529891d63@BOSKGEXC01.boskg.local>
	<CAJgngAfsEfBuaEdAtnpMQjdk4O6oN_5w740Q5D=RnAZ8jNrqxQ@mail.gmail.com>
Message-ID: <b2027d2364e149149d66806febdf55d1@bosch-si.com>

We also have the same requirements but would use it mostly for role metadata. This would not be used in a token but for thinks like after assigning a role to a user sending an email to the person responsible for that role. This is required for compliance reasons. We would strongly prefer to store this data in Keycloak as custom role attributes instead of maintaining it somewhere else...

Best regards,
Sebastian

Mit freundlichen Gr??en / Best regards

Dr.-Ing.  Sebastian Schuster

Engineering and Support (INST/ESY1) 
Bosch?Software Innovations?GmbH | Ullsteinstr. 128 | 12109 Berlin | GERMANY | www.bosch-si.com
Tel. +49 30 726112-485 | Fax +49 30 726112-100 | Sebastian.Schuster at bosch-si.com

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




-----Original Message-----
From: keycloak-dev-bounces at lists.jboss.org <keycloak-dev-bounces at lists.jboss.org> On Behalf Of Stian Thorgersen
Sent: Montag, 16. Juli 2018 20:27
To: Sebastian.Loesch at governikus.de
Cc: keycloak-dev <keycloak-dev at lists.jboss.org>
Subject: Re: [keycloak-dev] Introduce role attributes

I don't think we should add attributes to roles. It would introduce complexity and also potentially have performance/memory impacts.

I also struggle to see how you would use attributes associated with roles.
Are you thinking that would be mapped into the token together with the role name?

On Tue, 3 Jul 2018 at 07:37, L?sch, Sebastian < Sebastian.Loesch at governikus.de> wrote:

> Hi developers,
>
> we are currently setting up a project using keycloak and need to model:
> - representative roles, i.e. roles that are given temporarily from one 
> user to another e.g. in holiday times
> - roles contain entitlements on business objects
>
> The current role object in keycloak is not sufficent for our use cases.
> Searching for a solution I stumbled over
> https://issues.jboss.org/browse/KEYCLOAK-961
> Introducing role attributes would solve my challenges. Also this fits 
> well in the keycloak data model, as there are already user attributes, 
> group attributes, realm attributes.
>
> So I would like to add role attributes to keycloak in the style of 
> group attributes.
> What do you think?
>
> Best regards,
> Sebastian
>
> _______________________________________________
> 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  Wed Jul 25 10:28:46 2018
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Wed, 25 Jul 2018 17:28:46 +0300
Subject: [keycloak-dev] Introduce role attributes
In-Reply-To: <b2027d2364e149149d66806febdf55d1@bosch-si.com>
References: <f290648bf6f24a3994138d5529891d63@BOSKGEXC01.boskg.local>
	<CAJgngAfsEfBuaEdAtnpMQjdk4O6oN_5w740Q5D=RnAZ8jNrqxQ@mail.gmail.com>
	<b2027d2364e149149d66806febdf55d1@bosch-si.com>
Message-ID: <CAK-7U1hGpsfeQMAhtx2TSvB7-whq4gwMf-HpHf-5b2oCDOij7Q@mail.gmail.com>

Another use case could be supporting segregation of duties (SoD). A role
could list a set of mutual exclusive roles that cannot be assigned to a
user at the same time.

Schuster Sebastian (INST/ESY1) <Sebastian.Schuster at bosch-si.com> schrieb am
Mi., 25. Juli 2018, 17:03:

> We also have the same requirements but would use it mostly for role
> metadata. This would not be used in a token but for thinks like after
> assigning a role to a user sending an email to the person responsible for
> that role. This is required for compliance reasons. We would strongly
> prefer to store this data in Keycloak as custom role attributes instead of
> maintaining it somewhere else...
>
> Best regards,
> Sebastian
>
> Mit freundlichen Gr??en / Best regards
>
> Dr.-Ing.  Sebastian Schuster
>
> Engineering and Support (INST/ESY1)
> Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin |
> GERMANY | www.bosch-si.com
> Tel. +49 30 726112-485 | Fax +49 30 726112-100 |
> Sebastian.Schuster at bosch-si.com
>
> Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
> Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten L?cke; Gesch?ftsf?hrung: Dr.
> Stefan Ferber, Michael Hahn
>
>
>
>
> -----Original Message-----
> From: keycloak-dev-bounces at lists.jboss.org <
> keycloak-dev-bounces at lists.jboss.org> On Behalf Of Stian Thorgersen
> Sent: Montag, 16. Juli 2018 20:27
> To: Sebastian.Loesch at governikus.de
> Cc: keycloak-dev <keycloak-dev at lists.jboss.org>
> Subject: Re: [keycloak-dev] Introduce role attributes
>
> I don't think we should add attributes to roles. It would introduce
> complexity and also potentially have performance/memory impacts.
>
> I also struggle to see how you would use attributes associated with roles.
> Are you thinking that would be mapped into the token together with the
> role name?
>
> On Tue, 3 Jul 2018 at 07:37, L?sch, Sebastian <
> Sebastian.Loesch at governikus.de> wrote:
>
> > Hi developers,
> >
> > we are currently setting up a project using keycloak and need to model:
> > - representative roles, i.e. roles that are given temporarily from one
> > user to another e.g. in holiday times
> > - roles contain entitlements on business objects
> >
> > The current role object in keycloak is not sufficent for our use cases.
> > Searching for a solution I stumbled over
> > https://issues.jboss.org/browse/KEYCLOAK-961
> > Introducing role attributes would solve my challenges. Also this fits
> > well in the keycloak data model, as there are already user attributes,
> > group attributes, realm attributes.
> >
> > So I would like to add role attributes to keycloak in the style of
> > group attributes.
> > What do you think?
> >
> > Best regards,
> > Sebastian
> >
> > _______________________________________________
> > 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 Sebastian.Schuster at bosch-si.com  Wed Jul 25 11:10:22 2018
From: Sebastian.Schuster at bosch-si.com (Schuster Sebastian (INST/ESY1))
Date: Wed, 25 Jul 2018 15:10:22 +0000
Subject: [keycloak-dev] Possible Bug when listing users with fine-grained
	permissions
Message-ID: <5ccc909b43154c09a3b4937f602f9e00@bosch-si.com>

Hello,

we are currently experiencing issues with the "View all users" functionality of the Keycloak Admin Console and the respective API call to /auth/admin/realms/{realm}/users when using the permissions based on the authorization services. In our case, we have users separated into groups and some users are able to view these by means of having the realm-management.query-users role and the group.view-members scope by means of a permission/policy. When such a user tries to view all the users he can see, he only gets a subset or even none.

The reason is that in UsersResource, first a paginated subset of users is retrieved that is than filtered by checking visibility for each user. In general, this will return less users than the page and the admin UI will not offer to go to the next page. Even if it did, with many users where you can see only a small subset having to skip over lots of empty pages won?t be feasible.

Since we really like to use this feature, we discussed several options to fix it:

1.     Keycloak should query for users until it reaches the number of requested viewable users or until it has evaluated all available users (-> can lead to performance issues with an increasing number of users, in the worst case Keycloak needs to pull all users out of the database just to find out the current user might see none)

2.     Do the same thing but in the admin console (-> no changes in Keycloak but lots of request, probably even worse idea)

3.     Since groups are the resources a user needs to have view-members scope to see users, retrieve all groups from the database, filter out groups without view-members scope and then do a join by group membership and limit the result by paging. (-> less generalized approach, probably better performance as long as there are not too many groups)

All of these seem to be far less than ideal.

Any thoughts?

Best regards,
Sebastian

Mit freundlichen Gr??en / Best regards

Dr.-Ing. Sebastian Schuster

Engineering and Support (INST/ESY1)
Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin | GERMANY | www.bosch-si.com<http://www.bosch-si.com>
Tel. +49 30 726112-485 | Fax +49 30 726112-100 | Sebastian.Schuster at bosch-si.com<mailto:Sebastian.Schuster at bosch-si.com>

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




From mposolda at redhat.com  Wed Jul 25 13:26:53 2018
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 25 Jul 2018 19:26:53 +0200
Subject: [keycloak-dev] haveibeenpwned.com password policy provider
In-Reply-To: <CACf1j=cTLj-=-4AYoH7WjMRNzhXdFe8K+ckS8FY58921zzQ4Zg@mail.gmail.com>
References: <CAK-7U1gSb3VWbL4iSiEDEGnjSgBgWH7uFMohfHG4PROwxcCKZw@mail.gmail.com>
	<CACf1j=cTLj-=-4AYoH7WjMRNzhXdFe8K+ckS8FY58921zzQ4Zg@mail.gmail.com>
Message-ID: <ff739beb-3af4-3a59-8754-b398684553af@redhat.com>

This is interesting, but I am not 100% sure if it's something to be 
supported in Keycloak OOTB. Every built-in provider adds some 
complexity, needs of maintenance/refactoring etc. Maybe something to be 
added to our extensions page [1] ?

[1] https://www.keycloak.org/extensions.html

Marek

On 23/07/18 00:26, Chris Pitman wrote:
> I personally think this is great. In many ways it covers the need for any
> minimum complexity requirements, since most "obvious" passwords are in the
> database if people use them. Also covers the much more common case now of
> taking leaked passwords and attempting them on other sites.
>
> On Sun, Jul 22, 2018 at 5:32 PM Thomas Darimont <
> thomas.darimont at googlemail.com> wrote:
>
>> Hello Keycloak Team,
>>
>> yesterday I implemented a password policy provider [0] for Keycloak
>> which checks
>> if a given password is contained in the password breach database
>> haveibeenpwned.com.
>>
>> The policy provider uses their range based password search API [1] which
>> uses
>> a "k-Anonymity model" [2] which allows a password to be looked up by
>> partial hash.
>>
>> The real password is never revealed to the service, only the first few
>> bytes
>> of the SHA-1 hash is used for the search which then returns a list of
>> password hashes with
>> the given prefix.
>> Those hashes are then checked by the provider to see if the actual
>> password was
>> contained in the database and how often it occurred.
>>
>> Do you guys think that this could be something interesting to add to
>> Keycloak?
>>
>> Cheers,
>> Thomas
>>
>> [0]
>> https://github.com/thomasdarimont/keycloak/tree/issue/KEYCLOAK-XXX-haveibeenpwned-password-policy
>> [1] https://haveibeenpwned.com/API/v2#SearchingPwnedPasswordsByRange
>> [2] https://en.wikipedia.org/wiki/K-anonymity
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>


From mposolda at redhat.com  Wed Jul 25 14:16:41 2018
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 25 Jul 2018 20:16:41 +0200
Subject: [keycloak-dev] Proposal - use Ant Plugin for generating JKS
	files
In-Reply-To: <CAJgngAc2Y4bwgNPumnvPrf9wW7eH4GjR6FT2QE+541peYOOFuA@mail.gmail.com>
References: <CAA9R9O6Q+xTcngkFEkS7WSXzRxh=Vj5cS8Ou32-LqAZqdKaEAw@mail.gmail.com>
	<CAM01paZgQCsvo72HPnvDG1fv3vSUfzHt6i2e4c3Oker0Z1fjEw@mail.gmail.com>
	<CAA9R9O4OkbROORp1zncWFN4rs49H6BcPZ7vv91KH=wNZ=MmtmA@mail.gmail.com>
	<CAJgngAc2Y4bwgNPumnvPrf9wW7eH4GjR6FT2QE+541peYOOFuA@mail.gmail.com>
Message-ID: <ae4502c8-bb13-fd8a-ac28-8a90d57f67d7@redhat.com>

IMO Creating keystore files programatically as Peter suggested, looks 
better than creating them through maven-antrun-plugin. It seems that 
creating with maven will mean lots of the stuff in pom.xml files, 
however generating programatically will probably allow some better 
reusability (common utility class in the testsuite to easily generate 
keystore in various locations). Also programatic generation will work 
when running the test from Intellij Idea without previous maven build.

Sebastian, yesterday I didn't mention on the call that we probably don't 
test X509 authentication with IBM JDK. I recalled it just now :)? The 
thing is, that X509 tests are not executed during default build as they 
require Wildfly (they don't work on embedded undertow) and also 
phantomJS (no other browser is supported). So I am pretty sure they are 
not executed during the various matrix jobs for various java versions 
(Vasek Muzikar can correct me if I am wrong). Which means they probably 
don't work on IBM JDK too.

Marek


On 25/07/18 15:50, Stian Thorgersen wrote:
> Sounds like this could be a time-consuming task and the tests are working
> at the moment. So not sure I see a need to start a bulk refactoring here.
> The json file you're mentioning has a cert in pem format in the json file
> that is then stored in the DB. This doesn't have anything to do with
> keystores/truststores. We expect Keycloak to be able to handle a cert
> provided in the json file (or through admin endpoints) and store it in the
> DB.
>
> Now for SSL tests with the server itself I can see the value in what you
> are proposing. Keystore/truststore for Keycloak https connections and
> truststores for mutual SSL could probably be improved. However, it seems to
> be working at the moment, so not sure this is required.
>
> On Wed, 25 Jul 2018 at 15:30, Sebastian Laskawiec <slaskawi at redhat.com>
> wrote:
>
>> Thanks Darran and Peter for the insight!
>>
>> I've just noticed that generating JKS files is one thing but we will also
>> need to pre-process RealmRepresentation and replace all private/public keys
>> (like this one for example [1]) with values from keystores/truststores.
>>
>> At the moment I'm thinking about replacing [1] with something like this:
>> "jwt.credential.certificate" :
>>
>> "certificate:keystore=classpath:keystore.jks,password=password,alias=secure-portal,type=pkcs12"
>> similarly to private keys (if needed):
>> "privateKey" :
>>
>> "private-key:keystore=classpath:keystore.jks,password=password,alias=secure-portal,type=pkcs12"
>>
>> Later on, while converting JSON to RealmRepresentation I plan to traverse
>> all nodes and replace replace those which start with private-key or
>> certificate.
>>
>> Let me know if you have a better idea.
>>
>> [1]
>>
>> https://github.com/keycloak/keycloak/blob/master/testsuite/integration-arquillian/tests/base/src/test/resources/adapter-test/demorealm.json#L231
>>
>> On Wed, Jul 25, 2018 at 2:07 PM Peter Skopek <pskopek at redhat.com> wrote:
>>
>>> Hi Sebastian,
>>>
>>> I think that generation of Keystore on the fly is the only way to go.
>>> You can use Java Keystore API generate it entirely from Java code (no
>>> need to run maven).
>>>
>>> Here [1] is an example of utility class used in wildfly testsuite to
>>> generate Vault (basically just keystore).
>>> It will be easy to strip vault related stuff and use it in our testsuite.
>>>
>>> Note that there is one more drawback of storing generated JKS files,
>>> which is that in some cases they are not binary compatible between
>>> different JDK (particularly Oracle and IBM).
>>>
>>> HTH,
>>> Peter
>>>
>>> [1]
>>>
>> https://github.com/wildfly/wildfly/blob/master/testsuite/shared/src/main/java/org/jboss/as/test/integration/security/common/VaultHandler.java
>>> On Wed, Jul 25, 2018 at 1:23 PM Sebastian Laskawiec <slaskawi at redhat.com
>>>
>>> wrote:
>>>> Hey,
>>>>
>>>> Together with Sebi we are working on Certificate-based authentication
>> for
>>>> the clients. Our work will require adding at least 2-3 keystores to the
>>>> codebase with different DNs and I think this might be a good
>> opportunity
>>> to
>>>> revisit the way we handle JKS files in the tests.
>>>>
>>>> Currently we push JKS files directly into our repo, which has a couple
>> of
>>>> drawbacks:
>>>> - it is hard to figure out what's inside the JKS, it requires looking
>> up
>>>> for password (usually in some JSON configuration file or hardcoded in
>> the
>>>> test) and using keytool (or some similar one) to explore its content.
>>>> - It is not git-friendly. Every time we update JKS content we
>> effectively
>>>> store another binary file (git doesn't understand binary file changes
>> and
>>>> can not diff it).
>>>> - we use many different naming and password schemes in our tests.
>>>> - it is hard to migrate all keystores to pkcs12 at the same time (JKS
>>>> format is deprecated) [0]
>>>>
>>>> I believe most of the issues could be addressed by generating JKS files
>>> on
>>>> the fly - during the build. In Infinispan we did it with Maven Ant
>> Plugin
>>>> [1]. I already created a very limited POC for Keycloak and you can
>> check
>>> it
>>>> out here [2]. Unfortunately, the process of reverse engineering all
>> those
>>>> files is quite time-consuming, so I would like to know your opinion
>>> before
>>>> moving on.
>>>>
>>>> Of course, generating JKS files on the fly has some drawbacks:
>>>> - It increases build time (~1s per keytool invocation, and we probably
>>> will
>>>> have more than 30 of them).
>>>> - it makes testing from IDE a bit harder, you need to run Maven and
>>> process
>>>> test resources before doing anything. A common workaround is to use
>> `mvn
>>>> clean install -DskipTests` and then opening your IntelliJ.
>>>>
>>>> Please let me know what you think.
>>>>
>>>> Thanks,
>>>> Sebastian
>>>>
>>>> [0]
>>>>
>> https://blogs.oracle.com/jtc/jdk9-keytool-transitions-default-keystore-to-pkcs12
>>>> [1]
>>>>
>> https://github.com/infinispan/infinispan/blob/master/server/integration/testsuite/pom.xml#L460
>>>> [2] https://github.com/keycloak/keycloak/pull/5410
>>>> _______________________________________________
>>>> 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 takashi.norimatsu.ws at hitachi.com  Wed Jul 25 19:13:35 2018
From: takashi.norimatsu.ws at hitachi.com (=?utf-8?B?5LmX5p2+6ZqG5b+XIC8gTk9SSU1BVFNV77yMVEFLQVNISQ==?=)
Date: Wed, 25 Jul 2018 23:13:35 +0000
Subject: [keycloak-dev] OAuth 2.0 Mutual TLS Client Authentication
Message-ID: <OSAPR01MB264258AF4E777740E517BDA6CE540@OSAPR01MB2642.jpnprd01.prod.outlook.com>

Hello,

As for mentioned in https://issues.jboss.org/browse/KEYCLOAK-7512 and https://issues.jboss.org/browse/KEYCLOAK-7635, Is there anyone who currently implements OAuth 2.0 Mutual TLS Client Authentication defined in https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-2 ?

If no one does it, I would like to try to implement this feature. What do you think about it ?

Also, In https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-2, two types of OAuth 2.0 Mutual TLS Client Authentication are defined, for PKI and for Self-Signed Certificate.

I would be happy if you who are interested in this feature tell me which you like better.

Best regards,
Takashi Norimatsu
Hitachi Ltd.,


From slaskawi at redhat.com  Thu Jul 26 04:23:45 2018
From: slaskawi at redhat.com (Sebastian Laskawiec)
Date: Thu, 26 Jul 2018 10:23:45 +0200
Subject: [keycloak-dev] OAuth 2.0 Mutual TLS Client Authentication
In-Reply-To: <OSAPR01MB264258AF4E777740E517BDA6CE540@OSAPR01MB2642.jpnprd01.prod.outlook.com>
References: <OSAPR01MB264258AF4E777740E517BDA6CE540@OSAPR01MB2642.jpnprd01.prod.outlook.com>
Message-ID: <CAA9R9O5BnsP=PGA+-MNay4JzqfaBPjAmUMaU3CxAbDymXX9PdA@mail.gmail.com>

Hey Takashi,

Thanks a lot for the interest in contributing Keycloak!

Sebi and I are working on this topic currently. We plan to reuse some bits
of the User x509 Authentication and bring them to the client. We planned
the implementation for this sprint, so it *should* be ready in ~3 weeks.

More comments inlined.

Thanks,
Sebastian

On Thu, Jul 26, 2018 at 1:23 AM ???? / NORIMATSU?TAKASHI <
takashi.norimatsu.ws at hitachi.com> wrote:

> Hello,
>
> As for mentioned in https://issues.jboss.org/browse/KEYCLOAK-7512 and
> https://issues.jboss.org/browse/KEYCLOAK-7635, Is there anyone who
> currently implements OAuth 2.0 Mutual TLS Client Authentication defined in
> https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-2 ?
>

We also have additional requirement - allow to authenticate client without
"client_id" being sent (we need to extract it from the Certificate obtained
during TLS Handshake). This is required for OpenShift integration.


>
> If no one does it, I would like to try to implement this feature. What do
> you think about it ?
>
> Also, In https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-2,
> two types of OAuth 2.0 Mutual TLS Client Authentication are defined, for
> PKI and for Self-Signed Certificate.
>
> I would be happy if you who are interested in this feature tell me which
> you like better.
>

As far as I know, we won't be touching self-registering clients. So maybe
once we are done (let's assume that will happen in ~3 weeks), you could
take it over and look into that?

BTW, as for now, we will be implementing everything in this branch:
https://github.com/sebastienblanc/keycloak/tree/client-x509 (currently, it
contains an empty Authenticator but we will be adding bits and pieces to
it).


>
> 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 slaskawi at redhat.com  Thu Jul 26 05:03:40 2018
From: slaskawi at redhat.com (Sebastian Laskawiec)
Date: Thu, 26 Jul 2018 11:03:40 +0200
Subject: [keycloak-dev] Proposal - use Ant Plugin for generating JKS
	files
In-Reply-To: <ae4502c8-bb13-fd8a-ac28-8a90d57f67d7@redhat.com>
References: <CAA9R9O6Q+xTcngkFEkS7WSXzRxh=Vj5cS8Ou32-LqAZqdKaEAw@mail.gmail.com>
	<CAM01paZgQCsvo72HPnvDG1fv3vSUfzHt6i2e4c3Oker0Z1fjEw@mail.gmail.com>
	<CAA9R9O4OkbROORp1zncWFN4rs49H6BcPZ7vv91KH=wNZ=MmtmA@mail.gmail.com>
	<CAJgngAc2Y4bwgNPumnvPrf9wW7eH4GjR6FT2QE+541peYOOFuA@mail.gmail.com>
	<ae4502c8-bb13-fd8a-ac28-8a90d57f67d7@redhat.com>
Message-ID: <CAA9R9O54PJVwNzTNHzrt_a+7miy-FVxDCO4UsYPt8bmEgJP83g@mail.gmail.com>

Answering Stian's and Marek's email at the same time.

Just FYI - I've created a ticket to track this work -
https://issues.jboss.org/browse/KEYCLOAK-7940

On Wed, Jul 25, 2018 at 8:16 PM Marek Posolda <mposolda at redhat.com> wrote:

> IMO Creating keystore files programatically as Peter suggested, looks
> better than creating them through maven-antrun-plugin. It seems that
> creating with maven will mean lots of the stuff in pom.xml files,
> however generating programatically will probably allow some better
> reusability (common utility class in the testsuite to easily generate
> keystore in various locations). Also programatic generation will work
> when running the test from Intellij Idea without previous maven build.
>

Perhaps I didn't make it clear enough - the JKS autogeneration script will
mostly be executed in our test suite. I've just checked if you can run any
of the tests with a clean repo (without invoking `mvn package` or `mvn
install`) and it failed with [1]. So it seems you always need to execute
Maven prior to invoking any tests from the IDE (at least from the
Arquillian testsuite).

The programmable approach Peter suggested looks very nice. However, I'm not
sure if this is a good fit for us since we modify app servers during the
build [2]. Those servers expect a keystore (and sometimes a truststore too)
to be in certain places upon the server bootstrap. When the Arquillian
testsuite if fired, it's simply to late to generate keystores on the fly.

[1] https://gist.github.com/slaskawi/b7e5f9973798345c1bef182ae8d8d55f
[2]
https://github.com/keycloak/keycloak/blob/54fcbf12b0740f092e2d9148fb4d06a634618839/testsuite/integration-arquillian/servers/app-server/jboss/pom.xml#L148


> Sebastian, yesterday I didn't mention on the call that we probably don't
> test X509 authentication with IBM JDK. I recalled it just now :)  The
> thing is, that X509 tests are not executed during default build as they
> require Wildfly (they don't work on embedded undertow) and also
> phantomJS (no other browser is supported). So I am pretty sure they are
> not executed during the various matrix jobs for various java versions
> (Vasek Muzikar can correct me if I am wrong). Which means they probably
> don't work on IBM JDK too.
>

In Infinispan we had exactly the same problem. Keystores generated by
OpenJDK (or Oracle JDK) didn't work for IBM JDK. Therefore we added this
[3] little trick.

[3]
https://github.com/keycloak/keycloak/pull/5410/files#diff-03eb8cfddae682425845854ec51a2d53R246


>
> Marek
>
>
> On 25/07/18 15:50, Stian Thorgersen wrote:
> > Sounds like this could be a time-consuming task and the tests are working
> > at the moment.


I think I've solved the worst case - in some of the scenarios (like
`DemoServletsAdapterTest#testOIDCUiLocalesParamForwarding`) we expect the
certificate in keystore to be the same as the one from the realm JSON
configuration. I might be wrong here (I'm still the "new guy") but the
reason for this is that keystore.jks is used by the adapter whereas the
auth server uses the certificate from json file. Those need to match.
Therefore, I had to add a small piece of the code that does automatic
replacement of PEM certificates in the configuration [4]. I could probably
use some latest syntactic sugar (Optional#flatmap and Streams) but I think
the old way is more readable in this case (but of course, comments are more
than welcome, especially on the PR).

[4]
https://github.com/keycloak/keycloak/pull/5410/files#diff-207441f5cf5b6552db445afd0fe61492R28


> So not sure I see a need to start a bulk refactoring here.
>

Even though it might seem like a redundant thing to do, I would still
prefer to replace all existing JKS entries. The main reason for this is
that I'm a bit afraid that we'll end with a mixture of pushed JKS files and
automatically generated ones.

Let's make a deal. I'll look more into this today and will see how many of
those I'll manage to replace. Maybe it won't be that bad after all...


> > The json file you're mentioning has a cert in pem format in the json file
> > that is then stored in the DB. This doesn't have anything to do with
> > keystores/truststores. We expect Keycloak to be able to handle a cert
> > provided in the json file (or through admin endpoints) and store it in
> the
> > DB.
> >
> > Now for SSL tests with the server itself I can see the value in what you
> > are proposing. Keystore/truststore for Keycloak https connections and
> > truststores for mutual SSL could probably be improved. However, it seems
> to
> > be working at the moment, so not sure this is required.



>
> > On Wed, 25 Jul 2018 at 15:30, Sebastian Laskawiec <slaskawi at redhat.com>
> > wrote:
> >
> >> Thanks Darran and Peter for the insight!
> >>
> >> I've just noticed that generating JKS files is one thing but we will
> also
> >> need to pre-process RealmRepresentation and replace all private/public
> keys
> >> (like this one for example [1]) with values from keystores/truststores.
> >>
> >> At the moment I'm thinking about replacing [1] with something like this:
> >> "jwt.credential.certificate" :
> >>
> >>
> "certificate:keystore=classpath:keystore.jks,password=password,alias=secure-portal,type=pkcs12"
> >> similarly to private keys (if needed):
> >> "privateKey" :
> >>
> >>
> "private-key:keystore=classpath:keystore.jks,password=password,alias=secure-portal,type=pkcs12"
> >>
> >> Later on, while converting JSON to RealmRepresentation I plan to
> traverse
> >> all nodes and replace replace those which start with private-key or
> >> certificate.
> >>
> >> Let me know if you have a better idea.
> >>
> >> [1]
> >>
> >>
> https://github.com/keycloak/keycloak/blob/master/testsuite/integration-arquillian/tests/base/src/test/resources/adapter-test/demorealm.json#L231
> >>
> >> On Wed, Jul 25, 2018 at 2:07 PM Peter Skopek <pskopek at redhat.com>
> wrote:
> >>
> >>> Hi Sebastian,
> >>>
> >>> I think that generation of Keystore on the fly is the only way to go.
> >>> You can use Java Keystore API generate it entirely from Java code (no
> >>> need to run maven).
> >>>
> >>> Here [1] is an example of utility class used in wildfly testsuite to
> >>> generate Vault (basically just keystore).
> >>> It will be easy to strip vault related stuff and use it in our
> testsuite.
> >>>
> >>> Note that there is one more drawback of storing generated JKS files,
> >>> which is that in some cases they are not binary compatible between
> >>> different JDK (particularly Oracle and IBM).
> >>>
> >>> HTH,
> >>> Peter
> >>>
> >>> [1]
> >>>
> >>
> https://github.com/wildfly/wildfly/blob/master/testsuite/shared/src/main/java/org/jboss/as/test/integration/security/common/VaultHandler.java
> >>> On Wed, Jul 25, 2018 at 1:23 PM Sebastian Laskawiec <
> slaskawi at redhat.com
> >>>
> >>> wrote:
> >>>> Hey,
> >>>>
> >>>> Together with Sebi we are working on Certificate-based authentication
> >> for
> >>>> the clients. Our work will require adding at least 2-3 keystores to
> the
> >>>> codebase with different DNs and I think this might be a good
> >> opportunity
> >>> to
> >>>> revisit the way we handle JKS files in the tests.
> >>>>
> >>>> Currently we push JKS files directly into our repo, which has a couple
> >> of
> >>>> drawbacks:
> >>>> - it is hard to figure out what's inside the JKS, it requires looking
> >> up
> >>>> for password (usually in some JSON configuration file or hardcoded in
> >> the
> >>>> test) and using keytool (or some similar one) to explore its content.
> >>>> - It is not git-friendly. Every time we update JKS content we
> >> effectively
> >>>> store another binary file (git doesn't understand binary file changes
> >> and
> >>>> can not diff it).
> >>>> - we use many different naming and password schemes in our tests.
> >>>> - it is hard to migrate all keystores to pkcs12 at the same time (JKS
> >>>> format is deprecated) [0]
> >>>>
> >>>> I believe most of the issues could be addressed by generating JKS
> files
> >>> on
> >>>> the fly - during the build. In Infinispan we did it with Maven Ant
> >> Plugin
> >>>> [1]. I already created a very limited POC for Keycloak and you can
> >> check
> >>> it
> >>>> out here [2]. Unfortunately, the process of reverse engineering all
> >> those
> >>>> files is quite time-consuming, so I would like to know your opinion
> >>> before
> >>>> moving on.
> >>>>
> >>>> Of course, generating JKS files on the fly has some drawbacks:
> >>>> - It increases build time (~1s per keytool invocation, and we probably
> >>> will
> >>>> have more than 30 of them).
> >>>> - it makes testing from IDE a bit harder, you need to run Maven and
> >>> process
> >>>> test resources before doing anything. A common workaround is to use
> >> `mvn
> >>>> clean install -DskipTests` and then opening your IntelliJ.
> >>>>
> >>>> Please let me know what you think.
> >>>>
> >>>> Thanks,
> >>>> Sebastian
> >>>>
> >>>> [0]
> >>>>
> >>
> https://blogs.oracle.com/jtc/jdk9-keytool-transitions-default-keystore-to-pkcs12
> >>>> [1]
> >>>>
> >>
> https://github.com/infinispan/infinispan/blob/master/server/integration/testsuite/pom.xml#L460
> >>>> [2] https://github.com/keycloak/keycloak/pull/5410
> >>>> _______________________________________________
> >>>> 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 timmy.ccl at gmail.com  Thu Jul 26 06:12:15 2018
From: timmy.ccl at gmail.com (=?UTF-8?B?Q2hpaC1DaHVuIExlZSDmnY7lv5fntJQ=?=)
Date: Thu, 26 Jul 2018 18:12:15 +0800
Subject: [keycloak-dev] Redundant div end tag in base theme login.ftl
Message-ID: <CAEvJjXcHfMxLXB0zHFiHOmf89dnMgJq7CT=hnbxdnx29Ar9LmQ@mail.gmail.com>

Hello,

We found a redundant div end tag while creating our custom theme.

Please check this out:
https://github.com/keycloak/keycloak/blob/ca15db81bb5d84e9ba0f5203dbc868f90288b6e2/themes/src/main/resources/theme/base/login/login.ftl#L50

Best regards,
Timothy

From psilva at redhat.com  Thu Jul 26 08:06:18 2018
From: psilva at redhat.com (Pedro Igor Silva)
Date: Thu, 26 Jul 2018 09:06:18 -0300
Subject: [keycloak-dev] Possible Bug when listing users with
	fine-grained permissions
In-Reply-To: <5ccc909b43154c09a3b4937f602f9e00@bosch-si.com>
References: <5ccc909b43154c09a3b4937f602f9e00@bosch-si.com>
Message-ID: <CAJrcDBcRVojhpVMWRqtJD_k3=DR6bRUN2fDk6WkSD=RMoBUS_g@mail.gmail.com>

On Wed, Jul 25, 2018 at 12:10 PM, Schuster Sebastian (INST/ESY1) <
Sebastian.Schuster at bosch-si.com> wrote:

> Hello,
>
> we are currently experiencing issues with the "View all users"
> functionality of the Keycloak Admin Console and the respective API call to
> /auth/admin/realms/{realm}/users when using the permissions based on the
> authorization services. In our case, we have users separated into groups
> and some users are able to view these by means of having the
> realm-management.query-users role and the group.view-members scope by means
> of a permission/policy. When such a user tries to view all the users he can
> see, he only gets a subset or even none.
>
> The reason is that in UsersResource, first a paginated subset of users is
> retrieved that is than filtered by checking visibility for each user. In
> general, this will return less users than the page and the admin UI will
> not offer to go to the next page. Even if it did, with many users where you
> can see only a small subset having to skip over lots of empty pages won?t
> be feasible.
>
> Since we really like to use this feature, we discussed several options to
> fix it:
>
> 1.     Keycloak should query for users until it reaches the number of
> requested viewable users or until it has evaluated all available users (->
> can lead to performance issues with an increasing number of users, in the
> worst case Keycloak needs to pull all users out of the database just to
> find out the current user might see none)
>
> 2.     Do the same thing but in the admin console (-> no changes in
> Keycloak but lots of request, probably even worse idea)
>
> 3.     Since groups are the resources a user needs to have view-members
> scope to see users, retrieve all groups from the database, filter out
> groups without view-members scope and then do a join by group membership
> and limit the result by paging. (-> less generalized approach, probably
> better performance as long as there are not too many groups)
>
> All of these seem to be far less than ideal.
>
> Any thoughts?
>

Yeah, all these have drawbacks and they are hard to overcome. What about
instead of hiding users, we just list all users and somehow indicate in the
list which users access is not granted. We cold avoid clicking user and
accessing his details (via UI or directly URI).


>
> Best regards,
> Sebastian
>
> Mit freundlichen Gr??en / Best regards
>
> Dr.-Ing. Sebastian Schuster
>
> Engineering and Support (INST/ESY1)
> Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin |
> GERMANY | www.bosch-si.com<http://www.bosch-si.com>
> Tel. +49 30 726112-485 | Fax +49 30 726112-100 |
> Sebastian.Schuster at bosch-si.com<mailto:Sebastian.Schuster at bosch-si.com>
>
> Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
> Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten L?cke; Gesch?ftsf?hrung: Dr.
> Stefan Ferber, Michael Hahn
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From slaskawi at redhat.com  Thu Jul 26 08:47:46 2018
From: slaskawi at redhat.com (Sebastian Laskawiec)
Date: Thu, 26 Jul 2018 14:47:46 +0200
Subject: [keycloak-dev] Proposal - use Ant Plugin for generating JKS
	files
In-Reply-To: <CAA9R9O54PJVwNzTNHzrt_a+7miy-FVxDCO4UsYPt8bmEgJP83g@mail.gmail.com>
References: <CAA9R9O6Q+xTcngkFEkS7WSXzRxh=Vj5cS8Ou32-LqAZqdKaEAw@mail.gmail.com>
	<CAM01paZgQCsvo72HPnvDG1fv3vSUfzHt6i2e4c3Oker0Z1fjEw@mail.gmail.com>
	<CAA9R9O4OkbROORp1zncWFN4rs49H6BcPZ7vv91KH=wNZ=MmtmA@mail.gmail.com>
	<CAJgngAc2Y4bwgNPumnvPrf9wW7eH4GjR6FT2QE+541peYOOFuA@mail.gmail.com>
	<ae4502c8-bb13-fd8a-ac28-8a90d57f67d7@redhat.com>
	<CAA9R9O54PJVwNzTNHzrt_a+7miy-FVxDCO4UsYPt8bmEgJP83g@mail.gmail.com>
Message-ID: <CAA9R9O5Fk8XPDvAasUKecLxBPNoqovxdFcbF9pddVjk_YDndqA@mail.gmail.com>

As promised, here's an update on this.

I managed to migrate 3 more keystores (2 of them for SAML), see the PR [1].
Most of the time I spent on figuring out which signatures need to match
with the JSON configuration and which don't (because they are testing
negative path for example). This is not very complicated task but very time
consuming (comparing generated PEM files with each other and occasionally
debugging remote WF app server). So at the moment we have there are 28
still to be migrated.

It becomes clear to me that this task is simply to large to be implemented
off the sprint. Let's prioritize it and schedule for some of the next
sprints. As for now, I'm closing the PR.

Thanks,
Sebastian

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

On Thu, Jul 26, 2018 at 11:03 AM Sebastian Laskawiec <slaskawi at redhat.com>
wrote:

> Answering Stian's and Marek's email at the same time.
>
> Just FYI - I've created a ticket to track this work -
> https://issues.jboss.org/browse/KEYCLOAK-7940
>
> On Wed, Jul 25, 2018 at 8:16 PM Marek Posolda <mposolda at redhat.com> wrote:
>
>> IMO Creating keystore files programatically as Peter suggested, looks
>> better than creating them through maven-antrun-plugin. It seems that
>> creating with maven will mean lots of the stuff in pom.xml files,
>> however generating programatically will probably allow some better
>> reusability (common utility class in the testsuite to easily generate
>> keystore in various locations). Also programatic generation will work
>> when running the test from Intellij Idea without previous maven build.
>>
>
> Perhaps I didn't make it clear enough - the JKS autogeneration script will
> mostly be executed in our test suite. I've just checked if you can run any
> of the tests with a clean repo (without invoking `mvn package` or `mvn
> install`) and it failed with [1]. So it seems you always need to execute
> Maven prior to invoking any tests from the IDE (at least from the
> Arquillian testsuite).
>
> The programmable approach Peter suggested looks very nice. However, I'm
> not sure if this is a good fit for us since we modify app servers during
> the build [2]. Those servers expect a keystore (and sometimes a truststore
> too) to be in certain places upon the server bootstrap. When the Arquillian
> testsuite if fired, it's simply to late to generate keystores on the fly.
>
> [1] https://gist.github.com/slaskawi/b7e5f9973798345c1bef182ae8d8d55f
> [2]
> https://github.com/keycloak/keycloak/blob/54fcbf12b0740f092e2d9148fb4d06a634618839/testsuite/integration-arquillian/servers/app-server/jboss/pom.xml#L148
>
>
>> Sebastian, yesterday I didn't mention on the call that we probably don't
>> test X509 authentication with IBM JDK. I recalled it just now :)  The
>> thing is, that X509 tests are not executed during default build as they
>> require Wildfly (they don't work on embedded undertow) and also
>> phantomJS (no other browser is supported). So I am pretty sure they are
>> not executed during the various matrix jobs for various java versions
>> (Vasek Muzikar can correct me if I am wrong). Which means they probably
>> don't work on IBM JDK too.
>>
>
> In Infinispan we had exactly the same problem. Keystores generated by
> OpenJDK (or Oracle JDK) didn't work for IBM JDK. Therefore we added this
> [3] little trick.
>
> [3]
> https://github.com/keycloak/keycloak/pull/5410/files#diff-03eb8cfddae682425845854ec51a2d53R246
>
>
>>
>> Marek
>>
>>
>> On 25/07/18 15:50, Stian Thorgersen wrote:
>> > Sounds like this could be a time-consuming task and the tests are
>> working
>> > at the moment.
>
>
> I think I've solved the worst case - in some of the scenarios (like
> `DemoServletsAdapterTest#testOIDCUiLocalesParamForwarding`) we expect the
> certificate in keystore to be the same as the one from the realm JSON
> configuration. I might be wrong here (I'm still the "new guy") but the
> reason for this is that keystore.jks is used by the adapter whereas the
> auth server uses the certificate from json file. Those need to match.
> Therefore, I had to add a small piece of the code that does automatic
> replacement of PEM certificates in the configuration [4]. I could probably
> use some latest syntactic sugar (Optional#flatmap and Streams) but I think
> the old way is more readable in this case (but of course, comments are more
> than welcome, especially on the PR).
>
> [4]
> https://github.com/keycloak/keycloak/pull/5410/files#diff-207441f5cf5b6552db445afd0fe61492R28
>
>
>> So not sure I see a need to start a bulk refactoring here.
>>
>
> Even though it might seem like a redundant thing to do, I would still
> prefer to replace all existing JKS entries. The main reason for this is
> that I'm a bit afraid that we'll end with a mixture of pushed JKS files and
> automatically generated ones.
>
> Let's make a deal. I'll look more into this today and will see how many of
> those I'll manage to replace. Maybe it won't be that bad after all...
>
>
>> > The json file you're mentioning has a cert in pem format in the json
>> file
>> > that is then stored in the DB. This doesn't have anything to do with
>> > keystores/truststores. We expect Keycloak to be able to handle a cert
>> > provided in the json file (or through admin endpoints) and store it in
>> the
>> > DB.
>> >
>> > Now for SSL tests with the server itself I can see the value in what you
>> > are proposing. Keystore/truststore for Keycloak https connections and
>> > truststores for mutual SSL could probably be improved. However, it
>> seems to
>> > be working at the moment, so not sure this is required.
>
>
>
> >
>> > On Wed, 25 Jul 2018 at 15:30, Sebastian Laskawiec <slaskawi at redhat.com>
>> > wrote:
>> >
>> >> Thanks Darran and Peter for the insight!
>> >>
>> >> I've just noticed that generating JKS files is one thing but we will
>> also
>> >> need to pre-process RealmRepresentation and replace all private/public
>> keys
>> >> (like this one for example [1]) with values from keystores/truststores.
>> >>
>> >> At the moment I'm thinking about replacing [1] with something like
>> this:
>> >> "jwt.credential.certificate" :
>> >>
>> >>
>> "certificate:keystore=classpath:keystore.jks,password=password,alias=secure-portal,type=pkcs12"
>> >> similarly to private keys (if needed):
>> >> "privateKey" :
>> >>
>> >>
>> "private-key:keystore=classpath:keystore.jks,password=password,alias=secure-portal,type=pkcs12"
>> >>
>> >> Later on, while converting JSON to RealmRepresentation I plan to
>> traverse
>> >> all nodes and replace replace those which start with private-key or
>> >> certificate.
>> >>
>> >> Let me know if you have a better idea.
>> >>
>> >> [1]
>> >>
>> >>
>> https://github.com/keycloak/keycloak/blob/master/testsuite/integration-arquillian/tests/base/src/test/resources/adapter-test/demorealm.json#L231
>> >>
>> >> On Wed, Jul 25, 2018 at 2:07 PM Peter Skopek <pskopek at redhat.com>
>> wrote:
>> >>
>> >>> Hi Sebastian,
>> >>>
>> >>> I think that generation of Keystore on the fly is the only way to go.
>> >>> You can use Java Keystore API generate it entirely from Java code (no
>> >>> need to run maven).
>> >>>
>> >>> Here [1] is an example of utility class used in wildfly testsuite to
>> >>> generate Vault (basically just keystore).
>> >>> It will be easy to strip vault related stuff and use it in our
>> testsuite.
>> >>>
>> >>> Note that there is one more drawback of storing generated JKS files,
>> >>> which is that in some cases they are not binary compatible between
>> >>> different JDK (particularly Oracle and IBM).
>> >>>
>> >>> HTH,
>> >>> Peter
>> >>>
>> >>> [1]
>> >>>
>> >>
>> https://github.com/wildfly/wildfly/blob/master/testsuite/shared/src/main/java/org/jboss/as/test/integration/security/common/VaultHandler.java
>> >>> On Wed, Jul 25, 2018 at 1:23 PM Sebastian Laskawiec <
>> slaskawi at redhat.com
>> >>>
>> >>> wrote:
>> >>>> Hey,
>> >>>>
>> >>>> Together with Sebi we are working on Certificate-based authentication
>> >> for
>> >>>> the clients. Our work will require adding at least 2-3 keystores to
>> the
>> >>>> codebase with different DNs and I think this might be a good
>> >> opportunity
>> >>> to
>> >>>> revisit the way we handle JKS files in the tests.
>> >>>>
>> >>>> Currently we push JKS files directly into our repo, which has a
>> couple
>> >> of
>> >>>> drawbacks:
>> >>>> - it is hard to figure out what's inside the JKS, it requires looking
>> >> up
>> >>>> for password (usually in some JSON configuration file or hardcoded in
>> >> the
>> >>>> test) and using keytool (or some similar one) to explore its content.
>> >>>> - It is not git-friendly. Every time we update JKS content we
>> >> effectively
>> >>>> store another binary file (git doesn't understand binary file changes
>> >> and
>> >>>> can not diff it).
>> >>>> - we use many different naming and password schemes in our tests.
>> >>>> - it is hard to migrate all keystores to pkcs12 at the same time (JKS
>> >>>> format is deprecated) [0]
>> >>>>
>> >>>> I believe most of the issues could be addressed by generating JKS
>> files
>> >>> on
>> >>>> the fly - during the build. In Infinispan we did it with Maven Ant
>> >> Plugin
>> >>>> [1]. I already created a very limited POC for Keycloak and you can
>> >> check
>> >>> it
>> >>>> out here [2]. Unfortunately, the process of reverse engineering all
>> >> those
>> >>>> files is quite time-consuming, so I would like to know your opinion
>> >>> before
>> >>>> moving on.
>> >>>>
>> >>>> Of course, generating JKS files on the fly has some drawbacks:
>> >>>> - It increases build time (~1s per keytool invocation, and we
>> probably
>> >>> will
>> >>>> have more than 30 of them).
>> >>>> - it makes testing from IDE a bit harder, you need to run Maven and
>> >>> process
>> >>>> test resources before doing anything. A common workaround is to use
>> >> `mvn
>> >>>> clean install -DskipTests` and then opening your IntelliJ.
>> >>>>
>> >>>> Please let me know what you think.
>> >>>>
>> >>>> Thanks,
>> >>>> Sebastian
>> >>>>
>> >>>> [0]
>> >>>>
>> >>
>> https://blogs.oracle.com/jtc/jdk9-keytool-transitions-default-keystore-to-pkcs12
>> >>>> [1]
>> >>>>
>> >>
>> https://github.com/infinispan/infinispan/blob/master/server/integration/testsuite/pom.xml#L460
>> >>>> [2] https://github.com/keycloak/keycloak/pull/5410
>> >>>> _______________________________________________
>> >>>> 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 Sebastian.Schuster at bosch-si.com  Thu Jul 26 10:56:37 2018
From: Sebastian.Schuster at bosch-si.com (Schuster Sebastian (INST/ESY1))
Date: Thu, 26 Jul 2018 14:56:37 +0000
Subject: [keycloak-dev] Possible Bug when listing users with
 fine-grained permissions
In-Reply-To: <CAJrcDBcRVojhpVMWRqtJD_k3=DR6bRUN2fDk6WkSD=RMoBUS_g@mail.gmail.com>
References: <5ccc909b43154c09a3b4937f602f9e00@bosch-si.com>
	<CAJrcDBcRVojhpVMWRqtJD_k3=DR6bRUN2fDk6WkSD=RMoBUS_g@mail.gmail.com>
Message-ID: <b936474216134caf89cd73e2ff792d91@bosch-si.com>

Hi Pedro,

That would be kind of consistent with the behavior of the role ?query_groups?, allowing you to also see all group names, ids, and subgroups. However, on the users endpoint you get a lot more data, partly personal.
Unless the API is changed here (unlikely as it would be incompatible), I would prefer the current behavior of not seeing users at all if you miss the permission.

Do you think that the third approach, filtering groups and joining contained users, would be worth investigating?

Best regards,
Sebastian

Mit freundlichen Gr??en / Best regards

Dr.-Ing. Sebastian Schuster

Engineering and Support (INST/ESY1)
Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin | GERMANY | www.bosch-si.com<http://www.bosch-si.com>
Tel. +49 30 726112-485 | Fax +49 30 726112-100 | Sebastian.Schuster at bosch-si.com<mailto:Sebastian.Schuster at bosch-si.com>

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



From: Pedro Igor Silva <psilva at redhat.com>
Sent: Donnerstag, 26. Juli 2018 14:06
To: Schuster Sebastian (INST/ESY1) <Sebastian.Schuster at bosch-si.com>
Cc: keycloak-dev <keycloak-dev at lists.jboss.org>
Subject: Re: [keycloak-dev] Possible Bug when listing users with fine-grained permissions



On Wed, Jul 25, 2018 at 12:10 PM, Schuster Sebastian (INST/ESY1) <Sebastian.Schuster at bosch-si.com<mailto:Sebastian.Schuster at bosch-si.com>> wrote:
Hello,

we are currently experiencing issues with the "View all users" functionality of the Keycloak Admin Console and the respective API call to /auth/admin/realms/{realm}/users when using the permissions based on the authorization services. In our case, we have users separated into groups and some users are able to view these by means of having the realm-management.query-users role and the group.view-members scope by means of a permission/policy. When such a user tries to view all the users he can see, he only gets a subset or even none.

The reason is that in UsersResource, first a paginated subset of users is retrieved that is than filtered by checking visibility for each user. In general, this will return less users than the page and the admin UI will not offer to go to the next page. Even if it did, with many users where you can see only a small subset having to skip over lots of empty pages won?t be feasible.

Since we really like to use this feature, we discussed several options to fix it:

1.     Keycloak should query for users until it reaches the number of requested viewable users or until it has evaluated all available users (-> can lead to performance issues with an increasing number of users, in the worst case Keycloak needs to pull all users out of the database just to find out the current user might see none)

2.     Do the same thing but in the admin console (-> no changes in Keycloak but lots of request, probably even worse idea)

3.     Since groups are the resources a user needs to have view-members scope to see users, retrieve all groups from the database, filter out groups without view-members scope and then do a join by group membership and limit the result by paging. (-> less generalized approach, probably better performance as long as there are not too many groups)

All of these seem to be far less than ideal.

Any thoughts?

Yeah, all these have drawbacks and they are hard to overcome. What about instead of hiding users, we just list all users and somehow indicate in the list which users access is not granted. We cold avoid clicking user and accessing his details (via UI or directly URI).


Best regards,
Sebastian

Mit freundlichen Gr??en / Best regards

Dr.-Ing. Sebastian Schuster

Engineering and Support (INST/ESY1)
Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin | GERMANY | www.bosch-si.com<http://www.bosch-si.com><http://www.bosch-si.com>
Tel. +49 30 726112-485 | Fax +49 30 726112-100 | Sebastian.Schuster at bosch-si.com<mailto:Sebastian.Schuster at bosch-si.com><mailto:Sebastian.Schuster at bosch-si.com<mailto:Sebastian.Schuster at bosch-si.com>>

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



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


From psilva at redhat.com  Thu Jul 26 13:57:22 2018
From: psilva at redhat.com (Pedro Igor Silva)
Date: Thu, 26 Jul 2018 14:57:22 -0300
Subject: [keycloak-dev] Possible Bug when listing users with
	fine-grained permissions
In-Reply-To: <b936474216134caf89cd73e2ff792d91@bosch-si.com>
References: <5ccc909b43154c09a3b4937f602f9e00@bosch-si.com>
	<CAJrcDBcRVojhpVMWRqtJD_k3=DR6bRUN2fDk6WkSD=RMoBUS_g@mail.gmail.com>
	<b936474216134caf89cd73e2ff792d91@bosch-si.com>
Message-ID: <CAJrcDBdvCbfCkqwM9Bs5ycVk8po4oj8oPAc1c=XCg5j5vTiP5w@mail.gmail.com>

On Thu, Jul 26, 2018 at 11:56 AM, Schuster Sebastian (INST/ESY1) <
Sebastian.Schuster at bosch-si.com> wrote:

> Hi Pedro,
>
>
>
> That would be kind of consistent with the behavior of the role
> ?query_groups?, allowing you to also see all group names, ids, and
> subgroups. However, on the users endpoint you get a lot more data, partly
> personal.
>
> Unless the API is changed here (unlikely as it would be incompatible), I
> would prefer the current behavior of not seeing users at all if you miss
> the permission.
>

Yeah, I was thinking about something similar to "query_groups". Agree that
for users this is should work differently.


>
>
> Do you think that the third approach, filtering groups and joining
> contained users, would be worth investigating?
>

Yes, #3 seems to me the best among those options. Could you create a JIRA
to track this ? One more thing to check when reviewing this functionality
...


>
>
> Best regards,
>
> Sebastian
>
>
>
> Mit freundlichen Gr??en / Best regards
>
>
> *Dr.-Ing. Sebastian Schuster *
> Engineering and Support (INST/ESY1)
> Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin |
> <https://maps.google.com/?q=Ullsteinstr.+128+%7C+12109+Berlin+%7C++%0D%0AGERMANY&entry=gmail&source=g>
> GERMANY | www.bosch-si.com
> Tel. +49 30 726112-485 | Fax +49 30 726112-100 |
> Sebastian.Schuster at bosch-si.com
>
> Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
> Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten L?cke; Gesch?ftsf?hrung: Dr.
> Stefan Ferber, Michael Hahn
>
>
>
> *From:* Pedro Igor Silva <psilva at redhat.com>
> *Sent:* Donnerstag, 26. Juli 2018 14:06
> *To:* Schuster Sebastian (INST/ESY1) <Sebastian.Schuster at bosch-si.com>
> *Cc:* keycloak-dev <keycloak-dev at lists.jboss.org>
> *Subject:* Re: [keycloak-dev] Possible Bug when listing users with
> fine-grained permissions
>
>
>
>
>
>
>
> On Wed, Jul 25, 2018 at 12:10 PM, Schuster Sebastian (INST/ESY1) <
> Sebastian.Schuster at bosch-si.com> wrote:
>
> Hello,
>
> we are currently experiencing issues with the "View all users"
> functionality of the Keycloak Admin Console and the respective API call to
> /auth/admin/realms/{realm}/users when using the permissions based on the
> authorization services. In our case, we have users separated into groups
> and some users are able to view these by means of having the
> realm-management.query-users role and the group.view-members scope by means
> of a permission/policy. When such a user tries to view all the users he can
> see, he only gets a subset or even none.
>
> The reason is that in UsersResource, first a paginated subset of users is
> retrieved that is than filtered by checking visibility for each user. In
> general, this will return less users than the page and the admin UI will
> not offer to go to the next page. Even if it did, with many users where you
> can see only a small subset having to skip over lots of empty pages won?t
> be feasible.
>
> Since we really like to use this feature, we discussed several options to
> fix it:
>
> 1.     Keycloak should query for users until it reaches the number of
> requested viewable users or until it has evaluated all available users (->
> can lead to performance issues with an increasing number of users, in the
> worst case Keycloak needs to pull all users out of the database just to
> find out the current user might see none)
>
> 2.     Do the same thing but in the admin console (-> no changes in
> Keycloak but lots of request, probably even worse idea)
>
> 3.     Since groups are the resources a user needs to have view-members
> scope to see users, retrieve all groups from the database, filter out
> groups without view-members scope and then do a join by group membership
> and limit the result by paging. (-> less generalized approach, probably
> better performance as long as there are not too many groups)
>
> All of these seem to be far less than ideal.
>
> Any thoughts?
>
>
>
> Yeah, all these have drawbacks and they are hard to overcome. What about
> instead of hiding users, we just list all users and somehow indicate in the
> list which users access is not granted. We cold avoid clicking user and
> accessing his details (via UI or directly URI).
>
>
>
>
> Best regards,
> Sebastian
>
> Mit freundlichen Gr??en / Best regards
>
> Dr.-Ing. Sebastian Schuster
>
> Engineering and Support (INST/ESY1)
> Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin |
> GERMANY
> <https://maps.google.com/?q=Ullsteinstr.+128+%7C+12109+Berlin+%7C+GERMANY&entry=gmail&source=g>
> | www.bosch-si.com<http://www.bosch-si.com>
> Tel. +49 30 726112-485 | Fax +49 30 726112-100 |
> Sebastian.Schuster at bosch-si.com<mailto:Sebastian.Schuster at bosch-si.com>
>
> Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
> Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten L?cke; Gesch?ftsf?hrung: Dr.
> Stefan Ferber, Michael Hahn
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>

From takashi.norimatsu.ws at hitachi.com  Thu Jul 26 21:22:48 2018
From: takashi.norimatsu.ws at hitachi.com (=?utf-8?B?5LmX5p2+6ZqG5b+XIC8gTk9SSU1BVFNV77yMVEFLQVNISQ==?=)
Date: Fri, 27 Jul 2018 01:22:48 +0000
Subject: [keycloak-dev] OAuth 2.0 Mutual TLS Client Authentication
Message-ID: <TY2PR01MB26512F00C532C793EB937448CE2A0@TY2PR01MB2651.jpnprd01.prod.outlook.com>

Hello Sebastian,

I'm looking forward to your work, and I would be happy if I could make some contribution after finishing your work.

Best regards,
Takashi Norimatsu
Hitachi Ltd.,

----------
From: Sebastian Laskawiec <slaskawi at redhat.com> 
Sent: Thursday, July 26, 2018 5:24 PM
To: ???? / NORIMATSU?TAKASHI <takashi.norimatsu.ws at hitachi.com>
Cc: keycloak-dev at lists.jboss.org
Subject: [!]Re: [keycloak-dev] OAuth 2.0 Mutual TLS Client Authentication

Hey Takashi,

Thanks a lot for the interest in contributing Keycloak!

Sebi and I are working on this topic currently. We plan to reuse some bits of the User x509 Authentication and bring them to the client. We planned the implementation for this sprint, so it *should* be ready in ~3 weeks.

More comments inlined.

Thanks,
Sebastian
On Thu, Jul 26, 2018 at 1:23 AM ???? / NORIMATSU?TAKASHI <takashi.norimatsu.ws at hitachi.com> wrote:
Hello,

As for mentioned in https://issues.jboss.org/browse/KEYCLOAK-7512 and https://issues.jboss.org/browse/KEYCLOAK-7635, Is there anyone who currently implements OAuth 2.0 Mutual TLS Client Authentication defined in https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-2 ?

We also have additional requirement - allow to authenticate client without "client_id" being sent (we need to extract it from the Certificate obtained during TLS Handshake). This is required for OpenShift integration.
 

If no one does it, I would like to try to implement this feature. What do you think about it ?

Also, In https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-2, two types of OAuth 2.0 Mutual TLS Client Authentication are defined, for PKI and for Self-Signed Certificate.

I would be happy if you who are interested in this feature tell me which you like better.

As far as I know, we won't be touching self-registering clients. So maybe once we are done (let's assume that will happen in ~3 weeks), you could take it over and look into that?

BTW, as for now, we will be implementing everything in this branch: https://github.com/sebastienblanc/keycloak/tree/client-x509 (currently, it contains an empty Authenticator but we will be adding bits and pieces to it).
 

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 sblanc at redhat.com  Fri Jul 27 03:30:43 2018
From: sblanc at redhat.com (Sebastien Blanc)
Date: Fri, 27 Jul 2018 09:30:43 +0200
Subject: [keycloak-dev] OAuth 2.0 Mutual TLS Client Authentication
In-Reply-To: <TY2PR01MB26512F00C532C793EB937448CE2A0@TY2PR01MB2651.jpnprd01.prod.outlook.com>
References: <TY2PR01MB26512F00C532C793EB937448CE2A0@TY2PR01MB2651.jpnprd01.prod.outlook.com>
Message-ID: <CAMZCGg8p2=Z95aE=PuawtOYXJDOZiJifYbkB5Ss_ucL0U_mdXQ@mail.gmail.com>

Hi Takashi !

You can even help before if you want to :)

The ticket is here : https://issues.jboss.org/browse/KEYCLOAK-7635

I created an "empty" X509ClientAuthenticator" branch here  :
https://github.com/sebastienblanc/keycloak/tree/client-x509

And I'm investigating what we can reuse from this pacakge :
https://github.com/keycloak/keycloak/tree/master/services/src/main/java/org/keycloak/authentication/authenticators/x509

Any feedback, help, advise is welcome !

Sebi


On Fri, Jul 27, 2018 at 3:22 AM, ???? / NORIMATSU?TAKASHI <
takashi.norimatsu.ws at hitachi.com> wrote:

> Hello Sebastian,
>
> I'm looking forward to your work, and I would be happy if I could make
> some contribution after finishing your work.
>
> Best regards,
> Takashi Norimatsu
> Hitachi Ltd.,
>
> ----------
> From: Sebastian Laskawiec <slaskawi at redhat.com>
> Sent: Thursday, July 26, 2018 5:24 PM
> To: ???? / NORIMATSU?TAKASHI <takashi.norimatsu.ws at hitachi.com>
> Cc: keycloak-dev at lists.jboss.org
> Subject: [!]Re: [keycloak-dev] OAuth 2.0 Mutual TLS Client Authentication
>
> Hey Takashi,
>
> Thanks a lot for the interest in contributing Keycloak!
>
> Sebi and I are working on this topic currently. We plan to reuse some bits
> of the User x509 Authentication and bring them to the client. We planned
> the implementation for this sprint, so it *should* be ready in ~3 weeks.
>
> More comments inlined.
>
> Thanks,
> Sebastian
> On Thu, Jul 26, 2018 at 1:23 AM ???? / NORIMATSU?TAKASHI <
> takashi.norimatsu.ws at hitachi.com> wrote:
> Hello,
>
> As for mentioned in https://issues.jboss.org/browse/KEYCLOAK-7512 and
> https://issues.jboss.org/browse/KEYCLOAK-7635, Is there anyone who
> currently implements OAuth 2.0 Mutual TLS Client Authentication defined in
> https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-2 ?
>
> We also have additional requirement - allow to authenticate client without
> "client_id" being sent (we need to extract it from the Certificate obtained
> during TLS Handshake). This is required for OpenShift integration.
>
>
> If no one does it, I would like to try to implement this feature. What do
> you think about it ?
>
> Also, In https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-2,
> two types of OAuth 2.0 Mutual TLS Client Authentication are defined, for
> PKI and for Self-Signed Certificate.
>
> I would be happy if you who are interested in this feature tell me which
> you like better.
>
> As far as I know, we won't be touching self-registering clients. So maybe
> once we are done (let's assume that will happen in ~3 weeks), you could
> take it over and look into that?
>
> BTW, as for now, we will be implementing everything in this branch:
> https://github.com/sebastienblanc/keycloak/tree/client-x509 (currently,
> it contains an empty Authenticator but we will be adding bits and pieces to
> it).
>
>
> Best regards,
> Takashi Norimatsu
> Hitachi Ltd.,
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From hmlnarik at redhat.com  Fri Jul 27 04:56:01 2018
From: hmlnarik at redhat.com (Hynek Mlnarik)
Date: Fri, 27 Jul 2018 10:56:01 +0200
Subject: [keycloak-dev] Proposal - use Ant Plugin for generating JKS
	files
In-Reply-To: <CAA9R9O54PJVwNzTNHzrt_a+7miy-FVxDCO4UsYPt8bmEgJP83g@mail.gmail.com>
References: <CAA9R9O6Q+xTcngkFEkS7WSXzRxh=Vj5cS8Ou32-LqAZqdKaEAw@mail.gmail.com>
	<CAM01paZgQCsvo72HPnvDG1fv3vSUfzHt6i2e4c3Oker0Z1fjEw@mail.gmail.com>
	<CAA9R9O4OkbROORp1zncWFN4rs49H6BcPZ7vv91KH=wNZ=MmtmA@mail.gmail.com>
	<CAJgngAc2Y4bwgNPumnvPrf9wW7eH4GjR6FT2QE+541peYOOFuA@mail.gmail.com>
	<ae4502c8-bb13-fd8a-ac28-8a90d57f67d7@redhat.com>
	<CAA9R9O54PJVwNzTNHzrt_a+7miy-FVxDCO4UsYPt8bmEgJP83g@mail.gmail.com>
Message-ID: <CAMvXD=E-vNHeLWx6pUYPnMHaA0c6CEjQTMHANEjdFexuPr3pXQ@mail.gmail.com>

My preference is programmatic approach too. See inline.

On Thu, Jul 26, 2018 at 11:13 AM Sebastian Laskawiec <slaskawi at redhat.com>
wrote:

> Answering Stian's and Marek's email at the same time.
>
> Just FYI - I've created a ticket to track this work -
> https://issues.jboss.org/browse/KEYCLOAK-7940
>
> On Wed, Jul 25, 2018 at 8:16 PM Marek Posolda <mposolda at redhat.com> wrote:
>
> > IMO Creating keystore files programatically as Peter suggested, looks
> > better than creating them through maven-antrun-plugin. It seems that
> > creating with maven will mean lots of the stuff in pom.xml files,
> > however generating programatically will probably allow some better
> > reusability (common utility class in the testsuite to easily generate
> > keystore in various locations). Also programatic generation will work
> > when running the test from Intellij Idea without previous maven build.
> >
>
> Perhaps I didn't make it clear enough - the JKS autogeneration script will
> mostly be executed in our test suite. I've just checked if you can run any
> of the tests with a clean repo (without invoking `mvn package` or `mvn
> install`) and it failed with [1]. So it seems you always need to execute
> Maven prior to invoking any tests from the IDE (at least from the
> Arquillian testsuite).
>

The programmable approach Peter suggested looks very nice. However, I'm not
> sure if this is a good fit for us since we modify app servers during the
> build [2]. Those servers expect a keystore (and sometimes a truststore too)
> to be in certain places upon the server bootstrap. When the Arquillian
> testsuite if fired, it's simply to late to generate keystores on the fly.
>

It is not too late. We modify the app servers during the build, and will be
only controlling their lifecycle in the testsuite, which is current work in
progress to be merged soon. [1] So one can always prepare the config for
the keystore and generate the keystore (if it does not exist) in Java to
appropriate place (ideally location would be set via system property).

Adapter tests can then make use of the generated keystores since they could
be available to them via Arquillian-injected resources. That would make
tests that cope with encryption and/or signing simpler and I see quite a
benefit for at least SAML tests.

I believe this would be a neat follow-up on [1].

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

[1] https://gist.github.com/slaskawi/b7e5f9973798345c1bef182ae8d8d55f
> [2]
>
> https://github.com/keycloak/keycloak/blob/54fcbf12b0740f092e2d9148fb4d06a634618839/testsuite/integration-arquillian/servers/app-server/jboss/pom.xml#L148
>
>
> > Sebastian, yesterday I didn't mention on the call that we probably don't
> > test X509 authentication with IBM JDK. I recalled it just now :)  The
> > thing is, that X509 tests are not executed during default build as they
> > require Wildfly (they don't work on embedded undertow) and also
> > phantomJS (no other browser is supported). So I am pretty sure they are
> > not executed during the various matrix jobs for various java versions
> > (Vasek Muzikar can correct me if I am wrong). Which means they probably
> > don't work on IBM JDK too.
> >
>
> In Infinispan we had exactly the same problem. Keystores generated by
> OpenJDK (or Oracle JDK) didn't work for IBM JDK. Therefore we added this
> [3] little trick.
>
> [3]
>
> https://github.com/keycloak/keycloak/pull/5410/files#diff-03eb8cfddae682425845854ec51a2d53R246
>
>
> >
> > Marek
> >
> >
> > On 25/07/18 15:50, Stian Thorgersen wrote:
> > > Sounds like this could be a time-consuming task and the tests are
> working
> > > at the moment.
>
>
> I think I've solved the worst case - in some of the scenarios (like
> `DemoServletsAdapterTest#testOIDCUiLocalesParamForwarding`) we expect the
> certificate in keystore to be the same as the one from the realm JSON
> configuration. I might be wrong here (I'm still the "new guy") but the
> reason for this is that keystore.jks is used by the adapter whereas the
> auth server uses the certificate from json file. Those need to match.
> Therefore, I had to add a small piece of the code that does automatic
> replacement of PEM certificates in the configuration [4]. I could probably
> use some latest syntactic sugar (Optional#flatmap and Streams) but I think
> the old way is more readable in this case (but of course, comments are more
> than welcome, especially on the PR).
>
> [4]
>
> https://github.com/keycloak/keycloak/pull/5410/files#diff-207441f5cf5b6552db445afd0fe61492R28
>
>
> > So not sure I see a need to start a bulk refactoring here.
> >
>
> Even though it might seem like a redundant thing to do, I would still
> prefer to replace all existing JKS entries. The main reason for this is
> that I'm a bit afraid that we'll end with a mixture of pushed JKS files and
> automatically generated ones.
>
> Let's make a deal. I'll look more into this today and will see how many of
> those I'll manage to replace. Maybe it won't be that bad after all...
>
>
> > > The json file you're mentioning has a cert in pem format in the json
> file
> > > that is then stored in the DB. This doesn't have anything to do with
> > > keystores/truststores. We expect Keycloak to be able to handle a cert
> > > provided in the json file (or through admin endpoints) and store it in
> > the
> > > DB.
> > >
> > > Now for SSL tests with the server itself I can see the value in what
> you
> > > are proposing. Keystore/truststore for Keycloak https connections and
> > > truststores for mutual SSL could probably be improved. However, it
> seems
> > to
> > > be working at the moment, so not sure this is required.
>
>
>
> >
> > > On Wed, 25 Jul 2018 at 15:30, Sebastian Laskawiec <slaskawi at redhat.com
> >
> > > wrote:
> > >
> > >> Thanks Darran and Peter for the insight!
> > >>
> > >> I've just noticed that generating JKS files is one thing but we will
> > also
> > >> need to pre-process RealmRepresentation and replace all private/public
> > keys
> > >> (like this one for example [1]) with values from
> keystores/truststores.
> > >>
> > >> At the moment I'm thinking about replacing [1] with something like
> this:
> > >> "jwt.credential.certificate" :
> > >>
> > >>
> >
> "certificate:keystore=classpath:keystore.jks,password=password,alias=secure-portal,type=pkcs12"
> > >> similarly to private keys (if needed):
> > >> "privateKey" :
> > >>
> > >>
> >
> "private-key:keystore=classpath:keystore.jks,password=password,alias=secure-portal,type=pkcs12"
> > >>
> > >> Later on, while converting JSON to RealmRepresentation I plan to
> > traverse
> > >> all nodes and replace replace those which start with private-key or
> > >> certificate.
> > >>
> > >> Let me know if you have a better idea.
> > >>
> > >> [1]
> > >>
> > >>
> >
> https://github.com/keycloak/keycloak/blob/master/testsuite/integration-arquillian/tests/base/src/test/resources/adapter-test/demorealm.json#L231
> > >>
> > >> On Wed, Jul 25, 2018 at 2:07 PM Peter Skopek <pskopek at redhat.com>
> > wrote:
> > >>
> > >>> Hi Sebastian,
> > >>>
> > >>> I think that generation of Keystore on the fly is the only way to go.
> > >>> You can use Java Keystore API generate it entirely from Java code (no
> > >>> need to run maven).
> > >>>
> > >>> Here [1] is an example of utility class used in wildfly testsuite to
> > >>> generate Vault (basically just keystore).
> > >>> It will be easy to strip vault related stuff and use it in our
> > testsuite.
> > >>>
> > >>> Note that there is one more drawback of storing generated JKS files,
> > >>> which is that in some cases they are not binary compatible between
> > >>> different JDK (particularly Oracle and IBM).
> > >>>
> > >>> HTH,
> > >>> Peter
> > >>>
> > >>> [1]
> > >>>
> > >>
> >
> https://github.com/wildfly/wildfly/blob/master/testsuite/shared/src/main/java/org/jboss/as/test/integration/security/common/VaultHandler.java
> > >>> On Wed, Jul 25, 2018 at 1:23 PM Sebastian Laskawiec <
> > slaskawi at redhat.com
> > >>>
> > >>> wrote:
> > >>>> Hey,
> > >>>>
> > >>>> Together with Sebi we are working on Certificate-based
> authentication
> > >> for
> > >>>> the clients. Our work will require adding at least 2-3 keystores to
> > the
> > >>>> codebase with different DNs and I think this might be a good
> > >> opportunity
> > >>> to
> > >>>> revisit the way we handle JKS files in the tests.
> > >>>>
> > >>>> Currently we push JKS files directly into our repo, which has a
> couple
> > >> of
> > >>>> drawbacks:
> > >>>> - it is hard to figure out what's inside the JKS, it requires
> looking
> > >> up
> > >>>> for password (usually in some JSON configuration file or hardcoded
> in
> > >> the
> > >>>> test) and using keytool (or some similar one) to explore its
> content.
> > >>>> - It is not git-friendly. Every time we update JKS content we
> > >> effectively
> > >>>> store another binary file (git doesn't understand binary file
> changes
> > >> and
> > >>>> can not diff it).
> > >>>> - we use many different naming and password schemes in our tests.
> > >>>> - it is hard to migrate all keystores to pkcs12 at the same time
> (JKS
> > >>>> format is deprecated) [0]
> > >>>>
> > >>>> I believe most of the issues could be addressed by generating JKS
> > files
> > >>> on
> > >>>> the fly - during the build. In Infinispan we did it with Maven Ant
> > >> Plugin
> > >>>> [1]. I already created a very limited POC for Keycloak and you can
> > >> check
> > >>> it
> > >>>> out here [2]. Unfortunately, the process of reverse engineering all
> > >> those
> > >>>> files is quite time-consuming, so I would like to know your opinion
> > >>> before
> > >>>> moving on.
> > >>>>
> > >>>> Of course, generating JKS files on the fly has some drawbacks:
> > >>>> - It increases build time (~1s per keytool invocation, and we
> probably
> > >>> will
> > >>>> have more than 30 of them).
> > >>>> - it makes testing from IDE a bit harder, you need to run Maven and
> > >>> process
> > >>>> test resources before doing anything. A common workaround is to use
> > >> `mvn
> > >>>> clean install -DskipTests` and then opening your IntelliJ.
> > >>>>
> > >>>> Please let me know what you think.
> > >>>>
> > >>>> Thanks,
> > >>>> Sebastian
> > >>>>
> > >>>> [0]
> > >>>>
> > >>
> >
> https://blogs.oracle.com/jtc/jdk9-keytool-transitions-default-keystore-to-pkcs12
> > >>>> [1]
> > >>>>
> > >>
> >
> https://github.com/infinispan/infinispan/blob/master/server/integration/testsuite/pom.xml#L460
> > >>>> [2] https://github.com/keycloak/keycloak/pull/5410
> > >>>> _______________________________________________
> > >>>> 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 Sebastian.Schuster at bosch-si.com  Fri Jul 27 07:11:54 2018
From: Sebastian.Schuster at bosch-si.com (Schuster Sebastian (INST/ESY1))
Date: Fri, 27 Jul 2018 11:11:54 +0000
Subject: [keycloak-dev] Possible Bug when listing users with
 fine-grained permissions
In-Reply-To: <CAJrcDBdvCbfCkqwM9Bs5ycVk8po4oj8oPAc1c=XCg5j5vTiP5w@mail.gmail.com>
References: <5ccc909b43154c09a3b4937f602f9e00@bosch-si.com>
	<CAJrcDBcRVojhpVMWRqtJD_k3=DR6bRUN2fDk6WkSD=RMoBUS_g@mail.gmail.com>
	<b936474216134caf89cd73e2ff792d91@bosch-si.com>
	<CAJrcDBdvCbfCkqwM9Bs5ycVk8po4oj8oPAc1c=XCg5j5vTiP5w@mail.gmail.com>
Message-ID: <d5af62b47a1149c289f593440d527084@bosch-si.com>

Thanks Pedro, issue created: https://issues.jboss.org/browse/KEYCLOAK-7950

Best regards,
Sebastian

Mit freundlichen Gr??en / Best regards

Dr.-Ing. Sebastian Schuster

Engineering and Support (INST/ESY1)
Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin | GERMANY | www.bosch-si.com<http://www.bosch-si.com>
Tel. +49 30 726112-485 | Fax +49 30 726112-100 | Sebastian.Schuster at bosch-si.com<mailto:Sebastian.Schuster at bosch-si.com>

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



From: Pedro Igor Silva <psilva at redhat.com>
Sent: Donnerstag, 26. Juli 2018 19:57
To: Schuster Sebastian (INST/ESY1) <Sebastian.Schuster at bosch-si.com>
Cc: keycloak-dev <keycloak-dev at lists.jboss.org>
Subject: Re: [keycloak-dev] Possible Bug when listing users with fine-grained permissions



On Thu, Jul 26, 2018 at 11:56 AM, Schuster Sebastian (INST/ESY1) <Sebastian.Schuster at bosch-si.com<mailto:Sebastian.Schuster at bosch-si.com>> wrote:
Hi Pedro,

That would be kind of consistent with the behavior of the role ?query_groups?, allowing you to also see all group names, ids, and subgroups. However, on the users endpoint you get a lot more data, partly personal.
Unless the API is changed here (unlikely as it would be incompatible), I would prefer the current behavior of not seeing users at all if you miss the permission.

Yeah, I was thinking about something similar to "query_groups". Agree that for users this is should work differently.


Do you think that the third approach, filtering groups and joining contained users, would be worth investigating?

Yes, #3 seems to me the best among those options. Could you create a JIRA to track this ? One more thing to check when reviewing this functionality ...


Best regards,
Sebastian

Mit freundlichen Gr??en / Best regards

Dr.-Ing. Sebastian Schuster

Engineering and Support (INST/ESY1)
Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin | <https://maps.google.com/?q=Ullsteinstr.+128+%7C+12109+Berlin+%7C++%0D%0AGERMANY&entry=gmail&source=g> GERMANY | www.bosch-si.com<http://www.bosch-si.com>
Tel. +49 30 726112-485 | Fax +49 30 726112-100 | Sebastian.Schuster at bosch-si.com<mailto:Sebastian.Schuster at bosch-si.com>

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


From: Pedro Igor Silva <psilva at redhat.com<mailto:psilva at redhat.com>>
Sent: Donnerstag, 26. Juli 2018 14:06
To: Schuster Sebastian (INST/ESY1) <Sebastian.Schuster at bosch-si.com<mailto:Sebastian.Schuster at bosch-si.com>>
Cc: keycloak-dev <keycloak-dev at lists.jboss.org<mailto:keycloak-dev at lists.jboss.org>>
Subject: Re: [keycloak-dev] Possible Bug when listing users with fine-grained permissions



On Wed, Jul 25, 2018 at 12:10 PM, Schuster Sebastian (INST/ESY1) <Sebastian.Schuster at bosch-si.com<mailto:Sebastian.Schuster at bosch-si.com>> wrote:
Hello,

we are currently experiencing issues with the "View all users" functionality of the Keycloak Admin Console and the respective API call to /auth/admin/realms/{realm}/users when using the permissions based on the authorization services. In our case, we have users separated into groups and some users are able to view these by means of having the realm-management.query-users role and the group.view-members scope by means of a permission/policy. When such a user tries to view all the users he can see, he only gets a subset or even none.

The reason is that in UsersResource, first a paginated subset of users is retrieved that is than filtered by checking visibility for each user. In general, this will return less users than the page and the admin UI will not offer to go to the next page. Even if it did, with many users where you can see only a small subset having to skip over lots of empty pages won?t be feasible.

Since we really like to use this feature, we discussed several options to fix it:

1.     Keycloak should query for users until it reaches the number of requested viewable users or until it has evaluated all available users (-> can lead to performance issues with an increasing number of users, in the worst case Keycloak needs to pull all users out of the database just to find out the current user might see none)

2.     Do the same thing but in the admin console (-> no changes in Keycloak but lots of request, probably even worse idea)

3.     Since groups are the resources a user needs to have view-members scope to see users, retrieve all groups from the database, filter out groups without view-members scope and then do a join by group membership and limit the result by paging. (-> less generalized approach, probably better performance as long as there are not too many groups)

All of these seem to be far less than ideal.

Any thoughts?

Yeah, all these have drawbacks and they are hard to overcome. What about instead of hiding users, we just list all users and somehow indicate in the list which users access is not granted. We cold avoid clicking user and accessing his details (via UI or directly URI).


Best regards,
Sebastian

Mit freundlichen Gr??en / Best regards

Dr.-Ing. Sebastian Schuster

Engineering and Support (INST/ESY1)
Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin | GERMANY<https://maps.google.com/?q=Ullsteinstr.+128+%7C+12109+Berlin+%7C+GERMANY&entry=gmail&source=g> | www.bosch-si.com<http://www.bosch-si.com><http://www.bosch-si.com>
Tel. +49 30 726112-485 | Fax +49 30 726112-100 | Sebastian.Schuster at bosch-si.com<mailto:Sebastian.Schuster at bosch-si.com><mailto:Sebastian.Schuster at bosch-si.com<mailto:Sebastian.Schuster at bosch-si.com>>

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



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



From takashi.norimatsu.ws at hitachi.com  Sun Jul 29 20:40:37 2018
From: takashi.norimatsu.ws at hitachi.com (=?utf-8?B?5LmX5p2+6ZqG5b+XIC8gTk9SSU1BVFNV77yMVEFLQVNISQ==?=)
Date: Mon, 30 Jul 2018 00:40:37 +0000
Subject: [keycloak-dev] OAuth 2.0 Mutual TLS Client Authentication
In-Reply-To: <CAMZCGg8p2=Z95aE=PuawtOYXJDOZiJifYbkB5Ss_ucL0U_mdXQ@mail.gmail.com>
References: <TY2PR01MB26512F00C532C793EB937448CE2A0@TY2PR01MB2651.jpnprd01.prod.outlook.com>
	<CAMZCGg8p2=Z95aE=PuawtOYXJDOZiJifYbkB5Ss_ucL0U_mdXQ@mail.gmail.com>
Message-ID: <TY2PR01MB2651FA78064B1CE85E6B1EA7CE2F0@TY2PR01MB2651.jpnprd01.prod.outlook.com>

Hello Sebastien,

I've read the ticket you mentioned: https://issues.jboss.org/browse/KEYCLOAK-7635

I'm not sure what the token review endpoint is (similar to RFC 7662 OAuth 2.0 Token Introspection?), but I inferred the following situation.
* OpenShift accesses keycloak's token review endpoint with some token, but without client_id query parameter or client_id encoded Authorization header. Therefore, keycloak cannot conduct client authentication. In this situation, a client certificate might be used for client authentication in the context of OAuth 2.0.

Also, I'm not sure how to enclose client_id or client_id identifiable information onto a client certificate and extract it. So I would like to comment on other aspects other that it.

- register client dn
According to 2.1.2. Client Registration Metadata of OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens (https://tools.ietf.org/html/draft-ietf-oauth-mtls-10#section-2.1.2), each client has "tls_client_auth_subject_dn" metadata parameter's value. This has already been mentioned by @mposolda in https://issues.jboss.org/browse/KEYCLOAK-7512

In keycloak, OIDCClientRepresentation defines these OIDC Dynamic client registration properties.

OIDCAdvancedConfigWrapper can be used to convert these properties onto attributes of the client model.

DescriptionConverter can be used to convert internal representation of the client onto external one (through OIDC Dynamic client registration) and vice versa.

IMO, at least, those three classes have to be modified to support this new OIDC Client Registration property "tls_client_auth_subject_dn".

- extract client certificate

X509ClientCertificateLookup : 
https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/services/x509/X509ClientCertificateLookup.java
This Client Certificate Lookup provider can be used to leverage the feature supporting reverse proxy deployed environment mentioned in the server admin manual (https://www.keycloak.org/docs/latest/server_admin/index.html#client-certificate-lookup) .

You can consult 
https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/authentication/authenticators/x509/AbstractX509ClientCertificateAuthenticator.java#L196
to get how to use this client certificate lookup feature.

In order to use it, KeycloakSession and HttpRequest instances are required to find the Client Certificate Lookup provider implementation.

I've found that current ClientAuthenticator can get it by ClientAuthenticationFlowContext.getSession() and .getHttpRequest() in ClientAuthenticator.authenticateClient(ClientAuthenticationFlowContext context).

- server side metadata advertisement

OIDCConfigurationRepresentation is a server side metadata representation and might be related to 2.1.1. PKI Authentication Method Metadata Value of OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens (https://tools.ietf.org/html/draft-ietf-oauth-mtls-10#section-2.1.1)

Best regards,
Takashi Norimatsu
Hitachi Ltd.,

----------
From: Sebastien Blanc <sblanc at redhat.com> 
Sent: Friday, July 27, 2018 4:31 PM
To: ???? / NORIMATSU?TAKASHI <takashi.norimatsu.ws at hitachi.com>
Cc: Sebastian Laskawiec <slaskawi at redhat.com>; keycloak-dev at lists.jboss.org
Subject: [!]Re: [keycloak-dev] OAuth 2.0 Mutual TLS Client Authentication

Hi Takashi !

You can even help before if you want to :)

The ticket is here : https://issues.jboss.org/browse/KEYCLOAK-7635

I created an "empty" X509ClientAuthenticator" branch here  :
https://github.com/sebastienblanc/keycloak/tree/client-x509

And I'm investigating what we can reuse from this pacakge :
https://github.com/keycloak/keycloak/tree/master/services/src/main/java/org/keycloak/authentication/authenticators/x509

Any feedback, help, advise is welcome !

Sebi


On Fri, Jul 27, 2018 at 3:22 AM, ???? / NORIMATSU?TAKASHI <
takashi.norimatsu.ws at hitachi.com> wrote:

> Hello Sebastian,
>
> I'm looking forward to your work, and I would be happy if I could make
> some contribution after finishing your work.
>
> Best regards,
> Takashi Norimatsu
> Hitachi Ltd.,
>
> ----------
> From: Sebastian Laskawiec <slaskawi at redhat.com>
> Sent: Thursday, July 26, 2018 5:24 PM
> To: ???? / NORIMATSU?TAKASHI <takashi.norimatsu.ws at hitachi.com>
> Cc: keycloak-dev at lists.jboss.org
> Subject: [!]Re: [keycloak-dev] OAuth 2.0 Mutual TLS Client Authentication
>
> Hey Takashi,
>
> Thanks a lot for the interest in contributing Keycloak!
>
> Sebi and I are working on this topic currently. We plan to reuse some bits
> of the User x509 Authentication and bring them to the client. We planned
> the implementation for this sprint, so it *should* be ready in ~3 weeks.
>
> More comments inlined.
>
> Thanks,
> Sebastian
> On Thu, Jul 26, 2018 at 1:23 AM ???? / NORIMATSU?TAKASHI <
> takashi.norimatsu.ws at hitachi.com> wrote:
> Hello,
>
> As for mentioned in https://issues.jboss.org/browse/KEYCLOAK-7512 and
> https://issues.jboss.org/browse/KEYCLOAK-7635, Is there anyone who
> currently implements OAuth 2.0 Mutual TLS Client Authentication defined in
> https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-2 ?
>
> We also have additional requirement - allow to authenticate client without
> "client_id" being sent (we need to extract it from the Certificate obtained
> during TLS Handshake). This is required for OpenShift integration.
>
>
> If no one does it, I would like to try to implement this feature. What do
> you think about it ?
>
> Also, In https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-2,
> two types of OAuth 2.0 Mutual TLS Client Authentication are defined, for
> PKI and for Self-Signed Certificate.
>
> I would be happy if you who are interested in this feature tell me which
> you like better.
>
> As far as I know, we won't be touching self-registering clients. So maybe
> once we are done (let's assume that will happen in ~3 weeks), you could
> take it over and look into that?
>
> BTW, as for now, we will be implementing everything in this branch:
> https://github.com/sebastienblanc/keycloak/tree/client-x509 (currently,
> it contains an empty Authenticator but we will be adding bits and pieces to
> it).
>
>
> Best regards,
> Takashi Norimatsu
> Hitachi Ltd.,
>
> _______________________________________________
> 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 sblanc at redhat.com  Mon Jul 30 03:20:35 2018
From: sblanc at redhat.com (Sebastien Blanc)
Date: Mon, 30 Jul 2018 09:20:35 +0200
Subject: [keycloak-dev] OAuth 2.0 Mutual TLS Client Authentication
In-Reply-To: <TY2PR01MB2651FA78064B1CE85E6B1EA7CE2F0@TY2PR01MB2651.jpnprd01.prod.outlook.com>
References: <TY2PR01MB26512F00C532C793EB937448CE2A0@TY2PR01MB2651.jpnprd01.prod.outlook.com>
	<CAMZCGg8p2=Z95aE=PuawtOYXJDOZiJifYbkB5Ss_ucL0U_mdXQ@mail.gmail.com>
	<TY2PR01MB2651FA78064B1CE85E6B1EA7CE2F0@TY2PR01MB2651.jpnprd01.prod.outlook.com>
Message-ID: <CAMZCGg_vtWZEN2rPrQsw4bfPW_CTZi1m+D=YE6D8ytpxJ6wxGg@mail.gmail.com>

Thanks Takashi, this is really useful information. Some comments inline

On Mon, Jul 30, 2018 at 2:40 AM, ???? / NORIMATSU?TAKASHI <
takashi.norimatsu.ws at hitachi.com> wrote:

> Hello Sebastien,
>
> I've read the ticket you mentioned: https://issues.jboss.org/
> browse/KEYCLOAK-7635
>
> I'm not sure what the token review endpoint is (similar to RFC 7662 OAuth
> 2.0 Token Introspection?), but I inferred the following situation.
> * OpenShift accesses keycloak's token review endpoint with some token, but
> without client_id query parameter or client_id encoded Authorization
> header. Therefore, keycloak cannot conduct client authentication. In this
> situation, a client certificate might be used for client authentication in
> the context of OAuth 2.0.
>
> Also, I'm not sure how to enclose client_id or client_id identifiable
> information onto a client certificate and extract it. So I would like to
> comment on other aspects other that it.
>
> - register client dn
> According to 2.1.2. Client Registration Metadata of OAuth 2.0 Mutual TLS
> Client Authentication and Certificate Bound Access Tokens (
> https://tools.ietf.org/html/draft-ietf-oauth-mtls-10#section-2.1.2), each
> client has "tls_client_auth_subject_dn" metadata parameter's value. This
> has already been mentioned by @mposolda in https://issues.jboss.org/
> browse/KEYCLOAK-7512
>
> In keycloak, OIDCClientRepresentation defines these OIDC Dynamic client
> registration properties.
>
> OIDCAdvancedConfigWrapper can be used to convert these properties onto
> attributes of the client model.
>
> DescriptionConverter can be used to convert internal representation of the
> client onto external one (through OIDC Dynamic client registration) and
> vice versa.
>
> IMO, at least, those three classes have to be modified to support this new
> OIDC Client Registration property "tls_client_auth_subject_dn".
>
This is a nice complement to what Marek said in the ticket and makes thing
clearer for me as well.
But this would mean that Openshift should use dynamic client registration
to make this flow works ?

>
> - extract client certificate
>
> X509ClientCertificateLookup :
> https://github.com/keycloak/keycloak/blob/master/services/
> src/main/java/org/keycloak/services/x509/X509ClientCertificateLookup.java
> This Client Certificate Lookup provider can be used to leverage the
> feature supporting reverse proxy deployed environment mentioned in the
> server admin manual (https://www.keycloak.org/docs/latest/server_admin/
> index.html#client-certificate-lookup) .
>
> You can consult
> https://github.com/keycloak/keycloak/blob/master/services/
> src/main/java/org/keycloak/authentication/authenticators/x509/
> AbstractX509ClientCertificateAuthenticator.java#L196
> to get how to use this client certificate lookup feature.
>
> In order to use it, KeycloakSession and HttpRequest instances are required
> to find the Client Certificate Lookup provider implementation.
>
> I've found that current ClientAuthenticator can get it by
> ClientAuthenticationFlowContext.getSession() and .getHttpRequest() in
> ClientAuthenticator.authenticateClient(ClientAuthenticationFlowContext
> context).
>

Yes, I started to test that, exactly with this classes and methods but
until now I fail to retrieve any certificate (probably because of my local
setup/configuration).

>
> - server side metadata advertisement
>
> OIDCConfigurationRepresentation is a server side metadata representation
> and might be related to 2.1.1. PKI Authentication Method Metadata Value of
> OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access
> Tokens (https://tools.ietf.org/html/draft-ietf-oauth-mtls-10#section-2.1.1
> )
>
> Best regards,
> Takashi Norimatsu
> Hitachi Ltd.,
>
> ----------
> From: Sebastien Blanc <sblanc at redhat.com>
> Sent: Friday, July 27, 2018 4:31 PM
> To: ???? / NORIMATSU?TAKASHI <takashi.norimatsu.ws at hitachi.com>
> Cc: Sebastian Laskawiec <slaskawi at redhat.com>;
> keycloak-dev at lists.jboss.org
> Subject: [!]Re: [keycloak-dev] OAuth 2.0 Mutual TLS Client Authentication
>
> Hi Takashi !
>
> You can even help before if you want to :)
>
> The ticket is here : https://issues.jboss.org/browse/KEYCLOAK-7635
>
> I created an "empty" X509ClientAuthenticator" branch here  :
> https://github.com/sebastienblanc/keycloak/tree/client-x509
>
> And I'm investigating what we can reuse from this pacakge :
> https://github.com/keycloak/keycloak/tree/master/services/
> src/main/java/org/keycloak/authentication/authenticators/x509
>
> Any feedback, help, advise is welcome !
>
> Sebi
>
>
> On Fri, Jul 27, 2018 at 3:22 AM, ???? / NORIMATSU?TAKASHI <
> takashi.norimatsu.ws at hitachi.com> wrote:
>
> > Hello Sebastian,
> >
> > I'm looking forward to your work, and I would be happy if I could make
> > some contribution after finishing your work.
> >
> > Best regards,
> > Takashi Norimatsu
> > Hitachi Ltd.,
> >
> > ----------
> > From: Sebastian Laskawiec <slaskawi at redhat.com>
> > Sent: Thursday, July 26, 2018 5:24 PM
> > To: ???? / NORIMATSU?TAKASHI <takashi.norimatsu.ws at hitachi.com>
> > Cc: keycloak-dev at lists.jboss.org
> > Subject: [!]Re: [keycloak-dev] OAuth 2.0 Mutual TLS Client Authentication
> >
> > Hey Takashi,
> >
> > Thanks a lot for the interest in contributing Keycloak!
> >
> > Sebi and I are working on this topic currently. We plan to reuse some
> bits
> > of the User x509 Authentication and bring them to the client. We planned
> > the implementation for this sprint, so it *should* be ready in ~3 weeks.
> >
> > More comments inlined.
> >
> > Thanks,
> > Sebastian
> > On Thu, Jul 26, 2018 at 1:23 AM ???? / NORIMATSU?TAKASHI <
> > takashi.norimatsu.ws at hitachi.com> wrote:
> > Hello,
> >
> > As for mentioned in https://issues.jboss.org/browse/KEYCLOAK-7512 and
> > https://issues.jboss.org/browse/KEYCLOAK-7635, Is there anyone who
> > currently implements OAuth 2.0 Mutual TLS Client Authentication defined
> in
> > https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-2 ?
> >
> > We also have additional requirement - allow to authenticate client
> without
> > "client_id" being sent (we need to extract it from the Certificate
> obtained
> > during TLS Handshake). This is required for OpenShift integration.
> >
> >
> > If no one does it, I would like to try to implement this feature. What do
> > you think about it ?
> >
> > Also, In https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-2,
> > two types of OAuth 2.0 Mutual TLS Client Authentication are defined, for
> > PKI and for Self-Signed Certificate.
> >
> > I would be happy if you who are interested in this feature tell me which
> > you like better.
> >
> > As far as I know, we won't be touching self-registering clients. So maybe
> > once we are done (let's assume that will happen in ~3 weeks), you could
> > take it over and look into that?
> >
> > BTW, as for now, we will be implementing everything in this branch:
> > https://github.com/sebastienblanc/keycloak/tree/client-x509 (currently,
> > it contains an empty Authenticator but we will be adding bits and pieces
> to
> > it).
> >
> >
> > Best regards,
> > Takashi Norimatsu
> > Hitachi Ltd.,
> >
> > _______________________________________________
> > 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 l.lech at ringler.ch  Mon Jul 30 04:17:56 2018
From: l.lech at ringler.ch (Lukasz Lech)
Date: Mon, 30 Jul 2018 08:17:56 +0000
Subject: [keycloak-dev] Cookie support for Jax-RS filter
Message-ID: <5E48B917000C984B86B77170F441903A119B3B20@exch.ringler.ch>

Hello,

I'm rewriting my Java app secured 'classically' using session-stored credentials to Keycloak.  My app is AJAX client with REST channel implemented using JAX-RS, so I've picked up keycloak-jaxrs-oauth-client and  JaxrsBearerTokenFilterImpl. However, I have one place which I can't (or I don't see the way to do this) secure using that way: those are URLs that produce binary resources, available as direct downloads ( window.open ) and images (within img tag). I can't instruct browser to add Authorization token in that place, however, the classical cookie approach would work.

I can't find a way to use Cookies with given filter, but I ses that BearerTokenRequestAuthenticator is already made extensible (it has QueryParam implementation), however the JaxrsBearerTokenFilterImpl doesn't five a way to choose implementation.

Are there  any approaches for  (optional) cookie based approach made?

If the change was made to the bearerAuthentication method to replace
    BearerTokenRequestAuthenticator authenticator = new BearerTokenRequestAuthenticator(resolvedDeployment);
With
    BearerTokenRequestAuthenticator authenticator = createBearerTokenRequestAuthenticator(resolvedDeployment);
I could be free to change the implementation of that method in  my custom class with the strategy of my choice (either pure cookie-based strategy, or use cookie only when no Authorization header is present.

Is such change-request a reasonable approach, that could be accepted for the community code base?

Best regards,
Lukasz Lech


From jambo_mcd at yahoo.co.uk  Mon Jul 30 05:20:10 2018
From: jambo_mcd at yahoo.co.uk (Jamie McDowell)
Date: Mon, 30 Jul 2018 09:20:10 +0000 (UTC)
Subject: [keycloak-dev] kcadm - adding a protocol-mapper
In-Reply-To: <98566890.3575432.1532708944298@mail.yahoo.com>
References: <393991387.3571827.1532708749385.ref@mail.yahoo.com>
	<393991387.3571827.1532708749385@mail.yahoo.com>
	<98566890.3575432.1532708944298@mail.yahoo.com>
Message-ID: <1463277619.4619303.1532942410396@mail.yahoo.com>

Hi,

I am trying to add a client protocol-mapper however when i try and run this i get a?HTTP error - 500 Internal Server Error
opt/jboss/keycloak/bin/kcadm.sh create \clients/<id>/protocol-mappers/models \-r demorealm \-s protocol=openid-connect \-s protocolMapper=oidc-usermodel-realm-mapper \-s consentRequired=false \-s config.claim.name=group_membership \-s config.jsonType.label=String \-s config.id.token.claim=true \-s config.access.token.claim=true \-s config.userinfo.token.claim=true \-s config.multivalued=true \-s name=Realm \
I can confirm that kcadm works as i have been able to create groups, LDAP mappers, realms etc...
In the server.log i can see the below error when i run the above
ERROR [org.keycloak.services.error.KeycloakErrorHandler] (default task-109) Uncaught server error: com.fasterxml.jackson.databind.JsonMappingException: Can notat [Source: io.undertow.servlet.spec.ServletInputStreamImpl at 55dee6f8; line: 1, column: 119] (through reference chain: org.keycloak.representations.idm.ProtocolMapperRepresentation["co? ? ? ?at com.fasterxml.jackson.databind.JsonMappingException.from(JsonMappingException.java:270) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?? ? ? ?at com.fasterxml.jackson.databind.DeserializationContext.reportMappingException(DeserializationContext.java:1234) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?? ? ? ?at com.fasterxml.jackson.databind.DeserializationContext.handleUnexpectedToken(DeserializationContext.java:1122) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?? ? ? ?at com.fasterxml.jackson.databind.DeserializationContext.handleUnexpectedToken(DeserializationContext.java:1075) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?? ? ? ?at com.fasterxml.jackson.databind.deser.std.StringDeserializer.deserialize(StringDeserializer.java:60)
Appreciate if anyone can advise on this (keycloak version is 3.4.3)
Thanks?Jamie    

From sthorger at redhat.com  Mon Jul 30 07:03:57 2018
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 30 Jul 2018 13:03:57 +0200
Subject: [keycloak-dev] Keycloak URL and backchannel requests
Message-ID: <CAJgngAe4Kx12VS+7iSqwCSsEt9HTs76wSv2jNZsrFCuW05Q-nw@mail.gmail.com>

Keycloak needs to know its public URL for a number of reasons. For example
in the OIDC well-known endpoint, issuer in tokens and emails sent to users.

At the moment we retrieve this from the request headers and have documented
how to block requests with invalid URLs (
https://www.keycloak.org/docs/latest/server_admin/index.html#host). The
latter is important in production installations.

There's two problems with the current approach:

1) Clients in the same subnet can't use internal IP to communicate with
Keycloak
2) Configuring the valid URLs is an important step to secure a production
installation, but the current approach is probably not well known and is
rather messy to configure

I propose we introduce an BaseURL SPI to allow a flexible way to determine
the base URL. We would add two implementations OOTB:

1) Request - this would be set as the default-provider and would determine
the base url from request headers as we do today
2) Fixed - this would allow setting a hardcoded public URL

In standalone.xml it would look like this:

<spi name="baseURL">
    <default-provider>request</default-provider>
    <provider name="fixed">
       <properties>
         <property name="baseURL" value="localhost:8080/auth"/>
       </properties>
   </provider>
</spi>

For production the default-provider should be changed to fixed and the
baseURL value should be changed. This can be handled either through manual
editing standalone.xml or with jboss-cli.

Once this is incorporated it will make it easy to add support for
backchannel URL back to the adapters to allow adapters to use internal IP
address when communicating with Keycloak.

Implementation shouldn't be hard. It's mainly about making sure that
UriInfo is retrieved from KeycloakSession#KeycloakContext and not injected
directly.

If anyone has more complex requirements for determining the public URL they
can implement their own provider to handle it.

One thing I'm not sure about is if it's common to use different URLs for
different realms. If that's the case we may consider adding some support
for mapping different realms to different baseURLs. I don't think this is
common though.

From sthorger at redhat.com  Mon Jul 30 07:24:20 2018
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 30 Jul 2018 13:24:20 +0200
Subject: [keycloak-dev] Redundant div end tag in base theme login.ftl
In-Reply-To: <CAEvJjXcHfMxLXB0zHFiHOmf89dnMgJq7CT=hnbxdnx29Ar9LmQ@mail.gmail.com>
References: <CAEvJjXcHfMxLXB0zHFiHOmf89dnMgJq7CT=hnbxdnx29Ar9LmQ@mail.gmail.com>
Message-ID: <CAJgngAecB7jNNspA8jqntmzwhrNb-DvcH22xYdp5Pk1DctsvgA@mail.gmail.com>

At a quick glance it does indeed look redundant. Please create a JIRA and
would be great if you sent a PR with it.

On Thu, 26 Jul 2018 at 12:14, Chih-Chun Lee ??? <timmy.ccl at gmail.com> wrote:

> Hello,
>
> We found a redundant div end tag while creating our custom theme.
>
> Please check this out:
>
> https://github.com/keycloak/keycloak/blob/ca15db81bb5d84e9ba0f5203dbc868f90288b6e2/themes/src/main/resources/theme/base/login/login.ftl#L50
>
> Best regards,
> Timothy
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From slaskawi at redhat.com  Mon Jul 30 07:28:02 2018
From: slaskawi at redhat.com (Sebastian Laskawiec)
Date: Mon, 30 Jul 2018 13:28:02 +0200
Subject: [keycloak-dev] Keycloak URL and backchannel requests
In-Reply-To: <CAJgngAe4Kx12VS+7iSqwCSsEt9HTs76wSv2jNZsrFCuW05Q-nw@mail.gmail.com>
References: <CAJgngAe4Kx12VS+7iSqwCSsEt9HTs76wSv2jNZsrFCuW05Q-nw@mail.gmail.com>
Message-ID: <CAA9R9O5Spy5aVC0wV6ujKvkfpu0RPsLe7uvL8RzLXW9KG9fJzA@mail.gmail.com>

On Mon, Jul 30, 2018 at 1:05 PM Stian Thorgersen <sthorger at redhat.com>
wrote:

> Keycloak needs to know its public URL for a number of reasons. For example
> in the OIDC well-known endpoint, issuer in tokens and emails sent to users.
>
> At the moment we retrieve this from the request headers and have documented
> how to block requests with invalid URLs (
> https://www.keycloak.org/docs/latest/server_admin/index.html#host). The
> latter is important in production installations.
>
> There's two problems with the current approach:
>
> 1) Clients in the same subnet can't use internal IP to communicate with
> Keycloak
> 2) Configuring the valid URLs is an important step to secure a production
> installation, but the current approach is probably not well known and is
> rather messy to configure


> I propose we introduce an BaseURL SPI to allow a flexible way to determine
> the base URL. We would add two implementations OOTB:
>
> 1) Request - this would be set as the default-provider and would determine
> the base url from request headers as we do today
> 2) Fixed - this would allow setting a hardcoded public URL
>

How about adding a third option - "None". This would mean the Keycloak
operates without a fixed public IP (the implementation could probably call
back into "localhost:8080/auth" using a "Fixed" implementation). However,
with "None" we would be explicitly saying that there's no public IP and all
requests need to be local (e.g. from the same machine or Pod (sidecar
approach)).


>
> In standalone.xml it would look like this:
>
> <spi name="baseURL">
>     <default-provider>request</default-provider>
>     <provider name="fixed">
>        <properties>
>          <property name="baseURL" value="localhost:8080/auth"/>
>        </properties>
>    </provider>
> </spi>
>
> For production the default-provider should be changed to fixed and the
> baseURL value should be changed. This can be handled either through manual
> editing standalone.xml or with jboss-cli.
>

How about using the "None" as the default here?


>
> Once this is incorporated it will make it easy to add support for
> backchannel URL back to the adapters to allow adapters to use internal IP
> address when communicating with Keycloak.
>
> Implementation shouldn't be hard. It's mainly about making sure that
> UriInfo is retrieved from KeycloakSession#KeycloakContext and not injected
> directly.
>
> If anyone has more complex requirements for determining the public URL they
> can implement their own provider to handle it.
>
> One thing I'm not sure about is if it's common to use different URLs for
> different realms. If that's the case we may consider adding some support
> for mapping different realms to different baseURLs. I don't think this is
> common though.
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sthorger at redhat.com  Mon Jul 30 07:51:11 2018
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 30 Jul 2018 13:51:11 +0200
Subject: [keycloak-dev] Keycloak URL and backchannel requests
In-Reply-To: <CAA9R9O5Spy5aVC0wV6ujKvkfpu0RPsLe7uvL8RzLXW9KG9fJzA@mail.gmail.com>
References: <CAJgngAe4Kx12VS+7iSqwCSsEt9HTs76wSv2jNZsrFCuW05Q-nw@mail.gmail.com>
	<CAA9R9O5Spy5aVC0wV6ujKvkfpu0RPsLe7uvL8RzLXW9KG9fJzA@mail.gmail.com>
Message-ID: <CAJgngAcavpvA9pmREHg2GnNinmytp9=YrwRptcxr=4OpC6g1hg@mail.gmail.com>

On Mon, 30 Jul 2018 at 13:28, Sebastian Laskawiec <slaskawi at redhat.com>
wrote:

>
>
> On Mon, Jul 30, 2018 at 1:05 PM Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> Keycloak needs to know its public URL for a number of reasons. For example
>> in the OIDC well-known endpoint, issuer in tokens and emails sent to
>> users.
>>
>> At the moment we retrieve this from the request headers and have
>> documented
>> how to block requests with invalid URLs (
>> https://www.keycloak.org/docs/latest/server_admin/index.html#host). The
>> latter is important in production installations.
>>
>> There's two problems with the current approach:
>>
>> 1) Clients in the same subnet can't use internal IP to communicate with
>> Keycloak
>> 2) Configuring the valid URLs is an important step to secure a production
>> installation, but the current approach is probably not well known and is
>> rather messy to configure
>
>
>> I propose we introduce an BaseURL SPI to allow a flexible way to determine
>> the base URL. We would add two implementations OOTB:
>>
>> 1) Request - this would be set as the default-provider and would determine
>> the base url from request headers as we do today
>> 2) Fixed - this would allow setting a hardcoded public URL
>>
>
> How about adding a third option - "None". This would mean the Keycloak
> operates without a fixed public IP (the implementation could probably call
> back into "localhost:8080/auth" using a "Fixed" implementation). However,
> with "None" we would be explicitly saying that there's no public IP and all
> requests need to be local (e.g. from the same machine or Pod (sidecar
> approach)).
>

Keycloak has to know what URL users should be accessing it on. That can be
an internal URL or external URL, but Keycloak needs to know the actual URL.
There's really no such thing as a Keycloak server only reached internally.
Users needs to be able to login, they need links in password recovery
emails, etc, etc.


>
>
>>
>> In standalone.xml it would look like this:
>>
>> <spi name="baseURL">
>>     <default-provider>request</default-provider>
>>     <provider name="fixed">
>>        <properties>
>>          <property name="baseURL" value="localhost:8080/auth"/>
>>        </properties>
>>    </provider>
>> </spi>
>>
>> For production the default-provider should be changed to fixed and the
>> baseURL value should be changed. This can be handled either through manual
>> editing standalone.xml or with jboss-cli.
>>
>
> How about using the "None" as the default here?
>
>
>>
>> Once this is incorporated it will make it easy to add support for
>> backchannel URL back to the adapters to allow adapters to use internal IP
>> address when communicating with Keycloak.
>>
>> Implementation shouldn't be hard. It's mainly about making sure that
>> UriInfo is retrieved from KeycloakSession#KeycloakContext and not injected
>> directly.
>>
>> If anyone has more complex requirements for determining the public URL
>> they
>> can implement their own provider to handle it.
>>
>> One thing I'm not sure about is if it's common to use different URLs for
>> different realms. If that's the case we may consider adding some support
>> for mapping different realms to different baseURLs. I don't think this is
>> common though.
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>

From ddtxra at gmail.com  Mon Jul 30 09:30:39 2018
From: ddtxra at gmail.com (Daniel Teixeira)
Date: Mon, 30 Jul 2018 15:30:39 +0200
Subject: [keycloak-dev] SAML users should not be identified by SAML:NameID
Message-ID: <CAHvCgvwsURtAuWMhcPi0EKBczgj4KzctmjJYgTEtEqxQw=3GKA@mail.gmail.com>

Hello,

Seems like Keycloak always uses the saml:NameID to identify a SAML user.
In org.keycloak.broker.saml.SAMLEndpoint we see:

BrokeredIdentityContext identity = new
BrokeredIdentityContext(subjectNameID.getValue());
...
identity.setUsername(subjectNameID.getValue());

However this is not a good practice, see recommendations here:
https://kantarainitiative.github.io/SAMLprofiles/saml2int.html

*SPs MUST NOT require the presence of a <saml:NameID> element and MUST NOT
rely on the content of this element for long term identification of
subjects; <saml:Attribute> elements MUST be used for this purpose in
the *manner
detailed below.

IMO, Keycloak should provide a field when configuring an iDP to choose the
custom attribute to "identify" a user. This can be mail attribute for
example (urn:oid:0.9.2342.19200300.100.1.3). But should not take this
information from saml:NameID

Is there anyway to override this in Keycloak?
Should I create a JIRA issue?

Best regards,
Daniel Teixeira

From timmy.ccl at gmail.com  Mon Jul 30 10:49:43 2018
From: timmy.ccl at gmail.com (=?UTF-8?B?Q2hpaC1DaHVuIExlZSDmnY7lv5fntJQ=?=)
Date: Mon, 30 Jul 2018 22:49:43 +0800
Subject: [keycloak-dev] Redundant div end tag in base theme login.ftl
In-Reply-To: <CAJgngAecB7jNNspA8jqntmzwhrNb-DvcH22xYdp5Pk1DctsvgA@mail.gmail.com>
References: <CAEvJjXcHfMxLXB0zHFiHOmf89dnMgJq7CT=hnbxdnx29Ar9LmQ@mail.gmail.com>
	<CAJgngAecB7jNNspA8jqntmzwhrNb-DvcH22xYdp5Pk1DctsvgA@mail.gmail.com>
Message-ID: <CAEvJjXcL_dr9DbOSqfg6z7wcYRc_-OyivDTK=mkWxdUm_a2mhw@mail.gmail.com>

I created a ticket and sent a PR. Thank you for help!
https://issues.jboss.org/browse/KEYCLOAK-7965

Best regards,
Timothy

On Mon, Jul 30, 2018 at 7:24 PM, Stian Thorgersen <sthorger at redhat.com>
wrote:

> At a quick glance it does indeed look redundant. Please create a JIRA and
> would be great if you sent a PR with it.
>
> On Thu, 26 Jul 2018 at 12:14, Chih-Chun Lee ??? <timmy.ccl at gmail.com>
> wrote:
>
>> Hello,
>>
>> We found a redundant div end tag while creating our custom theme.
>>
>> Please check this out:
>> https://github.com/keycloak/keycloak/blob/ca15db81bb5d84e9ba0f5203dbc868
>> f90288b6e2/themes/src/main/resources/theme/base/login/login.ftl#L50
>>
>> Best regards,
>> Timothy
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>

From hmlnarik at redhat.com  Mon Jul 30 11:06:04 2018
From: hmlnarik at redhat.com (Hynek Mlnarik)
Date: Mon, 30 Jul 2018 17:06:04 +0200
Subject: [keycloak-dev] SAML users should not be identified by
	SAML:NameID
In-Reply-To: <CAHvCgvwsURtAuWMhcPi0EKBczgj4KzctmjJYgTEtEqxQw=3GKA@mail.gmail.com>
References: <CAHvCgvwsURtAuWMhcPi0EKBczgj4KzctmjJYgTEtEqxQw=3GKA@mail.gmail.com>
Message-ID: <CAMvXD=HrB3Sao+crY83MDsdw_zUjDKrrnbrRcMwBKuVp8MwLpg@mail.gmail.com>

Yes, please file a feature request JIRA

On Mon, Jul 30, 2018 at 3:33 PM Daniel Teixeira <ddtxra at gmail.com> wrote:

> Hello,
>
> Seems like Keycloak always uses the saml:NameID to identify a SAML user.
> In org.keycloak.broker.saml.SAMLEndpoint we see:
>
> BrokeredIdentityContext identity = new
> BrokeredIdentityContext(subjectNameID.getValue());
> ...
> identity.setUsername(subjectNameID.getValue());
>
> However this is not a good practice, see recommendations here:
> https://kantarainitiative.github.io/SAMLprofiles/saml2int.html
>
> *SPs MUST NOT require the presence of a <saml:NameID> element and MUST NOT
> rely on the content of this element for long term identification of
> subjects; <saml:Attribute> elements MUST be used for this purpose in
> the *manner
> detailed below.
>
> IMO, Keycloak should provide a field when configuring an iDP to choose the
> custom attribute to "identify" a user. This can be mail attribute for
> example (urn:oid:0.9.2342.19200300.100.1.3). But should not take this
> information from saml:NameID
>
> Is there anyway to override this in Keycloak?
> Should I create a JIRA issue?
>
> Best regards,
> Daniel Teixeira
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From jcain at redhat.com  Mon Jul 30 11:43:23 2018
From: jcain at redhat.com (Josh Cain)
Date: Mon, 30 Jul 2018 10:43:23 -0500
Subject: [keycloak-dev] SAML users should not be identified by
 SAML:NameID
In-Reply-To: <CAMvXD=HrB3Sao+crY83MDsdw_zUjDKrrnbrRcMwBKuVp8MwLpg@mail.gmail.com>
References: <CAHvCgvwsURtAuWMhcPi0EKBczgj4KzctmjJYgTEtEqxQw=3GKA@mail.gmail.com>
	<CAMvXD=HrB3Sao+crY83MDsdw_zUjDKrrnbrRcMwBKuVp8MwLpg@mail.gmail.com>
Message-ID: <0f8f7546e973a5fec7983a67f5ed2d944d7ea337.camel@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

+1 for this, we're going to need it.

On Mon, 2018-07-30 at 17:06 +0200, Hynek Mlnarik wrote:
> Yes, please file a feature request JIRA
> 
> On Mon, Jul 30, 2018 at 3:33 PM Daniel Teixeira <ddtxra at gmail.com>
> wrote:
> 
> > Hello,
> > 
> > Seems like Keycloak always uses the saml:NameID to identify a SAML
> > user.
> > In org.keycloak.broker.saml.SAMLEndpoint we see:
> > 
> > BrokeredIdentityContext identity = new
> > BrokeredIdentityContext(subjectNameID.getValue());
> > ...
> > identity.setUsername(subjectNameID.getValue());
> > 
> > However this is not a good practice, see recommendations here:
> > https://kantarainitiative.github.io/SAMLprofiles/saml2int.html
> > 
> > *SPs MUST NOT require the presence of a <saml:NameID> element and
> > MUST NOT
> > rely on the content of this element for long term identification of
> > subjects; <saml:Attribute> elements MUST be used for this purpose
> > in
> > the *manner
> > detailed below.
> > 
> > IMO, Keycloak should provide a field when configuring an iDP to
> > choose the
> > custom attribute to "identify" a user. This can be mail attribute
> > for
> > example (urn:oid:0.9.2342.19200300.100.1.3). But should not take
> > this
> > information from saml:NameID
> > 
> > Is there anyway to override this in Keycloak?
> > Should I create a JIRA issue?
> > 
> > Best regards,
> > Daniel Teixeira
> > _______________________________________________
> > 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
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEyXW6Vl+0L9r9LpVurGNtyYPQwPgFAltfMhsACgkQrGNtyYPQ
wPgjvA//VEuBittUNwRDJlr0DTsRmHvMxNZiIh8NQaiz02aLd6Q0H1Su7z4Cpx8q
eqNSRYue1r0hWRg/fOxsibWtK2q875iy2J+bT4RaBJyTo/v8vlV39G8kEZcYsjY9
sDcHX/8r/5YnFNdWJt6P5thHyMzIeX5/WLss9XJd9+StG8d9qCc+7a8OZgEv09GO
TU9en30ESK6AiBd6LZlXRe2P63l1z35kAtmq2b+fDsc43db+vlcYcdNIbUBa24oc
He1foH+0KAM6iqPV0CYsB8pBt/EhELuCU7qAUO2qIVXmYGWNMGS083r/WcaO8/+X
r2FYNKF7IRT11km453jOyWUwlYMEA1rVKDb/kQMkakohk798wixdnYm0sSm1BPhQ
hnhmWB9jJ/3RTTOj4+o/A9oeftQeVRm2Pv407X5bS6eFTa4dFpvqxSu1dk6GK/Aa
4V6VW64Rs7UiZaRXzJmzQyCvmtdyHdT5hbKlyU+ksEw20RV2agECJhuXxjXLG1hQ
KLkpRCYa6jNT76rRNvxpZVqkyRBGMB1myPe6v8hLe6R5mxwTIoW049mFnREXVNFp
cWgzAnwSSlNH3wrL+SVNEzb+jBi1fno2i4t29r8uvOPD52aCh7EvybitIvDIFC7S
eXzY11neuk4ry9j4VKb2vHadIXXnoUFii3CwBhKf/JVKToy2P2o=
=I7Oy
-----END PGP SIGNATURE-----


From sthorger at redhat.com  Mon Jul 30 13:48:21 2018
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 30 Jul 2018 19:48:21 +0200
Subject: [keycloak-dev] Improved CSP support
In-Reply-To: <CAF71dvG5jBaWpM0=1af4HkB3CmEYhd8FZ0eOaqyFAUQgPBF3vw@mail.gmail.com>
References: <CAF71dvG5jBaWpM0=1af4HkB3CmEYhd8FZ0eOaqyFAUQgPBF3vw@mail.gmail.com>
Message-ID: <CAJgngAfC3VaEv_WpXWXoXZD=B-QVw1RTUxe0Zh-mpQBx8=1tvQ@mail.gmail.com>

Not sure if it's an option to remove all inline scripts/styles. Maybe it is.

With regards to the other options. SHA hash seems rather brittle and hard
to maintain, so a nonce would probably be the better option. I haven't
looked to much at the details on how that's handled, but I assume it's a
per-request so you can easily generate one in
FreeMarkerLoginProvider/AccountProvider, add it to the header, then
templates can themselves add the nonce using something like
none="${cspNonce}".

Seems like an elegant solution to something we're working on at the moment.
Currently most fields are escaped so it's not possible to for example
inject scripts, but there are some that are not as they need to output HTML
tags (realm display name for instance). We've ended up with using OWASP
HTML sanitizer library to escape unsafe elements. It's a bit messy code +
we need to productize the OWASP library. It sounds like this could remove
the need to do that altogether.

On Wed, 20 Jun 2018 at 00:30, Johannes Knutsen <johannes at kodet.no> wrote:

> Hi,
>
> I am currently looking at improvements in the Content Security Policy
> (CSP) support.
>
> In our deployment, we have security requirements stating that a CSP
> header should be used and inline scripts, styles and resources should
> be blocked. For example by setting a CSP value like default-src
> 'self';.
>
> Such a policy breaks Keycloak's manipulation of the browser history
> implemented in the BrowserHistoryHelper, since the
> JavascriptHistoryReplace injects an inline JavaScript.
>
> The simplest workaround is to also inject a nonce value or SHA hash of
> the script to the existing CSP header.
>
> However, while implementing this, I found that a CSP nonce in general
> would be nice to have available in any template context. This will
> also make it easier to migrate the default Keycloak theme to support
> stricter security policies.
>
> An example implementation can be found here:
>
> https://github.com/knutz3n/keycloak/commit/c6cfb3efa2942d7569066c0e4bd90a2ed75a0005
>
> Would you be interested in merging a change like the one above? If
> not, what is your view on how to allow stricter content security
> policies?
> Tests and documentation is currently missing, but I will add both if
> this is something you would consider merging.
>
> As a note, I have also done some work on supporting a strict CSP value
> for the default theme. But there are some issues with included 3rd
> party scripts which must/should be resolved. Let me know if you want
> more details regarding this.
>
> Best regards,
> Johannes Knutsen
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From johannes at kodet.no  Mon Jul 30 14:19:37 2018
From: johannes at kodet.no (Johannes Knutsen)
Date: Mon, 30 Jul 2018 20:19:37 +0200
Subject: [keycloak-dev] Improved CSP support
In-Reply-To: <CAJgngAfC3VaEv_WpXWXoXZD=B-QVw1RTUxe0Zh-mpQBx8=1tvQ@mail.gmail.com>
References: <CAF71dvG5jBaWpM0=1af4HkB3CmEYhd8FZ0eOaqyFAUQgPBF3vw@mail.gmail.com>
	<CAJgngAfC3VaEv_WpXWXoXZD=B-QVw1RTUxe0Zh-mpQBx8=1tvQ@mail.gmail.com>
Message-ID: <CAF71dvHKEXiJVD8Gba1JR4FoFhSDqhoGoohuoPMeo6pBHQ_Djw@mail.gmail.com>

Actually, your suggestion to inject a cspNonce value through the
FreeMarkerLoginProvder/AccountProvider is the exact solution I chose
to implement in the example implementation,
https://github.com/keycloak/keycloak/compare/master...knutz3n:feature/support-stricter-csp-headers.

CSP support in the admin GUI, seems to be a hard problem. I did some
work to get this working and most issues were resolveable. However,
the ACE editor has an open issue,
https://github.com/ajaxorg/ace/issues/3260, regarding CSP and there
was also a minor change required to ng-file-upload.

Our first priority is anyways to be able to disable inline scripts on
our customer's authentication realm and currently we get a CSP error
when setting a script-src 'self' rule:
"Refused to execute inline script because it violates the following
Content Security Policy directive: "script-src 'self'". Either the
'unsafe-inline' keyword, a hash ('sha256-h/...'), or a nonce
('nonce-...') is required to enable inline execution."
This is due to the inline script injected by BrowserHistoryHelper.java
and adding a CSP nonce solves this.

I don't think CSP should replace using a sanitizer, since CSP support
is varying between browsers. However, if you would consider merging
the addition of adding a CSP nonce value to the Freemarker context as
shown in the diff above, I would be happy to add some tests. At least
it would allow template developers to also use inline scripts, by
using the CSP nonce value as you mentioned.

- Johannes

On Mon, Jul 30, 2018 at 7:48 PM, Stian Thorgersen <sthorger at redhat.com> wrote:
> Not sure if it's an option to remove all inline scripts/styles. Maybe it is.
>
> With regards to the other options. SHA hash seems rather brittle and hard to
> maintain, so a nonce would probably be the better option. I haven't looked
> to much at the details on how that's handled, but I assume it's a
> per-request so you can easily generate one in
> FreeMarkerLoginProvider/AccountProvider, add it to the header, then
> templates can themselves add the nonce using something like
> none="${cspNonce}".
>
> Seems like an elegant solution to something we're working on at the moment.
> Currently most fields are escaped so it's not possible to for example inject
> scripts, but there are some that are not as they need to output HTML tags
> (realm display name for instance). We've ended up with using OWASP HTML
> sanitizer library to escape unsafe elements. It's a bit messy code + we need
> to productize the OWASP library. It sounds like this could remove the need
> to do that altogether.
>
> On Wed, 20 Jun 2018 at 00:30, Johannes Knutsen <johannes at kodet.no> wrote:
>>
>> Hi,
>>
>> I am currently looking at improvements in the Content Security Policy
>> (CSP) support.
>>
>> In our deployment, we have security requirements stating that a CSP
>> header should be used and inline scripts, styles and resources should
>> be blocked. For example by setting a CSP value like default-src
>> 'self';.
>>
>> Such a policy breaks Keycloak's manipulation of the browser history
>> implemented in the BrowserHistoryHelper, since the
>> JavascriptHistoryReplace injects an inline JavaScript.
>>
>> The simplest workaround is to also inject a nonce value or SHA hash of
>> the script to the existing CSP header.
>>
>> However, while implementing this, I found that a CSP nonce in general
>> would be nice to have available in any template context. This will
>> also make it easier to migrate the default Keycloak theme to support
>> stricter security policies.
>>
>> An example implementation can be found here:
>>
>> https://github.com/knutz3n/keycloak/commit/c6cfb3efa2942d7569066c0e4bd90a2ed75a0005
>>
>> Would you be interested in merging a change like the one above? If
>> not, what is your view on how to allow stricter content security
>> policies?
>> Tests and documentation is currently missing, but I will add both if
>> this is something you would consider merging.
>>
>> As a note, I have also done some work on supporting a strict CSP value
>> for the default theme. But there are some issues with included 3rd
>> party scripts which must/should be resolved. Let me know if you want
>> more details regarding this.
>>
>> Best regards,
>> Johannes Knutsen
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From ddtxra at gmail.com  Mon Jul 30 16:38:09 2018
From: ddtxra at gmail.com (Daniel Teixeira)
Date: Mon, 30 Jul 2018 22:38:09 +0200
Subject: [keycloak-dev] SAML users should not be identified by
	SAML:NameID
In-Reply-To: <0f8f7546e973a5fec7983a67f5ed2d944d7ea337.camel@redhat.com>
References: <CAHvCgvwsURtAuWMhcPi0EKBczgj4KzctmjJYgTEtEqxQw=3GKA@mail.gmail.com>
	<CAMvXD=HrB3Sao+crY83MDsdw_zUjDKrrnbrRcMwBKuVp8MwLpg@mail.gmail.com>
	<0f8f7546e973a5fec7983a67f5ed2d944d7ea337.camel@redhat.com>
Message-ID: <CAHvCgvxq++2MUz2fg2y9zqjPZx8ypdfbLCMhpsOUK9LUFvrR+g@mail.gmail.com>

Thank you for your positive feedback, issue created here:
https://issues.jboss.org/browse/KEYCLOAK-7969


On Mon, Jul 30, 2018 at 5:43 PM, Josh Cain <jcain at redhat.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> +1 for this, we're going to need it.
>
> On Mon, 2018-07-30 at 17:06 +0200, Hynek Mlnarik wrote:
> > Yes, please file a feature request JIRA
> >
> > On Mon, Jul 30, 2018 at 3:33 PM Daniel Teixeira <ddtxra at gmail.com>
> > wrote:
> >
> > > Hello,
> > >
> > > Seems like Keycloak always uses the saml:NameID to identify a SAML
> > > user.
> > > In org.keycloak.broker.saml.SAMLEndpoint we see:
> > >
> > > BrokeredIdentityContext identity = new
> > > BrokeredIdentityContext(subjectNameID.getValue());
> > > ...
> > > identity.setUsername(subjectNameID.getValue());
> > >
> > > However this is not a good practice, see recommendations here:
> > > https://kantarainitiative.github.io/SAMLprofiles/saml2int.html
> > >
> > > *SPs MUST NOT require the presence of a <saml:NameID> element and
> > > MUST NOT
> > > rely on the content of this element for long term identification of
> > > subjects; <saml:Attribute> elements MUST be used for this purpose
> > > in
> > > the *manner
> > > detailed below.
> > >
> > > IMO, Keycloak should provide a field when configuring an iDP to
> > > choose the
> > > custom attribute to "identify" a user. This can be mail attribute
> > > for
> > > example (urn:oid:0.9.2342.19200300.100.1.3). But should not take
> > > this
> > > information from saml:NameID
> > >
> > > Is there anyway to override this in Keycloak?
> > > Should I create a JIRA issue?
> > >
> > > Best regards,
> > > Daniel Teixeira
> > > _______________________________________________
> > > 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
> -----BEGIN PGP SIGNATURE-----
>
> iQIzBAEBCAAdFiEEyXW6Vl+0L9r9LpVurGNtyYPQwPgFAltfMhsACgkQrGNtyYPQ
> wPgjvA//VEuBittUNwRDJlr0DTsRmHvMxNZiIh8NQaiz02aLd6Q0H1Su7z4Cpx8q
> eqNSRYue1r0hWRg/fOxsibWtK2q875iy2J+bT4RaBJyTo/v8vlV39G8kEZcYsjY9
> sDcHX/8r/5YnFNdWJt6P5thHyMzIeX5/WLss9XJd9+StG8d9qCc+7a8OZgEv09GO
> TU9en30ESK6AiBd6LZlXRe2P63l1z35kAtmq2b+fDsc43db+vlcYcdNIbUBa24oc
> He1foH+0KAM6iqPV0CYsB8pBt/EhELuCU7qAUO2qIVXmYGWNMGS083r/WcaO8/+X
> r2FYNKF7IRT11km453jOyWUwlYMEA1rVKDb/kQMkakohk798wixdnYm0sSm1BPhQ
> hnhmWB9jJ/3RTTOj4+o/A9oeftQeVRm2Pv407X5bS6eFTa4dFpvqxSu1dk6GK/Aa
> 4V6VW64Rs7UiZaRXzJmzQyCvmtdyHdT5hbKlyU+ksEw20RV2agECJhuXxjXLG1hQ
> KLkpRCYa6jNT76rRNvxpZVqkyRBGMB1myPe6v8hLe6R5mxwTIoW049mFnREXVNFp
> cWgzAnwSSlNH3wrL+SVNEzb+jBi1fno2i4t29r8uvOPD52aCh7EvybitIvDIFC7S
> eXzY11neuk4ry9j4VKb2vHadIXXnoUFii3CwBhKf/JVKToy2P2o=
> =I7Oy
> -----END PGP SIGNATURE-----
>
>


-- 
Daniel Teixeira

From sthorger at redhat.com  Mon Jul 30 16:56:01 2018
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 30 Jul 2018 22:56:01 +0200
Subject: [keycloak-dev] Keycloak URL and backchannel requests
In-Reply-To: <CAJgngAcavpvA9pmREHg2GnNinmytp9=YrwRptcxr=4OpC6g1hg@mail.gmail.com>
References: <CAJgngAe4Kx12VS+7iSqwCSsEt9HTs76wSv2jNZsrFCuW05Q-nw@mail.gmail.com>
	<CAA9R9O5Spy5aVC0wV6ujKvkfpu0RPsLe7uvL8RzLXW9KG9fJzA@mail.gmail.com>
	<CAJgngAcavpvA9pmREHg2GnNinmytp9=YrwRptcxr=4OpC6g1hg@mail.gmail.com>
Message-ID: <CAJgngAdXA87DqoBbyg6cSooFEHwzTyayiMizRzSt=xMr2h71jg@mail.gmail.com>

I've got a working prototype now. If anyone wants to take a look and review
that would be great. It's mainly missing tests at the moment.

https://github.com/stianst/keycloak/tree/KEYCLOAK-7967

Some implementation details:

* There's two providers: request (current Keycloak behaviour) and fixed
* When 'fixed' provider is selected the admin console will let you set a
hostname for a realm
* 'fixed' provider by default uses http and https port -1. This will result
in no ports in the URLs. If for some reason you need to set different than
default http/https ports for public URLs then you can set the
httpPort/httpsPort properties on the fixed provider (this can't be
overridden per realm)

Now I need to figure out how to test it, which is going to be a bit tricky
as we don't have support to restart the server from the tests at the moment.


On Mon, 30 Jul 2018 at 13:51, Stian Thorgersen <sthorger at redhat.com> wrote:

>
>
> On Mon, 30 Jul 2018 at 13:28, Sebastian Laskawiec <slaskawi at redhat.com>
> wrote:
>
>>
>>
>> On Mon, Jul 30, 2018 at 1:05 PM Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>>
>>> Keycloak needs to know its public URL for a number of reasons. For
>>> example
>>> in the OIDC well-known endpoint, issuer in tokens and emails sent to
>>> users.
>>>
>>> At the moment we retrieve this from the request headers and have
>>> documented
>>> how to block requests with invalid URLs (
>>> https://www.keycloak.org/docs/latest/server_admin/index.html#host). The
>>> latter is important in production installations.
>>>
>>> There's two problems with the current approach:
>>>
>>> 1) Clients in the same subnet can't use internal IP to communicate with
>>> Keycloak
>>> 2) Configuring the valid URLs is an important step to secure a production
>>> installation, but the current approach is probably not well known and is
>>> rather messy to configure
>>
>>
>>> I propose we introduce an BaseURL SPI to allow a flexible way to
>>> determine
>>> the base URL. We would add two implementations OOTB:
>>>
>>> 1) Request - this would be set as the default-provider and would
>>> determine
>>> the base url from request headers as we do today
>>> 2) Fixed - this would allow setting a hardcoded public URL
>>>
>>
>> How about adding a third option - "None". This would mean the Keycloak
>> operates without a fixed public IP (the implementation could probably call
>> back into "localhost:8080/auth" using a "Fixed" implementation). However,
>> with "None" we would be explicitly saying that there's no public IP and all
>> requests need to be local (e.g. from the same machine or Pod (sidecar
>> approach)).
>>
>
> Keycloak has to know what URL users should be accessing it on. That can be
> an internal URL or external URL, but Keycloak needs to know the actual URL.
> There's really no such thing as a Keycloak server only reached internally.
> Users needs to be able to login, they need links in password recovery
> emails, etc, etc.
>
>
>>
>>
>>>
>>> In standalone.xml it would look like this:
>>>
>>> <spi name="baseURL">
>>>     <default-provider>request</default-provider>
>>>     <provider name="fixed">
>>>        <properties>
>>>          <property name="baseURL" value="localhost:8080/auth"/>
>>>        </properties>
>>>    </provider>
>>> </spi>
>>>
>>> For production the default-provider should be changed to fixed and the
>>> baseURL value should be changed. This can be handled either through
>>> manual
>>> editing standalone.xml or with jboss-cli.
>>>
>>
>> How about using the "None" as the default here?
>>
>>
>>>
>>> Once this is incorporated it will make it easy to add support for
>>> backchannel URL back to the adapters to allow adapters to use internal IP
>>> address when communicating with Keycloak.
>>>
>>> Implementation shouldn't be hard. It's mainly about making sure that
>>> UriInfo is retrieved from KeycloakSession#KeycloakContext and not
>>> injected
>>> directly.
>>>
>>> If anyone has more complex requirements for determining the public URL
>>> they
>>> can implement their own provider to handle it.
>>>
>>> One thing I'm not sure about is if it's common to use different URLs for
>>> different realms. If that's the case we may consider adding some support
>>> for mapping different realms to different baseURLs. I don't think this is
>>> common though.
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>

From bruno at abstractj.org  Mon Jul 30 17:55:25 2018
From: bruno at abstractj.org (Bruno Oliveira)
Date: Mon, 30 Jul 2018 18:55:25 -0300
Subject: [keycloak-dev] Migration status of Keycloak generic adapter
	dependencies
Message-ID: <20180730215525.GA14659@abstractj.org>

Good night,

I've been working on the migration of the dependencies inside keycloak-proxy
(to be renamed to keycloak-generic-adapter) from Rohith's fork to its
respective upstream dependencies. 

While doing the migration I found a blocker that's holding us from
move the codebase to Keycloak organization. This piece of code: 
https://github.com/gambol99/keycloak-proxy/blob/master/server.go#L645-L719.
We could continue to pursue this, but that would gonna take more time.
Or we can just, move to go-oidc upstream v1 which can be fast and simple 
and later we consider v2. 

I believe that SkipClientIDCheck made a lot of sense when we had this 
idea of having a proxy for Keycloak. But now things had changed and 
we agreed that we do not aim to provide all proxy features, which 
includes SkipClientIDCheck.

This does not mean that in the future we're not going to revisit this.
But we have to move forward and having working code can be better than
perfection.

Just in case you have interest on this,here's the PR which the changes
I mentioned: https://github.com/gambol99/keycloak-proxy/pull/407

Thoughts?



-- 

abstractj

From dt at acutus.pro  Mon Jul 30 23:43:14 2018
From: dt at acutus.pro (Dmitry Telegin)
Date: Tue, 31 Jul 2018 06:43:14 +0300
Subject: [keycloak-dev] [keycloak-user] Sharing default configuration
 for keycloak deployment
In-Reply-To: <CANAVTmMZzVYW7g2KUtwG9oBS48M9Vgo-CQTPpx4m6_dL6w9e4Q@mail.gmail.com>
References: <CANAVTmMZzVYW7g2KUtwG9oBS48M9Vgo-CQTPpx4m6_dL6w9e4Q@mail.gmail.com>
Message-ID: <1533008594.5207.26.camel@acutus.pro>

Hi,

Is it correct that you're shipping vanilla Keycloak distro with your application, and you want to apply configuration changes as easy as possible?

You should be considering the following tools:
$KEYCLOAK/bin/add-user-keycloak.sh (to add admin user)
$KEYCLOAK/bin/kcadm.sh (to create realms and virtually everything else in Keycloak; remember you'll need to spin it up first)
$KEYCLOAK/bin/jboss-cli.sh (to install JDBC driver, configure database etc.)

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

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

On Wed, 2018-07-25 at 12:17 +0530, Test Oauth wrote:
> I am shipping Keycloak with my application and there is some default
> configuration that I have done. I want to ship this default configuration
> (like admin name/password, realm names etc) with my application so that the
> customers can bring the basic authentication flow up with a single click
> (of probably a batch file).
> 
> Is there a way to do this?
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user

From johannes at kodet.no  Tue Jul 31 04:59:48 2018
From: johannes at kodet.no (Johannes Knutsen)
Date: Tue, 31 Jul 2018 10:59:48 +0200
Subject: [keycloak-dev] Keycloak URL and backchannel requests
In-Reply-To: <CAJgngAdXA87DqoBbyg6cSooFEHwzTyayiMizRzSt=xMr2h71jg@mail.gmail.com>
References: <CAJgngAe4Kx12VS+7iSqwCSsEt9HTs76wSv2jNZsrFCuW05Q-nw@mail.gmail.com>
	<CAA9R9O5Spy5aVC0wV6ujKvkfpu0RPsLe7uvL8RzLXW9KG9fJzA@mail.gmail.com>
	<CAJgngAcavpvA9pmREHg2GnNinmytp9=YrwRptcxr=4OpC6g1hg@mail.gmail.com>
	<CAJgngAdXA87DqoBbyg6cSooFEHwzTyayiMizRzSt=xMr2h71jg@mail.gmail.com>
Message-ID: <CAF71dvEaUKv_QZ3pjAUVPB6MFDccMoF3Wfc_3pr9VJApaKZUAw@mail.gmail.com>

Just tested this branch. This seems like a good change.
However, I have an issue when creating an Initial Access Token in a
realm configured with a fixed hostname different from the hostname
used when accessing the admin console. The resulting initial access
token gets the request hostname as issuer and not the fixed hostname
configured for the realm. I expected the issuer to have the same
hostname as the fixed realm configuration.

- Johannes

On Mon, Jul 30, 2018 at 10:56 PM, Stian Thorgersen <sthorger at redhat.com> wrote:
> I've got a working prototype now. If anyone wants to take a look and review
> that would be great. It's mainly missing tests at the moment.
>
> https://github.com/stianst/keycloak/tree/KEYCLOAK-7967
>
> Some implementation details:
>
> * There's two providers: request (current Keycloak behaviour) and fixed
> * When 'fixed' provider is selected the admin console will let you set a
> hostname for a realm
> * 'fixed' provider by default uses http and https port -1. This will result
> in no ports in the URLs. If for some reason you need to set different than
> default http/https ports for public URLs then you can set the
> httpPort/httpsPort properties on the fixed provider (this can't be
> overridden per realm)
>
> Now I need to figure out how to test it, which is going to be a bit tricky
> as we don't have support to restart the server from the tests at the moment.
>
>
> On Mon, 30 Jul 2018 at 13:51, Stian Thorgersen <sthorger at redhat.com> wrote:
>
>>
>>
>> On Mon, 30 Jul 2018 at 13:28, Sebastian Laskawiec <slaskawi at redhat.com>
>> wrote:
>>
>>>
>>>
>>> On Mon, Jul 30, 2018 at 1:05 PM Stian Thorgersen <sthorger at redhat.com>
>>> wrote:
>>>
>>>> Keycloak needs to know its public URL for a number of reasons. For
>>>> example
>>>> in the OIDC well-known endpoint, issuer in tokens and emails sent to
>>>> users.
>>>>
>>>> At the moment we retrieve this from the request headers and have
>>>> documented
>>>> how to block requests with invalid URLs (
>>>> https://www.keycloak.org/docs/latest/server_admin/index.html#host). The
>>>> latter is important in production installations.
>>>>
>>>> There's two problems with the current approach:
>>>>
>>>> 1) Clients in the same subnet can't use internal IP to communicate with
>>>> Keycloak
>>>> 2) Configuring the valid URLs is an important step to secure a production
>>>> installation, but the current approach is probably not well known and is
>>>> rather messy to configure
>>>
>>>
>>>> I propose we introduce an BaseURL SPI to allow a flexible way to
>>>> determine
>>>> the base URL. We would add two implementations OOTB:
>>>>
>>>> 1) Request - this would be set as the default-provider and would
>>>> determine
>>>> the base url from request headers as we do today
>>>> 2) Fixed - this would allow setting a hardcoded public URL
>>>>
>>>
>>> How about adding a third option - "None". This would mean the Keycloak
>>> operates without a fixed public IP (the implementation could probably call
>>> back into "localhost:8080/auth" using a "Fixed" implementation). However,
>>> with "None" we would be explicitly saying that there's no public IP and all
>>> requests need to be local (e.g. from the same machine or Pod (sidecar
>>> approach)).
>>>
>>
>> Keycloak has to know what URL users should be accessing it on. That can be
>> an internal URL or external URL, but Keycloak needs to know the actual URL.
>> There's really no such thing as a Keycloak server only reached internally.
>> Users needs to be able to login, they need links in password recovery
>> emails, etc, etc.
>>
>>
>>>
>>>
>>>>
>>>> In standalone.xml it would look like this:
>>>>
>>>> <spi name="baseURL">
>>>>     <default-provider>request</default-provider>
>>>>     <provider name="fixed">
>>>>        <properties>
>>>>          <property name="baseURL" value="localhost:8080/auth"/>
>>>>        </properties>
>>>>    </provider>
>>>> </spi>
>>>>
>>>> For production the default-provider should be changed to fixed and the
>>>> baseURL value should be changed. This can be handled either through
>>>> manual
>>>> editing standalone.xml or with jboss-cli.
>>>>
>>>
>>> How about using the "None" as the default here?
>>>
>>>
>>>>
>>>> Once this is incorporated it will make it easy to add support for
>>>> backchannel URL back to the adapters to allow adapters to use internal IP
>>>> address when communicating with Keycloak.
>>>>
>>>> Implementation shouldn't be hard. It's mainly about making sure that
>>>> UriInfo is retrieved from KeycloakSession#KeycloakContext and not
>>>> injected
>>>> directly.
>>>>
>>>> If anyone has more complex requirements for determining the public URL
>>>> they
>>>> can implement their own provider to handle it.
>>>>
>>>> One thing I'm not sure about is if it's common to use different URLs for
>>>> different realms. If that's the case we may consider adding some support
>>>> for mapping different realms to different baseURLs. I don't think this is
>>>> common though.
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From sthorger at redhat.com  Tue Jul 31 06:08:35 2018
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 31 Jul 2018 12:08:35 +0200
Subject: [keycloak-dev] Keycloak URL and backchannel requests
In-Reply-To: <CAF71dvEaUKv_QZ3pjAUVPB6MFDccMoF3Wfc_3pr9VJApaKZUAw@mail.gmail.com>
References: <CAJgngAe4Kx12VS+7iSqwCSsEt9HTs76wSv2jNZsrFCuW05Q-nw@mail.gmail.com>
	<CAA9R9O5Spy5aVC0wV6ujKvkfpu0RPsLe7uvL8RzLXW9KG9fJzA@mail.gmail.com>
	<CAJgngAcavpvA9pmREHg2GnNinmytp9=YrwRptcxr=4OpC6g1hg@mail.gmail.com>
	<CAJgngAdXA87DqoBbyg6cSooFEHwzTyayiMizRzSt=xMr2h71jg@mail.gmail.com>
	<CAF71dvEaUKv_QZ3pjAUVPB6MFDccMoF3Wfc_3pr9VJApaKZUAw@mail.gmail.com>
Message-ID: <CAJgngAewh+UDO7CLKmRnfmaJ4Nrn4A4MFjP_q1ZatKVsvyTUaA@mail.gmail.com>

I assume you're creating the initial access token when logged-in to the
master realm right? Will add a testcase for that specifically and fix it.
Probably just need to change the realm in the KeycloakContext when creating
the token.

On Tue, 31 Jul 2018 at 10:59, Johannes Knutsen <johannes at kodet.no> wrote:

> Just tested this branch. This seems like a good change.
> However, I have an issue when creating an Initial Access Token in a
> realm configured with a fixed hostname different from the hostname
> used when accessing the admin console. The resulting initial access
> token gets the request hostname as issuer and not the fixed hostname
> configured for the realm. I expected the issuer to have the same
> hostname as the fixed realm configuration.
>
> - Johannes
>
> On Mon, Jul 30, 2018 at 10:56 PM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
> > I've got a working prototype now. If anyone wants to take a look and
> review
> > that would be great. It's mainly missing tests at the moment.
> >
> > https://github.com/stianst/keycloak/tree/KEYCLOAK-7967
> >
> > Some implementation details:
> >
> > * There's two providers: request (current Keycloak behaviour) and fixed
> > * When 'fixed' provider is selected the admin console will let you set a
> > hostname for a realm
> > * 'fixed' provider by default uses http and https port -1. This will
> result
> > in no ports in the URLs. If for some reason you need to set different
> than
> > default http/https ports for public URLs then you can set the
> > httpPort/httpsPort properties on the fixed provider (this can't be
> > overridden per realm)
> >
> > Now I need to figure out how to test it, which is going to be a bit
> tricky
> > as we don't have support to restart the server from the tests at the
> moment.
> >
> >
> > On Mon, 30 Jul 2018 at 13:51, Stian Thorgersen <sthorger at redhat.com>
> wrote:
> >
> >>
> >>
> >> On Mon, 30 Jul 2018 at 13:28, Sebastian Laskawiec <slaskawi at redhat.com>
> >> wrote:
> >>
> >>>
> >>>
> >>> On Mon, Jul 30, 2018 at 1:05 PM Stian Thorgersen <sthorger at redhat.com>
> >>> wrote:
> >>>
> >>>> Keycloak needs to know its public URL for a number of reasons. For
> >>>> example
> >>>> in the OIDC well-known endpoint, issuer in tokens and emails sent to
> >>>> users.
> >>>>
> >>>> At the moment we retrieve this from the request headers and have
> >>>> documented
> >>>> how to block requests with invalid URLs (
> >>>> https://www.keycloak.org/docs/latest/server_admin/index.html#host).
> The
> >>>> latter is important in production installations.
> >>>>
> >>>> There's two problems with the current approach:
> >>>>
> >>>> 1) Clients in the same subnet can't use internal IP to communicate
> with
> >>>> Keycloak
> >>>> 2) Configuring the valid URLs is an important step to secure a
> production
> >>>> installation, but the current approach is probably not well known and
> is
> >>>> rather messy to configure
> >>>
> >>>
> >>>> I propose we introduce an BaseURL SPI to allow a flexible way to
> >>>> determine
> >>>> the base URL. We would add two implementations OOTB:
> >>>>
> >>>> 1) Request - this would be set as the default-provider and would
> >>>> determine
> >>>> the base url from request headers as we do today
> >>>> 2) Fixed - this would allow setting a hardcoded public URL
> >>>>
> >>>
> >>> How about adding a third option - "None". This would mean the Keycloak
> >>> operates without a fixed public IP (the implementation could probably
> call
> >>> back into "localhost:8080/auth" using a "Fixed" implementation).
> However,
> >>> with "None" we would be explicitly saying that there's no public IP
> and all
> >>> requests need to be local (e.g. from the same machine or Pod (sidecar
> >>> approach)).
> >>>
> >>
> >> Keycloak has to know what URL users should be accessing it on. That can
> be
> >> an internal URL or external URL, but Keycloak needs to know the actual
> URL.
> >> There's really no such thing as a Keycloak server only reached
> internally.
> >> Users needs to be able to login, they need links in password recovery
> >> emails, etc, etc.
> >>
> >>
> >>>
> >>>
> >>>>
> >>>> In standalone.xml it would look like this:
> >>>>
> >>>> <spi name="baseURL">
> >>>>     <default-provider>request</default-provider>
> >>>>     <provider name="fixed">
> >>>>        <properties>
> >>>>          <property name="baseURL" value="localhost:8080/auth"/>
> >>>>        </properties>
> >>>>    </provider>
> >>>> </spi>
> >>>>
> >>>> For production the default-provider should be changed to fixed and the
> >>>> baseURL value should be changed. This can be handled either through
> >>>> manual
> >>>> editing standalone.xml or with jboss-cli.
> >>>>
> >>>
> >>> How about using the "None" as the default here?
> >>>
> >>>
> >>>>
> >>>> Once this is incorporated it will make it easy to add support for
> >>>> backchannel URL back to the adapters to allow adapters to use
> internal IP
> >>>> address when communicating with Keycloak.
> >>>>
> >>>> Implementation shouldn't be hard. It's mainly about making sure that
> >>>> UriInfo is retrieved from KeycloakSession#KeycloakContext and not
> >>>> injected
> >>>> directly.
> >>>>
> >>>> If anyone has more complex requirements for determining the public URL
> >>>> they
> >>>> can implement their own provider to handle it.
> >>>>
> >>>> One thing I'm not sure about is if it's common to use different URLs
> for
> >>>> different realms. If that's the case we may consider adding some
> support
> >>>> for mapping different realms to different baseURLs. I don't think
> this is
> >>>> common though.
> >>>> _______________________________________________
> >>>> 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 johannes at kodet.no  Tue Jul 31 06:26:27 2018
From: johannes at kodet.no (Johannes Knutsen)
Date: Tue, 31 Jul 2018 12:26:27 +0200
Subject: [keycloak-dev] Keycloak URL and backchannel requests
In-Reply-To: <CAJgngAewh+UDO7CLKmRnfmaJ4Nrn4A4MFjP_q1ZatKVsvyTUaA@mail.gmail.com>
References: <CAJgngAe4Kx12VS+7iSqwCSsEt9HTs76wSv2jNZsrFCuW05Q-nw@mail.gmail.com>
	<CAA9R9O5Spy5aVC0wV6ujKvkfpu0RPsLe7uvL8RzLXW9KG9fJzA@mail.gmail.com>
	<CAJgngAcavpvA9pmREHg2GnNinmytp9=YrwRptcxr=4OpC6g1hg@mail.gmail.com>
	<CAJgngAdXA87DqoBbyg6cSooFEHwzTyayiMizRzSt=xMr2h71jg@mail.gmail.com>
	<CAF71dvEaUKv_QZ3pjAUVPB6MFDccMoF3Wfc_3pr9VJApaKZUAw@mail.gmail.com>
	<CAJgngAewh+UDO7CLKmRnfmaJ4Nrn4A4MFjP_q1ZatKVsvyTUaA@mail.gmail.com>
Message-ID: <CAF71dvGhC4z+LOCj8kdFTgwYNHnAYUnweo0VNp7wp8UZ6UrT9A@mail.gmail.com>

Yes, I was logged-in to the master realm when testing this.

On Tue, Jul 31, 2018 at 12:08 PM, Stian Thorgersen <sthorger at redhat.com> wrote:
> I assume you're creating the initial access token when logged-in to the
> master realm right? Will add a testcase for that specifically and fix it.
> Probably just need to change the realm in the KeycloakContext when creating
> the token.
>
> On Tue, 31 Jul 2018 at 10:59, Johannes Knutsen <johannes at kodet.no> wrote:
>>
>> Just tested this branch. This seems like a good change.
>> However, I have an issue when creating an Initial Access Token in a
>> realm configured with a fixed hostname different from the hostname
>> used when accessing the admin console. The resulting initial access
>> token gets the request hostname as issuer and not the fixed hostname
>> configured for the realm. I expected the issuer to have the same
>> hostname as the fixed realm configuration.
>>
>> - Johannes
>>
>> On Mon, Jul 30, 2018 at 10:56 PM, Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>> > I've got a working prototype now. If anyone wants to take a look and
>> > review
>> > that would be great. It's mainly missing tests at the moment.
>> >
>> > https://github.com/stianst/keycloak/tree/KEYCLOAK-7967
>> >
>> > Some implementation details:
>> >
>> > * There's two providers: request (current Keycloak behaviour) and fixed
>> > * When 'fixed' provider is selected the admin console will let you set a
>> > hostname for a realm
>> > * 'fixed' provider by default uses http and https port -1. This will
>> > result
>> > in no ports in the URLs. If for some reason you need to set different
>> > than
>> > default http/https ports for public URLs then you can set the
>> > httpPort/httpsPort properties on the fixed provider (this can't be
>> > overridden per realm)
>> >
>> > Now I need to figure out how to test it, which is going to be a bit
>> > tricky
>> > as we don't have support to restart the server from the tests at the
>> > moment.
>> >
>> >
>> > On Mon, 30 Jul 2018 at 13:51, Stian Thorgersen <sthorger at redhat.com>
>> > wrote:
>> >
>> >>
>> >>
>> >> On Mon, 30 Jul 2018 at 13:28, Sebastian Laskawiec <slaskawi at redhat.com>
>> >> wrote:
>> >>
>> >>>
>> >>>
>> >>> On Mon, Jul 30, 2018 at 1:05 PM Stian Thorgersen <sthorger at redhat.com>
>> >>> wrote:
>> >>>
>> >>>> Keycloak needs to know its public URL for a number of reasons. For
>> >>>> example
>> >>>> in the OIDC well-known endpoint, issuer in tokens and emails sent to
>> >>>> users.
>> >>>>
>> >>>> At the moment we retrieve this from the request headers and have
>> >>>> documented
>> >>>> how to block requests with invalid URLs (
>> >>>> https://www.keycloak.org/docs/latest/server_admin/index.html#host).
>> >>>> The
>> >>>> latter is important in production installations.
>> >>>>
>> >>>> There's two problems with the current approach:
>> >>>>
>> >>>> 1) Clients in the same subnet can't use internal IP to communicate
>> >>>> with
>> >>>> Keycloak
>> >>>> 2) Configuring the valid URLs is an important step to secure a
>> >>>> production
>> >>>> installation, but the current approach is probably not well known and
>> >>>> is
>> >>>> rather messy to configure
>> >>>
>> >>>
>> >>>> I propose we introduce an BaseURL SPI to allow a flexible way to
>> >>>> determine
>> >>>> the base URL. We would add two implementations OOTB:
>> >>>>
>> >>>> 1) Request - this would be set as the default-provider and would
>> >>>> determine
>> >>>> the base url from request headers as we do today
>> >>>> 2) Fixed - this would allow setting a hardcoded public URL
>> >>>>
>> >>>
>> >>> How about adding a third option - "None". This would mean the Keycloak
>> >>> operates without a fixed public IP (the implementation could probably
>> >>> call
>> >>> back into "localhost:8080/auth" using a "Fixed" implementation).
>> >>> However,
>> >>> with "None" we would be explicitly saying that there's no public IP
>> >>> and all
>> >>> requests need to be local (e.g. from the same machine or Pod (sidecar
>> >>> approach)).
>> >>>
>> >>
>> >> Keycloak has to know what URL users should be accessing it on. That can
>> >> be
>> >> an internal URL or external URL, but Keycloak needs to know the actual
>> >> URL.
>> >> There's really no such thing as a Keycloak server only reached
>> >> internally.
>> >> Users needs to be able to login, they need links in password recovery
>> >> emails, etc, etc.
>> >>
>> >>
>> >>>
>> >>>
>> >>>>
>> >>>> In standalone.xml it would look like this:
>> >>>>
>> >>>> <spi name="baseURL">
>> >>>>     <default-provider>request</default-provider>
>> >>>>     <provider name="fixed">
>> >>>>        <properties>
>> >>>>          <property name="baseURL" value="localhost:8080/auth"/>
>> >>>>        </properties>
>> >>>>    </provider>
>> >>>> </spi>
>> >>>>
>> >>>> For production the default-provider should be changed to fixed and
>> >>>> the
>> >>>> baseURL value should be changed. This can be handled either through
>> >>>> manual
>> >>>> editing standalone.xml or with jboss-cli.
>> >>>>
>> >>>
>> >>> How about using the "None" as the default here?
>> >>>
>> >>>
>> >>>>
>> >>>> Once this is incorporated it will make it easy to add support for
>> >>>> backchannel URL back to the adapters to allow adapters to use
>> >>>> internal IP
>> >>>> address when communicating with Keycloak.
>> >>>>
>> >>>> Implementation shouldn't be hard. It's mainly about making sure that
>> >>>> UriInfo is retrieved from KeycloakSession#KeycloakContext and not
>> >>>> injected
>> >>>> directly.
>> >>>>
>> >>>> If anyone has more complex requirements for determining the public
>> >>>> URL
>> >>>> they
>> >>>> can implement their own provider to handle it.
>> >>>>
>> >>>> One thing I'm not sure about is if it's common to use different URLs
>> >>>> for
>> >>>> different realms. If that's the case we may consider adding some
>> >>>> support
>> >>>> for mapping different realms to different baseURLs. I don't think
>> >>>> this is
>> >>>> common though.
>> >>>> _______________________________________________
>> >>>> keycloak-dev mailing list
>> >>>> keycloak-dev at lists.jboss.org
>> >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> >>>>
>> >>>
>> > _______________________________________________
>> > keycloak-dev mailing list
>> > keycloak-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev

From sthorger at redhat.com  Tue Jul 31 14:39:53 2018
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 31 Jul 2018 20:39:53 +0200
Subject: [keycloak-dev] Improved CSP support
In-Reply-To: <CAF71dvHKEXiJVD8Gba1JR4FoFhSDqhoGoohuoPMeo6pBHQ_Djw@mail.gmail.com>
References: <CAF71dvG5jBaWpM0=1af4HkB3CmEYhd8FZ0eOaqyFAUQgPBF3vw@mail.gmail.com>
	<CAJgngAfC3VaEv_WpXWXoXZD=B-QVw1RTUxe0Zh-mpQBx8=1tvQ@mail.gmail.com>
	<CAF71dvHKEXiJVD8Gba1JR4FoFhSDqhoGoohuoPMeo6pBHQ_Djw@mail.gmail.com>
Message-ID: <CAJgngAefxAqTj50SKXugCurEoi72jJWdx4vVSdGP=0dkHmPBqw@mail.gmail.com>

On Mon, 30 Jul 2018 at 20:19, Johannes Knutsen <johannes at kodet.no> wrote:

> Actually, your suggestion to inject a cspNonce value through the
> FreeMarkerLoginProvder/AccountProvider is the exact solution I chose
> to implement in the example implementation,
>
> https://github.com/keycloak/keycloak/compare/master...knutz3n:feature/support-stricter-csp-headers
> .
>

Sounds good, I'm leaving for holiday today so won't have time to take a
look at it before I'm back in a week or so.


>
> CSP support in the admin GUI, seems to be a hard problem. I did some
> work to get this working and most issues were resolveable. However,
> the ACE editor has an open issue,
> https://github.com/ajaxorg/ace/issues/3260, regarding CSP and there
> was also a minor change required to ng-file-upload.
>

Is it only the ACE editor that is an issue? If that remains an issue we
could consider removing it. It's only used when editing js authenticators
and policies, but I don't think it's all that useful afaik.


>
> Our first priority is anyways to be able to disable inline scripts on
> our customer's authentication realm and currently we get a CSP error
> when setting a script-src 'self' rule:
> "Refused to execute inline script because it violates the following
> Content Security Policy directive: "script-src 'self'". Either the
> 'unsafe-inline' keyword, a hash ('sha256-h/...'), or a nonce
> ('nonce-...') is required to enable inline execution."
> This is due to the inline script injected by BrowserHistoryHelper.java
> and adding a CSP nonce solves this.
>

Do you generate the nonce on demand in your branch? As it's only needed for
very few requests we should generate one in the FreeMarker providers unless
it's actually needed.


>
> I don't think CSP should replace using a sanitizer, since CSP support
> is varying between browsers. However, if you would consider merging
> the addition of adding a CSP nonce value to the Freemarker context as
> shown in the diff above, I would be happy to add some tests. At least
> it would allow template developers to also use inline scripts, by
> using the CSP nonce value as you mentioned.
>

We'll keep the sanitizer as well. Always good to have more layers of
defence than less ;)

Would be ideal to have a complete solution. Nonce available, updated
default value for CSP header for realms, including migrating existing
realms when the value hasn't changed.


>
> - Johannes
>
> On Mon, Jul 30, 2018 at 7:48 PM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
> > Not sure if it's an option to remove all inline scripts/styles. Maybe it
> is.
> >
> > With regards to the other options. SHA hash seems rather brittle and
> hard to
> > maintain, so a nonce would probably be the better option. I haven't
> looked
> > to much at the details on how that's handled, but I assume it's a
> > per-request so you can easily generate one in
> > FreeMarkerLoginProvider/AccountProvider, add it to the header, then
> > templates can themselves add the nonce using something like
> > none="${cspNonce}".
> >
> > Seems like an elegant solution to something we're working on at the
> moment.
> > Currently most fields are escaped so it's not possible to for example
> inject
> > scripts, but there are some that are not as they need to output HTML tags
> > (realm display name for instance). We've ended up with using OWASP HTML
> > sanitizer library to escape unsafe elements. It's a bit messy code + we
> need
> > to productize the OWASP library. It sounds like this could remove the
> need
> > to do that altogether.
> >
> > On Wed, 20 Jun 2018 at 00:30, Johannes Knutsen <johannes at kodet.no>
> wrote:
> >>
> >> Hi,
> >>
> >> I am currently looking at improvements in the Content Security Policy
> >> (CSP) support.
> >>
> >> In our deployment, we have security requirements stating that a CSP
> >> header should be used and inline scripts, styles and resources should
> >> be blocked. For example by setting a CSP value like default-src
> >> 'self';.
> >>
> >> Such a policy breaks Keycloak's manipulation of the browser history
> >> implemented in the BrowserHistoryHelper, since the
> >> JavascriptHistoryReplace injects an inline JavaScript.
> >>
> >> The simplest workaround is to also inject a nonce value or SHA hash of
> >> the script to the existing CSP header.
> >>
> >> However, while implementing this, I found that a CSP nonce in general
> >> would be nice to have available in any template context. This will
> >> also make it easier to migrate the default Keycloak theme to support
> >> stricter security policies.
> >>
> >> An example implementation can be found here:
> >>
> >>
> https://github.com/knutz3n/keycloak/commit/c6cfb3efa2942d7569066c0e4bd90a2ed75a0005
> >>
> >> Would you be interested in merging a change like the one above? If
> >> not, what is your view on how to allow stricter content security
> >> policies?
> >> Tests and documentation is currently missing, but I will add both if
> >> this is something you would consider merging.
> >>
> >> As a note, I have also done some work on supporting a strict CSP value
> >> for the default theme. But there are some issues with included 3rd
> >> party scripts which must/should be resolved. Let me know if you want
> >> more details regarding this.
> >>
> >> Best regards,
> >> Johannes Knutsen
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>