Mailing-List: contact dev-help@taverna.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@taverna.incubator.apache.org
Message-ID: <55643EC8.2090004@manchester.ac.uk>
Date: Tue, 26 May 2015 10:37:12 +0100
From: "Donal K. Fellows" <donal.k.fellows@manchester.ac.uk>
Organization: University of Manchester
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8;
 rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: dev@taverna.incubator.apache.org
CC: larryakah@gmail.com
Subject: Re: GSoC android app update and availability for first weeks of GSoC
References: <2C733198BCF73948947E47FE746D0F4E18F32992@MBXP14.ds.man.ac.uk>
	<CAGW9_gNE_Bd+3c7NrnYu_t5eo6TzY1ncyJ50DSiwLkKjHONRQg@mail.gmail.com>
	<555F5DA9.1030808@googlemail.com>
	<CAGW9_gOgNY1nFobM8_Q7bpBmox5H+YfUVfQhzox2E+cYUZjzoA@mail.gmail.com>
	<CAGW9_gOexdPtD9SnqHNxHCR50NNLgbnA=tcnitVu_vVTU7PezA@mail.gmail.com>
	<5561F3C5.4070508@manchester.ac.uk>
 <CAGW9_gP6S_5ueDTU=DUfEMELBN6Zyxqb24MR6JefS86neN9jRw@mail.gmail.com>
In-Reply-To: 
 <CAGW9_gP6S_5ueDTU=DUfEMELBN6Zyxqb24MR6JefS86neN9jRw@mail.gmail.com>
Content-Type: multipart/mixed;
 boundary="------------030201080307050106010805"

--------------030201080307050106010805
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

On 25/05/2015 10:00, Larry Akah wrote:
> So I want to know against which server they do so. That is, which server
> holds the user accounts against which they authenticate. The server url to
> which to post data for authentication. Some useful documentation about that
> would help since i have searched and not yet found one that explains user
> authentication with a server.

The server itself holds the user account details; they're configured
through the administrative interface (which is a webapp that is only
open to people with the admin permission flag set). We don't currently
support logging in with accounts defined elsewhere; even if we did, we'd
just be delegating authentication, not authorization.

The credentials are stored in the internal database, hashed with bcrypt.
You have to provide them on each call (except a very few used to fetch
general metadata) using HTTP Basic Auth, which we selected because it is
extremely widely supported by clients. It does however mean that it is
strongly recommended that communications channels between the server and
the clients be secure; HTTPS is one way of doing this, as is co-locating
the server and its client portal on a shared secure network (relatively
easy to do these days).

Is the Taverna Server documentation missing this? It could well be. If
it is, let me know and I'll fix it. :-)

Donal.

--------------030201080307050106010805--