User authentication/authorization (application layer)
The application development team is fully responsible to choose the specific IP. The selected provider should support some standard OAuth functionality.
The cloud application should authorize the user unless the cloud platform provides the authorization. Most commonly, the cloud application should control user authorization for specific actions (sending a specific command to a particular station). Each user should have a defined role as a result of the authorization process.
Figure 4. User authentication — Application layer
As a result the cloud application should be able to collect a JSON Web Token (JWT) signed by the IP with these minimum claims:
- The algorithm should be RS256.
- The token issuer claim (iss) must contain a unique string that identifies the IP (typically this claim is fixed by the Identity Provider).
- The token audience claim (aud) must contain the predefined audience “Cloud Driver” (audience is configurable on the station side).
- The token subject claim (sub) should contain the user id (Use the guid for this. No personally identifiable information should be added to this field!).
- The private claim named “cloudroles” should contain the user role.
- The token expiration (exp) should be short! It is important to use short-living tokens to mitigate the risk of replay attacks. The recommendation is to choose a token time to live not longer then the typical user session.
- Avoid adding personally identifiable information to the JWT claims.
For development purposes, you could use native certificate management and jwt.io.
| ACTION: Set up Identity Provider |
|---|
|
Choose and configure the Identity Provider. Implement user authentication/authorization. The cloud application should be able to access JWT with particular claims to identify the user who initiated the command. |