Bug 1191210 - [AAA] API.users.get() does not work for new users who do not logged in yet (org.ovirt.engine-extensions.aaa.ldap)
Summary: [AAA] API.users.get() does not work for new users who do not logged in yet (o...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine-restapi
Version: 3.5.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: 3.6.0
Assignee: Yair Zaslavsky
QA Contact: Ondra Machacek
URL:
Whiteboard: infra
Depends On:
Blocks: oVirt-AAA-rewrite
TreeView+ depends on / blocked
 
Reported: 2015-02-10 17:13 UTC by Petr Spacek
Modified: 2016-02-10 19:27 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-02-23 14:27:21 UTC
oVirt Team: Infra
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Petr Spacek 2015-02-10 17:13:38 UTC
Description of problem:
Python API is not able to get users from org.ovirt.engine-extensions.aaa.ldap if the user did not logged in.

Version-Release number of selected component (if applicable):
RHEV-M 3.5.0-0.31.el6ev
rhevm-sdk-python-3.5.0.8-2.el6ev.noarch

How reproducible:
100 %

Steps to Reproduce:
1. Configure org.ovirt.engine-extensions.aaa.ldap:
# /etc/ovirt-engine/extensions.d/ldap-authz-corp.properties
ovirt.engine.extension.enabled = true
ovirt.engine.extension.name = ldap-authz-corp
ovirt.engine.extension.bindings.method = jbossmodule
ovirt.engine.extension.binding.jbossmodule.module = org.ovirt.engine-extensions.aaa.ldap
ovirt.engine.extension.binding.jbossmodule.class = org.ovirt.engineextensions.aaa.ldap.AuthzExtension
ovirt.engine.extension.provides = org.ovirt.engine.api.extensions.aaa.Authz
config.profile.file.1 = /etc/ovirt-engine/ldap-corp.properties

# /etc/ovirt-engine/ldap-corp.properties
include = <rhds.properties>

vars.user = ''
vars.password = ''
vars.domain = redhat.com
vars.server = ldap.corp.redhat.com

pool.default.serverset.single.server = ${global:vars.server}
pool.default.serverset.single.port = 389
pool.default.ssl.enable = false
pool.default.ssl.insecure = true

2. user Python SDK to connect to API
3. try to gen an user which exists in LDAP but did not logger-in to RHEV-M previously

Actual results:
>>> type(api)
<class 'ovirtsdk.api.API'>

>>> print(api.users.get('amarecek@ldap-authz-corp'))
None

>>> print(api.users.get('amarecek'))
None


Explicit user of id= or name= does not make any difference.

Expected results:
api.users.get() should be able to get all users defined in LDAP.

Additional info:
There are two main use cases for this:
- New user provisioning/onboarding process: Set of VMs is created for given user and he is automatically assigned permissions as soon as the account is created in LDAP. This allows the user to start working immediatelly after first log-in without waiting for RHEV-M admin.

- Mass migration/re-assignment of VMs after authz/n changes.

Comment 1 Alon Bar-Lev 2015-02-23 08:35:31 UTC
not sure I understand.

a user is added to system by sysadmin, up until then it is not available within application as it should as the application is not a replication of the directory.

up to 3.6 because of incorrect design, the user was added to the repository when login, this will be removed in 3.6 in favor of a session credentials. only  users/groups who actually assigned a permissions will exist within application repository (permissions).

you can list users using the api within the /domains/xxx/users and add them to /users.

Comment 2 Petr Spacek 2015-02-23 09:06:25 UTC
My main problem is that I need to use API to assign permissions to users which exist in directory but not logged into RHEV-M yet. As far as I can tell, it is not possible in RHEV 3.5 and this is a major pain point for practical usage of the user portal.

I wanted to call API.users.get() to get the correct user object and use this object for permission adding.

In Python SDK I tried to do something like this:

role = api.roles.get('UserVmManager')
user = api.users.get('login = %s' % username)
admin_vm_manager_perm = params.Permission(role=role, user=user)
vm.permissions.add(admin_vm_manager_perm)

Maybe I'm using incorrect API calls. Can you point me to docs which say how this should be implemented, please? Thank you!

Comment 3 Ondra Machacek 2015-02-23 09:07:33 UTC
(In reply to Petr Spacek from comment #2)
> My main problem is that I need to use API to assign permissions to users
> which exist in directory but not logged into RHEV-M yet. As far as I can
> tell, it is not possible in RHEV 3.5 and this is a major pain point for
> practical usage of the user portal.
> 

you can use groups

Comment 4 Petr Spacek 2015-02-23 09:09:42 UTC
Unfortunatelly I can't because there is no appropriate group in the directory. The vm is 'private' for the paricular user.

Comment 5 Alon Bar-Lev 2015-02-23 09:31:51 UTC
I do not know how to do this via the python interface.

By using the /domains/<id>/users you can get the user and then post it into /users, then the user will be available for you to assign permission to.

Comment 6 Ondra Machacek 2015-02-23 09:32:59 UTC
then to add user you have to:

domain = params.Domain(name='redhat.com')
user = params.User(user_name='userX', domain=domain)
user = API.users.add(user)
role = api.roles.get('UserVmManager')
admin_vm_manager_perm = params.Permission(role=role, user=user)
vm.permissions.add(admin_vm_manager_perm)

Comment 7 Petr Spacek 2015-02-23 13:57:02 UTC
Thank you Ondra, API.users.add() did the trick.

I have to say that it is kind of unexpected that admin have to 'add' users because users are defined in the directory. My expectation was that I should be able to assign rights to any user who exists in directory.

By analogy, you do not have to 'add' user to every unix system after adding user to LDAP server used for authentication :-)

Comment 8 Alon Bar-Lev 2015-02-23 14:27:21 UTC
You are right that it is unexpected, this is part of legacy implementation. For backward compatibility it is very hard to remove the user storage from application as it will break most of the api.

In 3.6 we stopped using the users table, which is a step forward in the right direction.


Note You need to log in before you can comment on or make changes to this bug.