Topic

API access and authorization management is very important part of API setup.  We will have a roundtable to discuss your organization's approach to API security, authentication and authorization. You are welcome to bring a one pager document.

Logistics

  • 09 March 2023
  • Ashish Pandit (UCSD)
  • Louis Zelus
  • Brandon Rich
  • Gary Tomlin (The University of Auckland)
  • Jared Kosanovic
  • Jill Peterson
  • John Gunvaldson (UCSD)
  • Jon Terrones
  • Matthew Hailstone
  • Mike Hall
  • Rupert Berk
  • Swarnim Ranjitkar (UCSF)
  • jeff kennedy (The University of Auckland)

Notes

BYU

  • Moved off of WSO2 (transition to Tyk with Hydra OAuth2 integration doing API authentication and authorization).
  • Migration to Okta as the IdP (parties registered in Okta and getting tokens from the OAuth server, calling for resources and services as appropriate, validating the token issued by Okta).
  • Introducing the concept of permissions tied to the relying parties and injecting those into the access tokens being issued.
  • New permissions-mapping service at the core of this:
  • APIs then just need to know the defined permissions once that gets unpacked from the mapping tool (administrators in the UI give relying parties with certain permissions mapped to the API's functionality).  This is meant for the BFF back-end access to APIs.
  • Web Applications operate in the following way, still doing the human-user authentication:
  • The refactoring of the access controls for APIs has been driven by modernization concerns and wishing to strengthen cybersecurity relative to the previous arrangements.  Focusing on making sure the user+context and bound robustly to the consuming applications.
  • Positive implications here for better data governance and visibility from data stewards of who is using what.
  • For example, a user wanting information about a student from a Financial Aid perspective would not be entitled to see the same set of information about a student that might be seen from the perspective of an application in another business domain.
  • The permissions decision engine is connected with (or at least able to consume) information from the group-management system.

University of Washington

  • Starting some work on API Access Management.
  • Quite a history of certificate-based and mutual-TLS authentication.
  • Some twenty years of process APIs ("process" as in the MuleSoft approach)
  • Making changes for improved user experience, improved API performance, better security
  • Different access protocols and tokens are used for different classes of API, noting that system APIs provided by vendors use whatever the vendor chooses (which can be  password or whatever):
  • UW has two IdPs, one Shibboleth and one Azure AD, both able to provide OIDC credentials.
  • Current (X.509) and future (OAuth2) access enforcement looks like this = in future, the consumer gets a token minted from the OAuth2 that includes scopes:
  • Current-state data entities involved in API access management look like this, makes use of DNS entries:
  • Future-state model makes use of IdPs to gain access tokens and will look like this:
  • Subscriptions? What visibility exists of who has subscribed to and consumed from these APIs?  UW has each subscriber cast as an App Identity in the diagram above, with permission for access to a system.  Permission assignment happens with delegated responsibilities that track back up through this stack.  The model for access assignment is tied into the data governance and leverages similar processes (involving humans) to other kinds of access provisioning requests and fulfilment.

UCSD

Further Information

Resources

  • Wahlstrom, E. (2023) _Architect a Modern API Access Control Strategy_, Gartner for Technical Professionals, Article ID #G00723547, available at https://gartner.com/document/4005508 — A single technical pattern for API access control is not sufficient for all types of APIs that organizations must secure. To be successful, security and risk management technical professionals must establish five guiding principles and an identity fabric that’s optimized for API access control.

Participants


  • No labels