<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">
<div class="im"><br></div><div class="im">
<br>
</div>I agree that this is a complex area that in some case will need to be<br>
handled by application specific methods. My point is that limiting by<br>
ip only covers a tiny fraction of the AA<br>
(authentication/authorization) scenarios, and that we will have to be<br>
backwards compatible with it in the long run the day we have the<br>
funds/needs for a full fledged AA component.<br>
<div class="im"><br></div></blockquote><div><br></div><div>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) </div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
><br>
> I thought if it was defined in the RFC well enough, by mentioning "The<br>
> setting of ows_enable_request (added in MS RFC 67) will also be taken into<br>
> account. Disabled requests cannot be re-enabled by IP lists, however we can<br>
> restrict the access to a subset of layers by IP lists within the enabled OGC<br>
> web services."<br>
</div>what I meant here is allowing a specific operation based on<br>
authorization (e.g. allow getmap for everyone, but getfeature only to<br>
a list of ips)<br>
<div class="im"><br></div></blockquote><div><br></div><div>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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
><br>
> Not sure if this concern is valid. If we don't use this feature just an<br>
> extra lookup for the metadata is taking place per layer. Assuming we have<br>
> dozens of metadata (and other kind of) lookups at each request this should<br>
> not be significant.<br>
<br>
</div>Agreed that this is not significant, I did say this was nitpicking. We<br>
are already abusing metadata, but I am not thrilled that we are having<br>
yet another hashtable lookup at each layer render. If the AA concept<br>
is extended along this model in the feature, we will also be adding<br>
lookups for allowed_ip_ldap, allowed_user_file, allowed_ip_sqlite,<br>
etc...<br>
<div><div class="h5"><br></div></div></blockquote><div><br></div><div>We not necessarily require to introduce new metadata because of this. With the proposed solution we use:</div><div><br></div><div>"ows_allowed_ip_list" "file:[path to a file]"</div>
<div><br></div><div>We could also utilize prefixes for ldap and sqlite too.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
<br>
> Not sure if that could provide a compatible solution. I assume you would<br>
> provide the authorization by using several combination of the layers in<br>
> different mapfiles regarding to the various groups of clients (having the<br>
> same authorization). This is not very efficient to manage due to the high<br>
> number of the possible combinations. Also I'm not quire sure how the same<br>
> layer order could be retained if we sub-divide the set of layers into<br>
> several includes.<br>
</div></div>The number of combinations might be a bit more complicated to<br>
maintain, however I don't think this is very different than having to<br>
maintain an uptodate list of ips inside the mapfile. It is however so<br>
much more flexible, as you can factor in any kind of authentication<br>
provided by apache. Having it this way also delegates AA to a sysadmin<br>
profile, who is usually much better suited at this task than a<br>
gis-mapfile profile.<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
As to layer ordering, you can keep the layer ordering by ordering your<br>
INCLUDEs no? or am I misunderstanding your point?<br>
<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div><br></div><div>Best regards,</div><div><br></div><div>Tamas</div><div><br></div></div>