MSO Services

These services require the client to authenticate itself direclty to the service. This is always done by means of Belgian Government issued certificate, e.g. the belgian eID.

We describe here the least common multiple of the different MSO services. Some services might have lower security requirements, but this library only provides a single extension for all MSO services.

Introduction

The service uses SSL (https) to ensure the confidentiality and integrity of the message. Confidentialy means only the client and service can read the message while integrity means that the sender is sure the messages arrives unaltered at the service. The identify of the caller if verified by an signature and certificate. Unfortunately the configuration of eHealth is incompatible with WCF by default.

Security in WS-SecurityPolicy terms.

There are 2 ways to define the eHealth security in WS-SecurityPolicy terms. Here are both.

Via Asymetric Binding

When using asymmetric binding it is without any special setting on the binding itself. Asymmetric binding means that the message is protected by means of an asymmetric key pair, the public key generaly part of a certificate. By default both client and service use there own key pair and the key pair is used both the sign and encrypt the message.

eHealth defines the following additional requirements
  • covered by WS-SecurityPolicy
    • The token must be protected
  • exceptions on WS-SecurityPolicy
    • One-way: only the client signs the message, not the service
    • Confidentialy via transport: message is only signed, not encrypted and the transport must be over SSL (https).

Via Transport Binding

When using transport binding, it is without client certificate and with an X509 endorsing supporting token. Transport binding means one-way SSL is used. Supporting token means there is another mean of authentication (besides the one of the binding, that in this case is non-existing). Endorsing means the client can prove the ownership of the token by "protecting" the timestamp. The X509 means that it is a certificate, the prove of ownership is delivered by the private key.

In general, the supporting token only applies on the input of an operation and therefore is only required for the client. The service does not provide it since it is already authorized by its SSL certificate.
  • covered by WS-SecurityPolicy
    • The Endorsing supporing token must also sign the entire body
  • violating WS-SecurityPolicy
    • The endorsing supporting token must be signed

In WCF 4.0

As far I could find out, it is impossible in WCF to specify that endorsing supporting tokens must sign the entire body. Therefore the security in the library is based on asymmetric binding.

It was set up in the following way
  • One-Way:
    • Allowing unsecure responses
    • Removing service token requirement via custom defined client credential type: OptClientCredentials
  • Protected token via
    • Add the token again is signed supporting token (this way the token same token is includes twise and the second token is referenced by the signature)
    • Use a custom Message that removes the original (unsigned) token and update signing token reference to point to the supporting token.
  • Confidentialy via transport
    • Set transport to "https"
    • Deactiving encryption could not be set by configuration and must be set on each service via the ProtectionLevel of the ServiceContract-Attribute

eHealth uses SOAP 1.1, so the library reflects this.

All this is put together in a "StsBinding" class, it does not allow/require any configuration.

Adding Service Reference

Adding a reference can be done in your favorite way. Warning the generated code must be addapted each time you (re)generate the code!

Locate the ServiceContractAttribute in the generated code and add the ProtectionLevel = ProtectionLevel.Sign property.

Example:
[ServiceContractAttribute(ProtectionLevel = ProtectionLevel.Sign, Namespace = "nnn", ConfigurationName = "ccc", Name = "sss")]
public interface XxxPortType {
   //snip
}

Configuration

The clients should use the custom defined StsBinding. This binding does not require any configuration. It should also use the OptClientCredentials instaid of the standard client credentials.

Via app.config/web.config

In the app.config or web.config the configuration looks as follows

<configuration>
  <system.serviceModel>
    <extensions>
      <bindingExtensions>
        <add name="stsBinding" type="Siemens.EHealth.Client.Sso.Sts.Configuration.StsBindingCollectionElement, Siemens.EHealth.Client"/>
      </bindingExtensions>
    </extensions>
    <client>
      <endpoint address="https://hhh/zzz" binding="stsBinding" behaviorConfiguration="b1" contract="xxx" name="yyy"/>
    </client>
    <behaviors>
      <endpointBehaviors>
         <behavior name="b1">
          <clientCredentials type="Siemens.EHealth.Client.Sso.WA.OptClientCredentials, Siemens.EHealth.Client">
            <clientCertificate storeLocation="CurrentUser" storeName="My" x509FindType="FindByThumbprint" findValue="iii"/>
          </clientCredentials>
        </behavior>
      </endpointBehaviors>
  </system.serviceModel>
</configuration>

Via code

Xxx target = new Xxx(new StsBinding(), new EndpointAddress("https://hhh/zzz"));
target.Endpoint.Behaviors.Remove<ClientCredentials>();
target.Endpoint.Behaviors.Add(new OptClientCredentials());
target.ClientCredentials.ClientCertificate.SetCertificate(StoreLocation.CurrentUser, StoreName.My, X509FindType.FindByThumbprint, "iii");

Last edited Dec 2, 2010 at 3:59 PM by egelke, version 6

Comments

No comments yet.