Fwd: Keycloak 3.2.1 Final not working in cluster
by mahendra sonawale
Hi Team,
We are facing similar problem where kelcloak is not running in cluster and
giving the same error log as mentioned by Subash in jira.
https://issues.jboss.org/browse/KEYCLOAK-5013
I tried to use the private interface as suggested into the document but
still no luck.
am I missing anything else? CAN YOU please help?? I am using Keycloak -
Version 3.2.1.Final.
I have load balancer configured above 2 keycloak nodes (nodes are running in
on different VMs)
Start command :
nohup ./bin/standalone.sh --server-config=standalone-ha.xml -b $HOSTNAME -u
230.0.0.4 &
HA configuration :
<interface name="private">
<inet-address value="$
{jboss.bind.address.private:(node1 IP address and on second node that IP
address)}
" />
</interface>
</interfaces>
<socket-binding-group name="standard-sockets"
default-interface="public" port-offset="$
{jboss.socket.binding.port-offset:0}
">
<socket-binding name="management-http" interface="private"
port="$
{jboss.management.http.port:9990}
" />
<socket-binding name="management-https" interface="private"
port="$
{jboss.management.https.port:9993}
" />
<socket-binding name="ajp" port="$
{jboss.ajp.port:8009}
" />
<socket-binding name="http" port="$
{jboss.http.port:8080}
" />
<socket-binding name="https" port="$
{jboss.https.port:8443}
" />
<socket-binding name="proxy-https" port="443"/>
<socket-binding name="jgroups-mping" interface="private"
port="0" multicast-address="$
{jboss.default.multicast.address:230.0.0.4}
"
multicast-port="45700" />
<socket-binding name="jgroups-tcp" interface="private"
port="7600" />
<socket-binding name="jgroups-tcp-fd" interface="private"
port="57600" />
<socket-binding name="jgroups-udp" interface="private"
port="55200" multicast-address="$
{jboss.default.multicast.address:230.0.0.4}
"
multicast-port="45688" />
<socket-binding name="jgroups-udp-fd" interface="private"
port="54200" />
<socket-binding name="modcluster" port="0"
multicast-address="224.0.1.105" multicast-port="23364" />
<socket-binding name="txn-recovery-environment" port="4712" />
<socket-binding name="txn-status-manager" port="4713" />
<outbound-socket-binding name="mail-smtp">
<remote-destination host="localhost" port="25" />
</outbound-socket-binding>
</socket-binding-group>
Log :
2017-11-09 04:38:22,749 INFO
[org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service
thread 1-3) ISPN000094: Received new cluster view for channel hibernate:
[keycloak2|0] (1) [keycloak2]
2017-11-09 04:38:22,750 INFO
[org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service
thread 1-2) ISPN000094: Received new cluster view for channel keycloak:
[keycloak2|0] (1) [keycloak2]
2017-11-09 04:38:22,749 INFO
[org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service
thread 1-4) ISPN000094: Received new cluster view for channel ejb:
[keycloak2|0] (1) [keycloak2]
2017-11-09 04:38:22,750 INFO
[org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service
thread 1-7) ISPN000094: Received new cluster view for channel server:
[keycloak2|0] (1) [keycloak2]
2017-11-09 04:38:22,749 INFO
[org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service
thread 1-1) ISPN000094: Received new cluster view for channel web:
[keycloak2|0] (1) [keycloak2]
2017-11-09 04:38:22,761 INFO
[org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service
thread 1-2) ISPN000079: Channel keycloak local address is keycloak2,
physical addresses are [**.**.**.**]
2017-11-09 04:38:22,763 INFO
[org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service
thread 1-1) ISPN000079: Channel web local address is keycloak2, physical
addresses are [**.**.**.**]
--
Sent from: http://keycloak-user.88327.x6.nabble.com/
8 years, 4 months
Registration when already logged in
by Gregor Tudan
Hello,
we recently upgraded Keycloak from version 3.0 to 3.2, and now we have run into a small problem, perhaps someone knows a clever solution…
In Keycloak 3.0, if a user registers while already being signed in, he would STILL be able to register a new user (with another user-name and e-mail), and would automatically be logged in to the NEW user.
After the Keycloak update, this no longer works. The user gets an error message AFTER registering a new user, stating he is already logged in as someone else, and can't go on.
I guess this was introduced by https://issues.jboss.org/browse/KEYCLOAK-4626
We redirect to the registration page using the javascript adapter. Is there some kind of parameter we can pass to:
a) get the old behaviour (user get’s logged in to the newly created account) or
b) see the error message on the registration page, instead of after registration has been completed?
Our application allows a user to have more than one account, so it’s not enough to just skip over the registration and log the user in under the old account.
Or is there another way that I’m missing?
Thanks, Gregor!
8 years, 4 months
Mutual Trust via Identity Brokering
by Michael Poettgen
Hello Everyone,
We would like to set up two (or more) Keycloak systems (in different, remote locations) and would like to establish something like mutual trust between them using Identity Brokering. For two IdPs A and B, each of the two should have their own accounts and should be set up to broker to the other IdP, e.g. via 'Keycloak OpenID Connect'. This would have the advantage that a client of A could be used by a user of B and vice versa.
Is this something that
* Definitely works
* Works, but with pitfalls ...
* Should work
* Doesn't work, because ...
Interesting situation may be, if a user tries to use a client and is redirect to IdP A, where he then clicks on "Authenticate via IdP B", where he then clicks on "Authenticate via IdP A", where he then clicks on "Authenticate via IdP B" and so on. Can this be avoided?
Thanks,
Michael
This message is for the designated recipient only and may contain privileged or confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited.
8 years, 4 months
Authentication SPI implementation for RADIUS
by John Franey
I'm not finding an implementation of Keycloak Authentication SPI for
RADIUS. Am I crazy just for looking? I mean, is the absence of such a
warning for folks? Or has it simply not been tried?
I don't find much of a demand for one either. So maybe that is the case, I
hope.
I think we'll have to write one to satisfy internal customer request.
Is there anyone willing to claim they attempted such? I'd like to hear
from you regarding approach and success.
Thanks,
John
8 years, 4 months
loggin saml requests/responses
by Phillip Fleischer
Hi,
I’m trying to debug using the saml clients and identity brokering, in the docs and several messages say that this can be done by turning on debug or trace.
I added the following to my standalone.xml but I’m not seeing anything. I also tried on a remote host by using jboss-cli.sh command to add the logger to no avail.
Is there something I’m missing?
<logger category="org.keycloak.saml">
<level name="TRACE"/>
</logger>
8 years, 4 months
API Keys
by O'Callaghan, John
Hi
I’m trying to understand if it is possible to generate an API Key for a particular user in keycloak ?
What I would like to be able to do is to generate a key that is associated with a user (and their realm roles).
I’d like to then be able to use that key at some later date (days, weeks, months later) to generate an access token which I can then use as per normal.
I would also like to be able to manage api keys created in the past – revoking them if needs be.
Is this something that is possible?
Thanks!
John
________________________________
This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy.
______________________________________________________________________________________
www.accenture.com
8 years, 4 months
Re: [keycloak-user] Keycloak as SAML Service Provider problem
by Drew Weirshousky
Hi Hynek,
The signature algorithm is set to RSA_SHA256 in okta and keycloak. I tried validating the XML response using https://www.samltool.com/validate_response.php and it fails with "Signature validation failed. Reference validation failed". Which some googling made me change Okta to use SHA1 for the Digest Algorithm. I received the same results using SHA1. I can't seem to find a digest setting for Keycloak so I would assume SHA256 is being used?
I've attached the data from SAML trace. These are both test servers setup to figure out how to do this.
Thanks
Drew Weirshousky
----- Original Message -----
From: "Hynek Mlnarik" <hmlnarik(a)redhat.com>
To: "Drew Weirshousky" <d.weirshousky(a)xsb.com>
Cc: "keycloak-user" <keycloak-user(a)lists.jboss.org>
Sent: Tuesday, November 14, 2017 5:34:12 AM
Subject: Re: [keycloak-user] Keycloak as SAML Service Provider problem
It's hard to say. Make sure the settings of signature algorithms match in
Okta and Keycloak. If you get nowhere, a dump of SAML communication (e.g.
via SAML Tracer or similar tool) would help.
--Hynek
On Mon, Nov 13, 2017 at 9:57 PM, Drew Weirshousky <d.weirshousky(a)xsb.com>
wrote:
> Hi,
> I have Keycloak 3.2.1 setup to act as a SP and Okta as a SAML IDP. I am
> trying to initiate login from Okta. After the initial user registration
> keycloak seems to fail while validating the signature on one of the SAML
> Responses. The error in the browser is invalidFederatedIdentityActionMessage
> and the stack trace is below.
>
> 20:53:59,161 ERROR [org.keycloak.broker.saml.SAMLEndpoint] (default
> task-18) validation failed: org.keycloak.common.VerificationException:
> Invalid signature on document
> at org.keycloak.protocol.saml.SamlProtocolUtils.
> verifyDocumentSignature(SamlProtocolUtils.java:83)
> at org.keycloak.broker.saml.SAMLEndpoint$PostBinding.
> verifySignature(SAMLEndpoint.java:533)
> at org.keycloak.broker.saml.SAMLEndpoint$Binding.
> handleSamlResponse(SAMLEndpoint.java:471)
> at org.keycloak.broker.saml.SAMLEndpoint$Binding.execute(
> SAMLEndpoint.java:239)
> at org.keycloak.broker.saml.SAMLEndpoint.postBinding(
> SAMLEndpoint.java:159)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(
> NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(
> DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(
> MethodInjectorImpl.java:139)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(
> ResourceMethodInvoker.java:295)
>
> The X509 certificate is the same on both ends. Am I missing a
> configuration setting some place else? Any help would be apprectated.
> Some googling brings up some old bugs but I believe they are all fixed in
> 3.2.1.
>
> Thanks
> Drew Weirshousky
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
--
--Hynek
8 years, 4 months
Keycloak as SAML Service Provider problem
by Drew Weirshousky
Hi,
I have Keycloak 3.2.1 setup to act as a SP and Okta as a SAML IDP. I am trying to initiate login from Okta. After the initial user registration keycloak seems to fail while validating the signature on one of the SAML Responses. The error in the browser is invalidFederatedIdentityActionMessage and the stack trace is below.
20:53:59,161 ERROR [org.keycloak.broker.saml.SAMLEndpoint] (default task-18) validation failed: org.keycloak.common.VerificationException: Invalid signature on document
at org.keycloak.protocol.saml.SamlProtocolUtils.verifyDocumentSignature(SamlProtocolUtils.java:83)
at org.keycloak.broker.saml.SAMLEndpoint$PostBinding.verifySignature(SAMLEndpoint.java:533)
at org.keycloak.broker.saml.SAMLEndpoint$Binding.handleSamlResponse(SAMLEndpoint.java:471)
at org.keycloak.broker.saml.SAMLEndpoint$Binding.execute(SAMLEndpoint.java:239)
at org.keycloak.broker.saml.SAMLEndpoint.postBinding(SAMLEndpoint.java:159)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139)
at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295)
The X509 certificate is the same on both ends. Am I missing a configuration setting some place else? Any help would be apprectated. Some googling brings up some old bugs but I believe they are all fixed in 3.2.1.
Thanks
Drew Weirshousky
8 years, 4 months
