Use mocking to embrace auth in your domain model from the outset

The OData Deep Dive mission is based around a cut-down version of the classic Northwind service called “Northbreeze”. That service is available in the repository https://github.com/SAP-samples/odata-dd-server and is a good basis for our exploration of the mocked authentication strategy in this tutorial.

👉 Clone the repository:

git clone https://github.com/SAP-samples/odata-dd-server

👉 Now open the northbreeze/ directory within the cloned repository in a new VS Code / Codespace window:

code odata-dd-server/northbreeze/

This should present just the Northbreeze project in the Explorer, at the root. Use the CAP Project Explorer feature to get a feel for the project’s service and entity definitions (you may need to use the Refresh button, in the form of a circular arrow, to get the explorer to re-read the project configuration):

Out of the box, the CDS model in this Northbreeze project comes with a single restriction on the Categories projection, in the form of a @readonly annotation - which exists as something to be examined in a different tutorial (Learn how to read annotations in OData metadata documents, part of the OData Deep Dive mission). We will ignore this for the purposes of this tutorial.

Talking of “out of the box”, the CAP server by default, in local development mode, uses the mocked authentication strategy.

👉 Check the detail of that, by looking at the effective configuration, specifically for the auth section:

cds env requires.auth

This should emit something like this:

{
  restrict_all_services: false,
  kind: 'mocked',
  users: {
    alice: { tenant: 't1', roles: [ 'admin' ] },
    bob: { tenant: 't1', roles: [ 'cds.ExtensionDeveloper' ] },
    carol: { tenant: 't1', roles: [ 'admin', 'cds.ExtensionDeveloper' ] },
    dave: { tenant: 't1', roles: [ 'admin' ], features: [] },
    erin: { tenant: 't2', roles: [ 'admin', 'cds.ExtensionDeveloper' ] },
    fred: { tenant: 't2', features: [ 'isbn' ] },
    me: { tenant: 't1', features: [ '*' ] },
    yves: { roles: [ 'internal-user' ] },
    '*': true
  },
  tenants: { t1: { features: [ 'isbn' ] }, t2: { features: '*' } }
}

👉 Observe:

• in this mode, there are no built-in restrictions on any of the services by default (see the blog post “CAP service authentication at design time and in production” for more on this)
• the authentication strategy (kind) is indeed “mocked”
• there are some sample users, with various tenant and role assignments, that we can use

👉 Start up a CAP server for this project with DEBUG=basic cds watch and observe the output, which should include:

[cds] - loaded model from 2 file(s):
 
  srv/main.cds
  db/schema.cds

[cds] - using bindings from: { registry: '~/.cds-services.json' }
[cds] - connect to db > sqlite { url: ':memory:' }
  > init from db/data/northbreeze-Suppliers.csv 
  > init from db/data/northbreeze-Products.csv 
  > init from db/data/northbreeze-Categories.csv 
/> successfully deployed to in-memory database. 

[cds] - using auth strategy { kind: 'mocked' }
[cds] - serving Main {
  at: [ '/northbreeze' ],
  decl: 'srv/main.cds:4'
}
[cds] - server listening on { url: 'http://localhost:4004' }

Note that use of the mocked authentication strategy is indeed announced.

The mocked authentication strategy is more or less just the basic authentication strategy, with these sample users, so we ask for debug level output for the basic module here (as there isn’t any specific mocked debug output).

In this step you’ll explore a couple of auth related aspects of the service as it stands right now.

👉 First, create a file Explore.http in a new directory test/ within the project root, with the following content:

@server=http://localhost:4004

### List first three products
GET {{server}}/northbreeze/Products?$top=3&$select=ProductName

### Delete product 1 (Chai)
DELETE {{server}}/northbreeze/Products/1

These are HTTP requests in a format that can be understood and executed by the REST Client extension for VS Code (and in Codespaces), an extension that is included in the set defined for the Dev Container that is in use here.

You can generate such HTTP requests in this format with the cds add http command too.

👉 Ensure that the CAP server is still running, and execute first the GET request, then the DELETE request, via the selectable “Send Request” text that appears above each one in the editor.

The GET request should return a 200 response with three products Chai, Chang and Aniseed Syrup. The DELETE request should return a 204 response with no content. If you were to execute the same GET request again, you would get the products Chang, Aniseed Syrup and Chef Anton’s Cajun Seasoning, as Chai (product with ID 1) is now gone.

Take a note of the implications here (again, ignoring the @readonly annotation for the Categories in srv/main.cds):

• we are able to access the service and resources within it without identifying ourselves (no authentication)
• we have full read-write access to the resources within the service (no authorization restrictions)

Let’s add a requirement for clients to identify themselves in the requests they send. In other words, add an authentication requirement.

Specify the pseudo-role authenticated-user as a requirement at the service level, by adding an annotation to srv/main.cds so it looks like this:

using northbreeze from '../db/schema';

@path    : '/northbreeze'
@requires: 'authenticated-user'
service Main {
  ...
}