Hi Andrew,

we're implementing this OASIS WG CBS draft written by Dave Ingham a while back. 
We'll have to give that love in the TC to drive it to completion as it has been 
sitting around, but we have it in production in Service Bus and Event Hubs. 
This allows setting per-node security tokens, and also replacing expiring 
tokens without getting in the way of the message flow. It also allows a client 
to establish an authenticated or anonymous connection with the broker and 
subsequently only allowing links when a token has been set for the link target, 
i.e. you can have 10 different tokens for 10 different targets multiplexed over 
the same connection. It's quite powerful.


I could make the two functions; where do I learn the house rules with regards 
to docs/tests/samples?

The JIRA issue is https://issues.apache.org/jira/browse/PROTON-988

Best Regards

-----Urspr√ľngliche Nachricht-----
Von: Andrew Stitcher [mailto:astitc...@redhat.com] 
Gesendet: Mittwoch, 9. September 2015 18:41
An: proton@qpid.apache.org
Betreff: Re: SASL negotiation w/ EXTERNAL

On Wed, 2015-09-09 at 15:57 +0000, Clemens Vasters wrote:
> Hi Andrew,
> I agree that the server should only offer EXTERNAL when the client has 
> presented a valid cert.
> We have the case that we still want to use PLAIN or ANONYMOUS even in 
> that case, however, since we'll want to use a particular permissions 
> -bound key not representable by the cert, or differentiated per-node
> (link) access control with the AMQP claims-based model,

This is a new thing to me - do you have a pointer to documentationa about the 
"claims-based" (access control?) model.

> So I/we would really like to have an override hook for this. The
> flags seem cheap; a    pn_messenger_set_allowed_sasl_mechs() 
>  function would be just as cheap. Advantage of the flag is that it 
> integrates nicely with flag that's already there.

As I said I'm not against this - I significantly prefer a new API rather than 
flags for the reasons I stated earlier.
pn_messenger_set_allowed_sasl_mechs() seems like a reasonable (if
wordy) name (together with an accessor pn_messenger_get_...).

> For the flags I've done the work and can send a PR. I also fixed the 
> bug I filed yesterday about pn_messenger_set_flags in one go as it's 
> the same function.

Can you point me at the JIRA for this bug?



Reply via email to