Hello, After this change we got a lot of problems with backup vms BZ 2021497 [RFE] Install and configure Keycloak as a default SSO provider Please note that default ovirt administrator user name has been changed from ‘admin’ to ‘admin@ovirt’ (Administrator Panel, VM Portal) and from ‘admin@internal’ to ‘admin@ovirt@internalsso’ (REST API). It isn't good practice to radically change default credentials. There are many customers who will get problems after the update, because they skip RN part. The veeam app is have to use admin@ovirt@internalsso as a user with this update, which looks really strange user name notation. Could you revert naming changes back to admin@internal? thank you.
(In reply to Yury.Panchenko from comment #0) > It isn't good practice to radically change default credentials. > There are many customers who will get problems after the update, because > they skip RN part. Hi Yury, Please note that this shouldn't affect users that upgraded their system, only those that deploy RHV from scratch would be affected I'd suggest to add it to the Veeam documentation that this should be different when working against oVirt/RHV that uses keyclock
When asking for REST API credentials you need to ask users to distinguish if they use the legacy internal AAA or RH SSO(RHV)/Keycloak(oVirt) configuration. Upgrades are not affected
Hello Arik and Michal, Thank you for the explanation. What will new customers get from this change? Sometimes customers could deploy a new RHV from scratch, then they will get this problems and ask support. after that they must read documentation and make configuration changes. It isn't good way to keep customer satisfaction. It looks like a default customer doesn't need this. Why don't you keep by default old type of authorization? If a customer would like to get new features, then he could configure this. I'm comparing this behaviour with other famous hypervisors. They never change defaults for all even for a new installation. Also they don't offer more types of auth than local domains and Ldap, and customers don't have problems with that. It's really cool to have ability to authorise via Git or etc, but most customers use more traditional auth types.
(In reply to Yury.Panchenko from comment #3) > What will new customers get from this change? The reasoning is documented in bz 2021497, you highlighted one of the functional benefits but there's also a non-functional benefit in terms of maintaining the legacy mechanism we used. Yury, wouldn't the Veeam client just work when the user specifies the expected credentials for keycloak? I don't think there's anything you need to do on your end to support this
Hello Arik, > The reasoning is documented in bz 2021497, you highlighted one of the functional benefits but there's also a non-functional benefit in terms of maintaining the legacy mechanism we used. I'm always ok with any changes it they don't break working functional > Yury, wouldn't the Veeam client just work when the user specifies the expected credentials for keycloak? I don't think there's anything you need to do on your end to support this Unfortunately no. We're researching for the reason, but I think the problem is double @ in the username whis is really unexpected, and we can't fix this without hotfix. If you change admin@ovirt to just admin (rest credentilas admin@internalsso), I think the problem will be gone.
unfortunately it's not possible to change anything on oVirt side. Keycloak requires "email-based" name, unlike the legacy AAA, so "admin" changed to "admin@ovirt". The domain part is and always was separated by @, for no good reason, it's just a historical decision. And this unfortunately leads to this double @ case with our API. People don't just use LDAP, there were/are numerous requests to integrate with openid, AD, integrate with all sorts of SSO solutions, and our limited custom AAA implementation puts all that burden on us. Either way, we can't fix it on our side, unfortunately, without dropping AAA completely which is way more disruptive as it would mean a complete reconfiguration during upgrade. (also, technically I don't think we ever specified that the username is just alphabetical, so all these validations are just incorrect if they assume that username cannot contain @. And yes, we had to fix ours in various places too:)
Several comments from my side: 1. Integrations with external Keycloak (for oVirt) RH SSO (for RHV) is functional since oVirt/RHV 4.2 and from the beginning it was created as a replacement for internal AAA (you can either use AAA or federate authentication to Keycloak) and is fully documented since then: oVirt: https://blogs.ovirt.org/2019/01/federate-ovirt-engine-authentication-to-openid-connect-infrastructure/ RHV: https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.4/html/administration_guide/chap-users_and_roles#Configuring_Red_Hat_SSO 2. In order not to break backward compatibility with existing RESTAPI/SDK clients, we have developed token infrastructure, which provides the same API regardless of authentication type being used (AAA or Keycloak) -> no client changes required if administrators switched from AAA to Keycloak 3. Preconfigured administration user admin@internal is created during installation to ease initial product administration. But common practise is to disable this account and use accounts of concrete persons for system administration -> many customers are not using admin@internal at all but rather assigned SuperUser role to concrete administrators from their LDAP integration 4. AAA has been designed to be able to use multiple LDAP servers/domains for a single engine instance, so we needed distinguish between those instances by using profile names -> that's why username for RESTAPI has always been defined as <USERNAME>@<PROFILE>. But some underlying LDAP provides (especially Active Directory) uses email address as a username, so it's very common that for RESTAPI you need to use john.doe@ad-example-com as a username 5. As a part of oVirt 4.5 we have decided to bundle Keycloak in oVirt to ease Keycloak installation and configuration for upstream users. That's why by default for new 4.5 installations Keycloak is configured and used. But users can disable Keycloak and stay with AAA during engine-setup phase (there is a question if Keycloak or AAA). 6. In RHV we cannot bundle Keycloak, so RHV users need to use RH SSO as fully supported solution. 7. During upgrades of both oVirt/RHV we honor current setup - oVirt/RHV 4.N with AAA will be upgraded to oVirt/RHV 4.M with AAA - oVirt/RHV 4.N with Keycloak/RH SSO will be upgraded to oVirt/RHV 4.M with Keycloak/RH SSO