Using public claims with JWT/KONG

[ksac...@gmail.com]

down votefavorite

I went through this tutorial on KONG https://getkong.org/plugins/jwt/ I have an understanding of JWT and authorization concepts. I have prototyped JWT with Spring Boot where I could put my own key value like this {"authorizations":"role_admin, role_user"}. It is easy to do that in Spring Boot but I am not able to find information on how to do this with KONG. Anyone has any info about it? Basically, I want to add my own authorization list and then decide if the api that is being accessed by the consumer, if the consumer has any or all of those authorizations

[ksac...@gmail.com]

Can anyone help on this?

[ksac...@gmail.com]

Trying again, any pointers on this?

[konrad....@infrasightlabs.com]

I have a similar situation but we add the roles "admin", "service_x.read", "service_y.write" in our own JWT key "roles".

Would be great if consumer object in Kong would support adding extra fields that later could be checked/enforced by ACL plugin to separate authentication with authorization.

Example:

request -> jwt plugin (decodes JWT and extracts "roles" to customer.roles) -> acl plugin (checks that customer.roles contains "admin")

[ksac...@gmail.com]

Hi Konrad:

Thanks for the reply. I guess you and I have similar thoughts on this. First a bit about ACL plugin. The plugin is not so granular as you have also felt. It is something along the lines of saying if the API and the consumer are in same ACL group, let the API be routed. Is that right?

Secondly, I am thinking on taking the similar approach where I have an authentication service, that will get the consumer secret from Kong, cache it, and then use that to create JWT with any custom payload that I want. Eventually, when Client puts such token back to access the resource, the right resource end point must do whatever it wants with the roles and token. Is that right? Of course I still do token validation at Kong layer as it allows that anyways( to verify the authenticity/validity of the token)

[konrad....@infrasightlabs.com]

My scenario is that we have a separate auth service (could be outside Kong request path) where user first authenticate and gets a JWT token back with a extra/custom claim: "roles": ["role_a", "role_b"]

The user then use this token when accessing our various APIs and only get access to the APIs we have specified for each role user has.

Ideally the web gateway / reverse proxy (Kong) should help with the initial validation of token (check that it's signed by our auth service and that it hasn't expired) and also enforce basic access control (allowed/denied) to for each API based on the roles in the decoded token.

The token also gets sent along with upstream API requests so backend service for each API can do additional access control (if they require).

What I'm a bit unsure of is how to best handle the following in Kong:

* Extract roles in custom claim in JWT and pass it along to later plugins (like ACL)

* Get ACL plugin to restrict access based on roles

I don't want to have to keep list of consumers in Kong in sync with our normal user directory but I'm not sure if Kong supports creating a consumer object on-the-fly without it already existing in the database.

Right now I'm trying to write my own Kong plugin that decodes JWT and extracts roles and it works but I still have enforcing of access based on roles left to figure out.

Might end up writing my own ACL-plugin for that as well.

[ksac...@gmail.com]

I guess you and I are talking about almost the same thing. From your initial reply it felt you have been able to integrate your custom roles with Kong ACLS. I thought so because of this line of yours in the reply - "Example:

request -> jwt plugin (decodes JWT and extracts "roles" to customer.roles) -> acl plugin (checks that customer.roles contains "admin")"

I guess you are not using ACLs either. Are you using them or not? My requirement is very similar to yours. Here is the flow I am trying to stick with, are you doing the same or you have better suggestions or any other proposal?

1. I have a separate Authentication service. What it does is, it gets the consumer/user info - the secret, etc from Kong and uses it to generate JWT when a login request comes. This login request can be routed via kong or it can be left out of Kong, does not matter. But if it comes via kong, you get free load balancing if u deploy multiple instances of it. However, the job of this service is to just generate a token.

2. The client recvs this token and calls the actual API that is routed by Kong. Before being routed, Kong merely verifies if JWT is genuine using the same consumer secret which separate Auth service had used to generate JWT. If fine, Kong routes it to the actual service.

3. The actual service can parse the token which when was generated had all the custom claims/roles which now the service can use to do whatever it wants.

That is the flow I am trying to go with. Do you have a different suggestion of this is what you also meant?

[konrad....@infrasightlabs.com]

I haven't managed to integrate with Kong ACL yet.

The flow I wrote was what I wanted to do but I'm not sure it's possible with existing plugins in Kong.

Your flow is very similar to ours except we don't keep our users stored as consumers in Kong.

Our Auth service fetch user information from separate user directory/database and I felt syncing them all with consumer records in Kong is too complex and unnecessary duplication of user data.

Ignoring that difference then we're looking at the exact same flow.

If I get my own implementation of JWT plugin and ACL plugin to work it might help you too.

You're problem would still be how to store what roles each user has assigned (I don't think the consumer object in Kong supports that).

[ksac...@gmail.com]

Konrad:

This is a useful discussion. Good exchange of points. Few things:

1. The ACL flow which you said would be nice to exist is what I believe so too. This would have been a good open source project for me to contribute to :). I hope plugin will come with long term support. It will be a good plugin to have.

2. I guess if you have skipped creating a consumer in Kong, I would want to know that does Kong in your case participate in JWT validation at all or not?

3. When I played with Kong, I realized that if I want Kong to at least verify the signature of JWT, I had to create a consumer and use the secrets of the consumer to verify the token signature at Kong layer. If token is not tampered with, Kong will just relay the request further down. If token signature seems invalid, Kong sends 401, etc in that case and does not even let the call go further. I think in your case, you just use Kong for plain routing of the APIs and Kong does not participate in verifying the JWT signature either and the service does that. Is that how it is?

thanks

[konrad....@infrasightlabs.com]

On Wednesday, 22 March 2017 15:16:17 UTC+1, ksac...@gmail.com wrote:

Konrad:

This is a useful discussion. Good exchange of points. Few things:

1. The ACL flow which you said would be nice to exist is what I believe so too. This would have been a good open source project for me to contribute to :). I hope plugin will come with long term support. It will be a good plugin to have.

I'm not a Lua expert so writing my proposed plugins isn't super fast for me. If I do get them up to a decent level I'll consider open sourcing them.

Any long term support for them would probably only happen if they get adopted by the Kong team.

2. I guess if you have skipped creating a consumer in Kong, I would want to know that does Kong in your case participate in JWT validation at all or not?

Yes, my own jwt-plugin does the validation of JWT in Kong.

 

3. When I played with Kong, I realized that if I want Kong to at least verify the signature of JWT, I had to create a consumer and use the secrets of the consumer to verify the token signature at Kong layer. If token is not tampered with, Kong will just relay the request further down. If token signature seems invalid, Kong sends 401, etc in that case and does not even let the call go further. I think in your case, you just use Kong for plain routing of the APIs and Kong does not participate in verifying the JWT signature either and the service does that. Is that how it is?

I found two things in Kong's authentication model a bit suboptimal:

1) Having to store all my users as consumer-entries in Kong is a lot of sync work and duplicate data if you already have your users in another system/directory.

2) Having a separate JWT secret key for each user kind of defeats the idea of JWT being stateless.

My idea of working around these in Kong is to build my own two Kong plugins:

1) A authentication plugin that is configured with one JWT secret key (same as my auth service uses) and validates all incoming tokens with that and extracts roles.

2) A authorization plugins that is configured for each API where I specify which role(s) a user needs to have to be able to access

This would not make use of consumer at all in Kong and therefore not require adding consumers and individual secrets for them.

It would be up to others if they want to use both plugins or maybe just the first (if they don't care about enforcing role based access control per API).

[Barry Kaplan]

Konrad, what you are doing is exactly what we need. Just started looking at kong and the existing jwt plugins. The code is clean and well tested, but not at all like how we jwt.

[dkav...@gmail.com]

Konrad hi,

Have you come to a point to share / decide to share?

[konrad....@infrasightlabs.com]

Hi Barry,

This got on hold on my side since I last posted but I'm about to dig into it again now when some other fixes (SSL for upstream) is also fixed in Kong.

Have you seen anybody else trying to do anything similar?