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

Thu Feb 26 16:58:12 UTC 2015

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> 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> 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>
> 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>
> 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
> >> //services.ogc.noaa.gov/geoserver/nmfs_st/wms
> >> //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> 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> 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>
> >> 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 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> 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. 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> 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 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
> >>
> >> _______________________________________________
> >> Open.ogc mailing list
> >> 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
> >>
> >>
> >>
> >> --
> >> 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
> >>
> >> _______________________________________________
> >> Open.ogc mailing list
> >> 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
> >> Cell: 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
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
> > --
> > Chi Y Kang
> > Principal Engineer
> > Phone: 301.628.5642
> > Cell: 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/20150226/2c324158/attachment.html>