[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [amqp] AMQP CBS Status
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
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>
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:
-- _____________________________________________________________________________ |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]