Alternative way of starting up the WinCC OA UI using HTTP protocol - PowerPoint PPT Presentation

Alternative way of starting up the WinCC OA UI using HTTP protocol Hannu Kamarainen, Piotr Golonka CERN EN/ICE-SCD 16 June 2015

Contents ● Motivation ● Mechanism for http access to WinCC OA project fjles ● Http web proxy concept ● Access control: integration with CERN Egroups ● Easy application access using subdomain names ● High Availability for proxy: redundancy/failover ● Performance ● Confjguration and deployment (proxy, WinCC OA projects) ● Current Status and Further steps

Motivation Typically: ● Problems with samba availability/support ● Problems with performance ● Access for WinCC OA redundant projects

Motivation ● Improve on: – Availability: Alternative way to network-share access fjles – Proper support for WinCC OA Redundant projects – Secure access to applications ● Preferably with egroups, CERN accounts – Management of ~200 difgerent applications

http access to WinCC OA files WCCOAui -server: “Out of the box” ● Built-in Web Server in a WinCC OA project: WCCOActrl webclient_http.ctl - Uses httpServer() CTRL function ● Client side (UI manager): WCCOAui -server http://cs-ccr-psen1:8080 -p vision/PSEN_login.pnl

http access to WinCC OA files WCCOAui -server: “Out of the box”

http access to WinCC OA files WCCOAui -server: “Out of the box” ● Authentication support implemented on client side (only some triviality available on server side) ● Https support; problem with certifjcates for many-server deployments ● “http tunneling” is active by default to access EM and DM – -noTunnel option allows to connect to EM, DM directly ● Feature originates from the Web client plugin of WinCC OA

proxy concept Client connects to Proxy: Proxy connects to the server “on behalf” of the client and transparently passes information between the client and the server.

http proxy concept ● Types of proxies: – Forward proxy ● Allows client to access arbitrary locations ● Client needs to be specifjcally confjgured – Reverse proxy ● Client accesses the proxy as its destination URL Proxy decides where client is (re-)directed ● No client confjguration needed ● Example: load-balanced web server

http reverse proxy server with WinCC OA UI Client connects to Proxy; Proxy connects to WinCC OA project “on behalf” of the client and transparently passes information between client and server.

Why having a proxy? ● Authentication/authorization ● http s -to-http offloading ● Load-balancing ● High-availability/redundancy

Managing proxy destinations

Managing proxy destinations Goal ● User-friendly, easy-to-remember url's to access applications ● Easy to manage Problem: ● http://MyScadaProxy.CERN.CH/myApp will not work

Managing proxy destinations Solution: Wildcard DNS record → Unlimited sub-domains *.scada.CERN.CH → MyScadaProxy.CERN.CH

Managing proxy destinations *.scada.CERN.CH → MyScadaProxy.CERN.CH psen.scada.CERN.CH moon.scada.CERN.CH na62dcs-muv.scada.CERN.CH QPS-DT8AG.scada.CERN.CH … → MyScadaProxy.CERN.CH ● Http Proxy server knows through which “host name” it was accessed ● It redirects to appropriate data server, based on that information

Configuration example: <VirtualHost *:80> ServerName psen.scada.CERN.CH <Proxy balancer://cluster> Support for redundancy Order deny,allow Allow from all BalancerMember http://cs-ccr-psen1:8080 retry=5 BalancerMember http://cs-ccr-psen2:8080 status=+H AuthName "PSEN Authentication" CERN NICE authentication AuthType Basic AuthBasicProvider ldap AuthzLDAPAuthoritative On AuthLDAPURL "ldap://tndc.cern.ch/OU=Users,OU=Organic Units,DC=cern,DC=ch? sAMAccountName?sub?(objectClass=person)" AuthLDAPBindDN "username" AuthLDAPBindPassword "password" Require ldap-group CN= acc-unicos-psen ,ou=e-groups,ou=Workgroups,dc=cern,dc=ch </Proxy> RequestHeader unset Authorization ProxyPass / balancer://cluster/ ProxyPassReverse / balancer://cluster/ Egroups authorization </VirtualHost>

Proxy Redundancy

Proxy Redundancy DNS round-robin setup *.scada.CERN.CH → 172.18.202.76 (cs-ccr-scada003) *.scada.CERN.CH → 172.18.202.74 (cs-ccr-scada002) Instead of receiving only one IP-address from the DNS, a list of addresses is received instead.

Proxy Redundancy DNS round-robin setup Pros: - One time setup (CERN DNS server) - Standard feature of the Internet - Maintained by IT Cons: - Possible delays in handling the handover (TTL) for certain applications

Performance Test: time to start up the UI for PSEN: Connection method s to login s to panel open total Samba 12 22 34 Local fjles 13 8 21 Win WCCOAui -server, no cache 13 10 23 Win WCCOAui -server, cache 8 8 16 Linux WCCOAui -server, no cache 7 7 14 Linux WCCOAui -server, cache 7 7 14

Configuration & Deployment ● DNS Server – Done. (minor IT intervention needed if re-locating proxy servers) ● Proxy server(s) – Confjg fjle(s) with defjnition of applications – Generated automatically (template + data from MOON DB) ● WinCC OA Projects – FwHttpFileServer component – Adds a manager that runs the server – Already redundancy-aware ● Windows Terminal servers – Make sure that OpenSSL is installed

Summing it up: features WCCOAui -server http:// MyApp .scada.CERN.CH -p CentralDCS.pnl -noTunnel Includes: ● No hassle with samba ● No hassle with UI-specifjc “+confjg” fjles ● Authentication, with CERN credentials ● Authorization with Egroups ● Access to WinCC OA redundant systems ● High availability ● Https -enabled connection with no certifjcate hassle ● (relatively) Easy to memorize command line (URL!) ● (relatively) Easy-to-maintain

Current Status ● Reviewed and initially accepted by IT Security ● Web front-end ready for managing projects' settings ● Large-scale test pending ● Deployment for production (?) as an alternative way of starting applications (?) ● Following up with ETM: Some security issues

Seconday Objective: Securing the WinCC OA web client ● WebSockets proxying work out of the box on Apache 2.4 and newer ● Shibboleth SSO works fjne ● Securing the Ultralight client for dedicated use cases (?)

Technology: Why Apache httpd ● Apache web server daemon – Most popular (54% of all active websites) ● Very well documented, huge users community – Stable, mature and being improved – Multiplatform (Linux, Windows) – Open source – Customizable with modules ● Could run in “proxy” mode – Readily available in all mainstream Linux Distributions → Scientifjc Linux OK → Supported by CERN Central Web Services