Thomas, I have tidied it a bit more, and added a new option (disabled_loginpage).
I thought you might want to take a look at it first, and depending on your thoughs would it be ok for me to submit my (heavily adjusted) version for review here? Ali On 9 February 2012 17:01, Ali Lown <[email protected]> wrote: > The IsRegistrationDisabled patch was implemented to disable the registration > page for private internet-facing servers. > > As such, to extend the same function to the client certificate, would be to > disable the automatic registration of users who authenticate with a > certificate for a user not already on the system. > > For your idea, I feel it would be better to do that sort of check during the > actual registration step, and use a new setting: > mustRegistrationUsernameMatchCert? > > On Feb 9, 2012 10:16 AM, "Thomas Leonard" <[email protected]> > wrote: >> >> Thanks. BTW, I was hoping to use isRegistrationDisabled the other way: to >> prevent people from registering any account *except* the one in their >> certificate. >> >> >> On 2012-02-08 20:43, Ali Lown wrote: >>> >>> Thomas, >>> >>> Yes that does fix it under Socket.IO (tested in Chrome, but means it >>> will work with all). >>> >>> I started work on generalising your patch a bit, you can see the >>> results in my ssl_client branch >>> (https://github.com/alown/wave/tree/ssl_client). >>> You will probably want to cherry-pick from that branch though, because >>> I haven't kept it completely clean... >>> >>> Ali >>> >>> On 3 February 2012 09:50, Thomas Leonard<[email protected]> >>> wrote: >>>> >>>> Well, we only need client auth for the AuthenticationServlet, so it >>>> should >>>> be easy to fix this by changing "Need" to "Want". Here's a patch to do >>>> that: >>>> >>>> >>>> https://github.com/tal-itinnov/wave/commit/07a604e6d5ab050f6991498afc0b267939e15d6d >>>> >>>> Does that fix it for you under Chrome? >>>> >>>> >>>> >>>> On 2012-02-02 19:38, Ali Lown wrote: >>>>> >>>>> >>>>> 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/ >>>> >>>> >>>> >>>> -- >>>> 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/
