OAuth 2.0 Authorisation

1,066 views
Skip to first unread message

Daniil Fedotov

unread,
Dec 29, 2015, 6:37:44 AM12/29/15
to rabbitmq-users
Right now I'm thinking on implementing OAuth 2.0 authorisation in RabbitMQ and have several implementation ideas. 
RabbitMQ server work as `resource server` in OAuth model.
Some other server work as `authorisation server`.
Client can access RabbitMQ (by web_stomp plugin for example) using `access_token` acquired from authorisation server.

Client and authorisation server communicate any way described in OAuth protocol.

What I'm trying to figure out right now is the way authorisation server and RabbitMQ server will communicate with each other and exchange token and permission information.

1. Authorisation server is a plugin, works on same machine as RabbitMQ, store tokens in same database. Can be done 'default' option.
2. Using separate authorisation server. 
    2.1 Authorisation server tells RabbitMQ plugin about new tokens, their scopes and expirations.
    2.2 Authorisation server provide API for RabbitMQ to ask if specific token have some permissions.

2-nd option requires some secure connection between authorisation server and RabbitMQ. It also requires authorisation server to have specific API to push or check tokens and permissions.

Want to know what you think.

Domenico Rotondi

unread,
Dec 29, 2015, 9:12:15 AM12/29/15
to rabbitm...@googlegroups.com
Hi Daniil,
the logic behind OAuth is that a user interactively obtain an access token from the AuthZ server that grants him/her access to a resource.
In my opinion this logic is not suitable for RabbitMQ where normally publishers or subscribers are not directly managed by end-users.
A most suitable approach can be based on capabilities or Google macaroons (http://macaroons.io/).
In these approach access to a reosurce (e.g., a RabbitMQ queue) is tied to the possession of a suitable access token whose "originator" is trusted by the RabbitMQ token-enhanced authorization service.

The mechanism is, roughly speaking, the following:
  • the resource manager (e.g., RabbitMQ) trust a resource owner (e.g., the RabbitMQ administrator)
  • the resource owner (e.g., a RabbitMQ administrator) generate an access token granting a specific access right (e.g., connect to queue X) to a given resource (e.g., queue X) to a subject (e.g., Alice)
  • the reosurce owner makes the access token available to the granted subject (Alice) using suitable means (e.g., via email, a web site, ...)
  • the granted subject (e.g. Alice) presents the access token, with an ownership proof; when connecting to the resource manager (e.g., Alice submit the token she received when connecting to RabbitMQ)
  • the reosurce manager checks the validity of the token and the proof of ownership and allows or denies access based on the check outcomes. N.B.: the resource manager doesn't need to authenticate the subject (e.g., Alice) nor it has to trust 3rd parties apart from trusting the resource owner
The proof of ownership can be the simple possession of the token (which is the basic mechanism in Google macaroons), or be based on a digital signature of the access request.
The above mechanism can also support delegation of access rights; for example Alice can create, on the basis of her access token, a new token for Bob witouth having to interact with the resource manager (e.g. RabbitMQ) or the resource manager have to trust Bob.

We did some work a couple of years ago to use capabilities with RabbitMQ; you can find details in:
  • “IoT@Work Automation Middleware System Design and Architecture”, in Proc. 17th IEEE International Conference on Emerging Technologies & Factory Automation (ETFA 2012), September 2012
  • “A capability-based security approach to manage access control in the Internet of Things”, Mathematical and Computer Modelling Journal, ISSN 0895-7177, 10.1016/j.mcm.2013.02.006

Hoping this helps. My best wishes for a fruitful 2016
   Domenico



--
You received this message because you are subscribed to the Google Groups "rabbitmq-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
rabbitmq-user...@googlegroups.com.
To post to this group, send email to
rabbitm...@googlegroups.com.
For more options, visit
https://groups.google.com/d/optout.

Michael Klishin

unread,
Dec 29, 2015, 9:14:14 AM12/29/15
to rabbitm...@googlegroups.com, Domenico Rotondi
On 29 December 2015 at 17:12:15, Domenico Rotondi (d.ro...@computer.org) wrote:
> the logic behind OAuth is that a user interactively obtain an
> access token from the AuthZ server that grants him/her access
> to a resource.

If so, why the "Implicit" authorisation grant type is in the spec?

> In my opinion this logic is not suitable for RabbitMQ where normally
> publishers or subscribers are not directly managed by end-users.

"end users" in case of RabbitMQ means "developers." 
--
MK

Staff Software Engineer, Pivotal/RabbitMQ


Michael Klishin

unread,
Dec 29, 2015, 9:18:50 AM12/29/15
to rabbitm...@googlegroups.com, Domenico Rotondi
 On 29 December 2015 at 17:12:15, Domenico Rotondi (d.ro...@computer.org) wrote:
Domenico,

Thank you for your input. We did read the spec. The question is now how OAuth 2 works
but what parts should be provided by RabbitMQ, for what use cases.

It's not unheard of for Web-based apps to use OAuth 2 tokens obtained
implicitly. It still provides almost all the benefits listed as motivations in the spec over username/password pairs.

However, some may want to use their own authorisation server. Others want a built-in thing.

That's the real question: what should the scope of OAuth 2 support be. We hear features requests
for it every so often but, of course, pretty much nobody provides any specifics on how things should
work.

Domenico Rotondi

unread,
Dec 29, 2015, 9:53:42 AM12/29/15
to rabbitm...@googlegroups.com
Hi Michael,
quite disputable that developers are end users.
If I develop a solution based on RabbitMQ (for example forcollecting and analyzing
events related to home security), I'm the developer while the end-users are the people
using my security solution in their houses and their friends accessing thier houses.
So they have to configure the system and, for token based access control (including
OAuth) they have to generate the tokens and all the other stuff not myself.

Additionally, the normal OAth usage is that the requesting user has to interact with
the system to generate the access token (and the interaction is normally performed
using a web browser).
So how can the owner of a house using my RabbitMQ based security solution can
generate and pass the token to the devices (e.g., smart door lock) that have to publish
events to RabbitMQ?

BTW: to my knowledge OAuth still doesn't support delegation of rights.
Ciao
Domenico
> --
> MK
>
> Staff Software Engineer, Pivotal/RabbitMQ
>
>
> --
> You received this message because you are subscribed to the Google Groups "rabbitmq-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to rabbitmq-user...@googlegroups.com.
> To post to this group, send an email to rabbitm...@googlegroups.com.

Michael Klishin

unread,
Dec 29, 2015, 9:59:57 AM12/29/15
to rabbitm...@googlegroups.com, Domenico Rotondi
On 29 December 2015 at 17:53:41, Domenico Rotondi (d.ro...@computer.org) wrote:
> So they have to configure the system and, for token based access
> control (including
> OAuth) they have to generate the tokens and all the other stuff
> not myself.

I don't think that in most systems that use RabbitMQ end users get a separate user account.
So yes, our end users are developers more often than not .

> Additionally, the normal OAth usage is that the requesting user
> has to interact with
> the system to generate the access token (and the interaction
> is normally performed
> using a web browser).
> So how can the owner of a house using my RabbitMQ based security
> solution can
> generate and pass the token to the devices (e.g., smart door lock)
> that have to publish
> events to RabbitMQ?

As long as the "implicit" grant authorisation method is used, any way they please.

Daniil Fedotov

unread,
Dec 29, 2015, 10:44:08 AM12/29/15
to rabbitmq-users, D.Ro...@computer.org, d.ro...@computer.org


On Tuesday, December 29, 2015 at 2:53:42 PM UTC, Domenico Rotondi wrote:
On 29 Dec 2015 at 17:13, Michael Klishin wrote:

> On 29 December 2015 at 17:12:15, Domenico Rotondi (d.ro...@computer.org) wrote:
If I develop a solution based on RabbitMQ (for example forcollecting and analyzing
events related to home security), I'm the developer while the end-users are the people
using my security solution in their houses and their friends accessing thier houses.
So they have to configure the system and, for token based access control (including
OAuth) they have to generate the tokens and all the other stuff not myself.  
Additionally, the normal OAth usage is that the requesting user has to interact with
the system to generate the access token (and the interaction is normally performed
using a web browser).
So how can the owner of a house using my RabbitMQ based security solution can
generate and pass the token to the devices (e.g., smart door lock) that have to publish
events to RabbitMQ?

BTW: to my knowledge OAuth still doesn't support delegation of rights.
Ciao

In this case capabilities is more suitable, I guess. 
But still token is generated by authorisation server and not owner himself and only require owner approve. So owner can grant access to new device on setup via auth server, while device have ability to keep it's access token up-to-date (via refresh tokens for exmaple)


Daniil Fedotov

unread,
Dec 29, 2015, 10:53:33 AM12/29/15
to rabbitmq-users, d.ro...@computer.org

> Additionally, the normal OAth usage is that the requesting user
> has to interact with
> the system to generate the access token (and the interaction
> is normally performed
> using a web browser).
> So how can the owner of a house using my RabbitMQ based security
> solution can
> generate and pass the token to the devices (e.g., smart door lock)
> that have to publish
> events to RabbitMQ?

As long as the "implicit" grant authorisation method is used, any way they please.

Implicit grant is not necessary, client can use any way to get auth token. Since client obtain auth token it can pass it to devices or anywhere (by secure channel of course).

Domenico Rotondi

unread,
Dec 29, 2015, 2:20:08 PM12/29/15
to rabbitm...@googlegroups.com, D.Ro...@computer.org, d.ro...@computer.org
See comment inline.
Ciao
   Domenico



On 29 Dec 2015 at 7:44, Daniil Fedotov wrote:



On Tuesday, December 29, 2015 at 2:53:42 PM UTC, Domenico Rotondi wrote:
On 29 Dec 2015 at 17:13, Michael Klishin wrote:

> On 29 December 2015 at 17:12:15, Domenico Rotondi (

If I develop a solution based on RabbitMQ (for example forcollecting and analyzing
events related to home security), I'm the developer while the end-users are the people
using my security solution in their houses and their friends accessing thier houses.
So they have to configure the system and, for token based access control (including
OAuth) they have to generate the tokens and all the other stuff not myself. 
Additionally, the normal OAth usage is that the requesting user has to interact with
the system to generate the access token (and the interaction is normally performed
using a web browser).
So how can the owner of a house using my RabbitMQ based security solution can
generate and pass the token to the devices (e.g., smart door lock) that have to publish
events to RabbitMQ?

BTW: to my knowledge OAuth still doesn't support delegation of rights.
Ciao

In this case capabilities is more suitable, I guess. 
But still token is generated by authorisation server and not owner himself and only require owner approve. So owner can grant access to new device on setup via auth server, while device have ability to keep it's access token up-to-date (via refresh tokens for exmaple)

Access tokens not necessarily must be created by an authorization server.
With refrence to the RabbitMQ based house security example reported above, access tokens can be used to control which sensors (e.g., door locks) are allowed to connect to RabbitMQ and publish events (e.g., door opening, door closing).
So the resource to be protected is one or more RabbitMQ Exchanges to which these sensors can sumbit events.
Suppose RabbitMQ authorization mechanism has been enhanced to support capabilities (or Google macaroons) and I'm the owner of a house in which the RabbitMQ based alarm system has been installed.
What I have to do is:
  • configure RabbitMQ so that it trusts capabilities (or macaroons) I generated
  • generate a capability (or a macaroon) for each sensor that needs to publish events via RabbitMQ
  • provide the capability (or macaroon) to each sensor
That's it! The way I generate capabilities (or macaroons) doesn't matter (I can even use an app on my smart phone), nor do I have to set up an authorization service to which the devices have to connect in order to get an access token.
Of course there could be the need to refresh those access tokens, but this is something that doesn't not affect the way RabbitMQ has to the operate or be configured. On the RabbitMQ side the only real constraint is that it trusts the creator of the tokens (e.g., because my token signing certificate is trusted by it) and RabbitMQ can perform all token's checking locally without any need to interact with other services like an authorization service.
Ciao
   Domenico
 

--
You received this message because you are subscribed to the Google Groups "rabbitmq-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
rabbitmq-user...@googlegroups.com
.
To post to this group, send email to
rabbitm...@googlegroups.com.
For more options, visit
https://groups.google.com/d/optout.
Reply all
Reply to author
Forward
0 new messages