Thomas, No. I never finished tidying it up for submission. Also, I found a small issue where 'sometimes' the certificate isn't used, and the user gets dumped back to the login screen when both client-auth and password-based login is enabled.
Thanks for the rebase, I might work on this this evening then. Ali On May 2, 2012 10:36 AM, "Thomas Leonard" <[email protected]> wrote: > Hi Ali, > > Did this get submitted? I merged the patches into one and rebased them to > trunk if that helps: > > https://github.com/tal-**itinnov/wave/commit/** > 4e2c18ef95825b3fd92034d6544054**f26c358b79<https://github.com/tal-itinnov/wave/commit/4e2c18ef95825b3fd92034d6544054f26c358b79> > > > On 2012-02-13 10:26, Thomas Leonard wrote: > >> It seems to work fine; please go ahead and submit... >> >> >> On 2012-02-11 22:07, Ali Lown wrote: >> >>> 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: >>>> mustRegistrationUsernameMatchC**ert? >>>> >>>> On Feb 9, 2012 10:16 AM, "Thomas Leonard"<tal@it-innovation.** >>>> soton.ac.uk <[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/> >>>>> >>>> >> > -- > 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/> >
