[Users] API read-only access / roles

Mon Mar 24 17:00:50 UTC 2014

Hi,

will this interface for 3.5 be production ready or
just a first release /draft ?

Would it be possible to add a read only user for 3.4.x releases?

Am 23.02.2014 09:52, schrieb Alon Bar-Lev:
> 
> 
> ----- Original Message -----
>> From: "Yair Zaslavsky" <yzaslavs at redhat.com>
>> To: "Juan Hernandez" <jhernand at redhat.com>
>> Cc: "Sven Kieske" <S.Kieske at mittwald.de>, "Users at ovirt.org List" <Users at ovirt.org>, "Itamar Heim" <iheim at redhat.com>,
>> "Alon Bar-Lev" <alonbl at redhat.com>
>> Sent: Sunday, February 23, 2014 8:55:07 AM
>> Subject: Re: [Users] API read-only access / roles
>>
>>
>>
>> ----- Original Message -----
>>> From: "Juan Hernandez" <jhernand at redhat.com>
>>> To: "Sven Kieske" <S.Kieske at mittwald.de>, "Users at ovirt.org List"
>>> <Users at ovirt.org>
>>> Cc: "Itamar Heim" <iheim at redhat.com>, "Yair Zaslavsky"
>>> <yzaslavs at redhat.com>
>>> 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 at 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 at redhat.com>
>>>>> 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 at 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.
>>>
>>
> 
> 
> 

-- 
Mit freundlichen Grüßen / Regards

Sven Kieske

Systemadministrator
Mittwald CM Service GmbH & Co. KG
Königsberger Straße 6
32339 Espelkamp
T: +49-5772-293-100
F: +49-5772-293-333
https://www.mittwald.de
Geschäftsführer: Robert Meyer
St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen
Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen