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 rights 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.

  1. User authentication. Performed by the selected access right management solution either through API or through a separate web page.
  2. CSWorks web service access authorization. Authorization information is stored in the ASP.NET session state, see CSWorks documentation for details.
  3. 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).
  4. 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.