[WG-UMA] Discussion on Github Issue #99

Maciej Machulak maciej.machulak at gmail.com
Tue Aug 26 15:16:00 CDT 2014


Hi Eve,

I would add these comments:


> *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
>

Just to bear in mind that the above con is "weak" as the RPT has to be
obtained only once per RS. Therefore, some may consider this interaction
negligible?


>
> *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
>

And also requires the client to be prepared to implement additional logic.


>
> Eve
>

Cheers,
Maciej


>
> 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
>
>
> _______________________________________________
> WG-UMA mailing list
> WG-UMA at kantarainitiative.org
> http://kantarainitiative.org/mailman/listinfo/wg-uma
>
>


-- 
Maciej Machulak
email: maciej.machulak at gmail.com
mobile: +44 7999 606 767 (UK)
mobile: +48 602 45 31 66 (PL)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kantarainitiative.org/pipermail/wg-uma/attachments/20140826/cba18de3/attachment.html>


More information about the WG-UMA mailing list