Our current implementation of SSO does simple authentication to allow users to access the Workbench UI. In order to extend this prototype to authenticate into user services (replacing the current basic-auth), given a token, we need a way to determine which resources (stack IDs, and therefore which ingress hostnames) the user should have access to.

Options:

1. Modify current /check_token to return a list of accessible resources along with 200
2. Add a new API call like /check_access for something similar which, given a token or namespace, will translate into the list of accessible resources

The ndslabs-auth server then needs to implement this REST call to deny users who are not authorized to access a particular resource.
This should be as simple as preforming an HTTP request to the Workbench API endpoint described above:

• if the returned resources include the one you are trying to access (likely to be determined using the target hostname), then return 200
• if the target resource is not included in the returned list, then return 403.

This ticket is complete when there is a programmatic way to determine which resources are associated with a given JWT.