On 04/17/2014 07:17 AM, Roman Bodnarchuk wrote:
Hello,
Right now I am trying to set-up a self-signup for users of our
OpenStack cloud. One of the essential points of this signup is
verification of user's email address - until a user proves that this
address belongs to him/her, he/she should not be able to do anything
useful in the cloud.
In the same time, a partial access to the cloud is very desirable - at
minimum, a user should be able to authenticate to Keystone and
successfully obtain a token, but should not be able to change anything
in other services or access information of other users.
It is possible to disable a user with corresponding field in User
model, but this will not let us to use Keystone as a source of
authentication data (Keystone returns 401 for request to /auth/token
with credentials of disabled user).
Other way to do this would be to created a special role like
`unconfirmed` for a default project/domain, and assign it to users
with unconfirmed email (this will be the only role assigned for
them). Thus, it will be possible to authenticate them, but they won't
able to use the system.
I think this is the right approach.
So, the question - does this approach make sense? Are there any
dangerous resources in OpenStack, which user with auth token and some
"unknown" role can access?
Yes, depending on the policy file. But it should only be restricted to
a specific project/tenant.
You could further develop the policy file such that "unconfirmed" can do
a limited set of actions, but what would those actions be?
Any comments about other possible solutions are also welcomed.
Thanks,
Roman
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
