Authorization Servicesprovide Access Tokensto Clientson behalf of Usersthat they pass to a Serverto be granted access to resources.

In a basic model (as shown in Figure 22) the Serveris 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 Serverrelies on external Authorization Servicesto provide some of its authorization requirements. These Authorization Servicesact in concert with an external identity provider which validates the user credentials before the external Authorization Servicecreates an Access Tokenthat tells the Serverwhat the user is a allowed to do. The Clientinteractions with these services may be indirect as shown in 6.2.2or direct as shown in 6.2.3.

Even when the Serverrequires the Clientto use an external Authorization Servicethe Serveris still responsible for managing and enforcing the Permissionsassigned to Nodesin 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 Serverinstead of the credentials. These tokens are passed as an IssuedIdentityTokendefined in 7.41.6.

The protocol to request tokens depends on the Authorization Service(AS). Common protocols include OAuth2 and OPC UA. OAuth2 supports claims based authorization as described in OPC 10000-2.

Serverspublish the Authorization Services(AS) they support in the UserTokenPolicieslist return with GetEndpoints. The IssuedTokenTypefield specifies the protocol used to communicate with the AS. The IssuerEndpointUrlfield contains the information needed by the Clientto connect to the AS using the protocol required by the AS.

The basic handshake is shown in Figure 24.

image027.png

Figure 24– Indirect handshake with an Identity Provider

Authorization Servicesrequire that Serversbe registered with them because the Access Tokenscan 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 Serverinformation 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.

image028.png

Figure 25– Direct handshake with an Identity Provider

The UserTokenPolicyreturned from the Serverprovides the URL of the Authorization Serviceand the identity provider. If the Application Authorization Serviceis linked with the GDS, it knows of all Serverswhich have been issued Certificates. The ApplicationUriis used as the identifier for the Serverpassed to the AS. The identity provider is responsible for managing users known to the system. It validates the credentials provided by the Clientand returns an Identity Access Tokenwhich identifies the user. The Identity Access Tokenis passed to the Application Authorization Servicewhich validates the Clientand Serverapplications and creates a new Access Tokenthat can be used to access the Server.