You can integrate your solutions with Ditto
- via the HTTP API or
- via WebSocket.
On all APIs Ditto protects functionality and data by using
- Authentication to make sure the requester is the one she claims to be,
- Authorization to make sure the requester is allowed to see, use or change the information he wants to access.
Authentication
User authentication at the HTTP API
A user who calls the HTTP API can be authenticated using two mechanisms:
- Pre-authentication by an HTTP reverse proxy in front of Ditto, e.g. doing HTTP BASIC Authentication by providing username and password as documented in the installation/operation guide.
- A JWT issued by Google or other OpenID Connect providers as documented in the installation/operation guide.
Authorization
Authorization is implemented with an ACL (in API version 1) or a Policy (in API version 2).
Please find details at ACL and Policies.
Authorization Context in DevOps Commands
An authorizationContext which is passed to DevOps Commands needs
to be a subject known to Ditto’s authentication. In the simplest case, it’s nginx:{username} where {username} is a user
that is configured for basic auth in the included nginx’s nginx.htpasswd file (where the nginx: prefix comes from).
If you are using the provided docker quickstart example from Getting Started you
can simply use nginx:ditto, then the commands that are passed from the connection are executed as if they
were issued via HTTP from the user ditto.