OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

amqp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [amqp] AMQP CBS Status


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.

 

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?

 

 

 

 

cid:image002.jpg@01CD8B42.2D0DE480

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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]