Usage: SSO Enabled 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

For SSO enabled applications, 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 SSO Enabled web application needs to update the registration 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.

Alternate Future Scenario: An SSO Enabled student created application needs to retrieve registrations information for a given student. The application will retrieve information on behalf of the student who has logged in; and only that students information. The student created 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 and who the logged in student is in order to limit the scope of information to only the logged in students information. The web application and user information will be needed in order to limit access.

Goals

Out of Scope

Assumptions

Requirements

Must meet shared requirements of Usage: Application w/ User to Resource Server Requirements

Ticket(s)TitleUser StoryPriorityNotes

SSO End User AuthenticationAs an Application Developer, I want to authenticate my end user using a Campus SSO solution.MUST HAVE
  • CAS 3.0
    • Potentially this could work if the CAS /serviceValidate endpoint can return a JWT token. (Research)
    • The CAS 3.0 ticket is short lived and can't be kept around like an OAuth access_token. CAS ticket will not be able to be transmitted to the Resource Service for validation.
  • OAuth 2.0





User Interaction, Design & Architecture

Service Architecture for OAuth Token (PowerPoint)


Sequence Diagram for OAuth Token (WebSequenceDiagrams Link)


Service Architecture for OAuth JWT (PowerPoint)



Sequence Diagrams 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
Can CAS 3.0 return a JWT? Will it be able to use the same keystore as the OAuth 2.0 endpoint?
How similar will the CAS 3.0 verification response be to an Auth 2.0 authentication code response?