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

Thu Jan 22 17:37:18 UTC 2015

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