19

For example, I have 3 services:

  • Authentication
  • Seller
  • Buyer

Each of them got their own databases, models, services... etc

Authentication service knows about users, user-groups, roles, permissions and creates token.

Where should I store sellers/buyers entities? On Authentication service, or on Seller/Buyer services?

How should Seller/Buyer services interact to create new seller/buyer entity?

How should Seller/Buyer services check permissions?

Seller and Buyer entities have some common fields: name, password, email..., but also each of them have their own additional fields.

Seller and Buyer interact with each other.

i.van
  • 776
  • 2
  • 8
  • 20
  • How do users differ from employees and bosses? Are users just a generic category for employees and bosses? – Will C Feb 13 '16 at 16:17
  • They have some common fields (email, phone....) but each of them have also their own additional fields – i.van Feb 13 '16 at 19:37
  • Just so I understand the problem domain, why do you need the boss service? It seems a little redundant since a boss is also an employee. – Will C Feb 14 '16 at 01:54
  • It was just a bad example. Let it be Employee and Cars or something else – i.van Feb 14 '16 at 15:29
  • I would update your question to reflect your comment. I would help you edit it but bringing this domain service in different ways could change your original question. For example, cars belonging to an employee or cars being something completely orthogonal to employees. If you could do that in clearer terms, I'm happy to try and answer your question. – Will C Feb 14 '16 at 19:08
  • I changed it, hope it is clearer now – i.van Feb 14 '16 at 20:27
  • Its a little clearer but I think we would still have to make the assumption on how the "seller" interacts with a "buyer". The two entities could be completely orthogonal. Would the seller be interacting with the buyer through a potential "product" entity? – Will C Feb 14 '16 at 23:48
  • They will interact like "firendship" on facebook. One can add another. – i.van Feb 15 '16 at 06:45

1 Answers1

14

This sounds familiar to a problem I was solving recently

Assuming your services are HTTP based, then I would recommend you check out oAuth 2.0

A short copy from RFC 6749

OAuth addresses these issues by introducing an authorization layer and separating the role of the client from that of the resource owner. In OAuth, the client requests access to resources controlled by the resource owner and hosted by the resource server, and is issued a different set of credentials than those of the resource owner.

Instead of using the resource owner's credentials to access protected resources, the client obtains an access token -- a string denoting a specific scope, lifetime, and other access attributes. Access tokens are issued to third-party clients by an authorization server with the approval of the resource owner. The client uses the access token to access the protected resources hosted by the resource server.

For example, an end-user (resource owner) can grant a printing service (client) access to her protected photos stored at a photo- sharing service (resource server), without sharing her username and password with the printing service. Instead, she authenticates directly with a server trusted by the photo-sharing service (authorization server), which issues the printing service delegation- specific credentials (access token).

It simply models the authentication and authorization into a workflow between

A User

  • Owns some data, hence it is also called Resource Owner
  • Has credential(s)

Authorization Server

  • Owns and Controls the User Identity, Credentials, and Claims
  • Controls granting & denying access to User's resources (not really required in this scenario)
  • Exchanges a user's credentials for an access_token that a Client can then use to access information from a Resource Provider
  • Optionally grants a refresh_token that can be used to renew an expired access_token

Resource Provider(s)

  • Service that has information
  • Trusts the Authorization Server
  • Verify access_token is valid (has not expired, signed correctly, etc.)
  • Verify required claims are present (user, roles, etc)
  • And Release information to a requesting Client

Client(s)

  • An Application (internal or 3rd party)
  • Authenticates the user via the known authorization server
  • Obtains an access_token
  • Uses the access_token to call resource provider(s) to obtain information

Claims Identity

A Claims Identity (explained better in more details here) is not just a username & password, it can carry many claims such as an email, a date of birth, etc. for an authenticated user, and you can use those claims to communicate any common user properties to your various services.

Shared Attributes

Now, your last questions was about linking a user (or an identity) to an entity in each service that represents some unique information in that service's context... this can be achieved by linking an existing authenticated identity and access_token to an internal representation of the user in each service.

Something like:

  • A Seller Is a User
  • A Buyer Is a User
  • A User has (Claims, access_token)
  • A Claim is a key value pair
  • A Claim can be (name, email, role, ... etc)
Community
  • 1
  • 1
Bishoy
  • 3,915
  • 29
  • 37
  • Very useful, thanks! After the user is authenticated and holds a token, does every request goes through some proxy to decode the token or is it being decoded on every resource provider with the same private key? I mean, how could difference resource providers (microservices) read the decoded token? Do they all know the private key or some proxy/authorization service decodes the token and the request continues to the backend decoded? – Korenz Jul 15 '20 at 09:02
  • @Korenz they only need the public key to decide the token and if you’re using JWT, then deciding the token is very easy and supported by many open source libraries – Bishoy Jul 15 '20 at 09:08