| Page Properties | ||||||||
|---|---|---|---|---|---|---|---|---|
|
Background & Business Value
Provide a secure and standardized way to access resources through the Campus API Gateway.
Goals
Out of Scope
Defining Authorization/Permissions System(s)
What we would like from Campus IdM
- New Accounts Types in Campus IdM
- 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
- Basic Security Requirements
- Developer Portal
- Campus Service Accounts
- API Gateway Integration Usage Scenarios
| 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 | 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
| Create from Template | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
| Page Properties Report | ||||||
|---|---|---|---|---|---|---|
|
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? | ||
| What is Shibboleth and how does it fit into all this? | Shibboleth is an Open Source SSO Federation system.
|