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<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<tal@it-innovation.**soton.ac.uk<[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/** >>> 07a604e6d5ab050f6991498afc0b26**7939e15d6d<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 67d73f61b77eb89315219f715d97f3**8f386fe09e and >>>> 8626aa5d0b10eb8627ae1a38ff3c94**4390c73b22 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<tal@it-innovation.** >>>>> soton.ac.uk <[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/** >>>>>> ae8d59c5725a74bcf0fc2ae08ae569**4abca02a7f<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<tal@it-innovation.** >>>>>>> soton.ac.uk <[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:tal@it-innovation.**soton.ac.uk<[email protected]> >>>>>>>> http://www.it-innovation.**soton.ac.uk/<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:tal@it-innovation.**soton.ac.uk<[email protected]> >>>>>> http://www.it-innovation.**soton.ac.uk/<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:tal@it-innovation.**soton.ac.uk <[email protected]> >>> http://www.it-innovation.**soton.ac.uk/<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:tal@it-innovation.**soton.ac.uk <[email protected]> > http://www.it-innovation.**soton.ac.uk/<http://www.it-innovation.soton.ac.uk/> >
