TAP 1.1 authentication

[Patrick Dowler]

In our case, authentication allows for a variety of more subtle things to
happen. In most  of our tap services:

- authenticated users can use a custom param to send output to a vospace
- authenticated users may be able to see rows which have restricted access
(some telescopes have proprietary metadata)
- authenticated users can make use of the UWS job listing feature (we only
let people list their own jobs)

In our catalogue tap service some tables are public and some are
proprietary so:

- authenticated users see additoonal tables they have access to
- vospace outout as above
- job listing as above

In principle, people could have private VOTable(s) in vospace and use them
via TAP_UPLOAD as well; that requires authentication (so the tap job can
retrieve the table).

We've been down the road of trying to have multiple resources in the past;
the main issue is that it is more confusing to users because they have to
pick the right resource --  the VOSI capabilities approach already works
fine and the details of auth only really effect s/w devs. There is just an
"itchy bit" because the TAP capability is not exactly a single thing. It is
one kind of "job" that is executable with two different "invocation
patterns". I think we have come down to a mechanism that makes sense,
maintains compatibility, an works programmatically, and hides as much of
the auth details from the user as possible.

--
Patrick Dowler
Canadian Astronomy Data Centre
Victoria, BC, Canada


On Wed, 29 Aug 2018 at 05:53, Paul Harrison <paul.harrison at manchester.ac.uk>
wrote:

>
>
> > On 2018-08 -27, at 13:21, Markus Demleitner <
> msdemlei at ari.uni-heidelberg.de> wrote:
> >
> > Hi all,
> >
> > On Thu, Aug 23, 2018 at 04:19:47PM -0700, Patrick Dowler wrote:
> >> 2. DALI <http://wiki.ivoa.net/twiki/bin/view/IVOA/DALI>-1.1 specifies
> >> (Section 2) that all endpoints in a service must be siblings of the
> >> VOSI-capabilities resource (except VOSI-availability); further, DALI
> >> <http://wiki.ivoa.net/twiki/bin/view/IVOA/DALI> also specifies that the
> >> capabilities resource must be named /capabilities (relative to the
> base).
> >
>
> I think that the single base URL with multiple children principle is worth
> keeping, and it seems to me that the TAP 1.1 proposal of registering the
> TAP sync/async endpoints separately for a single service is causing all
> sorts of problems/contradictions.
>
> Taking a step back then I think that the main reason for having an
> authenticated version of the service is that it can serve a potentially
> different set of (proprietary) tables - this means that it would
> potentially have a different set of VOSI metadata anyway, so it would be
> sensible to have a completely separate URL tree for the authenticated
> service. In the existing registry model this would mean two separate sets
> of capabilities (which naturally provides the grouping), one with the
> authenticated access and the other without - it might also make sense that
> for the authenticated service even the VOSI endpoints require
> authentication (the data might be so proprietary that even the metadata
> should not be exposed….).
>
> The only question then would be whether to put the two capabilities into
> one resource, or have two separate resources - either would be acceptable I
> think, though I would possibly go for two resources with a relationship
> between them and a differing description as to the public/proprietary
> nature of the access.
>
> Does this work, or have I missed something?
>
> Cheers,
>         Paul.
>
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dal/attachments/20180829/c6efab41/attachment.html>