Usage: Application w/ User to Resource Server Requirements

Owned by Steven Maglio
Last updated: Jul 11, 2018
3 min read
Project TitleCampus 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 updating 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.

Real World Scenario: An Engineering web application needs to update the registrations status for a given student. The web application will need to call through the API Gateway to the Registrations service. The Registrations service will need to know who the client application is in order to limit the scope of students that can be updated (ie. the Engineering web app call only look up Engineering students). Since this is an update, the audit log will also need to show who the user was that made the update. The user isn't used for access scoping, just 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.
  • Define a policy on Token Lifespan of 9 hours for password grant.

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.
  • 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

Ticket(s)TitleUser StoryPriorityNotes

Identify End UserAs 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 UserAs a Campus IdM Admin, I need authenticate the End User before the Resource Service can grant access.MUST HAVE
  • Should use password grant.
  • The End User Token will only be valid for particular amount of time. The Web Application will need to have a Session Timeout Period the same time period or less.
  • For Staff Web Applications, Student Affairs requires our SSO Token lifespan to be a minimum of 9 hours.

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

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 for OAuth Token (PowerPoint)


Sequence Diagram for OAuth Token (WebSequenceDiagrams Link)



Service Architecture for OAuth JWT (PowerPoint)


Sequence Diagram for OAuth JWT (WebSequenceDiagrams Link)



Examples and References

Questions

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

QuestionOutcomeDecision Date