Description of problem: currently I am not able to add a "local" user to ovirt. So if I just need a read only user for monitoring or other purposes I need to setup or attach a full blown LDAP/IPA or AD server Version-Release number of selected component (if applicable): How reproducible: always Steps to Reproduce: 1. 2. 3. Actual results: you need to setup a complete directory server for just read only access via api Expected results: ship a preconfigured user which has only login permissions. This should still be possible to add in 3.4 as it should be a very little change! Additional info: See this thread on users ML: http://lists.ovirt.org/pipermail/users/2013-November/017946.html
(In reply to Sven Kieske from comment #0) > Description of problem: > currently I am not able to add a "local" user to ovirt. > So if I just need a read only user for monitoring or other purposes > I need to setup or attach a full blown LDAP/IPA or AD server > > Actual results: > you need to setup a complete directory server for just read only access via > api > > Expected results: > ship a preconfigured user which has only login permissions. > Sven, login only may not be sufficient in terms of the information available for this user. Can you please specify if this user should see all available information (similar to admin), or specific entities / stats?
The user should be able to see everything, like admin. This would be huge if it could get included, thank you!
discussed here as well: http://lists.ovirt.org/pipermail/users/2014-February/021631.html
I do not think it can be included in 3.4, apart from the user addition in the engine side, support for setting the new read-only user should be added in the engine setup site. IMHO to late for 3.4 Alon?
(In reply to Eli Mesika from comment #4) > I do not think it can be included in 3.4, apart from the user addition in > the engine side, support for setting the new read-only user should be added > in the engine setup site. > > IMHO to late for 3.4 > > Alon? I do not know enough the permission model of ovirt-engine, can we have a user that sees all objects and cannot perform any change? is that supported if I, for example, add simple local openldap? If that is possible, there is a solution for 3.3 and up, right? In any case, such user will not be created automatically but explicitly by admin, I guess that it will be done in future using jdbc directory provider.
(In reply to Alon Bar-Lev from comment #5) > I do not know enough the permission model of ovirt-engine, can we have a > user that sees all objects and cannot perform any change? is that supported > if I, for example, add simple local openldap? Yes https://bugzilla.redhat.com/show_bug.cgi?id=1038222
(In reply to Eli Mesika from comment #6) > (In reply to Alon Bar-Lev from comment #5) > > > I do not know enough the permission model of ovirt-engine, can we have a > > user that sees all objects and cannot perform any change? is that supported > > if I, for example, add simple local openldap? > > Yes > bug#1038222 So, there is a simple solution since 3.3, just install local ldap server with single user and use this user for api.
(In reply to Alon Bar-Lev from comment #7) > (In reply to Eli Mesika from comment #6) > > (In reply to Alon Bar-Lev from comment #5) > > > > > I do not know enough the permission model of ovirt-engine, can we have a > > > user that sees all objects and cannot perform any change? is that supported > > > if I, for example, add simple local openldap? > > > > Yes > > bug#1038222 > > So, there is a simple solution since 3.3, just install local ldap server > with single user and use this user for api. hmmm... yair... to avoid kerberos, I remember that you have some setting to use simple bind... right?
(In reply to Alon Bar-Lev from comment #8) > (In reply to Alon Bar-Lev from comment #7) > > (In reply to Eli Mesika from comment #6) > > > (In reply to Alon Bar-Lev from comment #5) > > > > > > > I do not know enough the permission model of ovirt-engine, can we have a > > > > user that sees all objects and cannot perform any change? is that supported > > > > if I, for example, add simple local openldap? > > > > > > Yes > > > bug#1038222 > > > > So, there is a simple solution since 3.3, just install local ldap server > > with single user and use this user for api. > > hmmm... yair... to avoid kerberos, I remember that you have some setting to > use simple bind... right? SIMPLE is not supported for several versions now...
(In reply to Yair Zaslavsky from comment #9) > > hmmm... yair... to avoid kerberos, I remember that you have some setting to > > use simple bind... right? > > SIMPLE is not supported for several versions now... Not even in some debug option?
(In reply to Alon Bar-Lev from comment #10) > (In reply to Yair Zaslavsky from comment #9) > > > hmmm... yair... to avoid kerberos, I remember that you have some setting to > > > use simple bind... right? > > > > SIMPLE is not supported for several versions now... > > Not even in some debug option? It would be too hacky IMHO. You will need to change one of the entries at vdc_options to mark that for a given domain you would like to use SIMPLE, and even with that I'm not 100% sure it will work.
(In reply to Alon Bar-Lev from comment #7) > (In reply to Eli Mesika from comment #6) > > (In reply to Alon Bar-Lev from comment #5) > > > > > I do not know enough the permission model of ovirt-engine, can we have a > > > user that sees all objects and cannot perform any change? is that supported > > > if I, for example, add simple local openldap? > > > > Yes > > bug#1038222 > > So, there is a simple solution since 3.3, just install local ldap server > with single user and use this user for api. I think our understanding about what is "simple" (complete LDAP + Kerberos) really differ a lot. Also keep in mind: (In reply to Yair Zaslavsky from comment #9) > SIMPLE is not supported for several versions now... ;) To be more specific: What this RFE asks for is not a method to plugin outside authentication, but a _builtin_ user. What would be less cool, but still not that much work like a full LDAP (which you have to secure, patch, etc.) would be an additional local unix user in e.g. /etc/passwd To reiterate: I was asking for a simple read only user role which works out of the box, or nearly out of the box instead of connecting to an LDAP or AD. You tell me to install an LDAP Server. Thats more like taking a sledgehammer to crack a nut, you know? Thanks for your efforts so far, anyway!
(In reply to Sven Kieske from comment #12) > I was asking for a simple read only user role which works out of the box I do not know what is user that works out of the box. Setup will perform the minimum tasks to have engine up and running, as far as users are involved, it will only set up admin user. From this point the admin can customize the product as he sees fit, including adding additional users with specific attributes. As written in previous corresponding, the ability to extend the authentication and authorization is scheduled for 3.5, the steps would probably: 1. add jdbc authentication and authorization providers 2. create a table for its usage 3. add users. Maybe we will have enough time to replace the internal authentication and authorization provider that supports only admin with that extension, not in priority compared to having proper LDAP interaction.
Replacing the "internal" provider with a provider that is capable of managing local users will solve this as well, dup of bug#1076971. *** This bug has been marked as a duplicate of bug 1076971 ***