Authorization Services provide Access Tokens to Clients on behalf of Users that they pass to a Server to be granted access to resources.
In a basic model (as shown in Figure 22) the Server is responsible for authorization (i.e. deciding what a user can do) while a separate identity provider (e.g. the operating system) is responsible for authentication (deciding who the user is).
In more complex models, the Server relies on external Authorization Services to provide some of its authorization requirements. These Authorization Services act in concert with an external identity provider which validates the user credentials before the external Authorization Service creates an Access Token that tells the Server what the user is a allowed to do. The Client interactions with these services may be indirect as shown in 6.2.2 or direct as shown in 6.2.3.
Even when the Server requires the Client to use an external Authorization Service the Server is still responsible for managing and enforcing the Permissions assigned to Nodes in its Address Space. The clauses below discuss the use of an external Authorization Service in more detail.
Authorization Services (AS) provide access to identity providers which can validate the credentials provided by Clients. They then provide tokens which can be passed to a Server instead of the credentials. These tokens are passed as an IssuedIdentityToken defined in 7.36.6.
The protocol to request tokens depends on the Authorization Service (AS). Common protocols include Kerberos and OAuth2. OAuth2 supports claims based authorization as described in OPC 10000-2.
Servers publish the Authorization Services (AS) they support in the UserTokenPolicies list return with GetEndpoints. The IssuedTokenType field specifies the protocol used to communicate with the AS. The IssuerEndpointUrl field contains the information needed by the Client to connect to the AS using the protocol required by the AS.
The basic handshake is shown in Figure 24.
Figure 24 – Indirect Handshake with an Identity Provider
Authorization Services require that Servers be registered with them because the Access Tokens can only be used with a single Server. This can introduce a lot of complexity for administrators. One way to reduce this complexity is to leverage the Server information that is already managed by a Global Discovery Service (GDS) described in OPC 10000-12. In this model the user identities are still managed by a central Authorization Service. The interactions are shown in Figure 25.
Figure 25 – Direct Handshake with an Identity Provider
The UserTokenPolicy returned from the Server provides the URL of the Authorization Service and the identity provider. If the Application Authorization Service is linked with the GDS, it knows of all Servers which have been issued Certificates. The ApplicationUri is used as the identifier for the Server passed to the AS. The identity provider is responsible for managing users known to the system. It validates the credentials provided by the Client and returns an Identity Access Token which identifies the user. The Identity Access Token is passed to the Application Authorization Service which validates the Client and Server applications and creates a new Access Token that can be used to access the Server.