Yes, that’s correct, the Keycloak service would be unmanaged. If we’re saying that with SSO option turned on, we won’t have a visible way of logging in via local users – then we’re good. Otherwise, we may need to add something on the login page.
I agree, Keycloak the service shouldn’t be handled by Foreman. But apart from detecting if SSO logins are enabled on Foreman, we may also need to set/unset Apache settings and Foreman’s settings.yaml related to login_delegation. For example when the user wishes to disable SSO.
It does not change much. The only changes that we anticipate are:
Apache’s handling of <Location /saml2> and <Location /users/extlogin>. It must intercept these URLs and not pass it on to the Puma server.
I was looking out for a solution for the SSO integration, there are only
two approached that is possible right now with keycloak(these solutions were suggested by one of the members of the keycloak team):
Command-line tools in userspace would probably fall under guidelines given in RFC8252. To summarize, it would basically mean hammer providing a callback mechanism (i.e.localhost port) and spinning up a web browser for the auth process.
The keycloak team is also working on the offline token initiative, whereby apps can store long-lived credentials so users don’t have to continually re-auth (if that isn’t desired).
I was keen on implementing the second approach as it is been commonly used and would be easy for the users to adapt to but since the timeline for the feature to be implemented is not certain I think we should go with the first approach. The first approach is not really clear to me, I need to look into it more closely.
One thing I would be curious about from folks, would it be acceptable to require the use of sessions in hammer if oauth is setup? That would allow for the webserver trick to only be used once per session.
Temporary webserver on hammer side because of the callback sounds very hacky to me. Also very prone to errors, users would need to reconfigure firewall and update selinux on every client host they would use hammer on. Is there some other open source CLI that integrates keycloak? How they solve it? If not, could the Foreman be the thing that receives callback?
Collect credentials directly in the CLI and exchange for a token
this token is further passed to foreman to validate the token and
provide a session to the user. The session is then used to provide
the required output to the user in CLI.
My findings ( Following steps are involved in the implementation ):
Getting the token from CLI by giving keycloak username/password.
Passing this token to foreman
Use this JWT token for validation(which involves):
a) Validation of the JWT token
b) If JWT token is valid then authenticate the user using it.