qpid-proton mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Clemens Vasters <cleme...@microsoft.com>
Subject AW: SASL negotiation w/ EXTERNAL
Date Wed, 09 Sep 2015 17:03:33 GMT
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:astitcher@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?



View raw message