Opening reset password link in a different browser
by Eivind Larsen
Hi
We are running Keycloak 3.4.3.Final.
It seems that opening reset password link in a different browser than the
browser it was created in results in a 400 Bad request
with the message 'Login requester not enabled’, and renders the user unable
to reset credentials.
This is an issue, especially for users on mobile that often uses sandboxed
web views.
Are anyone else seeing this?
Is this a known issue?
Best regards,
Eivind Larsen
6 years, 3 months
SSL-Problem with KeycloakOIDCFilter when "Touching" WAR-File instead of restarting
by SW
Good Day everyone,
well this is kind of a tricky problem, but maybe someone can help me.
I got two server-instances:
The fist instance is kind of a testing-stage and is secured by the
keycloak-oidc-filter, where the keycloak-server is accessd with the help of
self-signed SSL-certificate
The other one is kind of production and is secured by the
keycloak-oidc-filter, where the keycloak-server is accessed by a bought
SSL-certificate
Both of them work with the certificates. No Problem, but... when I wanna
reload some propertes and touch the production-war file per commandline. I
get following error:
So I need to restart the Production-Server to get this thing working again.
It seems to me that the KeycloakOIDC-Filter can't connect to my
HTTPS-Keycloak-Instance, the filter seems to go into an instable state, when
the touch occurs and the restart resets everything.
The strange thing is that my test-server with the self-signed-certs doesn't
have the same problem.
regards && tia
Sebastian
--
Sent from: http://keycloak-user.88327.x6.nabble.com/
6 years, 3 months
Reverse Proxy issue
by Henning Waack
Hi.
Using KC 4.0.0 behind a Apache httpd proxy with SSL termination, I have the
issue that KC is return redirect URIs with http instead of https.
I have configure KC standalone.xml as follows:
<subsystem xmlns="urn:jboss:domain:undertow:4.0">
<buffer-cache name="default"/>
<server name="default-server">
<!--<http-listener name="default" socket-binding="http"
redirect-socket="https-proxy" proxy-address-forwarding="true"
enable-http2="true"/>-->
<http-listener name="default" socket-binding="http"
redirect-socket="https-proxy" proxy-address-forwarding="true"/>
<https-listener name="https" socket-binding="https"
security-realm="ApplicationRealm" enable-http2="true"/>
....
</subsystem>
...
<socket-binding-group name="standard-sockets" default-interface="public"
port-offset="${jboss.socket.binding.port-offset:0}">
...
<socket-binding name="http" port="${jboss.http.port:8080}"/>
<socket-binding name="https" port="${jboss.https.port:8443}"/>
<socket-binding name="https-proxy" port="443"/>
...
</socket-binding-group>
I have enabled the undertow request logging filter, thus seeing that the
X-Forwarded-Proto, -For and Host headers are correctly set, but KC is still
returning the wrong redirect location, using http instead of https:
2018-07-02 09:31:06,785 DEBUG
[org.keycloak.adapters.OAuthRequestAuthenticator] (default task-2) there
was no code
2018-07-02 09:31:06,785 DEBUG
[org.keycloak.adapters.OAuthRequestAuthenticator] (default task-2)
redirecting to auth server
2018-07-02 09:31:06,786 DEBUG
[org.keycloak.adapters.OAuthRequestAuthenticator] (default task-2) callback
uri: https://nak.xxx.com/auskunftssystem/sso/login
2018-07-02 09:31:06,791 DEBUG
[org.keycloak.adapters.springsecurity.filter.KeycloakAuthenticationProcessingFilter]
(default task-2) Auth outcome: NOT_ATTEMPTED
2018-07-02 09:31:06,792 DEBUG
[org.keycloak.adapters.OAuthRequestAuthenticator] (default task-2) Sending
redirect to login page:
http://nak.xxx.com/auth/realms/NAK/protocol/openid-connect/auth?response_...
2018-07-02 09:31:06,796 DEBUG
[org.springframework.security.web.context.HttpSessionSecurityContextRepository]
(default task-2) SecurityContext is empty or contents are anonymous -
context will not be stored in HttpSession.
2018-07-02 09:31:06,796 DEBUG
[org.springframework.security.web.context.SecurityContextPersistenceFilter]
(default task-2) SecurityContextHolder now cleared, as request processing
completed
2018-07-02 09:31:06,802 INFO [io.undertow.request.dump] (default task-2)
----------------------------REQUEST---------------------------
URI=/auskunftssystem/sso/login
characterEncoding=null
contentLength=-1
contentType=null
cookie=JSESSIONID=zAbSKWq1wWtYZ1CBJ48iZ0s4Gfc42QHc6XKUv_VP.nak
cookie=OAuth_Token_Request_State=dacaf5e0-34fe-4efc-842f-405a3575a74f
header=Accept=text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
header=Accept-Language=de,en-US;q=0.7,en;q=0.3
header=Accept-Encoding=gzip, deflate, br
header=DNT=1
header=X-Forwarded-Server=nak.xxx.com,
p4FD27CDE.dip0.t-ipconnect.de
header=User-Agent=Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13;
rv:60.0) Gecko/20100101 Firefox/60.0
header=Connection=Keep-Alive
header=X-Forwarded-Proto=https
header=X-Forwarded-For=21.32.236.47, 10.10.66.56
header=Cookie=OAuth_Token_Request_State=dacaf5e0-34fe-4efc-842f-405a3575a74f;
JSESSIONID=zAbSKWq1wWtYZ1CBJ48iZ0s4Gfc42QHc6XKUv_VP.nak
header=Upgrade-Insecure-Requests=1
header=Host=nak.xxx.com
header=X-Forwarded-Host=nak.xxx.com, nak.xxx.com
locale=[de, en_US, en]
method=GET
protocol=HTTP/1.1
queryString=
remoteAddr=87.167.236.47:0
remoteHost=87.167.236.47
scheme=https
host=nak.xxx.com
serverPort=0
--------------------------RESPONSE--------------------------
contentLength=-1
contentType=null
cookie=OAuth_Token_Request_State=f9a80dfd-df35-4893-9009-513d4793c1d2;
domain=null; path=null
header=Expires=0
header=Cache-Control=no-cache, no-store, max-age=0,
must-revalidate
header=Set-Cookie=OAuth_Token_Request_State=f9a80dfd-df35-4893-9009-513d4793c1d2;
secure; HttpOnly
header=X-XSS-Protection=1; mode=block
header=Pragma=no-cache
header=Location=
http://nak.xxx.com/auth/realms/NAK/protocol/openid-connect/auth?response_...
header=X-Frame-Options=DENY
header=Date=Mon, 02 Jul 2018 07:31:06 GMT
header=Connection=keep-alive
header=X-Content-Type-Options=nosniff
header=Strict-Transport-Security=max-age=31536000 ;
includeSubDomains
header=Transfer-Encoding=chunked
status=302
==============================================================
2018-07-02 09:31:07,643 DEBUG
[org.keycloak.transaction.JtaTransactionWrapper] (default task-3) new
JtaTransactionWrapper
Any idea why KC is returning http instead of https? Am I still missing some
header?
Thanks & greetings
Henning
6 years, 3 months
Get all users for a given client with consent
by Henning Waack
Hi.
Is it possible to get a list of all users who have given their consent for a specific client? I am working with KC 4.0 (and Spring Boot 2.0).
Thanks & greetings
Henning
6 years, 3 months
Keycloak on Kubernetes - HTTPS required
by Pavlov, Yordan
Hi all,
I’m evaluating Keycloak as IAM for one open source project [1], so far, I’ve tested it successfully on a minikube (local) Kubernetes cluster and I want to run it in on a real cluster.
The real cluster (created by Gardener [2]) is running on AWS and the access to the Keycloak is exposed through an Ingress controller [3].
We’ve also installed “cert-manager” for automated certificates management of Let’s Encrypt issued certificates.
So far so good, but when I try to login to the “Admin Console” I get the following error:
“We're sorry... HTTPS required”
In the logs of the pod, there is the following warning:
“WARN [org.keycloak.events] (default task-12) type=LOGIN_ERROR, realmId=master, clientId=null, userId=null, ipAddress=100.96.0.6, error=ssl_required”
As far as I understand, the Let’s Encrypt certificated is trusted by the browsers and it appears to be trusted by the OpenJDK also [4].
Then what should be done in order to access the Admin Console?
Last but not least, we are using jboss/keycloak:latest image (I know that we should be using some stable version like 4.0.0, but it appears that the issue is not related to the image version).
Regards,
Yordan Pavlov
[1] ProMART: https://github.com/promart-io | https://www.promart.io/
[2] Gardener: https://github.com/gardener
[3] Keycloak: https://kkk.ingress.promart.promart.shoot.canary.k8s-hana.ondemand.com
[4] DST Root CA X3: https://bugs.openjdk.java.net/browse/JDK-8154757
6 years, 3 months
KEYCLOAK-7237 : Redirect URI is adding port zero to the url
by Shawn Fu Sheng
Dear keycloak team,
I encountered redirect_uri error. Found same issue logged at below JIRA, just want to check any work around? Anyone can help? Thank you in advance.
KEYCLOAK-7237 <https://issues.jboss.org/browse/KEYCLOAK-7237>
2018-06-30 11:34:13,996 WARN [org.keycloak.events] (default task-8) type=LOGIN_ERROR, realmId=Victz, clientId=portal, userId=null, ipAddress=175.156.168.158, error=invalid_redirect_uri, redirect_uri=https://www.mydomain.com:0/home <https://www.mydomain.com:0/home>
I am using apache http reverse proxy running on centos7, wildly 10, keycloak 3.4.3. has also tried in below environment but same error.
Tried in
wildly 10, wildly 11, jboss 7.1
Keycloak 3.4.3 as well as keycloak 4.0
Also tried shutdown apache http and access directly to http://www.mydomain.com:8080/home <http://www.mydomain.com:8080/home> , but seems return_uri automatically been converted to https with port 0.
Please see below standalone.xml, tried removed below config in red but no luck.
<subsystem xmlns="urn:jboss:domain:undertow:4.0">
<buffer-cache name="default"/>
<server name="default-server">
<http-listener name="default" socket-binding="http" proxy-address-forwarding="true" enable-http2="true"/>
<https-listener name="https" socket-binding="https" proxy-address-forwarding="true" security-realm="ApplicationRealm" enable-http2="true"/>
<host name="default-host" alias="localhost">
<location name="/" handler="welcome-content"/>
<location name="/drive" handler="drive"/>
<access-log pattern="%h %l %u %t "%r" %s %b "%{i,Referer}" "%{i,User-Agent}" "%{i,COOKIE}" "%{o,SET-COOKIE}" %S "%I %T"" prefix="access."/>
<filter-ref name="server-header"/>
<filter-ref name="x-powered-by-header"/>
<http-invoker security-realm="ApplicationRealm"/>
</host>
<host name="mydomain1" alias="mydomain1.com,www.mydomain1.com" default-web-module=“mydomain-0.1.war">
<location name="/drive" handler="drive”/>
<filter-ref name="proxy-peer"/>
<filter-ref name="request-dumper" priority="30"/>
</host>
<host name="mydomain2" alias="mydomain2.com,www.mydomain2.com" default-web-module="mydomain2-0.1.war">
<location name="/drive" handler="drive"/>
<filter-ref name="proxy-peer"/>
<filter-ref name="request-dumper" priority="30"/>
</host>
<host name="mydomain3" alias="mydomain3.com,www.mydomain3.com" default-web-module="mydomain3-0.1.war">
<location name="/drive" handler="drive"/>
<filter-ref name="proxy-peer"/>
<filter-ref name="request-dumper" priority="30"/>
</host>
</server>
<servlet-container name="default">
<jsp-config/>
<websockets/>
</servlet-container>
<handlers>
<file name="welcome-content" path="${jboss.home.dir}/welcome-content"/>
<file name="drive" path="/app/drive"/>
</handlers>
<filters>
<response-header name="server-header" header-name="Server" header-value="JBoss-EAP/7"/>
<response-header name="x-powered-by-header" header-name="X-Powered-By" header-value="Undertow/1"/>
<filter name="proxy-peer" class-name="io.undertow.server.handlers.ProxyPeerAddressHandler" module="io.undertow.core"/>
<filter name="request-dumper" class-name="io.undertow.server.handlers.RequestDumpingHandler" module="io.undertow.core"/>
</filters>
</subsystem>
Rds,
Shawn
6 years, 3 months
