ONE Security Guide

The security guide aims to provide an overview of the security architecture of the ONE platform. It describes the different modes of authentication that can be used and gives an overview of how to set up and administer users on the platform.

Overview of the platform

The following diagram gives an overview of the ONE platform. A device-specific application is available in the respective AppStore of the mobile platform (like the Apple AppStore, Google Play, etc.).

This application connects to the ONE Cloud platform that is hosted on the Windows Azure offering from Microsoft. Each customer of ONE is provisioned as a tenant in the system.

one-security-guide.002.png

The customer can access the cloud environment through the website one.sitrion.com.

All users that have been configured with administrative rights for their respective company will see a wrench icon at the top of their screen when they log on to this address. Clicking this icon will give the user access to the administrative functions specified for them ([lease see ONE Administrative Guide for more details).

The Hub in the diagram above is an optional components which may be installed to allow communication with premises-based backend systems. The cloud tenant communicates with the ONE hub component, a windows service that needs to be installed inside the customer’s network. It needs to be able to connect to the internet and it will automatically create a tunnel using the Microsoft Service Bus technology. More details on the hub service component can be found in the section Communication between Cloud and Company Network.

Communication between Phone and Cloud

The clients (phones, tablets and Windows PCs) connect to the ONE API via a REST interface. All communication is secured using SSL certificates. Upon an incoming request to the API, a check is performed to see if the request contains a valid security token that was issued by the ONE tenant of the Azure Access Control Service. In case either there isn’t a token present or the received token is invalid (e.g. due to timeout), the client will be redirected to a login page.

Communication between Cloud and Company Network

The ONE cloud environment, hosted on Microsoft Azure, communicates via a secure connection with the hub service component that is part of ONE. The hub service is the only component that needs to be installed inside the customer’s network. This component is provided by ONE in form of an MSI file that needs to be installed on a machine (real or virtual) that can access the internet and also all backend systems that you want to enable for mobile consumption (SAP systems, Microsoft SharePoint, etc.). The hub service is implemented as a Windows service that will be set by the installer to automatically start.

The user account that hosts the service may need to be adjusted depending on single sign-on (SSO) needs. Further information can be found in the Communication between Hub and SAP and Communication between Hub and SharePoint sections at the end of this document.

The hub service uses a SQL database configuration.

one-security-guide.003.png

Troubleshooting tip

Should the hub service fail to connect to the cloud environment, consult the following documentation provided by Microsoft. It describes additional measures, like opening a set of ports in the firewall (hosting behind a Firewall with the Service Bus - http://msdn.microsoft.com/en-us/library/azure/ee706729).

The given ports for the Hub are also described in the Prerequisites of the Hub.

Connection from the Hub Service to SAP (RFC)

The hub service uses the RFC protocol to talk to SAP. The connection can be secured using an SNC library like SAP Crypto. While using ONE Authentication Mode, a user has to enter their SAP credentials for each of the SAP systems that are targeted by all applications that they has access to. They can enter these credentials on their device and they will be securely transferred to the hub service where they will be encrypted and linked with the ONE user account.

When using Active Directory Authentication Mode (ADFS authentication), an SAP system can be configured to use SSO via SNC. The user has to create a trust relationship between the SAP system and the machine where the hub service is installed. When a request is made against SAP, the user’s Windows identity that is part of the security token will be passed to SAP where the user needs to be mapped to an SAP user.

Connection from the Hub Service to SharePoint

The connection to SharePoint from the hub is made using the SharePoint client API and the web services that SharePoint provides. When direct calls will be made to SharePoint, a user has to enter their Windows credentials for the SharePoint system on their device. These credentials will be securely transferred to the hub service where they will be encrypted and linked with the ONE user account. When a request is made against SharePoint, the user will be impersonated using the stored credentials. This way, the SharePoint security is enforced correctly for the user.

Authentication

All users must be authenticated to use ONE. The ONE platform can be configured to use one or more different authentication providers. The most typical configuration is that a customer has an enterprise authentication provider (e.g. ADFS, Azure AD, Ping, Okta, Centrify, etc). Another common case is that ONE will provide an authentication service for the customer. The third pattern is that a single customer will use more than one authentication provider (possibly their own enterprise service for some of their users and ONE’s instance of Identity Server for the rest of their users).

Choosing which authentication option to use involves several variables. The Customer Success Manager can guide customers through this process. In cases where the customer’s enterprise auth platform is used, user accounts will typically be created automatically in the ONE platform based on the response from the auth provider (e.g. the authentication response will include a unique identifier which is often an email address, and if there is not a user record for this ID, the ONE platform will create a new user automatically). For cases where Identity Server is being used, it is possible to create user records by uploading data (manually or via API) or by users creating their own accounts through the initial login.

The sections below give some information about the authentication and user provisioning processes related to the ONE-operated instance of Identity Server and ADFS. As noted above, many different auth providers can be used including basically any that support SAML or OpenIDConnect. There are also variations that can apply to user onboarding depending on what information the customer has available about their users. These sections just give examples to convey general concepts.

Additional Notes

If a customer requires multiple factors (e.g. a time-based code in addition to username and password) on their enterprise authentication provider, users will need to provide all these elements when authenticating. The ONE clients are simply showing the login screen from the authentication provider.
Regardless of what authentication provider(s) the customer chooses, PIN/TouchID protection can be enabled on the native clients. When this is enabled, users will be challenged for a PIN or fingerprint when the client launches. When this challenge is successfully passed, the client will check to see if it has a valid security token (i.e. the user has logged in previously and been issued a token which lasts several days). If a valid token exists, the user will not be challenged to log in again.
Token durations and refresh behaviors are typically controlled by the authentication provider. By default, the ONE-operated Identity Server will silently refresh the authentication token of a user for up to 30 days, provided the user logs in at least once every seven days. If a user has been disabled, the refresh flow will not grant a new token and the user will not be able to access ONE. In some cases, ONE can be configured to grant a longer timeout duration token than the customer enterprise authentication system grants by default (e.g. a 10-day timeout instead of a 24-hour timeout). This is only ever done based on specific guidance from the customer.

ONE Identity Server Process

This is one typical flow for a new user when the company is ONE’s instance of Identity Server. The user starts the application on their device for the first time and is prompted to provide their company email address. Based on the email’s domain (e.g. @limeade.com) being configured in the user’s tenant, the secure ONE Identity Server login page will be shown on the device and it prompts the user for their login credentials (email, password). After the user enters the credentials, the ONE Identity Server creates a security token. In the diagram below, the user continues on in step 3 to provide additional credentials for accessing backend systems through the Hub. When a request is made to one of those systems (as represented in step 4), those credentials (which were stored securely in the Hub) are used to authenticate with the backend system.

one-security-guide.004.png

Adding Users to a Company (Identity Server)

Using ONE’s instance of Identity Server, there are different ways to add users to the platform. A company administrator can add users manually using the management portal or they can do a batch import from a CSV file (or users can be added by calling an endpoint on the ONE platform). Another way to add users is to allow users to sign up themselves using a mobile device. The following will describe these methods in more detail.

Add Users manually

Go to one.sitrion.com
Login as an administrator
Click on Users in the Tenant Admin section
Click on Create User
Fill out the pop-up form and choose a role for the user
A confirmation email containing a link to enable the account will be sent to the provided
email address
When the user confirms their email address using the link, they will be marked as authenticated in the system and receive an initial password via email
The user can now login with the provided password from their device.

Batch import of Users

Go to one.sitrion.com
Login as an administrator.
Click on Users in the Tenant Admin section
Click on Import Users
Choose a file on the local machine that confirms to the CSV file format that is shown on the popup
Click on import to start the import process. (This may take a while, depending on the size of the file.)
Each user in the file will need to follow steps 6 – 8 as described above under Add users manually to complete the process.

Sign up Through the Device App

Users will be able to register an account with ONE from inside the ONE application on their device. They will be provisioned to the company’s tenant based on their email address (e.g. @limeade.com). Users that sign up this way are created in the system and will be activated automatically. All users that sign up this way will automatically be assigned to the default role for their company.

Account Types

ONE distinguishes between two different account types: normal users and administrators. Normal users can log on using their device and access their respective applications. They cannot log on to the management portal. Administrators have the same rights as normal users, but also can access administrative functions (they have the wrench icon at the top of the screen at http://one.sitrion.com that allows them to access administrative UI’s). Administrative users can have a wide variety of permissions within Tenant Administration (controlling settings for their company use of ONE) and Cloud Communications (creating messages and related tasks with the Cloud Comm portion of the ONE platform).

Active Delivery Federation Service (ADFS) Authentication

ONE supports ADFS (along with many other options) as an enterprise authentication provider. Users will be provisioned for the platform based on the responses from ADFS, and there is no need to configure users via the management portal.

one-security-guide.005.png

Requirements

In order to use ADFS as an auth provider, a company needs an Active Directory and must have the Active Directory Federation Service (ADFS v2) installed. ADFS is supported on Windows Server 2003 and higher.

The ADFS server needs to be accessed via internet. Microsoft offers a special proxy for ADFS to more easily enable this scenario. More information on this topic can be found in the Microsoft documentation.

Setup

In order to use ADFS, a trust relationship must be created between ONE and the customer’s ADFS server. This process is performed in coordination with the Limeade technical staff. Below are typical steps for configuring ADFS.

one-security-guide.006.png

In the ADFS configuration, add a Relaying Party Trust and load the metadata from:

https://sitrionone.accesscontrol.windows.net/FederationMetadata/2007-06/FederationMetadata.xml

This will automatically import the required certificates onto the machine that runs the ADFS server. Afterward, click on the newly created relaying party and right-click > Edit Claim Rules.

On the dialog, click on Add claim rule and select Send LDAP Attributes as Claims from the dropdown
list. Create the mapping as it is shown in the following screenshot

one-security-guide.007.png

Click OK to create the rule.

Limeade is responsible for the setup of the corresponding rules in ONE. After that, users should be transferred to the login page of the ADFS

Multifactor Authentication

As mentioned above, if a customer has implemented multi-factor authentication on their ADFS server, this will be enforced when users login in their ONE clients.

Customizing the Login Experience

The ADFS server provides the login pages that the end-users will see on their device. These pages are simple ASP.NET pages that can be customized to render better on a mobile device. With the help of media queries, a device-dependent rendering of the login process can be created.

FAQ

ONE is a cloud-based solution, which is hosted on Microsoft Azure.

General questions in regards of the Microsoft Azure datacenter are mainly covered on Microsoft’s Windows Azure Trust Center: http://www.windowsazure.com/en-us/support/trust-center

General

The following questions have come up frequently in security conversations.

Q: When using ONE’s instance of Identity Server, how are the password complexity rules defined and set within the ONE login server?

A: Customers can provide settings on password length and complexity which are enforced by Identity Server.

Q: Is there a way to require the use of a token to authenticate as an administrator and/or the ability to limit the source IP address that is able to login as an administrator? For example, only someone from within the company’s network could authenticate using an account with administrator authorizations?

A: ONE will always use the customer-designated authentication provider. ONE’s instance of Identity Server does not have mechanisms to enforce these behaviors, but the customer’s enterprise auth platform might.

Q: If a customer enterprise authentication provider is used, does it prevent the use of managing users separately within the ONE cloud logon server?

A: Controls within ONE around users can still be managed through the ONE admin UI, but authentication for these users will always come from the customer auth provider.

Q: What controls, other than the username and password, are in place to prevent attackers on the Internet from authenticating with the ONE Logon server using one of our company user accounts? For example, are the mobile devices supplied with certificates that are trusted and used to authenticate?

A: With regards to things like password strength and authentication providers, customers choose based on their risk assessment of the data. Separately, Limeade does a threat assessment and regular review of the ONE platform along with annual SOC 2 assessment to validate overall platform security.

Q: How does the ONE Hub ensure the authenticity of the ONE cloud, i.e., how do you prevent other potentially malicious external sources from authenticating with the ONE hub and masquerading as the ONE cloud?

A: The ONE Hub uses the Microsoft Azure Service Bus technology. Between the ONE Hub and the Microsoft Azure cloud a secure relay access token is used.

Q: I noticed there is a shared key provided. I assume the encryption uses a symmetric key algorithm, which may not be completely safe.

A: The shared key is mainly used to authenticate the Hub with a company's personal ONE tenant, but it’s not used for encryption.

Q: Please elaborate more about the data at rest in ONE cloud. Are the credentials and results data stored in ONE Cloud?

A: The main type of business data that could be stored in the ONE cloud is card data. This is the data used to display cards in the ONE productivity stream. This data is encrypted with a customer-specific encryption key. That key, in turn, is encrypted with a master key which can only decrypt the customer key in the ONE production environment via the ONE production code. So the cutomer business data is stored encrypted with no way for ONE personnel to read it.

User credentials for backend systems are stored in the database of the Hub, which is installed on-premise. Limeade persist user credentials using symmetric encryption in the database mentioned on the on-prem server. However, there’s no interface for the cloud to retrieve those passwords so the password never leaves the company’s internal network when accessing back-end systems.

The cloud itself contains configuration data like the assignment of micro-apps/cards to roles, endpoint definitions and it contains the ONE user.

When ONE’s instance of Identity Server is used, the user’s login credentials to ONE itself are stored in the cloud, but Limeade only saves a hash of the password.

On action cards, the action gets executed directly through the Hub to the given backend system. This data doesn’t get stored in the cloud or in the client.

Q: What controls are in place to protect the company account passwords that are being passed through the ONE Cloud?

A: The communication between the mobile device and the Azure cloud is SSL secured. The communication between the Azure cloud and the ONE Hub is secured by the Azure Service Bus using a secure relay access token.

Q: In case a user has to provide backend credentials, where are these credentials stored?

A: The credentials are stored in the SQL database which is connected to the ONE Hub. Based on the fact that the ONE Hub is usually installed on-premise, this SQL database itself will be most likely also in the data center. The credentials themselves are, of course, stored encrypted.

Q: What level of encryption does ONE use?

A: Based on the different components, ONE has different types of encryptions in place:

SSL: TLS 1.2, connection encrypted with AES 256 CBC, SHA1 for message authentication and ECDHE RSA as the key exchange mechanism.
Cards: The content of cards, which lives in the cloud, is encrypted card content with Rijndael (AES) - 256-bit key. The ONE cloud encryption uses dynamically generated keys per tenant. In general, each customer has their own tenant.
ONE Hub: Limeade encrypts maybe given backend credentials using AES 256bit in the Hub SQL database

Q: Do any controls in AppBuilder use external resources or pass data through external services?

Yes. The map control is powered by Google and uses javascript housed on their servers. Also, depending on the client, links to certain document types (e.g. pdf) can cause the document to be sent through Google’s proxying services. If there are concerns about these cases, please talk to the Customer Success Manager directly.

SAP Connector/Collector

These questions are specific to the SAP connector/collector.

Q: Does the solution require system/communication accounts to be present in SAP if the SAP collector is used? If so, what authorizations are required?

A: This isn’t required. If users access SAP through the SAP connector, their personal SAP account is used to perform the given SAP call.

Q: Does the solution require any development or customization in the SAP landscape?

A: This isn’t required. Only for the SAP collector, this might be required. For more details please review the SAP collector documentation.

Q: Please describe the network segment using RFC/SNC in both ONE authentication mode and in Active Directory authentication mode for the SAP connector.

A: SNC is used for Windows integration. For the ONE authentication, username/password is used against SAP.

Articles in this section