Options for user registration

#1

Hi,

We’re working on a self-registration service for our cluster using the /register redirect feature within OOD which detects authenticated users that don’t have system accounts and redirects them to the /register link. This builds on the user_map_cmd, map_fail_uri, and register_uri config variables. It makes complete sense that this is not a core part of OOD since the approach to registering users is so site specific and I like the hooks that OOD does provide.

I’m interested to learn what approaches or canned apps other sites are using to register their users (possibly triggered by OOD redirect). Is this always a custom in-house app or are there front ends that are taking care of some of the details?

Our current account create process is mostly automated but triggered by a manual action after receiving a support request. We are building a Flask-based frontend that leverages the web SSO auth already used by OOD to identify the user and allow them to initiate their own account creation. It’s nothing fancy or uncommon, and every web site does it. :slight_smile: I’m curious to learn more about how other HPC sites are approaching this.

Thanks for any insights.

1 Like
#2

This is what we do at OSC.

We provide the ability to login with either OSC LDAP or with CILogon. Because we support both, the map script we use is /opt/ood/ood_auth_map/bin/ood_auth_map.mapfile (https://github.com/OSC/ondemand/blob/master/ood_auth_map/bin/ood_auth_map.mapfile).

When authenticating with mod_auth_openidc the REMOTE_USER will either look something like these:

So we store mappings in a grid map file (default /etc/grid-security/grid-mapfile and following format http://toolkit.globus.org/toolkit/docs/2.4/gsi/grid-mapfile_v11.html). As you know, the mapping script tries to find the REMOTE_USER in the grid map file which is mapped to the system user. So we have a register page that only authenticated users can access that presents a web form showing on the right information about the identity provider they chose to login with, and on the left fields to insert their HPC username and password. They authenticate with their HPC credentials, and upon successful authentication the mapping between their distinguished name and their HPC username is added to the gridmap file using some custom scripts.

Once its in the gridmap file, future invocations of /opt/ood/ood_auth_map/bin/ood_auth_map.mapfile succeed.

Two caveats to this approach:

  1. We feel that we are abusing the gridmap file and should be using a different approach if we continue to maintain a custom registration page. CILogon may have recommendations here.
  2. I want to move to using Keycloak for identity brokering. Keycloak’s identity brokering features may replace the need for custom discover and register pages. You can even define a “first login flow”, though the theme would need to be modified with enough contextual information so users don’t get lost in the mapping process. See https://www.keycloak.org/docs/latest/server_admin/index.html#_identity_broker
#3

Oops I did just realize this solution assumes you have an HPC account already, not

using the /register redirect feature within OOD which detects authenticated users that don’t have system accounts and redirects them to the /register link

#4

Thanks for the insight. I’ve noticed your “provide HPC account details to link with your federated id page”. I think this works well for account linking. To be fair, that’s what the grid map file is about so the abuse doesn’t seem egregious. In our dev env use a map file under /etc/ood to map the samltest.id accounts to local dev system accounts. It works well.

Given that your registration/account linking assumes a pre-existing HPC account, do you have any automated process for user to get that account set up? Creating the actual HPC account for authorized users is what our app is focusing on.

#5

On both discover and register pages, we link to https://my.osc.edu, our client facing portal that allows users to initiate the sign up process. That process is partly self-initiated and automated, but there are required visual compliance steps we take before users get system accounts created.

#6

Is this an in-house developed portal or an adaption of pre-exsiting tools?

#7

In house custom Oracle APEX site. @mkzia does Coldfront offer anything in terms of automatic account provisioning? What does Buffalo do?

#8

ColdFront does not do account provisioning. At UB (CCR), we use freeIPA as our IDM solution. Instead of Keycloak, we use Hydra (https://github.com/ory/hydra) for OAuth2.0 server implementation and Mokey (https://github.com/ubccr/mokey) as a bridge between FreeIPA and Hydra. Mokey also handles user registration and acts as the broker for SSO.