[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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 <Kevin Fox pnnl gov> wrote:
keystone v3 renamed tenant to project. Otherwise, should be the same.

Thanks,
Kevin



From: dev-bounces lists openshift redhat com [dev-bounces lists openshift redhat com] on behalf of Jordan Liggitt [jliggitt redhat com]
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 <chmouel redhat com> wrote:
Hello,

I was looking at trying the keystone password authentication. While there is some missing directive in the documentation :


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 :


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 :


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
dev lists openshift redhat com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]