2014-02-10 17:03 GMT+01:00 Kieran Spear <kisp...@gmail.com>: > On 10 February 2014 08:27, Soren Hansen <so...@linux2go.dk> wrote: >> I agree that putting admin credentials on a public web server is a >> security risk, but I'm not sure why a set of restricted admin >> credentials that only allow you to create users and tenants is a >> bigger problem than the credentials for separate registration service >> that performs the exact same operations? > The third (and most dangerous) operation here is the role grant. I > don't think any Keystone policy could be specific enough to prevent > arbitrary member role assignment in this case.
Fair enough. That seems like something we should fix, though. It really seems to me like adding this intermediate service is an overly complicated (although necessary given the current constraints) approach. User registration seems like something that very much falls under Keystone's domain: * Keystone should abstract any and all interaction with the user database. Having another service that adds things directly to MySQL or LDAP seems wrong to me. * Having a component whose only job is to talk to Keystone really screams to me that it ought to be part of Keystone. Perhaps a user registration API extension that lets you pass just username/password/whatever and then it creates the relevant things on the backend in a way that's configured in Keystone. I.e. it validates the request and then creates the user and tenant and grants the appropriate roles. As I see it, if we don't trust Keystone's security, we're *so* screwed anyway. This needs to work. -- Soren Hansen | http://linux2go.dk/ Ubuntu Developer | http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
