[oslc-core] OAuth and delegated UIs

[Dave]

Are there any clarifications or informative text that we can add to
the OSLC Core spec to help explain how best to approach authentication
of delegated UIs?

- Dave


On Tue, Jan 11, 2011 at 12:59 PM, Jim des Rivieres
<Jim_des_Rivieres at ca.ibm.com> wrote:
> Using OAuth to access a protected delegated UI URL doesn't work well in
> practice. Let me explain why.
>
> Even if you arrange to pass OAuth credentials when the browser
> dereferences the delegated UI URL to some HTML page, any follow-on GETs
> the browser makes to retrieve subsidiary resources - images, css style
> sheets, scripts, etc. - will not bear any OAuth credentials. So if any of
> these are protected resources, the browser will be hit with some kind of
> authentication challenge unless the user has already logged in to the
> site. Web browsers generally don't take kindly to receiving authentication
> challenges when retrieving subsidiary resources needed to show an HTML
> page - often they give up with "error loading page".
>
> The problem is that web browsers are not prepared to play the role of
> OAuth consumer.  Web browsers are only prepared to pass Basic auth
> credentials and roundtrip cookies.
>
> For this reason, dereferencing a delegated UI URL will usually require a
> normal log-in to the target server to establish a session, and it will be
> these session credentials that will unlock access to the delegated UI URL
> web page and subsidiary resources.
>
> ---Jim des Rivieres
>
>
>
> From:
> Steve K Speicher/Raleigh/IBM at IBMUS
> To:
> Jim des Rivieres <Jim_des_Rivieres at ca.ibm.com>
> Cc:
> Ed Gentry/Portland/IBM at IBMUS, oslc-core at open-services.net
> Date:
> 01/10/2011 02:02 PM
> Subject:
> Re: [oslc-core] OAuth and delegated UIs
>
>
>
> I guess I don't fully understand, as OAuth is about "enabling delegated
> access to protected resources" [1].
> If an application has an access token then it would seem that it should
> use it with its request.  Given the browser context and the delegated UI
> resource, the request for this resource is done by creating an iframe and
> setting the src attribute to the delegated UI URL.
>
> I'm not a strong advocate for this, I'm just arguing a position to make
> sure we are not putting constraints on some resource "types" and how
> certain class of clients access them.  Also there appears to be some spec
> [2] to support this in OAuth already.  An implementer came to me with this
>
> as an approach as well.
>
> [1] - http://tools.ietf.org/html/rfc5849
> [2] - http://tools.ietf.org/html/rfc5849#section-3.5.3
>
> Thanks,
> Steve Speicher | IBM Rational Software | (919) 254-0645
>
>
> Jim des Rivieres <Jim_des_Rivieres at ca.ibm.com> wrote on 01/06/2011
> 04:14:11 PM:
>
>> From: Jim des Rivieres <Jim_des_Rivieres at ca.ibm.com>
>> To: Steve K Speicher/Raleigh/IBM at IBMUS
>> Cc: oslc-core at open-services.net, Ed Gentry/Portland/IBM at IBMUS
>> Date: 01/06/2011 04:14 PM
>> Subject: Re: [oslc-core] OAuth and delegated UIs
>>
>> Since you mention the delegated UI sections, it bears noting that
> passing
>> OAuth parameters to request URLs (whether by header, body, or embedded
> in
>> the URL) does not make sense for web page URLs meant to be displayed in
> a
>> web browser; e.g., picker URLs. OAuth 1.0 is not about authenticating a
>> user in a browser talking to a server, but about authorizing servers
>> talking between themselves.
>>
>> Regards,
>> Jim des Rivieres
>>
>>
>>
>> From:
>> Steve K Speicher <sspeiche at us.ibm.com>
>> To:
>> oslc-core at open-services.net
>> Date:
>> 01/06/2011 02:44 PM
>> Subject:
>> [oslc-core] OAuth and delegated UIs
>> Sent by:
>> oslc-core-bounces at open-services.net
>>
>>
>>
>> It would be desirable if OSLC Core spec were to recommend (SHOULD) that
>> service providers be prepared to handle OAuth parameters embedded in the
>
>
>> request URI [1]
>> If a provider of the delegated UIs didn't support this, it could just
>> ignore it.   This would provide some improvements to usability where
>> setting up single solutions may not be available.
>>
>> I propose that we add this to the delegated UI sections (or maybe just
> the
>>
>> OAuth section)?
>>
>> [1] - http://tools.ietf.org/html/rfc5849#section-3.5.3
>>
>> Thanks,
>> Steve Speicher | IBM Rational Software | (919) 254-0645
>>
>>
>> _______________________________________________
>> Oslc-Core mailing list
>> Oslc-Core at open-services.net
>> http://open-services.net/mailman/listinfo/oslc-core_open-services.net
>>
>>
>>
>
>
>
>
>
> _______________________________________________
> Oslc-Core mailing list
> Oslc-Core at open-services.net
> http://open-services.net/mailman/listinfo/oslc-core_open-services.net
>