So if we have an organization that, for any reason, cannot run freeipa. They cannot use ovirt. Freeipa is a false requirement for cloud and virtualization. The web frontend already uses basic auth, by doing this it makes it easy to swap auth out with many of the apache mod_auth modules allowing people to pick whatever auth mechanism they want. Use case: 1) Admin uses mod_auth_postgres 2) User exists in postgres logs in to ovirtwui 3) ovirt creates the user if it doesn't exist 4) admin can then create permissions and things for the user How hard would it to be the above? -Mike "lets find some stuff to take out before we add" McGrath
On Thu, 9 Apr 2009 14:11:21 -0500 (CDT) Mike McGrath <mmcgrath at redhat.com> wrote:> So if we have an organization that, for any reason, cannot run freeipa. > They cannot use ovirt. Freeipa is a false requirement for cloud and > virtualization. > > The web frontend already uses basic auth, by doing this it makes it easy > to swap auth out with many of the apache mod_auth modules allowing people > to pick whatever auth mechanism they want. > > Use case: > > 1) Admin uses mod_auth_postgres > 2) User exists in postgres logs in to ovirtwui > 3) ovirt creates the user if it doesn't exist > 4) admin can then create permissions and things for the user > > How hard would it to be the above?The other issue is that the qpid infrastructure is currently set up to require kerberos authentication. However, it's kind of silly in a way because the default roll out has it grabbing the ticket from the web server specified in the DNS SRV records, which means that no authentication of nodes really takes place. The right way to securely connect nodes is to copy the ticket to some persistent storage on the node before deployment. The thing this protects against is malicious nodes.. note that a VM could also register as a node so you have to trust your VMs too.. this is actually a problem with the current default config. Note that you don't need a node image booted, you just need the ovirt scripts to register with the ovirt server etc. The danger of a rogue node is that it gives that node access to whatever VMs happen to get created on it (take snapshot, scp it to home computer or such - image stealing). I think it would be a good idea to enable the qpid infrastructure to work without kerberos for demoing/testing/evaluating. If we could have a mode where we get rid of the freeipa and dns requirements, it would definitely make it much easier to deploy for evaluation etc. It would be good for developers to get up and running as well which may also be advantageous. Ian
Mike McGrath wrote:> So if we have an organization that, for any reason, cannot run freeipa. > They cannot use ovirt. Freeipa is a false requirement for cloud and > virtualization. > > The web frontend already uses basic auth, by doing this it makes it easy > to swap auth out with many of the apache mod_auth modules allowing people > to pick whatever auth mechanism they want. > > Use case: > > 1) Admin uses mod_auth_postgres > 2) User exists in postgres logs in to ovirtwui > 3) ovirt creates the user if it doesn't exist > 4) admin can then create permissions and things for the user > > How hard would it to be the above? > > -Mike "lets find some stuff to take out before we add" McGrath > > _______________________________________________ > Ovirt-devel mailing list > Ovirt-devel at redhat.com > https://www.redhat.com/mailman/listinfo/ovirt-devel >+1. There's also a likelihood that an ovirt userbase could have an existing kerberos server they want to use, or don't want an LDAP server. Are those supportable now? From experience, organizations tend to be picky about site-specific details, and supporting multiple systems provides a greater chance of adoption. Thus it is very nice to support auth, via say, pam, or Apache (including what Mike mentions, but also doing basic auth for demos), or something that allows for configuring options. The other question is that if they must also set up FreeIPA, is a user is more likely to get frustrated during the demo or not install it? Ideally, "yum install" and having a guest up and running in 30 minutes should be a good goal to have. That was one of the major reasons, I think, why virt-factory didn't take off -- they had to understand Puppet + virt, at a time when they really wanted to wrap their heads around one new thing. So FreeIPA + OVirt is also two new things, in much the same kind of way. Providing simple options as well as the IPA options would probably help reach a wider install base, and also make setting it up for a proof of concept/demo easier too, I think. If I could just say, point it at an existing kerberos source and allow only these 7 users access, even, that would be useful. --Michael