-
Notifications
You must be signed in to change notification settings - Fork 2k
Spring Credential
This method leverages the Azure Active Directory as the Authorization Server and performs an OAuth 2.0 request to acquire an access token. The access token could be issued to:
- Users
- Service principals
- Managed identities for Azure resources
Pass the access token in the Authorization header using the Bearer scheme:
Request:
GET /container/file.txt
Authorization: Bearer eyJ0eXAiO...V09ccgQ
Host: sampleoautheast2.blob.core.windows.net
The AMQP Claims-Based-Authorization (CBS) specification draft builds on the management specification request/response pattern, and describes a generalized model for how to use federated security tokens with AMQP. CBS defines a virtual management node, named $cbs
, to be provided by the messaging infrastructure. The management node accepts tokens on behalf of any other nodes in the messaging infrastructure. The token type could be either jwt
or servicebus.windows.net:sastoken
.
A client using Shared Key passes a header with every request that is signed using the storage account access key. For more information, see Authorize with Shared Key.
A request using Shared Key authorization would be like this:
PUT http://myaccount/mycontainer?restype=container&timeout=30 HTTP/1.1
x-ms-version: 2014-02-14
x-ms-date: Fri, 26 Jun 2015 23:39:12 GMT
Authorization: SharedKey myaccount:ctzMq410TV3wS7upTBcunJTDLEJwMAZuFPfr0mrrA08=
A shared access signature is a signed URI that points to one or more storage resources. The URI includes a token that contains a special set of query parameters. The token indicates how the resources may be accessed by the client. One of the query parameters, the signature, is constructed from the SAS parameters and signed with the key that was used to create the SAS. This signature is used by Azure Storage to authorize access to the storage resource.
You can sign a SAS token with a user delegation key or with a storage account key (Shared Key). By any chance, if these SAS keys are compromised, we can only stop further access by regenerating our storage account keys, which is an expensive thing to do. Stored access policies
give you the option to revoke permissions for a service SAS without having to regenerate the storage account keys. Here are the best practices when using SAS.
Azure SDK | TokenCredential | AzureKeyCredential / Key | AzureNamedKeyCredential | AzureSasCredential | SharedKeyCredential |
---|---|---|---|---|---|
Key Vault Secret | ✅ | ❌ | ❌ | ❌ | ❌ |
Cosmos | ✅ | ✅ | ❌ | ❌ | ❌ |
Storage Blob | ✅ | ❌ | ❌ | ✅ | ✅ StorageSharedKeyCredential |
Storage File Share | ❌ | ❌ | ❌ | ✅ | ✅ StorageSharedKeyCredential |
Storage Queue | ✅ | ❌ | ❌ | ✅ | ✅ StorageSharedKeyCredential |
Event Hubs | ✅ | ❌ | ✅ | ✅ ✔️ EventHubSharedKeyCredential (the name is SharedKeyCredential, but it generates a SAS token) | ❌ |
Service Bus | ✅ | ❌ | ✅ | ✅ ✔️ ServiceBusSharedKeyCredential (the name is SharedKeyCredential, but it generates a SAS token) | ❌ |
- Spring Credential
- Spring Cloud Azure 4.0 Design
- Spring Cloud Azure AutoConfigure Design
- Spring Cloud Azure Core Design
- Spring Cloud Azure Messaging Design
- Spring Cloud Azure Service Bus Spring Jms Support Design
- Design for directory, module name and package path for Spring Cloud Azure messaging
- Design for Remove warning logs of unknown configs for Kafka Passwordless
- Design for Enhance AAD token authentication converter to customized granted authorities converter
- Design for Enhance the ObjectMapper to support Spring Boot's pattern to enable autoconfiguration
- Passwordless connection support for Spring Cloud Azure
- Passwordless connection support for MySQL
- Passwordless connection support for Event Hubs Kafka
- Remove warning logs of unknown configs for Kafka Passwordless