...
...
...
...
...
...
UMA1 Interop Features and Feature Tests
Main UMA1 Interop Testing page | Participants and Solutions | Results | uma-dev list
...
A feature test identifier has three parts, separated by hyphens. Every identifier starts with FT. The second part indicates the software entity being tested: AS, RS, or C. The third part, which may have embedded hyphens, describes the nature of the test. The supporting clauses in the technical specifications have been classified using feature "tags". The tests are grouped under primary feature tags for ease of test result reporting:
- config: Machine-readability of entity capabilities and constraints.
- dynreg: Client registration of resource servers (which are clients of the AS's protection API) and clients of resource servers (which are also clients of the AS's authorization API) at run time when services have not "met" before a resource owner or requesting party forces the issue.
- pat: "Protection of the protection API" at the authorization server, and the association made between the authorization server, resource server, and resource owner as a result of protection API token (PAT) issuance.
- aat: "Protection of the authorization API" at the authorization server, and the association made between the authorization server, client, and requesting party as a result of authorization API token (AAT) issuance.
- protapi: RS-AS communication through the protection API and its various endpoints.
- authzapi: C-AS communication through the authorization API and its various endpoints.
- access: C-RS communication through the UMA-protected resource interface for the purpose of attempting and granting or denying access.
- error: Requirements for error messages.
"config" feature tests.
Feature tests for "config"
Machine-readability of entity capabilities and constraints.
asdf
Feature tests for "config"
asdf
| Identifier | Required? | Description | Success |
|---|---|---|---|
| FT-as-config-data | req | AS provides configuration data that conforms to specified formats and provides all required properties and values. | Data conforms and is complete
|
FT-as-config-endpt | req | AS makes config data available through https://as_uri/.well-known/uma-configuration. | AS config data endpoint uses https: scheme with specific URL form, with a valid certificate |
| FT-rs-get-config-data | opt | RS successfully accesses and parses AS config data properties it needs at https://as_uri/.well-known/uma-configuration, including all endpoint-related properties not specific to the RS and including handling of non-understood extension properties. | RS successfully accesses and parses AS config data |
| FT-c-get-config-data | opt | Client successfully accesses and parses AS config data properties it needs at https://as_uri/.well-known/uma-configuration, including all endpoint-related properties not specific to the client and including handling of non-understood extension properties. | Client successfully accesses and parses AS config data |
Feature tests for "dynreg"
...
Client registration of resource servers (which are clients of the AS's protection API) and clients of resource servers (which are also clients of the AS's authorization API) at run time when services have not "met" before a resource owner or requesting party forces the issue.
| Identifier | Required? | Description | Success |
|---|---|---|---|
| FT-as-dyn-client-reg | opt | AS config data "dynamic_client_endpoint" property is non-nullAS config data "dynamic_client_endpoint" property has a valid URL value for a DynClientReg endpointprovides a URI value | Property has a URI provided |
| FT-rs-get-dyn-client-creds | opt | RS interacts with AS to request and receive client credentials dynamically | RS gets client credentials dynamically |
| FT-c-get-dyn-client-creds | opt | C interacts with AS to request and receive client credentials dynamically | C gets client credentials dynamically |
Feature tests for "pat
...
"
"Protection of the protection API" at the authorization server, and the association made between the authorization server, resource server, and resource owner as a result of protection API token (PAT) issuance.
| Identifier | Required? | Description | Success | ||||
|---|---|---|---|---|---|---|---|
| FT-rs-get-pat | req | AS issues PAT to RS given correct using OAuth authorization_code grant flow (required by the spec) and request for protection API scope | AS issues PAT to RS IFF RS engages correctly and with correct scope | ||||
| FT-as-pat-config | req | AS supports PAT grant types as declared in configuration data | AS configuration data contains at least authorization_code grant type and optionally SAML bearer token grant type for PATs | FT-as-require-pat | req | AS requires OAuth clients of protection API (definitionally, RSs) to present valid OAuth access tokens with protection API scope in order to use endpoints | AS allows RSs to make protection API calls IFF they present protection API scope |
| FT-rs-use-pat | req | RS presents valid OAuth access token with protection API scope when making calls to all protection API endpoints | RS presents PAT to all protection API endpoints |
Feature tests for "aat"
...
"Protection of the authorization API" at the authorization server, and the association made between the authorization server, client, and requesting party as a result of authorization API token (AAT) issuance.
| Identifier | Required? | Description | Success | ||||
|---|---|---|---|---|---|---|---|
| FT-c-get-aat | req | AS issues AAT to Client given correct OAuth authorization_code grant flow (required by the spec) and request for authorization | AS issues AAT to client IFF client engages correctly and with correct scope | FT-as-aat-saml | opt | AS issues AAT to Client given correct OAuth SAML (urn:ietf:params:oauth:grant-type:saml2-bearer) bearer token grant type and request for authorizationAPI scope | AS issues AAT to client IFF client engages correctly and with correct scope |
| FT-as-aat-config | req | AS supports AAT grant types as declared in configuration data | AS configuration data contains at least authorization_code grant type and optionally SAML bearer token grant type for AATs | FT-as-require-aat | req | AS requires OAuth clients of authorization API (definitionally, Clients) to present valid OAuth access tokens with authorization API scope in order to use endpoints | AS allows Client to make authorization API calls IFF they present authorization API scope |
| FT-c-use-aat | req | Client presents valid OAuth access token with authorization API scope when making calls to all authorization API endpoints | Client presents AAT to all authorization API endpoints |
Feature tests for "protapi"
...
RS-AS communication through the protection API and its various endpoints.
| Identifier | Required? | Description | Success | ||||||
|---|---|---|---|---|---|---|---|---|---|
| FT-as-rsr | req | AS successfully presents all of the following methods at a resource set registration endpoint of form {rsreguri}/resource_set/{rsid}, and treats others as unsupported: PUT with unique ID to register new resource set description; GET with unique ID to read already-registered resource set description, handling the presence of any policy_uri property in AS's response; PUT with If-Match and unique ID to update already-registered resource set description, handling the presence of any policy_uri property in AS's response; DELETE with a unique ID to delete an already-registered resource set description; and GET on resource_set path to read list of already-registered resource set descriptions. | AS presents all elements of resource set registration API correctly | ||||||
| FT-rs-rsr | req | RS successfully uses: PUT with unique ID to register new resource set description; GET with unique ID to read already-registered resource set description, handling the presence of any policy_uri property in AS's response; PUT with If-Match and unique ID to update already-registered resource set description, handling the presence of any policy_uri property in AS's response; DELETE with a unique ID to delete an already-registered resource set description; and GET on resource_set path to read list of already-registered resource set descriptions. RS links to well-formed scope descriptions and provides well-formed resource set descriptions. | RS uses all elements of resource set registration API and scope and resource set description formats correctly | ||||||
| FT-as-rsr-error | req | AS issues errors for resource set registration error conditions, including unsupported_method_type, not_found, and precondition_failed. | AS issues resource set registration API errors for error conditions | ||||||
| FT-as-rsr-scope-ext | req | If a scope description contains extension properties, the AS proceeds normally in handling the scope description. | AS does not produce an error on encountering extension properties in scope description | ||||||
| Test ID | Type | Role | Description | Success | |||||
| FT-unprotected-resource | req | RSRS responds to access request for unprotected or otherwise non-UMA-protected resource without including anything UMA-specific in the response | RS responds in non-UMA fashion | ||||||
| FT-rs-no-rpt | req | RS | RS responds to client not bearing an RPT with HTTP 401 and correct as_uri corresponding to AS protecting the resource to which access was attempted | RS responds with HTTP 401 and as_uri | |||||
| FT-c-get-rpt | req | C | Client presents valid AAT at AS's RPT endpoint to get RPT | Client qualifies for and gets new or refreshed RPT | |||||
| FT-as-issue-rpt | req | AS | AS issues RPT in response to client's request for an RPT at the correct endpoint with a valid AAT; if an existing RPT associated with this AAT was still valid, it is invalidated when the new RPT is issued (see above for issue) | AS issues RPT | |||||
| FT-c-rpt | req | C | C requests access to a resource with an RPT | ||||||
| FT-rs-introspect-rpt | req, rpt-bearer | RS | RS presents a valid RPT at AS's token introspection endpoint to get token's status (see above for issue). | RS gets well-formed RPT status | FT-as-introspect-rpt | req | AS | AS returns RPT's status in response to RS request | AS returns well-formed RPT status |
| FT-rs-invalid-rpt | req | RS | RS responds to client bearing an invalid RPT with HTTP 401 and correct as_uri corresponding to AS protecting the resource to which access was attempted | RS responds with HTTP 401 and as_uri | FT-rs-register-permission | req | RS | RS presents a valid PAT at AS's permission registration endpoint to register a requested permission that is relevant for the type of access attempted by client (see above issue) | RS registers requested permission |
| FT-as-permission-ticket | req | AS | AS registers permission associated with correct resource owner and resource set and returns securely random permission ticket in response to RS registration of requested permission (see above issue) | AS returns permission ticket that is securely random |
Feature tests for "authzapi"
C-AS communication through the authorization API and its various endpoints.
| Test ID | Type | Role | Description | Success | ||||||
|---|---|---|---|---|---|---|---|---|---|---|
| FT- | rsc- | insufficientget- | permsreq, rpt-bearer | RS | RS responds to client bearing a valid "bearer" profile RPT that has insufficient permissions with HTTP 403, as_uri, and permission ticket corresponding to resource for which access was attempted | RS responds with HTTP 403, as_uri, and permission ticketrpt | req | C | Client presents valid AAT at AS's RPT endpoint to get RPT | Client qualifies for and gets new or refreshed RPT |
| FT-as-issue-rpt | req | AS | AS issues RPT in response to client's request for an RPT at the correct endpoint with a valid AAT; if an existing RPT associated with this AAT was still valid, it is invalidated when the new RPT is issued (see above for issue) | AS issues RPT | ||||||
| FT-c-add-authz-data | req | C | Client presents valid AAT, valid RPT, and permission ticket at AS's authorization endpoint to POST request that authorization data be associated with RPT | Client receives back normal success or error message | ||||||
| FT-as-deny-authz-data | req | AS | AS determines that the client should not get authorization data, and returns either an invalid_ticket error, an expired_ticket error, or a not_authorized_permission error | AS returns one of the errors | ||||||
| FT-as-give-authz-data | req | AS | AS associates new authorization data with the RPT that the client presented and responds with success | AS adds authorization data and responds with success | ||||||
| FT-as-need-claims | req, rptbearer | AS | AS indicates it needs requesting party claims to considering adding permission to "bearer" profile RPT | AS responds to the client with a need_claims error | ||||||
| FT-c-claims-redirect | req, humanrqp | C | Client redirects human requesting party to AS to provide claims, providing whatever data is required by the selected claim profile | AS redirects requesting party to AS | ||||||
| FT-as-oidc-client | opt, claim-oidc | AS | AS correctly acts as OpenID Connect relying party as defined by the OpenID Connect claim profile | AS acts correctly? |
Feature tests for "access"
C-RS communication through the UMA-protected resource interface for the purpose of attempting and granting or denying access.
| Test ID | Type | Role | Description | Success |
|---|---|---|---|---|
| FT-unprotected-resource | req | RS | RS responds to access request for unprotected or otherwise non-UMA-protected resource without including anything UMA-specific in the response | RS responds in non-UMA fashion |
| FT-rs-no-rpt | req | RS | RS responds to client not bearing an RPT with HTTP 401 and correct as_uri corresponding to AS protecting the resource to which access was attempted | RS responds with HTTP 401 and as_uri |
| FT-c-rpt | req | C | C requests access to a resource with an RPT | |
| FT-rs-insufficient-perms | req, rpt-bearer | RS | RS responds to client bearing a valid "bearer" profile RPT that has insufficient permissions with HTTP 403, as_uri, and permission ticket corresponding to resource for which access was attempted | RS responds with HTTP 403, as_uri, and permission ticket |
| FT-rs-respect-authz-data | req | RS | RS limits access to resource that is currently under protection at an AS for which a valid RPT with valid authorization data has not been presented by a client | RS blocks and grants client's access according to RPT's current status |
Feature tests for "claims"
TBS.