Omniscope files are not only more compact, interactive and visually communicative than other report data files (e.g. spreadsheet files and webpage tables), they also have many more potential layers of security options to prevent unauthorised access to, and potential re-use of, the data and images within your published files.
Most file security options are accessed from the File > Save or the File > Export > Data File {File Type = IOK} dialog, either as a specific Security dialogue (also available under File > File security) or on the far right side of the File > Save as dialogue under the Security section (with the exception of text field scrambling and random sampling options under the Data > Operations menu, and the 'walled gardens' security perimeter option implemented by issuance of special groups of activation keys.
Owner-locking is a change prevention and copy-prevention feature that prevents any changes to the file configuration and even cut-and-paste copying from Omniscope, as well as saving or exporting the data in any way. This is an 'all-or-nothing' setting, designed primarily to prevent recipients of your file from changing the configuration or extracting, modifying or plagiarising your data and Omniscope configuration. Only the Owner (i.e. the Omniscope installation license key that created or last refreshed the file) can be used to disable this setting. The Owner can continue to refresh, edit and save the file even with this setting enabled, but no other installation using another license key can. Effectively, a file opened on a different PC with this setting enabled will operate in free Viewer mode only; changing file configurations, un-hiding tabs or menu/sidebar elements etc. or extracting/copying data will not be permitted. This setting does not protect file B from being overwritten when opening file A, choosing File > Save as and saving over file B. In order to prevent overwrites, you should not only use write protection (see below) but also operating system-level options such as setting the file as Read only in the Windows Explorer file properties, especially for empty template files stored in a shared directory or on the server for refreshing.
This option is available from the right side of the File > Save As dialogue under the 'Other' headiing is a safeguard against accidentally saving changes to an important file, like an empty template file. When this option is selected, users will be warned if they try to save the file with changes or save another IOK file with the same name. As with Owner-locking (see above) this option does not fully-protect file B from being overwritten when opening file A, choosing File >Save as and saving over file B with the same name. To prevent this, you should use operating system-level options such as Read only settings in the Windows Explorer file properties. Omniscope's Write-protect option merely warns you if you inadvertently press Ctrl+S while an important file is open.
Less revealing versions of files for external distribution/sharing can quickly be generated automatically using operations available under Data > Operations {Scramble} and {Random Sample}. These options create a new version of the IOK file with specified text column values to be 'scrambled' such that the text values cannot be read, or with only a specified number or randomly-sampled rows preserved and the rest deleted for the saved copy of the new sampled file. These security features permit us to assist you with files containing confidential information, but also allows selective scrambling for out-sourcing of some aspects of workflow and data quality while maintaining some columns of data, e.g. names on the payroll, credit card numbers, etc. in un-scrambled format.
Tick 'password protect' and enter a password to protect the file. If you have already set a password, the Change option will let you change it. Note that if you do not add additional layers of security, anyone with the password can open the file and save a copy with a new password, or none at all. The batch output option also allows you to set personalised passwords on files so that each file recipient must use a separate individualised password.
All Omniscope Editions can apply time-limiting to files. This option should always be used to ensure that stale, un-refreshed copies of files are not used once distributed and potentially copied and saved in unexpected places. Ticking this option displays a settings dialog which enables you to specify the exact date/time the file will expire, whether or not an external online Internet time-check will be required (if so, the file will not work offline), an option to specify an "out-of-date please refresh" notice yet still allow access, and the message to display if recipients try to open a completely expired file.
Note: For time-limiting to be permanently enforceable, you must also tick "Owner-locking" (see above).
Server Editions can be used to add server-based authorisation/permissioning to files. Essentially, this uses the same login & password system used for web pages to control access to an IOK file. More on implementing this option is available from the KnowledgeBase article on implementing server-based permissioning [1].
Note: For web server-based file authentication to be permanently enforceable, you must also tick "Owner-locking" (see above)
Domain locking is a powerful and effective access-restriction and revenue protection feature. Omniscope .IOK/.IOM files are normally free-standing and easily transferred (by e-mail, posting/downloading from blogs and websites, etc.). Adding domain-locking to an .IOK/.IOM file imposes the restriction that the file must be opened directly from the originating (generally password-protected and secure) website. This option enables organisations to restrict access to current employees/subscribers with valid web credentials, and enables commercial data publishers to ensure that only current subscribers have access to their data, and that potentially stale, unrefreshed copies of files saved locally will not open. More information on using domain locking [2].
Note: For domain locking to be permanently enforceable, you must also tick "Owner-locking" (see above)
The option to designate a group of specific Omniscope installations able to create and share files only within the same licensing group is referred to as a 'walled garden'. Omniscope installations activated using license keys belonging to the same 'walled garden' group are able to exchange files, bit other Omniscopes, free Viewer or activated desktops, cannot open files created inside one or more (overlapping) walled garden groups. Files created by Omniscope installations within 'walled gardens' will open only in other Omniscope installations activated by keys from the same 'walled garden' list. An installation can belong to more than one 'walled garden group, which can overlap. Installations can belong to more than one 'walled garden', with different privileges in each 'walled garden'. Privileges for each installation can be set individually to Read-only or Read/Write/Create capabilities for both 'walled garden' and non-'walled-garden' .IOK/IOM files.
For more information on implementing Omniscope-based reporting in high-security settings, please contact us [3].
HTTP authentication is part of the Internet HTTP protocol and is a system for restricting access to any web resource (such as a page, set of pages or area, or (in the case of an Omniscope IOK file, any downloadable file). HTTP Authentication usually entails a pop-up prompt from the web server asking for for username and password, but should not be confused with a log-in page on a website where there is a username and password form displayed on the page itself.
HTTP URLs can be pre-encoded with the authentication information if needed, in the standard format:
"http://user:password@www.site.com/xyz"
...and if the credentials are incomplete or incorrect, the browser or application will prompt for username and password. Normally, HTTP authentication will be used in conjunction with HTTPS (encrypted HTTP) for added security, although this is not mandatory.
Omniscope supports options to use HTTP authentication to control access to data file in two ways; hosting and server permissioning [1], with the additional, tigher requirement imposed by domain-locking [2].
You can host your IOK files on your own web server securely using HTTP authentication. If the Omniscope IOK file is downloaded through the browser, the user will be prompted to enter their credentials before being able to download the Omniscope file. This standard facility is provided by the browser and the web server, not by Omniscope, although in the case that Omniscope's internal browser is used to access a URL directly, using for example File > Open > Open from web, Omniscope will prompt the user directly for the username and password required to obtain the file.
Of more interest is the ability of a downloaded Omniscope IOK file to be configured to refresh data from any online resource with HTTP authentication. For example, a locally saved IOK file containing a user's views and layouts can be configured to refresh-on-open from an HTTP-authenticated source, such as another IOK file or a CSV data file. On opening the local file, Omniscope requests a username and password and supplies these to the server. The server responds with the updated data, which may be personalised extracts tailored to that username. Omniscope then displays the updated data using the refreshed local IOK file's configured views and layout.
Even if the file has not been obtained by download for your own website...perhaps becasue it has been forwarded by e-mail, or folder synchronisation service like DropBox, GDrive etc. assuming you have Server Edition or higher, you can still configure your IOK file to use "server permissioning". Server permissioning (if configured) is a second check that Omniscope performs before allowing you to open, view and explore the file. This option is applied using the Save-as dialogue file security settings available in Server Editions or higher. To configure, you must supply an arbitrary HTTP/HTTPS URL which requires authentication. On attempting to open a server-permissioned IOK file, however obtained, on your local machine, Omniscope will still prompt the file possessor for the username and password for that URL, just as if the Omniscope IOK file were a web page on a remote server.
This allows you to restrict access to the IOK file according to the credentials required for any permissioned web server page you choose, and allows you to withdraw or change access rights to the IOK file even AFTER publishing your data. More detail on applying server-permissioing to control access to local Omnicope files is here [1].
The Domain-locking option enables commercial publishers and others to require that anyone trying to open their files must be logged in to their website, and ensures that stale copies of files cannot be saved locally and forwarded to others. Sensitive corporate data can be protected such that if users' web credentials are revoked via Active Directory/LDAP etc., they can no longer open or refresh any corporate Omniscope files they may still have copies of, because these files require http: authentication and are 'locked' to secure corporate domains. If an invalid user attempts to open a downloaded, forwarded, file-syched or otherwise locally-saved copy of a domain-locked file, Omniscope will not permit the file to open and will display an owner-configurable notice. More information on Domain locking [2]
Like password-protecting a file, Server permissioning and Domain locking options preventing unwanted users from opening a file, but depend on settings INSIDE the file, whereas HTTP Authetication on the web server does not. Therefore, once a secured Omniscope file has been successfully opened, a licensed Omniscope user can choose to save the file with internal security settings removed. To prevent this, you must also add the extra layer of security by applying 'Owner-locking' to the file. This file security setting is also available in the Save dialog in all Editions.
The Server Permissioning file security option in Omniscope allows you to save an IOK file with a URL pointing to a web server which will be used to authenticate users who try to open the Omniscope file, however they obtained it. This option can be used with Omniscope files saved to shared network folders accessible to a wider group, or to files shared via folder synchronisation services, like DropBox, or files downloaded from external web sites and perhaps forwarded.
Note: In general Omniscope files will work offline, but not if they require Server Permissioning authentication before openning
The example below describes how to set up basic Omniscope file authentication assuming the web server being used to authenticate against is running Apache. However, Server Permissioning will work with any other HTTP/HTTPS authentication server.
In your main website root directory create a new folder which can be named anything i.e. test. This new folder should be accessible from the web in the following format:
http://<domain name>/<folder name>
or
https://<domain name>/<folder name>
Where <domain name> should be replaced with the actual domain name e.g. 'www.visokio.com' and <folder name> with the name of the folder created above i.e. authentication. The final URL should look like http://www.visokio.com/authentication or https://www.visokio.com/authentication
Once the URL above is working, create an index.html/index.jsp/index.php relevant page which is just a welcome message e.g. "You have successfully logged in from Omniscope" in the folder created above. This page is shown to the user once they have successfully logged in through Omniscope and the file will then open.
The next step is to create HTTP authentication to determine which users are allowed to access to this location. First you need to create the password file with the usernames and passwords using Apache htpasswd.exe. For further information please refer to http://httpd.apache.org/docs/2.0/programs/htpasswd.html [4]
Once you have created the HTTP password file the next step is to create the .htaccess file. Create a new file called '.htaccess' in the folder created in Step 1. Open the file in Notepad and enter the authentication information please refer to Apache docs for further information [5]. For example:
AuthType Basic
AuthName "My test"
AuthUserFile "C:\Apache\htPasswdFile"
Require user test
Helpful information:
AuthType: The type of authentication
AuthName: This name is shown when asking for user credentials
AuthUserFile: Is the full path to the http password file.
Require user: This can be either 'valid-user' or certain user names from the htpasswd file. Please consult apache document for further information.
Start Omniscope open the file you wish to use this server permissioning on. Once open you can set this option by either going to File > File security > Server permissioning..., or from the Save dialog. You can also set server permissioning option from the Scheduler using the Secure File action. Once you click on the Server permissioning option enter the URL created in Step 1, save the file and test to verify that it works before deploying or sending to users.
Domain-locking is a powerful and effective file security and revenue protection feature. Whereas Omniscope IOK files are normally free-standing and easily transferred (by e-mail attachment, FTP posting/downloading from web portals/pages/blogs, via folder synchronisation services like GDrive & Dropbox, etc.), domain-locked Omniscope files have the additional restriction that they must be opened directly from one and only one originating website download, meaning that the user attempting to open the file must have a current, valid User ID and Password credentials for the originating website to which the IOK is 'domain-locked'.
The Domain-locking option enables commercial publishers and others to require that anyone trying to open their files must be logged in to their website, and ensures that stale copies of files cannot be saved locally and forwarded to others. Sensitive corporate data can be protected such that if users' web credentials are revoked via AD/LDAP etc., they can no longer open or refresh any corporate Omniscope files they may still have copies of, because these files require http: authentication and are 'locked' to secure corporate domains. If an invalid user attempts to open a downloaded, forwarded, file-syched or otherwise locally-saved copy of a domain-locked file, Omniscope will not permit this and displays this notice:
In order to domain-lock a particular file, please follow the steps listed below:
The domain restriction is a text string that specifies the top-level domain of the website you want to lock the file to. Do not enter the full web address; anything beyond just the domain will not work. For example, if you were to enter the domain "visokio.com", this would restrict the IOK file so it would only open from URLs such as:
"http://visokio.com/any/aaa/bbb/ccc/file.iok"
"http://www.visokio.com/any/path/to/file.iok"
"http://www2.visokio.com/file.iok"
If you were to enter "subdomain.visokio.com", this would restrict the .IOK/.IOM file so it would only open from URLs such as:
"http://subdomain.visokio.com/any/aaa/bbb/ccc/file.iok"
"http://www.subdomain.visokio.com/any/path/to/file.iok"
"http://www2.subdomain.visokio.com/file.iok"
If you create a link directly to the domain-locked .IOK/.IOM file, this will not work, because the user's web browser downloads the file to a temporary location before starting Omniscope and opening the local copy.
You can test that domain locking is working by starting Omniscope and choosing Open from the web from the Open file dialog, then pasting the full URL to the .IOK/.IOM file such as "http://visokio.com/any/aaa/bbb/ccc/file.iok".
To create a smoother experience for the user, it is best to create a Visokio .ILF file on the server which references the domain-locked IOK/IOM file as follows:
Here is a working example of domain-locking a file, testing the lock, than using an .ILF file link to provide access from HTML pages.
Note: this demo visokio.com domain hasn't been password protected. Your domain generally will be password-protected.
Bond Prices Demo file - domain-locked [7]
Testing the domain-locked locked-status:
http://www.visokio.com/files/Resources/OUGuide/453_FileSecurity/Bond_prices_domain_locked.iok [7]
Best practice is to link the user to the file via an Omniscope .ILF file constructed as described above:
Click here [8] to download the .ILF file pointing to the domain-locked file.
Links:
[1] http://kb.visokio.com/server-permissioning
[2] http://kb.visokio.com/domain-locking
[3] http://kb.visokio.com/contact
[4] http://httpd.apache.org/docs/2.0/programs/htpasswd.html
[5] http://httpd.apache.org/docs/1.3/howto/auth.html
[6] http://kb.visokio.com/files/Resources/OUGuide/453_FileSecurity/Bond_prices.iok
[7] http://kb.visokio.com/files/Resources/OUGuide/453_FileSecurity/Bond_prices_domain_locked.iok
[8] http://kb.visokio.com/files/Resources/OUGuide/453_FileSecurity/Bond_Prices.ilf