UMA1 Interop Participants and Solutions

Go to Main UMA1 Interop Testing page | Features and Feature Tests page
Go to main UMA1 Interop Testing page 
Visit the uma-dev list archive
Participants in UMA1 testing must register on this page, either by editing the page or by contacting the UMA WG chair, and should subscribe  | Results

We are planning to do initial interop testing of UMA authorization servers against Roland Hedberg's test suite. Eventually we will test UMA resource servers and clients as well, and conduct cross- matrix testing. In preparation for these later phases, we began to register interop participants on this page; don't read too much into the solution information provided here for now.

Subscribe to the uma-dev mailing list , which will be used for interop-related communications. No ranking of other special meaning should be attached to the order in which participants appear. Participants must supply:

1. Links to participant's organization, organization logo, and Twitter handle (if any)
2. Names and emails of 1-2 key contacts participating in the interop and available during the interop event
3. Whether the contacts will be participating F2F or virtually
4. Which UMA roles are covered in each solution
5. Any other relevant details as discussed below:
   
   1. TBS (any particular desired testing partners, how many wired network drops needed if participating F2F, static IP addresses required, any special requests for the event or venue, ?)
   2. AS role only:
      
      1. TBS (how RS and C can get client credentials if not dynamic, ?)
      2. Link to the AS configuration data
   3. RS role only:
      
      1. TBS (API documentation, ?)
   4. C role only:
      
      1. TBS

for updates.

Participant information

...

Results

Record feature-test-specific results in this matrix. An example result for a FOO:AS-to-BAR:RS interaction attempt regarding the F-as-config test might read: FT-rs-get-config-data failed. Config data from FOO:AS was malformed.

Record rollup results in this matrix. An example cell for a FOO:BAR comparison might read: Detected failures when FOO is AS and BAR is RS or C. When FOO is RS and BAR is AS, succeeds.

Solution information: AS role

For the purposes of automating testing, one option is to use a query parameter with the name _umaauthn to convey a token string that enables login of an RO or RqP. Any RqP credentials provided in the form of "token strings" below can be used in this fashion.

It is assumed that the C is claims-unaware and will be using the redirect claim profile to redirect the RqP to the AS for login as the sole claims-gathering process.

The "Alice" user can be used as both an RO and an RqP, and the "Bob" user can be used as an RqP. The different RqPs can be used with the same client to test policies that discriminate between RqPs using the same client. Clients "A" and "B" can be easily used to test policies that discriminate between the same RqP using different clients.

Solution information: RS role

Any RS participating in interop needs to expose either multiple resource sets (as registered with the AS) or multiple scopes, or both. This enables testing UMA-specific interop around sufficient/insufficient authorization data, permission tickets that match or don't match the requested type of access, etc., while not dictating the specifics of what the API looks like. Each RS participant needs to provide enough information directly in the table below to explain how to access these differential resource sets and scopes, e.g. the URLs, parameters, etc. This way, clients can tell whether the RS was at fault or not if something goes wrong with authorization. It is recommended that each RS document exactly the one or two endpoints/calls/parameters that are sufficient for UMA interop testing purposes, to limit the universe of potential actions that a client can take.

Solution information: C role

As noted above, it is assumed that the C is claims-unaware and will be using the redirect claim profile to redirect the RqP to the AS for login as the sole claims-gathering process for assessing policy. There are currently (V0.9) not even any optional feature tests for claim profiles anyway, so we're not testing claims gathering at this stage.