Skip to content
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

Merged
merged 2 commits into from
Jun 16, 2020

Conversation

abhipsaMisra
Copy link
Member

@abhipsaMisra abhipsaMisra commented Jun 12, 2020

  • Add implementation for IoT Hub service client authentication via connection string
  • Add initial setup required for E2E tests

Used the SDK board recommended Azure Application Configuration Service SDK for reference.


namespace Azure.Iot.Hub.Service.Authentication
{
internal class SasTokenAuthenticationPolicy : HttpPipelinePolicy
Copy link
Member

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member Author

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.

Copy link
Contributor

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.

Copy link
Member

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?

Copy link
Member

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member

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.

Copy link
Member Author

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

{
internal static class SharedAccessSignatureConstants
{
public const int MaxKeyNameLength = 256;
Copy link
Contributor

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor

@drwill-ms drwill-ms left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

waiting

Copy link
Member

@vinagesh vinagesh left a 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.

@vinagesh
Copy link
Member

Update commit message according to guidelines.

@abhipsaMisra
Copy link
Member Author

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.

@abhipsaMisra abhipsaMisra force-pushed the feature/abmisr/devicesE2e branch 2 times, most recently from c49dc4d to d36de29 Compare June 15, 2020 23:21
public class IotHubServiceTestEnvironment : TestEnvironment
{
public IotHubServiceTestEnvironment()
: base("iot")
Copy link
Member

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@abhipsaMisra abhipsaMisra merged commit 9db34d6 into feature/IoT-Hub Jun 16, 2020
@abhipsaMisra abhipsaMisra deleted the feature/abmisr/devicesE2e branch June 16, 2020 00:35
azabbasi added a commit that referenced this pull request Jun 29, 2020
* 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]>
prmathur-microsoft pushed a commit that referenced this pull request Jul 7, 2020
* feat(e2e-tests): Add initial setup for E2E tests

* feat(iot-service): Add authentication via connection string
prmathur-microsoft pushed a commit that referenced this pull request Jul 8, 2020
* 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]>
prmathur-microsoft pushed a commit that referenced this pull request Jul 8, 2020
* feat(e2e-tests): Add initial setup for E2E tests

* feat(iot-service): Add authentication via connection string
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants