Explore Cognito as a means for authentication in the new system

[briri]

Cognito can provide us with out-of-the-box management for our authentication needs:

• email + password
• SSO with various Identity Providers (IdPs) using SAML2
• ability to later add ORCID using Open ID Connect (OIDC)
• ability to later add common 3rd party providers like Google or Facebook

A significant problem we must address though is our use of the Shibboleth Service Provider (SP) and the InCommon Federation (which is essentially a registry of IdPs and SPs).

Our Shibboleth SP currently handles the SSO functionality in the system using SAML2. Here is how it all works:

• The DMPTool stores an organization's entityID in the database.
• When a user logs in (or creates an account) via SSO
• The DMPTool makes a call to the Shibboleth SP and passes it the entityID and a redirect URL.
• The Shibboleth SP then uses that entityID to look up the IdP's metadata.
• The metadata is then used to communicate with the user's IdP.
• The Shibboleth SP sends the user to the IdP for login.
• Once the user logs into their IdP, the IdP sends a SAML2 response back to our Shibboleth SP.
• Our Shibboleth SP verifies the SAML record and, if satisfied, redirects the user back to the DMPTool.

This is very similar to what Cognito is doing except that Cognito cannot "look up" the IdP metadata based on the entityID.

I think we can accomplish this by building a Lambda that can perform this lookup for us. Here is an outline of how that might work:

In the new system's UI (nextJS app):

• An Org Admin decides they want to enable SSO for their users
• They enter their entityID into a field (we provide a link to InCommon for them to look this value up)
• The UI calls our new Lambda function (passing the Org's ROR ID and the entityID)
• The Lambda runs async, so the UI displays a message to user that this can take a few minutes

In the new Lambda function:

• First verify that the entityID is not already setup with a different ROR ID
• Fetch the metadata from InCommon (or, eventually, Azure or whatever others are out there).
• For example these are the URLs to fetch the metadata (note that the entityID is embedded in the URL):
  • https://met.refeds.org/met/entity/urn:mace:incommon:ucop.edu/?viewxml=true&federation=edugain
  • https://met.refeds.org/met/entity/https://shibidp.syr.edu/idp/shibboleth/?viewxml=true&federation=edugain
• Use the Cognito SDK to programatically add a new identity provider to our Cognito UserPool

Scheduled Lambda function:

• Collects all of these entityIds we have registered and goes out and fetches their latest metadata to make sure our Cognito is up to date. This will help keep us in sync the way InCommon does

Outstanding questions:

• Need to figure out how nextJS learns when the Lambda is done
• Need to figure out a way for the admin to test it (linking their own account) which acts as verification that it all worked
• Need to add logic to understand various errors from Cognito (e.g. IdP doesn't "trust" us, SSL cert is expired, etc.) we then need to notify the org admin with info on how to resolve on their end

[ashleygould]

Very interesting idea.

One feature to add that pops to mind is to somehow record all the idp metadata for backup use.

[marisastrong]

Idp metadata can refer to incommon for backup

[briri]

sounds like this is a non-starter if Cognito can only handle a single IdP definition. Here's the Confluence doc for more info.

So it looks like we'll want to setup our ShibSP on an ECS Cluster