Security¶
Security for API Node administration API¶
The API node administration API can only be queried through administrative API keys.
API node administrative API keys are managed by the ./bin/apinode-admin tool (see Using the apinode-admin tool for more information).
./bin/apinode-admin admin-key-create
./bin/apinode-admin admin-keys-list
./bin/apinode-admin admin-key-delete KEY
Each API key has full administrative permissions; the API node does not have fine-grained administrative privileges.
Permissions for API Deployer¶
The API deployer offers per-group permissions on Published API Services and Infrastructures.
There are no permissions on the deployments:
You may read details of a deployment if you have “read” permission on both the service and the infrastructure
You may create a new deployment if you have “deploy” permission on both the service and the infrastructure
This gives a large amount of flexibility for implementing:
A system where some API services are “public” while some are restricted even from viewing
A system where data scientists may deploy any API service to development and testing infrastructures, but only a small set of devops may deploy to the production infrastructure
Infrastructures¶
Infrastructures may only be initially created by global DSS administrators.
Once an infrastructure is created, an arbitrary number of groups may be granted access with the following privileges:
View: view this infrastructure, view associated deployments (if you also have Read permission on the service)
Deploy: use this infrastructure to create deployments, update, enable/disable deployments on this infrastructure, manage their settings (if you also have Deploy permission on the service)
Admin: manage infrastructure settings, including managing permissions
To manage infrastructure privileges, go to API Deployer > Infrastructure > Settings > Permissions.
Services¶
Services may be created by any user who has the global “Create API Service” privilege (this is handled at the Group level, see Main project permissions).
The user who creates the service is automatically assigned as “Owner” of the service, which grants full access to the service.
The owner, or any group who has “Admin” privilege on the service, can grant access to an arbitrary number of groups with the following privileges:
Read: view this service, view associated deployments (if you also have Read permission on the infrastructure) - Note that this gives the ability to see API keys for the service
Write: manage versions of this service (upload, delete)
Deploy: create new deployments of this service, update, enable/disable deployments of this service, manage their settings (if you also have Deploy permission on the infrastructure)
Admin: manage service settings, including managing permissions and deleting service
To manage service privileges, go to API Deployer > API Services > Settings > Permissions.
Without API Deployer¶
When not using API Deployer, security is configured at design time, in the DSS Design node:
From the Service page, go to the Security > Authorization tab
Select the authorization method of your choice.
When you create the package, the authorization settings are packaged with it, and when you activate the deployment in the API Nodes, they are propagated.
With API Deployer¶
When using API Deployer, in addition to the method mentioned above (defining the authorization method at design time), you can also set security on a per-deployment basis.
This allows you to have different authorization method settings, like different API keys, for development and production deployments of the same API Service.
Go to Deployment > Settings > Authorization
Select whether you want to use the security settings defined in the API Designer, or override them for this deployment
When choosing the authorization method API keys, the API Deployer screen and sample code will show the first API Key, but all API keys will work similarly.
Your POST requests will now require an additional user parameter. For example, it will look something like:
curl -X POST --header 'Authorization: Bearer 1234APIKEY56789' \
URL \
--data '{
"key": "value"
}'
Send requests to an API protected with JWT/OAuth2¶
Once you have setup the JWT/OAuth2 authorization method, you will need to retrieve a token from the third party.
The token must then be sent to the API node using the Authorization header, as follow:
Authorization: Bearer <token>
Using OAuth2¶
You may have chosen to configure the JWT/OAuth2 settings for an OAuth2 provider. In this scenario, the JWT token is an access token and the API node acts as a resource server. The API node is agnostic about how you retrieve the access token from the OAuth2 provider. It will only check the validity of the token. Therefore you can choose to retrieve the access token using the authorization grant of your choice (see RFC 6749 for more information). If you are unsure, please contact your IAM admin for more details on which grant you should use and how.
Once you have retrieved an access token, it can be sent to the API node using the same Authorization header:
Authorization: Bearer <access-token>