Hi, is nobody interested in this feature at all? it would be a huge security gain, while lowering the bars for having a read only user if this could get shipped with 3.4:

Am 19.02.2014 15:32, schrieb Sven Kieske:> I just looked into my test vm with the 3.4 beta > and I can't see such an user there. > > I created an RFE at: https://bugzilla.redhat.com/show_bug.cgi?id=1067036 > > > I really hope this can get included in 3.4 (I know it's late) > as it should be a very very minor change at engine-setup. > > Thanks > > Am 19.02.2014 14:55, schrieb Sven Kieske: >> Hi, >> >> reiterating on this somewhat old mail: >> >> Is there a read only user integrated in 3.4? >> >> Because it's a huge overhead to install somewhere >> e.g. a freeipa server just to get read only access. >> >> Am 21.11.2013 09:52, schrieb Sander Grendelman: >>> Hi Doron, >>> >>> The user I've defined in [1] works for me. >>> A built-in login-/read-only role would be nice, >>> but it's quite easy to define a custom role so >>> more of a nice-to-have instead of a must-have. >>> >>> Thanks for asking! >>> >>> Sander. >>> >>> On Wed, Nov 20, 2013 at 5:40 PM, Doron Fediuck <dfediuck(a)redhat.com&gt; wrote: >>>> Hi Sander, >>>> We're closing the ovirt 3.4 scope, and wondering if you're handling >>>> Zabbix based on [1]. >>>> If so please let me know and I'll update the 3.4 features list. >>>> >>>> Thanks, >>>> Doron >>>> >>>> [1] http://lists.ovirt.org/pipermail/users/2013-November/017946.html >> >

From: "Juan Hernandez" <jhernand(a)redhat.com&gt; To: "Sven Kieske" <S.Kieske(a)mittwald.de&gt;, &quot;Users(a)ovirt.org List" <Users(a)ovirt.org&gt; Cc: "Itamar Heim" <iheim(a)redhat.com&gt;, "Yair Zaslavsky" <yzaslavs(a)redhat.com&gt; Sent: Saturday, February 22, 2014 2:22:14 PM Subject: Re: [Users] API read-only access / roles On 02/20/2014 04:51 PM, Itamar Heim wrote: > On 02/20/2014 05:24 PM, Sven Kieske wrote: >> Hi, >> >> is nobody interested in this feature at all? >> it would be a huge security gain, while lowering >> the bars for having a read only user if this could get shipped with 3.4: > > we are very interested, but we want to do this based on the > authentication re-factoring, which in itself, barely made the 3.4 timeline. > Yair - are we "pluggable" yet, that someone could add such a user by > dropping a jar somewhere, or still on going work towards 3.5?

> Pugglability of authentication already works in 3.4. By default it uses the previous mechanism, but the administrator can change this. In order to change you need to create the /etc/ovirt-engine/auth.conf.d directory and then create inside one or more "authentication profiles" configuration files. An authentication profile is a combination of an "authenticator" and a "directory". The authenticator is used to check the credentials (the user name and password) and the "directory" is used to search users and their details. For example, if you want to use local authentication (the users, passwords, and groups of the OS) you can create a "local.conf" file with the following content: # # The name of the profile. This is what will be displayed in the # combo box in the login page. # name=local # # Needed to enable the profile, by default all profiles are # disabled. # enabled=true # # The configuration of the authenticator used by the profile. The # type and the module are mandatory, the rest are optional and # the default values are as shown below. # authenticator.type=ssh authenticator.module=org.ovirt.engine.core.authentication.ssh # authenticator.host=localhost # authenticator.port=22 # authenticator.timeout=10 # # The configuration of the directory: # directory.type=nss directory.module=org.ovirt.engine.core.authentication.nss For this to work you need to install some additional modules, which aren't currently part of the engine. This is where plugabillity comes in place. This modules can be built externally. I created modules for SSH authentication and NSS (Name Service Switch) directory. The source is available here: https://github.com/jhernand/ovirt-engine-ssh-authenticator https://github.com/jhernand/ovirt-engine-nss-directory The NSS directory also needs JNA (Java Native Access): https://github.com/jhernand/ovirt-engine-jna-module Installing these extensions is very easy, just build from source and uncompress the generated .zip files to /usr/share/ovirt-engine/modules. In case you don't want to build from source you can use the RPMs that I created. The source for the .spec files is here: https://github.com/jhernand/ovirt-engine-rpms If you don't want to build form source you can use a yum repository that I created with binaries for Fedora 20 (should work in CentOS as well): http://jhernand.fedorapeople.org/repo So, to summarize: # cat > /etc/yum.repos.d/my.repo <<. [my] name=my baseurl=http://jhernand.fedorapeople.org/repo enabled=1 gpgcheck=0 . # yum -y install \ ovirt-engine-ssh-authenticator \ ovirt-engine-nss-directory # mkdir -p /etc/ovirt-engine/auth.conf.d # cat > /etc/ovirt-engine/auth.conf.d/local.conf <<. name=local enabled=true authenticator.type=ssh authenticator.module=org.ovirt.engine.core.authentication.ssh directory.type=nss directory.module=org.ovirt.engine.core.authentication.nss . # systemctl restart ovirt-engine Then you can login with admin@internal, add some local users and permissions, and then use them to login to the GUI or the API. Take into account that I created these modules as a way to test the new authentication infrastructure, so they may have limitations or issues. I appreciate any feedback. >> >> Am 19.02.2014 15:32, schrieb Sven Kieske:> I just looked into my test vm >> with the 3.4 beta >>> and I can't see such an user there. >>> >>> I created an RFE at: https://bugzilla.redhat.com/show_bug.cgi?id=1067036 >>> >>> >>> I really hope this can get included in 3.4 (I know it's late) >>> as it should be a very very minor change at engine-setup. >>> >>> Thanks >>> >>> Am 19.02.2014 14:55, schrieb Sven Kieske: >>>> Hi, >>>> >>>> reiterating on this somewhat old mail: >>>> >>>> Is there a read only user integrated in 3.4? >>>> >>>> Because it's a huge overhead to install somewhere >>>> e.g. a freeipa server just to get read only access. >>>> >>>> Am 21.11.2013 09:52, schrieb Sander Grendelman: >>>>> Hi Doron, >>>>> >>>>> The user I've defined in [1] works for me. >>>>> A built-in login-/read-only role would be nice, >>>>> but it's quite easy to define a custom role so >>>>> more of a nice-to-have instead of a must-have. >>>>> >>>>> Thanks for asking! >>>>> >>>>> Sander. >>>>> >>>>> On Wed, Nov 20, 2013 at 5:40 PM, Doron Fediuck <dfediuck(a)redhat.com&gt; >> wrote: >>>>>> Hi Sander, >>>>>> We're closing the ovirt 3.4 scope, and wondering if you're handling >>>>>> Zabbix based on [1]. >>>>>> If so please let me know and I'll update the 3.4 features list. >>>>>> >>>>>> Thanks, >>>>>> Doron >>>>>> >>>>>> [1] http://lists.ovirt.org/pipermail/users/2013-November/017946.html >>>> >>> > > _______________________________________________ > Users mailing list > Users(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/users > -- Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta 3ºD, 28016 Madrid, Spain Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.

From: "Yair Zaslavsky" <yzaslavs(a)redhat.com&gt; To: "Juan Hernandez" <jhernand(a)redhat.com&gt; Cc: "Sven Kieske" <S.Kieske(a)mittwald.de&gt;, &quot;Users(a)ovirt.org List" <Users(a)ovirt.org&gt;, "Itamar Heim" <iheim(a)redhat.com&gt;, "Alon Bar-Lev" <alonbl(a)redhat.com&gt; Sent: Sunday, February 23, 2014 8:55:07 AM Subject: Re: [Users] API read-only access / roles ----- Original Message ----- > From: "Juan Hernandez" <jhernand(a)redhat.com&gt; > To: "Sven Kieske" <S.Kieske(a)mittwald.de&gt;, &quot;Users(a)ovirt.org List" > <Users(a)ovirt.org&gt; > Cc: "Itamar Heim" <iheim(a)redhat.com&gt;, "Yair Zaslavsky" > <yzaslavs(a)redhat.com&gt; > Sent: Saturday, February 22, 2014 2:22:14 PM > Subject: Re: [Users] API read-only access / roles > > On 02/20/2014 04:51 PM, Itamar Heim wrote: > > On 02/20/2014 05:24 PM, Sven Kieske wrote: > >> Hi, > >> > >> is nobody interested in this feature at all? > >> it would be a huge security gain, while lowering > >> the bars for having a read only user if this could get shipped with 3.4: > > > > we are very interested, but we want to do this based on the > > authentication re-factoring, which in itself, barely made the 3.4 > > timeline. > > Yair - are we "pluggable" yet, that someone could add such a user by > > dropping a jar somewhere, or still on going work towards 3.5? As Juan mentioned in his email, it should be possible to plug in at 3.4 as well. However, we're changing the configuration format at 3.5 as we're changing the mechanism to use the extensions mechanism - both Directory and Authenticator are extensions, the configuration for directory (authorization extension) and authenciator (authentication extension) will look a bit different.

> > > > Pugglability of authentication already works in 3.4. By default it uses > the previous mechanism, but the administrator can change this. In order > to change you need to create the /etc/ovirt-engine/auth.conf.d directory > and then create inside one or more "authentication profiles" > configuration files. An authentication profile is a combination of an > "authenticator" and a "directory". The authenticator is used to check > the credentials (the user name and password) and the "directory" is used > to search users and their details. For example, if you want to use local > authentication (the users, passwords, and groups of the OS) you can > create a "local.conf" file with the following content: > > # > # The name of the profile. This is what will be displayed in the > # combo box in the login page. > # > name=local > > # > # Needed to enable the profile, by default all profiles are > # disabled. > # > enabled=true > > # > # The configuration of the authenticator used by the profile. The > # type and the module are mandatory, the rest are optional and > # the default values are as shown below. > # > authenticator.type=ssh > authenticator.module=org.ovirt.engine.core.authentication.ssh > # authenticator.host=localhost > # authenticator.port=22 > # authenticator.timeout=10 > > # > # The configuration of the directory: > # > directory.type=nss > directory.module=org.ovirt.engine.core.authentication.nss > > For this to work you need to install some additional modules, which > aren't currently part of the engine. This is where plugabillity comes in > place. This modules can be built externally. I created modules for SSH > authentication and NSS (Name Service Switch) directory. The source is > available here: > > https://github.com/jhernand/ovirt-engine-ssh-authenticator > https://github.com/jhernand/ovirt-engine-nss-directory > > The NSS directory also needs JNA (Java Native Access): > > https://github.com/jhernand/ovirt-engine-jna-module > > Installing these extensions is very easy, just build from source and > uncompress the generated .zip files to /usr/share/ovirt-engine/modules. > In case you don't want to build from source you can use the RPMs that I > created. The source for the .spec files is here: > > https://github.com/jhernand/ovirt-engine-rpms > > If you don't want to build form source you can use a yum repository that > I created with binaries for Fedora 20 (should work in CentOS as well): > > http://jhernand.fedorapeople.org/repo > > So, to summarize: > > # cat > /etc/yum.repos.d/my.repo <<. > [my] > name=my > baseurl=http://jhernand.fedorapeople.org/repo > enabled=1 > gpgcheck=0 > . > > # yum -y install \ > ovirt-engine-ssh-authenticator \ > ovirt-engine-nss-directory > > # mkdir -p /etc/ovirt-engine/auth.conf.d > > # cat > /etc/ovirt-engine/auth.conf.d/local.conf <<. > name=local > enabled=true > authenticator.type=ssh > authenticator.module=org.ovirt.engine.core.authentication.ssh > directory.type=nss > directory.module=org.ovirt.engine.core.authentication.nss > . > > # systemctl restart ovirt-engine > > Then you can login with admin@internal, add some local users and > permissions, and then use them to login to the GUI or the API. > > Take into account that I created these modules as a way to test the new > authentication infrastructure, so they may have limitations or issues. I > appreciate any feedback. > > >> > >> Am 19.02.2014 15:32, schrieb Sven Kieske:> I just looked into my test vm > >> with the 3.4 beta > >>> and I can't see such an user there. > >>> > >>> I created an RFE at: > >>> https://bugzilla.redhat.com/show_bug.cgi?id=1067036 > >>> > >>> > >>> I really hope this can get included in 3.4 (I know it's late) > >>> as it should be a very very minor change at engine-setup. > >>> > >>> Thanks > >>> > >>> Am 19.02.2014 14:55, schrieb Sven Kieske: > >>>> Hi, > >>>> > >>>> reiterating on this somewhat old mail: > >>>> > >>>> Is there a read only user integrated in 3.4? > >>>> > >>>> Because it's a huge overhead to install somewhere > >>>> e.g. a freeipa server just to get read only access. > >>>> > >>>> Am 21.11.2013 09:52, schrieb Sander Grendelman: > >>>>> Hi Doron, > >>>>> > >>>>> The user I've defined in [1] works for me. > >>>>> A built-in login-/read-only role would be nice, > >>>>> but it's quite easy to define a custom role so > >>>>> more of a nice-to-have instead of a must-have. > >>>>> > >>>>> Thanks for asking! > >>>>> > >>>>> Sander. > >>>>> > >>>>> On Wed, Nov 20, 2013 at 5:40 PM, Doron Fediuck <dfediuck(a)redhat.com&gt; > >> wrote: > >>>>>> Hi Sander, > >>>>>> We're closing the ovirt 3.4 scope, and wondering if you're handling > >>>>>> Zabbix based on [1]. > >>>>>> If so please let me know and I'll update the 3.4 features list. > >>>>>> > >>>>>> Thanks, > >>>>>> Doron > >>>>>> > >>>>>> [1] http://lists.ovirt.org/pipermail/users/2013-November/017946.html > >>>> > >>> > > > > _______________________________________________ > > Users mailing list > > Users(a)ovirt.org > > http://lists.ovirt.org/mailman/listinfo/users > > > > > -- > Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta > 3ºD, 28016 Madrid, Spain > Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L. >

----- Original Message ----- > From: "Yair Zaslavsky" <yzaslavs(a)redhat.com&gt; > To: "Juan Hernandez" <jhernand(a)redhat.com&gt; > Cc: "Sven Kieske" <S.Kieske(a)mittwald.de&gt;, &quot;Users(a)ovirt.org List" <Users(a)ovirt.org&gt;, "Itamar Heim" <iheim(a)redhat.com&gt;, > "Alon Bar-Lev" <alonbl(a)redhat.com&gt; > Sent: Sunday, February 23, 2014 8:55:07 AM > Subject: Re: [Users] API read-only access / roles > > > > ----- Original Message ----- >> From: "Juan Hernandez" <jhernand(a)redhat.com&gt; >> To: "Sven Kieske" <S.Kieske(a)mittwald.de&gt;, &quot;Users(a)ovirt.org List" >> <Users(a)ovirt.org&gt; >> Cc: "Itamar Heim" <iheim(a)redhat.com&gt;, "Yair Zaslavsky" >> <yzaslavs(a)redhat.com&gt; >> Sent: Saturday, February 22, 2014 2:22:14 PM >> Subject: Re: [Users] API read-only access / roles >> >> On 02/20/2014 04:51 PM, Itamar Heim wrote: >>> On 02/20/2014 05:24 PM, Sven Kieske wrote: >>>> Hi, >>>> >>>> is nobody interested in this feature at all? >>>> it would be a huge security gain, while lowering >>>> the bars for having a read only user if this could get shipped with 3.4: >>> >>> we are very interested, but we want to do this based on the >>> authentication re-factoring, which in itself, barely made the 3.4 >>> timeline. >>> Yair - are we "pluggable" yet, that someone could add such a user by >>> dropping a jar somewhere, or still on going work towards 3.5? > > As Juan mentioned in his email, it should be possible to plug in at 3.4 as > well. > However, we're changing the configuration format at 3.5 as we're changing the > mechanism to use the extensions mechanism - both Directory and Authenticator > are extensions, the configuration for > directory (authorization extension) and authenciator (authentication > extension) will look a bit different. Hello, Until we announce public interface for aaa (authentication, authorization, accounting) the implementation is internal and should not be used by external projects. We are heading for publishing the interface within 3.5 timeline. Thanks, Alon > > > > >>> >> >> Pugglability of authentication already works in 3.4. By default it uses >> the previous mechanism, but the administrator can change this. In order >> to change you need to create the /etc/ovirt-engine/auth.conf.d directory >> and then create inside one or more "authentication profiles" >> configuration files. An authentication profile is a combination of an >> "authenticator" and a "directory". The authenticator is used to check >> the credentials (the user name and password) and the "directory" is used >> to search users and their details. For example, if you want to use local >> authentication (the users, passwords, and groups of the OS) you can >> create a "local.conf" file with the following content: >> >> # >> # The name of the profile. This is what will be displayed in the >> # combo box in the login page. >> # >> name=local >> >> # >> # Needed to enable the profile, by default all profiles are >> # disabled. >> # >> enabled=true >> >> # >> # The configuration of the authenticator used by the profile. The >> # type and the module are mandatory, the rest are optional and >> # the default values are as shown below. >> # >> authenticator.type=ssh >> authenticator.module=org.ovirt.engine.core.authentication.ssh >> # authenticator.host=localhost >> # authenticator.port=22 >> # authenticator.timeout=10 >> >> # >> # The configuration of the directory: >> # >> directory.type=nss >> directory.module=org.ovirt.engine.core.authentication.nss >> >> For this to work you need to install some additional modules, which >> aren't currently part of the engine. This is where plugabillity comes in >> place. This modules can be built externally. I created modules for SSH >> authentication and NSS (Name Service Switch) directory. The source is >> available here: >> >> https://github.com/jhernand/ovirt-engine-ssh-authenticator >> https://github.com/jhernand/ovirt-engine-nss-directory >> >> The NSS directory also needs JNA (Java Native Access): >> >> https://github.com/jhernand/ovirt-engine-jna-module >> >> Installing these extensions is very easy, just build from source and >> uncompress the generated .zip files to /usr/share/ovirt-engine/modules. >> In case you don't want to build from source you can use the RPMs that I >> created. The source for the .spec files is here: >> >> https://github.com/jhernand/ovirt-engine-rpms >> >> If you don't want to build form source you can use a yum repository that >> I created with binaries for Fedora 20 (should work in CentOS as well): >> >> http://jhernand.fedorapeople.org/repo >> >> So, to summarize: >> >> # cat > /etc/yum.repos.d/my.repo <<. >> [my] >> name=my >> baseurl=http://jhernand.fedorapeople.org/repo >> enabled=1 >> gpgcheck=0 >> . >> >> # yum -y install \ >> ovirt-engine-ssh-authenticator \ >> ovirt-engine-nss-directory >> >> # mkdir -p /etc/ovirt-engine/auth.conf.d >> >> # cat > /etc/ovirt-engine/auth.conf.d/local.conf <<. >> name=local >> enabled=true >> authenticator.type=ssh >> authenticator.module=org.ovirt.engine.core.authentication.ssh >> directory.type=nss >> directory.module=org.ovirt.engine.core.authentication.nss >> . >> >> # systemctl restart ovirt-engine >> >> Then you can login with admin@internal, add some local users and >> permissions, and then use them to login to the GUI or the API. >> >> Take into account that I created these modules as a way to test the new >> authentication infrastructure, so they may have limitations or issues. I >> appreciate any feedback. >> >>>> >>>> Am 19.02.2014 15:32, schrieb Sven Kieske:> I just looked into my test vm >>>> with the 3.4 beta >>>>> and I can't see such an user there. >>>>> >>>>> I created an RFE at: >>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1067036 >>>>> >>>>> >>>>> I really hope this can get included in 3.4 (I know it's late) >>>>> as it should be a very very minor change at engine-setup. >>>>> >>>>> Thanks >>>>> >>>>> Am 19.02.2014 14:55, schrieb Sven Kieske: >>>>>> Hi, >>>>>> >>>>>> reiterating on this somewhat old mail: >>>>>> >>>>>> Is there a read only user integrated in 3.4? >>>>>> >>>>>> Because it's a huge overhead to install somewhere >>>>>> e.g. a freeipa server just to get read only access. >>>>>> >>>>>> Am 21.11.2013 09:52, schrieb Sander Grendelman: >>>>>>> Hi Doron, >>>>>>> >>>>>>> The user I've defined in [1] works for me. >>>>>>> A built-in login-/read-only role would be nice, >>>>>>> but it's quite easy to define a custom role so >>>>>>> more of a nice-to-have instead of a must-have. >>>>>>> >>>>>>> Thanks for asking! >>>>>>> >>>>>>> Sander. >>>>>>> >>>>>>> On Wed, Nov 20, 2013 at 5:40 PM, Doron Fediuck <dfediuck(a)redhat.com&gt; >>>> wrote: >>>>>>>> Hi Sander, >>>>>>>> We're closing the ovirt 3.4 scope, and wondering if you're handling >>>>>>>> Zabbix based on [1]. >>>>>>>> If so please let me know and I'll update the 3.4 features list. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Doron >>>>>>>> >>>>>>>> [1] http://lists.ovirt.org/pipermail/users/2013-November/017946.html >>>>>> >>>>> >>> >>> _______________________________________________ >>> Users mailing list >>> Users(a)ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/users >>> >> >> >> -- >> Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta >> 3ºD, 28016 Madrid, Spain >> Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L. >> >

Hi, as we now have setup ldap, now the question which never got answered in the first place: 1. which rights do I need for read only access? as stated in BZ just login rights won't suffice.

2. I want to create a user who has just the right to open the vnc/spice connection to every vm, is this possible?

On 03/26/2014 06:16 AM, Sven Kieske wrote: > Hi, > > as we now have setup ldap, now the question which > never got answered in the first place: > > 1. > which rights do I need for read only access? > > as stated in BZ just login rights won't suffice. an admin role with login? why not? i thought we even pre-created such a default read only role by now: Bug 1038222 - [RFE] Read Only Admin role in AP (and you can create one yourself in 3.3 as well iirc)

its not a user. its a system defined role. you can create a user defined role (with a different name) you should do this via the GUI in 3.3, not via the db (then the uuid will be different as well, and no upgrade issues)