When proxying calls to your back end API, the API Manager adds a header with details gathered during the authentication process. These details are commonly used for:
...
...
- Standard JWT Claims - part of the JWT spec
- Authorization Invocation Claims - details about how authentication api was performedcalled
- Application Details - details about the application invoking the API
- User Details - details about the user that the application is working on behalf of
...
| Note |
|---|
Some API developers choose to "trust" the application and have the application provide user details as other headers or part of the payload. These details are not verified by the APIM which means that API developers have to be more careful about which applications they grant subscriptions to. Claims in the JWT cannot be spoofed by a "rogue" application as they are independently gathered by the APIM. |
Standard Claims
The JWT specification includes a number of possible claims. The JWT contains the following standard claims:
Claim | Value |
|---|---|
| iss | Issuing entity. This will be the domain of the identity server used to create the JWT. Adding the URI fragment "/.well-known/openid-configuration" to the value will produce the location of the OpenId Connect Discover document for this domain. See the OpenId Connect Discovery document for details on using this value. See validation instructions above for information about using this claim. |
| exp | Expiration time in Unix format |
Authorization Claims
Claim | Value |
|---|---|
| http://wso2.org/claims/subscriber | The APIM user who registered the application making the invocation. This really shouldn't be used for anything other than contact information, instead use the application name. Eventually we hope to allow teams to jointly manage application registrations, which will make this field even less useful. |
| http://wso2.org/claims/applicationname | The name of the registered application that is invoking the API. The Client / Secret pair used during invocation maps to the application registration. |
| http://wso2.org/claims/apicontext | The context of the API invoked. This is unique to each API registered in the APIM and can be used to determine which API the user invoked if multiple APIs point to a single backend. |
| http://wso2.org/claims/version | The version of the API invoked. Useful if the backend API supports multiple versions of it's interface, although most back end implementations choose to include the version on the URL. |
| http://wso2.org/claims/tier | The throttling tier of the subscription used. Almost never used. It can be used to provide different "tiers" of service to different consumers. Which tiers are available to subscribers are selected by the API publisher from a global list maintained by the APIM administrators. Currently UCSD does not utilize this feature and almost all subscriptions select "Unlimited" |
| http://wso2.org/claims/enduser | The APIM user who invoked the API. This value shouldn't be used as it's their APIM username, which has no meaning outside of the APIM. Instead use the SSO details described below. |
Invocation Details
Claim | Value |
|---|---|
| http://wso2.org/claims/apicontext | The context of the API invoked. This is unique to each API registered in the APIM and can be used to determine which API the user invoked if multiple APIs point to a single backend. |
| http://wso2.org/claims/version | The version of the API invoked. Useful if the backend API supports multiple versions of it's interface, although most back end implementations choose to include the version on the URL. |
| http://wso2.org/claims/keytype | Most APIs send Production/Sandbox (or QA/Dev) requests to different backend. In the case that both go to the same backend service, this value can be used to determine which version was invoked. Specifically if a "PRODUCTION" or "SANDBOX" key was used. Note: on QA we have adjusted the UI to say "QA" and "Dev", but this value will still be "PRODUCTION" or "SANDBOX" |
| http://wso2.org/claims/usertype | The type of OAuth 2.0 grant used for authorization. "APPLICATION_USER" for grant types that include a Resource Owner (authorization_code, implicit, resource owner password). "APPLICATION" for those that only have a Client (client credentials). When set to "APPLICATION", no user details will be included. |
Application Details
Claim | Value |
|---|---|
| http://wso2.org/claims/subscriber | The APIM user who registered the application making the invocation. This really shouldn't be used for anything other than contact information, instead use the application name. Eventually we hope to allow teams to jointly manage application registrations, which will make this field even less useful. |
| http://wso2.org/claims/applicationid | The ID of the registered application. Less descriptive and more brittle than the application name, it may be useful in certain scenarios where high security is needed. |
| http://wso2.org/claims/applicationname | The name of the registered application that is invoking the API. The Client / Secret pair used during invocation maps to the application registration. |
| http://wso2.org/claims/applicationtier | The throttling tier of the registered application. Used even less than http://wso2.org/claims/tier. |
| http://wso2.org/claims/tier | The throttling tier of the subscription used. Almost never used. It can be used to provide different "tiers" of service to different consumers. Which tiers are available to subscribers are selected by the API publisher from a global list maintained by the APIM administrators. Currently UCSD does not utilize this feature and almost all subscriptions select "Unlimited" |
| http://wso2.org/claims/enduser | The APIM user who invoked the API. This value shouldn't be used as it's their APIM username, which has no meaning outside of the APIM. Instead use the SSO details described below. |
User Details
Claim | Value |
|---|---|
| http://wso2.org/claims/enduser | The APIM user who invoked the API. This value shouldn't be used as it's their APIM username, which has no meaning outside of the APIM. Instead use the SSO details described below. |
| http://wso2.org/claims/enduserTenantId | The APIM can be setup to segregate users and apis into different tenants. UCSD is not utilizing this feature so this claim has no meaning. |
| http://wso2.org/claims/role | The Roles associated with the user in the APIM system. These are not roles from any external source (e.g. AD) and have no meaning outside the APIM. |
...
All other values in the table should be filled in with the appropriate information.
Relationship records should only be added for applications under the control of a BYU entity. There is no need to add them for individuals publishing their own applications. Currently there is no defined process for approving and adding these relationship records.
...