Experimental Physics and
Industrial Control System

Hello Heinz,

with NSLS-II Archiver Appliance in my care, I was for long concerned about how the full power of management API is available to anyone who knows where to look. With sample scripts usable by anyone, it is a completely feasible scenario when wrong PVs are added/deleted, or worse, data is wiped.

With that, a challenging list of requirements was composed to understand what we want from an Archiver Appliance "access control":

1) The retrieval engine should remain accessible to anyone from anywhere within the Controls network.
2) The solution should be applicable to any existing Appliance. We have many of those - the main Accelerator one, the secondary one, and every beamline has their own. We also want to accommodate Appliance updates easily.
3) The "read-only" API should remain accessible to anyone. It proves to be very handy when users of the service can check the status of their PVs before making an add/modify PV request.
4) The "write" API should be available only to a set of people, "Archiver Appliance Management". It should be easy to add "cognizant engineers" to that group so that they could handle PV addition/modification requests from users.

Additional requirements were derived along the way:

5) Since we opted to use the LDAP password auth, we needed to enable HTTPS for connections to the archiver.
6) Appliance engines (i.e. mgmt, etl...) should be able to talk to each other without any issues.
7) We want to have a single point of BPL write access to make sure no rogue scripts can run anywhere else.

Together with heavy involvement of our IT (thanks Mizuki, Leon) we evaluated different approaches to have all these requirements satisfied. A detailed description of what we eventually did may look fairly complex, but that is because SSL, LDAP, certificates, and Apache configuration are involved. In the end, it's only a modification/creation of very few files on Appliance mgmt engine side. Steps are:

1) Prepare a keystore file for encrypted port communications including user authentications. This keystore file is placed in mgmt/conf.
2)  Redirect default port (e.g. 17665) to SSL port 8443, enable encryption. This is done by configuring a connector in the Appliance mgmt/conf/server.xml file and pointing it to the keystore file created in step 1.
3) Configure the LDAP realm in the existing mgmt/conf/server.xml file to use our LDAP server.
4) In LDAP, create the "Appliance Management" user group.
5) Select an authorized management machine. Write access to bpl/* will only be allowed from there, and this machine only allows ssh for "Appliance Management" members.
6) Prepare special user-facing "status" pages. These are based on existing ui/index.html and ui/pvdetails.html with all management capacity removed. I also had to supply a modified version of existing ui/js/mgmt.js so that it used the new pages.
7) Configure urlRewriteFilter to allow all bpl/get* calls but deny any other /bpl/* calls unless the caller is from localhost (engines talking to each other) or an authorized management machine selected in step 5. We used urlrewritefilter-4.0.3 from Maven repo. The jar is simply dropped in mgmt/webapps/mgmt/WEB-INF/lib dir and a small rules file is created in mgmt/webapps/mgmt/WEB-INF dir.
8) Configure authentication and security constraints in the existing mgmt/webapps/mgmt/WEB-INF/web.xml file:
* Enable BASIC authentication. When accessing a protected resource, i.e. anything under ui/* except for special user-facing pages and anything under bpl/* except for bpl/get*, a dialog will pop up to ask for LDAP credentials.
* Restrict access to /ui/* pages to Appliance Management members only. These are users who belong to the LDAP group created in step 4.
* Give everyone access to the two special user-facing pages created in step 6.
* Submit all /bpl/* calls to urlRewriteFilter rules as set up in step 7.

As a result, the retrieval remains available to anyone (we didn't even touch it); users can check the status of PVs from anywhere; all BPL write calls are restricted to a special LDAP user group and can only happen from the special management machine.

Regards,
Anton.