Domino App Dev Pack: Understanding Scopes

One of the aspects of the app dev pack yet to fully coalesce is the concept of scopes. But I think it will be key to the future, as an app dev and admin tool. It’s certainly something that will not be familiar to those who have never stepped beyond Domino.

First off, if all your application is focused on is Client access or traditional web options, scopes will be irrelevant. “Hide-from” settings on design elements are used to restrict availability of certain design elements from client or web. And there is only one “application” that accesses the application via nRPC (client) or HTTP/S (web) – the one you design. Scopes are really only relevant when multiple interfaces access the application over a single protocol.

Let’s just recap on what’s available for managing access to Domino data:

• ACL levels – Manager, Editor, Author etc. These can be further restricted via the “Maximum Internet Name & Password” setting, which can downgrade the access available for non-HTTP/S protocols.
• Roles. These can be used to restrict access to particular design elements or navigation options.
• Server settings. These include preventing HTTP access, restricting or allowing DAS / DDS or other custom data services. These will be configured server-wide in configuration.

As Dan Dumont confirmed at Engage in response to my question, scopes will work alongside these additional settings, to refine access still further. Scopes were something I came across with Watson Workspace, although the scopes available were always the same via the Workspace Workspace APIs. Presumably different scopes were available internally though. Scopes make a lot of sense when your application is API-first and built in a microservices approach, where your “official” user interface is just one implementation and you want others to access the same APIs via different application interfaces. This is why it’s not relevant to Client or traditional web applications, because they aren’t built around APIs intended to be called from multiple interfaces. So restricting what APIs are available requires you to change the way the application is built in order to leverage them. And if you want to have REST access to a client application, you may refactor some code, but the entry point for Client and REST will be different, so can be handled differently. Even with REST services on an XPage, they’re not typically intended to be called from outside the XPage.

In a Node.js world it may be possible that you only ever allow one client certificate and only allow domino-db access from your internal official applications. You may choose to expose a separate API gateway on Node-RED or whatever, in which case you will handle in code any external access. However, your official JavaScript application (React, Vue, Angular, whatever) will be calling REST endpoints or making DQL calls that may also intended for use by external applications. Firstly, there are two levels of access if you’re using IAM – the Domino user who has authorised the application and the application itself (which is also mapped to a Domino user). This is where scopes come in, because the access should be an intersection of the access for the Domino user and the application user. A user may have Editor access but an application – a particular implementation – may be intended to only read data on the Domino user’s behalf, or only be able to create certain types of documents. Scopes can be used to differentiate between official applications and one or more external application. Indeed the database owner may want to allow different external applications different scopes of access. In the case of a CRM, for example, the official application may want to be able to do everything, but external application A should only read companies, external application B should only read companies and contacts, external application C should be able to create sales leads etc. Indeed, even in internal-0nly, you may want a separate admin application to be able to update keywords via DQL while allowing the typical end-user application to only read them.

It may be possible to handle that with roles that are only defined against application users and not Domino users, but when they’re on both, roles and user access levels and an aggregation of all, not an intersection. JavaScript developers may prefer scopes, because it makes more sense outside of Domino development, avoid some of the limitations of roles and typically have more developer-friendly names. If you start to integrate all of them – access, roles and scopes – you start to get a very powerful but admittedly complicated degree of granularity.

It’s going to require a new interface – definitely via API, possibly editable only via API or console command, but with some interface to report on it. It would probably make sense to be stored alongside the ACL, because it’s specific to the database and user. And the scopes itself make sense to be stored in the database design, because they will be relevant to any implementation. Of course it’s totally valid for database design is managed fully through an API – the database(s) created on-the-fly as needed during runtime, upgraded as required via code too. That’s what I did for the ToDo applications in my IBM Think 2018 session with John Jardin. And scopes have also been manually coded in the past by, for example, requiring additional keys for use of certain endpoints, preventing them from being initialised outside of dev or test environment etc. It’s still early days, and the actual requirements are still being defined, as developers start to come to grips with different requirements for their applications and different ways of building the applications.