-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
IoT hub service client authentication via connection string #12731
Conversation
f811f69
to
71ba3e8
Compare
sdk/iot/Azure.Iot.Hub.Service/api/Azure.Iot.Hub.Service.netstandard2.0.cs
Outdated
Show resolved
Hide resolved
|
||
namespace Azure.Iot.Hub.Service.Authentication | ||
{ | ||
internal class SasTokenAuthenticationPolicy : HttpPipelinePolicy |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@pakrym Is there support for Connection String auth in Azure.Core? Is this something we should add just for our client library or will there be support in Azure.Core? We can contribute to the codebase.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is a parse that you can use https://github.com/Azure/azure-sdk-for-net/blob/master/sdk/core/Azure.Core/src/Shared/ConnectionString.cs
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@pakrym We have taken a dependency on the Azure.Core.ConnectionString parser for parsing the connection string. Do we have an Azure.Core authentication policy that will inject the generated sas token (from the connection string shared access key and policy) into the HTTP pipeline?
The app configuration SDK, that we've used for reference, also uses connection strings, but they've defined their own http pipeline policy for adding the auth header to the HTTP requests.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, we don't have a shared policy like that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@pakrym Do you think it would make sense to have a common Policy that all client libraries can share? Just like the Bearer token policy?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe the policy just adds the authentication header so it could be common right? If there is a difference in getting the value of the header, each client can have their own implementation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If it's only about adding a header value then https://github.com/Azure/azure-sdk-for-net/blob/master/sdk/core/Azure.Core/src/Shared/AzureKeyCredentialPolicy.cs is what you want.
But I've seen AppConfig mentioned above and it has a way more complicated policy: https://github.com/Azure/azure-sdk-for-net/blob/master/sdk/appconfiguration/Azure.Data.AppConfiguration/src/AuthenticationPolicy.cs
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@abhipsaMisra - We should be able to re-use the AzureKeyCredentialPolicy and just pass the necessary value to it instead of creating a new policy. Also do you see that the code will be same for ours and other libraries? We should try to get to a common solution in that case. My minimal knowledge of connection strings suggests that it should be same but I might be wrong.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes @pakrym, we should be good to reuse the AzureKeyCredentialPolicy to pass the token to the http pipeline. For the implementation for actually generating the sas token, our code is here: https://github.com/Azure/azure-sdk-for-net/blob/feature/abmisr/devicesE2e/sdk/iot/Azure.Iot.Hub.Service/src/Authentication/SharedAccessSignatureBuilder.cs#L36
It uses sha256 on the access key to sign the hostname and token expiry time. App configuration uses a similar mechanism to compute their token, but their request string has a few more parameters.
@vinagesh : I would think so, yes, but I don't think that's the case. Looking at app configuration SDK, their implementation for generating tokens wouldn't work for us, so I am not sure exactly how much of this we can generalize. This will need deeper investigation and input from service teams.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sdk/iot/Azure.Iot.Hub.Service/tests/IotHubServiceTestEnvironment.cs
Outdated
Show resolved
Hide resolved
sdk/iot/Azure.Iot.Hub.Service/src/Authentication/ISasTokenProvider.cs
Outdated
Show resolved
Hide resolved
sdk/iot/Azure.Iot.Hub.Service/src/Authentication/StaticSasTokenProvider.cs
Outdated
Show resolved
Hide resolved
sdk/iot/Azure.Iot.Hub.Service/src/Authentication/SasTokenProviderWithSharedAccessKey.cs
Outdated
Show resolved
Hide resolved
sdk/iot/Azure.Iot.Hub.Service/src/Authentication/IotHubConnectionString.cs
Show resolved
Hide resolved
sdk/iot/Azure.Iot.Hub.Service/src/Authentication/IotHubConnectionString.cs
Outdated
Show resolved
Hide resolved
sdk/iot/Azure.Iot.Hub.Service/src/Authentication/SharedAccessSignatureBuilder.cs
Outdated
Show resolved
Hide resolved
sdk/iot/Azure.Iot.Hub.Service/src/Authentication/SharedAccessSignatureConstants.cs
Show resolved
Hide resolved
{ | ||
internal static class SharedAccessSignatureConstants | ||
{ | ||
public const int MaxKeyNameLength = 256; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Each of these could use meaningful xml comments as well
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
waiting
sdk/iot/Azure.Iot.Hub.Service/src/Authentication/IotHubConnectionString.cs
Show resolved
Hide resolved
sdk/iot/Azure.Iot.Hub.Service/src/Authentication/SasTokenProviderWithSharedAccessKey.cs
Show resolved
Hide resolved
sdk/iot/Azure.Iot.Hub.Service/src/Authentication/SharedAccessSignatureBuilder.cs
Outdated
Show resolved
Hide resolved
sdk/iot/Azure.Iot.Hub.Service/src/Authentication/SharedAccessSignatureConstants.cs
Outdated
Show resolved
Hide resolved
sdk/iot/Azure.Iot.Hub.Service/src/Authentication/StaticSasTokenProvider.cs
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are quite a few open points to conclude on so let us do that.
Update commit message according to guidelines. |
Thanks for reminding @vinagesh . I'll do that when I clean up the commits, after the review is complete. |
c49dc4d
to
d36de29
Compare
d36de29
to
4a2b882
Compare
public class IotHubServiceTestEnvironment : TestEnvironment | ||
{ | ||
public IotHubServiceTestEnvironment() | ||
: base("iot") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be TestSettings.IotHubServiceEnvironmentVariablesPrefix
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
* feat(hub): Creating a new feature branch with swagger and generated files * fix(doc): Fix markdown for API design doc (#11690) * swagger(iothub): Adding overrides for type names (#12026) * fix(tests): Fix project reference for the test framework (#12053) * fix(hub): Fix property accessibility issue (#12055) * Fix API categories for iothub service client (#12087) * swagger(iothub): Swagger comment changes (#12149) * fix(iot): Regenerate iothub PL after rebase from master * refactor(iot): Remove unnecessary custom code This class only existed to make the DigitalTwinClient internal, but now all generated clients are internal by default * Swagger changes for Iot Hub (#12218) * Revert swagger back to what is currently deployed This swagger should never be hand edited. We can update it only when service accepts the changes * Add composite swagger file with all suggested changes for service to make read only, required params, and comment refactors. OperationId changes will go in here, too * Regenerate PL with the currently deployed swagger * Update models to rename CloudToDeviceMethod and CloudToDeviceMethodResult (#12240) * Modules API design (#12188) * Add IoTHub Devices subclient APIs * Swagger changes for Client grouping (#12245) * Add suggested type name changes to iothub swagger (#12296) * Service Client CL and client grouping (#12323) * Small API design comments fix * feat(autorest): Generated clients from autorest after sync with master * Add implementation for Devices APIs (#12611) * (feat): Implement Modules client (#12673) * feat(tests): Add test infrastructure and setup.ps1 for local setup (#12719) * Add test infrastructure and setup * Add common files, remove specific sub (#12722) * fix(swagger): Fix IotHub swagger descriptions (#12695) * fix(pipeline): Update setup script to call test-resources ARM template directly (#12775) * feat(samples): Samples project skeleton (#12787) * IoT hub service client authentication via connection string (#12731) * feat(e2e-tests): Add initial setup for E2E tests * feat(iot-service): Add authentication via connection string * fix(iot-service): Fix merge conflict in infrastructure setup file (#12803) Co-authored-by: Abhipsa Misra <[email protected]> * feat(tests): Changes to fix tests and make sure we can run them successfully. (#12819) * Start recording tests and add intial Session recording (#12827) * feat(samples): Initial CREATE/DELETE sample for ModuleI (#12850) * feat(samples): Finish Modules samples (#12989) * feat(e2e): Devices E2E tests (#12997) * Update the logic for ETags and preconditions (#13046) * Fix the CI and test pipelines. (#13091) Co-authored-by: abhipds <[email protected]> Co-authored-by: Abhipsa Misra <[email protected]> Co-authored-by: vinagesh <[email protected]> Co-authored-by: timtay-microsoft <[email protected]> Co-authored-by: bikamani <[email protected]> Co-authored-by: Sindhu Nagesh <[email protected]> Co-authored-by: Abhipsa Misra <[email protected]>
* feat(e2e-tests): Add initial setup for E2E tests * feat(iot-service): Add authentication via connection string
* feat(hub): Creating a new feature branch with swagger and generated files * fix(doc): Fix markdown for API design doc (#11690) * swagger(iothub): Adding overrides for type names (#12026) * fix(tests): Fix project reference for the test framework (#12053) * fix(hub): Fix property accessibility issue (#12055) * Fix API categories for iothub service client (#12087) * swagger(iothub): Swagger comment changes (#12149) * fix(iot): Regenerate iothub PL after rebase from master * refactor(iot): Remove unnecessary custom code This class only existed to make the DigitalTwinClient internal, but now all generated clients are internal by default * Swagger changes for Iot Hub (#12218) * Revert swagger back to what is currently deployed This swagger should never be hand edited. We can update it only when service accepts the changes * Add composite swagger file with all suggested changes for service to make read only, required params, and comment refactors. OperationId changes will go in here, too * Regenerate PL with the currently deployed swagger * Update models to rename CloudToDeviceMethod and CloudToDeviceMethodResult (#12240) * Modules API design (#12188) * Add IoTHub Devices subclient APIs * Swagger changes for Client grouping (#12245) * Add suggested type name changes to iothub swagger (#12296) * Service Client CL and client grouping (#12323) * Small API design comments fix * feat(autorest): Generated clients from autorest after sync with master * Add implementation for Devices APIs (#12611) * (feat): Implement Modules client (#12673) * feat(tests): Add test infrastructure and setup.ps1 for local setup (#12719) * Add test infrastructure and setup * Add common files, remove specific sub (#12722) * fix(swagger): Fix IotHub swagger descriptions (#12695) * fix(pipeline): Update setup script to call test-resources ARM template directly (#12775) * feat(samples): Samples project skeleton (#12787) * IoT hub service client authentication via connection string (#12731) * feat(e2e-tests): Add initial setup for E2E tests * feat(iot-service): Add authentication via connection string * fix(iot-service): Fix merge conflict in infrastructure setup file (#12803) Co-authored-by: Abhipsa Misra <[email protected]> * feat(tests): Changes to fix tests and make sure we can run them successfully. (#12819) * Start recording tests and add intial Session recording (#12827) * feat(samples): Initial CREATE/DELETE sample for ModuleI (#12850) * feat(samples): Finish Modules samples (#12989) * feat(e2e): Devices E2E tests (#12997) * Update the logic for ETags and preconditions (#13046) * Fix the CI and test pipelines. (#13091) Co-authored-by: abhipds <[email protected]> Co-authored-by: Abhipsa Misra <[email protected]> Co-authored-by: vinagesh <[email protected]> Co-authored-by: timtay-microsoft <[email protected]> Co-authored-by: bikamani <[email protected]> Co-authored-by: Sindhu Nagesh <[email protected]> Co-authored-by: Abhipsa Misra <[email protected]>
* feat(e2e-tests): Add initial setup for E2E tests * feat(iot-service): Add authentication via connection string
Used the SDK board recommended Azure Application Configuration Service SDK for reference.