[keycloak-user] Access tokens in Queue based systems

[Pedro Igor Silva]

The clients are then confidential and I guess I can assume they can keep
their secret secure. In addition to that, if you have mechanisms to proof
that the sender is actually the holder of the token, you can avoid replay
attacks.

Keycloak supports mTLS [1], I don't know much about Rabbit and how you can
authenticate/authorize using bearer tokens, or how to use TLS. But maybe
this can help.

[1] https://tools.ietf.org/html/draft-ietf-oauth-mtls-13

On Fri, Aug 16, 2019 at 9:21 AM Pavel Micka <Pavel.Micka at zoomint.com> wrote:

> Currently we are using credentials for accessing the broker (and we are
> investigating, if we can do more). The clients are generally microservices,
> the messages are essentially events (in sense of event streaming, so small
> chages of data records).
>
> If we are talking about KC level, then they have service accounts.
>
>
>
> Pavel
>
>
>
>
>
> *From:* Pedro Igor Silva <psilva at redhat.com>
> *Sent:* Friday, August 16, 2019 2:01 PM
> *To:* Pavel Micka <Pavel.Micka at zoomint.com>
> *Cc:* keycloak-user at lists.jboss.org
> *Subject:* Re: [keycloak-user] Access tokens in Queue based systems
>
>
>
> Hi,
>
>
>
> Out of curiosity:
>
>
>
> * How authentication in Rabbit is being done?
>
> * What types of clients are sending messages?
>
> * How these clients are obtaining access tokens (grant types)?
>
>
>
> Regards.
>
> Pedro Igor
>
>
>
> On Tue, Aug 13, 2019 at 4:14 AM Pavel Micka <Pavel.Micka at zoomint.com>
> wrote:
>
> Hello everyone,
>
> We are using Keycloak (OIDC) in our system and it has proven to be a great
> solution for http based communication. But we have slight issue with
> figuring out how to correctly pass the access tokens through queues. The
> point is that we have a partially a streaming system and we want to make
> sure that if an attacker manages to send the messages to Rabbit, the
> messages will not be authorized by clients. That is the theory.
>
> We can send the access tokens through the queue... but the messages may
> rot in the queue for quite some time (our SLA is in hours), so that would
> mean long validity of the token (and that may cause issues in case the
> token is somehow leaked).
>
> Better option would be to have a long validity token, but scope it to the
> content of the message. But you know...streaming application... there can
> be thousands of messages a second. And that may cause big scalability
> issues when bombarding keycloak for each and every message in the system.
>
> Is there some better approach with OIDC? Or should I look on some
> additional non-KC solution?
>
> Thanks!
>
> Pavel
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>