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

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.

-- 

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