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

• 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

WCCOAui -server: “Out of the box”

http access to WinCC OA files

WCCOAui -server: “Out of the box”

http access to WinCC OA files

• 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

WCCOAui -server: “Out of the box”

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
• https-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

*.scada.CERN.CH → MyScadaProxy.CERN.CH

Solution: Wildcard DNS record → Unlimited sub-domains

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

<VirtualHost *:80> ServerName psen.scada.CERN.CH <Proxy balancer://cluster> 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" 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/ </VirtualHost>

Configuration example:

Support for redundancy Egroups authorization CERN NICE authentication

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

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

Test: time to start up the UI for PSEN:

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

• 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

(?)

Seconday Objective: Securing the WinCC OA web client

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 →