TAP 1.1 securityMethod VOSI-capabilities extension

Mark Taylor M.B.Taylor at bristol.ac.uk
Thu Oct 3 12:42:13 CEST 2019


Juan and Juan Carlos,

On Thu, 3 Oct 2019, Juan Gonzalez wrote:

> Following the discussions in Paris and your early implementation of authentication methods description in VOSI capabilities in TOPCAT, JC. Segovia has prepared a test service of our Gaia TAP including the response with 'securityMethod' items to 'ivo://ivoa.net/std/TAP' capabilities as follows: 
> 
> <securityMethod/> 
> <securityMethod standardID="ivo://ivoa.net/sso#cookie"/> 
> 
> We tested this with the early implementation version of TOPCAT you provided in Paris (topcat-full_tap11b.jar). We were able to specify our service using 'cookies' as security method. But we were not able to retrieve any table nor to launch any sync/async query using a private table with the current Gaia TAP. The service may be added, cookie authentication method selected, and provision of the cookie retrieved as text JSESSIONID=xxxx. We get a 'Table Metadata Error' error: java.io.IOException: Table resource access failure (500 500). Apparently the tool is adding an extra /tables string to the URL before invoking the service (like /tap-server/tap/tap/tables). We can provide you further details or the test service if you wish to dig further this. 

Yes please, if you can give me a URL for the test service if I'm able
to access it, and if possible a valid cookie or a means to acquire one,
I will take a closer look.  You can communicate that to me off-list.

(I've forgotten what topcat version I may have passed you before;
my latest auth-capable version is
ftp://andromeda.star.bris.ac.uk/pub/star/topcat/pre/topcat-full_tap11c.jar,
but whether it behaves differently than the one you have in this respect
I'm not sure.  I can compare the results if I can see the service).


> Nevertheless, we think some extra parameters would be required under the 'securityMethod' item in order to have enough flexibility to interpret any cookie-based authenticated TAP. As a minimum we feel it shall be added a login URL, username and password HTTP parameters names, cookie identifier and HTTP method (get vs post) as follows: 
> 
> <securityMethod standardID="ivo://ivoa.net/sso#cookie"> 
> <param id="url" ucd="meta.ref.url" utype="Access.reference"> [ https://gea.esac.esa.int/tap-server/login | https://host/tap-server/login ] </param> 
> <param id="method" ucd="meta.ref.method" utype="Request.method">POST</param> 
> <param id="user" ucd="login.name" utype="Request.param">username</param> 
> <param id="pwd" ucd="login.password" utype="Request.param">password</param> 
> <param id="cookie" ucd="login.cookie" type="Response.cookie">JSESSIONID</param> 
> </securityMethod> 
> 
> Probably similar parameters could be added for the case of 'tls-with-certificate' services. 
> 
> What are your opinions about this? Could this be a discussion item for the upcoming Interop? 

This is certainly the kind of thing that needs to be worked out before
TAP auth is usable in practice.  Sounds to me like a topic for discussion
in the DAL/GWS "AuthN/AuthZ next steps" session in Groningen, but I
leave the details to the GWS/DAL chairs.

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/


More information about the dal mailing list