TAP 1.1 authentication

[Patrick Dowler]

I am in the process of re-wording the text about auth and UWSRegExt and
while I was at it I made  a comment in the TAP11 RFC page concerning auth
endpoints in a TAP service in response to Mark's idea of thinking of
"bundles" of resources. I include it here as well for discussion:

These items from my DAL mailing list post of 2018-06-13 is the primary
obstacle to this bundle concept:

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).

3. VOSI-1.1 specifies that VOSI-capabilities must be provided with
anonymous access and such capabilities must not include a securityMethod

So, you have a base URL and a single anonymous child {baseURL}/capabilities
and all the TAP endpoints (eg sync and async query execution) have to be
siblings of that (i.e. direct children of {baseURL}). That is just a flat
list of interfaces and can't be presented as a bundle with current VOSI.
Somewhat ironically, before that DALI
<http://wiki.ivoa.net/twiki/bin/view/IVOA/DALI>-1.1 restriction the CADC
TAP service used to place the username/password auth endpoints under a
"subdirectory", so it used to be /tap/auth/sync and /tap/auth/async and now
it is /tap/auth-sync and /tap/auth-async so everything is a sibling of
/tap/capabilities... that is quite natural from a service deployment point
of view and more or less conforms to the bundle and defaults approach
described above. But the community thought it was a good idea to be able to
navigate(?) from any endpoint to the capabilities endpoint. Either (flat or
bundle) works fine if you use the capabilities the way that our
cadc-registry client lib does (it is just cosmetic). But: the only way to
go the bundle way is for TAP-1.1 to violate DALI
<http://wiki.ivoa.net/twiki/bin/view/IVOA/DALI>-1.1 and/or retract that bit
from DALI <http://wiki.ivoa.net/twiki/bin/view/IVOA/DALI> (admit mistake;
issue erratum).
--
Patrick Dowler
Canadian Astronomy Data Centre
Victoria, BC, Canada


On Wed, 13 Jun 2018 at 11:49, Patrick Dowler <pdowler.cadc at gmail.com> wrote:

> TAP-author-hat: on
>
> I won't go into all the details of the current usage, but I would like to
> point out the relevant specs and clarify what is being "proposed" and what
> is just being used.
>
> 1. VOResource defines the capability/interface/accessURL/securityMethod
> stuff in the VOSI-capabilities documents; all of that usage conforms to
> existing RECommendations
>
> 2. 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 also specifies that the capabilities resource must be named
> /capabilities (relative to the base).
>
> 3. VOSI-1.1 specifies that VOSI-capabilities must be provided with
> anonymous access and such capabilities must not include a securityMethod
>
> 4. Practically, web servers and application servers typically implement
> authentication and applications declare which endpoints (paths) require
> authentication (overly simplified); cases involving challenge-response (eg.
> http basic or digest) essentially have a different accessuRL... there are
> other configurations that lead to a different accessURL.
>
> 5. In TAP-1.0 we recommended by example that people define an interface
> where the accessURL was the base URL of the service and clients could
> append the standard /async or /sync path components to generate the
> endpoint URL themselves; RegTAP makes some discovery recommendations
> (example queries) that involve finding a capability with the TAP-1.0
> standardID.
>
> 6. The conceptual problem is that authentication is orthogonal to
> functionality but VOResource is heirarchical. VOResource chose to include
> authentication (securityMethod) at the leaves of the model, which is kind
> of like tagging... that choice is probably the most loosely coupled and
> flexible one that could have been made.
>
> And finally: when you take all these restrictions into account and  you
> want to tell clients how to authenticate, you end up with a  flat list of
> interface(s) with the different accessURL/securityMethod combinations. When
> you apply that to TAP specificially, you have some TAP-sync interfaces and
> some TAP-async interfaces and the client needs to be able to tell which one
> is which.
>
> The *only* thing being proposed is a way to tell the difference between
> the backwards-compatible base interface (#5), the additional async
> interfaces, and the additional sync interfaces. We need 3 distinct values
> to differentiate and since the interfaces behave differently the decision
> (Santiago splinter) was to invent 2 new interface types.
>
> Pat
>
>
> On 12 June 2018 at 06:58, Mark Taylor <m.b.taylor at bristol.ac.uk> wrote:
>
>> Hi DAL.
>>
>> On Tue, 12 Jun 2018, Mark Taylor wrote on thread "Home of the UWS
>> Registry Extension":
>>
>> > I still have my doubts about whether this approach is a complete
>> > or optimal solution to the problem of TAP services with multiple
>> > security methods, but this may not be the best place to air
>> > those concerns.
>>
>> I have written up my thoughts on this on the TAP 1.1 RFC page
>>
>> http://wiki.ivoa.net/twiki/bin/view/IVOA/TAP11RFC#Comments_from_Mark_Taylor_2018_0
>>
>> My comments include a call for service providers who are expecting
>> to have to provide authenticated TAP services in the future to look
>> at the relevant parts of TAP 1.1 and assess whether the current PR
>> fits their requirements.  If that's you, please take a look.
>>
>> Mark
>>
>> --
>> Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
>> m.b.taylor at bris.ac.uk +44-117-9288776  http://www.star.bris.ac.uk/~mbt/
>>
>
>
>
> --
> Patrick Dowler
> Canadian Astronomy Data Centre
> Victoria, BC, Canada
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dal/attachments/20180823/e0fcce3a/attachment-0001.html>