<div dir="ltr">Hi Markus,<div><div class="gmail_extra"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 14, 2016 at 12:47 AM, Markus Demleitner <span dir="ltr"><<a href="mailto:msdemlei@ari.uni-heidelberg.de" target="_blank">msdemlei@ari.uni-heidelberg.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dear colleagues,<br>
<br>
I'm not quite sure where to go with this, but since it could have<br>
something to do with our work on auth method identifiers for<br>
SecurityMethod, I thought I should cc: gws. Discussion, I'd suggest,<br>
should take place on registry.<br>
<br>
The problem popped up with ivo://<a href="http://nci.org.au/skymapper/tap" rel="noreferrer" target="_blank">nci.org.au/skymapper/tap</a> -- that's a<br>
properly registred TAP service, as it should be. However, access is<br>
limited by (I suppose) IP ranges to something like "within<br>
Australia".</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Now, for GloTS (you may remember the globally federated TAP schema),<br>
this is a bit of a problem, because it tries to hit this service once<br>
every 12 hours and of course gets rejected, which results in log spam<br>
on my end.<br>
<br>
This type of "global TAP operation" will, I predict, become more<br>
important as more common data models like Obscore emerge, and clients<br>
should have a way to decide whether a failure of a remote service is<br>
to be expected (because of missing "credentials") or whether a<br>
service just has a temporary downtime and the user should be bothered<br>
with diagnostics.<br>
<br>
At this point I think securityMethod might be a reasonable way to do<br>
this -- if an interface defines a securityMethod, in GloTS I (and in<br>
future all-VO Obscore searchers their authors) could just ignore it.<br>
<br>
However, we don't have a securityMethod id defined for "access<br>
control by IP address" (or perhaps something a little more generic.<br>
<br>
Well, could we?</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
An alternative I can see might be to say that clients are advised to<br>
take 403 forbidden as a non-failure. Which might be easier overall,<br>
but somehow I think this rule will hide genuine errors.<br></blockquote><div><br></div><div>If you are indeed getting a 403 forbidden response, then I think that's</div><div>enough to indicate that the service is up but you are not authorized see</div><div>it.</div><div><br></div><div>securityMethods are ways for services to say what credentials it can</div><div>recognize in order to determine who you are. In this case, the service</div><div>already knows enough about who you are (by IP), but it is saying that</div><div>you are not authorized. It is analogous to, say, providing a valid</div><div>username/password combination to a service but still being 'forbidden'</div><div>to access a resource. So, I think this question of authorization goes</div><div>beyond securityMethod and I doesn't fit the model quite right.</div><div><br></div><div>However, if, instead of returning the 403 forbidden, the service didn't</div><div>respond at all or responded with a network level error, a client would</div><div>not have any way of knowing that is is behind an ACL. That could be</div><div>an argument to having something in the interface definition to indicate</div><div>it's available only to certain clients with certain characteristics (such</div><div>as geo-location).</div><div><br></div><div><br></div><div>Brian</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
-- Markus<br>
</font></span></blockquote></div><br></div></div></div>