The LEADTOOLS Medical Web Viewer Framework provides and implements a security and management model. Use the management system portion to:

• Manage the users accessing the server side of the framework remotely and from different locations over the web
• Create user accounts and configure them to the application's requirements
• Register accounts to specific roles and groups.
• Assign permissions to roles to access the patient's information.

Each client can securely communicate with the web server using the framework security model.  The Medical Web Viewer framework supports all security options provided by WCF services which can be configured by an administrator without the need to write any extra code.  Security can be configured for each plug-in contract independently and with different options. An administrator can use the WCF security model for message security which is based on the open platform secure SOAP messages by using either user name and password or X.509 certificates for securing the Query, Store and DICOM retrieve plug-ins and applying a transport level security such as HTTPS on the Manage plug-in. A developer can use the access control and authorization model in WCF services to assign different roles and identities to the service clients. Auditing security events is also supported and can be configured to log messages directly to the windows event log or implement any type of custom logging systems.

The following is an example of the current implementation for configuring user authentication and authorization and applying message security level mode for the Query service. First, you will need to register the WCF service endpoint and configure the binding method as shown: 

      <service behaviorConfiguration="internet" name="Leadtools.Dicom.WCF.DICOMService">
        <endpoint binding="wsHttpBinding" bindingConfiguration="wsHttpBindingConfig" contract="Leadtools.Dicom.WCF.IQueryService" />
        ...
        ...
      </service>
           

We chose WCF wsHttpBinding which supports HTTP and HTTPS transport security and text message encoding to enable the service to serve our client communications regardless of its technology and platform Now we need to configure our wsHttpBinding binding in its configuration section which we called wsHttpBindingConfig as shown:

      <wsHttpBinding>
        <binding name="wsHttpBindingConfig"...>
        ...
        ...
          <security mode="Message">
            <message clientCredentialType="UserName" negotiateServiceCredential="true" establishSecurityContext="true" />
          </security>
        </binding>
      </wsHttpBinding>

We use User name and password client credentials to authenticate calling users and encrypt messages. Now that we have configured the service bindings, we will configure the service behavior by setting the clients authentication to use the ASP.NET authentication provider and authorization mode to use the ASP.NET authorization provider. Then we will instruct the WCF clients to validate our service using service certificate validation.

      <serviceBehaviors>
        <behavior name="internet">
          ...
          ...
          <serviceAuthorization principalPermissionMode="UseAspNetRoles" />
          ...
          <serviceCredentials>
            <userNameAuthentication userNamePasswordValidationMode="MembershipProvider" />
            <serviceCertificate findValue="MedicalViewerTestCert" storeLocation="LocalMachine" storeName="My" x509FindType="FindBySubjectName" />
          </serviceCredentials>
                    ...
        </behavior>
      </serviceBehaviors>

With the above configuration, we can depend on ASP.NET technology to authenticate and authorize users using the built-in membership and roles providers which can be configured to connect to any credentials store. Also we integrate this technology to perform message level security to encrypt the information sent between the WCF service and authenticated users and define a method for the clients to validate our service using X509 certificate to ensure full security model in all communication directions.

On the client side, the WCF service caller will provide the service with a user name and password for service authentication and validation. Also the client should obtain and install the service certificate using any mechanism (email, public download page...) then instruct the WCF to validate the calls to the service.

      <endpoint address="http://localhost/Service.svc" behaviorConfiguration="ServiceCertificate"... </endpoint>

 

 

    <behaviors>

      <endpointBehaviors>

        <behavior name="ServiceCertificate">

          <clientCredentials>

            <serviceCertificate>

              <authentication certificateValidationMode="PeerTrust" />

            </serviceCertificate>

          </clientCredentials>

        </behavior>

      </endpointBehaviors>

    </behaviors>

If the client can’t get the WCF service certificate and install it into the local machine for any reason, the client can explicitly specify the certificate name in the endpoint identity’s section and instruct the WCF not perform validation on the certificate: 

      <endpoint address="http://localhost/Service.svc" behaviorConfiguration="ServiceCertificate"...

        <identity>

          <dns value="MedicalWebViewerCert" />

        </identity>

      </endpoint>

   

    <behaviors>

      <endpointBehaviors>

        <behavior name="ServiceCertificate">

          <clientCredentials>

            <serviceCertificate>

              <authentication certificateValidationMode="None" />

            </serviceCertificate>

          </clientCredentials>

        </behavior>

      </endpointBehaviors>

    </behaviors>

See Also

 

 

---

Products | Support | Contact Us |

© 2006-2011 All Rights Reserved. LEAD Technologies, Inc.