Custom AdminEvents
by Dmitry Telegin
Hi,
The org.keycloak.events.* subsystem could potentially be of great use
for KeyCloak extensions (providers), especially for combinations of
JpaEntityProvider+RealmResourceProvider. Imagine we've implemented a
custom entity + REST resource, and we want to log create/update/delete
events for our entity, and then analyze log records in the event viewer
inside admin console.
Unfortunately, the event subsystem in its current state is not very
useful for the above. This is due to resource types hardcoded into
org.keycloak.events.admin.ResourceType enum. When logging events for a
custom entity, the only option is to leave resource type empty:
adminEvent .operation(OperationType.CREATE) .resource
Path(uriInfo,
myEntity.getId()) .representation(rep) .success();
This will obviously create a log record without a "Resource Type"
value, which is definitely not of great use.
It would be nice to have extensible ResourceType. One of the approaches
to the extensible enum problem is described here: https://blogs.oracle.
com/darcy/entry/enums_and_mixins
I think this could be applied here with minimal modifications.
ResourceType would become an interface, and there would be introduced
something like StandardResourceType enum, which would implement built-
in resource types as enum keys, and store custom types in a static map-
backed registry. A public static method would be introduced so that
extension authors could register their own resource types. In the
future, when (I hope) registering providers will be done with
annotations, this could be even more simplified and made purely
declarative.
The same approach could be applied to extending login events
(potentially useful for custom authenticators etc.) What do you think?
If everybody is OK with it, I can go on with JIRA and a PR.
Cheers,
Dmitry
7 years, 6 months
KeycloakSecurityContext is always null
by Maurício Giacomini Penteado
Hello everyone,
I do not understanding how can I correctly use KeycloakSecurityContext on a Rest service to obtain access to keycloak tokens.
I tryed via httpServletRequest:
KeycloakSecurityContext session = (KeycloakSecurityContext) httpServletRequest.getAttribute(KeycloakSecurityContext.class.getName());
But, my KeycloakSecurityContext is always null.
I put the anotation @SecurityDomain("keycloak") on my class without success.
The authentication works perfectly but, the authorization is a problem. I am trying access to KeycloakSecurityContext to work with authorization.
If someone has a tip that can help me, please let me know.
Regards,
Mauricio.
7 years, 6 months
How to report security problem
by Hiroyuki Wada
Hello,
I have security concern in Keycloak server. It might be a vulnerability.
Where should I report this problem?
Regards,
--
Hiroyuki Wada,
Developer,
Nomura Research Institute, Ltd.
7 years, 6 months
Re: [keycloak-dev] Email custom header: KEYCLOAK-3605
by Nikolay Petrovski
Adding keycloak-dev
On Wed, Oct 12, 2016 at 3:13 PM, Nikolay Petrovski <to.petrovski(a)gmail.com>
wrote:
> Well, the use-case I reached is based on the fact that I rule 2 different
> Keycloak environments (lets call them "prod" and "test") from the same
> subnet + 1 Mail server on top.
>
> All emails are received from one and the same IP address, and in the Mail
> Server I have to figure out which Keycloak has sent the email so a specific
> rule will be applied (quarantine the emails from the "test" server for
> instance).
>
> Any idea how to distinguish emails sent from different Keycloak instances
> without using a custom email headers?
>
>
>
> On Wed, Oct 12, 2016 at 2:46 PM, Stian Thorgersen <sthorger(a)redhat.com>
> wrote:
>
>> I'm not convinced this is needed. What's the actual use-case?
>>
>> You could also just extend the built-in email sender and add the headers
>> there.
>>
>> On 12 October 2016 at 09:51, Nikolay Petrovski <to.petrovski(a)gmail.com>
>> wrote:
>>
>>> Hello, I would like to start working on
>>> https://issues.jboss.org/browse/KEYCLOAK-3605 - implementing custom
>>> X-headers for the outbound emails that Keycloak is sending.
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>>
>
7 years, 6 months
Re: [keycloak-dev] feature request
by Stian Thorgersen
[Adding list again]
Token based security relies on HTTPS for security. You need to use the
HTTPs domain name when you are contacting Keycloak. The HTTPs domain should
match the issuer of the domain.
On 11 October 2016 at 18:56, Mátyás Bachorecz <bachoreczm(a)gmail.com> wrote:
> My token audience does not match, because we request for a token via
> floating ip (openstack, like 10.xx.xx.xx), and would like to validate via
> private ip (like 192.168.xx.xx). So my question is how to solve this
> problem?
>
> There are two machines, one belongs to user, and on the other we running
> keycloak, and a client, which can validate token. But client only nows the
> private ip, and user can't access keycloak on private ip, cause he/she is
> not in that network.
>
> Br,
> Matyi
>
> On 11 October 2016 at 18:45, Stian Thorgersen <sthorger(a)redhat.com> wrote:
>
>> Rather than hacking Keycloak you should figure out why your token
>> audience doesn't match. For a token to be valid it has to been issued by
>> the same server URL and realm. It's an important check and we wouldn't
>> accept a feature that prevents it.
>>
>> On 11 October 2016 at 17:07, Mátyás Bachorecz <bachoreczm(a)gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> we have a multi-component project, and all components running in one
>>> machine, also Keycloak.
>>> We would like to obtain token via curl, and our components would like to
>>> validate it, but they can't, because we've got:
>>> "Token audience doesn't match domain. Token issuer is " +
>>> token.getIssuer()
>>> + ", but URL from configuration is " + realmUrl (RSATokenVerifier.java)
>>>
>>> I would like to implement a new feature: a new checkbox or something else
>>> to realm settings page, which can switch off the above mentioned feature.
>>> I've read that I should write an email here if I would like to implement
>>> something. Is it ok, or how it works?
>>>
>>> Br,
>>> Matyi
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>>
>
7 years, 6 months
Keycloak Clustering
by gambol
Hiya
I'm running Keycloak inside Kubernetes and attempting to get clustering
working. Multicasting is isn't available so i'm attempting to get the
gossip protocol working.
Version: 2.2.1-Final
I've changed the standalone-ha.xml
<subsystem xmlns="urn:jboss:domain:jgroups:4.0">
<channels default="ee">
<channel name="ee" stack="tcp"/>
</channels>
<stacks>
<stack name="udp">
<transport type="UDP" socket-binding="jgroups-udp"/>
<protocol type="PING"/>
<protocol type="MERGE3"/>
<protocol type="FD_SOCK" socket-binding="jgroups-udp-
fd"/>
<protocol type="FD_ALL"/>
<protocol type="VERIFY_SUSPECT"/>
<protocol type="pbcast.NAKACK2"/>
<protocol type="UNICAST3"/>
<protocol type="pbcast.STABLE"/>
<protocol type="pbcast.GMS"/>
<protocol type="UFC"/>
<protocol type="MFC"/>
<protocol type="FRAG2"/>
</stack>
<stack name="tcp">
<transport type="TCP" socket-binding="jgroups-tcp"/>
<protocol type="TCPGOSSIP">
<property name="initial_hosts">${env.
GOSSIP_ROUTER_HOST:127.0.0.1}[12001]</property>
</protocol>
<protocol type="MPING" socket-binding="jgroups-mping"/>
<protocol type="MERGE3"/>
<protocol type="FD_SOCK" socket-binding="jgroups-tcp-
fd"/>
<protocol type="FD"/>
<protocol type="VERIFY_SUSPECT"/>
<protocol type="pbcast.NAKACK2"/>
<protocol type="UNICAST3"/>
<protocol type="pbcast.STABLE"/>
<protocol type="pbcast.GMS"/>
<protocol type="MFC"/>
<protocol type="FRAG2"/>
</stack>
</stacks>
The gossip router service were using is jboss/jgroups-gossip
12:40:53,114 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
(MSC service thread 1-8) ISPN000078: Starting JGroups channel ejb
12:40:53,114 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
(MSC service thread 1-6) ISPN000078: Starting JGroups channel server
12:40:53,114 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
(MSC service thread 1-1) ISPN000078: Starting JGroups channel hibernate
12:40:53,114 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
(MSC service thread 1-4) ISPN000078: Starting JGroups channel keycloak
12:40:53,114 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
(MSC service thread 1-7) ISPN000078: Starting JGroups channel web
12:40:53,216 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
(MSC service thread 1-8) ISPN000094: Received new cluster view for channel
ejb: [keycloak-4062290770-sn7jb|0] (1) [keycloak-4062290770-sn7jb]
12:40:53,216 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
(MSC service thread 1-1) ISPN000094: Received new cluster view for channel
hibernate: [keycloak-4062290770-sn7jb|0] (1) [keycloak-4062290770-sn7jb]
12:40:53,216 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
(MSC service thread 1-6) ISPN000094: Received new cluster view for channel
server: [keycloak-4062290770-sn7jb|0] (1) [keycloak-4062290770-sn7jb]
12:40:53,217 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
(MSC service thread 1-4) ISPN000094: Received new cluster view for channel
keycloak: [keycloak-4062290770-sn7jb|0] (1) [keycloak-4062290770-sn7jb]
12:40:53,216 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
(MSC service thread 1-7) ISPN000094: Received new cluster view for channel
web: [keycloak-4062290770-sn7jb|0] (1) [keycloak-4062290770-sn7jb]
12:40:53,221 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
(MSC service thread 1-4) ISPN000079: Channel keycloak local address is
keycloak-4062290770-sn7jb, physical addresses are [10.10.69.4:7600]
12:40:53,221 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
(MSC service thread 1-6) ISPN000079: Channel server local address is
keycloak-4062290770-sn7jb, physical addresses are [10.10.69.4:7600]
12:40:53,221 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
(MSC service thread 1-1) ISPN000079: Channel hibernate local address is
keycloak-4062290770-sn7jb, physical addresses are [10.10.69.4:7600]
12:40:53,221 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
(MSC service thread 1-7) ISPN000079: Channel web local address is
keycloak-4062290770-sn7jb, physical addresses are [10.10.69.4:7600]
12:40:53,221 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
(MSC service thread 1-8) ISPN000079: Channel ejb local address is
keycloak-4062290770-sn7jb, physical addresses are [10.10.69.4:7600]
12:40:53,314 INFO [org.infinispan.factories.GlobalComponentRegistry] (MSC
service thread 1-6) ISPN000128: Infinispan version: Infinispan 'Mahou'
8.1.0.Final
12:40:53,314 INFO [org.infinispan.factories.GlobalComponentRegistry] (MSC
service thread 1-4) ISPN000128: Infinispan version: Infinispan 'Mahou'
8.1.0.Final
12:40:53,314 INFO [org.infinispan.factories.GlobalComponentRegistry] (MSC
service thread 1-8) ISPN000128: Infinispan version: Infinispan 'Mahou'
8.1.0.Final
12:40:53,314 INFO [org.infinispan.factories.GlobalComponentRegistry] (MSC
service thread 1-1) ISPN000128: Infinispan version: Infinispan 'Mahou'
8.1.0.Final
12:40:55,110 INFO [org.jboss.as.clustering.infinispan] (ServerService
Thread Pool -- 60) WFLYCLINF0002: Started users cache from keycloak
container
12:40:55,111 INFO [org.jboss.as.clustering.infinispan] (ServerService
Thread Pool -- 52) WFLYCLINF0002: Started realms cache from keycloak
container
12:40:55,114 INFO [org.jboss.as.clustering.infinispan] (ServerService
Thread Pool -- 56) WFLYCLINF0002: Started sessions cache from keycloak
container
12:40:55,113 INFO [org.jboss.as.clustering.infinispan] (ServerService
Thread Pool -- 54) WFLYCLINF0002: Started work cache from keycloak container
12:40:55,117 INFO [org.jboss.as.clustering.infinispan] (ServerService
Thread Pool -- 59) WFLYCLINF0002: Started offlineSessions cache from
keycloak container
12:40:55,117 INFO [org.jboss.as.clustering.infinispan] (ServerService
Thread Pool -- 58) WFLYCLINF0002: Started authorization cache from keycloak
container
12:40:55,115 INFO [org.jboss.as.clustering.infinispan] (ServerService
Thread Pool -- 55) WFLYCLINF0002: Started loginFailures cache from keycloak
container
12:40:58,330 INFO [org.keycloak.services] (ServerService Thread Pool --
58) KC-SERVICES0001: Loading config from standalone.xml or domain.xml
12:41:00,911 INFO [org.jboss.as.clustering.infinispan] (ServerService
Thread Pool -- 58) WFLYCLINF0002: Started userRevisions cache from keycloak
container
12:41:00,921 INFO [org.jboss.as.clustering.infinispan] (ServerService
Thread Pool -- 58) WFLYCLINF0002: Started realmRevisions cache from
keycloak container
But no matter what i seem to change ... I can't multiple pods to see the
membership ... Note, i don't even see a reference to the gossip route
itself, so i'm not entirely sure it's being used.
Are there any working examples or perhaps something obvious i'm missing?
Rohith
7 years, 6 months
feature request
by Mátyás Bachorecz
Hi,
we have a multi-component project, and all components running in one
machine, also Keycloak.
We would like to obtain token via curl, and our components would like to
validate it, but they can't, because we've got:
"Token audience doesn't match domain. Token issuer is " + token.getIssuer()
+ ", but URL from configuration is " + realmUrl (RSATokenVerifier.java)
I would like to implement a new feature: a new checkbox or something else
to realm settings page, which can switch off the above mentioned feature.
I've read that I should write an email here if I would like to implement
something. Is it ok, or how it works?
Br,
Matyi
7 years, 6 months
