SWIM Demo Server-Authentication
SWIM Weather Public Demonstration >

Authentication

EUROCONTROL SWIM Technical Infrastructure (TI) Yellow Profile 2.0, specifically requirement SWIM-TIYP-0042, mandates that the authenticity of the MET-SWIM server (in the IBL case, the “SWIM Weather” server) must be verifiable using “TLS Server Authentication” using an X.509 server certificate signed by HARICA or another certificate authority approved by EUROCONTROL EACP.

The mechanisms for verifying client authenticity are left open to implementations, but SWIM TI Yellow Profile 2.0 lists the following methods as examples:

  1. Mutual TLS authentication with X.509 client authentication: Implemented by SWIM Weather, but combined also with username/password authentication.
  2. Basic client authentication – Implemented by SWIM Weather 1.2.0 for HTTPS connections (and using SASL PLAIN for AMQP connections). Applies both to Mutual TLS and Server TLS connections.
  3. Bearer client authentication – NOT available in IBL SWIM Weather.
  4. Anonymous client authentication – NOT available in IBL SWIM Weather.
  5. Other authentication mechanisms are allowed, but not specifically mentioned by the SWIM TI Yellow Profile 2.0 (requirement SWIM-TIYP-0042).

There are two authentication methods currently available in SWIM Weather. Both rely on usernames and passwords, but they differ in terms of whether client certificates need to be presented by users for additional protection.

Client Authentication and Authorisation - Server TLS with Usernames and passwords

In this basic mode, available from SWIM Weather 1.2.0, clients do not need to possess client certificates. The clients can verify the server’s authenticity by checking the server's TLS certificate (check if it was signed by HARICA or another EACP-approved CA).

  1. The SWIM Weather administrator, who is part of the organisation providing the SWIM services, manages a list of user identities along with their corresponding passwords.
  2. The passwords are stored using salted hashes on the SWIM Weather server. The passwords can not be decrypted after they have been entered. If users lose their passwords, new ones need to be assigned.
  3. For OGC EDR requests over HTTPS, client users must include the username and password in the HTTP Authorization request header using the Basic authentication scheme.

    1. The client must concatenate the username, a single colon (:), and the password into a single string (e.g., username:password).

    2. This string must be encoded using Base64.

    3. The resulting header follows the format: Authorization: Basic <Base64_encoded_credentials>.

    4. Example: If the username is swim_user and the password is secret123, the combined string swim_user:secret123 is Base64 encoded to c3dpbV91c2VyOnNlY3JldDEyMw==. The header sent by the client would be: Authorization: Basic c3dpbV91c2VyOnNlY3JldDEyMw==

  4. For AMQPS connections, the username and password must be provided using the SASL PLAIN mechanism.


Note
Since both Mutual TLS and Server TLS access to SWIM Weather require usernames and passwords to be sent by the clients, the two methods differ only in the additional client certificate validation and whitelisting available for the Mutual TLS mode.

Client Authentication and Authorisation - Mutual TLS with Usernames and Passwords

When the Mutual TLS mode is used for connections, each client needs an EACP client certificate signed by an EUROCONTROL-approved CA (currently only HARICA). The client certificate must be present in both AMQPS and HTTPS connections. The SWIM Weather server verifies the client certificates.

The SWIM Weather contains the HARICA CA certificate preconfigured so that the client certificates can be verified. Multiple CA certificates for client verification can be registered in addition, for example:

  1. HARICA staging (testing) environment
  2. In the future, CA certificates of other EACP-approved authorities besides HARICA.

Once a client authenticates using a client certificate whose authenticity can be verified using one of the pre-registered CA certificates, the system authorises or denies the request based on two mechanisms used in sequence:

  1. Based on a whitelist of Distinguished Names (DN) or parts of DN (e.g. organisation, or e-mail).
    1. The SWIM Weather server extracts the Organisation name, Email, and Common Name from the client certificate.
    2. In addition to the client certificate being issued by an EACP-approved CA, the details from the client certificate must also be known to SWIM Weather in order to authorize the user to access the EDR and AMQP services.
  2. Since SWIM Weather 1.2.0, using an additional username and a password.
    1. For more details about the usernames and passwords, please see "Client Authentication and Authorisation - Server TLS with usernames and passwords".

There are two ways through which a client certificate can be obtained:

  1. The client's organisation goes through the EACP enrollment process.
    1. The client organisation will receive access to a CA portal (for example, the HARICA portal), where client certificates can be generated.
    2. Public details of the certificate, especially the Distinguished Name parts, need to be communicated to the MET-SWIM service provider (organisation running SWIM Weather). These certificate details will then be added to a whitelist of allowed clients.
  2. If the client organisation is not enrolled in EACP, the MET-SWIM service provider operating SWIM Weather can generate a client certificate for the client.
    1. The Organisation and Email parts of the Distinguished Name will be in this case fixed and identify the MET-SWIM service provider.
    2. The Common Name (CN) part of the certificate can be used to distinguish individual clients. The CN will then be the main piece of information needed to distinguish the client in the SWIM Weather client certificate whitelist.


Note
In either of the above cases, the client certificate should identify individual client software systems running in the client organisation. For example, if the client organisation operates five software systems that will connect to SWIM services using Mutual TLS, each should have its own client certificate. This is not a SWIM Weather technical requirement, but it is an EACP requirement.