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 <[email protected]> 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@IBMUS > To: > Jim des Rivieres <[email protected]> > Cc: > Ed Gentry/Portland/IBM@IBMUS, [email protected] > 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 <[email protected]> wrote on 01/06/2011 > 04:14:11 PM: > >> From: Jim des Rivieres <[email protected]> >> To: Steve K Speicher/Raleigh/IBM@IBMUS >> Cc: [email protected], Ed Gentry/Portland/IBM@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 <[email protected]> >> To: >> [email protected] >> Date: >> 01/06/2011 02:44 PM >> Subject: >> [oslc-core] OAuth and delegated UIs >> Sent by: >> [email protected] >> >> >> >> 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 >> [email protected] >> http://open-services.net/mailman/listinfo/oslc-core_open-services.net >> >> >> > > > > > > _______________________________________________ > Oslc-Core mailing list > [email protected] > http://open-services.net/mailman/listinfo/oslc-core_open-services.net >
