cxf filter
by Nhut Thai Le
Hello,
I have a web app and a REST API running inside an OSGI environment.
The web app has some servlets registered with the web container (jetty) as
OSGI whiteboard services. All of these servlets are configured to be
protected (authentication required) by keycloak servlet filter.
Dictionary<String, String> props;
props = new Hashtable<>();
props.put("alias", "/whiteboard");
servletReg = context.registerService(Servlet.class, new
WhiteboardServlet("/test"), props);
Dictionary<String, Object> filterProps = new Hashtable<String, Object>();
String[] urls = { "/*" }; //$NON-NLS-1$
filterProps.put(HttpWhiteboardConstants.HTTP_WHITEBOARD_FILTER_NAME,
"keycloakFilter");
filterProps.put(HttpWhiteboardConstants.HTTP_WHITEBOARD_FILTER_PATTERN,
urls);
keycloakFilter = context.registerService(Filter.class, new
KeycloakOIDCFilter(), filterProps);
The REST api is hosted by aries-jax-rs-whiteboard.
@Component(
immediate = true,
property = JAX_RS_APPLICATION_BASE + "=/rest",
service = Application.class
)
@Path("/common")
public final class RestAPI extends Application {
public static final Response EMPTY_RESPONSE =
Response.noContent().type(MediaType.TEXT_HTML_TYPE).build();
@Override
public Set<Object> getSingletons() {
return Collections.singleton(this);
}
@GET
@Path("/getObject")
@Produces(MediaType.APPLICATION_JSON)
public String getObject() {
return "Rest call"; //$NON-NLS-1$
}
}
The web app has some JS code executed on user browser that make an ajax
call to the REST service above. Since this call happen after user has been
auithenticated with keycloak and originate from the same browser session, I
assume the ajax request also contains KeycloakSecurityContext. Thus this
call should be allowed to reach the REST service. What I want is to
register a filter (ContainerRequestFilter) to deny access to the REST
service if user has not been authenticated.
Is there an existing implementation of ContainerRequestFilter by keycloak
that can do this?
Thai
8 years
Need help : How to configure keycloak client for android / IOS application
by Christophe Lehingue
Hello,
How to configure the information for an android client application (as
attachment, screenshots) in the keycloak administration environment?
What should I put as information in the following areas:
- Valid Redirect URIs
- Web Origins
Is there any other information to inform?
Regards,
Christophe
[image: image.png]
[image: image.png]
8 years
LOGIN_ERROR invalid_redirect_uri
by sisyphus18
Hello Users,
Apologies if this is not the right place to ask a question.
I have an issue in configuring KeyCloak...I am getting an error "invalid redirect uri"
Here's the log output from the service provider, a local application...
8-08-30 13:19:12.420 INFO --- [nio-8080-exec-2] o.s.security.saml.log.SAMLDefaultLogger : AuthNRequest;SUCCESS;127.0.0.1;[https://*/csi-gu](https://csichargingdev....
hargedb/;http://localhost:8081/auth/realms/csi_realm_1;;;
Here's the log from Keycloak
13:19:13,414 WARN [org.keycloak.events] (default task-1) type=LOGIN_ERROR, realmId=csi_realm_1, clientId=null, userId=null, ipAddress=127.0.0.1, error=invalid_redirect_uri
I do not know what value I have to put for redirect URI...I have tried many permutations and combinations. Attached are some screenshots from the Keycloak interface as well. Any help will be greatly appreciated.
Thanking you.
Sent with [ProtonMail](https://protonmail.com) Secure Email.
8 years
Optional/Alternative in login flows
by Max Allan
Hi,
I'd like to make a login flow :
If the user has TOTP, use it.
If the user has no TOTP but SMS, use it instead.
If the user has neither use the TOTP normal enrolment to set it up.
Setting the SMS execution to optional results in a "missing mobile number"
error when I login, rather than skipping the step. Is this a fault in the
SMS plugin? Or have I misunderstood the "optional" indicator?
(https://github.com/gwallet/keycloak-sms-authenticator)
Thanks,
Max
8 years
Re: [keycloak-user] Does Keycloak need sticky session at the load balancer?
by Rafael Weingärtner
Thanks!
you guys helped me a lot!
On Thu, Aug 30, 2018 at 8:17 AM, Bela Ban <bban(a)redhat.com> wrote:
>
>
> On 30/08/18 13:02, Rafael Weingärtner wrote:
>
>> Awesome, thanks for the help, Sebastian. I have a question regarding
>> these "owners" numbers. What happens if I set this number to (let's say) 10
>> and I only spin up 7 nodes? Is it a valid deployment? And, will everything
>> work just fine? Or, would I start to get errors?
>>
>
> If numOwners is bigger than the number of members in the cluster, you
> essentially end up with full replication, where every data item is
> replicated to all members.
>
> IIRC, Infinispan even checks for this condition and automatically switches
> to multicasting rather than unicasting as long as the condition holds.
>
>
> On Thu, Aug 30, 2018 at 5:02 AM, Sebastian Laskawiec <slaskawi(a)redhat.com
>> <mailto:slaskawi@redhat.com>> wrote:
>>
>> On Wed, Aug 29, 2018 at 3:27 PM Rafael Weingärtner
>> <rafaelweingartner(a)gmail.com <mailto:rafaelweingartner@gmail.com>>
>> wrote:
>>
>> I think I will need a little bit of your wisdom again.
>>
>> I am now seeing the cluster between my Keycloak replicas to be
>> created:
>>
>> ^[[0m^[[0m13:03:03,800 INFO
>> [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
>> (MSC service thread 1-2) ISPN000079: Channel ejb local address is
>> keycloak01, physical addresses are [192.168.1.58:55200 <
>> http://192.168.1.58:55200>]
>>
>> ^[[0m^[[0m13:03:03,801 INFO
>> [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
>> (MSC service thread 1-1) ISPN000094: Received new cluster view for channel
>> ejb: [keycloak02|1] (2) [keycloak02, keycloak01]
>>
>>
>> The problem is that when I shutdown one of them, a logged user
>> will receive the following message:
>>
>> An internal server error has occurred
>>
>> Then, in the log files I see the following:
>>
>> ^[[0m^[[31m13:18:04,149 ERROR
>> [org.infinispan.interceptors.InvocationContextInterceptor]
>> (default task-24) ISPN000136: Error executing command
>> GetKeyValueCommand, writing keys []:
>> org.infinispan.util.concurrent.TimeoutException: Replication
>> timeout
>> at
>> org.infinispan.remoting.transport.jgroups.JGroupsTransport.
>> lambda$invokeRemotelyAsync$1(JGroupsTransport.java:639)
>> ^[[0m^[[31m13:18:15,262 ERROR
>> [org.infinispan.interceptors.InvocationContextInterceptor]
>> (expiration-thread--p22-t1) ISPN000136: Error executing
>> command RemoveExpiredCommand, writing keys
>> [468d1940-7293-4824-9e86-4aece6cd6744]:
>> org.infinispan.util.concurrent.TimeoutException: Replication
>> timeout for keycloak02
>>
>>
>> I see you just killed the node (e.g. kill -9 <pid>), so that it
>> exited without saying "goodbye". In that case JGroups FD_* protocols
>> on the other node need to do their work and discover the failure. If
>> you have any commands in flight, they might fail. I highly encourage
>> you to use a larger cluster (with odd number of nodes if possible).
>> Having only two nodes can be a bit dangerous. Imagine a partition
>> split, after the split heals, which node is right? Hard to tell...
>>
>>
>> I would say that this is expected as the node is down. However,
>> it should not be a problem for the whole system.
>>
>> My replication settings are the following:
>>
>> <distributed-cache name="sessions" mode="SYNC" owners="2"/>
>> <distributed-cache name="authenticationSessions" mode="SYNC"
>> owners="2"/>
>> <distributed-cache name="offlineSessions" mode="SYNC"
>> owners="2"/>
>> <distributed-cache name="clientSessions" mode="SYNC"
>> owners="2"/>
>> <distributed-cache name="offlineClientSessions" mode="SYNC"
>> owners="2"/>
>> <distributed-cache name="loginFailures" mode="SYNC"
>> owners="2"/>
>>
>>
>> Do I need to change something else?
>>
>> Here's the exactly the same problem. With number of owners=2 and 2
>> nodes, this is essentially a replicated cache (despite some
>> differences in logic). I'd advice using at least 3 nodes (or even
>> better 5).
>>
>>
>> On Wed, Aug 29, 2018 at 9:51 AM, Rafael Weingärtner
>> <rafaelweingartner(a)gmail.com
>> <mailto:rafaelweingartner@gmail.com>> wrote:
>>
>> Ah no problem. It was my fault. I forgot to start debugging
>> from the ground up (connectivity, firewalls, applications
>> and so on )
>>
>> On Wed, Aug 29, 2018 at 9:49 AM, Bela Ban <bban(a)redhat.com
>> <mailto:bban@redhat.com>> wrote:
>>
>> Excellent! Unfortunately, JGroups cannot detect this...
>>
>> On 29/08/18 14:42, Rafael Weingärtner wrote:
>>
>> Thanks!
>> The problem was caused by firewalld blocking
>> Multicast traffic.
>>
>> On Fri, Aug 24, 2018 at 7:28 AM, Sebastian Laskawiec
>> <slaskawi(a)redhat.com <mailto:slaskawi@redhat.com>
>> <mailto:slaskawi@redhat.com
>> <mailto:slaskawi@redhat.com>>> wrote:
>>
>> Great write-up! Bookmarked!
>>
>> On Thu, Aug 23, 2018 at 4:36 PM Bela Ban
>> <bban(a)redhat.com <mailto:bban@redhat.com>
>> <mailto:bban@redhat.com
>> <mailto:bban@redhat.com>>> wrote:
>>
>> Have you checked
>> https://github.com/belaban/wor
>> kshop/blob/master/slides/admin.adoc#problem-1-members-don-t-
>> find-each-other
>> <https://github.com/belaban/wo
>> rkshop/blob/master/slides/admin.adoc#problem-1-members-don-
>> t-find-each-other>
>> <
>> https://github.com/belaban/workshop/blob/master/slides/admi
>> n.adoc#problem-1-members-don-t-find-each-other
>> <https://github.com/belaban/wo
>> rkshop/blob/master/slides/admin.adoc#problem-1-members-don-
>> t-find-each-other>>?
>>
>> On 23/08/18 13:53, Sebastian Laskawiec wrote:
>> > +Bela Ban <mailto:bban@redhat.com
>> <mailto:bban@redhat.com> <mailto:bban@redhat.com
>>
>> <mailto:bban@redhat.com>>>
>> >
>> > As I expected, the cluster doesn't form.
>> >
>> > I'm not sure where and why those UDP
>> discovery packets are
>> rejected. I
>> > just stumbled upon this thread [1],
>> which you may find
>> useful. Maybe
>> > Bela will also have an idea what's going
>> on there.
>> >
>> > If you won't manage to get UDP working,
>> you can always fall
>> back into
>> > TCP (and MPING).
>> >
>> > [1]
>> https://serverfault.com/questi
>> ons/211482/tools-to-test-multicast-routing
>> <https://serverfault.com/quest
>> ions/211482/tools-to-test-multicast-routing>
>> <
>> https://serverfault.com/questions/211482/tools-to-test-multicast-routing
>> <https://serverfault.com/quest
>> ions/211482/tools-to-test-multicast-routing>>
>> >
>> > On Thu, Aug 23, 2018 at 1:26 PM Rafael
>> Weingärtner
>> > <rafaelweingartner(a)gmail.com
>> <mailto:rafaelweingartner@gmail.com>
>> <mailto:rafaelweingartner@gmail.com
>> <mailto:rafaelweingartner@gmail.com>>
>> <mailto:rafaelweingartner@gmail.com
>> <mailto:rafaelweingartner@gmail.com>
>>
>> <mailto:rafaelweingartner@gmail.com
>> <mailto:rafaelweingartner@gmail.com>>>> wrote:
>> >
>> > Thanks for the reply Sebastian!
>> >
>> >
>> > Note, that IP Multicasting is
>> disabled in many data
>> centers (I
>> > have never found out why they do
>> it, but I've seen it
>> many, many
>> > times). So make sure your
>> cluster forms correctly
>> (just grep
>> > logs and look for "view").
>> >
>> >
>> > I thought about that. Then, I used
>> tcpdump, and I can see the
>> > multicast packets from both Keycloak
>> replicas. However,
>> it seems
>> > that these packets are being ignored.
>> >
>> > root@Keycloak01:/# tcpdump -i
>> eth0 port 7600 or port
>> 55200 or
>> > port 45700 or port 45688 or port
>> 23364 or port 4712
>> or port 4713
>> > tcpdump: verbose output
>> suppressed, use -v or -vv for
>> full
>> > protocol decode
>> > listening on eth0, link-type
>> EN10MB (Ethernet),
>> capture size
>> > 262144 bytes
>> > 11:13:36.540080 IP
>> keycloak02.local.55200 >
>> 230.0.0.4.45688:
>> > UDP, length 83
>> > 11:13:41.288449 IP
>> keycloak02.local.55200 >
>> 230.0.0.4.45688:
>> > UDP, length 83
>> > 11:13:46.342606 IP
>> keycloak02.local.55200 >
>> 230.0.0.4.45688:
>> > UDP, length 83
>> >
>> >
>> > root@keycloak02:/# tcpdump -i
>> eth0 port 7600 or port
>> 55200 or
>> > port 45700 or port 45688 or port
>> 23364 or port 4712
>> or port 4713
>> > tcpdump: verbose output
>> suppressed, use -v or -vv for
>> full
>> > protocol decode
>> > listening on eth0, link-type
>> EN10MB (Ethernet),
>> capture size
>> > 262144 bytes
>> > 11:12:14.218317 IP
>> Keycloak01.local.55200 >
>> 230.0.0.4.45688:
>> > UDP, length 83
>> > 11:12:23.146798 IP
>> Keycloak01.local.55200 >
>> 230.0.0.4.45688:
>> > UDP, length 83
>> > 11:12:27.201888 IP
>> Keycloak01.local.55200 >
>> 230.0.0.4.45688:
>> > UDP, length 83
>> >
>> >
>> >
>> > Here go the log entries. I filtered
>> by “view”. This is
>> from Keycloak01.
>> >
>> > ^[[0m^[[0m11:16:57,896 INFO
>> >
>> [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
>> > (MSC service thread 1-4)
>> ISPN000094: Received new
>> cluster view
>> > for channel ejb: [keycloak01|0]
>> (1) [keycloak01]
>> > ^[[0m^[[0m11:16:57,896 INFO
>> >
>> [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
>> > (MSC service thread 1-2)
>> ISPN000094: Received new
>> cluster view
>> > for channel ejb: [keycloak01|0]
>> (1) [keycloak01]
>> > ^[[0m^[[0m11:16:57,897 INFO
>> >
>> [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
>> > (MSC service thread 1-1)
>> ISPN000094: Received new
>> cluster view
>> > for channel ejb: [keycloak01|0]
>> (1) [keycloak01]
>> > ^[[0m^[[0m11:16:57,898 INFO
>> >
>> [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
>> > (MSC service thread 1-3)
>> ISPN000094: Received new
>> cluster view
>> > for channel ejb: [keycloak01|0]
>> (1) [keycloak01]
>> > ^[[0m^[[0m11:16:57,962 INFO
>> >
>> [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
>> > (MSC service thread 1-1)
>> ISPN000094: Received new
>> cluster view
>> > for channel ejb: [keycloak01|0]
>> (1) [keycloak01]
>> >
>> >
>> > I expected it to be only one. I
>> mean, I first started
>> Keycloak01,
>> > and just then Keycloak02. Next, we
>> have the logs from
>> Keycloak02.
>> >
>> > ^[[0m^[[0m11:17:34,950 INFO
>> >
>> [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
>> > (MSC service thread 1-3)
>> ISPN000094: Received new
>> cluster view
>> > for channel ejb: [keycloak02|0]
>> (1) [keycloak02]
>> > ^[[0m^[[0m11:17:34,952 INFO
>> >
>> [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
>> > (MSC service thread 1-4)
>> ISPN000094: Received new
>> cluster view
>> > for channel ejb: [keycloak02|0]
>> (1) [keycloak02]
>> > ^[[0m^[[0m11:17:34,957 INFO
>> >
>> [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
>> > (MSC service thread 1-1)
>> ISPN000094: Received new
>> cluster view
>> > for channel ejb: [keycloak02|0]
>> (1) [keycloak02]
>> > ^[[0m^[[0m11:17:34,957 INFO
>> >
>> [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
>> > (MSC service thread 1-2)
>> ISPN000094: Received new
>> cluster view
>> > for channel ejb: [keycloak02|0]
>> (1) [keycloak02]
>> > ^[[0m^[[0m11:17:35,052 INFO
>> >
>> [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
>> > (MSC service thread 1-1)
>> ISPN000094: Received new
>> cluster view
>> > for channel ejb: [keycloak02|0]
>> (1) [keycloak02
>> >
>> >
>> > They are similar. It seems that both
>> applications are not
>> seeing
>> > each other. At first, I thought that
>> the problem was
>> caused by
>> > “owners=1” configuration (the lack
>> of data
>> synchronization between
>> > replicas). I then changed it to
>> “owners=2”, but still, if
>> I log in
>> > the Keycloak01 and then force my
>> request to go two
>> Keycloak02, my
>> > session is not there, and I am
>> requested to log in again.
>> >
>> > Do you need some other log entries
>> or configuration files?
>> >
>> > Again, thanks for your reply and help!
>> >
>> > On Thu, Aug 23, 2018 at 5:24 AM,
>> Sebastian Laskawiec
>> > <slaskawi(a)redhat.com
>> <mailto:slaskawi@redhat.com>
>> <mailto:slaskawi@redhat.com
>> <mailto:slaskawi@redhat.com>>
>> <mailto:slaskawi@redhat.com
>> <mailto:slaskawi@redhat.com>
>> <mailto:slaskawi@redhat.com
>> <mailto:slaskawi@redhat.com>>>> wrote:
>> >
>> >
>> >
>> > On Wed, Aug 22, 2018 at 10:24 PM
>> Rafael Weingärtner
>> > <rafaelweingartner(a)gmail.com
>> <mailto:rafaelweingartner@gmail.com>
>> <mailto:rafaelweingartner@gmail.com
>> <mailto:rafaelweingartner@gmail.com>>
>> > <mailto:
>> rafaelweingartner(a)gmail.com
>> <mailto:rafaelweingartner@gmail.com>
>>
>> <mailto:rafaelweingartner@gmail.com
>> <mailto:rafaelweingartner@gmail.com>>>> wrote:
>> >
>> > Hello Keycloakers,
>> >
>> > I have some doubts regarding
>> Keycloak and load
>> balancers. I
>> > set up two
>> > keycloak replicas to provide
>> HA. To start them I
>> am using
>> > “./standalone.sh
>> >
>> --server-config=standalone-ha.xml”. I am
>> assuming that they
>> > will use
>> > multicast to replicate
>> information between nodes,
>> right?
>> >
>> >
>> > That is correct. It uses PING
>> protocol, which in turn
>> uses IP
>> > Multicasting for discovery.
>> >
>> > Note, that IP Multicasting is
>> disabled in many data
>> centers (I
>> > have never found out why they do
>> it, but I've seen it
>> many, many
>> > times). So make sure your
>> cluster forms correctly
>> (just grep
>> > logs and look for "view").
>> >
>> > Then, I set up a load
>> balancer layer using Apache
>> HTTPD and
>> > AJP connector
>> > via 8009 port. To make
>> everything work I needed
>> to use
>> > sticky session;
>> > otherwise, the login would
>> never happen. I am
>> fine with the
>> > sticky session,
>> > however, if I stop one of
>> the replicas where the
>> user is
>> > logged in, when
>> > the user access Keycloak
>> again, he/she is asked
>> to present
>> > the credentials
>> > as if he/she was not logged
>> in the other Keycloak
>> replica.
>> > Is that the
>> > expected behavior?
>> >
>> >
>> > My intuition tells me that your
>> cluster didn't form
>> correctly
>> > (as I mentioned before, grep the
>> logs and look for "view"
>> > generated by JGroups).
>> Therefore, if you enable
>> sticky session,
>> > all your requests get to the
>> same Keycloak instance,
>> which has
>> > everything in the local cache.
>> That's why it works fine.
>> >
>> >
>> > Is there some
>> troubleshooting or test that I can
>> perform to
>> > check if
>> > replication is being executed?
>> >
>> >
>> > Let's start with investigating
>> the logs. Later on we
>> can check JMX.
>> >
>> >
>> > --
>> > Rafael Weingärtner
>> >
>> _______________________________________________
>> > keycloak-user mailing list
>> > keycloak-user(a)lists.jboss.org
>> <mailto:keycloak-user@lists.jboss.org>
>> <mailto:keycloak-user@lists.jboss.org
>> <mailto:keycloak-user@lists.jboss.org>>
>> > <mailto:
>> keycloak-user(a)lists.jboss.org
>> <mailto:keycloak-user@lists.jboss.org>
>> <mailto:keycloak-user@lists.jboss.org
>> <mailto:keycloak-user@lists.jboss.org>>>
>> >
>> https://lists.jboss.org/mailma
>> n/listinfo/keycloak-user
>> <https://lists.jboss.org/mailm
>> an/listinfo/keycloak-user>
>> <
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>> <https://lists.jboss.org/mailm
>> an/listinfo/keycloak-user>>
>> >
>> >
>> >
>> >
>> > --
>> > Rafael Weingärtner
>> >
>>
>> -- Bela Ban | http://www.jgroups.org
>>
>>
>>
>>
>> -- Rafael Weingärtner
>>
>>
>> -- Bela Ban | http://www.jgroups.org
>>
>>
>>
>>
>> -- Rafael Weingärtner
>>
>>
>>
>>
>> -- Rafael Weingärtner
>>
>>
>>
>>
>> --
>> Rafael Weingärtner
>>
>
> --
> Bela Ban | http://www.jgroups.org
>
>
--
Rafael Weingärtner
8 years
Re: [keycloak-user] Does Keycloak need sticky session at the load balancer?
by Rafael Weingärtner
I think I will need a little bit of your wisdom again.
I am now seeing the cluster between my Keycloak replicas to be created:
> ^[[0m^[[0m13:03:03,800 INFO
> [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service
> thread 1-2) ISPN000079: Channel ejb local address is keycloak01, physical
> addresses are [192.168.1.58:55200]
> ^[[0m^[[0m13:03:03,801 INFO
> [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service
> thread 1-1) ISPN000094: Received new cluster view for channel ejb:
> [keycloak02|1] (2) [keycloak02, keycloak01]
>
The problem is that when I shutdown one of them, a logged user will receive
the following message:
> An internal server error has occurred
>
Then, in the log files I see the following:
> ^[[0m^[[31m13:18:04,149 ERROR
> [org.infinispan.interceptors.InvocationContextInterceptor] (default
> task-24) ISPN000136: Error executing command GetKeyValueCommand, writing
> keys []: org.infinispan.util.concurrent.TimeoutException: Replication
> timeout
> at
> org.infinispan.remoting.transport.jgroups.JGroupsTransport.lambda$invokeRemotelyAsync$1(JGroupsTransport.java:639)
> ^[[0m^[[31m13:18:15,262 ERROR
> [org.infinispan.interceptors.InvocationContextInterceptor]
> (expiration-thread--p22-t1) ISPN000136: Error executing command
> RemoveExpiredCommand, writing keys [468d1940-7293-4824-9e86-4aece6cd6744]:
> org.infinispan.util.concurrent.TimeoutException: Replication timeout for
> keycloak02
>
I would say that this is expected as the node is down. However, it should
not be a problem for the whole system.
My replication settings are the following:
> <distributed-cache name="sessions" mode="SYNC" owners="2"/>
> <distributed-cache name="authenticationSessions" mode="SYNC" owners="2"/>
> <distributed-cache name="offlineSessions" mode="SYNC" owners="2"/>
> <distributed-cache name="clientSessions" mode="SYNC" owners="2"/>
> <distributed-cache name="offlineClientSessions" mode="SYNC" owners="2"/>
> <distributed-cache name="loginFailures" mode="SYNC" owners="2"/>
>
Do I need to change something else?
On Wed, Aug 29, 2018 at 9:51 AM, Rafael Weingärtner <
rafaelweingartner(a)gmail.com> wrote:
> Ah no problem. It was my fault. I forgot to start debugging from the
> ground up (connectivity, firewalls, applications and so on )
>
> On Wed, Aug 29, 2018 at 9:49 AM, Bela Ban <bban(a)redhat.com> wrote:
>
>> Excellent! Unfortunately, JGroups cannot detect this...
>>
>> On 29/08/18 14:42, Rafael Weingärtner wrote:
>>
>>> Thanks!
>>> The problem was caused by firewalld blocking Multicast traffic.
>>>
>>> On Fri, Aug 24, 2018 at 7:28 AM, Sebastian Laskawiec <
>>> slaskawi(a)redhat.com <mailto:slaskawi@redhat.com>> wrote:
>>>
>>> Great write-up! Bookmarked!
>>>
>>> On Thu, Aug 23, 2018 at 4:36 PM Bela Ban <bban(a)redhat.com
>>> <mailto:bban@redhat.com>> wrote:
>>>
>>> Have you checked
>>> https://github.com/belaban/workshop/blob/master/slides/admin
>>> .adoc#problem-1-members-don-t-find-each-other
>>> <https://github.com/belaban/workshop/blob/master/slides/admi
>>> n.adoc#problem-1-members-don-t-find-each-other>?
>>>
>>> On 23/08/18 13:53, Sebastian Laskawiec wrote:
>>> > +Bela Ban <mailto:bban@redhat.com <mailto:bban@redhat.com>>
>>> >
>>> > As I expected, the cluster doesn't form.
>>> >
>>> > I'm not sure where and why those UDP discovery packets are
>>> rejected. I
>>> > just stumbled upon this thread [1], which you may find
>>> useful. Maybe
>>> > Bela will also have an idea what's going on there.
>>> >
>>> > If you won't manage to get UDP working, you can always fall
>>> back into
>>> > TCP (and MPING).
>>> >
>>> > [1]
>>> https://serverfault.com/questions/211482/tools-to-test-multi
>>> cast-routing
>>> <https://serverfault.com/questions/211482/tools-to-test-mult
>>> icast-routing>
>>> >
>>> > On Thu, Aug 23, 2018 at 1:26 PM Rafael Weingärtner
>>> > <rafaelweingartner(a)gmail.com
>>> <mailto:rafaelweingartner@gmail.com>
>>> <mailto:rafaelweingartner@gmail.com
>>>
>>> <mailto:rafaelweingartner@gmail.com>>> wrote:
>>> >
>>> > Thanks for the reply Sebastian!
>>> >
>>> >
>>> > Note, that IP Multicasting is disabled in many data
>>> centers (I
>>> > have never found out why they do it, but I've seen it
>>> many, many
>>> > times). So make sure your cluster forms correctly
>>> (just grep
>>> > logs and look for "view").
>>> >
>>> >
>>> > I thought about that. Then, I used tcpdump, and I can see
>>> the
>>> > multicast packets from both Keycloak replicas. However,
>>> it seems
>>> > that these packets are being ignored.
>>> >
>>> > root@Keycloak01:/# tcpdump -i eth0 port 7600 or port
>>> 55200 or
>>> > port 45700 or port 45688 or port 23364 or port 4712
>>> or port 4713
>>> > tcpdump: verbose output suppressed, use -v or -vv for
>>> full
>>> > protocol decode
>>> > listening on eth0, link-type EN10MB (Ethernet),
>>> capture size
>>> > 262144 bytes
>>> > 11:13:36.540080 IP keycloak02.local.55200 >
>>> 230.0.0.4.45688:
>>> > UDP, length 83
>>> > 11:13:41.288449 IP keycloak02.local.55200 >
>>> 230.0.0.4.45688:
>>> > UDP, length 83
>>> > 11:13:46.342606 IP keycloak02.local.55200 >
>>> 230.0.0.4.45688:
>>> > UDP, length 83
>>> >
>>> >
>>> > root@keycloak02:/# tcpdump -i eth0 port 7600 or port
>>> 55200 or
>>> > port 45700 or port 45688 or port 23364 or port 4712
>>> or port 4713
>>> > tcpdump: verbose output suppressed, use -v or -vv for
>>> full
>>> > protocol decode
>>> > listening on eth0, link-type EN10MB (Ethernet),
>>> capture size
>>> > 262144 bytes
>>> > 11:12:14.218317 IP Keycloak01.local.55200 >
>>> 230.0.0.4.45688:
>>> > UDP, length 83
>>> > 11:12:23.146798 IP Keycloak01.local.55200 >
>>> 230.0.0.4.45688:
>>> > UDP, length 83
>>> > 11:12:27.201888 IP Keycloak01.local.55200 >
>>> 230.0.0.4.45688:
>>> > UDP, length 83
>>> >
>>> >
>>> >
>>> > Here go the log entries. I filtered by “view”. This is
>>> from Keycloak01.
>>> >
>>> > ^[[0m^[[0m11:16:57,896 INFO
>>> > [org.infinispan.remoting.tran
>>> sport.jgroups.JGroupsTransport]
>>> > (MSC service thread 1-4) ISPN000094: Received new
>>> cluster view
>>> > for channel ejb: [keycloak01|0] (1) [keycloak01]
>>> > ^[[0m^[[0m11:16:57,896 INFO
>>> > [org.infinispan.remoting.tran
>>> sport.jgroups.JGroupsTransport]
>>> > (MSC service thread 1-2) ISPN000094: Received new
>>> cluster view
>>> > for channel ejb: [keycloak01|0] (1) [keycloak01]
>>> > ^[[0m^[[0m11:16:57,897 INFO
>>> > [org.infinispan.remoting.tran
>>> sport.jgroups.JGroupsTransport]
>>> > (MSC service thread 1-1) ISPN000094: Received new
>>> cluster view
>>> > for channel ejb: [keycloak01|0] (1) [keycloak01]
>>> > ^[[0m^[[0m11:16:57,898 INFO
>>> > [org.infinispan.remoting.tran
>>> sport.jgroups.JGroupsTransport]
>>> > (MSC service thread 1-3) ISPN000094: Received new
>>> cluster view
>>> > for channel ejb: [keycloak01|0] (1) [keycloak01]
>>> > ^[[0m^[[0m11:16:57,962 INFO
>>> > [org.infinispan.remoting.tran
>>> sport.jgroups.JGroupsTransport]
>>> > (MSC service thread 1-1) ISPN000094: Received new
>>> cluster view
>>> > for channel ejb: [keycloak01|0] (1) [keycloak01]
>>> >
>>> >
>>> > I expected it to be only one. I mean, I first started
>>> Keycloak01,
>>> > and just then Keycloak02. Next, we have the logs from
>>> Keycloak02.
>>> >
>>> > ^[[0m^[[0m11:17:34,950 INFO
>>> > [org.infinispan.remoting.tran
>>> sport.jgroups.JGroupsTransport]
>>> > (MSC service thread 1-3) ISPN000094: Received new
>>> cluster view
>>> > for channel ejb: [keycloak02|0] (1) [keycloak02]
>>> > ^[[0m^[[0m11:17:34,952 INFO
>>> > [org.infinispan.remoting.tran
>>> sport.jgroups.JGroupsTransport]
>>> > (MSC service thread 1-4) ISPN000094: Received new
>>> cluster view
>>> > for channel ejb: [keycloak02|0] (1) [keycloak02]
>>> > ^[[0m^[[0m11:17:34,957 INFO
>>> > [org.infinispan.remoting.tran
>>> sport.jgroups.JGroupsTransport]
>>> > (MSC service thread 1-1) ISPN000094: Received new
>>> cluster view
>>> > for channel ejb: [keycloak02|0] (1) [keycloak02]
>>> > ^[[0m^[[0m11:17:34,957 INFO
>>> > [org.infinispan.remoting.tran
>>> sport.jgroups.JGroupsTransport]
>>> > (MSC service thread 1-2) ISPN000094: Received new
>>> cluster view
>>> > for channel ejb: [keycloak02|0] (1) [keycloak02]
>>> > ^[[0m^[[0m11:17:35,052 INFO
>>> > [org.infinispan.remoting.tran
>>> sport.jgroups.JGroupsTransport]
>>> > (MSC service thread 1-1) ISPN000094: Received new
>>> cluster view
>>> > for channel ejb: [keycloak02|0] (1) [keycloak02
>>> >
>>> >
>>> > They are similar. It seems that both applications are not
>>> seeing
>>> > each other. At first, I thought that the problem was
>>> caused by
>>> > “owners=1” configuration (the lack of data
>>> synchronization between
>>> > replicas). I then changed it to “owners=2”, but still, if
>>> I log in
>>> > the Keycloak01 and then force my request to go two
>>> Keycloak02, my
>>> > session is not there, and I am requested to log in again.
>>> >
>>> > Do you need some other log entries or configuration files?
>>> >
>>> > Again, thanks for your reply and help!
>>> >
>>> > On Thu, Aug 23, 2018 at 5:24 AM, Sebastian Laskawiec
>>> > <slaskawi(a)redhat.com <mailto:slaskawi@redhat.com>
>>> <mailto:slaskawi@redhat.com <mailto:slaskawi@redhat.com>>>
>>> wrote:
>>> >
>>> >
>>> >
>>> > On Wed, Aug 22, 2018 at 10:24 PM Rafael Weingärtner
>>> > <rafaelweingartner(a)gmail.com
>>> <mailto:rafaelweingartner@gmail.com>
>>> > <mailto:rafaelweingartner@gmail.com
>>>
>>> <mailto:rafaelweingartner@gmail.com>>> wrote:
>>> >
>>> > Hello Keycloakers,
>>> >
>>> > I have some doubts regarding Keycloak and load
>>> balancers. I
>>> > set up two
>>> > keycloak replicas to provide HA. To start them I
>>> am using
>>> > “./standalone.sh
>>> > --server-config=standalone-ha.xml”. I am
>>> assuming that they
>>> > will use
>>> > multicast to replicate information between nodes,
>>> right?
>>> >
>>> >
>>> > That is correct. It uses PING protocol, which in turn
>>> uses IP
>>> > Multicasting for discovery.
>>> >
>>> > Note, that IP Multicasting is disabled in many data
>>> centers (I
>>> > have never found out why they do it, but I've seen it
>>> many, many
>>> > times). So make sure your cluster forms correctly
>>> (just grep
>>> > logs and look for "view").
>>> >
>>> > Then, I set up a load balancer layer using Apache
>>> HTTPD and
>>> > AJP connector
>>> > via 8009 port. To make everything work I needed
>>> to use
>>> > sticky session;
>>> > otherwise, the login would never happen. I am
>>> fine with the
>>> > sticky session,
>>> > however, if I stop one of the replicas where the
>>> user is
>>> > logged in, when
>>> > the user access Keycloak again, he/she is asked
>>> to present
>>> > the credentials
>>> > as if he/she was not logged in the other Keycloak
>>> replica.
>>> > Is that the
>>> > expected behavior?
>>> >
>>> >
>>> > My intuition tells me that your cluster didn't form
>>> correctly
>>> > (as I mentioned before, grep the logs and look for
>>> "view"
>>> > generated by JGroups). Therefore, if you enable
>>> sticky session,
>>> > all your requests get to the same Keycloak instance,
>>> which has
>>> > everything in the local cache. That's why it works
>>> fine.
>>> >
>>> >
>>> > Is there some troubleshooting or test that I can
>>> perform to
>>> > check if
>>> > replication is being executed?
>>> >
>>> >
>>> > Let's start with investigating the logs. Later on we
>>> can check JMX.
>>> >
>>> >
>>> > --
>>> > Rafael Weingärtner
>>> > _______________________________________________
>>> > keycloak-user mailing list
>>> > keycloak-user(a)lists.jboss.org
>>> <mailto:keycloak-user@lists.jboss.org>
>>> > <mailto:keycloak-user@lists.jboss.org
>>> <mailto:keycloak-user@lists.jboss.org>>
>>> > https://lists.jboss.org/mailman/listinfo/keycloak-user
>>> <https://lists.jboss.org/mailman/listinfo/keycloak-user>
>>> >
>>> >
>>> >
>>> >
>>> > --
>>> > Rafael Weingärtner
>>> >
>>>
>>> -- Bela Ban | http://www.jgroups.org
>>>
>>>
>>>
>>>
>>> --
>>> Rafael Weingärtner
>>>
>>
>> --
>> Bela Ban | http://www.jgroups.org
>>
>>
>
>
> --
> Rafael Weingärtner
>
--
Rafael Weingärtner
8 years
Keycloak SAML Invalid response
by Rémi GOYARD
Hi All,
I just tried to use the Auth0 service and it worked with Workplace by facebook (following this documentation : https://scontent-cdt1-1.xx.fbcdn.net/v/t39.2365-6/33246377_95188065163880...)
It seems that keycloak do not produce a Valid response for the email mapping, The above documentation precise the following configuration steps but I really don’t know how to map it In Keycloak :
{
"audience": "https://www.facebook.com/company/ID”,
"recipient": "https://workplace.facebook.com/work/saml.php”,
"mappings": { "email": "Email", },
"nameIdentifierFormat": "urn:oasis:names:tc:SAML:2.0:nameid-format:email”,
"nameIdentifierProbes”: [ "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" ],
}
I think that I need to precise the informations : "nameIdentifierFormat": "urn:oasis:names:tc:SAML:2.0:nameid-format:email”,
"nameIdentifierProbes”: [ "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" ],
Does anyone have ideas ?
Regards
Rémi
8 years
Strange Redirect Behavior When Upgrading to Version 2
by KevinO
I've finally go around to upgrading my keycloak server. Everything seems to
be working correctly until I try and view Users in the management portal.
When I try and view a users, it opens the right page but then immediately
redirects to a brute-force url. However, I do not have attack-detection
turned on.
Any idea what configurations I have incorrect.
Keycloak v 2.3.0.Final
http://localhost:8070/auth/admin/realms/External/attack-detection/brute-f...
23:33:44,681 INFO [org.wildfly.extension.undertow] (ServerService Thread
Pool -- 52) WFLYUT0021: Registered web context: /auth
23:33:44,703 INFO [org.jboss.as.server] (ServerService Thread Pool -- 47)
WFLYSRV0010: Deployed "keycloak-server.war" (runtime-name :
"keycloak-server.war")
23:33:44,763 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060:
Http management interface listening on http://172.27.0.4:9990/management
23:33:44,763 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051:
Admin console listening on http://172.27.0.4:9990
23:33:44,763 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025:
Keycloak 2.3.0.Final (WildFly Core 2.0.10.Final) started in 13304ms -
Started 425 of 801 services (542 services are lazy, passive or on-dem
and)
23:34:24,425 ERROR [org.jboss.resteasy.resteasy_jaxrs.i18n] (default
task-29) RESTEASY002010: Failed to execute: javax.ws.rs.NotFoundException:
RESTEASY003210: Could not find resource for full path: http://local
host:8070/auth/admin/realms/External/attack-detection/brute-force/usernames/10052
at
org.jboss.resteasy.core.registry.SegmentNode.match(SegmentNode.java:114)
at org.jboss.resteasy.core.registry.RootNode.match(RootNode.java:43)
at
org.jboss.resteasy.core.LocatorRegistry.getResourceInvoker(LocatorRegistry.java:79)
at
org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:129)
8 years
Tracking/auditing login events for GDPR compliance with Keycloak APIs?
by Max Demian
Hey everyone,
we have been happily using Keycloak to secure our recently developed
applications.
One of those applications requires users to give an informed consent when
first logging in by marking a checkbox on the Keycloak login page.
To comply with EU general data protection regulation, we need to track and
archive those events.
We are contemplating doing that from within Keycloak as the login event
system and provider APIs seemingly give us everything we need.
But before we commit to that, i would love the opinion of people better
versed in the internal Keycloak APIs, databases and when to use them.
Here is what we need to do:
For every initial login event (i.e. when the users identity is first linked
via our custom User Storage Federation Provider), we would have to store
the following information:
* The time of the event
* The username
* Ideally: custom information from the Keycloak login page, e.g. the url
and/or hash of the consent document the user just read and accepted
Here is what we already have:
* a custom Keycloak login theme
* a custom User Storage Federation provider
We are currently using the federation provider to send the event to an
external service but if we can cover this use case with Keycloak internal
APIs and databases, we would happily do so because we are moving towards
Keycloak as our central IDP.
The reason we are using an external service right now is because there we
have full control.
For instance, a likely future functionality is querying the API if the user
in question has already given his consent for given document.
Thanks for your time!
8 years
Question about RPT requests for all permissions on multiple clients
by David Erie (US)
Hello,
We're excited to be integrating Keycloak into our application suite, and I have some authorization questions I haven't been able to answer myself.
We have an unusual Single Page Application (SPA) architecture where our web server and our "data" server are separate processes. Further, we don't own the web server source code. Consequently, the SPA code running in the browser will need to perform fine-grained permission enforcement on its own.
I believe we can do this by sending the following type of request to get an RPT with all allowed permissions on the given resource server (I tested this and it works as expected):
curl -X POST \
http://${host}:${port}/auth/realms/${realm}/protocol/openid-connect/token \
-H "Authorization: Bearer ${access_token}" \
--data "grant_type=urn:ietf:params:oauth:grant-type:uma-ticket" \
--data "client_id={web_client_id}" \
--data "audience={resource_server_client_id}"
We would actually need to send two of these requests, one with the "web" resource server client ID, and the other with the "data" resource server client ID, because they would each own a set of resources that are accessed and whose permissions are enforced in the SPA.
Is this the recommended way to approach this problem?
Will this approach be supported in the long term (versus being deprecated for some reason related to the UMA 2.0 spec)?
Finally, what is the limit on the length of or number of permissions in an RPT?
Thank you,
Dave
8 years
