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" <yzasl...@redhat.com> >> To: "Juan Hernandez" <jhern...@redhat.com> >> Cc: "Sven Kieske" <s.kie...@mittwald.de>, "Users@ovirt.org List" >> <Users@ovirt.org>, "Itamar Heim" <ih...@redhat.com>, >> "Alon Bar-Lev" <alo...@redhat.com> >> Sent: Sunday, February 23, 2014 8:55:07 AM >> Subject: Re: [Users] API read-only access / roles >> >> >> >> ----- Original Message ----- >>> From: "Juan Hernandez" <jhern...@redhat.com> >>> To: "Sven Kieske" <s.kie...@mittwald.de>, "Users@ovirt.org List" >>> <Users@ovirt.org> >>> Cc: "Itamar Heim" <ih...@redhat.com>, "Yair Zaslavsky" >>> <yzasl...@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@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 <dfedi...@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@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 _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users