[Tilecache] Tilecache Authentication

[Christopher Schmidt]

On Thu, Jan 17, 2008 at 02:17:49PM +0100, Attila Csipa wrote:
> On Thursday 17 January 2008 13:29:38 Christopher Schmidt wrote:
> > (And this is far more than I expected you would get out of me, but
> > squeak enough and I guess you still get the grease.)
> 
> lol
> 
> > The reason that this isn't *built in* to TileCache is clear to me: it's
> > too site specific. Everyone will want a different way of doing it. Some
> 
> This is mostly what I meant by saying "unless you are doing the whole HTTP 
> authentication process within tilecache, which I would advise against." :)

Right, I just commented because it's come up a couple times -- you were
just my target because you had responded recently :)

> > For cases where you have more complex needs, you'll need a more complex
> > solution. 
> 
> What I think would make sense is to step away from the gritty details of 
> authentication and think about this from a system perspective. Is tilecache a 
> really fundamentally separate service ? Not really - it's a _cache_ as the 
> name suggests. 

I don't think that's entirely true. For some use cases ,it is -- but for
example, with Mapnik -- or for OpenAerialMap -- it's the *only* Server
for the tiles. It caches as well, but there is no seperate server on the
backend: TileCache has logic built into it, which uses mapscript to
actually generate the tiles.  

> So to do auth exclusively on the level of tilecache makes my 
> engineer-sense tingle. 

I can see that if you have a cache. 

> What I would rather lean to (again, just 
> metaphysically speaking, without getting into implementation details), is to 
> think about a mechanism that relays any necessary auth information to the 
> data source tilecache is using. If that source cannot provide any 
> authentication/access management, tilecache itself would be the wrong place 
> to put such barriers in, IMH(E)O. Comments welcome.

I think that most WMS Services don't provide authentication -- in part,
because there is no specification of ho wto do it. This means that any
auth is implemented in the same way as it would be with TileCache --
outside the service itself. If TileCache is your sole source of tiles --
everything else being blocked off by IP, for example -- then it doesn't
really matter which level you put your auth at, and the closer you put
it to the clientside, the better level of control you may have.

Additionally, even if there was a scheme which allowed authenticating to
WMS servers, that doesn't mean that you would want to use the same auth
to TileCache: TileCache is the 'public' face of the 'private' internal
service. The patch to add username/password support to WMS requests
takes this into account: you set up auth to the backend service, but
this isn't the same as the auth your users will use to get into
TileCache.

So, although I agree that putting it in TileCache is wrong, I agree for
different reasons -- I do think that TileCache is a service in and of
itself (in some cases), but that doesn't mean that it should be the
level auth lives at, becuase it's hard to implement generic
authentication support, and it's trivial in most deployment settings to
use the existing authentication support that your deployment environment
provides.

That said, if there's some scheme for which passing through
authentication makes sense, I'm willing to put in a patch, so long as it
doesn't negatively affect other users. (The WMS password one is
something I'll get in this weekend, for example.)

Regards,
-- 
Christopher Schmidt
MetaCarta