Hi Thomas,<div><br></div><div>See my responses inline below:<br><br><div class="gmail_quote">2013/2/28 thomas bonfort <span dir="ltr"><<a href="mailto:thomas.bonfort@gmail.com" target="_blank">thomas.bonfort@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
- ip based authentication is notoriously insecure and can be<br>
worked-around, albeit with a bit of effort. c.f.<br>
<a href="http://en.wikipedia.org/wiki/IP_address_spoofing" target="_blank">http://en.wikipedia.org/wiki/IP_address_spoofing</a><br>
<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- the proposed solution of providing ip addresses in a file is simple,<br>
but opens up the need to support other providers in the future<br>
(database, ldap, etc...). In the long run this means duplicating the<br>
entire authentication/authorization middleware in mapserver, which is<br>
something that we are not competent at.<br>
<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- I believe there is an overlap with the exisiting ows_enable_request<br>
mechanism, and it is not clear which should take precedence given that<br>
the two mechanisms are distinct.<br>
<br></blockquote><div><br></div><div>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."</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- This is nitpicking, but performance wise these checks will be run<br>
for each rendered layer, and will affect all mapserver users, whereby<br>
the vast majority of these users has no need for such a feature.<br>
<br></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- I believe that similar functionality can be obtained in a much<br>
cleaner and modular fashion by relying on the webserver<br>
authentication/authorization, using plain mapfile includes and apache<br>
configuration, namely: </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
mapfile-pub.map:<br>
map<br>
 ...<br>
 include "layers-pub.inc"<br>
end<br>
<br>
mapfile-private.map<br>
map<br>
 ...<br>
 include "layers-pub.inc"<br>
 include "my-super-secret-layers.inc"<br>
end<br>
<br>
and in apache you use the existing, featurefull and secure options to<br>
set MS_MAPFILE to mapfile-pub or mapfile-private depending on ip<br>
addresses, authentication, time-of-day, etc...<br>
This also alleviates the need to implement ms_enable_modes as the<br>
private layers are completely absent from the configuration for an<br>
unauthorized client.<br>
<br></blockquote><div><br></div><div>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. </div>
<div><br></div><div><br></div><div>Best regards,</div><div><br></div><div>Tamas</div><div><br></div><div><br></div></div></div>