At my site we’re considering switching from InCommon shibboleth to CILogon authentication, but we hesitate to allow logins from basically the whole world. We’d like to retain control over which IDPs are able be used to log in. Has anyone else done this? Have I overlooked some documentation? Any pointers would be appreciated.
Hello! This is probably more of a CILogon question than an OOD question. The CILogon docs indicate that you register which IDPs to use at set-up. CILogon provides help@cilogon.org which might be able to provide further guidance.
Just to add to this, we utilize CILogon in production here at OSC and definitely don’t allow the whole world to login. @tdockendorf might be able to add some details.
The way OSC uses CILogon is we add it as IDP to Keycloak and OnDemand uses Keycloak. If someone chooses to login through CILogon using Keycloak they will authenticate with whatever institution they choose but if it’s the first time using CILogon they get redirected to Keycloak and must do local OSC LDAP authentication to map their CILogon identity to their OSC username. With OnDemand the username must be local to the cluster so we use Keycloak to handle that mapping so someone can only log into OSC with CILogon if they already have OSC account. The one “gotcha” with this approach is if I login with CILogon and choose “OSU” then later try to login with “Google” or something different, Keycloak will throw errors. A user must first remove their mapping via Keycloak to map to a different CILogon identity.
How do users get accounts at OSC? On my site they register on our “web portal”, which in turn adds users to LDAP. I was hoping that whatever solution works for OOD would also work for the portal, but I can’t make the portal rely on LDAP due to chicken/egg issues.
We have a custom, bespoke client management portal (my.osc.edu if you want to see the landing page) where clients sign up for accounts, go through the various approval processes, etc. It populates our LDAP then behind the scenes.
Note a fundamental aspect of OOD is that whenever possible, it relies on underlying system resources / services. Authentication is very much one of those underlying resources / services that we don’t want OOD to manage at all.
You might want to look at the ColdFront platform to help with managing allocations and such (although it too relies on underlying authentication): ColdFront (Allocations Management Portal) - Center for Computational Research
CILogon said that if you get the Essential Service subscription, they can set an IDP whitelist on their end rather than a client-side IDP “hint list”. This is technically a solution to the question that I posted, but I’m looking for something more fine-grained.
I was under the impression that coldfront was able to handle registering new accounts, mutually exclusive with our “web portal” or your “bespoke client management portal”. Is that true?
Using CILogon for OnDemand won’t be useful or even work unless you have a mechanism to map that external identity to a local user. OnDemand expects everyone using OnDemand to have a local user account.
What OnDemand cares about is you have your cluster’s local users accessible on the HPC side of things and OnDemand side. So if you have users in LDAP, then that will work for OnDemand so long as you use something like SSSD to map LDAP users to Linux user accounts. Things like OSC’s client portal and Coldfront will help automate the process to get users into LDAP.
Since you have users in LDAP, to use CILogon you have to have some mechanism to say like “user1@google.com” belongs to “foobar1” user on your local cluster. Without that mapping, CILogon won’t work for OnDemand. OSC uses Keycloak to handle that mapping since Keycloak can pull users from LDAP so we have a process defined in Keycloak so that if I log into OSC using like “tdockendorf@google.com” then that will map to my “tdockendorf” LDAP identity for OSC.