[Idel-wg] Mike Jones: Working Group Draft for OAuth 2.0 Act-As and On-Behalf-Of

[Mischa Salle]

On Thu, Sep 18, 2014 at 03:43:45PM +0100, Jensen, Jens (STFC,RAL,SC) wrote:
> Hi Mischa,
> 
> That sounds to me like a great use case. If you look at the life of a
> GSI proxy in the wild, you can see how many times it was delegated (like
> tree rings or something), and that alone suggests a need for multistep
> delegation.

Hi Jens,

just some background information: the use-case came up in the context of
the CLARIN project: user contacts portal, portal contacts SP1, and SP1
must be able to contact SP2 on behalf of the original user.
Apart from the last step, you can do this with standard OAuth2. However,
by default AFAIK, the token is not really restricted, so nothing
prevents SP1 from just using the token it got presented by the portal to
contact SP2. You would want to constrain the scope to a specific
service, such that any other service using that token will not be
allowed access. Instead, the token could allow the first service to
obtain a new token, which it could use to do the second step. Kerberos
has something like that I belief, although I couldn't find the right
reference.
This is something you actually also would like to do with proxy
certificates and for some reason has never been developed (see also
RFC3820 3.8.2, 5.3.2, 5.4). Even though making such constrained
delegation information private is hard (at least for proxies), it still
would be a big improvement in security. Proxy theft would become a lot
less interesting.

    Cheers,
    Mischa

> On 16/09/2014 14:21, Mischa Salle wrote:
> > Hi Paul, others,
> >
> > On Mon, Aug 25, 2014 at 03:49:56PM +0200, Paul Millar wrote:
> >> Hi Alan,
> >>
> >> On 25/08/14 07:13, Sill, Alan wrote:
> >>> Thought you would be interested in the following link, from the blog
> >>> of Mike Jones of Microsoft.
> >>>
> >>> Topic: There's now an OAuth working group draft of the OAuth 2.0
> >>> Token Exchange specification, which provides Act-As and On-Behalf-Of
> >>> functionality for OAuth 2.0. This functionality is deliberately
> >>> modelled on the same functionality present in WS-Trust.
> >> Interesting, although (to me) a little odd: OAuth is already about
> >> delegation, so providing a delegation framework within a delegation
> >> framework seems redundant.
> >>
> >> Another odd point is that the RP needs to know (a priori) the
> >> identity it wishes which, in general, it doesn't (c.f. OpenID
> >> Connect).
> >>
> > Maybe I'm wrong, but I would think that an interesting use-case is
> > multi-step delegation. For single-step delegation standard OAuth2.0 is
> > fine. But how should a resource server then do a further delegation
> > step, so RP-1 want to request access to RP-2 on behalf of user. It could
> > try to (mis)use the original token, but it's much better to require a
> > new token. That means it must request a token on behalf of the original
> > user. In that case, it also would know which identity to use, right? Or
> > do I misunderstand your second remark?
> >
> >     Cheers,
> >     Mischa
> >
> >> So, the use-case seems to be RP needs a credential (X.509, Kerberos,
> >> ...) to communicate with some server that doesn't support OAuth but
> >> trusts the server issuing the credential --- perhaps for legacy
> >> services or ones that don't provide a web front-end?
> >>
> >> Anyhow, thanks for the pointer.
> >>
> >> Cheers,
> >>
> >> Paul.
> >> _______________________________________________
> >> Idel-wg mailing list
> >> Idel-wg at ogf.org
> >> https://www.ogf.org/mailman/listinfo/idel-wg
> >
> >
> > _______________________________________________
> > Idel-wg mailing list
> > Idel-wg at ogf.org
> > https://www.ogf.org/mailman/listinfo/idel-wg
> 
> 
> -- 
> Scanned by iCritical.

> _______________________________________________
> Idel-wg mailing list
> Idel-wg at ogf.org
> https://www.ogf.org/mailman/listinfo/idel-wg


-- 
Nikhef                      Room  H155
Science Park 105            Tel.  +31-20-592 5102
1098 XG Amsterdam           Fax   +31-20-592 5155
The Netherlands             Email msalle at nikhef.nl
  __ .. ... _._. .... ._  ... ._ ._.. ._.. .._..
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4332 bytes
Desc: not available
URL: <http://www.ogf.org/pipermail/idel-wg/attachments/20140923/0247a1c3/attachment.bin>