Re: Question about "TLS CCA Session" versus "Web Session"

On 12 May 2014 13:50, Anders Rundgren <anders.rundgren.net@gmail.com> wrote:

> On 2014-05-12 13:33, Kingsley Idehen wrote:
>
>> On 5/12/14 6:00 AM, Anders Rundgren wrote:
>>
>>> On 2014-05-12 10:57, henry.story@bblfish.net wrote:
>>>
>>>>
>>>> On 12 May 2014, at 09:32, Anders Rundgren <
>>>> anders.rundgren.net@gmail.com> wrote:
>>>>
>>>>  On 2014-05-07 11:48, henry.story@bblfish.net wrote:
>>>>>
>>>>>> On 7 May 2014, at 08:42, Anders Rundgren <
>>>>>> anders.rundgren.net@gmail.com> wrote:
>>>>>>
>>>>>>  I don't claim knowing everything so please bear with me when I ask a
>>>>>>> simple question :-)
>>>>>>>
>>>>>>> Using JBoss and Tomcat (java-based) servers an HTTPS Client
>>>>>>> Certificate Authenticated
>>>>>>> session created from a browser *never terminates* regardless of
>>>>>>> session time-out settings
>>>>>>> because the TLS session has no link into the Java Servlet web
>>>>>>> session framework.
>>>>>>>
>>>>>>> Due to this neither manual logout or automatic logout work in such
>>>>>>> setups.
>>>>>>>
>>>>>>> Q1: how do other web-servers enforce logout from the server-side?
>>>>>>> Q2: if other web-servers actually can do this,  does this require
>>>>>>> TCP terminate?
>>>>>>> Q3: if other web-servers actually can do this,  logout works
>>>>>>> formost/all browsers without specific measures?
>>>>>>>
>>>>>>>  As far as I can tell a server cannot force logout of the client,
>>>>>> since the browsers tend to resend the same certificate
>>>>>> to the server. You can only do this with Firefox which has a
>>>>>> Javascript logout call currently. In my view login/logout
>>>>>> has to be handled by the client in the chrome.
>>>>>>
>>>>>
>>>>> This is a unique problem for HTTPS Client Certificate Authentication;
>>>>> no other authentication
>>>>> method needs modifications of the chrome in order to perform logout or
>>>>> requires the client
>>>>> to support session timeout policies.
>>>>>
>>>>
>>>> That is wrong as a little reflection should show:
>>>>
>>>> - Basic Authentication uses the Chrome
>>>>
>>>
>>> True.  However, basic auth is even less popular than HTTPS Client Cert
>>> Auth.
>>> Form-based login rules on the web.
>>>
>>>
>>>  - All other current methods rely on cookie based authentication, and it
>>>> is problematic to exactly the extent that
>>>>    there until recently it was difficult for a user to control his
>>>> cookie based personas. This is exactly what Aza Raskin
>>>>    was trying to bring into the Chrome with his "Identity in the
>>>> Browser" blog post
>>>> http://www.azarask.in/blog/post/identity-in-the-browser-firefox/
>>>>
>>>
>>> Fine with me.  If the mechanism is universal it would be a useful option.
>>>
>>>
>>>  I can though imagine a chrome-based identity context but it should be
>>>>> optional and universal.
>>>>> It should probably also address logout to *all* enabled sites that you
>>>>> have encountered
>>>>> during your session on the web.
>>>>>
>>>>
>>>> yes, there are many such features that become possible once one starts
>>>> thinking about tying
>>>> identity to the Chrome, and putting the user fully in control of it.
>>>> Google Chrome's Profiles
>>>> are a good step in the direction, but they don't yet help show which
>>>> certificates are used,
>>>>
>>>
>>> OK
>>>
>>>
>>>  which  is important just because with WebID one could log into all
>>>> sites with the same certificate.
>>>>
>>>
>>> In theory a singe certificate using WebID could log in to all sites but
>>> due to differences in
>>> policies etc. this won't happen.  I don't see that as a problem if you
>>> have a working certificate
>>> selection filter.
>>>
>>>
>>> Question: where does this leave us?
>>>
>>> Anders
>>>
>>
>> Waiting for Chrome, Firefox, and Opera to catch up with IE (Windows) and
>>  Safari (on Mac OS X, iOS). Now if you want to look at matters through
>> "actual user" lenses, then the total users of IE and Safari completely
>> trump the users of Firefox and Chrome, who for all intents are purposes
>> fall into the "programmer / developer" user profile.
>>
>> To conclude, most end-users don't even have a problem. They can work with
>> <http://id.myopenlink.net/ods/webid_demo.html> and switch certificates
>> without restarting their browsers. As for the issues with Certificate
>> selection presentation, that's less of a problem when the Certificate
>> Generator UI aids the user accordingly re., CN attribute values.
>>
>> As is often the case, the programmer is making an incorrect assumption
>> about end-users based on the programmers own preferred combination of host
>> operating system, development tools, and test applications (e.g.,, browser
>> in this case). Windows, Mac OS X, and iOS end-users don't have a problem
>> because they use the default browsers provided by the OS.
>>
>> If I have <http://id.myopenlink.net/ods/webid_demo.html> tweaked (which
>> I will), such that it tests for Firefox/Mozilla, even users of that
>> particular browser will be able to authenticate without restarting the
>> browser -- since the HTML page served up from the server will include the
>> necessary JS code achieving this goal.
>>
>
> This discusson doesn't go forward.
>
> Google, Microsoft, PayPal and a lot of other big players recently
> put their money on U2F which is completely new solution. There must be
> reasons for not bulding on the already deployed platform, right?
>
> Not until the WebID folks understand the motives behing the U2F we
> can expect any progress in this space.
>

WebID + U2F works too, there are many flavours.

WebID + OpenID -- we have working demos of this

WebID + Facebook Connect -- all facebook users have a WebID located at
graph.facebook.com which server RDF/turtle

WebID + cookie

WebID + username / password

WebID + OAuth

WebID + TLS

etc. etc.

Just pick your favourite solution and use that.  If there isnt a bridge,
build your own.  WebID + TLS is just for those that want to manage their
keys on the client via X.509, until Web Crypto API comes out and offers
more choice ...



>
> Anders
>
>
>
>> --
>>
>> Regards,
>>
>> Kingsley Idehen
>> Founder & CEO
>> OpenLink Software
>> Company Web:http://www.openlinksw.com
>> Personal Weblog:http://www.openlinksw.com/blog/~kidehen
>> Twitter Profile:https://twitter.com/kidehen
>> Google+ Profile:https://plus.google.com/+KingsleyIdehen/about
>> LinkedIn Profile:http://www.linkedin.com/in/kidehen
>>
>>
>>
>>
>>
>
>