[oslc-core] OAuth and delegated UIs

[Jim des Rivieres]

You could mention that delegated UIs (and UI Previews) should be treated 
like regular web pages vis a vis authentication; i.e., initial access to a 
protected web pages on the web site typically triggers standard Basic 
authentication challenge, or some kind of form-based authentication 
challenge.

---jim



From:
Dave <snoopdave at gmail.com>
To:
Jim des Rivieres/Ottawa/IBM at IBMCA
Cc:
Steve K Speicher <sspeiche at us.ibm.com>, oslc-core at open-services.net, Ed 
Gentry <egentry at us.ibm.com>
Date:
01/18/2011 08:09 AM
Subject:
Re: [oslc-core] OAuth and delegated UIs



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
>