Re: Using multiple protocols and identifiers for authentication and resource access

On 12/27/12 11:54 AM, Peter Williams wrote:
> After the holiday period (which I typically use to for programming 
> fun, free of the need to always make engineering-quality code), 
> consider this statement in the docs. It seems to be the root cause of 
> the interworking failure:
> “Once the user authenticated and approved or declined the request they 
> are redirected to the given callback URL. ODS does not add any query 
> parameters to the redirection URL. It might thus be prudent for the 
> client to set some type of session ID to be able to map the 
> redirection to the correct request token.”
> ITs not true factually; and it seems to be non-conforming as stated. 
> Even if its conforming (and who knows in open source land with free 
> wheeling and funky specs full of gray areas what is truly conforming), 
> it assumes a proprietary tying of the client code and the ODS provider.
> First realize that MODERN multi-tenant consumer websites and their 
> OAUTH frameworks may have multiple outstanding authorization requests. 
> To de-multiplex the inbound response from 1 interaction, they send 
> consumer-specific parameters on the authorize call’s request. Known as 
> state parameters (in OAUTH2), in OAUTH1 these are 
> just “non-oauth-named” parameters. They are supposed to round-trip, 
> letting consumer/provider layer entities at protocols higher than that 
> of the OAUTH layer in the stack signal each other.
> Yes this means that a provider could be using unverified parameters 
> supplied on a callback URI on a protocol run, which is typically a 
> no-no - given the web is a malicious place, full of malicious users 
> (and cyberwar govt contractors doing the same thing). Only the stem of 
> the callback URI would be verified in such a world, being pre-rded in 
> the trusted (third party vendor) registry of the provider. But, that 
> is why we have OAUTH2 .. no? to address all these issues, suitably.
> But even ignoring the issue of such callback parameter reflection, a 
> more substantive issue is the need to identity to the _stateless_ 
> class of consumer which oauth_consumer the response is tied - mostly 
> in order that it can lookup the associated secrets need to verify the 
> simple HTTP-level rolling mac-based session used in the OAUTH design.
> ODS doesn't supply that value, assuming the OAUTH consumer code is 
> stateful, and will take a proprietary cue parameter to lookup a 
> session. It assumes the vendor of the address_book app (say) knows its 
> proprietary sid identifier, and from said sid value ( the id of an 
> application and its particular endpoint on the server, I believe) it 
> should do a ODS-custom-lookup of consumer_key and consumer_secret in 
> its MIB of security parameters.
> I could go make custom subclasses of Microsoft code to accommodate 
> this, but its a bit of a pain to have to do so.
> One MIGHT do this:
> have two deployment models for ODS: (1) the baseline being maximally 
> interoperable with commodity consumer code plugin frameworks, 
> delivering lower assurance at the level of Facebook and Twitter at co, 
> and (2) the upgrade which assumes the API consumer is 
> higher-assurance, and is tuned up to deal with ODS specific profile to 
> the OAUTH protocol.

Okay, we'll have this sorted and then fix our docs accordingly.

Kingsley
> Sent from Windows Mail
> *From:* Kingsley Idehen
> *Sent:* ‎December‎ ‎27‎, ‎2012 ‎7‎:‎31‎ ‎AM
> *To:* public-rww@w3.org, Peter Williams
> *Subject:* Re: Using multiple protocols and identifiers for 
> authentication and resource access
> On 12/27/12 12:23 AM, Peter Williams wrote:
>
>     http://yorkporc.wordpress.com/2012/12/26/asp-net-visual-studio-2012-to-openlink-oauth/ documents
>     as far as I could get, using a Microsoft “production” library (a
>     wrapper around the dotnetopenauth library - used in conformance
>     testing). The lib allows one to fiddle with only certain aspects
>     of the protocol (the endpoint behaviours, mostly), demanding
>     conformance in other ways - from the way its objects and their
>     interfaces are constructed.
>     The provider seems not to provide a oauth_token parameter by
>     return, upon completing authorization. I suspect it should reflect
>     what its given. Attempts to add it to the callback URI don't work,
>     since its removed by the authorization handler.
>
>
> Here is a revised edition of the ODS OAuth provider documentation: 
> http://web.ods.openlinksw.com/odsdox/ods_oauth_server.html
>
> I'll make time to digest your post too.
>
> Happy Holidays!
>
> Kingsley
>
>     Sent from Windows Mail
>     *From:* Kingsley Idehen
>     *Sent:* ‎December‎ ‎17‎, ‎2012 ‎6‎:‎47‎ ‎AM
>     *To:* public-rww@w3.org <mailto:public-rww@w3.org>, Peter Williams
>     *Subject:* Re: Using multiple protocols and identifiers for
>     authentication and resource access
>     On 12/14/12 5:35 PM, peter williams wrote:
>
>         Can you update your openid or oAuth provider proxies, and
>         publish the endpoints etc.
>
>         I've also built a multi protocol name linking site,
>         multitenant, arouNd hosted in the azure cloud, and talks
>         upstream to most oauth and openid ( and more enterprise )
>         protocols. By this means it indirectly supports browserid and
>         I'm hoping webid, if we can get your gateway working again.
>
>         I also added an oauth guarded Api that might even cooperate
>         with your connection point manager.
>
>         Anyways Lots to play with as several layers of nameid linking
>         occurs.
>
>         For legal/ patent reasons, I'm limited to the semantics and
>         methods of saml sp affiliations ( though we are relaxed about
>         what blog formats are used, sAml blobs or otherwise)
>
>
>     Peter,
>
>     For now, look at our current OAuth binding guide [1]. That said,
>     we are going to produce another that looks more like what you see
>     provided by other OAuth providers re. HTML flow etc..
>
>     Links:
>
>     1.
>     http://virtuoso.openlinksw.com/dataspace/dav/wiki/Main/VirtuosoOAuthServer
>     -- current docs (shows endpoint patterns etc..)
>
>     Kingsley
>
>
>         Kingsley Idehen <kidehen@openlinksw.com>
>         <mailto:kidehen@openlinksw.com> wrote:
>
>         All,
>
>         Here is a simple (silent) screencast that demonstrates how a
>         system can
>         combine the features of OpenID, OAuth, Persona (but not
>         covered in this
>         demo), and WebID en rotue to providing read-write access to
>         protected
>         resources published to an HTTP network such as the World Wide Web.
>
>         The screencast covers:
>
>         1. Associating 3rd party accounts with an ODS account -- note
>         accounts
>         can also be automatically created via WebID, OpenID, Persona,
>         OAuth etc..
>         2. Resource Access control scoped to specific identifiers for
>         Agents or
>         Accounts.
>
>         What happens:
>
>         1. I login to ODS using WebID -- since my ODS account is
>         associated with
>         one of my WebIDs
>         2. I connect my Twitter, LinkedIn, and Facebook accounts via
>         the ODS
>         Profile UI for 3rd party account binding
>         3. I use the ODS-Briefcase UI to provide access to setup
>         resource ACLs
>         4. Access the protected resource.
>
>         Screencast Link: http://bit.ly/XUkXx1 .
>
>         -- 
>
>         Regards,
>
>         Kingsley Idehen
>         Founder & CEO
>         OpenLink Software
>         Company Web: http://www.openlinksw.com
>         Personal Weblog: http://www.openlinksw.com/blog/~kidehen
>         <http://www.openlinksw.com/blog/%7Ekidehen>
>         Twitter/Identi.ca handle: @kidehen
>         Google+ Profile:
>         https://plus.google.com/112399767740508618350/about
>         LinkedIn Profile: http://www.linkedin.com/in/kidehen
>
>
>
>
>
>
>
>     -- 
>
>     Regards,
>
>     Kingsley Idehen 
>     Founder & CEO
>     OpenLink Software
>     Company Web:http://www.openlinksw.com
>     Personal Weblog:http://www.openlinksw.com/blog/~kidehen  <http://www.openlinksw.com/blog/%7Ekidehen>
>     Twitter/Identi.ca handle: @kidehen
>     Google+ Profile:https://plus.google.com/112399767740508618350/about
>     LinkedIn Profile:http://www.linkedin.com/in/kidehen
>
>
>
>
>
>
> -- 
>
> Regards,
>
> Kingsley Idehen 
> Founder & CEO
> OpenLink Software
> Company Web:http://www.openlinksw.com
> Personal Weblog:http://www.openlinksw.com/blog/~kidehen  <http://www.openlinksw.com/blog/%7Ekidehen>
> Twitter/Identi.ca handle: @kidehen
> Google+ Profile:https://plus.google.com/112399767740508618350/about
> LinkedIn Profile:http://www.linkedin.com/in/kidehen
>
>
>
>


-- 

Regards,

Kingsley Idehen 
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen