Add Login.gov as Authentication

This guide provides step-by-step instructions on how to integrate Login.gov as the authentication provider for a Flask application with API routes. Using datagov-harvest-admin as an example here.

Prerequisites

• A Flask application with API routes.
• A Login.gov account and access to the Login.gov Developer Dashboard.
• Python 3.6+ and Flask installed.
• requests library for handling HTTP requests.

Steps to add login.gov authentication:

Register Your Application with Login.gov:

• Log in to the Login.gov Developer Dashboard.
• Register a new application and obtain the following credentials:

Client ID
Client Secret
Authorization Endpoint
Token Endpoint
User Info Endpoint

• Set the redirect URI t* o a route in your Flask application that will handle the OAuth callback. For example, https://yourapp.com/callback.

Install Required Packages:

Ensure you have the necessary Python packages installed

Configure Flask Application:

In your Flask application, add the necessary configuration for Login.gov.

Update the Flask Application

Secure Your API Routes

Update key

CKAN app SP certificates:

Run command

$ openssl req -nodes -x509 -days 365 -newkey rsa:2048 -keyout private.pem -out public.crt -config <(
cat <<EOF
[req]
prompt = no
default_md = sha256
distinguished_name = dn

[ dn ]
C=US
ST=District of Columbia
L=Washington
O=General Services Administration
OU=Technology Transformation Service
emailAddress=test@gsa.gov
CN=test.data.gov

EOF
)

Replace the CN value [domain-name-for-service-provider] with the corresponding domain names of the apps, so that the certificates are recognizable. This command will generate two files: private.pem as the private key and public.crt as the public certificate.

Update SP public certificate on the login.gov dashboard

Add apps on sandbox login.gov dashboard:

upload file mycert.pem to have the app updated with the new public certificate. Changes made to Active apps take effect right away.

Save to SP certiciates to team google drive.

Location: DatagovDevSecOps > secrets. The files are version controlled. Upload the certificate files as new version. This should be done before the next step so that other team members have access to the certificates to perform the next step.

Update SP certificates for cloud.gov apps:

In the code, replace the placeholder text the public certificates.

Run cf command cf env datagov-harvest to get the credential value for service datagov-harvest-secrets. For example

{
  "CF_SERVICE_AUTH": "[...]",
  ...
  "OPENID_PRIVATE_KEY": "LS0[...]0tLQo="
}

Save it as file secrets.json in your local.

replace the value for OPENID_PRIVATE_KEY in file secrets.json.

Run cf command cf uups datagov-harvest-secrets -p secrets.json to update the cf service datagov-harvest-secrets. Restart the datagov-harvest app to pick up the updated OPENID_PRIVATE_KEY value.

These steps need to be done 3 times to complete private key update for app in cf spaces development, staging and prod.

This step has to be done together with login.gov dashboard certificate update. If one is done without the other, it means down time for the app login function. So when login.gov support notifies the task has been scheduled/resolved, it is time to do this step.

To update SP certificates for local docker Catalog app:

certificates go to .env.

Other thoughts

1. Once an app gets promoted to login.gov production server, we lost access to manage it, so any change including SP public certificate change needs to go through login.gov supporting channel. This might get improved in the future when login.gov production server supports developer self-management.
2. For local docker and development SP certificates, it is OK to give it a longer expiry date, say 10 years.
3. Production CKAN applications should NOT use login.gov sandbox environment. Sandbox has no ATO, is not cleared for official use.