SOAP services for XProtect

Overview of services

The following table illustrates what to use where:

Authentication methods

OpenID Connect and OAuth2

In XProtect 2021 R1 and later, authentication and authorization can be provided by an internal OpenID Connect- and OAuth2-compliant identity provider service. This improves privacy and is a step towards unified user management and better integration with cloud services and 3rd-party identity providers.

In the XProtect 2021 R1 release, the focus has been on secure user authentication and securing the Management Server services. There are no essential changes to how users are added and managed, and both Basic and Windows users are supported.

After login, an OAuth2 access token is acquired from the internal identity provider service and can be used to authorize communication with other OAuth-enabled services, currently only Management Server services.

To support backwards compatibility for already deployed clients and integrations, the existing Management Server service endpoints for Windows and Basic users are still supported.

Windows

The Windows user authentication protocol can be either NTLM or Kerberos, and is the underlying technique used with the SOAP protocol to convey user name and password, while encrypting the communication. The NTLM or Kerberos protocol is not directly visible in the SOAP protocol.

When developing .NET Framework applications, the .NET library will handle this protocol. Developing for Linux requires you to implement this yourself.

Basic HTTP over TLS

Basic user login uses standard basic HTTP authentication over TLS (HTTPS). TLS encrypts the traffic and provides some level of security.

XProtect token

After login, an XProtect token is acquired from the Management Server and used to authorize communication with other services. A token only lives for a short period of time, and needs to be refreshed regularly.

Services and how to find addresses and ports

When connecting to an XProtect server, only an address (port), user name and password are required. From that point, all information is fetched from the server via GetConfiguration calls, ConfigurationApiService calls or other calls. A person installing a solution should not have to configure any addresses or ports for Recording Servers, Event Servers or any other services.

ServiceRegistrationService contains all relevant information for connecting to the Management Server, Recording Server, Event Server, Mobile Server and any other server services in the future.

The service provides address, port and server type information, for all registered services.

Multiple instances can be available for the same service, but this is currently only used for the Mobile Server.

The ServiceRegistrationService is always located on the Management Server. Address and port of Recording Servers are not found here, but are included as part of the configuration.

Protocol implementation versus MIP SDK .NET library

Use the MIPSDK .NET library when possible; it will take care of many details.

Use ServiceRegistrationService for getting the address, port and authentication information. Partners are welcome to register their own services, to e.g. make connections from Smart Clients easy, because external server addresses can be configured once in the Management Client, and used by many Smart Client operators.

Avoid asking end-users to configure addresses in the Smart Client.