14 November 2018 Wednesday

DominoDB and a big NO-NO !

So folks,

the beta of DominoDB is out and people are starting to use it.
One of my early-adopting customers started to play around with it and started to create a React.-based application using DominoDb to modify database content. They secured their Proton task using the SSL encryption. So far so good. What I did not expect was the flaw in the architecture of the app that I came across when I looked at the source.-
The guys where using DominoDb right from the React App IN THE CLIENT APP ITSELF. The next pictures illustrates what I mean by that:

Image:DominoDB and a big NO-NO !
For testing, they opened their firewall at the proton port and are now communicating via SSL from the browser directly to the proton task on the server. While this is working, for me as a solution architect, this is a big NO-NO as you expose your client access keys and encryption keys in an end-user application as well as the server address for your proton task, name of the database etc. DO NOT DO THIS !!!!

From my perspective, DominoDB is always sitting on a server. Period. It is ment to be sitting behind a REST-Facade that hides the application and server access part from the end user. So my quick redraw of the architecture would look like this:

Image:DominoDB and a big NO-NO !

So the Client Browser only talks to the reverse proxy which then accesses resources on Domino (Xpages or whatever) or a Node/Express based REST-API that takes care of the Domino related tasks using DominoDB.

I wasn't prepared to having to write this up as it seemed logical to me but maybe it's better to write it down, eh ?!

Have your say....

Heiko.
Heiko Voigt   |   14 November 2018 16:38:29   |    Domino 10  #dominoforever  react  node.js    |  
  |   Next Document   |   Previous Document

Discussion for this entry is now closed.

Comments (12)

Peter Stark       14.11.2018 16:56:08

Thanks for clarifying this. Seems obvious but I did not see anyone talking about an architecture for the usage of dominodb. Seems time someone started this !

Rami Jundi       15.11.2018 2:29:17

I am a little confused I guess. Did they bypass the node module which I presume is a wrapper to communicate with Proton and use another method in React?

Tinus Riyanto       15.11.2018 3:13:22

The Domino DB package seemed to assume that you already have a separate node.js environment. But what if you did not have one and/or have no intention to built another environment simply to run your node js application ?

Sven Hasselbach    http://blog.hasselba.ch    15.11.2018 8:38:35

Sorry, but I have a different opinion.

The client certificates for the domino-db driver are just the user credentials for the backend user on Domino. The access is still limited to the rights the backend user has.

You are loosing the benefits of a performance optimized server-to-server protocol and scalability is more complicated.

In most environments of my customers installing a Node.JS server on top of the Domino server is a no-go.

The port should be limited to the IPs of the client app machines, and exposing the database name is normal for Domino (just look at the URL of your blog).

So what are you winning with this architecture? The REST API still needs user credentials which have to be stored in the client application. The only benefit is that you have better control about the possible actions (based on your REST API).

Heiko Voigt    http://www.sit.de    15.11.2018 9:18:59

Hi Sven,

I disagree. The client app needs to authenticate against the Node environment not against Domino/Proton. The node instance can of course run on a separate machine/vm/container and currently acts as a proxy to the dbs. The client app will never ever see the certificates and keys. Personalization has to be implemented in the node environment for now. This might change with the OAuth part but we still will probably have to traverse Node users to Domino users somehow. Of course this limits the use of reader/author fields but iI guess from my discussions with HCL/IBM that this is intended for now.

Or are you saying to create client keys for each user ? I don't think that is the intended use case... . Giving the certificates out to the client is giving your notes.id AND your password away and letting someone from outside know where your server is. Who would do that in Notes ? Exposing Dbs and such was necessary before dominodb. We don't have to do that anymore so why do it ? Node/Express and dominodb are supposed to work in internet/cloud environments so I don't even think limiting access to a port for ip adresses is a viable option. In my architecture I'm only talking https to the client using a reverse proxy - no gRPC outside of my server landscape. The downside is I have to traverse Node/Express users to Domino users - I normally do this via LDAP authentication from node/express against domino. So far I can't solve the issue with reader/author fields which is indeed a downside. But at least I do not have to expose authentication and access to a publicly used client app. And that was my goal.

Heiko Voigt    http://www.sit.de    15.11.2018 9:53:23

Tinus,

for me, having the certificates and client keys in a (public) client app is like giving away your Notes.ID and your Password (!) to a possibly uncontrolled environment. Who would do this in Notes today ? Nobody I guess. If you want to do that - fine. I'm just saying that you have to be aware of what you are doing and think about the consequences.

Sven Hasselbach    http://blog.hasselba.ch    15.11.2018 9:59:14

Why should the client app not "see" the client certificates? These are just the user credentials. So where is the problem here? Your post didn't gave an answer to this...

And that the complete user authentication is currently not in the beta makes the whole domino-db package obsolete - we still need the information which user is making the request to Domino, a technical user is not enough. This kills the existing security mechanisms we have for decades. By adding a additional layer with the REST API/Reverse Proxy this problem is not solved.

From architectual standpoint: The Domino server has no clue who has sent a request, and it does not matter if the application communicating via gRPC is running before a proxy or not. The incoming gRPC request comes from an insecure source.

The open questions is: How can we ensure that the Request was made by User A? At the moment it is impossible, even creating keys for every user would not solve this issue (the client application still has the keys, so Domino has no clue if a request was authorized from User A or not).

The domino-db package was created like a typical web development setup. One database driver with a single technical user, and the application handles the user authentication. And these details must be stored in the application, in form of user/password or certificates.

P.S.

Exposing the database name was also not neccessary - a reverse proxy could easly handle this.

Heiko Voigt    http://www.sit.de    15.11.2018 10:11:04

Hi Sven,

I agree that in the current beta teh security model is missing - I'm not stating anything else. Yes, currently it is a technical user with no personalized access whatsoever. That's why I try to map users via LDAP login so I can at least somehow be sure who made the request. I have to do my CRUD operations with a different user but I know that the client user is authenticated against domino and who it is. In my chart, the gRPC call comes from one of my servers and can only be issued by an authenticated client request against the API not by someone having the certificates/keys and talking directly to my proton task without my knowledge. The proton port is not exposed to the outside world. And I will not be storing user credentials in a client app, in this usecase the user has to authenticate via logoin against LDAP. From the LDAP login I get a user object and the app will receive an access token to talk to the api which then let's me know who authenticated the calls. Access Tokens invalidate after e.g. 15 minutes and have to be renewed by the client app as needed.

You're right of course - we can hide paths/dbs from urls via reverse proxies today.

John Detterline       15.11.2018 16:34:33

I have to agree with Heiko, that the original configuration is less than desirable. I understand there may be environment constraints that prevent the addition of a new Node server, but designing the app to bypass the reverse proxy defeats the primary purpose of having the reverse proxy in the first place. It's been a while since I've played with Nginx, but couldn't you create a rule in Nginx to redirect certain URLs to the Proton port? That would help isolate the Domino server from the client. One temporary method you might try depending on your overall configuration is the Websphere headers option. That would allow you to include the authenticated Notes name in the http header of the request. Not an ideal method, but it should let you build a React app that access Domino data with readers/authors fields.

John Detterline       15.11.2018 16:47:28

Forgot to mention that I created a Node app that performed a Domino login using name and password provided by the user. The Domino server was set up to allow http/s web authentication so I was able to create an authenticated session and retrieve the DomAuthSessId cookie. Once I created that cookie in the browser, I was able to request other pages as an authenticated Domino user.

Dan Dumont       15.11.2018 17:56:09

Thank you! This is great to point out. Please do not use domino-db from the web!

Sven Hasselbach    http://blog.hasselba.ch    16.11.2018 15:02:27

@John Detterline:

1. nginx can do that. See here: https://www.nginx.com/blog/nginx-1-13-10-grpc/

2. Did I understand you right that you are tunneling username / password through your node.js application?

@Dan Dumont:

Why not? I am interested to hear a reason for you concerns.