Page tree
Skip to end of metadata
Go to start of metadata

Fundamentals of API Authorization

Regardless of the particular machinery involved, users and clients must identify themselves to a service.  This means users and clients have identities and credentials.

Initial axioms (from Jim Fox)

  1. Internet2 has a recommended identity solution for people users --- Shibboleth and InCommon metadata.
  2. Internet2 has an identity system for services --- InCommon Certificate Service.
  3. Internet2 is all about federation and inter-institutional collaboration.

Users are already well taken care of with Shibboleth, InCommon metadata and person registries. We are developing APIs for the latter.  A service can easily identify a user and know about her (via attributes).  Federation allows services to identify users from different institutions.

What is needed is similar support for API clients---a registry of entities. An Entity Registry, of both services and clients, supported by a standardized API, seems necessary. Entity attributes, while not the same as those of a person, are similar and could be handled by similar APIs.

The InCommon Certificate Authority already gives us one potential method of support for entity federation. A client could use its certificate to register with an entity registry, or to get a credential from an authorization service.

Emerging Issues

IssueIDIssue TitleNotes

1

Entities as Agents

(Clients, Services)

A

Must have a registry in which they are an entry
BMust have accounts/credential sets
CMust be discoverable by potential clients
DMust have a trust anchor

 

 

API Security turns out to be the driver for taking up non-person entities

2

Authorization policies have a fundamental structure

ASUBJECT can perform ACTION on RESOURCE under CONDITIONS
BTrue = Allow
CFalse = Deny
 
3  
4  

 

 

 

  • No labels

2 Comments

  1. Note: A question for our issues list: Do we want to leverage the TLS client authentication mechanism for authenticating clients to services? Or JWTs? Or what?

  2. Caveats:

    • Shibb & InC constitute an identity solution for people who are strongly affiliated with one member institution (not a solution for researchers and scholars working independently or at non-member institutions, nor a really good solution for people affiliated with multiple institutions).
    • InC cert service provides verification of URL ownership traced back to a member institution, but seems less than an identity service:
      - may have multiple services at a single URL
      - essentially no other attributes