[WG-UMA] Discussion on Github Issue #99

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


Oh, I'm sorry that my comments were passionate ;)

On 26 August 2014 21:25, Eve Maler <eve at xmlgrrl.com> wrote:

> Aha, I was trying to be dispassionate in my recital of the options, but
> since you add value judgments... :-) Here are my opinions:
>
> On 26 Aug 2014, at 1:16 PM, Maciej Machulak <maciej.machulak at gmail.com>
> wrote:
>
> 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?
>
>
> It's true that the added chattiness is a one-time thing, and therefore
> perhaps not a huge burden. I think that's why we stuck with the long flow
> all this time.
>


Yes, I agree.

>
>
>
>>
>> *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
>>
>
> It would make me a little nervous to enforce this as the only option.
>

Yes, I agree.

>
>
>> *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.
>
>
> The logic doesn't seem hugely burdensome: literally "if no ticket, get RPT
> and retry". This is actually a place where I'm not as bothered by the
> optionality as I usually am, because it lets the RS take circumstances into
> account, and that feels like an implementation/deployment-level choice. We
> would have to figure out if there's a mandatory to implement (MTI) option
> between the two (if so, the chatty version seems preferable).
>
> What do others think?
>

Yes, I think this chatty option is definitely the preferred one. By the way
- a related comment to this: This will work OK with the current spec where
requesting the RPT for the first time can only result in the RPT being
issued to the client. Once this part of the flow (Section 3.4.1) involves
any error messages, wouldn't that add some more complexity to the client
eventually? Is the returned error because "the client cannot access any
resources of this RS" or because "policy associated with that resource set
does not allow access" - that's hypothetical anyway but just a comment that
there are no error messages for Section 3.4.1 and if such are introduced
then there might be slightly more than just "if no ticket, get RPT and
retry".

What do you think?

It's actually related to the comment that was mentioned earlier in this
thread to allow the RPT to be associated with RS when this RPT is first
issued (i.e. include the host_id in the request). Such request may result
in an error, potentially based on policy, I think.

Cheers,
Maciej


>
>
>
>>
>> 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)
>
>
>
> Eve Maler                                  http://www.xmlgrrl.com/blog
> +1 425 345 6756                         http://www.twitter.com/xmlgrrl
>
>


-- 
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/c4e7b56b/attachment-0001.html>


More information about the WG-UMA mailing list