When a prospective client approaches us about integrating our solution, often the first question they have is about how we handle data security.
So I want to share with you how Windward works with the vast array of security protocols that exist in today’s world. In this blog post you will learn how we operate in regards to security as well as the reasoning behind our methodologies.
I always like to differentiate the two distinct ways in which the Windward Solution will interact with your data. We consider secured access to come in two variations: the way Windward accesses your files (templates and report output) and the way Windward accesses the storage mediums that house your data.
When working with the Windward solution, two file types are typically generated:
- The template, designed in AutoTag.
- The actual report output, which is generated during template execution.
At the end of the day, these are all regular files that reside on a file system or repository. While we do have some clients storing their template and report output files in databases or other storage mediums, they most typically store them on a file system.
Because Windward interacts directly with the file system layer, we use the existing security that you have already built in your organization. This means there is no need to use and maintain another security layer to access Windward file components. Whether you have deployed an Active Directory or similar LDAP structure in your environment, Windward will be able to connect and interact with files stored in those mediums through a standard username and password validate or a token-based system.
For Active Directory connections, Windward can authenticate as the currently logged in session user. Or, you can choose to provide a username and password for another user setup on the system.
The same applies for LDAP connections in Unix-based environments. You just need to provide the username and password of the user who has access to the file on your target system.
Data storage comes in many different flavors and Windward is always expanding its connectivity to its already large library of data source connectors. Windward even maintains an open source library of our connectors, named Kailua, so that others can benefit from our protocol connectivity development.
(You can see a full list of the data sources that Windward currently provides. We provide a large library of SQL-based, file-based, Web-based and Big Data-based connectors.)
Windward works with your data structure connectivity in much the same way that we work with our file connectivity: we allow you to utilize the existing underlying data security structure you already have in place.
Regarding SQL-based data sources, Windward allows you to use either your current active directory session (if you are using a Microsoft SQL server) or provide a database authenticated username and password combination. The file-based connections work exactly as our file based security is described in the previous section.
When it comes to web-based and big data protocols, it gets a bit more involved as these tend to be implemented as end point services rather than a regular database authentication. OData, XML and JSON streams in particular provides some additional challenges as authentication is typical done before a connection is established and then a serialized token is provided for all communication afterwards.
Windward has recently upgraded its connectivity for these data sources to allow extra protocols to be implemented in each. Some of the protocols that Windward has added are Kerberos, RADIUS, CRAM-MD5, CHAP (MSCHAP), EAP, PAP, PEAP and PANA. These protocols can be initialed once during the initial connection and they can also be customized to allows users to extend them for transactional-based authentication by inserting custom tokens, specifically for the case of using OAUTH with OData.
Windward has also added multi-tenancy authentication for multiple-user sessions authenticating to a single end point resource.
In addition, Windward offers generic ODBC/JDBC and OleDB connections. For these connections, you often have to build the connection string yourself. We refer our clients to a very helpful website, ConnectionStrings.com, in order to assist them in gathering the proper server, communications port, database name, username and password to build the connection string for a successful connection.
A connection string will also need to be used in order to write the code to connect the Windward Engine (both .NET or Java) to your datasource. This can be easily generated in AutoTag by using our Generate Code utility in order to build a connection string from your already working connection in AutoTag.
In sum, Windward easily integrates with your existing security structure, allowing for ease of integration and maintenance. You can start working with the product without any additional security setup.
Author: Ryan Fligg
Ryan, Windward's Sales Engineer, has been with Windward since 2006 in many roles as a sales engineer, IT specialist and account executive. Ryan's background fuels his desire to guide Windward's product development. He now works on the future vision of Windward offerings through creating the product roadmap, responding to customer requests, and communicating what Windward is doing and where it’s headed.
Other posts by Ryan Fligg