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

[Tamas Szekeres]

Hi Thomas,

See my responses inline below:

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

>
> - ip based authentication is notoriously insecure and can be
> worked-around, albeit with a bit of effort. c.f.
> http://en.wikipedia.org/wiki/IP_address_spoofing
>
>
According to the refferred document rewriting the source address in IP is
easy, but getting the response packet from a different network is
difficult. Since this approach may provide solution mainly for private
networks, I (the implementer) let the user (who requests the feature)
decide whether this option of workaround counts or not.



> - the proposed solution of providing ip addresses in a file is simple,
> but opens up the need to support other providers in the future
> (database, ldap, etc...). In the long run this means duplicating the
> entire authentication/authorization middleware in mapserver, which is
> something that we are not competent at.
>
>
While I agree the authorization may be more generic than the current
approach, I prefer to get it implemented later assuming we can get enough
motivation and funds. The proposed solution is fairly minor, which can
easily be assimilated into a higher level concept.

Further to this, I doubt mapserver is not competent in the layer level
authorization. The concept of the layers is application  specific, the
authorization of the application specific objects should be done by the
application itself. This can however utilize a more sophisticated approach
as well, but the fact we cannot eliminate mapserver from the line is true.
For example if we introduce a role based model (with an extra level of
abstraction) mapserver should take care of how the roles should access to
the application specific objects, definitely. Assigning users/groups to
roles can then be done independently.



> - I believe there is an overlap with the exisiting ows_enable_request
> mechanism, and it is not clear which should take precedence given that
> the two mechanisms are distinct.
>
>
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."


> - This is nitpicking, but performance wise these checks will be run
> for each rendered layer, and will affect all mapserver users, whereby
> the vast majority of these users has no need for such a feature.
>
>
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.


> - I believe that similar functionality can be obtained in a much
> cleaner and modular fashion by relying on the webserver
> authentication/authorization, using plain mapfile includes and apache
> configuration, namely:

mapfile-pub.map:
> map
>  ...
>  include "layers-pub.inc"
> end
>
> mapfile-private.map
> map
>  ...
>  include "layers-pub.inc"
>  include "my-super-secret-layers.inc"
> end
>
> and in apache you use the existing, featurefull and secure options to
> set MS_MAPFILE to mapfile-pub or mapfile-private depending on ip
> addresses, authentication, time-of-day, etc...
> This also alleviates the need to implement ms_enable_modes as the
> private layers are completely absent from the configuration for an
> unauthorized client.
>
>
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.


Best regards,

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