ON THIS PAGE:
Standard Configuration
The Field Operator Conduit web service is a mechanism for the Field Operator server software to respond to request from the remote device.
For many companies, the devices in the field will not have access to resources on the corporate domain. Field Operator devices communicate with the Field Operator Server Instance via the Field Operator Conduit web service. The purpose of this service is to eliminate the need for devices to be inside the corporate firewall to sync data. Setting up and connecting to a corporate VPN on am iPhone or iPad or even some windows devices can be time consuming and can cause extra support time for IT professionals. With the conduit, a user simply needs to be connected to the Internet to use the system.
The conduit is a secure web service (currently hosted in AWS) which does not store any data but simply acts as messaging mechanism between the remote device and the Field Operator Server. The web service is secured via HTTPS and HMAC encrypted authentication tokens.
Although not an exact parallel, the conduit service can be thought of as a chat service. The Field Operator Server and the mobile device need to have a conversation. Since they are not directly connected to each other, each computer will send and request messages to the service. The service holds a (compressed and encrypted) message only until the intended recipient receives it. In the case where a communication connection is lost, for example if the mobile device loses its internet connection, the conversation is abandoned, and messages are cleared after a short timeout period.
It is important to note that the conduit does not make calls to the Field Operator Server, only receives requests from the Field Operator Server and remote devices. No firewall tunnelling or port opening is required as the Field Operator Server is simply making outbound https calls to the web service.
Alternative Configurations
For your implementation, you can decide to use the P2 publicly available conduit web service, or you can decide to implement the service internally.
Note: If you’d like to explorer installing your own copy of the Conduit web service, please contact P2 to obtain the Zip Deploy and to arrange for our professional services organization to assist you.
If installing the conduit service behind your firewall, devices will need to connect to your internal network (likely through VPVN). Your mobile device management system may offer VPN technology which allows users to connect to resources behind the corporate firewall. In this case the entire system may be “on premise” since the devices have access to on site resources.
Field Operator Conduit – Frequently Asked Questions
How does the server talk to the Conduit?
Via https calls. There are special headers required on the endpoints that are only understood by P2’s code. The server is executing two types of calls:
1. Push a message to a queue and
2. Check the queue for return messages
The Conduit service utilizes “long-polling” which allows the server to request data continuously.
How does the client talk to the Conduit?
Via https calls. There are special headers required on the endpoints that are only understood by P2’s code. The client is executing two types of calls:
1. Push a message to a queue and
2. Check the queue for return messages.
Note: once a message is retrieved by the other side of a conversation it is deleted from the queue. If the other side of the conversation does not retrieve the message within 15 minutes, the message is also deleted.
How does the client talk to the server?
Indirectly through the Conduit. The client makes HTTPS calls to the Conduit to push a message to a queue or to request any data that’s waiting in its queue
How does the Conduit talk to the Server?
It doesn’t. The server makes HTTPS calls to the Conduit to request any data that’s waiting in queues or push data to queues for waiting clients. All communication to the Conduit is inbound https calls. The Conduit never initiates contact to any other component in the system.
How does server talk back to client?
Indirectly through the Conduit. The server pushes messages to a queue in the conduit and the client retrieves the messages from the Conduit. All communication from the server is an outbound https get or post to the Conduit.
What role does AWS play?
Our P2 conduit web service is deployed to AWS using AWS Elastic Beanstock virtual machines. The Conduit also utilizes AWS SQS queues for messages in transit and AWS S3 buckets for images.
How does the password authentication work?
The password is entered into the device by the user, encrypted and sent (via Conduit queues) to the server. The server checks the account and password against Active Directory using the .net System.DirectoryServices.AccountManagement.PrincipalContext assembly. Once authenticated the password is no longer stored anywhere in the system and a token is used for further communication. (See diagram above).
Where are these passwords stored (on the server, database, client side)?
Nowhere. The password is only passed once (in an encrypted state) during the authentication process.
Is everything encrypted as it passes between client and server?
In transit, yes, the data is encrypted. But the production data is not encrypted in storage on the server or the device. If a customer requires the production data to be encrypted in storage, we recommend implementing a Mobile Device Management solution.