geo-location securityMethod?

[Brian Major]

Hi Markus,


On Wed, Sep 14, 2016 at 12:47 AM, Markus Demleitner <
msdemlei at ari.uni-heidelberg.de> wrote:

> Dear colleagues,
>
> I'm not quite sure where to go with this, but since it could have
> something to do with our work on auth method identifiers for
> SecurityMethod, I thought I should cc: gws.  Discussion, I'd suggest,
> should take place on registry.
>
> The problem popped up with ivo://nci.org.au/skymapper/tap -- that's a
> properly registred TAP service, as it should be.  However, access is
> limited by (I suppose) IP ranges to something like "within
> Australia".


> Now, for GloTS (you may remember the globally federated TAP schema),
> this is a bit of a problem, because it tries to hit this service once
> every 12 hours and of course gets rejected, which results in log spam
> on my end.
>
> This type of "global TAP operation" will, I predict, become more
> important as more common data models like Obscore emerge, and clients
> should have a way to decide whether a failure of a remote service is
> to be expected (because of missing "credentials") or whether a
> service just has a temporary downtime and the user should be bothered
> with diagnostics.
>
> At this point I think securityMethod might be a reasonable way to do
> this -- if an interface defines a securityMethod, in GloTS I (and in
> future all-VO Obscore searchers their authors) could just ignore it.
>
> However, we don't have a securityMethod id defined for "access
> control by IP address" (or perhaps something a little more generic.
>
> Well, could we?


> An alternative I can see might be to say that clients are advised to
> take 403 forbidden as a non-failure.  Which might be easier overall,
> but somehow I think this rule will hide genuine errors.
>

If you are indeed getting a 403 forbidden response, then I think that's
enough to indicate that the service is up but you are not authorized see
it.

securityMethods are ways for services to say what credentials it can
recognize in order to determine who you are.  In this case, the service
already knows enough about who you are (by IP), but it is saying that
you are not authorized.  It is analogous to, say, providing a valid
username/password combination to a service but still being 'forbidden'
to access a resource.  So, I think this question of authorization goes
beyond securityMethod and I doesn't fit the model quite right.

However, if, instead of returning the 403 forbidden, the service didn't
respond at all or responded with a network level error, a client would
not have any way of knowing that is is behind an ACL.  That could be
an argument to having something in the interface definition to indicate
it's available only to certain clients with certain characteristics (such
as geo-location).


Brian



>
>         -- Markus
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/registry/attachments/20160927/8bc69cdb/attachment.html>