TAP/UWS authentication - short survey

[Patrick Dowler]

On 2011-08-08 09:43:42 matthias egger wrote:
> * do you run a TAP service which requires authentication

It does not require authentication, but users can authenticate if want to (see 
below). The "observation" tables in our TAP service contain both public and 
proprietary metadata and they describe public and proprietary data. During the 
transformation from ADQL to SQL, we modify the query such that:

- anonymous users only see public metadata

- authenticated users see public metadata and proprietary metadata they are 
permitted to see

- we currently let people see the metadata for proprietary data and try to 
download it since the retrieval system will challenge them and check 
authorisation; in theory we could predict the success of that and save the 
users some hassle/disappointment but it's hard to see how to make that work 
"correctly" with ADQL queries

So, right now users get some value in authenticating *if* they could have 
access to proprietary metadata (they are part of an observing program for a 
telescope collection we host and still in proprietary period, for example).

In the very near future, we want to implement things like storing the query 
result from an async query directly in the user's VOSpace; that will require 
authentication *and* credential delegation. This would also be needed to 
support upload tables from a vos URI, assuming the vospace requires 
authentication.

see: http://www.ivoa.net/Documents/CredentialDelegation/

> * if yes: which authentication method/system do you use:
> 
>   * (HTTP) BASIC
> 
>   * FORM-Based
> 
>   * X.509 Certificates

We use IVOA SSO (X.509 client cert) on all https connections and no auth on 
http, so users can chose to authenticate by using https instead of http.

Well, that's the short version of the story... we have some internal use cases 
that are making it desireable to implement some kind of username/password auth 
on an alternate (probably unregistered) resource path. This is mainly because 
our users find certificates painful, although now that we know what we are doing 
and resolved the issues it is pretty slick. 

I'm not sure how to interpret the SSO mandate that basic auth *not* be used. 
It certainly cannot be the only way to authenticate but I don't see how any 
spec can forbid custom behaviour that goes beyond the spec... maybe it just 
means that such a resource cannot be considerd an IVOA-compliant resource?
 
>   * SAML2
> 
>   * OpenID


-- 

Patrick Dowler
Tel/Tél: (250) 363-0044
Canadian Astronomy Data Centre
National Research Council Canada
5071 West Saanich Road
Victoria, BC V9E 2M7

Centre canadien de donnees astronomiques
Conseil national de recherches Canada
5071, chemin West Saanich
Victoria (C.-B.) V9E 2M7