We don't use the token to make any other API calls, just to verify the
user's auth credentials.

On Thu, Apr 14, 2016 at 1:36 PM, Fox, Kevin M <[email protected]> wrote:

> Ah. There are scoped and unscoped tokens in keystone. Unscoped ones are
> project-less but can do almost nothing. Project scoped ones usually used.
>
> Most resources in openstack is bound to the project and not the user, so
> hence the need for scoped tokens.
>
> Thanks,
> Kevin
> ------------------------------
> *From:* Jordan Liggitt [[email protected]]
> *Sent:* Thursday, April 14, 2016 9:53 AM
> *To:* Fox, Kevin M; Scott Seago
> *Cc:* Chmouel Boudjnah; OpenShift List Dev
> *Subject:* Re: keystonepasswd auth
>
> I'm not seeing where tenant name is defaulted to the user name. The
> keystone auth request is a password authentication with the user name and
> domain name, which uniquely identifies the user (users belong to domains,
> not tenants/projects)
>
> On Thu, Apr 14, 2016 at 12:20 PM, Fox, Kevin M <[email protected]> wrote:
>
>> keystone v3 renamed tenant to project. Otherwise, should be the same.
>>
>> Thanks,
>> Kevin
>>
>>
>> ------------------------------
>> *From:* [email protected] [
>> [email protected]] on behalf of Jordan Liggitt [
>> [email protected]]
>> *Sent:* Thursday, April 14, 2016 9:16 AM
>> *To:* Chmouel Boudjnah
>> *Cc:* OpenShift List Dev
>> *Subject:* Re: keystonepasswd auth
>>
>> The OpenShift Keystone IDP integration only supports the v3 Keystone API.
>> I don't see any discussion of tenants in the doc for that API (
>> http://developer.openstack.org/api-ref-identity-v3.html)
>>
>>
>>
>> On Thu, Apr 14, 2016 at 12:06 PM, Chmouel Boudjnah <[email protected]>
>> wrote:
>>
>>> Hello,
>>>
>>> I was looking at trying the keystone password authentication. While
>>> there is some missing directive in the documentation :
>>>
>>> https://github.com/openshift/openshift-docs/pull/1902
>>>
>>> things are working and i could properly auth my openshift user with my
>>> keystone username/password.
>>>
>>> The only caveat is that in OpenStack we usually need to specify a
>>> tenant_name/id for the user to auth with, by default if I understand
>>> correctly gophercloud would try to match the provider from the argument
>>> provided :
>>>
>>>
>>> https://github.com/rackspace/gophercloud/blob/e83aa011e019917c7bd951444d61c42431b4d21d/auth_options.go#L10-L11
>>>
>>> which in this case if no tenant_name are specified would do a
>>> tenant_name==user_name like done by default on Rackspace Cloud (gophercloud
>>> is written by rackspace)
>>>
>>> So now the question is how can we improve this and be able to specify a
>>> tenant_name in there? Since most of deployed OpenStack clouds would have
>>> multiple users scoped to different tenants
>>>
>>> We could do some hackery things like having a delimiter like colon : to
>>> be able to split those as tenant_name and user_name which is something we
>>> did on swiftclient sometime ago but that's not very openstackish and was
>>> more of hack that need to be supported forever (i implemented that :(( )
>>>
>>> We could add a switch like --keystone-tenant-name or something but i
>>> guess that would pollute the login if we want to add more stuff.
>>>
>>> Maybe using the openstack environment which is a standard way in
>>> OpenStack for the clients to use would be an option :
>>>
>>>
>>> https://github.com/rackspace/gophercloud/blob/e83aa011e019917c7bd951444d61c42431b4d21d/openstack/auth_env.go#L24
>>>
>>> which would be transparent for the user since they would have only to
>>> download their openrc from openstack dashboard (horizon) and just issue a
>>> oc login to connect (which could be only a fallback to the current method)
>>>
>>> What do you think?
>>>
>>> Cheers,
>>> Chmouel
>>>
>>>
>>>
>>> _______________________________________________
>>> dev mailing list
>>> [email protected]
>>> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>>>
>>>
>>
>
_______________________________________________
dev mailing list
[email protected]
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

Reply via email to