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)
- Internet2 has a recommended identity solution for people users --- Shibboleth and InCommon metadata.
- Internet2 has an identity system for services --- InCommon Certificate Service.
- 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
IssueID | Issue Title | Notes | ||||||||
---|---|---|---|---|---|---|---|---|---|---|
1 | Entities as Agents (Clients, Services)
| API Security turns out to be the driver for taking up non-person entities | ||||||||
2 | Authorization policies have a fundamental structure
| |||||||||
3 | ||||||||||
4 |
2 Comments
Keith Hazelton (wisc.edu)
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?
David Bantz (alaska.edu)
Caveats:
- may have multiple services at a single URL
- essentially no other attributes