adding support for user authentication within Mapserver for GetCapablities and GetMap

Ed McNierney ed at TOPOZONE.COM
Sat Sep 1 08:57:14 PDT 2007


Christopher -

"the authentication mechanism you choose needs to be down to you" -
actually, in this case, ESRI actually gets to make the choice <g>, and
they made a spectacularly poor one.

	- Ed

-----Original Message-----
From: UMN MapServer Users List [mailto:MAPSERVER-USERS at LISTS.UMN.EDU] On
Behalf Of Christopher Schmidt
Sent: Saturday, September 01, 2007 9:14 AM
To: MAPSERVER-USERS at LISTS.UMN.EDU
Subject: Re: [UMN_MAPSERVER-USERS] adding support for user
authentication within Mapserver for GetCapablities and GetMap

On Sat, Sep 01, 2007 at 12:15:30AM -0400, Ed McNierney wrote:
> Christopher -
> 
> Yes, but it is important to remember that the "perspective of the
user"
> is often more important than the "perspective of the web", and we need
> to provide solutions users can actually use, not ones which
impressively
> adhere to all the aesthetically correct principles but don't actually
> work.

Completely agreed. The fact that it is the best possible solution
doesn't make it a 'correct' solution though: Having users use this
particular solution is encouraging them to do something potentially
dangerous, and because it's "not the way of the web", they should be
warned that they are doing so that in order to make correct choices
based on that fact. (Like choosing throwaway password, or possibly even
generating it for them, rather than having them use one of their own.)

I completely agree that you have to do whatever it takes to get the job
done. If you're working in the web browser, you're in luck, since the
browser takes care of this problem for you, and you can use HTTP
authentication. That's a great thing to have. When you're working
outside the browser, however, I agree that the lack of standard on this
is frustration -- 

-- but I'm not sure that it changes the point of what the *right* thing
to do is. The fact that the standard is looking to be anything other
than asking WMS clients to support HTTP authentication seems like a
problem that was originally brought up by Sean. I don't know if he was
neccesarily saying that all clients should only use HTTP Auth -- I know
I wasn't -- but rather that the standard should prescribe HTTP Auth, and
then clients should support it.

But, as you said, it doesn't matter what should happen: what matters is
what happens, and what needs to be done in order to get something
working for your use case. 

In the browser-as-client environment, the answer seems simple: Use HTTP
Auth. Then, your auth can take place outside your MapServer CGI, and you
don't get tangled up in a big mess of anything. The browser implements
these things for you, and your webserver implements the other half.

In other environments, you'll have to be more creative. You could have
users sign in on a website, then store their IP as a user for a certain
period of time (until they are inactive for 6 hours, for example) and
allow traffic from that IP through. That could still be done 'outside'
mapserver, using your favorite  mod_foo bindings to write the
authentication module.

Or maybe you really do need to stick the username and password into the
URL, for tracking, but be aware that those are easily copyable, more
likely to be found by spiders, etc., so it may make more sense to tie it
only to a token, perhaps one which expires after a certain time period,
rather than a username and password, the exposure of which could be
annoying at best, and crippling at worst.

In the end, the authentication mechanism you choose needs to be down to
you -- and if the "W" in "WMS" really wants to live up to its name,
maybe it's time to start forcing the hand of standards bodies and client
authors to support HTTP auth as a simple authentication scheme for
accessing WMS servers. OpenLayers is already there. :) 

Regards,
-- 
Christopher Schmidt
MetaCarta



More information about the MapServer-users mailing list