settingsLogin | Registersettings

[openstack-dev] [keystone] Does anybody need OAuth1 API in keystone?

0 votes

Hi!

I'm working on unifying all the models that store actor access rights to
the resources [0],
and now I'm wondering if we can just drop current OAuth1 implementation [1].
It's definitely not perfect and require considerable effort to bring it in
good shape so the question is if the feature worth the attention?

​[0]​ https://blueprints.launchpad.net/keystone/+spec/unified-delegation
[1] https://github.com/openstack/keystone/tree/master/keystone/oauth1

--
Kind Regards,
Alexander Makarov,
Senior Software Developer,

Mirantis, Inc.
35b/3, Vorontsovskaya St., 109147, Moscow, Russia

Tel.: +7 (495) 640-49-04
Tel.: +7 (926) 204-50-60

Skype: MAKAPOB.AJIEKCAHDP


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
asked Mar 17, 2016 in openstack-dev by Alexander_V_Makarov (900 points)   1 2

2 Responses

0 votes

Hi Alexander,

We - the murano team (so adding [murano] to subj) - are planning to utilise
keystone's OAuth flow in Newton timeframe.

Our use cases require to have ability to delegate some of user's privileges
o various kinds of external (i.e. non-openstack) apps or services, so they
may interact with Murano API on behalf of that user.

A real-life example is a Cloud Foundry integration: we have a service which
acts as a Cloud Foundry Service Broker [1]: it exposes a
CloudFoundry-compatible APIs but under the hood implements them as calls to
Murano APIs. So, it needs to authenticate with Keystone using some valid
credentials. Right now we use regular user's name and password for that,
but this approach is not perfect, since these services may be controlled by
third-parties, so the users may not trust them - so, this is the exact use
case for the OAuth as a standard.

Another example of highly demanded use case for murano are custom
murano-powered CI/CD pipelines: in such deployments a build server may need
to generate murano applications, form murano packages, upload it to package
repository (glance/glare) and then deploy that package within an
appropriate murano environment. This case also requires this buildserver to
call glare and murano APIs on behalf of the user owning the job. We have
such deployments right now, but they also are statically configured with
the usernames and passwords of some service users, and that's not right.

So, we are looking forward for OAuth indeed.

I did some research with the current implementation, it obviously has some
issues (including the security ones), but I strongly believe that it should
be fixed and improved, not dropped (after all, silently dropping a part of
public api should never be an option in openstack: once public - always
public).
If you need my help or feedback on use-cases and found issues - please let
me know, I'll be happy to help.

[1] http://docs.cloudfoundry.org/services/api.html

On Thu, Mar 17, 2016 at 1:05 PM Alexander Makarov amakarov@mirantis.com
wrote:

Hi!

I'm working on unifying all the models that store actor access rights to
the resources [0],
and now I'm wondering if we can just drop current OAuth1 implementation
[1].
It's definitely not perfect and require considerable effort to bring it in
good shape so the question is if the feature worth the attention?

​[0]​ https://blueprints.launchpad.net/keystone/+spec/unified-delegation
[1] https://github.com/openstack/keystone/tree/master/keystone/oauth1

--
Kind Regards,
Alexander Makarov,
Senior Software Developer,

Mirantis, Inc.
35b/3, Vorontsovskaya St., 109147, Moscow, Russia

Tel.: +7 (495) 640-49-04
Tel.: +7 (926) 204-50-60

Skype: MAKAPOB.AJIEKCAHDP


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Regards,
Alexander Tivelkov


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Mar 25, 2016 by Alexander_Tivelkov (3,080 points)   3 4
0 votes

On 03/25/2016 08:44 AM, Alexander Tivelkov wrote:
Hi Alexander,

We - the murano team (so adding [murano] to subj) - are planning to
utilise keystone's OAuth flow in Newton timeframe.

Our use cases require to have ability to delegate some of user's
privileges o various kinds of external (i.e. non-openstack) apps or
services, so they may interact with Murano API on behalf of that user.

A real-life example is a Cloud Foundry integration: we have a service
which acts as a Cloud Foundry Service Broker [1]: it exposes a
CloudFoundry-compatible APIs but under the hood implements them as
calls to Murano APIs. So, it needs to authenticate with Keystone using
some valid credentials. Right now we use regular user's name and
password for that, but this approach is not perfect, since these
services may be controlled by third-parties, so the users may not
trust them - so, this is the exact use case for the OAuth as a standard.

Another example of highly demanded use case for murano are custom
murano-powered CI/CD pipelines: in such deployments a build server may
need to generate murano applications, form murano packages, upload it
to package repository (glance/glare) and then deploy that package
within an appropriate murano environment. This case also requires this
buildserver to call glare and murano APIs on behalf of the user owning
the job. We have such deployments right now, but they also are
statically configured with the usernames and passwords of some service
users, and that's not right.

So, we are looking forward for OAuth indeed.

I did some research with the current implementation, it obviously has
some issues (including the security ones), but I strongly believe that
it should be fixed and improved, not dropped (after all, silently
dropping a part of public api should never be an option in openstack:
once public - always public).
If you need my help or feedback on use-cases and found issues - please
let me know, I'll be happy to help.

This is good to know, and exactly what the API was designed for. We are
looking to unify the implementation with how we do Trusts and Role
Assignments, but we will not be changing the semantics. We just were
hoping to avoid the work for OAUTH if it was not being used.

[1] http://docs.cloudfoundry.org/services/api.html

On Thu, Mar 17, 2016 at 1:05 PM Alexander Makarov
<amakarov@mirantis.com amakarov@mirantis.com> wrote:

Hi!

I'm working on unifying all the models that store actor access
rights to the resources [0],
and now I'm wondering if we can just drop current OAuth1
implementation [1].
It's definitely not perfect and require considerable effort to
bring it in good shape so the question is if the feature worth the
attention?

​[0]​
https://blueprints.launchpad.net/keystone/+spec/unified-delegation
[1] https://github.com/openstack/keystone/tree/master/keystone/oauth1

-- 
Kind Regards,
Alexander Makarov,
Senior Software Developer,

Mirantis, Inc.
35b/3, Vorontsovskaya St., 109147, Moscow, Russia

Tel.: +7 (495) 640-49-04
Tel.: +7 (926) 204-50-60

Skype: MAKAPOB.AJIEKCAHDP
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Regards,
Alexander Tivelkov


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Mar 26, 2016 by Adam_Young (19,940 points)   2 7 12
...