[OASIS Issue Tracker] (AMQP-109) Scope (connection/session) of CBS token

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ https://issues.oasis-open.org/browse/AMQP-109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=66919#comment-66919 ] 

Clemens Vasters commented on AMQP-109:
--------------------------------------

SASL is connection scoped. There's no security model in AMQP that is scoped to the session. Therefore CBS is also scoped to the connection. 

I agree that it might be useful to have a further security layer, but I don't think it's in scope for this particular spec.

What I would find truly useful is a further security layer at the link layer, which would allow security contexts to be "routable" and recoverable. 

There's arguably a hole in the overall security story in that links are not firmly tied up to the connection security context and how to tie them back to a new connection context. It's therefore possible that with implementations that support link recovery, links are being recovered from a different security context. An implementation might enforce that not being allowed, but there's no rule or hint in the specs that I can see that guides that behavior. 

> Scope (connection/session) of CBS token
> ---------------------------------------
>
>                 Key: AMQP-109
>                 URL: https://issues.oasis-open.org/browse/AMQP-109
>             Project: OASIS Advanced Message Queuing Protocol (AMQP) TC
>          Issue Type: Improvement
>          Components: Claims Based Security
>    Affects Versions: cbs-WD03
>            Reporter: Rob Godfrey
>
> I'm not sure that it is made explicit anywhere in the text as to the scope of $cbs - that is, are tokens sent to $cbs valid for the current connection, or only for operations on the session to which the link to $cbs was created.
> I *think* the intent is that the scope is for the entire connection (and clearly for the SASL mechanism the scope MUST be the entire connection since at the time of the SASL exchange there is no notion of sessions).
> One use case for AMQP sessions that has been discussed the past is that of a "connection concentrator" whereby an AMQP intermediary would take incoming connections and proxy those onto a single connection to a remote server using distinct sessions for each of the sessions on each of the "incoming" connections.  To support such a use case it might be nice to add an option "session-scoped" to the put-token operation to specify that the token is only valid for the current session.  This option would be optional and default to false.



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)