[WG-UMA] Discussion on Github Issue #99

Eve Maler eve at xmlgrrl.com
Tue Aug 26 14:57:40 CDT 2014

I'd like to discuss and hopefully get to a disposition on this issue in Thursday's call. As stated below, there are really a couple of things going on in the issue.

One is the completion of the binding of an RPT to a specific RS, and it's proposed below that the client specify the desired RS in a host_id parameter to achieve this. Yuriy, I think you had some thoughts on this when last we spoke about it -- something about a model that allows multi-RS vs. single-RS binding? Can you shed light ahead of the call in email?

The other is the question of compressing two cycles into one, from:

C attempts access at RS with no RPT
RS fails with as_uri
C gets RPT at AS
C attempts access at RS with RPT
RS gets permission ticket at AS
RS fails with as_uri and permission ticket
C attempts access at RS with no RPT
RS gets permission ticket at AS
RS fails with as_uri and permission ticket
As noted, there are pros and cons on each side. Here are some choices we face (maybe I'm missing some), with some pros and cons attached (again, maybe I'm missing some):

Option 1: keep current "long flow"
Pros: doesn't ask RS and AS to perform work until C has done some work; backwards compatible (= identical) with V0.9 behavior
Cons: more multi-party HTTP interactions just to get access the first time

Option 2: switch to "short flow"
Pros: shortens the number of HTTP interactions that lead to access
Cons: C could force RS to do a lot of work getting permission tickets in DoS fashion; backwards incompatible with V0.9 behavior

Option 3: let the RS freely choose which flow to use
Pros: lets the RS assess context, trust relationships, etc. (could do it once but refuse a second time on seeing the same C) and still requires simple deterministic behavior from the C: if no ticket, get RPT and retry; backwards compatible with V0.9 behavior
Cons: introduces optionality into the spec


On 15 Aug 2014, at 1:06 PM, Casey Gilray <casey.gilray at forgerock.com> wrote:

> As issue #99 stands now there is an open question as to whether it would be better to automatically send a ticket along with an RPT to the clients instead of forcing them to request a ticket separately. Currently the client must request a resource from the RS and be sent an error requesting that the client get an RPT. The client obtains the RPT and tries the request again in order gain a permission ticket. The proposed work around is for the RS to obtain the RPT and automatically register the sought permissions, then return the new RPT along with the permissions ticket.
> There are valid reasons to have both paths available. Issuing the ticket automatically may tie up more resources on the server side but this also frees the client from making several requests. This leaves the server more vulnerable to denial of service attacks at this endpoint. If you are not a high value target for DDoS or are otherwise not worried about attacks then having the server automatically issue the ticket along with the RPT would be a valid solution.
> The second part of issue #99 deals with the binding between an RPT and the RS. When a client obtains an RPT there is no notion of which RS this RPT will be used with. It was suggested that the Client pass a host ID, a identifying token which is known by the AS. These hostID tokens could be stored dynamically or have static “trusted” host IDs depending on the security demands of the implementation.
> In an attempt to open discussion to close issue #99 I will pose the following question: Would it be possible to add into the spec the option for the RS to either obtain and create tickets for requests automatically or make the client obtain and re-request with a new RPT OR, leave the spec as is where the client is forced to obtain their RPT from the AS, then attempt the request again to get the permissions ticket.
> Secondly, In regards to binding could the RPT request include a host_id parameter that could match to a list of known and trusted RS’s, thus binding each RPT to one specific RS?
> Link to issue #99: https://github.com/xmlgrrl/UMA-Specifications/issues/99

Eve Maler                                  http://www.xmlgrrl.com/blog
+1 425 345 6756                         http://www.twitter.com/xmlgrrl

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kantarainitiative.org/pipermail/wg-uma/attachments/20140826/7dc8ee55/attachment-0001.html>

More information about the WG-UMA mailing list