[OASIS Issue Tracker] (AMQP-139) Link recovery tokens

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

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

Clemens Vasters commented on AMQP-139:
--------------------------------------

Since we're trying to protect the links, any greater scope than the link does not really make sense to me. I also look at containers as a virtual concept and not a real operational scope.

Example scenario: Some software host H1 runs in a multi-node failover cluster where it owns responsibility for processing contexts C1 and C2. Acting as an AMQP container, it connects to another software entity E running elsewhere that also acts as an AMQP container. Links L1 (for C1) and L2 (for C2) are established over the connection/session between the two containers H1 and E. Now assume the host H1 crashes due to a hardware failure and the connection collapses. The cluster fabric now assigns ownership of context C1 to the secondary host H2 and context C2 to secondary host H3. What I now want is that H2 can recover L1/C1 and H3 can recover L2/C2. 

I believe it's reasonable to expect a party to durably remember its identity and associated state when it wants to recover from a failure condition. 

How a peer enforces association of the link recovery token with the connection-level authentication context may be up to the peer's implementation. The peer issuing the token could tie that up to the other peer's identity and require that the newly established connection has a compatible authentication context (i.e. same identity claim or user).

> Link recovery tokens
> --------------------
>
>                 Key: AMQP-139
>                 URL: https://issues.oasis-open.org/browse/AMQP-139
>             Project: OASIS Advanced Message Queuing Protocol (AMQP) TC
>          Issue Type: Improvement
>          Components: Security
>            Reporter: Clemens Vasters
>
> The recovery of links from broken connections/sessions may require proof that the client is authorized to perform that recovery. In this scenario, the client may be a failover instance of a prior client instance. What shall be prevented is that some other party that has access to the broker and that can guess the respective link names, can "steal" such recovery-pending links from another party that has just lost its connection to the broker. 



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