Manage API Keys

[Łukasz Lewczyński]

Hi,

I am working on OLMIS-3135 / OLMIS-3784 to investigate if Spring OAuth could handle API keys somehow and because of that there will be less work to do by us.

For now I found two solutions to handle API keys by OpenLMIS:

1. Use access_token as a API key (most things are handled by Spring OAuth)

In this solution we will have a single entity in the reference data service - Service Account - which will contain fields like id, login and list of rights. The id field is required by database and the login field will be equal to access_token generated by the auth service which will be always valid (for now).

This solution if quite easy to introduce and don't required too much work from us.

The problem I found with this solution is how service endpoints should handle new request type. Currently we only check if a request was sent by other service or by the end user. Probably, we will need to add a new if statement to check if the request was sent by an external service.

Also here we mix the meaning of access token because in some requests it will be treated as an access token and a API key in the same time. I am not sure if this is safe and correct approach.

2. Use custom header / request parameter (Some part will use Spring OAuth)

This solution requires more coding staff because we will need to create entities in reference-data and auth services (similar to user entities in those services), a custom filter to handle our custom header / parameter, probably custom authentication provider, and maybe some other additional classes.

In this solution an external service will use our custom header / parameter (probably X-API-KEY header or api_key parameter) to authenticate itself so our filter will check if there is a correct entry in the auth service, generate access token and add it to the request. In this case the external service will be authenticated with each request but only if the access token is expired. The access token part will be handled by Spring OAuth. Also if there will be an access token and the custom header / property the token will have higher priority than custom header.

Like I said this solution requires more coding but it would be easier to check a type of request by service endpoints because the principal field in Authentication will contain different values for different request types:

• client id -> service request
• username -> user request
• service account -> external service request

Also in this solution we don't mix the meaning of access token. It will be always treated as an token that authenticate a user.

I would really like to hear what do you think about those propositions. If you think that there is a better approach which I don't see then please let me know.

Regards,

Lukasz

Łukasz Lewczyński
Software Developer
llewc...@soldevelo.com

SolDevelo Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

[Josh Zamor]

Hi Lukasz,

I certainly envisioned #1 and not #2.  Put another way, using access_token or the Authorization header field to transport OAuth Bearer tokens.  I don't think we should invent our own header fields or tokens here.

I agree that some additional checking would need to be added when checking the token - the kind of token we're interested in are closer to what we've called service-based tokens rather than user-based tokens.

I look forward to seeing how this design could be made elegant.  It's more than okay here to start small: we know that a first pass for these API tokens don't have options an administrator selects when creating them, it'll just be for certain CCE endpoints.  In the near future we'll get to identifying specific types of API tokens that will hopefully align with specific services.

Best,
Josh

[Łukasz Lewczyński]

Hi Josh,

Thanks for response, I will start working on solution #1. I think for now there is also one more problem with this solution. We will treat the API keys as a service-based tokens and currently all those tokens (if endpoint support it) have access to everything. I know in the future those tokens will have some roles/rights assigned so the problem will be resolved in the future.

Regards,

Lukasz

Łukasz Lewczyński
Software Developer
llewc...@soldevelo.com

--
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.
To post to this group, send email to openlm...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/b676d308-e4ae-4f17-ac65-f5a9c4fcd370%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Josh Zamor]

Hi Lukasz,

I’m not sure I follow.  I’m not suggesting that this api token give access to everything.  Just the places that accept it.  This may require some work to clarify service tokens.  I think you’ll need to advise us with how best the current structure should be amended in the service code.  I wanted you to be reassured that we do in fact want to use OAuth2 bearer tokens.

Best,

Josh

[Łukasz Lewczyński]

Hi Josh,

I described the problem on the slack channel and in the end to find out if the authentication should be treated as service level request it should have client id equals to the value which is in the auth.server.clientId property from the application.properties. As part of the work I will block access to the all endpoints that check if user has right to call an endpoint with parameters. Is that sound okay for you?

Regards,

Lukasz

Łukasz Lewczyński
Software Developer
llewc...@soldevelo.com

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/1A011DE8-2B66-47CD-BFAC-8C70FDEC2E1F%40villagereach.org.

For more options, visit https://groups.google.com/d/optout.

[Paweł Albecki]

Hi all,

Regarding checking if client id equals to the value which is in the auth.server.clientId property, is it safe to assume that there will be only one "trusted client" for service-based token?

Best regards,

Paweł

 

 

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/CAAdp53xyDVasDNKTyJE%2BgQJwo8M6oAcuKhSuDN7fUaD8K6Hchw%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Paweł Albecki
Software Developer
palb...@soldevelo.com