Keycloak OIDC Id Token
by Jari Kuusisto
Hello there. I have a web application (war) deployed on Wildfly and it is
protected by Keycloak. I am using Java/Wildfly adapter (not "keycloak.js)",
and there is a KC client that uses Standard flow (OIDC): it is configured
to use Access Type "public". The setup works just fine. But is it possible
to retrieve and access the Id Token (JWT) from the client-side i.e.
end-user browser in this case? Or is it available on server-side as a
http-only cookie value? I planned to keep then JWT token short-lived and
use it for secondary login on another website based on the claims in it,
for example " 'login': 'allowed' " for "john.smith(a)example.com".
I also have configured protocol mappers for the client so that certain
roles should be included i.e. mapped in the Id Token, but I can not see
them there. Any ideas what could be wrong? KC version is 2.2.1.Final and WF
version is 10. Thanks!
8 years, 11 months
Detect user impersonation
by David Delbecq
Hello,
for audit reason, our application need to be able to make the difference
between "userA" and "userA impersonated by admin xyz". Is there some way
from the client point of view to make a difference between a logged in user
and an admin impersonating that user? Is it possible to add some property
in KeycloakPrincipal to detect it? And possiblity get the name of the admin
doing it?
--
<http://www.trimble.com/>
David Delbecq
Software engineer, Transport & Logistics
Geldenaaksebaan 329, 1st floor | 3001 Leuven
+32 16 391 121 <+32%2016%20391%20121> Direct
david.delbecq(a)trimbletl.com
<http://www.trimbletl.com/>
8 years, 11 months
Red Hat SSO supported version
by Haim Vana
Hi,
Currently we are using keycloak 1.9.3, could we get support for that version ? or we will have to upgrade ? if so to which version ?
Thanks,
Haim.
The information contained in this message is proprietary to the sender, protected from disclosure, and may be privileged. The information is intended to be conveyed only to the designated recipient(s) of the message. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you.
8 years, 11 months
Design question for thousands of resource servers
by Michael.E.Brown＠dell.com
I'm wrestling with a design problem that I could use some help on.
I have a console application that users will log into with OIDC. That console application manages (potentially thousands) of devices. Each device individually has a web-ui that a user can log into with OIDC.
I've pretty much finished the design for individual logins to the console and the individual devices, using Client Roles to enumerate permissions on the console and device, and creating groups that give users access to the roles on the devices they should have permissions to. I've set up a Client Role mapper that adds a "{device|console}_permissions": ["perm1", "perm2", "perm3"... ] to the ID Token. The console or device then uses the ID Token to create a session with the appropriate permissions.
The individual devices also have REST endpoints which the console will access. This is where I am running into a problem. I need a solution for the console to act as a Client and get Access Tokens for each of the individual devices.
There are three access modes where the console uses the device REST apis:
- In the context of a user that is present and logged into the console
- On behalf of a user who may or may not be presently logged in (Think scheduled tasks)
- As part of the infrastructure, outside a user context
How can I set up the solution so that the console can get Access Tokens from keycloak for each of these use cases, and how does each device verify the token? I don't think it will scale to have the initial console login Access Token contain all of the permissions for every device. Additionally, I'm worried about the effects if one device is compromised, it seems that the access token could be then used to make requests on any of the other connected servers. But I am at a loss to find another way to accomplish this.
--
Michael
8 years, 12 months
Hot deployment of service providers in Keycloak 2.5.0 final
by Matuszak, Eduard
Hello
I am trying to understand and implement the new concept of deploying service providers, but I fail at several points.
What is meant by the "Keycloak deploy/ directory" mentioned in the documentation?
When trying the user-storage-simple example it was possible to hot deploy the jar-file in wildfly's standalone/deployment-dir, but the event-listener-sysout sample fails by class-loading problem ("java.lang.NoClassDefFoundError: Failed to link org/keycloak/examples/providers/events/SysoutEventListenerProviderFactory").
So perhaps not all SPI's do provide the new deployment concept?
There is also a mismatch, I think, between the deploy-description in the Readme.md of the event-listener-sysout example (describing the "old" way to deploy) and the documentation in https://keycloak.gitbooks.io/server-developer-guide/content/topics/provid... (recommending Keycloak deployer utilizing the enigmatic "Keycloak deploy/ directory").
I was working on Kecloak 2.5.0 Final.
Thanks in advatage for some clarifications.
Eduard Matuszak
8 years, 12 months
Red Hat SSO support feedback
by Haim Vana
Hi all,
We are considering to use the Red Hat SSO support, so if you have any experience working with them we would appreciate if you could share it (you can reply to me or to the group).
Thanks,
Haim.
The information contained in this message is proprietary to the sender, protected from disclosure, and may be privileged. The information is intended to be conveyed only to the designated recipient(s) of the message. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you.
8 years, 12 months
Re: [keycloak-user] Getting the client-IP behind a reverse proxy with HTTPS
by Olivier Bruylandt
Dear,
I get an issue to get the wanted behavior when retrieving the client public
IP.
This is the situation :
(all IP's have been anonymized)
- *infrastructure level*:
----------- Reverse Proxy NGINX ----------------------------------- KeyCloak
RP is listening on ports 80 & 443 (80 is redirected to 443)
There is a public certificate signed by some external CA
Nginx redirects to the 8443 (https) of KC (HTTP runs on 8080)
Keycloak is set as standalone server on a Wildfly last version
- *Nginx config*
*server { listen 443; server_name ************;
fastcgi_param HTTPS on; location / { add_header
X-Cache-Status $upstream_cache_status; add_header X-Real-IP
$remote_addr; add_header X-Forwarded-For $remote_addr;
add_header X-Forwarded-Proto $scheme;
more_set_headers 'Server: ******'; more_clear_headers
'X-Powered-By'; charset UTF-8; proxy_cache
******_cache; proxy_pass https://1.1.1.1:8443/
<https://1.1.1.1:8443/>; }*
* ssl on; ssl_certificate /etc/ssl/private/**********.crt;
ssl_certificate_key /etc/ssl/private/*************.key;
ssl_prefer_server_ciphers on; ssl_dhparam /etc/ssl/***********.pem;
ssl_protocols TLSv1.1 TLSv1.2; ssl_stapling on;
ssl_session_cache builtin:1000 shared:SSL:10m; add_header
Strict-Transport-Security "max-age=63072000; includeSubdomains; preload";
add_header X-Frame-Options "DENY"; ssl_ciphers
'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH';*
- *Keycloak config* :
* <subsystem xmlns="urn:jboss:domain:undertow:3.0">*
* <buffer-cache name="default"/>*
* <server name="default-server">*
* <http-listener
name="default" proxy-address-forwarding="true" socket-binding="http"/>*
* <https-listener name="https" security-realm="**********"
socket-binding="https"/>*
* <host name="default-host" alias="localhost">*
* <location name="/" handler="welcome-content"/>*
* </host>*
* </server>*
* <servlet-container name="default">*
* <jsp-config/>*
* <websockets/>*
* </servlet-container>*
* <handlers>*
* <file name="welcome-content"
path="${jboss.home.dir}/welcome-content"/>*
* </handlers>*
* </subsystem>*
The situation is that everything is working fine and smooth EXCEPT ... the
fact that under sessions (and moreover for all user activities), the user
IP I see is the one of the reverse proxy !!
As I put in red in the KC config, this is what should do the trick to use
the X-Forwarded-For header value to set the client's IP.
15:07:55,104 WARN [org.keycloak.events] (default task-19)
type=REFRESH_TOKEN_ERROR, realmId=***, clientId=account, userId=null,
ipAddress=2.2.2.2, (...)
When I tried to reach KC on the 8080 (HTTP) listener (so the RP terminates
the SSL connection and the one to KC server is made in HTTP), I got
obviously a whole bunch of warnings and errors due to HTTP -> HTTPS
transport and also a HTTP connection towards the external social identity
providers like Google, FB, etc. ... BUT I got at least the real IP as you
might see hereunder :
15:09:24,068 WARN [org.keycloak.events] (default task-29)
type=LOGIN_ERROR, realmId=*****, clientId=account, userId=null,
ipAddress=191.21.133.234, (...)
So the situation is that I will only get the "real" IP of the client only
if it passes through the HTTP listener of KC (that has the parameter
"proxy-address-forwarding") which is not what I want as I want to reach the
HTTPS listener.
I obviously also tried to add the same parameter (*proxy-address-forwarding
= "true"*) in the HTTPS listener configuration but then, standalone.sh
shows an error and refuses to start :
*14:24:30,621 INFO [org.jboss.modules] (main) JBoss Modules version
1.5.1.Final*
*14:24:30,821 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final*
*14:24:30,888 INFO [org.jboss.as <http://org.jboss.as/>] (MSC service
thread 1-2) WFLYSRV0049: Keycloak 2.5.0.CR1 (WildFly Core 2.0.10.Final)
starting*
*14:24:31,597 ERROR [org.jboss.as.server] (Controller Boot Thread)
WFLYSRV0055: Caught exception during boot:
org.jboss.as.controller.persistence.ConfigurationPersistenceException:
WFLYCTL0085:
Failed to parse configuration*
* at
org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:131)*
* at org.jboss.as.server.ServerService.boot(ServerService.java:356)*
* at
org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:299)*
* at java.lang.Thread.run(Thread.java:745)*
*Caused by: javax.xml.stream.XMLStreamException: ParseError at
[row,col]:[380,17]*
*Message: WFLYCTL0376: Unexpected attribute 'proxy-address-forwarding'
encountered. Valid attributes are: 'socket-binding, worker, buffer-pool,
enabled, resolve-peer-address, security-realm, verify-client,
enabled-cipher-suites, enabled-protocols, enable-http2, enable-spdy,
ssl-session-cache-size, ssl-session-timeout, max-header-size,
max-post-size, buffer-pipelined-data, max-parameters, max-headers,
max-cookies, allow-encoded-slash, decode-url, url-charset,
always-set-keep-alive, max-buffered-request-size,
record-request-start-time, allow-equals-in-cookie-value,
no-request-timeout, request-parse-timeout, disallowed-methods, tcp-backlog,
receive-buffer, send-buffer, tcp-keep-alive, read-timeout, write-timeout,
max-connections, secure'*
* at
org.jboss.as.controller.parsing.ParseUtils.unexpectedAttribute(ParseUtils.java:128)*
*requirements* :
- Entire solution has to run with SSL (HTTPS) from end to end
Did someone already faced that situation or does have any clue about this ?
Thank you for reading this post.
Regards,
/Olivier
On 10 January 2017 at 11:52, Olivier Bruylandt <olivier.bruylandt(a)gmail.com>
wrote:
> Dear,
>
>
> I get an issue to get the wanted behavior when retrieving the client
> public IP.
> This is the situation :
> (all IP's have been anonymized)
>
>
>
> - *infrastructure level*:
>
> ----------- Reverse Proxy NGINX -----------------------------------
> KeyCloak
>
> RP is listening on ports 80 & 443 (80 is redirected to 443)
> There is a public certificate signed by some external CA
> Nginx redirects to the 8443 (https) of KC (HTTP runs on 8080)
> Keycloak is set as standalone server on a Wildfly last version
>
>
>
>
> - *Nginx config*
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *server { listen 443; server_name ************;
> fastcgi_param HTTPS on; location / { add_header
> X-Cache-Status $upstream_cache_status; add_header X-Real-IP
> $remote_addr; add_header X-Forwarded-For $remote_addr;
> add_header X-Forwarded-Proto $scheme;
> more_set_headers 'Server: ******'; more_clear_headers
> 'X-Powered-By'; charset UTF-8; proxy_cache
> ******_cache; proxy_pass https://1.1.1.1:8443/
> <https://1.1.1.1:8443/>; }*
>
>
>
>
>
>
>
>
>
>
>
>
> * ssl on; ssl_certificate /etc/ssl/private/**********.crt;
> ssl_certificate_key /etc/ssl/private/*************.key;
> ssl_prefer_server_ciphers on; ssl_dhparam /etc/ssl/***********.pem;
> ssl_protocols TLSv1.1 TLSv1.2; ssl_stapling on;
> ssl_session_cache builtin:1000 shared:SSL:10m; add_header
> Strict-Transport-Security "max-age=63072000; includeSubdomains; preload";
> add_header X-Frame-Options "DENY"; ssl_ciphers
> 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH';*
>
>
>
>
> - *Keycloak config* :
>
>
> * <subsystem xmlns="urn:jboss:domain:undertow:3.0">*
> * <buffer-cache name="default"/>*
> * <server name="default-server">*
>
> * <http-listener
> name="default" proxy-address-forwarding="true" socket-binding="http"/>*
> * <https-listener name="https" security-realm="**********"
> socket-binding="https"/>*
> * <host name="default-host" alias="localhost">*
> * <location name="/" handler="welcome-content"/>*
> * </host>*
> * </server>*
> * <servlet-container name="default">*
> * <jsp-config/>*
> * <websockets/>*
> * </servlet-container>*
> * <handlers>*
> * <file name="welcome-content"
> path="${jboss.home.dir}/welcome-content"/>*
> * </handlers>*
> * </subsystem>*
>
>
>
>
>
>
>
> The situation is that everything is working fine and smooth EXCEPT ... the
> fact that under sessions (and moreover for all user activities), the user
> IP I see is the one of the reverse proxy !!
> As I put in red in the KC config, this is what should do the trick to use
> the X-Forwarded-For header value to set the client's IP.
>
> 15:07:55,104 WARN [org.keycloak.events] (default task-19)
> type=REFRESH_TOKEN_ERROR, realmId=***, clientId=account, userId=null,
> ipAddress=2.2.2.2, (...)
>
>
>
> When I tried to reach KC on the 8080 (HTTP) listener (so the RP terminates
> the SSL connection and the one to KC server is made in HTTP), I got
> obviously a whole bunch of warnings and errors due to HTTP -> HTTPS
> transport and also a HTTP connection towards the external social identity
> providers like Google, FB, etc. ... BUT I got at least the real IP as you
> might see hereunder :
>
> 15:09:24,068 WARN [org.keycloak.events] (default task-29)
> type=LOGIN_ERROR, realmId=*****, clientId=account, userId=null,
> ipAddress=191.21.133.234, (...)
>
>
>
>
>
> So the situation is that I will only get the "real" IP of the client only
> if it passes through the HTTP listener of KC (that has the parameter
> "proxy-address-forwarding") which is not what I want as I want to reach the
> HTTPS listener.
> I obviously also tried to add the same parameter (*proxy-address-forwarding
> = "true"*) in the HTTPS listener configuration but then, standalone.sh
> shows an error and refuses to start :
>
>
> *14:24:30,621 INFO [org.jboss.modules] (main) JBoss Modules version
> 1.5.1.Final*
> *14:24:30,821 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final*
> *14:24:30,888 INFO [org.jboss.as <http://org.jboss.as/>] (MSC service
> thread 1-2) WFLYSRV0049: Keycloak 2.5.0.CR1 (WildFly Core 2.0.10.Final)
> starting*
> *14:24:31,597 ERROR [org.jboss.as.server] (Controller Boot Thread)
> WFLYSRV0055: Caught exception during boot:
> org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085:
> Failed to parse configuration*
> * at
> org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:131)*
> * at org.jboss.as.server.ServerService.boot(ServerService.java:356)*
> * at
> org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:299)*
> * at java.lang.Thread.run(Thread.java:745)*
> *Caused by: javax.xml.stream.XMLStreamException: ParseError at
> [row,col]:[380,17]*
> *Message: WFLYCTL0376: Unexpected attribute 'proxy-address-forwarding'
> encountered. Valid attributes are: 'socket-binding, worker, buffer-pool,
> enabled, resolve-peer-address, security-realm, verify-client,
> enabled-cipher-suites, enabled-protocols, enable-http2, enable-spdy,
> ssl-session-cache-size, ssl-session-timeout, max-header-size,
> max-post-size, buffer-pipelined-data, max-parameters, max-headers,
> max-cookies, allow-encoded-slash, decode-url, url-charset,
> always-set-keep-alive, max-buffered-request-size,
> record-request-start-time, allow-equals-in-cookie-value,
> no-request-timeout, request-parse-timeout, disallowed-methods, tcp-backlog,
> receive-buffer, send-buffer, tcp-keep-alive, read-timeout, write-timeout,
> max-connections, secure'*
> * at
> org.jboss.as.controller.parsing.ParseUtils.unexpectedAttribute(ParseUtils.java:128)*
>
>
>
>
>
> *requirements* :
>
> - Entire solution has to run with SSL (HTTPS) from end to end
>
>
>
> Did someone already faced that situation or does have any clue about this ?
> Thank you for reading this post.
>
> Regards,
>
>
> /Olivier
>
8 years, 12 months
Account lock after several attempts
by Dekel Aslan
Hi,
I noticed that there is the feature for brute force detection, but it only locks the user for a period of time with no option for admin to unlock.
Is there another mechanism that simply after X attempts locks the user until an admin releases him?
Thanks :)
Dekel.
The information contained in this message is proprietary to the sender, protected from disclosure, and may be privileged. The information is intended to be conveyed only to the designated recipient(s) of the message. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you.
8 years, 12 months
Access token appears to be valid even though session has expired in the background
by Scott Finlay
Hi,
We're having issues that we receive an access token (using our refresh token)
which appears to be valid for some certain amount of time (based on the expiration
time), but that the session expires in the background some time before that
because SSO Session Max has been reached.
Here's an example experiment:
SSO Session Idle = 2min
SSO Session Max = 3min
Access Token Lifespan = 1min
0 - create session (with client credentials)
---1m00 access token expires---
1m10 - register user (refresh token)
1m40 - register user
---2m10 access token expires---
2m40 - register user (refresh token)
---3m00 session expires---
3m10 - register user DIED HERE
---3m40 access token expires---
4m00 - register user (with client credentials)
Is there any way to make our expires time for access tokens take the session lifetime into account?
For example, if we request a new access token 10 seconds before SSO Session Max, it should say
that the token is valid for 10 seconds, not for 60 seconds.
Regards,
Scott
8 years, 12 months
