[foaf-protocols] foaf.me with https, vs http
pwilliams at rapattoni.com
Thu Jan 21 00:46:50 CET 2010
Thanks. That helps.
I've implemented scenario B to demo level (and A is a given). I have not implemented the combination of A and B (which feels like a cute demo, for showcasing). Since my demo is supposed to be rigorously RESTful, I have no notion of web session (only persistent "transport sessions" that are provided by SSL in a manner transparent to the web layer). There is no notion of being "logged in", and thus one cannot the RP cannot signal the IDP to destroy its persistent transport session (SSL of course) with the windows desktop.
The only things missing in supporting B is the ability to (a) actually verify the RSA signatures (which I'm debugging), support the exception cases of the state machines disclosed on the spec page, and implement some window for accepting the timestamp . (There is no evidence of an anti-replay requirement, requiring caching, making the scheme essentially equivalent to the 1-pass strong auth mechanism documented in X.509 1988). I'm not sure how much of an official proposal foafssl.org's message decls and states are, though. It's mostly a demo of a "nominal" token asserting IDP using a redirect binding, from what I can tell. Its rather similar to the OASIS "simple signing" binding of SAML, of course (which does away with the SOAP and XML wrappers/marshalling). WE might be better to simply use what he simple saml SAML binding provides, particularly if it removes the SOAP and XML handling obligation so its easy for string processing php/perl scripts to process.
So far I've implemented B using a end-end script, rather than make its tokenhandler an formal inceptor in the stack that has its claims goes into the authorization policy handlers, along with other claims from the other tokens on the call (if any). Its relatively trivial to move the script class into the listener behaviour, so it becomes an interceptor... A class is a class, in .NET world.
One interesting experiment is to have the client induce server-side destruction of transport session ...by doing a TCP close on WITHOUT first doing a SSL close. For conforming servers, this forces the server to cease further use of that transport session (ssl3 sessionid) on ALL outstanding connections, including those connections derived from the pre-master secret tied to the SSL3 sessionid.
From: Akbar Hossain [mailto:akkiehossain at googlemail.com]
Sent: Wednesday, January 20, 2010 3:27 PM
To: Peter Williams
Cc: foaf-protocols at lists.foaf-project.org
Subject: Re: [foaf-protocols] foaf.me with https, vs http
The login on behaviour foaf.me<http://foaf.me> changed back in December.
The scenario/behaviours you describe is the result of supporting both the delegated server (B) and the direct ssl authentication (A) within a single function.
[The setup of the server and the site is maybe not what you would not expect on a site using a delegated login service]
The foaf.me<http://foaf.me> server has an ssl connection and asks for a client certificate on all pages served. I dont think you would expect this on site using testssl.org<http://testssl.org>.
So if you visit https://foaf.me it will ask for a client certificate. If you supply an authenticated certificate it will store the result in a session cookie. If you press the log out button the session get cleared. If you now press the login button it does scenario B.
If you start at http://foaf.me (must be a new session) the login button is scenario B.
The relevant code is here.
The function to start with is getAuth().
On Wed, Jan 20, 2010 at 2:46 PM, Peter Williams <pwilliams at rapattoni.com<mailto:pwilliams at rapattoni.com>> wrote:
Has the behavior of foaf.me<http://foaf.me> changed, recently?
(I'm back to programming my foaf-demonstrate website to rely on foafssl.org<http://foafssl.org>'s signed tokens, simply by copying what foaf.me<http://foaf.me> does in practice).
Here is what the evidence from observing foaf.me<http://foaf.me>'s interaction with foafssl.org<http://foafssl.org> suggests:
A If I connect a browser to foaf.me<http://foaf.me> using https, the site seems to rely directly upon the client cert (and associated foaf document). It directly mints a web session.
B If I connect a browser to foaf.me<http://foaf.me> using http, it redirects to foafssl.org<http://foafssl.org> (which seems to rely upon the client cert and associated foaf document). The redirect is sent over https. Foafssl.org seems to returns a redirect status response (over https, though I didn't look for a possible ssl half close) bearing an hmac-signed token targeting foaf.me<http://foaf.me>. The redirects seems to induce the browse to connect over HTTP to Foaf.me , which seems to rely upon that token, presumably after verification, and then mints a web session.
The web sessions minted by foaf.me<http://foaf.me> in cases A and B seem identical, despite there being very different bases of reliance and quite different levels of transport security used during the processes of reliance. Note in B how the asserted token is transferred over http vs https at one point and in B the token's security is a simple hmac (vs the ssl-handshake's read key for integrity used during reliance in case A).
foaf-protocols mailing list
foaf-protocols at lists.foaf-project.org<mailto:foaf-protocols at lists.foaf-project.org>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the foaf-protocols