How to retrieve the user from the session?

Support Installation and Deployment
1

Imported Google Group message. Original thread at: Redirecting to Google Groups Import Date: 2016-01-19 21:20:06 +0000.
Sender:Fabien Herfray.
Date:Thursday, 13 August 2015 03:09:13 UTC+1.

Hi,

I’m currently working on a microservice architecture with public signup/signin/signout and CRUD resources.

I know that Tyk manage only admin and developer users, not public ones, and that I have to handle the problem myself in a webservice.
I have no problem with that way of thinking but how does my CRUD webservice is supposed to retrieve the user doing the request ?

When I do a signin, my user webservice call the Tyk REST API and create a session/token, but how can the gateway find back the user from the session token afterward ?

Thanks

2

Imported Google Group message.
Sender:Martin Buhr.
Date:Thursday, 13 August 2015 19:41:16 UTC+1.

Hi Fabien,

I feel that at some point you will need to tie your users to their respective tokens / policies.

Is your application going to be reacting to their current quota usage? If so, a call back to Tyk to retrieve this information is pretty unavoidable (it changes with every request).

If you don’t want to be tied to the portal, I would suggest caching the policy data/ID and the token information in your user service when you generate the tokens (they are, after all user-domain data, so if they belong anywhere, they should be there), and if you are generating the tokens using a REST call, you have a copy of the policy ID locally.

If you want to go all out, you could put the necessary information from the Tyk Session object on it’s way using a middleware JS plugin, since the token session is sent to the plugins, so you could pass the information on to your service and just extract the data from the headers.

Cheers,
Martin

3

Imported Google Group message.
Sender:Fabien Herfray.
Date:Thursday, 13 August 2015 06:26:50 UTC+1.

Hi,

When you create the token you can add some meta data to the session object in a meta_data field, this is just a key/value map. You could embed the user ID data there. Then your App could look it up with a subsequent API call (not great because there are two round trips for identity data)

Alternatively, when you generate the token, you could store the token with your own user data during sign in so that when a request passes through Tyk, which will use an authorisation header with the Tyk token to manage the traffic, when it hits your service you can identify the user from the Tyk token by looking it up as if you were checking a user ID - might require some changes to your code though, so not great

Alternatively, you could inject the user ID from the embedded token meta data into the header for your micro services using a JavaScript middleware plugin - no change needed to your code.

Finally, you could use your own user-ID as the Tyk token by adding the token instead of having Tyk create it (different API endpoint), then the credentials are aligned and you don’t need to do any header substitution. This is amazingly simple, but means tokens are not dynamic, you’d need to be careful around expiry too.

The JS header substitution method with embedded user ID meta_data might be the most elegant way to go. But using a custom token ID that aligned with your micro service session data would be the simplest thing to do.

Let me know if you’d like some help with any of these :slight_smile:

Cheers,
Martin

From: Fabien Herfray [email protected]
Sent: Thursday, August 13, 2015 03:09
Subject: How to retrieve the user from the session ?
To: Tyk Community Support [email protected]

  • show quoted text -

–
You received this message because you are subscribed to the Google Groups “Tyk Community Support” group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To view this discussion on the web, visit https://groups.google.com/d/msgid/tyk-community-support/acb494d6-ad05-4f70-a2c5-f72f90ed896d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

4

Imported Google Group message.
Sender:Martin Buhr.
Date:Thursday, 13 August 2015 19:17:41 UTC+1.

Thanks for your detailed answer.
In fact, it brings me to other questions haha.

I like the idea of putting the user id in headers to minimize the overhead but in most case, I will probably need the roles associated with the user (the policies in the session object), which bring back the problem of having to request the gateway.
I am kind of afraid (wrong ?) of adding a lot of overhead having my CRUD service doing, for every user request, two requests to the gateway and the user service.

I also would like to be the less coupled to the gateway as possible by only having my services querying the user service.
It would provide an user/session/auth interface independent from the gateway.
The CRUD service would for exemple give the token to the user service, which would request the session from the gateway, get the associated user and give back the whole package to the CRUD service. What do you think ?

Or maybe that’s not the way of doing the role management ? Should I have a parallel role/authorization system for my services ?
I seems to me that it would add a lot of complexity.

  • show quoted text -
5

Imported Google Group message.
Sender:Fabien Herfray.
Date:Thursday, 13 August 2015 19:41:16 UTC+1.

Hi Fabien,

I feel that at some point you will need to tie your users to their respective tokens / policies.

Is your application going to be reacting to their current quota usage? If so, a call back to Tyk to retrieve this information is pretty unavoidable (it changes with every request).

If you don’t want to be tied to the portal, I would suggest caching the policy data/ID and the token information in your user service when you generate the tokens (they are, after all user-domain data, so if they belong anywhere, they should be there), and if you are generating the tokens using a REST call, you have a copy of the policy ID locally.

If you want to go all out, you could put the necessary information from the Tyk Session object on it’s way using a middleware JS plugin, since the token session is sent to the plugins, so you could pass the information on to your service and just extract the data from the headers.

Cheers,
Martin