Re: [amqp] AMQP CBS Status

[Rob Godfrey <rgodfrey@redhat.com>]

On Fri, 8 Feb 2019 at 16:34, Clemens Vasters <clemensv@microsoft.com> wrote:

For this spec, thereâs no difference whether you need one token or many. Both cases are real. We have scenarios where the audience of the token is the entire container, and we have scenarios where the audience is a node or are some nodes in that container, e.g. a client may only be authorized to read from queue A and send to queue B, and otherwise interact with nothing in the container.

Sure - but my point here is that if you need to know enough detail about the implementation of the authz system to know you need to request many different tokens, for different purposes... then this standardisation is pretty pointless, all of the complexity is already pushed onto the application programmer, they still need to be exposed to putToken() and deleteToken() methods and to know when in their messaging activity they need to call these. Writing a generic AMQP client you can't know when to intercept the application action and inject (through some vendor specific plugin) a request for a new token and then put that to $cbs at the AMQP server. If we could define a set of actions that might require new tokens (even if in some implementations it would not) and what the parameters needed are (node name, send/receive, ???) then the details could be abstracted from the application programmer. As is the only knowledge we are really abstracting is the name of the node, which seems like a very small part of the problem.

-- RobÂÂ

Â

Accordingly, you can have a generic token provider at the connection level and/or at the entity client level and those can then interact with the $cbs endpoint as appropriate for their scope, and do so even independently for when they acquire refresh tokens.

Â

From: Rob Godfrey <rgodfrey@redhat.com>
Sent: Friday, February 8, 2019 4:29 PM
To: Clemens Vasters <clemensv@microsoft.com>
Cc: amqp@lists.oasis-open.org
Subject: Re: [amqp] AMQP CBS Status

Â

Â

Â

On Fri, 8 Feb 2019 at 16:21, Clemens Vasters <clemensv@microsoft.com> wrote:

The client library that acquires the tokens will typically be in the know of when a new token is required, because the expiration is stamped onto the token. Thatâs the OAuth token provider, though, and therefore itâs already defined over there (refresh token acquisition plus the expiration on the chosen token format) and out of scope for this spec. Once the client has a new token, it needs to flow it into the AMQP container such that the AMQP container can use it for an ongoing link and that is this spec.

Â

So, yes, the client that uses these standards in concert is indeed quite generic and driven, for instance, by the expiration policy set in the token issuer.

Â

Which is fine if we are only talking about a single token per connection, but the way the spec is written it seems to me there is an expectation of multiple tokens (that refer to different claims?) and that if that is the case, the application programmer is still going to have to trigger the request for additional tokens based on their knowledge of the system they are communicating with. If the expected case is that you have a single token with all your claims, and that this needs periodic refreshing, then I can clearly see the standardisation benefit.

Â

-- Rob

Â

Â

From: Rob Godfrey <rgodfrey@redhat.com>
Sent: Friday, February 8, 2019 4:14 PM
To: Clemens Vasters <clemensv@microsoft.com>
Cc: amqp@lists.oasis-open.org
Subject: Re: [amqp] AMQP CBS Status

Â

Â

Â

On Fri, 8 Feb 2019 at 14:54, Clemens Vasters <clemensv@microsoft.com> wrote:

Weâre using this mechanism with three different products (Event Hubs, Service Bus, and IoT Hub) and with two different tokens formats (SWT and JWT) and two different authorization models (token-associated rights and RBAC) and four AuthZ authorities (ACS, AAD, IoT Hub, SAS) and several language implementations, and we benefit greatly from having a shared code-base using this spec thatâs able to do the three things that I enumerate below and does them in a consistent manner, in spite of the AuthZ relationships being different.

Â

Sure - I guess I'm just hoping for a bit more, such that the level of standardisation is amenable to some sort of generic code that could be introduced into client libraries. As is it seems to me that the application programmer would still need to be in control of managing when to send tokens (both in terms of when they are initially required, and when they are refreshed) as well as knowledge about how to acquire them (which in principle is probably fine if there was some sort of way to "plug in" such token acquisition logic). As is I don't see how this standardisation would lead to generic client libraries adding any sort of meaningful support for this technique (the most the could do is add some trivial convenience API around put-token / delete-token). Having some way to codify when a token needs to be updated by, or determining that maximally new tokens may be required on attach, or on sending to a new destination, would give the opportunity to provide some sort of pluggable API into the client, removing the burden on the application programmer knowing the precise details of when new tokens need to be sent.

Â

-- Rob

Â

Â

Whether the node name is â$cbsâ isnât essential. We could communicate the name in a connection property. What matters is that the interactions described herein are consistently implementable, because theyâre the same across the variety of mechanisms weâre using them with, and products that want to do any of the thing in the list below need to have a mechanism for it and this is one.

Â

From: Rob Godfrey <rgodfrey@redhat.com>
Sent: Friday, February 8, 2019 2:25 PM
To: Clemens Vasters <clemensv@microsoft.com>
Cc: amqp@lists.oasis-open.org
Subject: Re: [amqp] AMQP CBS Status

Â

Â

Â

On Fri, 8 Feb 2019 at 14:12, Clemens Vasters <clemensv@microsoft.com> wrote:

In the underlying user story, I go to an authorization service and acquire a token and I need to pass that token to a broker for it to grant me access to a queue and I periodically need to renew that token as well.

Â

The interaction with the STS is covered by OpenID (for establishing identity) and OAuth (for acquiring the authorization token) and neither of these specs actually mandates a particular token format: https://oauth.net/2/bearer-tokens/

Â

What we do here, is to take that opaque token and associate that with a node in an AMQP container in a standardized fashion, either in the SASL handshake or for initial configuration or for renewal via a management node. None of that depends on the token format.

Â

Thereâs a relationship between the authorization server and the AMQP node in that the node needs to understand the token and its claims and also needs to be able to verify the signature. That relationship depends on which standards suite you pick for authorization and issued tokens. The currently popular combination is OAuth and JWTs. You can also use WS-Trust and SAML or you can rely on PKI with SAML. Which is the claims in the token then ultimately grants you access is a policy matter and there are standard policy languages for that, but largely simple rules mechanisms.

Â

Even though that part has many options and those are even still evolving, whatâs common â and that is what this spec is about â is (a) that these tokens usually expire and that their lifetime is often shorter than a connection lifetime and therefore require renewal without disturbing ongoing transfers and (b) and that you might need different tokens for different link targets when youâve got an external authorization service that issues tokens at the granularity of an AMQP node.

Â

The status quo is that without CBS

Â

• you canât establish per-link authorization contexts and
• you canât renew tokens for those contexts while the link/connection exists and
• you canât carry multiple tokens for different link targets in a SASL preamble

Â

Â

Having such a node is valuable if you are using this form of authorisation, but given that how frequently you need to send tokens, for which operations, and what form those tokens take are all knowledge that needs to be determined out of bounds, and will be server implementation specific, what benefit does standardising the name of the AMQP node bring?... if all the associated syntax and semantics are implementation specific, then is it any benefit to have the node named $cbs rather than acme_com_node or whatever? As it stands it seems to me that the application programmer will still need to know the details of the server it is connecting to (what operations require tokens, how frequently they need to be refreshed, etc.) and so standardising on a node name to send them to isn't really bringing that much benefit. As a client library writer I don't think there is enough information here even to define some sort of plug-in architecture where different vendors could provide some plugin that works with their service for authorization (and keeping the details opaque) while otherwise maintaining a standard messaging API.

Â

-- Rob

Â

The standard does that. What is doesnât do is to constrain the authorization context model and permissions topology, just as we donât prescribe a model and topology for messaging entities.

Â

From: Rob Godfrey <rgodfrey@redhat.com>
Sent: Friday, February 8, 2019 1:50 PM
To: Clemens Vasters <clemensv@microsoft.com>
Cc: amqp@lists.oasis-open.org
Subject: Re: [amqp] AMQP CBS Status

Â

The issue I have then is that I'm not completely sure of the value in standardisation. Since the client has to be aware of the server/service it is communicating with, then I don't see a huge value in standardising on a mechanism for the transfer. We would define where you need to go to present you papers, but not which papers you would need to fill in nor what information to provide, nor when you need to present them. If I'm implementing a general purpose client, how does the information in this specification help me, and if I'm writing a client against a specific server implementation then why do I care?

Â

-- Rob

Â

On Fri, 8 Feb 2019 at 13:38, Clemens Vasters <clemensv@microsoft.com> wrote:

Tokens are generally opaque and are usually based on some prior OOB agreement and exchange of secrets between the relying party (token target) and the issuer. I really donât want to be more specific in the spec than we are here, since itâs not this mechanismâs business to know. The mechanism simply moves opaque stuff.

Â

Regarding the token types, the spec enumerates âcommon token typesâ but that doesnât preclude using others and doesnât mean you need to support any of them and maybe we should clarify that.

Â

From: Rob Godfrey <rgodfrey@redhat.com>
Sent: Friday, February 8, 2019 1:29 PM
To: Clemens Vasters <clemensv@microsoft.com>
Cc: amqp@lists.oasis-open.org
Subject: Re: [amqp] AMQP CBS Status

Â

Â

Â

On Fri, 8 Feb 2019 at 13:09, Clemens Vasters <clemensv@microsoft.com> wrote:

https://www.oasis-open.org/apps/org/workgroup/amqp/document.php?document_id=62097

Â

Iâve looked through the AMQP CBS spec once again and Iâm actually quite happy with it as it stands for the purpose of client authorization at a container, and I propose we start the process of turning it into a committee spec.

Â

Â

It's been a long time since I looked at this... my main question is really whether we need to go into more detail about the form of the tokens. The document says things like "Before the Client establishes a link or sends messages to âq1â, it puts a token with the appropriate claims conferring âsendâ permission to âq1â on the CBS Node, and verifies its successful disposition. Tokens can be put at any time, and expiring tokens can be replaced at any time." What is "appropriate", how does the client know the form of token required? Moreover we define at least three token types - are we saying that every party must support all three, any one of the three, none at all? How is that information conveyed.

Â

-- RobÂ

Â

I believe we will then need a further complementary spec for authorization in federation scenarios that answers questions like:

Â

• How does authorization work for establishing links through intermediaries? Is there a token attached to the link and is that being propagated?

• At the intermediary?
• At the ultimate link destination?

• How does authorization work for message based routing? Is there a token attached to the message?

• At the intermediary?
• At the ultimate message destination?

• How do we attach tokens to AMQP URIs as a parameters?

Â

Â

Â

Â

Clemens Vasters Messaging Platform Architect Microsoft Azure Ã+49 151 44063557 * clemensv@microsoft.com  European Microsoft Innovation Center GmbH |ÂGewÃrzmÃhlstrasse 11Â| 80539 Munich| Germany GeschÃftsfÃhrer/General Managers: Keith Dolliver, Benjamin O. Orndorff Amtsgericht Aachen, HRB 12066

Â

Â

Â

--

_____________________________________________________________________________

Red Hat GmbH,Âwww.de.redhat.com,
Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham, Michael O'Neill

Â

--

_____________________________________________________________________________

Red Hat GmbH,Âwww.de.redhat.com,
Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham, Michael O'Neill

Â

--

_____________________________________________________________________________

Red Hat GmbH,Âwww.de.redhat.com,
Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham, Michael O'Neill

Â

--

_____________________________________________________________________________

Red Hat GmbH,Âwww.de.redhat.com,
Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham, Michael O'Neill

Â

--

_____________________________________________________________________________

Red Hat GmbH,Âwww.de.redhat.com,
Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham, Michael O'Neill

--

_____________________________________________________________________________

Red Hat GmbH,Âwww.de.redhat.com,
Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham, Michael O'Neill