ControlSystemWorks Blog - security

Security - access rights management

Sergey Sorokin — Tue, 07 Sep 2010 18:06:29 GMT

CSWorks provides a mechanism to support LiveData, Alarming and Historical data access authorization, but does not have access rights management functionality. Companies that deploy web-based solutions usually have some access management infrastructure in place, which is either based on Active Directory or integrates with some third-party technologies. And in most cases, IT managers in these companies do not like the idea of having yet another piece of security infrastructure that can be used for SCADA-related authentication tasks only. It's just too much hassle: extra support, one more set of user names and passwords to maintain, extra security risks.

This is why we do not offer our own access right management subsystem with CSWorks - we want to let IT managers choose the right one. We designed CSWorks in a way it can be integrated with existing security solutions. It's up to the application developer team how CSWorks-powered ASP.NET application authenticates a user and what screens are available to the authenticated user. CSWorks can only enforce some restrictions on data access when a CSWorks-powered client application accesses data - LiveData Alarming, or Historical (see CSWorks documentation for details).

If you are new to the world of the web-based access rights management systems, you probably need something to start with. I would recommend downloading a few products available on the market and getting familiar with them. PortSight SecureAccess and Atlassian Crowd are good candidates: they both support Active Directory integration, both are .NET friendly, both are mature products, both provide samples for .NET developers. If you decide to use such a product for your CSWorks solution, your application should perform the following tasks.

User authentication. Performed by the selected access right management solution either through API or through a separate web page.
CSWorks web service access authorization. Authorization information is stored in the ASP.NET session state, see CSWorks documentation for details.
ASP.NET page access authorization. Your ASP.NET application should provides access only to the pages that are available to the authenticated user. This can be done by using access right management solution API (direct .NET calls or web service-based).
Silverlight page access authorization. Your Silverlight client application should provides access only to the pages that are available to the authenticated user. This can be done by a variety of methods: web service calls from the client applications or passing startup parameters to the Silverlight engine when starting client application.

Of course, there is a learning curve involved in some cases. Yes, third-party (or custom developed) software is involved. The benefits outweigh the risks though - customers get a robust solution that works in a predictable way and re-uses existing security infrastructure.

Running CSWorks demo applications from remote clients

Sergey Sorokin — Thu, 25 Feb 2010 00:24:27 GMT

One of the first things I would do after installing CSWorks is to open a browser on another machine in the network and type in "http://MyTestBox/CSWorksDemo/PipesAndTanksDemo.html", where MyTestBox is the name of the machine where I installed CSWorks.

This doesn't work. And it's not supposed to work because of the cross-domain web service call restrictions imposed by your browser. If you have a look at ServiceReferences.ClientConfig file in the Pipes and Tanks Demo xap package (CSWorks.Client.PipesAndTanksDemo.xap in your CSWorksDemo/ClientBin folder; don't worry it's just a ZIP file with XAP extension), you will find endpoint description for LiveData web service calls that looks as follows:

In our case, when Silverlight is trying to make a web service call to http://localhost/CSWorksDemo/LiveDataWebService/Service.asmx, the browser checks the URL of the application which happens to start with "http://MyTestBox". Since it doesn't start with "http://localhost", the browser considers this a potential security threat and blocks the call.

To make things work, just replace "localhost" in the config file with the name (or IP address) of your CSWorks server:

and save updated config to the xap file. Now refresh the page in the browser on the remote machine - Pipes and Tanks Demo should work fine.

Update (June 25, 2010):

with Silverlight 4, you can use relative web service addresses, see this post for details.

Certificate security for WCF over MSMQ communication

Sergey Sorokin — Tue, 29 Sep 2009 04:52:32 GMT

While working on one of my projects, I had to make WCF run over a farm of load-balanced message queues. After several days of web search, asking questions and coding I have come up with the following "Step-by step guide for setting up certificate security for WCF over MSMQ communication".

The goal is to implement a secured WCF communication based on MSMQ under the following requirements/assumptions/recommendations.

All MSMQ traffic must be encrypted and signed.
No involvement of Windows Domain security and Active Directory.
No code changes required on the client or on the server side.
MSMQ version 4.0 (W2K8) is used, but it would be nice to have a solution that works on MSMQ 3.0 (W2K3) as well.
There must be a well-established and straightforward routine for setting up secured communication that can be followed during test/staging/production deployment.

The weapon of choice is message-based certificate security. To put it simple, it means two things:

all security-related activities happen on WCF level, MSMQ engine works only as a transport;

certificate keys are stored on client and server machines.

Read on...