[WG-UMA] Pull?

Nat Sakimura sakimura at gmail.com
Sat Jul 3 13:22:15 EDT 2010


On Sat, Jul 3, 2010 at 2:01 AM, Joe Andrieu <joe at switchbook.com> wrote:
> I'm still a bit confused. I had understood there was a push/pull question
> for the host telling the AM about the resources it hosts, including enough
> information to process policy decisions. But I'm either misunderstanding the

Correct.

Then Eve was also talking about another step: The interpretation of
access token by the Host/Server. I do not think it has been talked
much in UMA context. (We have been doing it in AB context.) The access
token may have a structure so that it is computationally feasible for
the Host to judge the validity - or it could do access token resolve
to the AM to ascertain whether the access should be granted.

> conversation (which is likely) or the presumptions about communications
> flows are still in flux.
>
> If I understand your "pull" scenario, Eve, the AM is pulling the required
> policy data every time there is a request for an access decision. Also in
> that scenario, the host is contacting the AM in realtime to get the access
> decision. So, for this situation, why not have the host send the required
> policy information?

It is too late by then, I think, in many cases.

> Or at a minimum, a hash or count of the last policy
> infoset so the AM can know if it needs to pull the new policy set?

It does, at least in the AB case.

Let me explain again.

The players are Requester, Host, AM, and the User.

At the outset, Host is introduced to AM by the User.
At this point, Host metadata needs to be transferred to the AM.
It could be done either by Pull or Push but Pull seems to involve less
problems of server farm synchronization. Also, the Host is always
exposed to the internet, so there should not be the firewall problem.
Pull seems to be a logical way.

Then the user wishes to use a service by the Requester.
The requester needs to hand its request somehow, and obtain the User's
permission.
It could again be by Push or Pull.
To have less problem with the server sync, less network traffic and
Requester authentication via SSL/TLS, Pull again seem to be a better
solution. Note that the URL from which the request is being pulled may
come with the hash of it as the fragment of the URL. By looking at it,
the AM can decide whether to pull it or use the cache. However, the
Requester is not always on the internet. It may be behind the
firewall. In such a case, push may be required. It could also be
implemented as a "request registration service" that returns a URL for
the "Pushed" request. Then, the rest of the process is the same as the
Pull case. Note that if the Requester wishes, it could also use a
one-time URL with sufficient entropy such that the entropy of the URL
is larger than the User credential for sending some sensitive
information as well.

Then, in the WebApp flow, the AM returns the 'code' to the Requester,
which is used to obtain the access_token.

This 'access_token' then can be presented to the Host/Server to obtain
the data etc. Now, if the access_token is opaque, then the Host/Server
has to resolve it at the AM to obtain the meaning of it so that it can
decide what to return as the response (access token resolve case/Pull
Case). On the other hand, if the access_token has a structure that the
Host/Server can understand, then it does not need the access_token
resolve step. It could again be either way. The access_token resolve
case has the advantage that all the data access is practically logged
at the AM, while the other case has less network traffic and may be
able to cope with more network configurations - In fact, it can even
cope with Protocol Pigeons, though in which case the Host introduction
has to also be done out-of-band. (In fact, this could be sometimes a
requirement in high security network.)

So, there are four places whether Push or Pull (or None) can be chosen.

1) Host registration at AM
2) Requester Requesting access token to the AM through the User redirect
3) Requester Requesting data from the Host.
4) Host interpreting the access token: it may resolve with AM (pull)

In AB, the default is Pull-Pull-Push-None. When the Requester is
behind the firewall,
then it would be Pull-Push-Push-None. If the User demands the data
released to be logged realtime at AM, then it will be
Pull-Pull/Push-Push-Pull.

>
> Don't we also have the simultaneous question of whether or not there is a
> strong token verse a weak token authenticated in realtime?  If the token is

In UMA, token is shared by three parties. A secret shared by three parties are
no more secret, so it is not advisable to rely on the entropy of the token
for the security. We need explicit authentication through crypto.

> strong, then we can dramatically reduce the bandwidth costs in favor of
> computational cost. Whereas with a strong token, it seems to me the pull
> model is the worst of both worlds: a computationally expensive token, but
> the AM still has to talk to the host to verify current policy for every
> policy request (which doesn't seem like a good idea). Which a strong token,
> we could push the policy and keep host/AM chatter to a minimum.
>
> So, is it fair to say there are two schools of thought which are unresolved
> in UMA? One favoring real-time, high frequency communication between host &
> AM, but lightweight computation and one favoring minimal communication but
> accepting computation costs for tokens? It seems that if we pick one,
> several decisions get easier. I for one, am having a hard time following
> proposals that seem to suggest high-frequency communication and strong
> tokens.
>
> Maybe we need to support both schools, giving hosts both options. If so, it
> might make sense to be explicit about two modes for UMA, without mixing the
> two from a flow perspective. Perhaps this is the core of the question and
> I'm just now understanding where we are in the conversation.

IMHO, the options are the same as in AB, and it depends on the network
location of the Requester as well as the User's policy.


>
> If so, then the push/pull conversation still has unresolved issues on
> propagation delay, but am I tracking this correctly so far?
>
> -j
>
> Joe Andrieu
> joe at switchbook.com
> +1 (805) 705-8651
> http://www.switchbook.com
>
>
> On 7/1/2010 1:59 PM, Eve Maler wrote:
>
> Are you thinking of the AM pulling information about protected resources at
> the host, which might (if we can figure out how to do it) include
> host-specific policies that the user had set while visiting the host? The AM
> is the one making policy decisions that result in granting access tokens,
> even if we have a back channel where it's making the decisions in a fashion
> that respects the user-at-the-host's wishes.
> When it comes time, in step 3, for a host to figure out what to do when
> approached by a requester with an access token, we have two models in mind.
> One is for the host to validate the token (carried from the AM by the
> requester) locally, which requires the token to have some heft. The other is
> for the host to approach the AM in real time to get the token validated by
> it, which requires an interaction between them that I suppose could be
> called "pushing" a token and other information in a request, and then
> getting an answer back. (It could be done with a sort of a pull pattern
> too...? Having previously informed the AM where its "tokens waiting for
> decisions" will sit, the host can tell the AM it needs a decision, the AM
> can pull the necessary info, and then it can return an answer.)
> Hopefully this helps,
> Eve
> On 1 Jul 2010, at 10:57 AM, Joe Andrieu wrote:
>
> I have an idea about Push/Pull, but first a question.
>
> In the Pull scenario, when is the AM Pulling for policy?
>
> Does that occur every time a policy decision is required?  Or is it a
> polling mechanism at arbitrary intervals? Or something else? What triggers
> the pull?
>
> -j
>
> --
> Joe Andrieu
> joe.andrieu at auds.org
> +1 (805) 705-8651
>
> _______________________________________________
> WG-UMA mailing list
> WG-UMA at kantarainitiative.org
> http://kantarainitiative.org/mailman/listinfo/wg-uma
>
>
> Eve Maler
> eve at xmlgrrl.com
> http://www.xmlgrrl.com/blog
>
> _______________________________________________
> WG-UMA mailing list
> WG-UMA at kantarainitiative.org
> http://kantarainitiative.org/mailman/listinfo/wg-uma
>
>



-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en


More information about the WG-UMA mailing list