Mobile Signature Service attempts to connect a service (Application Provider) to a user (Mobile User).

MSS is essentially a big, scalable cloud thingy. Add more hardware and it works faster, right? Let’s open up the cloud and see the hardware inside, from the point of view of a single operator:

In this scenario the AE (Acquiring Entity) server is responsible of routing requests from an AP (Application Provider)

• to the HMSSP (Home MSSP) if the requested mobile user belongs to my operator or
• otherwise to the RE (Roaming Entity).

The RE server is responsible for routing requests

• to the HMSSP if the requested mobile user belongs to my operator or
• otherwise to the operator that the mobile user belongs to.

The Problem

In order to make trusted connections between AE, RE and HMSSP, they need to share service URLs and certificates.

This isn’t a huge problem in our setup since we only have three servers. However, when scaling up, the amount of information required by each server grows rapidly. In other scalable systems different information can be required.

Now imagine that each server needs to be manually configured with all required information about other servers. For instance, updating a certificate in a single server would require updating configuration in affected servers.

In large systems finding affected servers is hard and configuration mistakes are probable. Updating certificates in all servers would require tears and long hours.

The Solution

Our solution to these problems is MSSP metadata. Each server stores provides the data as an XML file. Servers can request each other’s metadata for a complete picture of the system.

During installation an admin needs to configure, for each server:

• Certificate of the server.
• Metadata distribution URL of the server.
• Other servers’ metadata distribution URLs.
• Other servers’ metadata XML file.

Since the certificate only needs to be configured on a single server the maintenance is easy and configuration mistakes are improbable.

Metadata can work even between operators. This is simply done by configuring metadata distribution URLs between operators.

Security

Initially the metadata downloaded from the distribution URLs cannot be trusted because the other servers’ certificates aren’t configured.

This is solved by copying other servers’ metadata manually to the server that’s being configured. An other server’s certificate is taken from the manually copied metadata. The certificate is used to establish trust to downloaded metadatas.

From this point on server certificates can be securely updated via the metadata.

Specification

As a base for designing the MSSP metadata solution, we used SAML 2.0 metadata. SAML 2.0 provides a well-defined, interoperable metadata format but it isn’t flexible enough to fit our requirements.

For further reading: Kiuru_MSSP_5.0_Metadata_Specification