You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jclouds.apache.org by Jim Spring <jm...@gmail.com> on 2017/11/21 03:34:33 UTC
Azure KeyVault PR and Dynamic resource in ClientCredentialsSecretFlow/ClientCredentialsJWTBearerTokenFlow
@Ignasi/@Andrea -
I'm guilty for writing the code as it is in OAuth, I should have thought ahead.
Azure KeyVault has a dynamic resource (the vault URI) that
authorization must be requested against. In the current PR, @Andrea
added the KeyVaultFilter to support this, mostly duplicating
ClientCredentialsSecretFlow. With Azure, conceivably we could use
both ClientCredentialsJWTBearerTokenFlow and
ClientCredentialsSecretFlow.
My thought is, to isolate the changes (for now) in azurecompute-arm
and figure out a way to work around this (while not duplicating the
code as it is in the current PR). Once the PR is in, then work on
updating jclouds proper and update azurecompute-arm accordingly.
Thoughts?
Thanks
-jim
Re: Azure KeyVault PR and Dynamic resource in ClientCredentialsSecretFlow/ClientCredentialsJWTBearerTokenFlow
Posted by Ignasi Barrera <ig...@gmail.com>.
There was already a per-request call to get the read or write scope. I
don't think there is significant impact.
On Nov 24, 2017 9:44 PM, "Andrea Turli" <an...@gmail.com> wrote:
> Hi!
>
> the approach looks sensible to me, especially because it is backwards
> compatible.
>
> Do you envisage any significant impact on the performances due to on per
> request basis switch?
>
> I'll try to give it a try asap.
>
> Cheers
>
> On Fri, Nov 24, 2017 at 5:18 PM, Ignasi Barrera <na...@apache.org> wrote:
>
> > Hi!
> >
> > I've been thinking about this and perhaps we could extend the OAuth
> > API to allow dynamic configuration of each OAuth property. I've
> > created a branch to play with and see if this approach could work:
> >
> > Here is the change to OAuth (backwards-compatible):
> > https://github.com/nacx/jclouds/commit/5e384265ae738b913863931e89d8e3
> > 7a3170b155
> >
> > And here the change to Azure ARM:
> > https://github.com/nacx/jclouds-labs/commit/
> 5212be898c3100f4caf07f0dbaa071
> > f99563a6e5
> >
> > The idea is to apply the same pattern we were applying tot he OAuth
> > scopes, but provide all the configuration per-request. The default
> > implementation just returns the values configured as context
> > properties, but custom ones can be bound to the Guice context to
> > provide custom values per-request.
> >
> >
> > @Jim, @Andrea could you give this approach a try and see if we can use
> > this to remove the custom keyvault filter in Azure ARM? With this
> > approach we should be able to keep using the OAuthFilter.
> >
> > On 21 November 2017 at 04:34, Jim Spring <jm...@gmail.com> wrote:
> > > @Ignasi/@Andrea -
> > >
> > > I'm guilty for writing the code as it is in OAuth, I should have
> thought
> > ahead.
> > >
> > > Azure KeyVault has a dynamic resource (the vault URI) that
> > > authorization must be requested against. In the current PR, @Andrea
> > > added the KeyVaultFilter to support this, mostly duplicating
> > > ClientCredentialsSecretFlow. With Azure, conceivably we could use
> > > both ClientCredentialsJWTBearerTokenFlow and
> > > ClientCredentialsSecretFlow.
> > >
> > > My thought is, to isolate the changes (for now) in azurecompute-arm
> > > and figure out a way to work around this (while not duplicating the
> > > code as it is in the current PR). Once the PR is in, then work on
> > > updating jclouds proper and update azurecompute-arm accordingly.
> > >
> > > Thoughts?
> > >
> > > Thanks
> > > -jim
> >
>
Re: Azure KeyVault PR and Dynamic resource in ClientCredentialsSecretFlow/ClientCredentialsJWTBearerTokenFlow
Posted by Andrea Turli <an...@gmail.com>.
Hi!
the approach looks sensible to me, especially because it is backwards
compatible.
Do you envisage any significant impact on the performances due to on per
request basis switch?
I'll try to give it a try asap.
Cheers
On Fri, Nov 24, 2017 at 5:18 PM, Ignasi Barrera <na...@apache.org> wrote:
> Hi!
>
> I've been thinking about this and perhaps we could extend the OAuth
> API to allow dynamic configuration of each OAuth property. I've
> created a branch to play with and see if this approach could work:
>
> Here is the change to OAuth (backwards-compatible):
> https://github.com/nacx/jclouds/commit/5e384265ae738b913863931e89d8e3
> 7a3170b155
>
> And here the change to Azure ARM:
> https://github.com/nacx/jclouds-labs/commit/5212be898c3100f4caf07f0dbaa071
> f99563a6e5
>
> The idea is to apply the same pattern we were applying tot he OAuth
> scopes, but provide all the configuration per-request. The default
> implementation just returns the values configured as context
> properties, but custom ones can be bound to the Guice context to
> provide custom values per-request.
>
>
> @Jim, @Andrea could you give this approach a try and see if we can use
> this to remove the custom keyvault filter in Azure ARM? With this
> approach we should be able to keep using the OAuthFilter.
>
> On 21 November 2017 at 04:34, Jim Spring <jm...@gmail.com> wrote:
> > @Ignasi/@Andrea -
> >
> > I'm guilty for writing the code as it is in OAuth, I should have thought
> ahead.
> >
> > Azure KeyVault has a dynamic resource (the vault URI) that
> > authorization must be requested against. In the current PR, @Andrea
> > added the KeyVaultFilter to support this, mostly duplicating
> > ClientCredentialsSecretFlow. With Azure, conceivably we could use
> > both ClientCredentialsJWTBearerTokenFlow and
> > ClientCredentialsSecretFlow.
> >
> > My thought is, to isolate the changes (for now) in azurecompute-arm
> > and figure out a way to work around this (while not duplicating the
> > code as it is in the current PR). Once the PR is in, then work on
> > updating jclouds proper and update azurecompute-arm accordingly.
> >
> > Thoughts?
> >
> > Thanks
> > -jim
>
Re: Azure KeyVault PR and Dynamic resource in ClientCredentialsSecretFlow/ClientCredentialsJWTBearerTokenFlow
Posted by Ignasi Barrera <na...@apache.org>.
Hi!
I've been thinking about this and perhaps we could extend the OAuth
API to allow dynamic configuration of each OAuth property. I've
created a branch to play with and see if this approach could work:
Here is the change to OAuth (backwards-compatible):
https://github.com/nacx/jclouds/commit/5e384265ae738b913863931e89d8e37a3170b155
And here the change to Azure ARM:
https://github.com/nacx/jclouds-labs/commit/5212be898c3100f4caf07f0dbaa071f99563a6e5
The idea is to apply the same pattern we were applying tot he OAuth
scopes, but provide all the configuration per-request. The default
implementation just returns the values configured as context
properties, but custom ones can be bound to the Guice context to
provide custom values per-request.
@Jim, @Andrea could you give this approach a try and see if we can use
this to remove the custom keyvault filter in Azure ARM? With this
approach we should be able to keep using the OAuthFilter.
On 21 November 2017 at 04:34, Jim Spring <jm...@gmail.com> wrote:
> @Ignasi/@Andrea -
>
> I'm guilty for writing the code as it is in OAuth, I should have thought ahead.
>
> Azure KeyVault has a dynamic resource (the vault URI) that
> authorization must be requested against. In the current PR, @Andrea
> added the KeyVaultFilter to support this, mostly duplicating
> ClientCredentialsSecretFlow. With Azure, conceivably we could use
> both ClientCredentialsJWTBearerTokenFlow and
> ClientCredentialsSecretFlow.
>
> My thought is, to isolate the changes (for now) in azurecompute-arm
> and figure out a way to work around this (while not duplicating the
> code as it is in the current PR). Once the PR is in, then work on
> updating jclouds proper and update azurecompute-arm accordingly.
>
> Thoughts?
>
> Thanks
> -jim