Shibboleth Service Provider

A generic Shibboleth service provider service for use in Shibboleth authentication schemes (e.g. NIH).

https://broad-shibboleth-prod.appspot.com/

1. The web UI presents a link with a return-url parameter which includes the literal string {token}. Once the user has successfully completed the eRA Commons login flow, they will be redirected to this URL with the {token} literal replaced by the encoded JWT.
2. The JWT is encoded and signed with this system's private key. It must be verified using this system's public key, available at the URL /public-key.pem.

Development

Philosophy

Fast cycles enable learning through experimentation. This provides the foundation for deep system interrogation and innovation as well as safety because of the ability to recover quickly. Fast cycles have been prioritized in this implementation, both for local changes as well as changes to the system as it exists in a production environment.

Approachability is achieved through supporting development and testing as first-class features. Fake, development-appropriate flows with examples are implemented and supported as production features.

Loose coupling is achieved through parameterization, specifically the return-url. This has security implications, so these URLs must be on a whitelist. The flow is carefully constructed so developers can complete and test a production implementation before requesting addition to the whitelist, which is not necessary to enable the flow, only to make it smoother.

Getting Started

bash npm start

Minimal server up test:

bash curl localhost:8080/hello

Beyond this, it should be possible to interrogate the system by using any HTTP client. The error messages should help guide toward correct usage. This ideal is not always achieved, but it is the goal.

Running Dev Flow locally

Before committing/pushing your changes, you should test the dev flow locally.

Pre-requisite

The application gets configuration information from a Google Bucket. In order for you to run the Shibboleth service locally, you must gcloud auth login as your firecloud.org user because this is the account that developers own that have access to the configuration bucket. If you are already logged in as your firecloud.org user, try logging in again.

How to execute the dev flow

1. Open your browser to: http://localhost:8080
2. Under the "Development Flow" section, click on the link underneath start:
3. Enter any string you want as a "username"
4. Click "Sign-In"
5. You should quickly get a response that says ""Sign-In" Successful!" at the top of the page. If the page hangs, or you get an error at this point, check that you have satisfied the pre-requisite.
6. At the bottom of the resulting page, there should be a large link titled, "Return URL". Click on that link.
7. This should take you to a page title "Example Return Page" and it should have a section title "Verification" containing dev: passed. At this point it is normal and expected to say prod: failed since we did not test the Prod flow.
   

Hot Reloading

If running locally, the server must be started with the environment variable GOOGLE_CLOUD_PROJECT defined, which provides the source for permissions checking.

bash GOOGLE_CLOUD_PROJECT=broad-shibboleth-prod npm start

bash tar -c --exclude='./node_modules/*' . \ | curl localhost:8080/.src --data-binary @- \ -H "Authorization: Bearer $(gcloud auth print-access-token)"

Deployment

The Shibboleth Service Provider is hosted on Google App Engine as a single application which supports both the development and production workflows. Google Cloud Build deploys a new version of the application automatically when commits are merged to the master branch.