Also, I gave your patch a shot here, and it mostly works:
- In Chrome (17-Dev Build 0/Linux 64) websockets then fail to connect
(despite the websocket URL being a wss://) -> perhaps Chrome doesn't
support authenticating websockets?

After hard-disabling websockets (or using Firefox etc.) it works properly.
(Cherry-pick 67d73f61b77eb89315219f715d97f38f386fe09e and
8626aa5d0b10eb8627ae1a38ff3c944390c73b22 from my github repo)

And you may want to add the removal of the "Sign out" button to your
patch -> since it doesn't exactly server much purpose when using
client auth.

On 2 February 2012 15:18, Ali Lown <[email protected]> wrote:
> Looks interesting.
>
> It would be nice to generalise and get this patch submitted upstream
> (certainly beats typing in a username + password each time).
>
> Since the AuthenticationServlet already has CoreSettings injected in
> the constructor, it would be quite easy for you to move the hard-coded
> OID and the  addresses out into the config file which would be nice.
>
> You will probably also want to add a useClientAuth flag into the
> settings, and update ServerRpcProvider to enable based on this. It
> would then let you decide in the AuthenticationServlet whether to
> serve the login page or not (rather than commenting it out).
>
> PS. Disabling tests in build.xml is all very well (as long as you
> remember not to commit it to a review patch (I did this once)), but I
> find it easier simply to map 'ant compile-gwt-dev && ant dist-server'
> to an alias in my shell instead.
>
> On 2 February 2012 14:41, Thomas Leonard <[email protected]> 
> wrote:
>> I've now got X.509 client authentication working working too. Now, when one
>> of our users goes to our server it:
>>
>> - checks that their browser has a certificate issued by us (from our
>> Microsoft Active Directory Certificate Services)
>>
>> - generates a wave ID for them automatically, based on the email address in
>> their certificate
>>
>> - creates an account for them if they don't already have one
>>
>> - logs them in automatically
>>
>> The patch is quite hacky (just enough to get it working), but in case anyone
>> wants to see how it works:
>>
>> https://github.com/tal-itinnov/wave/commit/ae8d59c5725a74bcf0fc2ae08ae5694abca02a7f
>>
>> This means that everyone gets access to their old imported waves (i.e. they
>> can't register an account with the wrong ID, or with someone else's ID).
>>
>>
>> On 2012-02-01 22:43, Ali Lown wrote:
>>>
>>> Updated the patch for review to the one I am using.
>>>
>>> I haven't yet been able to solve the ICS/OpenSSL issue much to my
>>> irritation.
>>> Ideas on this are welcome since I am not a security expert (or have
>>> ever used JSSE before...)
>>>
>>> On 31 January 2012 10:56, Thomas Leonard<[email protected]>
>>>  wrote:
>>>>
>>>> Would it be worth applying the patch anyway, with a note in the config
>>>> that
>>>> this doesn't work with all clients (and is disabled by default)? That
>>>> would
>>>> allow wider testing.
>>>>
>>>>
>>>>
>>>> On 2012-01-29 23:01, Ali Lown wrote:
>>>>>
>>>>>
>>>>> OpenSSL's s_client is also unable to connect when asked to use the TLS
>>>>> cipher suites (but can do SSL3 ones fine).
>>>>> This is despite the web browsers (Chrome, Firefox etc.) all connecting
>>>>> via TLS 1.0
>>>>>
>>>>> It is looking like a bug/limitation in Jetty's SSL engine to me now,
>>>>> rather than an issue with ICS's browser.
>>>>>
>>>>> Still looking into this issue before sending any further
>>>>> patches/updates.
>>>>>
>>>>> On 29 January 2012 15:08, Ali Lown<[email protected]>    wrote:
>>>>>>
>>>>>>
>>>>>> Found another issue with the implementation:
>>>>>> For some reason Android ICS's Browser has a 'time out' when loading
>>>>>> the page, yet Gingerbread, Froyo etc. are fine.
>>>>>>
>>>>>> They must have changed something to do with the SSL handshake the
>>>>>> device performs when running ICS.
>>>>>>
>>>>>> Other devices, eg. iPhone have no issue with the handshake...
>>>>>>
>>>>>> Looking into this now.
>>>>>>
>>>>>> On 26 January 2012 20:33, Ali Lown<[email protected]>    wrote:
>>>>>>>
>>>>>>>
>>>>>>> Oops, just discovered that my patch broke the bots (due to them all
>>>>>>> having hard-coded 'http' URLs in the code). The fact it took me a week
>>>>>>> despite running  it on my server, suggests this code isn't ready yet.
>>>>>>>
>>>>>>> I will submit a new patch to fix this in a few days time, once I have
>>>>>>> had a chance to check for any other bugs it may have introduced.
>>>>>>>
>>>>>>> On 22 January 2012 22:59, Ali Lown<[email protected]>    wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> Sent a review request for most of the code.
>>>>>>>> To get socket.io to work correctly though I had to edit socket.io.js
>>>>>>>> in the third_party/runtime/socketio/socketio-core-0.1-SNAPSHOT.jar
>>>>>>>> (attached here for your reference).
>>>>>>>>
>>>>>>>> As for the issue of privileged ports, I have chosen to run WIAB on a
>>>>>>>> non-privileged, and with the help of an iptables REDIRECT, can make
>>>>>>>> it
>>>>>>>> appear to be running on 443.
>>>>>>>>
>>>>>>>> Works for me. :)
>>>>>>>>
>>>>>>>> On 18 January 2012 15:12, Vicente J. Ruiz Jurado<[email protected]>
>>>>>>>>  wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> El 18/01/12 00:20, Ali Lown escribió:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I had a go at setting it up and yes this method of adjusting jetty
>>>>>>>>>> seems to work fine.
>>>>>>>>>>
>>>>>>>>>> Over the next couple of days I will have a go at writing a patch so
>>>>>>>>>> that we can choose between ssl (and normal) listeners, keystore
>>>>>>>>>> location and password all from the configuration file.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Just to say: Great job guys!
>>>>>>>>>
>>>>
>>>> --
>>>> Dr Thomas Leonard
>>>> IT Innovation Centre
>>>> Gamma House, Enterprise Road,
>>>> Southampton SO16 7NS, UK
>>>>
>>>>
>>>> tel: +44 23 8059 8866
>>>>
>>>> mailto:[email protected]
>>>> http://www.it-innovation.soton.ac.uk/
>>
>>
>> --
>> Dr Thomas Leonard
>> IT Innovation Centre
>> Gamma House, Enterprise Road,
>> Southampton SO16 7NS, UK
>>
>>
>> tel: +44 23 8059 8866
>>
>> mailto:[email protected]
>> http://www.it-innovation.soton.ac.uk/

Reply via email to