[Users] API read-only access / roles

Yair Zaslavsky yzaslavs at redhat.com
Sun Feb 23 02:03:05 EST 2014 


----- Original Message -----
> From: "Yair Zaslavsky" <yzaslavs at redhat.com>
> To: "Juan Hernandez" <jhernand at redhat.com>
> Cc: "Users at ovirt.org List" <Users at ovirt.org>
> 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.

CC'ed Sven as well, 
In addition bare in mind as Directory and Authenticator will be extensions, there will be some interface change.

Yair

> 
> 
> 
> 
> > > 
> > 
> > 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.
> > 
> _______________________________________________
> Users mailing list
> Users at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>

More information about the Users mailing list