Supporting this would be a very good thing, and well worth the investment. One slight addition to the analysis: a lot of services are exposed via firewalls and proxies - and these set-ups are often imposed across large swathes of government by (practically) immutable and poorly designed service contracts - in some cases https is not be available at all (crazy but true!). This may be enforced at a proxy or the router. Rarely are containers directly exposed.
There needs to be a flag - HTTP only, HTTPs only or mixed-mode (default) Rob A On Wed, Apr 15, 2009 at 6:15 AM, Arne Kepp <a...@opengeo.org> wrote: > I was wondering whether we could generate a hostname on startup, like > SSH. However, I dont think you want a certificate without a fully > qualified hostname, and asking the operating systems is probably not > accurate in most cases. So that leaves prompting the user during startup. > > I'd also like to point out again that a lot of users will do the HTTPS > part using an Apache proxy, or a dedicated daemon like Pound. Partially > because you should trust as few programs as possible with the key. So it > should be possible to force redirection to HTTPS even when the container > does not support SSL. > > -Arne > > > Andrea Aime wrote: >> Hey all, >> so I've been looking at how to have GeoServer automatically switch to >> HTTPS when user credentials are on the fence and/or when we do have >> possibly sensible information running over the wire. >> The two use cases I have in mind are: >> - admin console, whenever an administrator logs in and edits >> store/layer information, that should happen over SSL >> - any data transfer that requires the user to authenticate >> (meaning that the user credentials are stored in http basic >> authentication headers, and that the information being >> transferred might be sensible as well). >> >> So basically what seems to be needed is: >> - have the authentication form post to an HTTPS url >> - have all secure pages force a redirect to HTTPS if they >> are hit thru a non secure URL >> - have all OGC service requests using http basic authentication >> switch to HTTPS by default >> - have the responses asking the user to authenticate using >> HTTP basic include a redirect to HTTPS first (that is, first >> redirect to HTTPS, then tell the client that the user does not >> have enough credentials and ask for them using a HTTP 401 >> response. At that point the browser will pop up a user >> credential request, but the whole communication will be >> switched to https already). >> >> Am I missing anything? >> >> There are two more things to discuss. The first is that the >> container might not have SSL enabled. Acegi has a class >> that performs redirection only if SSL is there, but it >> requires one to configure the SSL ports in the application >> context... bah! Not very useful as people can be using >> custom ones... I'll have to find a way to make this runtime >> configurable (maybe turn it into a GeoServerInfo parameter?). >> >> The second issue is, what do we do for development and >> demo (release) purposes? Setting up a SSL layer requires >> one to create a certificate, a keystore and whatnot. >> This guide provides some hint: >> http://docs.codehaus.org/display/JETTY/How+to+configure+SSL >> >> I would say that for development purposes we should setup >> a keystore with a well known setup and give Start.java >> an option to use it, so that we can do tests with both >> SSL enabled or not. The certificate will be valid for localhost >> only, maybe the browser will get grumpy the first time and >> ask us if we want to really trust that self signed certificate, >> but from there on it should be smooth ride. >> >> What about release? The Jetty configuration we ship with >> actually has a keystore ready, one just has to include >> the jetty-ssl.xml config file in the command line. Try >> with: >> java -DGEOSERVER_DATA_DIR=... -jar start.jar etc/jetty.xml etc/jetty-ssl.xml >> >> and then try to connect to http://localhost:8443/geoserver >> and you'll see. >> We could just enable this by default but... as Arne pointed >> out, it would give people a false sense of security, >> since everybody knows the private key of that certificate >> so it's possible to hijack those ssl communications without >> much effort. >> The only way to get real security is to have people >> buy/create and install their own certificates... >> >> Opinions? Help very much appreciated, I'm no security expert ;-) >> Cheers >> Andrea >> >> ------------------------------------------------------------------------------ >> This SF.net email is sponsored by: >> High Quality Requirements in a Collaborative Environment. >> Download a free trial of Rational Requirements Composer Now! >> http://p.sf.net/sfu/www-ibm-com >> _______________________________________________ >> Geoserver-devel mailing list >> Geoserver-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/geoserver-devel >> > > > -- > Arne Kepp > OpenGeo - http://opengeo.org > Expert service straight from the developers > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > High Quality Requirements in a Collaborative Environment. > Download a free trial of Rational Requirements Composer Now! > http://p.sf.net/sfu/www-ibm-com > _______________________________________________ > Geoserver-devel mailing list > Geoserver-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geoserver-devel > ------------------------------------------------------------------------------ This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com _______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
