Usage: Application w/ User to Resource Server Requirements

Project Title	Campus API Gateway
Target Release
Epic
Document Status	DRAFT
Document Owner
Document Sign-Off
Subject Matter Expert(s)
Technical Expert(s)

Background & Business Value

Frequently when updated a resource not only does the Calling Application need to be known, but the End User that is attempting to perform the update also needs to be known. Either one or both are needed to properly determine if the action is authorized, while both are needed for audit logging.

Goals

All Goals from Usage: Application to Resource Server Requirements
Provide a way to get identifying information for both the Client Application and the End User.
- This identifiers should be used for both authorization and audit logging.

Out of Scope

Defining Resource Server (Service) Authorization/Permissions System.

Assumptions

All Assumptions from Usage: Application to Resource Server Requirements
Campus IdM system will support the password grant type.
It is a requirement that ucsbNetId's for Service Accounts must be unique and non-changing.
- They should be able to be reused. But the expectation is that if a service account changes names, it will need to have it's permissions reestablished in all downstream systems.

Requirements

Must meet requirements from Usage: Application to Resource Server Requirements

Title	User Story	Priority	Notes
Identify End User	As a Client Developer, I need a way to provide the Resource Service with authenticated identity information about who is using my application.	MUST HAVE	Should need both Service Account `ucsbNetId` and `password`, and the End User `ucsbNetId` and `password`. OAuth call should go against Apigee OAuth endpoint. Apigee will pass through the call to Campus IdM The Campus IdM response will pass through back to the client
Authenticate End User	As a Campus IdM Admin, I need authenticate the End User before the Resource Service can grant access.	MUST HAVE	Should use p assword grant. Will return `Apigee client_id`. If not directly in the response, then the information should be attainable from an Introspection Endpoint. What does the Introspection Endpoint return for this grant type?
Verify End User in Resource Server (Service)	As a Resource Service Developer, I need a way to provide the Resource Service with authenticated identity information about who is using my resource.	MUST HAVE	The PingIdentity server will need to validate the `access_token` given. This should use the PingIdentity servers validate_bearer grant type.
Authorize End User & App in Resource Server (Service)	As a Resource Service Developer, I need to be able to lookup permissions and enforce access authorization.	MUST HAVE	For application specific permissions, the Authorization Provider should be determined by the Resource Service Developer. This can be something created solely by the developer for their needs or it can be a campus provided solution.
Verify App in Resource Server (Service)	As a Resource Service Developer, I need to be able to provide the Resource service with authenticated identity information about the client application using my resource.	NICE TO HAVE	The PingIdentity server will need to validate the `access_token` given. This should use the PingIdentity servers validate_bearer grant type. The response should include the Client Service Account `ucsbNetId`. There does not seem to be a way to get the Client Service Account `ucsbCampusId`. Because of this, it is a requirement that `ucsbNetId`'s for Service Accounts must be unique and non-changing. They should be able to be reused. But the expectation is that if a service account changes names, it will need to have it's permissions reestablished in all downstream systems.

User Interaction, Design & Architecture

Service Architecture (PowerPoint)

Sequence Diagrams (WebSequenceDiagrams Link)

Examples and References

Questions

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

Question	Outcome	Decision Date
Can you use the Introspection Endpoint from the Resource Service? Is the original client_id and client_secret required? Or will it work with the client_id of the Resource Service (Registrations SVC `ucsbNetId`)?
What does the Introspection Endpoint return for the password grant type? Does it return both the End User ucsbNetId and the client_ID (Client App `ucsbNetId`)?	It returns both the `sub` (End User `ucsbNetId`) and the `client_id` (Client App `ucsbNetId`).	28 May 2018