All campus data must be protected, just like any other institutional asset.
Berkeley's API management platform uses Transport Layer Security (TLS) to encrypt all integrations and to verify their senders and recipients. In addition, to allow accurate tracking and rate-limiting and to enforce specific data protection policies, EIS limits access to all APIs to verifiably identified client applications.
Authenticating API Calls
Client application identity is presented as a public "app_id" and authenticated via a corresponding private "app_key." These two form a credential pair for the client's application. Credential pairs are managed via the API Central developer portal, where access to a restricted API is requested and routed to the Data Owner for a decision.
Once access is granted, API Central account holders generate separate credential pairs for each environment (e.g., DEV, TEST, PROD) of the application. Authentication is enforced (and coarse-grained authorization given) at the API gateway layer by validating the credential pair that must be included in each request.
Fine-grained Authorization
Fine-grained authorization (FGA) enforces specific access rights on each data element in an API response—redacting or masking all elements not allowed for a particular client. This gives providers the freedom to design APIs and response payloads for campus-wide use, while still enabling data stewards precise control over which data is presented to whom.
Default Policy
The first step in implementing FGA is to describe a default policy, which identifies the group of restricted data elements to be redacted or masked by default in all the API's responses. Our architects can assist in identifying data elements that fall under government, University, and campus policy restrictions. The Data Owner can then choose to restrict access to any or all of these, as well as any other data they determine require extra protection.
Exception Management
After our DataPower appliance has been configured to enforce this default policy, exceptions can be added to allow access to any restricted data for any specific client—as identified by their app_id. This level of protection is completely decoupled from and seamless to both the API service and its clients.