List credentials by type

[Jamie Lennox]

Currently the only attribute that you can filter a credential list by is user_id. I want to be able to list by user_id and credential type (a required field) so that i only get back my EC2 credentials (for example) when i do a list.

[Deepti Ramakrishna (dramakri)]

Hi Jason,

I had started looking at this bug and would have appreciated if you had notified me before reassigning it to yourself. From next time on wards, please coordinate with the original bug assignee before reassigning a bug to yourself.

Thanks,
Deepti

[Jason O'Brien (jason10258)]

Hello Deepti,

I'm so sorry about not notifying you about the bug. I was planning on telling you during the meeting and also I can't login to my lync/Skype so I can't email you yet. If you want I would very much be okay if you want to take that bug back.

Thanks,

Jason

> On Jun 22, 2015, at 10:32 AM, Deepti Ramakrishna <email address hidden> wrote:
>
> Hi Jason,
>
> I had started looking at this bug and would have appreciated if you had
> notified me before reassigning it to yourself. From next time on wards,
> please coordinate with the original bug assignee before reassigning a
> bug to yourself.
>
> Thanks,
> Deepti
>
> --
> You received this bug notification because you are a bug assignee.
> https://bugs.launchpad.net/bugs/1460492
>
> Title:
> List credentials by type
>
> Status in OpenStack Identity (Keystone):
> Triaged
>
> Bug description:
> Currently the only attribute that you can filter a credential list by
> is user_id. I want to be able to list by user_id and credential type
> (a required field) so that i only get back my EC2 credentials (for
> example) when i do a list.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/keystone/+bug/1460492/+subscriptions

[Deepti Ramakrishna (dramakri)]

Hey Jason, didn't recognize you as one of our interns :) Feel free to work on this.

[Anh Huynh (anhx-huynh)]

Hello Deepti,

I am a high school intern at Intel, may I assign this bug to myself?

[Deepti Ramakrishna (dramakri)]

Sure Anh. If you end up not working on this, please inform me before unassigning.

[Anh Huynh (anhx-huynh)]

Jamie, can you please clarify what is meant to "list by credential types"? Does it mean to list by access key or secret key or email or password, or does it mean to list by roles such as admin and user? And does "list by" means to sort them alphabetically by user_id or to only list fields that matches the filter?

And also when you do >openstack ec2 credentials list --user <user>, you can get the only that user's project ID, secret and access key. Is that what you mean by "so that i only get back my EC2 credentials (for example) when i do a list" or did you mean something else?

[Jamie Lennox (jamielennox)]

So the credential interface is fairly generic, you put up a blob of data and you tag it with a type that should let you know what the blob is for and therefore how you should use it. You can see the fields here[1] and see that user_id, type and blob are required, and that it gives examples of type as ec2 or cert.

When i use the credential interface to list i can specify my user_id [2] so that i can list all of my credentials. But in reality if i'm listing my own credentials i probably know what i'm looking for, so i want to be able to like list all my credentials that are ec2 or something like that. So in addition to being able to do GET /credentials?user_id=XXX i want to do ?user_id=XXX&type=ec2

[1] https://github.com/openstack/keystone-specs/blob/master/api/v3/identity-api-v3.rst#credentials-v3credentials
[2] https://github.com/openstack/keystone-specs/blob/master/api/v3/identity-api-v3.rst#list-credentials

[Jamie Lennox (jamielennox)]

Note that when you say openstack ec2 that's a seperate but related interface that is actually provided by the ec2 middleware in keystone[1]. Ideally if we could teach OSC about the different types of credential we could use the credentials interface directly and get rid of that middlewarw.

[1] https://github.com/openstack/keystone/tree/master/keystone/contrib/ec2

[Anh Huynh (anhx-huynh)]

Discussion from IRC:
2015-06-30T19:40:38 <anhhuynx> jamielennox: Would you please advise me on how to start with this? It appears that I have been going about this the wrong way, and I have no idea how to even use the v3 keystone API. If you don't mind can you point me to some reading materials?
2015-06-30T19:43:58 <jamielennox> anhhuynx: hmm reading material for keystone v3...
2015-06-30T19:46:13 <jamielennox> anhhuynx: so i guess there are multiple ways to interact and it depends what you are looking for
2015-06-30T19:46:55 <jamielennox> anhhuynx: so keystone provides a REST API for how to interact with it which is defined https://github.com/openstack/keystone-specs/blob/master/api/v3/identity-api-v3.rst
2015-06-30T19:46:56 <dramakri> anhhuynx: some simple v3 api examples from ayoung's blog - http://adam.younglogic.com/2013/09/keystone-v3-api-examples/
2015-06-30T19:47:16 <jamielennox> anhhuynx: to communicate with that you can use curl or whatever you like that talks http
2015-06-30T19:47:28 <anhhuynx> Thank you very much!
2015-06-30T19:47:52 <jamielennox> we provide keystoneclient which is a python library that provides a way to talk python and have the library make calls for you
2015-06-30T19:48:15 <jamielennox> documentation is a bit scarse but: http://docs.openstack.org/developer/python-keystoneclient/using-api-v3.html
2015-06-30T19:48:53 <jamielennox> then openstack client is an application that you can call from the command line which consumes keystoneclient internally
2015-06-30T19:50:05 <jamielennox> so i guess it depends how you want to use it
2015-06-30T19:51:18 <jamielennox> anhhuynx: regarding how you go about implementing it, first you would need to update the identity-api-v3 document above to add a new type parameter to the list credentials
2015-06-30T19:51:59 <jamielennox> then you need to add it to keystone itself so that when type= is passed it filters the results
2015-06-30T19:52:47 <jamielennox> then add it to keystoneclient and maybe openstackclient
2015-06-30T19:54:16 <anhhuynx> jamielennox: Isn't the identity-api-v3 document above just documentation?
2015-06-30T19:54:36 <anhhuynx> Would updating it change anything?
2015-06-30T19:55:05 <jamielennox> anhhuynx: we consider that doc to be the complete list of what keystone can do and it's where we nitpick over the high level change
2015-06-30T19:55:35 <jamielennox> so no, changing it won't actually do anything but people won't let you merge the keystone review until the spec change has been approved
2015-06-30T19:55:54 <anhhuynx> Ok, so if I want to add any functionality I better be documenting it?
2015-06-30T19:56:10 <jamielennox> in this case it's really unlikely anyone will say no to the change so you can absolutely work on all of this in parallel
2015-06-30T19:56:40 <jamielennox> yep, if it's part of the public API it has to exist in that doc

[Anh Huynh (anhx-huynh)]

[14:16] <anhhuynx> jamielennox: so Jamie, I was looking at: https://github.com/openstack/keystone/blob/master/keystone/credential/controllers.py#L84-L90
[14:17] <anhhuynx> jamielennox: Do you think that by adding @controller.filterprotected('type') I would be going down the right path?
[14:25] <+jamielennox> anhhuynx: that would be the first step and make keystone actually accept the type flag
[14:25] <+jamielennox> anhhuynx: i think you would need to modify the driver hints as well and the DB call so that when you query the database you do so based on that type
[14:26] <+jamielennox> anhhuynx: but yes - you're in the right place

[Anh Huynh (anhx-huynh)]

Blocked by this bug: https://bugs.launchpad.net/keystone/+bug/1473489

[PRAVAR JAWALEKAR (pravar3088)]

I want to start contributing to keystone - and for that I want to fix this bug if nobody is working on it.
I am a newbie so please ignore if i sound stupid but please advise how i can proceed over fixing bugs like this one!

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/208620

[Steve Martinelli (stevemar)]

Also, feel free to update the API too: http://specs.openstack.org/openstack/keystone-specs/api/v3/identity-api-v3.html#list-credentials

we can also use the bug to track the changes against keystoneclient and openstackclient

[Jeremy Stanley (fungi)]

Why has this bug been switched to a security vulnerability? It looks like a normal feature request. Can you elaborate on how this represents a risk which could be exploited by a malicious actor?

[Marianne Linhares Monteiro (mariannelinharesm)]

I'm sorry Jeremy, it was a mistake. I didn't mean to change the security. Sorry, Thanks for the comment!

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/208620
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=4c9a5353effd616a2fd7e407c5488ba53e8a2daa
Submitter: Jenkins
Branch: master

commit 4c9a5353effd616a2fd7e407c5488ba53e8a2daa
Author: mari-linhares <email address hidden>
Date: Mon Aug 3 16:01:25 2015 -0300

    List credentials by type

    Currently the only attribute that you can filter a credential list by is
    user_id. I want to be able to list by user_id and credential type (a
    required field) so that I only get back my EC2 credentials (for example)
    when I do a list.

    Change-Id: I91f8fb15a2e9a8326059d7a60d2bf1b4c4aa6daa
    Closes-bug: #1460492
    bp list-credentials-by-type

[Nate Potter (ntpttr)]

Hi everyone, I'm still relatively new to OpenStack contribution and I'd like to get started with adding this feature to the python-keystoneclient and the python-openstack client if that's all right. I'm wondering what CLI command I can use to test it - in the keystone client all I'm seeing is ec2-credentials-list (from the v2 API) and in the openstack client I see 'openstack ec2 credentials list', neither of which seem to be the list function in /v3/credentials.py on GitHub. Do I need to update anything to use the v3 API, or should installing devstack make it available to me? Thanks!

[Nate Potter (ntpttr)]

Also, was it just a documentation change that was needed for the clients or are there any changes needed to the actual python code? I don't have a lot of experience with Keystone but it looks like passing type in to **kwargs would just work now with the change made to keystone. If that's the case isn't the doc change already made here http://specs.openstack.org/openstack/keystone-specs/api/v3/identity-api-v3.html#list-credentials? Sorry for the confusion, just wanting to see if there's anything left to be done.

[Lin Hua Cheng (lin-hua-cheng)]

Hi Nathaniel.,

There are still some work needed in OpenStackClient, to expose the Type filter to the user:

https://github.com/openstack/python-openstackclient/blob/master/openstackclient/identity/v3/credential.py#L101

[Steve Martinelli (stevemar)]

removing assignees due to inactivity

[Steve Martinelli (stevemar)]

Automatically unassigning due to inactivity.

[Steve Martinelli (stevemar)]

Anyone want to patch keystoneclient, this is a relatively easy fix, just need to add "type" to the list function.

[Kyrylo Romanenko (kromanenko)]

Now there is command in OSC to get only EC2 creds: openstack ec2 credentials list.
So, can we consider this wishlist is fulfilled?

[Lance Bragstad (lbragstad)]

I think this could be marked as Fix Released for openstackclient. The implementation [0] landed several months ago but it was never tagged against this bug.

[0] https://github.com/openstack/python-openstackclient/commit/15d3717e733aec9e8b6526a1abffd62f2da1e32b

[Lance Bragstad (lbragstad)]

Actually - I shouldn't have closed this. Keystone doesn't restrict credential type to only `ec2` and `cert`, which is what I was thinking it did. If that were the case we would be able to list credentials by all supported types. But since that isn't the case we should still keep this open for openstackclient. An example would be creating a credential of type `totp` to use for multifactor authentication. Example of creating credentials with `totp` types can be found in our documentation [0].

[0] http://docs.openstack.org/developer/keystone/auth-totp.html