RE: Using multiple protocols and identifiers for authentication and resource access from Peter Williams on 2012-12-27 (public-rww@w3.org from December 2012)

From: Peter Williams <home_pw@msn.com>
Date: Thu, 27 Dec 2012 16:54:49 +0000
To: "public-rww@w3.org" <public-rww@w3.org>, Kingsley Idehen <kidehen@openlinksw.com>
Message-ID: <SNT403-EAS337544C50E64C167E6C964292380@phx.gbl>
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.

 


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, 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> 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

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








-- 

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
Received on Thursday, 27 December 2012 16:55:21 UTC