[Open.ogc] services.ogc.noaa.gov password protected under SSL (https)

Micah Wengren micah.wengren at noaa.gov
Tue Mar 10 14:02:10 UTC 2015


Chi,

The rule changes look good to me.  Looks like restricted URLs are being 
properly forwarded to HTTPS and others are available over HTTP.  Tim, 
any feedback from your side?

Thanks for adding them,
Micah

On 2/26/2015 11:58 AM, Chi Kang - NOAA Federal wrote:
> Gotcha.
>
> Let me know how the changes look.
>
>
> On Tue, Feb 24, 2015 at 1:48 PM, Micah Wengren - NOAA Federal 
> <micah.wengren at noaa.gov <mailto:micah.wengren at noaa.gov>> wrote:
>
>     Yes, would that rule also cover
>
>     geoserver/wms and
>     geoserver/wfs
>
>     there is also
>     geoserver/ows
>
>     that should be public.
>
>     Thanks!
>
>     Micah
>
>
>
>     On Tuesday, February 24, 2015, Chi Kang - NOAA Federal
>     <chi.y.kang at noaa.gov <mailto:chi.y.kang at noaa.gov>> wrote:
>     > Yeah, we can put a match statement in there.  So i just want to
>     understand.
>     > You want to switch to pubic access for ?
>     > /geoserver/*/wms
>     > /geoserver/*/wfs
>     >
>     >
>     > On Fri, Jan 23, 2015 at 11:38 AM, Micah Wengren
>     <micah.wengren at noaa.gov <mailto:micah.wengren at noaa.gov>> wrote:
>     >>
>     >> Hi Chi,
>     >>
>     >> Currently we have a couple of controls on the HTTPS service,
>     one that checks an IP whitelist, and the second that uses the HTTP
>     Basic auth, correct?
>     >>
>     >> I think to make the service more usable for use cases like
>     Tim's we should only apply those controls to URLs where the user
>     is prompted for their internal password (like the GeoServer admin
>     page, GeoExplorer, and REST API).  Those URLs should be:
>     >>
>     >> /geoserver/web
>     >> /geoserver/rest
>     >> /geoexplorer
>     >>
>     >> The rest shouldn't have any controls, so both the global WMS
>     and WFS services:
>     >>
>     >> /geoserver/wms
>     >> /geoserver/wfs
>     >> /geoserver/ows
>     >>
>     >> and the workspace-specific ones:
>     >>
>     >> /geoserver/nmfs_st/wms
>     >> /geoserver/nmfs_st/wfs
>     >> /geoserver/*/wms
>     >> /geoserver/*/wfs
>     >> etc....
>     >>
>     >> should be open to all.  Is that possible?
>     >>
>     >> Micah
>     >>
>     >>
>     >>
>     >> On 1/22/2015 12:37 PM, Chi Kang - NOAA Federal wrote:
>     >>
>     >> I am good with the idea of allowing authentication to be
>     restricted by
>     >> a satfiy all statement.
>     >>
>     >> But the URLs aren't just
>     >>
>     >> /geoserver/web
>     >> /geoserver/rest
>     >> /geoexplorer
>     >> /geoserver/wms
>     >> /geoserver/wfs
>     >> /geoserver/ows
>     >>
>     >> ?
>     >>
>     >> Isn't it more like
>     >> /geoserver/*/wms ?
>     >>
>     >> I just want to make sure we understand what URLs we are talking
>     about here.
>     >>
>     >>
>     >> On Wed, Jan 21, 2015 at 12:19 PM, Micah Wengren
>     <micah.wengren at noaa.gov <mailto:micah.wengren at noaa.gov>> wrote:
>     >>
>     >> Hi Chi/WOC,
>     >>
>     >> Do you guys think these type of rules can be implemented to
>     improve the
>     >> public HTTPS access to the services? I don't think it's a
>     priority or
>     >> urgent, but if you might be able to give an estimate for when
>     they could be
>     >> added, that would probably help Tim in his planning.
>     >>
>     >> Thanks,
>     >> Micah
>     >>
>     >>
>     >> On 1/7/2015 2:51 PM, Micah Wengren wrote:
>     >>
>     >> I think the ideal situation would be for only the URLs that
>     optionally allow
>     >> authentication to be restricted by the extra HTTP Basic
>     authentication (or
>     >> NOAA IP address). Those should be:
>     >>
>     >> /geoserver/web
>     >> /geoserver/rest
>     >> /geoexplorer
>     >>
>     >> Everything else can be considered a map or data set request to
>     the WMS or
>     >> WFS. Typically those are the URLs that Tim included but could
>     also be to
>     >> the base WMS and WFS services:
>     >>
>     >> /geoserver/wms
>     >> /geoserver/wfs
>     >> /geoserver/ows
>     >>
>     >> Those should all be allowed from any IP address. I think this
>     would help
>     >> out for use cases like what Tim's is.
>     >>
>     >> Micah
>     >>
>     >>
>     >> On 1/7/2015 1:16 PM, Tim Haverland - NOAA Federal wrote:
>     >>
>     >> I'm calling URLs such as:
>     >>
>     >> //services.ogc.noaa.gov/geoserver/nmfs_st/wfs
>     <http://services.ogc.noaa.gov/geoserver/nmfs_st/wfs>
>     >> //services.ogc.noaa.gov/geoserver/nmfs_st/wms
>     <http://services.ogc.noaa.gov/geoserver/nmfs_st/wms>
>     >> //services.ogc.noaa.gov/geoserver/nmfs_st/ows
>     <http://services.ogc.noaa.gov/geoserver/nmfs_st/ows>
>     >>
>     >> After looking at these URLs I realize that I'm including our
>     workspace name
>     >> (nmfs_st). I'm not sure if that's necessary. Micah, do you know?
>     >>
>     >> Tim
>     >>
>     >>
>     >>
>     >>
>     >> On Wed, Jan 7, 2015 at 12:25 PM, Chi Kang - NOAA Federal
>     >> <chi.y.kang at noaa.gov <mailto:chi.y.kang at noaa.gov>> wrote:
>     >>
>     >> Tim / Micah I don't think i have an issue getting more granular
>     but I
>     >> want to understand all the URLs involved first.
>     >>
>     >> Can someone outline them for me as an example?
>     >>
>     >>
>     >> On Fri, Jan 2, 2015 at 5:11 PM, Tim Haverland - NOAA Federal
>     >> <tim.haverland at noaa.gov <mailto:tim.haverland at noaa.gov>> wrote:
>     >>
>     >> What you suggest would be very helpful and allow my calls to
>     geoserver
>     >> to be
>     >> protocol relative.
>     >>
>     >> I have redirected all https calls to my map to http at the moment.
>     >>
>     >> Tim
>     >>
>     >> On Fri, Jan 2, 2015 at 5:07 PM, Micah Wengren
>     <micah.wengren at noaa.gov <mailto:micah.wengren at noaa.gov>>
>     >> wrote:
>     >>
>     >> Tim/WOC,
>     >>
>     >> I think the reason for the extra authentication step for HTTPS
>     was to
>     >> prevent public from being able to access /geoserver/web (with login
>     >> form
>     >> components) for preventing brute force password attacks and such.
>     >>
>     >> I can't think of a reason to not allow HTTPS access to the
>     >> /geoserver/wms
>     >> and /geoserver/wfs paths though.
>     >>
>     >> This might be something to look into potentially relaxing, if
>     the WOC
>     >> is
>     >> willing to make that change and web server config allows it to that
>     >> level of
>     >> granularity.
>     >>
>     >> Micah
>     >>
>     >>
>     >> On 12/4/2014 12:09 PM, Tim Haverland - NOAA Federal wrote:
>     >>
>     >> Hi Micah,
>     >>
>     >> Yes, I was trying to avoid the situation where someone loads
>     our map
>     >> page
>     >> via https and our calls to services using http are blocked by the
>     >> browser.
>     >>
>     >> I can have our sysadmin redirect all https requests to my page
>     to http,
>     >> but was hoping to avoid that by simply making my service URLs
>     protocol
>     >> relative.
>     >>
>     >> Is there a reason why services.ogc.noaa.gov
>     <http://services.ogc.noaa.gov> requests a password for
>     >> ssl?
>     >> Are there services that I can't get to via HTTP but can with HTTPS?
>     >>
>     >> Tim
>     >>
>     >> On Thu, Dec 4, 2014 at 9:48 AM, Micah Wengren - NOAA Federal
>     >> <micah.wengren at noaa.gov <mailto:micah.wengren at noaa.gov>> wrote:
>     >>
>     >> Tim,
>     >>
>     >> Your goal is to have your web map SSL-enabled (to allow restricted
>     >> views
>     >> with a user login for example), or are you just trying to
>     accommodate
>     >> users
>     >> who come in to the Fisheries website over HTTPS?
>     >>
>     >> If it's the latter, I think you should be able to hard-code the web
>     >> map
>     >> requests to go over HTTP regardless of which protocol users come to
>     >> the site
>     >> through. This way they shouldn't get the login prompt from a
>     non-NOAA
>     >> network to access services.ogc.noaa.gov
>     <http://services.ogc.noaa.gov>. The drawback to that is that
>     >> the
>     >> browser will give a warning message because some content is coming
>     >> over
>     >> HTTP. That's the case for the NOAA Data Catalog, because the tile
>     >> provider
>     >> only supports HTTP not HTTPS: https://data.noaa.gov/dataset (the
>     >> browser
>     >> will show a warning message rather than a secure connection
>     message).
>     >>
>     >> It might be more complicated in your case though because you're
>     making
>     >> GetFeatureInfo requests to the service that return XML instead
>     of map
>     >> tiles.
>     >> I don't know how that would differ.
>     >>
>     >>
>     >> Can you look into that before we investigate making any changes
>     to the
>     >> HTTPS access policies?
>     >>
>     >>
>     >> Micah
>     >>
>     >>
>     >> On Wed, Dec 3, 2014 at 5:46 PM, Tim Haverland - NOAA Federal
>     >> <tim.haverland at noaa.gov <mailto:tim.haverland at noaa.gov>> wrote:
>     >>
>     >> Hi all,
>     >>
>     >> Recently I've been trying to enable an application that uses
>     noaa ogc
>     >> services to run under https. When I do so, the application runs
>     when
>     >> I'm at
>     >> work, but from home (and no VPN) it asks that I enter my noaa email
>     >> username/pwd.
>     >>
>     >> This is fine for me but won't work for public users of my
>     >> application.
>     >>
>     >> Is there a reason that ssl access to services.ogc.noaa.gov
>     <http://services.ogc.noaa.gov> requires
>     >> login for users that aren't on a noaa network (I assume).
>     >>
>     >> Here's the app if anyone want to see this behavior in action:
>     >>
>     >> Works anywhere:
>     >>
>     >>
>     http://www.st.nmfs.noaa.gov/humandimensions/social-indicators/map-copy
>     >>
>     >> Requires password for I assume non-noaa network users:
>     >>
>     >>
>     https://www.st.nmfs.noaa.gov/humandimensions/social-indicators/map-copy
>     >>
>     >> I suppose I could redirect users coming in on https to http,
>     but that
>     >> causes other headaches on my end.
>     >>
>     >> Any thoughts?
>     >>
>     >> Tim
>     >>
>     >> --
>     >> Tim Haverland
>     >> Acting Operations Branch Chief
>     >> NOAA Fisheries Office of Science and Technology
>     >> 1315 East-West Highway
>     >> SSMC3 Rm 12303
>     >> Silver Spring, MD 20910
>     >> 301-427-8137 <tel:301-427-8137>
>     >>
>     >> _______________________________________________
>     >> Open.ogc mailing list
>     >> Open.ogc at list.woc.noaa.gov <mailto:Open.ogc at list.woc.noaa.gov>
>     >> https://list.woc.noaa.gov/cgi-bin/mailman/listinfo/open.ogc
>     >>
>     >>
>     >> --
>     >> Tim Haverland
>     >> Acting Operations Branch Chief
>     >> NOAA Fisheries Office of Science and Technology
>     >> 1315 East-West Highway
>     >> SSMC3 Rm 12303
>     >> Silver Spring, MD 20910
>     >> 301-427-8137 <tel:301-427-8137>
>     >>
>     >>
>     >>
>     >> --
>     >> Tim Haverland
>     >> Acting Operations Branch Chief
>     >> NOAA Fisheries Office of Science and Technology
>     >> 1315 East-West Highway
>     >> SSMC3 Rm 12303
>     >> Silver Spring, MD 20910
>     >> 301-427-8137 <tel:301-427-8137>
>     >>
>     >> _______________________________________________
>     >> Open.ogc mailing list
>     >> Open.ogc at list.woc.noaa.gov <mailto:Open.ogc at list.woc.noaa.gov>
>     >> https://list.woc.noaa.gov/cgi-bin/mailman/listinfo/open.ogc
>     >>
>     >>
>     >> --
>     >> Chi Y Kang
>     >> Principal Engineer
>     >> Phone: 301.628.5642 <tel:301.628.5642>
>     >> Cell: 240.338.1059 <tel:240.338.1059>
>     >>
>     >>
>     >> --
>     >> Tim Haverland
>     >> Acting Operations Branch Chief
>     >> NOAA Fisheries Office of Science and Technology
>     >> 1315 East-West Highway
>     >> SSMC3 Rm 12303
>     >> Silver Spring, MD 20910
>     >> 301-427-8137 <tel:301-427-8137>
>     >>
>     >>
>     >>
>     >>
>     >>
>     >
>     >
>     >
>     > --
>     > Chi Y Kang
>     > Principal Engineer
>     > Phone: 301.628.5642 <tel:301.628.5642>
>     > Cell: 240.338.1059 <tel:240.338.1059>
>
>
>
>
> -- 
> Chi Y Kang
> Principal Engineer
> Phone: 301.628.5642
> Cell: 240.338.1059

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://list.woc.noaa.gov/pipermail/open.ogc/attachments/20150310/5688b4ec/attachment-0001.html>


More information about the Open.ogc mailing list