User Group in the response header by proxy
by abhishek raghav
Hi,
I am maintaining a legacy application where i can not install keycloak
adapter. This is secured behind the keycloak proxy.
Keycloak proxy inject some identity headers by default keycloak_subject,
name, username, email and access token.
My requirement is such that that i need role and group should also be going
as part of injected headers. I know for the fact that this information
exists in the access token itself but then i need to add a depency/plugin
on application side to parse the token info and get the roles/groups.
Is there a way on the proxy side, i can add these two headers which can
also be sent along with the identity headers. Secondly, is it a good
approach or breaking the secured design patter.
*- Best Regards*
Abhishek Raghav
9 years, 3 months
Client Signature Algorithm from SAML Metadata
by Caranzo Gideon
Hi,
When creating a client from SAML metadata, should Keycloak use the SignatureMethod from the metadata as Signature Algorithm for the client?
I noticed that the Signature Algorithm is always RSA_SHA256 regardless of the algorithm in the metadata file. Is this a bug or it's just the designed behavior?
Thanks,
Gideon
________________________________
This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited.
E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender.
Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus.
9 years, 3 months
Migration of old offline tokens
by Marek Posolda
We have a bug that offline tokens issued in the old release (eg. 1.9.8)
don't work after migration into the new release and can't be
successfully refreshed. JIRA is
https://issues.jboss.org/browse/KEYCLOAK-4140 .
Reason is, that old offline token don't have KID in the header, but
currently we require KID to be present, so we can lookup correct key. I
wonder about possible solutions:
1) If KID is not present in offline token, then just look for the realm
active RSA key and use that one for the verification. This is easier and
I've sent PR for it now https://github.com/keycloak/keycloak/pull/3752 .
However there is one small limitation though, that if admin changes the
active realm key, the old offline tokens won't work (even though the old
publicKey is still valid, it is just not active). So seems that if we go
with this one, we should add a note to the migration guide about this
limitation?
2) Iterate over all realm RSA keys and try to verify token with any of
them. This won't have the limitation above, but it's more complex though.
IMO the limitation is acceptable, considering that it's just about
backwards compatibility. So I would rather go with simpler 1. WDYT?
Marek
9 years, 3 months
Storage Provider SPI
by Christian Froehlich
Hi,
it seems that the Sync settings for the "periodic full sync" and the
"periodic changed user sync" get only active after a restart of the
keycloak server.
What I did to get the error:
I migrate our user federation provider from version 2.3.0.Final to the new
storage proivder SPI in version 2.5.0.Final (BTW: Good job! The SPI is
better structured and includes a very good documentation at all levels!).
My ProviderFactory implements the ImportSynchronization interface to make
a periodic sync possible. The manual sync works well when I push the
coresponding buttons but the periodic sync is only activated/changed after
a restart of the server.
Should I create a jira bug? I can't find a matching bug/issue ...
Regards Christian
9 years, 3 months
Support for themes in the new deployer
by Dmitry Telegin
Hi,
The new provider deployer is incredibly cool! But could this approach
be extended to themes, so that they'd be deployed from the same
archive?
As of 2.5.0, the preferred way to deploy providers is via the
"deployments" directory. But let's imagine a complete Keycloak
extension that comprises several providers and a GUI theme. ATM, there
are three deployment options:
- old school: package everything into a JAR and deploy it as a module;
- package providers and themes separately, deploy the former via the
new mechanism and the latter as a module;
- package everything into a single JAR and deploy via the new
mechanism. This dynamically deployed module, according to JBoss/WildFly
conventions, will be named "deployment.my-module-XYZ.jar"; use this
name in the main config to load theme from the module. This is hacky
and requires restart, which renders unusable the whole idea of hot
(re)deployment.
However, there could be another option, more natural and simple one,
that is to automatically deploy providers *and* themes from the same
archive placed into the "deployments" directory. What do you think?
Cheers,
Dmitry
9 years, 3 months
Community driven documentation for unsupported LDAP vendors
by Marek Posolda
We support and test just with few known LDAP server vendors. However
there are lots of questions from the community related to other various
LDAP servers (eg. MSAD LDS, Samba4 AD, Novell eDirectory). There are
also some community contributions. For example we have the user, who did
the integration with MSAD LDS and he contributed the
MSADLDSUserAccountControlStorageMapper for that.
I was thinking whether it's good to have community-driven documentation
with the notes about how to integrate with various external LDAP
servers. We will just add the sub-chapter like "LDAP server vendors
specific configurations" to our LDAP documentation. At the beginning, we
will add the Warning paragraph with the text like:
"These LDAP servers are not tested and officially supported by the
Keycloak team. It is all driven by the community. So be aware that
provided informations are not guaranteed to be 100% up-to-date."
And then paragraphs with the needed steps how to configure LDAP
StorageProvider and mappers when you want to integrate with the
particular LDAP vendor. For example something like this for MSAD LDS:
https://issues.jboss.org/browse/KEYCLOAK-4009?focusedCommentId=13333341&p...
Marek
9 years, 3 months
Service Account enable for clients
by Sven Thoms
Is it possible via a setting to automatically enable clients registered
dynamically via the well-known registration endpoint and registration
access token? My current approach is to iterate over all clients post -
creation and set serviceaccountsEnabled to true. I need a more prompt and
real-time way
9 years, 3 months
Retrieving client's public IP not working 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 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 which is not what I want as I
would prefer getting to 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 ?
Thank you for reading this post.
Regards,
/Olivier
9 years, 3 months
