This is a template of a REST API application built with ObjectScript in InterSystems IRIS. It contains the example of unauthenticated and authenticated access to the persistent data via REST API. It demoes the creation of users, roles and how to grant the access.
Make sure you have git and Docker desktop installed.
zpm:USER>install dc-sample-rest
Create your repository from template.
Clone/git pull the repo into any local directory e.g. like it is shown below (here I show all the examples related to this repository, but I assume you have your own derived from the template):
$ git clone git@github.com:intersystems-community/secured-rest-api.git
Open the terminal in this directory and run:
$ docker-compose up -d --build
The template creates two REST API web Apps:
- unsecured /crudall with access from any user.
- and /crud REST web-application with basic authentication. Both REST API spec the same, have the same class-dispatcher and implement 4 types of communication: GET, POST, PUT and DELETE aka CRUD operations to read, write an delete from the database. These interface work with a sample persistent class dc.sample.rest.Person.
Open http://localhost:52773/swagger-ui/index.html to discover and test the REST API
The template also creates:
- 10 random records in dc.sample.rest.Person
- two roles: Reader with right to read records from dc.sample.rest.Person and Writer with right to add and alter.
- two users: Bill with Reader role and John with Writer role.
UnknownUser that represents the unauthenticated access has the Reader role. And we can test unsecure access with /crudall web app.
Open http://localhost:52773/crudall/persons/all to see the records from Person class in JSON, like this:
We see them because /crudall doesn't demand authentication according to this line in ZPM module
and thus the /crudall registers sign in of a UnknownUser which has a role Reader assigned in Security class.
Secured access in this demo expressed via deploying of two users Bill and John and Reader and Writer roles for the data access regulation. The regulation is implemented via role checking in the REST-API implementation calls: e.g. here for GET and PUT calls.
Open http://localhost:52773/crud/persons/all. You'll be prompted for the basic authenticatoin. Sign in with user Bill with ChangeMe password, that has Reader role. And you'll see the data as the Reader role is assigned to user Bill. Check also in another window or via request in Postman that if you sign in with user John you'll get 403 error back (Unauthorised access) as user John doesn't have role Reader.
PUT and POST requests can be tested on a http://localhost:52773/crud/persons/ call which we can test e.g. via Postman. The postman collection with calls can be found in the repo. Try the Update Person PUT call that will change the name of the first record to John Doe and will perform the call with Basic Authentication and John as a user. If you change the user to Bill you'll get 403 response.
Next steps for these demo could be the representation of API map in Open API (swagger) standard and implementation if a Bearer Authentication
Pull requests are very wellcome!