wissel.net

Usability - Productivity - Business - The web - Singapore & Twins

Serving Single Page Applications with Domino


Single Page Applications (SPA) are all the rage. They get developed with AngularJS, ReactJS or {insert-your-framework-of-choice}. Those share a few communialities:
  • the application is served by a static web server
  • data is provided via an API, typically reading/writing JSON via REST or graph
  • authentication is often long lasting (remember me...) based on JWT
  • authentication is highly flexible: login with {facebook|google|linkedin|twitter} or a corporate account. Increasingly 2 factor authentication is used (especially in Europe)
How does Domino fit into the picture with its integrated http stack, authentication and database? The answer isn't very straight forward. Bundling components creates ease of administration, but carries the risk that new technologies are implemented late (or not at all). For anything internet facing that's quite some risk. So here is what I would do:
Red/Green Zone layout for Domino
The main rationale for this approach is a best in breed selection of components separated by firewall components. In detail:
  • The front facing machine is a NGINX http server. I would configure it to support http/2, PageSpeed and Certbot. All calls to http would get redirected to https provided by LetsEncrypt (or buy your own). Running in a VM or a Container I would wipe it from time to time (daily), so anything that might have established a foothold dies then
  • The http server would contain the SPA with proper manifest and http expiry headers. That makes delivery fast and saves server resources up the chain. Deployment would be bound to the VM/Container creation process, so the http server would be mainly readonly
  • The authProxy would be a NodeJS application using the PassportJS framework. It offers an unparalleled selection of more than 300 ways to authenticate. The identified user then can be passed on to Domino. In addition some URL sanitisation could be performed. Since only API calls would land there, checking them for plausibility can be done cheap and easy
  • The Domino server's role is the provision of API access powered by its NoSQL NSF store. If so choosen its LDAP could serve as the identity source for the passport authentication
Who is member of the green or red zone is subject to debate, so you might want to go with a different approach like the one below.
Alternate layout for Domino SPA
As usual: YMMV

Posted by on 2017-01-11 04:14 | Comments (3) | categories: IBM Notes XPages

Comments

  1. posted by Michael Bourak on Thursday 12 January 2017 AD - 00:36 Singapore Time:
    Can you pass the NodeJS Passeport user to Domino and have this user authentified on Domino (including Reader / Author fields and so on ?)
    If so, how can you do that ? (Specific HTTP Header for IHS/Was plugin, other)

    Thanks
  2. posted by Stephan H. Wissel on Thursday 12 January 2017 AD - 01:18 Singapore Time:
    @Michael: Yes you can using HTTP Headers and the HTTPEnableConnectorHeaders notes.ini variable.

    Reader/Author fields have nothing to do with AUTHENTICATION. They are a matter of (document level) AUTHORIZATION which happens after the user is identified. Authorization is generally oblivious about the way authentication has happened.

    Kind of: As long as I know who you are, no matter how I found out, I can tell what you are allowed to do.
  3. posted by Nathan T Freeman on Thursday 26 January 2017 AD - 12:58 Singapore Time:
    You'll find that people working on variants of this idea, including CrossWorlds, use the ODA to ensure that sessions for the API layer have the identity requested by the AuthProxy.

    This principle alone would make me choose to put the AuthProxy in the Green Zone.