Search Results for

Show / Hide Table of Contents

# Security

There are several security scenarios for accessing memoQ Server. Most existing web service security standards (such as WS-I Basic Profile security, WS-Security, etc.) are supported. If memoQ Server is accessed from a .NET environment, other, non-standard options are also possible.

## IP address filtering

The most likely scenario for the WS API is that the consumer is another server-based system that accesses memoQ Server from a protected intranet zone. In this case the default web service configuration options for memoQ Server are suitable: the security is basically turned off, and the "Web Service interface" page of the Server Administrator of memoQ Client can be used to enable web service access only for the other server-based system by enabling IP address filtering:

IP address filtering might not be a sufficient solution in every case, for example if the web service is publicly available on the internet (e.g. hosted by the Kilgray cloud) and its clients have dynamic IP address.

## API key

memoQ Server administrators can generate a cryptographically random 40 characters length alphanumeric API key for the WS API, which the clients must include in every request to the web service. The API key limitation can be enabled in both the Server Administrator and the Deployment Tool.

As for the clients the API key must be set in the header of the SOAP messages as the value of an "ApiKey" element:

    <s:Envelope
        xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
      <s:Header>
        <ApiKey>
          Y90lL2T7zexDLtM3t8JEMGNhXdDbDqri6Hyrzyhv
        </ApiKey>
      </s:Header>
      <s:Body>
        ...
      </s:Body>
    </s:Envelope>

In case of a client application using WCF, sending an API key in the header of the SOAP messages can be achieved purely with the right modifications in the WCF configuration file. For every endpoint that the client intends to call a section should be defined in the appropriate element, and in this element the API key should be specified in an element (if an endpoint entry was an empty XML element before, it should be replaced with an opening and closing element):

    ...
      <client>
         <endpointaddress="https://localhost:8081/memoqservices/security/SecurityService"
              binding="basicHttpBinding"bindingConfiguration="CommonBindingConfig"
              contract="SecurityService.ISecurityService"name="SecurityService" >
            <headers>
              <ApiKey>Y90lL2T7zexDLtM3t8JEMGNhXdDbDqri6Hyrzyhv</ApiKey>
            </headers>
         </endpoint>
    ...

In our test client tool this configuration can be done in the MemoQServicesClient.exe.config file. In this file, there is already an "ApiKey" entry as an example (only for one endpoint), commented out by default.

Besides this configuration, the test client tool provides another way to test the API key with the help of the following form that can be brought up by the "Api key test" menu item.

Here the users can call a WS API function (ListUsers) and specify an arbitrary API key.

If a WS API function is called with an invalid (maybe a new key was generated on the server) or missing API key, the appropriate error message is sent back to the client in a GenericFault exception along with an ErrorCode to distinguish the 2 cases:

Case | ErrorCode
--- | ---
No API key was sent in the SOAP header | Generic.MissingApiKey
Wrong API key was sent in the SOAP header | Generic.InvalidApiKey

To catch these exceptions, WCF clients can use the following code:

    catch (FaultException<GenericFault> genericFault)
    {
        if (genericFault.Detail.ErrorCode == "Generic.MissingApiKey")
        {
            ...
        }
        else if (genericFault.Detail.ErrorCode == "Generic.InvalidApiKey")
        {
            ...
        }
        else
        {
            ...
        }
    }

It is important to emphasize that this API key limitation makes only sense over a secure channel (e.g. using HTTPS), otherwise the API key of a legal client could be perceived and later used by not intended clients.

## Other security scenarios

It is possible to configure memoQ Server to use SSL for web service communication.

It is also possible to limit access to the web service based on the Windows identity of the consuming system if it supports Windows Integrated Security.

## User level authorization

This functionality is deprecated.

User level authorization and operations requiring user level authentication will be eliminated in 8.0

The memoQ Server's user permissions do not apply to most of the WS API "user." API access assumes unlimited trust, the WS API is a super user with unlimited privileges, except for the following functions:

- TMService/LookupSegment
- TMService/Concordance
- TMService/AddOrUpdateEntry

The functions require a memoQ user session and validate the user's permissions.