Support oauth2 client credentials flow from hermes to subscribers

[sslavic]

Access to subscriber endpoints can be protected. Subscriber should be able to identify Hermes from any other client making request. oauth2, and client credentials grant is one popular way how access to subscriber endpoint can be protected. Please build appropriate support in Hermes.

For a start it could be enough to add appropriate logic in Hermes Consumers, with support for configuring whether oauth2 is enabled/disabled, and if enabled also configure single/global authorization/token issuing endpoint, client credentials (client id and client secret), and scope to be requested. One should be able to provide these configuration options through configuration file, Java system properties and environment variables. Hermes Consumers should handle appropriately fact that tokens have TTL/expire, e.g. by renewing token.

[adamdubiel]

In Allegro we chose other form of authentication - we will use mutual SSL to:

• see if i can talk with the other host and he is who he says he is
• host can decide if it trusts Hermes

This has some advantages, mainly it operates at connection level, so it does not add up to the overhead (we are talking about migrating to http/2 for better streaming experience in this context).

However, this is our specific solution and i agree we should provide support for some widely used protocols. I can't guarantee any specific date when this kind of support will be added. We would also rely on you testing it with some real traffic and in longer term, as we won't run it on our production, unlike all the other features, which we perceive as ready to use for external clients once we run it on production.

[sslavic]

HTTPS client authentication is interesting for us as well, and yes has benefits over oauth2 when it comes to performance/latency. Was fix for #313 enough to have working client authentication? Is it documented what needs to be configured?

Is there a ticket on GitHub for HTTP/2 support?

Nevertheless, would be great to have more options (oauth2, basic auth), when HTTPS client authentication is not possible.

[adamdubiel]

No, #313 was only what you requested - a simple https support, without any sophisticated authorization certificate validation.

We also don't have any http/2 open issue here yet. I think that we would be able to start working on authorization specific matters (http/2 and OAuth/Basic) starting from the next quarter (April), as we still have some requests which are more urgent from our point of view.

[dankraw]

@sslavic would you be satisfied if the Consumers module implemented similar Resource Owner Password Credentials Grant?
It looks more interesting from our point of view.

In this case [client_id, client_secret, username, password, scope (optional), grant_type: password] would be sent to the token request endpoint. Both flows are very similar, it is possible to have a single request needed to access the token.

This somehow extends the client credentials grant flow as it requires the client (Hermes) to be authenticated using provided client_id / secret, but asks for the user (subscriber) token in the end. The returned Bearer token can then be used to access the resource, i.e. to send messages to the subscriber.

The token provider would be configurable per subscription as there might be various systems connected to Hermes.

The idea from a bird's eye view would be:

1. [Admin] Adding a number of OAuth providers to Hermes, requires client_id, client_secret, token_endpoint.
2. [Subscriber] Enabling OAuth for specific subscription, choosing one of the providers available and setting username, password for resource access (resource then will be accessed with header Authentication: Bearer <token>).

What I understand it would be enough for you to have point 1. resolved (no specific resource owner credentials required) and using the client token for resource access (header Authentication: Basic <token>)?

[adamdubiel]

Released in 0.8.11 version - @sslavic let us know if the concept is ok for you and could be used in your case.

[sslavic]

Thank you very much guys for the effort and support! We will have a look and get back to you.