Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Next »

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

We would like to simplify the usage of the Campus API Gateway by making it's Developer Portal integrated with the Campus IdM solutions.

Goals

  • An easy way to sign into the Developer Portal
    • Preferably you would be able to sign in using the Campus SSO solution
    • If possible, the ability to create a Campus IdM Team Account at the time of registration with the Developer Portal
  • An easy way for Teams of Developers to manage Groups of Applications
  • An easy way to associate API Gateway Applications with Campus IdM Service Accounts for use with OAuth Authentication
    • If possible, the ability to create a Campus IdM Service Account at the time of registering an Application
    • If possible, the ability to delete a Campus IdM Service Account at the time of Application removal
  • An easy way to pass in an Apigee Client ID to an attribute on a Campus IdM Service Account

Out of Scope

Assumptions

  • Campus IdM will support Application Accounts (Service Accounts).
    • Application Accounts (Service Accounts) Description from ETSC (UCSB isDesk):
      > 2018-05-25 10:06:09 - Laurie Branagan (Additional comments)
      > App accounts were created to allow for programmatic access to the
      > directory without embedding a person's credentials in the application. They
      > were not scoped to be used for authorization beyond access to the
      > directory. It's understood this utility is somewhat limited.
      > If what you're requesting is non-person entities in the directory - That
      > feature is on the roadmap document that the Identity Advisory Group drafted
      > last year. It has not been implemented.
  • We will eventually integrate Developer Portal logins with Campus SSO.

Requirements

Ticket(s)TitleUser StoryStory GroupingPriorityNotes

Apigee Developer AccountAs an Application Developer, I would like to sign into the Developer Portal using an email address that is shared by a development team on campus (ends in @*.ucsb.edu)
DEPRECATE

This is the way the system currently works. We would like to move away from this.

  • Currently the system has no way of sharing access to Applications between multiple logins. So, you need to create a "shared" login to be able to do that. We call these functional accounts.
  • These are used to register actual applications so they can be maintained by a team of people.
  • These accounts must be created using shared emails address with @*.ucsb.edu addresses.
  • The passwords for these are only usable in the Developer Portal. The password will not be stored anywhere or retrievable after creation.
  • It is a requirement that the person who created the password must store and share the password safely with their team.
  • There is a way to reset a password.

Apigee Application AccountAs an Application Developer, I would like to Register an Application with the account I logged in with.
DEPRECATE

This is the way the system currently works. We would like to move away from this.

  • Applications are only visible to Developer Account which created them.
  • Applications can be created and deleted by the Developer Account through the Developer Portal at any time.
  • Currently when system creates an Application it also generates a unique client_id as the identifier.
  • All permissions to Apigee API's are granted based upon the internal client_id.
  • For OAuth to work the client_id will need to be set as attribute on a Service Account record in our Campus Id system.


As a Third Party Company that is implementing a project with a campus department, I would like to register an account with the Developer Portal.
MUST HAVE

Campus Application Service AccountAs an Application Developer, I need the Campus to have the ability to create Service Accounts for my Applications. 
MUST HAVE
  • They must have UCSB Net IDs and Passwords that can be Authenticated through OAuth
  • There will need to way to enter the Service Account UCSB Net ID for association.
  • When an Apigee Application is Created, the Apigee Client Id will need to be pushed into the Campus IdM's Service Account as an Attribute.
    • The Apigee Client Id attribute must be retrievable as an OAuth claim or "access token key/value pair".


As an Application Developer, I would like to create a UCSB Service Account with a UCSB Net ID and Password for my Application at the time of Registration.
NICE TO HAVE


As an Application Developer, I would like to sign in using my UCSB Net ID and password in order to do Proof of Concept work.API ACCOUNTMUST HAVE

This IS NOT the way the system currently works. But, it can be easily implemented. This IS an edge-case, not the main use case.

  • During account creation, the UcsbCampusId will be stored in Apigee as the foreign key.
  • These are intended for Developers to do Proof of Concept work and generally try things out.


As an Application Developer, I would like to Register an Application with a UCSB Net ID Service Account which will belong to currently logged in account.API ACCOUNTMUST HAVE

This is NOT the way the system currently works. But, is needed in all scenarios.

  • There will need be a way add the Campus Service Account UCSB Net ID.
  • The ucsbNetId should be stored in Apigee as a custom attribute on the Application
  • The Campus IdM system should populate an apigeeClientId attribute on a Service Account record
    • If the Service Account already has an apigeeClientId associated with it, it should return an error. Campus IdM Service accounts should only be associated with on apigeeClientId.
    • If the UCSB Net ID given is not a Service Account it should throw an error.


As an Application Developer, I would like to sign into Developer Portal using a UCSB Net ID and Password that was created for a Campus Development Team.IDM TEAMSNICE TO HAVEThis would require the Campus IdM Team to implement "Group/Team Accounts" that would have UCSB Net ID's and Passwords.


As an Application Developer, I would like to Register an Application with a UCSB Net ID Service Account which will belong to the Campus Developer Team.IDM TEAMSNICE TO HAVEThis would require the Campus IdM Team to implement "Group/Team Accounts" that would have UCSB Net ID's and Passwords.


As an Application Developer, I would like to sign into the Developer Portal using my UCSB Net ID and Password.API TEAMSNICE TO HAVE

This would require the Apigee Product Suite to implement a Teams functionality.





As an Application Developer, I would like to belong to one or more Development Teams.API TEAMSNICE TO HAVE

This would require the Apigee Product Suite to implement a Teams functionality.





As an Application Developer, I would like to Register an Application with a UCSB Net ID Service Account with a Development Team.API TEAMSNICE TO HAVE

This would require the Apigee Product Suite to implement a Teams functionality.









User Interaction, Design & Architecture

Product and Component Architecture of Apigee Suite


Current Account and App Creation (WebSequenceDiagram Link)


Simple SSO and Service Account Association (WebSequenceDiagram Link)


Campus IdM Team SSO and Service Account OAuth Association (WebSequenceDiagram Link)

  • Maybe 


Simple SSO with Apigee Teams and Service Account Association (WebSequenceDiagram Link)

  • The Apigee Team claimed they have something like this in the Roadmap; but it really didn't sound right. Like they were talking about something that used the term "Group" but didn't have to do with grouping Developers together.
  • If we did this, the Campus API Team would have to develop it from the ground up; so it would probably never happen.

Examples and References

Questions

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

QuestionOutcomeDecision Date
  • No labels