(Migrated) Payload-based auth mechanism

(This message has been automatically imported from the retired mailing list)

Hi,

a scenario which unfortunately is quite frequently encountered is an
external service which authenticates its clients without using any
standards-based approach. Let me give you an example:

POST /some/api
Content-Type: application/json
Payload:
{
‘user’: ‘…’,
‘password’: ‘…’,
other stuff…
}

Of course this isn’t nice at all and if possible a standards-based
approach should be preferred.

I was wondering if there is any way to create an outgoing connection
supporting this kind of authentication scheme without having to manage it
manually and, in case that isn’t the case, if this would be an interesting
addition.

Cheers,
Andr=C3=A9s

On 16/03/15 20:57, Andrés Fernández wrote:

I was wondering if there is any way to create an outgoing connection
supporting this kind of authentication scheme without having to manage
it manually

Well, there isn’t really - this is a custom auth mechanism and it cannot
be added just through configuration.

You will probably need a common function in a base class for your
services to inherit from.

and, in case that isn’t the case, if this would be an
interesting addition.

Yes, definitely. We already have XPath for channels …

https://zato.io/docs/web-admin/security/xpath.html

… so it makes sense to add JSON and XPath for outgoing connections as
well. Also JSON to channels in that case :slight_smile:

On 16/03/15 21:08, Dariusz Suchojad wrote:

Well, there isn’t really - this is a custom auth mechanism and it cannot
be added just through configuration.

Here’s an idea though.

We could add a flag to signal that a user service implements a security
mechanism.

For instance:

class MyAuth(Service):

def handle(self):

(The convention would be that anything whose name ends in Auth is an
auth service - could be overridden in server.conf).

And now in channels and outconns in the ‘Security’ definition all
services containing such a flag would be listed along with other auth means.

In channels - self.response.payload.auth_ok would have to be True/False.

In outconns - I’m not sure myself yet because sometimes you will need to
add custom headers rather than elements in payload.

Regardless of the details of the API that we can work out with time, the
ultimate goal would be implementing custom auth without actually waiting
for Zato releases, sort of like user plugins for security.

On Mon, Mar 16, 2015 at 3:57 PM, Andrés Fernández
farefernandez@gmail.com wrote:

Hi,

a scenario which unfortunately is quite frequently encountered is an
external service which authenticates its clients without using any
standards-based approach. Let me give you an example:

POST /some/api
Content-Type: application/json
Payload:
{
‘user’: ‘…’,
‘password’: ‘…’,
other stuff…
}

Of course this isn’t nice at all and if possible a standards-based
approach should be preferred.

I was wondering if there is any way to create an outgoing connection
supporting this kind of authentication scheme without having to manage it
manually and, in case that isn’t the case, if this would be an interesting
addition.

Cheers,
Andrés

Hi Andrés,

An alternative that our team found was to use the JWT standard
http://jwt.io/ and the https://github.com/jpadilla/pyjwt with Zato. We
are still working out the details, but so far it is working well.

Sam