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

[thomas bonfort]

On 28 February 2013 11:02, Tamas Szekeres <szekerest at gmail.com> wrote:
> 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.

agreed.

>
>
>>
>> - 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 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.

>
>
>>
>> - 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."
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 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.

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...

>
>>
>> - 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.
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.
As to layer ordering, you can keep the layer ordering by ordering your
INCLUDEs no? or am I misunderstanding your point?

regards,
thomas

>
>
> Best regards,
>
> Tamas
>
>