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

Wed Mar 11 14:24:29 UTC 2015

Looks like it works ... my production page still is redirecting all https
to http, but in a test page I was able to run my page under https using
protocol-relative links. Https is slower than http but it works.

Tim

On Tue, Mar 10, 2015 at 10:02 AM, Micah Wengren <micah.wengren at noaa.gov>
wrote:

>  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> 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
>
>
>

-- 
*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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://list.woc.noaa.gov/pipermail/open.ogc/attachments/20150311/7a29d32e/attachment-0001.html>