Shared Access Signature Connection String Support

[jsquire]

Summary

When using Service Bus one common scenario is for untrusted parties, such as IoT devices, to publish events to a given entity. Because these callers are untrusted, it is desirable to manage them at a granular level that doesn't impact all interactions with an entity. In many cases, using AAD principals is either not possible due to device support, undesirable due to the overhead of managing a large number of identities, or may have cost barriers.

For granularity of access, it is possible to create a publisher entity for a given entity and apply access policies to that publisher. This controls authorization on a more granular level than the entity alone and helps to allow individuals or a small group of publishers to be managed as a unit without any actions impacting other publishers.

Because publishers are potentially untrusted and unable to use AAD principals, allowing them access to the shared key and shared value is a security risk. One common solution is to allow them to request a SAS token that is bound to their publisher identity which can be used with a connection string for access. Using this approach, risk is contained to the scope of the publisher identity and limited by the time that the SAS token is valid.

The current implementation of the Service Bus clients do not support a SAS token used for access; instead they require that the shared key and value be provided. A design is needed to allow for creation of a SAS token by users of the Service Bus client library and which supports authorization using the SAS token.

Scope of Work

• Implement support for a SharedAccessSignature token in the connection string. If present, the value for the token should be treated as a pre-formed SAS and otherwise follow the same credential and authorization flow as a shared key appearing in the connection string.

• If the SharedAccessSignature appears in a connection string that also contains shared key information (either the key, value, or both), the connection string fails validation and is rejected.

Success Criteria

• Support for a shared access signature in the connection string has been implemented and can be used in place of a shared key for authorization.

• The tests necessary for its validation have been created or adjusted and pass reliably.

• The existing test suite continues to produce deterministic results and pass reliably.

Out of Scope

• Support for a dedicated publisher entity to be specified; this will be covered under a dedicated issue in the future.

• Support for a token credential to represent the shared access signature; for the time being, SAS authorization will be supported only via the connection string.

Related Issues and References

• Change Request: Support components of connection string not present in the portal (#1701)