we are currently in the process of making our privacyidea/keycloak testing installation production ready. right now we have privacyidea and keycloak on separate VMs.
is there any reason why we should not have privacyidea and keycloak running on the same machine?
Hello @hkunz ,
I think it depends on your further use cases and network design.
Usually I would not put the privacyIDEA server on the same machine as a “privacyIDEA client” (in this case your keycloak).
If you are going to connect further applications against privacyIDEA, like SSH logins. Then you might not want to make the availability of the SSH logins depending on whether you need to restart “keycloak” or not.
If you are going to have different responsibilities for SSO and MFA, then it makes sense, so separate the root access for the different administrators via different machines.
etc…
However, if this is a logical unit: SSO+MFA and if it is going to stay this way, then you might put them on one machine.
Regards
Cornelius
thanks for your opinions. OK, I might elaborate here a bit.
we use keycloak to connect our openid connect capable applications and provide them with MFA+SSO.
for ssh (and sudo) we use pam_privacyidea (only MFA, without SSO). so, ssh (and sudo) would not rely on keycloak. But I think I get your point @cornelinux (although I am not entirely sure). of course we need to take care, that we can still use ssh to login to the privacyidea server even when privacyidea is not running.
ah, and no, we do not have different resposibilities for SSO and MFA (we are only one team of admins).
Somehow it does. Imagine your keycloak process chokes the server or requires the whole server to be restarted. Then your SSH login depends on the failure of keycloak.
However, I am talking about the worst case scenario. For real world examples the comment by @AAuer might be more helpful.
great guys, your comments help me a lot. I elaborate again
our plans are two use a two node galera cluster, with privacyidea and keycloak. this would be an active passive cluster (with a virtual IP). it would NOT be a perfect HA solution, because keycloak makes extensive use of caches. so in the case of a failover, people would have to renew their SSO sessions.
but I totally agree, we need a good “backup plan” for logging in to servers needed for authentication (privacyidea, keycloak, ldap) even when these services are down. i.e. local users (in case LDAP is down), ssh logins using key-based authentication (which we exclude from MFA), etc.