[mapserver-dev] MS RFC 90: Enable/Disable Layers in OGC Web Services by IP Lists - Call For Vote

[Tamas Szekeres]

2013/2/28 thomas bonfort <thomas.bonfort at gmail.com>

>
>
> I agree that this is a complex area that in some case will need to be
> handled by application specific methods. My point is that limiting by
> ip only covers a tiny fraction of the AA
> (authentication/authorization) scenarios, and that we will have to be
> backwards compatible with it in the long run the day we have the
> funds/needs for a full fledged AA component.
>
>
We don't necessarily required to be backward between major version changes.
Users should update their mapfiles so they could migrate their IP lists to
some other places if required (Assuming we remain function compatible)



>
> >
> > I thought if it was defined in the RFC well enough, by mentioning "The
> > setting of ows_enable_request (added in MS RFC 67) will also be taken
> into
> > account. Disabled requests cannot be re-enabled by IP lists, however we
> can
> > restrict the access to a subset of layers by IP lists within the enabled
> OGC
> > web services."
> what I meant here is allowing a specific operation based on
> authorization (e.g. allow getmap for everyone, but getfeature only to
> a list of ips)
>
>
This would require to maintain different IP lists per request type which
was not addressed. But I'm not sure what specific use cases would require
this. I think if someone is not authorized to see a particular layer for
GetFeature he should not be allowed to see that layer on the map either.


> >
> > Not sure if this concern is valid. If we don't use this feature just an
> > extra lookup for the metadata is taking place per layer. Assuming we have
> > dozens of metadata (and other kind of) lookups at each request this
> should
> > not be significant.
>
> Agreed that this is not significant, I did say this was nitpicking. We
> are already abusing metadata, but I am not thrilled that we are having
> yet another hashtable lookup at each layer render. If the AA concept
> is extended along this model in the feature, we will also be adding
> lookups for allowed_ip_ldap, allowed_user_file, allowed_ip_sqlite,
> etc...
>
>
We not necessarily require to introduce new metadata because of this. With
the proposed solution we use:

"ows_allowed_ip_list" "file:[path to a file]"

We could also utilize prefixes for ldap and sqlite too.



>
> > Not sure if that could provide a compatible solution. I assume you would
> > provide the authorization by using several combination of the layers in
> > different mapfiles regarding to the various groups of clients (having the
> > same authorization). This is not very efficient to manage due to the high
> > number of the possible combinations. Also I'm not quire sure how the same
> > layer order could be retained if we sub-divide the set of layers into
> > several includes.
> The number of combinations might be a bit more complicated to
> maintain, however I don't think this is very different than having to
> maintain an uptodate list of ips inside the mapfile. It is however so
> much more flexible, as you can factor in any kind of authentication
> provided by apache. Having it this way also delegates AA to a sysadmin
> profile, who is usually much better suited at this task than a
> gis-mapfile profile.
>

I think in most cases admins will maintain ip lists in files. This is quite
independent from the mapfile configuration and it can be placed in
different locations either. We could also assign meaningful names to the
files depending on the role it represents.



> As to layer ordering, you can keep the layer ordering by ordering your
> INCLUDEs no? or am I misunderstanding your point?
>
>
We not necessarily assign adjacent layers to the same users (IPs). So we
might require to place each layer to a different include file which IMHO
makes the setting more complicated to manage. Regardless of the include
files you may probably require to maintain different set of mapfiles for
each user combination, definitely.


Best regards,

Tamas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-dev/attachments/20130228/d4274cac/attachment-0001.html>