We are implementing Keycloak with CILogon to replace standard ldap authentication. I’m at 1.3 in the documentation 1. Install Keycloak — Open OnDemand 3.0.0 documentation.
I’m confused by the item:
I don’t have any of the folders starting with httpd24. Do I create that entire folder structure and create the file? I’m running Keycloak on my OOD server.
Actually I figured it out, I use the default httpd installed and not httpd24. I found what I needed under /etc/httpd/conf.d/
Got Keycloak all the way configured up to CILogon, where OIDC Client Registration is temporarily closed for now LOL.
Yep, sorry I didn’t get to this topic, but yea you found it.
I did however create this ticket upstream to update the documentation for the same.
I have walked through the implementation of Keycloak completely and I am getting no results. The minute I remove ondemand-dex to replace with Keycloak my website gives me a Internal Server Error and I’m unable to move Keycloak into play even for just ldap authentication. The Keycloak website runs fine and I’m able to configure it completely, but the main OOD remains broken. I’m not even getting a login screen.
Can I please ask for some assistance in troubleshooting what I’m doing wrong?
Kenny Hanson, MSU
What are the errors in
/var/log/httpd? When you try to connect using Keycloak, apache should be logging something indicative of what’s gone wrong.
It really blows my mind how I get blocked and simply don’t remember to check the httpd logs, thanks for that. I did check and the main issue was no SSL certificate for my tempest-keycloak instance. I got one installed and I’m way closer but I get this when going to my OOD login:
I restarted keycloak service and httpd and htcacheclean.
I’m a little out of my depth now. But it seems like you need to setup an OnDemand client in Keycloak.
Then back in the OOD configurations use the same id you were given (or defined) when you created the client. I think it’s similar to the client secret.
Yeah I went through that part of creating a client through your documentation here: 2. Configure Keycloak — Open OnDemand 3.0.0 documentation
I found an issue, I named my client the wrong name so that’s why it couldn’t find it. Now I think I have a CILogon issue where I didn’t select the Scope of what’s returned, so I’ve opened up support with them.
Thanks Jeff, you led me right to the issues!
I’ve gone back over the entire install with a fine tooth comb. I don’t know what I’m missing. I get a basic logon screen with user/password text boxes and a CILogon link when I go to my OOD instance. Click CILogon and I get to my school’s federated login but it returns me to the login screen (keycloak instance) when it comes back and there’s no login taking place.
After playing with it for a bit I blew the entire Keycloak config away and started new. Got all the way to the login screen and now the CILogon button doesn’t do a thing.
error.log: [Tue Aug 22 10:44:07.407596 2023] [auth_openidc:warn] [pid 1622436:tid 139887722346240] [client 126.96.36.199:55992] oidc_clean_expired_state_cookies: state (mod_auth_openidc_state_LPsp0qOzTDsCuMK8vIJPAdxPoqs) has expired (original_url=https://tempest-ood3.msu.montana.edu/pun/sys/dashboard)
That log entry is immediate upon return from federated login.
@tdockendorf do you have any guidance on Keycloak & CILogon integration?
You still need LDAP authentication with Keycloak when using CILogon. With CILogon there still needs to be a way for Keycloak to map the CILogon identity to a local LDAP identity. The way OSC has it setup is if you choose to login with CILogon, you’re redirected to the CILogon auth page, then back to Keycloak where if it’s your first time with that CILogon identity, you have to provide LDAP credentials to map the CILogon identity to LDAP. Subsequent logins don’t have the LDAP authentication part since the identity is mapped.
Be aware that due to limitations in Keycloak a user can only map one CILogon identity per LDAP username. So if I used CILogon to login with Ohio State University, I couldn’t then use CILogon to login to Google without first deleting the Ohio State University mapping.
Using CILogon requires that you create the OAuth identity with CILogon. That will give you the Client ID and Client Secret you use in Keycloak for the identity provider. OIDC.
OSC uses Puppet to add the Keycloak identity provider for CILogon. Example:
cilogon on osc:
default_scope: openid profile org.cilogon.userinfo
We use a custom login theme to give users the option to login with either LDAP or CILogon: GitHub - OSC/keycloak-theme: Keycloak theme for OSC OnDemand and AweSim
We have some custom flows defined using Puppet to setup the desired flow since the CILogon to LDAP mapping part doesn’t work out of the box:
browser-with-duo on osc:
form-browser-with-duo under browser-with-duo on osc:
identity-provider-duo on osc:
auth-cookie under browser-with-duo on osc:
identity-provider-redirector under browser-with-duo on osc:
display_name: Identity Provider Redirector
auth-username-password-form under form-browser-with-duo on osc:
display_name: Username Password Form
duo-universal under form-browser-with-duo on osc:
display_name: Duo Universal MFA
alias: Duo Universal
duo-universal under identity-provider-duo on osc:
display_name: Duo Universal MFA
alias: Identity Provider Duo Universal
I revisited my login for my cloned development OODv3 environment. Straight up ldap auth works now and so does CILogon. They work independently of each other, apparently. It’s not very clear that a user needs to use the CILogon first before using their ldap auth to login.
I’m curious about this limitation you speak of:
“So if I used CILogon to login with Ohio State University, I couldn’t then use CILogon to login to Google without first deleting the Ohio State University mapping.”
We use CILogon for quite a bit of access across campus including Microsoft and Adobe products. We use the same ldap login id (we call it a NetID), or username. Is this going to be an issue?
I suspect there is a slip grammatical error here causing the confusion. @tdockendorf said “…use CILogon to login to Google…”, but I think he meant “…use CILogon to login WITH Google…”. I think the issue is once you logon with a particular mapping, it’s not ‘automatic’ that you can go back to the logon page and try to logon with another provider and have it map correctly.
That’s to say, somebody has an account on your system at Montana. They use the CILogon page to map their Ohio State account to their Montana account to let them logon to your OOD page with their Ohio State credentials. The next time they go back to the CILogon page, if they try to use a Google account instead, there will be an error or conflict of some sort because the system already knows about the Ohio State > Montana mapping but doesn’t know about the Google > Montana mapping, and won’t necessarily automatically set it up.
I think there is a way to within the CILogon page add such additional mappings, but it isn’t intuitive if I recall (it’s been years since I setup my mappings).
Okay, Thanks Alan . I’ll have time later this week to dedicate to this. Our IT Security Dept is anxious to have MFA on our systems.
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.