Project Title	Campus API Gateway
JIRA Project
Project Lead
Project Team

Background & Business Value

Provide a secure and standardized way to access resources through the Campus API Gateway.

Goals

Use OAuth2 (or something similar)
Provide secure access to data (P1 and up)

Out of Scope

Defining Authorization/Permissions System(s)

What we would like from Campus IdM

New Accounts Types in Campus IdM
- Service Accounts (Application Accounts)
REST APIs to Manage Service Accounts
Support for all OAuth2 offered by PingIdentity (including JWT)
- An SSO Token/TGT lifespan of at least 9 hours.

Poorly Used Terms

Campus API Gateway and Apigee can be used interchangeably (unless otherwise specified).
Campus IdM can refer to PingIdentity, PingFederate, CAS 3.0, Shibboleth, OAuth 2.0 Authorization Server or OpenId Authorization Server.
- The definition should be understandable from the context. If not clear, the text should be clarified and updated.

Assumptions

Initial Requirements Outline

Name	User Token in Application	App Token in Application	User Token in Browser	App Token in Browser	App OAuth in API Gateway	User OAuth in API Gateway	OAuth Lookup in Resource Server
Application to Campus API Gateway		X			X	(not expected)
Application to Resource Server		X			X	(not expected)	X
Application w/ User to Resource Server	X	X			X	(not expected)	X
SSO Application w/ User to Resource Server	X	X			X	(not expected)	X
Browser App to Campus API Gateway (not suggested)*				X	X	(not expected)
Browser App to Resource Server (not suggested)*				X	X	(not expected)	X
Browser App w/ User to Resource Server (not suggested)*			X	X	X	(not expected)	X
SSO Browser App w/ User to Resource Server (not suggested)*			X	X	X	(not expected)	X
SSO Single Page Application Alt (All Code Runs in Browser) (not suggested)*			X	X	X	(not expected)	X

* = Browsers Apps are not suggested because security through the API Gateway is based upon the Client Application (Web Application) permissions. In all scenarios the Authentication Token for the Client Application can't be securely used in a browser. However, we understand that it will happen, so there is some guidance within the documentation.

Requirements Documents

Questions

Below is a list of questions to be addressed as a result of this requirements document:

Question	Outcome	Decision Date
Can CAS do all the things OAuth does without the need for pre-registering Service Accounts? How does it handle the implicit grant scenario? Is CAS a protocol or a product? CAS 3.0 CAS REST CAS OAuth
What is Shibboleth and how does it fit into all this?	Shibboleth is an Open Source SSO Federation system. It seems to be focused on SSO. It doesn't look like the Application to * use cases that OAuth provide will be implemented by Shibboleth any time soon: OAuth 2 ... Neither the demand for this, nor the actual use cases, are very clear at the moment. It may have the Server Account Management functionality we're looking for in the Dev Portal: "Extensive and carefully-managed APIs to allow the software to be extended to support custom scenarios."	19 Jun 2018

Question

Outcome

Decision Date

Can CAS do all the things OAuth does without the need for pre-registering Service Accounts? How does it handle the implicit grant scenario? Is CAS a protocol or a product?

What is Shibboleth and how does it fit into all this?

Shibboleth is an Open Source SSO Federation system.

It seems to be focused on SSO.
It doesn't look like the Application to * use cases that OAuth provide will be implemented by Shibboleth any time soon: OAuth 2 ... Neither the demand for this, nor the actual use cases, are very clear at the moment.
It may have the Server Account Management functionality we're looking for in the Dev Portal: "Extensive and carefully-managed APIs to allow the software to be extended to support custom scenarios."

19 Jun 2018

Browser not supported