0

We are currently in the process of building a service (a REST API) which is called on by our primary application. The primary application contains a users/permissions/roles set up which is used to verify if the user is able to complete tasks on the application. The user-roles relationship is one-to-many.

The third party API has various end points. We are now required to implement a roles/permissions type system for the endpoints. For example role A might be able to call a create/update endpoint but not destroy.

The question lies within where the roles/permissions should be stored and verified for the REST API service. We already have a roles/permissions set up on the primary application and adding finance specific roles to this set up seems like the wrong choice. It also means that the logic would not be contained on the REST API service so if we were to call the endpoints from other services later down the line this service would also require a roles/permission set up.

The question in general is

Should the roles/permissions tables and logic be stored on the REST API service (the REST API service) - I am almost certain this is the correct/best approach.

How to assign the API services roles/permissions to the users of the primary application. Maybe it requires the set up of additional tables that contain service specific roles (this still feels dirty as we would have two different places where users relate to the roles)

Another option is to have a roles_users table on the REST API service which relates the primary user ID to roles within the service.

Other considerations are that the primary application will need to check these permissions almost every page load to check if certain menu information should be displayed - we can obviously cache this information since it should not be changed often.

The framework is Laravel but I do not think this is relevant to the question. Included it just in case.

Improve this question

2 Answers 2

Reset to default
4

Put the permissions and authentication on a separate Auth service.

This checks the username/password and issues a signed token containing all the roles the user is in.

You microservices can then check the signature of the token against the public key and compare the users roles with the required role for the method they are calling.

The benefits of this approach are that

  • You have a single place which knows about users and roles. If a user needs a new role, or a new user is created you dont have to find each microservice that user will need and add the user to each.

  • Microservices don't have to call a central place to check roles. The roles are listed in the token which is sent with the request, and they have the public key for the auth service and are thus able to verify that the token isnt fake.

  • There are a few standard auth flows which use this principle such as O Auth, for which you can download various pre written libraries

Improve this answer
4
  • 1
    Is there any reason not to use Kerberos as the implementation of the auth service? Your descrption sounds like just what krb does, and reusing semi-standard tools seems like a good choice. Esp. for critical stuff like this.
    – kqr
    Nov 5, 2018 at 17:07
  • 1
    @kqr not to put words in Ewans keyboard, but him suggesting an Auth Service doesn’t seem to imply the auth service can’t be an off the self system. If it were me I would adopt an existing identity and access management service (which might use Kerberos or any number of other ticket granting protocols under the hood)
    – Paul
    Nov 5, 2018 at 17:12
  • I believe kerberos has a different flow, where the microserive will authenticate the user with the auth service. Its possible to use kerberos athough ive not done it myself. I think the main reason is complexity, but pass through 'double impersonation' and getting your client side java script to talk to kerberos servers are tricky. It would be good to see an answer from a kerberos expert on this
    – Ewan
    Nov 5, 2018 at 17:22
  • Thanks for the additional info ! I'll spend some time researching Kerberos as it is the first I have heard of this protocol.
    – Daniel Benzie
    Nov 6, 2018 at 11:26
0

Who is able to access this REST service? If the answer is, "only your application," then it may be perfectly justifiable for your service to simply trust its client.

But, if the REST service must obtain trust in order to successfully carry out one of its prescribed objectives, it may be necessary to (e.g.) create some kind of token that the client can hand to the service. That token, for instance, could be something that the back-end system will recognize to be a temporal identifier of the system-user who initiated all of this.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.