Options for user registration

Feature Requests and Roadmap Discussion
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.

30%20AM
screen 2019-05-16 at 11.47.30 AM.png1340×565 84.2 KB

55%20AM

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.

9

We recently switched from our custom identity brokering solution (discover + register php scripts + gridmap file + CILogon for external IDPs + Keycloak for local IDP) to one managed entirely by Keycloak (Keycloak is the identity broker and local IDP, external IDPs provided by CILogon).

Users can still self sign up for an account at my.osc.edu and have to go through the normal visual compliance and other verification steps prior to getting an account on our systems.

I’m happy to share details on the identity brokering with Keycloak if you are interested.

10

Hi @efranz,

I am curious to know what your keycloak workflow looks like.

I am looking to add a self-registration feature to a new cluster that I will be deploying OOD on, though with the added difficulty of not having passwords :).

I have hacked together a previous keycloak install for another cluster that only accepts identity brokering as a login method and automatically links the presented identity with the cluster user that is read in from ldap (matching the email provided by the broker with the email associated with the cluster account in the clusters ldap).

Now, I am trying to take the same setup for this new cluster but also allowing keycloak to write to register new users and maybe even write back to ldap?

Not sure how much I can pull from OSC’s setup as inspiration, but seeing another keycloak config might help.

Thanks,
Morgan

11

@m_ludwig For OSC the Keycloak login page is a split view using a custom theme [1]. The left side is Keycloak login that is backed by LDAP. The right side is Identity Provider of CILogon [2]. The “firstBrokerLoginFlowAlias” of “browser” basically redirects new users using CILogon to just Keycloak login page that upon successful login will map their CILogon identity to their LDAP record in Keycloak. Subsequent logins with that CILogon provider will redirect to OnDemand rather than require a second authentication to perform the mapping.

The only issue we’ve had is if you login with something like OSU via CILogon then log in with Google, that will cause duplicate record errors in Keycloak due to how the database schema is setup. The CILogon claim ID changes based on the provider used and Keycloak expects Identity Providers to always return the same claim ID for a given user. The user account portal for Keycloak allows users to remove their mapping and so we’ve just overloaded a help link in OnDemand to allow direct users to the page in Keycloak that allows them to delete their CILogon mapping. I think I also had to avoid the “email” value in “defaultScope” to prevent Keycloak trying to automatically create users inside Keycloak.

If you support a “Social” Identity Provider in Keycloak like CILogon the you can custom the flow via “firstBrokerLoginFlowAlias” to redirect users to registration pages or other parts of Keycloak. The flow aspect of Keycloak is highly configurable.

The self-registration at OSC is handled by a different application that ultimately writes records to LDAP. The LDAP configuration for Keycloak is set to read-only.

[1] : https://github.com/OSC/keycloak-theme

[2]:

[ {
  "alias" : "cilogon",
  "displayName" : "CILogon",
  "internalId" : "cilogon-osc",
  "providerId" : "oidc",
  "enabled" : true,
  "updateProfileFirstLoginMode" : "on",
  "trustEmail" : false,
  "storeToken" : false,
  "addReadTokenRoleOnCreate" : false,
  "authenticateByDefault" : false,
  "linkOnly" : false,
  "firstBrokerLoginFlowAlias" : "browser",
  "config" : {
    "hideOnLoginPage" : "false",
    "userInfoUrl" : "https://cilogon.org/oauth2/userinfo",
    "validateSignature" : "false",
    "clientId" : "<OMIT>",
    "tokenUrl" : "https://cilogon.org/oauth2/token",
    "uiLocales" : "false",
    "backchannelSupported" : "false",
    "useJwksUrl" : "true",
    "loginHint" : "false",
    "authorizationUrl" : "https://cilogon.org/authorize",
    "disableUserInfo" : "false",
    "clientSecret" : "**********",
    "defaultScope" : "openid profile org.cilogon.userinfo"
  }
} ]