[OTDev] A&A

Nina Jeliazkova jeliazkova.nina at gmail.com
Fri Oct 22 18:22:37 CEST 2010


Hi Tobias,

On 22 October 2010 18:15, Tobias Girschick <tobias.girschick at in.tum.de>wrote:

> Hi Micha, All,
>
> On Fri, 2010-10-22 at 11:04 +0200, Micha Rautenberg wrote:
> > Hi Tobias, All,
> >
> > yes it should be in API 1.2 and (in my opinion) in every component even
> > if it is optional.
>
> Ok. I think that's a good solution.
>
> > and a short comment on the algorithm example
> >
> > curl -X GET -d 'username=usr' -d 'password=pwd'
>


> > http://localhost:8080/OpenTox-dev/algorithm/test -iv
> >
> > should use the token from the opensso authentication
> >
> > curl -X GET -d 'token_id=token'
> > http://localhost:8080/OpenTox-dev/algorithm/test -iv
> >
> > you authenticate once and then use the token afterwards. Each
> > webservices proofs authorization with the token.
>
> The problem is, that in this case, the user would have to authenticate
> on his own before using a 'restricted' web service. Or is it in this
> case a 'security breach', as the service get's the uid and pwd? It would
> be convenient to just use my pwd and my username if I want to issue just
> one service call...
> Has this been discussed and I am not finding and/or remembering the
> results or is this still an open issue?
>

It has been discussed number of times,  look for discussions of service
being able to authenticate on behalf of users .

I am not sure if there was a final decision , but would be good to have
support of both options.

Best regards,
Nina




>
>
> best regards,
> Tobias
>
> >
> > best regards,
> >
> > Micha
> >
> >
> > Tobias Girschick schrieb:
> > > Hi,
> > >
> > > ok. In that case, I propose to use the same scheme as in the A&A
> > > Deliverable Example session for communicating with the openSSO service
> > > to prevent confusion (also the parameter names can be reused). There
> > > form parameters are used:
> > > curl -i -d 'username=<uid>' -d 'password=<sec>'
> > > http://opensso.in-silico.....
> > >
> > > For an algorithm that would mean:
> > > curl -X GET -d 'username=usr' -d 'password=pwd'
> > > http://localhost:8080/OpenTox-dev/algorithm/test -iv
> > >
> > > The question is where to add it in the wiki (API)? Only in the A&A
> > > section or in every component?
> > >
> > > Any opinions on that? NTUA, how are you handling that? ALU? All?
> > > best regards,
> > > Tobias
> > >
> > > On Thu, 2010-10-21 at 16:16 +0300, Nina Jeliazkova wrote:
> > >
> > >> Hi Tobias,
> > >>
> > >>
> > >> On 21 October 2010 16:07, Tobias Girschick
> > >> <tobias.girschick at in.tum.de> wrote:
> > >>         Hi Nina, Andreas, All,
> > >>
> > >>         while adding the A&A functionality to the TUM webservices I
> > >>         stumbled
> > >>         upon one question: is there a uniform way how the user
> > >>         credentials
> > >>         (username, password) are passed to the services (not the A&A
> > >>         services
> > >>         but an algorithm for example)?
> > >>
> > >>         Meaning do I issue:
> > >>         curl -X GET
> > >>
> http://localhost:8080/OpenTox-dev/tox/test?username=usr&password=pwd -iv
> > >>         or
> > >>         curl -X GET -d 'username=usr' -d 'password=pwd'
> > >>         http://localhost:8080/OpenTox-dev/tox/test -iv
> > >>
> > >>         I didn't find anything in the A&A Deliverable or the API...
> > >>
> > >> Your observation is absolutely correct, AFAIK this is not (yet!)
> > >> defined in the API .
> > >>
> > >>
> > >>         I think I have seen the first version in the AMBIT code (might
> > >>         be
> > >>         deprecated version)
> > >>
> > >>         Object username =
> > >>
> request.getResourceRef().getQueryAsForm().getFirstValue(username_tag);
> > >>
> > >>
> > >> It's not deprecated, but was done quickly to test the the AA and is
> > >> used only for a test resource.
> > >>
> > >> I think it would be best if you just pick up parameter names which you
> > >> prefer (hopefully the same as ALU and NTUA are using) and document it
> > >> in the wiki.  I don't have preferences and it will be easy to change
> > >> ambit code to reflect your choice.
> > >>
> > >> Best regards,
> > >> Nina
> > >>
> > >>
> > >>         best regards,
> > >>         Tobias
> > >>         --
> > >>         Dipl.-Bioinf. Tobias Girschick
> > >>
> > >>         Technische Universität München
> > >>         Institut für Informatik
> > >>         Lehrstuhl I12 - Bioinformatik
> > >>         Bolzmannstr. 3
> > >>         85748 Garching b. München, Germany
> > >>
> > >>         Room: MI 01.09.042
> > >>         Phone: +49 (89) 289-18002
> > >>         Email: tobias.girschick at in.tum.de
> > >>         Web: http://wwwkramer.in.tum.de/girschick
> > >>
> > >>
> > >>
> > >
> > >
> > _______________________________________________
> > Development mailing list
> > Development at opentox.org
> > http://www.opentox.org/mailman/listinfo/development
>
> --
> Dipl.-Bioinf. Tobias Girschick
>
> Technische Universität München
> Institut für Informatik
> Lehrstuhl I12 - Bioinformatik
> Bolzmannstr. 3
> 85748 Garching b. München, Germany
>
> Room: MI 01.09.042
> Phone: +49 (89) 289-18002
> Email: tobias.girschick at in.tum.de
> Web: http://wwwkramer.in.tum.de/girschick
>
> _______________________________________________
> Development mailing list
> Development at opentox.org
> http://www.opentox.org/mailman/listinfo/development
>



More information about the Development mailing list