Sean -

While I agree with you in theory, we need to acknowledge that our WMS servers 
need (in some cases) to be easily accessible to the WMS clients our users want 
to or need to use.  I cannot tell my ArcGIS customers that my server uses HTTP 
Basic authentication, because their client software provides no support for it 
and no place for them to type their username and password.

For better or worse, the WMS specification is completely silent on the subject 
of authentication, and therefore set no expectations on what a well-behaved 
client is supposed to do.  It is unreasonable to expect, in the absence of 
guidance in the specification, that all WMS clients will support the complete 
HTTP protocol suite in all its flavors, with the required user interfaces to 
make that happen.

So we need to compromise to live in the real world.  The "wrapper" script is 
one way to do that.  If I create a wrapper PHP script such that my WMS Resource 
URI changes from:

http://my.server.com/mapserv?map=my.map&;

to:

http://my.server.com/mapserv.php?user=me&password=secret&;

then I'm really not doing anything different than what HTTP Basic 
authentication is doing, except for putting a few of the bytes in different 
places in the HTTP request.  It is hard to see that using HTTP Basic 
authentication is fundamentally the Right Way and the querystring parameters is 
the Evil Way, since they are almost identical.  Perhaps the wrapper approach 
even has the benefit of reminding the user that their id and password are being 
sent as clear text!

     - Ed

Ed McNierney
Chief Mapmaker
Demand Media / TopoZone.com
73 Princeton Street, Suite 305
North Chelmsford, MA  01863
Phone: 978-251-4242, Fax: 978-251-1396
[EMAIL PROTECTED]



-----Original Message-----
From: UMN MapServer Users List [mailto:[EMAIL PROTECTED] On Behalf Of Sean 
Gillies
Sent: Friday, August 31, 2007 6:49 PM
To: [email protected]
Subject: Re: [UMN_MAPSERVER-USERS] adding support for user authentication 
within Mapserver for GetCapablities and GetMap

Gerry Creager wrote:
> Gregor Mosheh wrote:
>> Sean Gillies wrote:
>>>> Gerry Creager wrote:
>>>>> Rights management is now well into the investigatory and 
>>>>> specification stages in OGC.
>>>> He, that's excellent to hear. Thanks for the tip.
>>> No, it's not excellent. DRM is defective by design.
>> Hrm, perhaps I misunderstood. I read "access control" as in password 
>> protection to get into my WMS/WFS server.
>>
>> Gerry, did you mean access control at the application layer, so I can 
>> have Mapserver manage user accounts and access to my WMS layers, or 
>> something deeper such as DRM on the imagery, copy-protection on 
>> GeoTIFFs, and the like?
>>
>> (yeah, it's off the topic of Mapserver; so's a lot of educational and 
>> interesting stuff we talk about :)
> 
> The working group title is GeoDRM.  I am not real happy with that but 
> the bigger organizations are thinking of the resources they've put into 
> their datasets and/or products. Some governments fail to see the 
> benefits to their citizens of making geospatial data widely available, 
> and thus are supporting this sort of thing.  It's gonna be an 
> interesting period, but I'm trying to get them to see the benefits of 
> authentication/authorization/capabilities control.  They keep thinking 
> the RIAA/MPAA model is good and working.  We have interesting debates. 
> I can't tell if I'm making headway or not.
> 
> The National Middelware Initiative (NSF funded, Internet2/SURA 
> implemented) covers a lot of this via federation and credential exchange 
> in their Shibboleth software initiative.
> 
> gerry

Gerry, I'm all for security too, but I think it's already addressed for 
web services by HTTP Basic + SSL/TLS. In my opinion, adding a spatial 
and time dimensions to auth (user 'joe' can only use a service between 
9am-5pm originating from Larimer County, Colorado) is pure geo-wankery.

The "GeoDRM" name -- it's clearly pandering to the non-technical guys in 
suits who (like you say) still think the RIAA is the good guy.

Cheers,
Sean

Reply via email to