Ask Your Question
0

mixing authentication methods within a domain

asked 2015-03-26 15:40:02 -0600

pentatonic gravatar image

I'm trying to figure out if it is possible with Juno Keystone to do the following:

Have a domain with a domain specific keystone.domain-name.conf file which points to a particular idp (for example ldap, or some custom built identity driver)

But allow users to user EITHER external auth or password auth in that domain. Not both.

For example, say my identity driver points to an LDAP configuration. But I have a special admin that I want to authenticate with say x509 client certificates.

Can I have essentially this in the conf file: methods=external, password

But...

I want all regular users to be able to authenticate with password, which will go against the LDAP backend. But I want the admin user to exclusively be authenticatable through x509. I don't want him to have a password, or have to set his password to some bogus value that potentially could be modified.

I think the 2 methods can coexist but that there is no way to target certain users to be forced to use one auth method versus the other, am I wrong?

edit retag flag offensive close merge delete
add a comment

2 answers

Sort by ยป oldest newest most voted
0

answered 2015-03-26 18:01:44 -0600

Haneef Ali gravatar image

How is cert based auth going to get the tenant name? Unless you are using scoped token you are not going to get roles and you can't do anything. Ofcourse you can bypass this by using custom code.. To answer your question, you can do this juno via custom code

Better way to do this, is as follows 1) Move your admin user to new domain 2) Authenticate him using cert 3) Regular users are part of LDAP domain

Check this out as it is not part of kilo. It will be in liberty https://github.com/openstack/keystone... https://review.openstack.org/#/c/156870/

edit flag offensive delete link more
add a comment
0

answered 2015-03-27 10:46:52 -0600

pentatonic gravatar image

Thank you, the upcoming tokenless authz changes sound very good.

To answer your question, the project or domain scope in my case, were going to be given the same way as they usually are, through the token request. Meaning, I would have method=external, and scope=domainx.

What I'm trying to find out is, even with the Liberty changes, since the user (even one backed by x509 client auth) has to exist (in order for Keystone to assign roles to it) in the Keystone backend, technically he could have a password.

It means I could authenticate this user using the password method and go around the x509 authentication.

I'm trying to see if, within a domain, I can force external only for some users and external or password for others.

If not, can I have domain specific configuration where a domain is fully auth=external (and exclusively), and another domain is auth=password ? I tried and it didn't seem to work as I expected but I may have made mistakes; just trying to see if it's supposed to work.

So I could have my x509 admin user that would have some bogus password but that password would never be allowed as an authentication method.

edit flag offensive delete link more

Comments

I may need to double check once it is implemented, X509 user doesn't need to exist. It is handled similar to federation where the federated user doesn't exist in keystone

Haneef Ali gravatar imageHaneef Ali ( 2015-03-27 12:13:55 -0600 )edit

Ah I see.Yes it would make sense. And I guess then this admin user would get mapped to a group at runtime and the group would have pre-assigned roles (like with OS-FEDERATION). The user itself absolutely doesn't exist in Keystone at all.In Juno, I don't think one can do what I'm suggesting right?

pentatonic gravatar imagepentatonic ( 2015-03-27 12:40:44 -0600 )edit

Yes. you nailed it

Haneef Ali gravatar imageHaneef Ali ( 2015-03-27 12:44:41 -0600 )edit
add a comment

Get to know Ask OpenStack

Resources for moderators

Question Tools

1 follower

subscribe to rss feed

Stats

Asked: 2015-03-26 15:40:02 -0600

Seen: 179 times

Last updated: Mar 27 '15