Design notes.

[cgcgbcbc]

Use koa or express for handling routes, use es6 rest syntax.

Use middleware passport and passport-local-mongoose for fetching user info.

[cgcgbcbc]

koa's response and request objects are not compatible with node's native ones, so that koa may not be a choice unless abandon node-http-proxy.

Another difficulty is that if the resources are not under user namespace, e.g.

/user/someuser/posts/xxx
/posts/xxx

For authentication for these requests, there are two methods to use:

1. do not validate at all, and add a header field X-xxx-user, pass the request to the backend.
2. add backend url in config for these complex requests.

[cgcgbcbc]

http://wiki.openiam.com/display/IAMSUITEV3/Single+Sign-on+to+Web+Applications+Using+the+Reverse+Proxy

[cgcgbcbc]

Another approach is add complex logic in the gateway. This requires we implements mu-gateway as a library. This may be helpful if we want to add A&A for legacy systems without A&A, for example, the open source docker registry, consul, and so on.
Then the benefits of this project is that it will provided a single reusable passport system across all the services.

[cgcgbcbc]

The third method is implement database plugin for common databases like mysql, mongo or postgre, and response for A&A query.

[cgcgbcbc]

The function we need can be decoupled as three independent micro-service:

1. authentication service:

   Authenticate who the user is, an oAuth2 service may work.

2. authorization service:

   • Scope: under which application the authorization info is.
   • Register: register resources for user
   • Authorise: authorise whether the user has access to the resource

3. gateway (reverse proxy):

   • ask the authentication service who the request user is.
   • ask the authorization service if the user has access to the resource under given scope.
   • deny or proxy request to the given service

How does this architecture work together with other service? Typically we only need to solve CRUD.

1. Create
   • take create action as a resource.
   • a & a & gateway service have validated the request.
   • the backend service create the resource arbitrary, without validation.
   • if the created resource is not a user, grant correct access right to the resource (e.g. write: some user, read: anyone)
   • if the created resource is a user, no, you shouldn't do that. Leave the user management to authentication service.
   • register the create action resource under some group of users.
2. Read
   • return the queried resources arbitrary
3. Update
   • update resources arbitrary
4. Delete
   • delete resources arbitrary