If your site is a part of the National Science Foundation’s (NSF) ACCESS program (formerley XSEDE) you can use their Identity Provider (IDP) CI Logon to authenticate users for your Open OnDemand instance.

OIDC Client Registration

You should read the ACCESS IDP documentation on how to register your Open OnDemand instance as an Open ID Connect (OIDC) client.

Once you’ve registered your Open OnDemand instance, you can then configure it accordingly. Since ACCESS uses Open ID Connect (OIDC) you can see our oidc documentation for more details on how to configure Open OnDemand with what CI Logon has provided in registering your application.

Here’s an example you can use to get started. Note that oidc_client_id and oidc_client_secret are commented out because they are specific to your site.

oidc_uri: "/oidc"
oidc_provider_metadata_url: "https://cilogon.org/.well-known/openid-configuration"
# oidc_client_id: "cilogon:/client_id/..."
# oidc_client_secret: "..."
oidc_remote_user_claim: "eppn"
oidc_scope: "openid email org.cilogon.userinfo"
oidc_session_inactivity_timeout: 28800
oidc_session_max_duration: 28800
oidc_state_max_number_of_cookies: "10 true"
  OIDCPassIDTokenAs: "serialized"
  OIDCPassRefreshToken: "On"
  OIDCPassClaimsAs: "environment"
  OIDCStripCookies: "mod_auth_openidc_session mod_auth_openidc_session_chunks mod_auth_openidc_session_0 mod_auth_openidc_session_1"
  OIDCAuthRequestParams: "idphint=https%3A%2F%2Faccess-ci.org%2Fidp"

Shibboleth and InCommon

If your campus already runs Shibboleth authentication, you have an alternative to the Open ID Connect configuration above.

CI Logon provides a bridge from campus authentication, via the InCommon Federation, to certificate-based and OAuth/OIDC-based research cyberinfrastructure (CI).

The SAML metadata for idp.access-ci.org is not yet published by InCommon. Please manually fetch the metadata from https://identity.access-ci.org/access-metadata.xml and configure it in a local file until we can complete the InCommon publication process.

See our shibboleth documentation for more information on Shibboleth authentication.

Mapping Users

ACCESS users have allocations on many ACCESS resource, of which you are one. This means they have disparate usernames on all these systems and a unique username on _your_ system.

So you’ll need an additional utility provided by access ACCESS, namely the access-oauth-mapfile.

Follow the instructions to install that utility and you’ll get a lookup table in /etc/grid-security/access-oauth-mapfile like so:

annie-oakley@access-ci.org aoakley

You can set the user_map_cmd in ood_portal.yml to search this file and return the local user given the ACCESS username.


MAPPED_USER=$(grep "$1" ./delme.txt | awk '{print $2}')
if [[ "$MAPPED_USER" != "" ]]; then
  echo -n "$MAPPED_USER"
  echo "$1-not-found"