Re: [Openstack] [Keystone] List group members with policy.v3cloudsample.json

[林自均]

Hi all,

I found this issue was fixed by
https://bugs.launchpad.net/keystone/+bug/1433402. Thanks.

John

Eugen Block <ebl...@nde.ag> 於 2016年8月4日 週四 下午9:20寫道：

> I just tried to reproduce that with a test domain, but I didn't get
> any errors. Did you make sure that your environment script uses the
> right credentials for (user)domain scope? I had my share with them a
> couple of times...
>
>
> Zitat von 林自均 <johnl...@gmail.com>:
>
> > Hi Eugen,
> >
> > I have no problem with the cloud admin, so I guess your workaround
> doesn't
> > work for me. What disturbing me is the unexpected behavior of the domain
> > admin.
> >
> > John
> >
> > Eugen Block <ebl...@nde.ag> 於 2016年8月4日 週四 下午3:34寫道：
> >
> >> Hi,
> >>
> >> I had a similar issue recently [1], I had to adjust my policy file
> >> because for some reason "domain_id:default" was not applied, instead I
> >> use "user_domain_id:default" which works fine now.
> >>
> >> ---cut here---
> >> control1:~ # grep "\"cloud_admin\":" /etc/keystone/policy.json
> >>  "cloud_admin": "rule:admin_required and (domain_id:default or
> >> user_domain_id:default)",
> >> ---cut here---
> >>
> >> And I added it as an OR statement as a workaround to keep the original
> >> statement. Hope this helps!
> >>
> >> Regards,
> >> Eugen
> >>
> >> [1]
> http://lists.openstack.org/pipermail/openstack/2016-June/016454.html
> >>
> >>
> >> Zitat von 林自均 <johnl...@gmail.com>:
> >>
> >> > Hi all,
> >> >
> >> > My OpenStack version is Mitaka. I updated my
> /etc/keystone/policy.json to
> >> > policy.v3cloudsample.json
> >> > <
> >>
> https://github.com/openstack/keystone/blob/master/etc/policy.v3cloudsample.json
> >> >.
> >> > Most functions works as expected.
> >> >
> >> > However, when I wanted to list members in a group as a domain admin,
> an
> >> > error occurred: “You are not authorized to perform the requested
> action:
> >> > identity:list_users_in_group (HTTP 403)”.
> >> >
> >> > The reproduce steps are:
> >> >
> >> >- As cloud admin:
> >> >   - openstack domain create taiwan
> >> >   - openstack user create --domain taiwan --password 5ecret
> >> >   taiwan-president
> >> >   - openstack role add --user taiwan-president --domain taiwan
> admin
> >> >- As taiwan-president:
> >> >   - openstack group create --domain taiwan indigenous
> >> >   - openstack user create --domain taiwan margaret
> >> >   - openstack group add user --group-domain taiwan indigenous
> >> margaret
> >> >   - openstack user list --group indigenous --domain taiwan
> >> >
> >> > The last command will generate the 403 error.
> >> >
> >> > The rule for identity:list_users_in_group is rule:cloud_admin or
> >> > rule:admin_and_matching_target_group_domain_id. I can successfully
> list
> >> > group members if I changed it to rule:admin_required.
> >> >
> >> > Am I doing anything wrong? Or did I run into some kind of bug? Thanks
> for
> >> > the help.
> >> >
> >> > John
> >> > ​
> >>
> >>
> >>
> >> --
> >> Eugen Block voice   : +49-40-559 51 75
> >> NDE Netzdesign und -entwicklung AG  fax : +49-40-559 51 77
> >> Postfach 61 03 15
> >> D-22423 Hamburg e-mail  : ebl...@nde.ag
> >>
> >>  Vorsitzende des Aufsichtsrates: Angelika Mozdzen
> >>Sitz und Registergericht: Hamburg, HRB 90934
> >>Vorstand: Jens-U. Mozdzen
> >> USt-IdNr. DE 814 013 983
> >>
> >>
> >> ___
> >> Mailing list:
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> >> Post to : openstack@lists.openstack.org
> >> Unsubscribe :
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> >>
>
>
>
> --
> Eugen Block voice   : +49-40-559 51 75
> NDE Netzdesign und -entwicklung AG  fax : +49-40-559 51 77
> Postfach 61 03 15
> D-22423 Hamburg e-mail  : ebl...@nde.ag
>
>  Vorsitzende des Aufsichtsrates: Angelika Mozdzen
>Sitz und Registergericht: Hamburg, HRB 90934
>Vorstand: Jens-U. Mozdzen
> USt-IdNr. DE 814 013 983
>
>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] [Keystone] List group members with policy.v3cloudsample.json

[林自均]

Hi Eugen,

I have no problem with the cloud admin, so I guess your workaround doesn't
work for me. What disturbing me is the unexpected behavior of the domain
admin.

John

Eugen Block <ebl...@nde.ag> 於 2016年8月4日 週四 下午3:34寫道：

> Hi,
>
> I had a similar issue recently [1], I had to adjust my policy file
> because for some reason "domain_id:default" was not applied, instead I
> use "user_domain_id:default" which works fine now.
>
> ---cut here---
> control1:~ # grep "\"cloud_admin\":" /etc/keystone/policy.json
>  "cloud_admin": "rule:admin_required and (domain_id:default or
> user_domain_id:default)",
> ---cut here---
>
> And I added it as an OR statement as a workaround to keep the original
> statement. Hope this helps!
>
> Regards,
> Eugen
>
> [1] http://lists.openstack.org/pipermail/openstack/2016-June/016454.html
>
>
> Zitat von 林自均 <johnl...@gmail.com>:
>
> > Hi all,
> >
> > My OpenStack version is Mitaka. I updated my /etc/keystone/policy.json to
> > policy.v3cloudsample.json
> > <
> https://github.com/openstack/keystone/blob/master/etc/policy.v3cloudsample.json
> >.
> > Most functions works as expected.
> >
> > However, when I wanted to list members in a group as a domain admin, an
> > error occurred: “You are not authorized to perform the requested action:
> > identity:list_users_in_group (HTTP 403)”.
> >
> > The reproduce steps are:
> >
> >- As cloud admin:
> >   - openstack domain create taiwan
> >   - openstack user create --domain taiwan --password 5ecret
> >   taiwan-president
> >   - openstack role add --user taiwan-president --domain taiwan admin
> >- As taiwan-president:
> >   - openstack group create --domain taiwan indigenous
> >   - openstack user create --domain taiwan margaret
> >   - openstack group add user --group-domain taiwan indigenous
> margaret
> >   - openstack user list --group indigenous --domain taiwan
> >
> > The last command will generate the 403 error.
> >
> > The rule for identity:list_users_in_group is rule:cloud_admin or
> > rule:admin_and_matching_target_group_domain_id. I can successfully list
> > group members if I changed it to rule:admin_required.
> >
> > Am I doing anything wrong? Or did I run into some kind of bug? Thanks for
> > the help.
> >
> > John
> > ​
>
>
>
> --
> Eugen Block voice   : +49-40-559 51 75
> NDE Netzdesign und -entwicklung AG  fax : +49-40-559 51 77
> Postfach 61 03 15
> D-22423 Hamburg e-mail  : ebl...@nde.ag
>
>  Vorsitzende des Aufsichtsrates: Angelika Mozdzen
>Sitz und Registergericht: Hamburg, HRB 90934
>Vorstand: Jens-U. Mozdzen
> USt-IdNr. DE 814 013 983
>
>
> ___
> Mailing list:
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe :
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[Openstack] [Keystone] List group members with policy.v3cloudsample.json

[林自均]

Hi all,

My OpenStack version is Mitaka. I updated my /etc/keystone/policy.json to
policy.v3cloudsample.json
.
Most functions works as expected.

However, when I wanted to list members in a group as a domain admin, an
error occurred: “You are not authorized to perform the requested action:
identity:list_users_in_group (HTTP 403)”.

The reproduce steps are:

   - As cloud admin:
  - openstack domain create taiwan
  - openstack user create --domain taiwan --password 5ecret
  taiwan-president
  - openstack role add --user taiwan-president --domain taiwan admin
   - As taiwan-president:
  - openstack group create --domain taiwan indigenous
  - openstack user create --domain taiwan margaret
  - openstack group add user --group-domain taiwan indigenous margaret
  - openstack user list --group indigenous --domain taiwan

The last command will generate the 403 error.

The rule for identity:list_users_in_group is rule:cloud_admin or
rule:admin_and_matching_target_group_domain_id. I can successfully list
group members if I changed it to rule:admin_required.

Am I doing anything wrong? Or did I run into some kind of bug? Thanks for
the help.

John
​
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] [Keystone] Why not OAuth 2.0 provider?

[林自均]

Hi Steve,

Thanks for your explanation! I have some further questions:

You said that OS-OAUTH doesn't make Keystone a proper OAuth provider, so
what is missing? Can name some of the missing parts?

Another thing, a backlog started by you proposed to unify delegation
features [1]. Its spec uses terms of "trustor" and "trustee". Can I say
that the unified delegation workflow will be more like (or even the same
as) the one in current OS-TRUST?

[1]
https://specs.openstack.org/openstack/keystone-specs/specs/backlog/unified-delegation.html

John


Steve Martinelli <s.martine...@gmail.com> 於 2016年6月28日 週二 下午1:57寫道：

> So, the os-oauth routes you mention in the documentation do not make
> keystone a proper oauth provider. We simply perform delegation (one user
> handing some level of permission on a project to another entity) with the
> standard flow established in the oauth1.0b specification.
>
> Historically we chose oauth1.0 because one of the implementers was very
> much against a flow based on oauth2.0 (though the names are similar, these
> can be treated as two very different beasts, you can read about it here
> [1]). Even amongst popular service providers the choice is split down the
> middle, some providing support for both [2]
>
> We haven't bothered to implement support for oauth2.0 since there has been
> no feedback or desire from operators to do so. Mostly, we don't want
> yet-another-delegation mechanism in keystone, we have trusts and oauth1.0;
> should an enticing use case arise to include another, then we can revisit
> the discussion.
>
> [1] https://hueniverse.com/2012/07/26/oauth-2-0-and-the-road-to-hell/
> [2] https://en.wikipedia.org/wiki/List_of_OAuth_providers
>
> On Mon, Jun 27, 2016 at 11:15 PM, 林自均 <johnl...@gmail.com> wrote:
>
>> Hi all,
>>
>> When I am searching for OAuth provider in Keystone, I found only OAuth
>> 1.0. I am a little bit curious about the decision of 1.0 over 2.0. I failed
>> to see the reason in the documentation
>> <https://specs.openstack.org/openstack/keystone-specs/api/v3/identity-api-v3-os-oauth1-ext.html>
>> and this blueprint
>> <https://blueprints.launchpad.net/keystone/+spec/delegated-auth-via-oauth>.
>> Is OAuth 2.0 not compatible with design of Keystone?
>>
>> John
>>
>> ___
>> Mailing list:
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>> Post to : openstack@lists.openstack.org
>> Unsubscribe :
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>
>>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] [Keystone] Source IP address in tokens

[林自均]

Hi Craig,

Okay, I will read some documents on how to implement such mechanism. Thanks!

John

Craig A Lee <craig.a@aero.org> 於 2016年6月27日 週一 下午3:38寫道：

> All,
>
>
>
> This issue of *delegation of trust* (user -> nova -> glance, i.e.,
> enabling nova to auth to glance on behalf of the user) is a fundamental
> capability.  This is precisely why PKI *proxy certs* (IETF 3820) were
> developed back in the grid era enabling chains of trust to be established
> up to a specifiable length.  The OAuth approach essentially enables one
> step of delegation but is certainly getting more widely used.  What’s the
> best approach for Keystone, however, is not going to be simple to pin down.
>
>
>
> --Craig
>
>
>
> *From:* Morgan Fainberg [mailto:morgan.fainb...@gmail.com]
> *Sent:* Sunday, June 26, 2016 11:11 PM
> *To:* 林自均 <johnl...@gmail.com>
> *Cc:* openstack@lists.openstack.org
> *Subject:* Re: [Openstack] [Keystone] Source IP address in tokens
>
>
>
>
> On Jun 26, 2016 19:39, "林自均" <johnl...@gmail.com> wrote:
> >
> > Hi all,
> >
> > I have the following scenario:
> >
> > 1. On client machine A, a user obtains an auth token with a username and
> password.
> > 2. The user can use the auth token to do operations on client machine A.
> > 3. A thief steals the auth token, and do operations on client machine B.
> >
> > Can Keystone check the auth token's source IP (which is client machine A
> in the above example) to prevent thieves to use it? Does this feature
> exist? Or is it a work in progress? Thanks for the help!
> >
> > John
> >
> > ___
> > Mailing list:
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> > Post to : openstack@lists.openstack.org
> > Unsubscribe :
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> >
>
> Unfortunately, validating tokens in this way will induce a number of
> failures. The user's token is passed through from one service to another
> for subsequent actions (e.g. nova talking to glance to get the proper
> image).
>
> We are working on changing how AuthZ is handled when it is service to
> service (nova to glance or cinder) vs when it is user to service.
>
> While we have had the concept of token binding (requiring an x509 client
> cert for example) the above mentioned limitation has made the feature a
> non-starter. Generally speaking bearer tokens are known to have this issue
> and keystone tokens are bearer tokens.
>
> The best mitigation is to use TLS for communication to the endpoints (user
> -> service) and limit the life span of the tokens to the shortest window
> possible (making replay attacks significantly more difficult as the tokens
> expire quickly).
>
> Eventually we can work on solving this, but there is a bunch of work
> needed before it can be worked on/explored.
>
> --Morgan
>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] [Keystone] Source IP address in tokens

[林自均]

Hi Steve & Morgan,

Thank you for your reply! I see the reasons not to validate tokens with
theirs source IP addresses.

One more question to Morgan: you mentioned that I should use the shortest
life span of tokens (perhaps 1 hour?), but this will make the users type in
their usernames and passwords too often. Let's say if I want to provide a
"Remember me for 30 days" checkbox, is there a better way other than
setting the life span of tokens to 30 days?

John

Morgan Fainberg <morgan.fainb...@gmail.com> 於 2016年6月27日 週一 下午2:11寫道：

>
> On Jun 26, 2016 19:39, "林自均" <johnl...@gmail.com> wrote:
> >
> > Hi all,
> >
> > I have the following scenario:
> >
> > 1. On client machine A, a user obtains an auth token with a username and
> password.
> > 2. The user can use the auth token to do operations on client machine A.
> > 3. A thief steals the auth token, and do operations on client machine B.
> >
> > Can Keystone check the auth token's source IP (which is client machine A
> in the above example) to prevent thieves to use it? Does this feature
> exist? Or is it a work in progress? Thanks for the help!
> >
> > John
> >
>
> > ___
> > Mailing list:
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> > Post to : openstack@lists.openstack.org
> > Unsubscribe :
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> >
>
> Unfortunately, validating tokens in this way will induce a number of
> failures. The user's token is passed through from one service to another
> for subsequent actions (e.g. nova talking to glance to get the proper
> image).
>
> We are working on changing how AuthZ is handled when it is service to
> service (nova to glance or cinder) vs when it is user to service.
>
> While we have had the concept of token binding (requiring an x509 client
> cert for example) the above mentioned limitation has made the feature a
> non-starter. Generally speaking bearer tokens are known to have this issue
> and keystone tokens are bearer tokens.
>
> The best mitigation is to use TLS for communication to the endpoints (user
> -> service) and limit the life span of the tokens to the shortest window
> possible (making replay attacks significantly more difficult as the tokens
> expire quickly).
>
> Eventually we can work on solving this, but there is a bunch of work
> needed before it can be worked on/explored.
>
> --Morgan
>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[Openstack] [Keystone] Source IP address in tokens

[林自均]

Hi all,

I have the following scenario:

1. On client machine A, a user obtains an auth token with a username and
password.
2. The user can use the auth token to do operations on client machine A.
3. A thief steals the auth token, and do operations on client machine B.

Can Keystone check the auth token's source IP (which is client machine A in
the above example) to prevent thieves to use it? Does this feature exist?
Or is it a work in progress? Thanks for the help!

John
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack