Table of Contents
The security guide aims to provide you with 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 setup and administer users on the platform.
The following diagram gives you an overview of the Sitrion 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 Sitrion Cloud platform that is hosted on the Windows Azure offering from Microsoft. Each customer of Sitrion ONE is provisioned as a tenant in the system.
The customer can access the cloud environment through the website .
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. (Please see Sitrion 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 Sitrion 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”.
The clients (phones, tablets and Windows PCs) connect to the Sitrion 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 Sitrion 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 logon page.
The Sitrion cloud environment, hosted on Microsoft Azure, communicates via a secure connection with the hub service component that is part of Sitrion ONE. The hub service is the only component that needs to be installed inside of the customer’s network. This component is provided by Sitrion 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, ...). 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 your 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.
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 - ).
The given ports for the Hub are also described in the of the Hub.
The hub service uses the RFC protocol to talk to SAP. The connection can be secured using an SNC library like SAP Crypto. When using Sitrion Authentication Mode, a user has to enter his SAP credentials for each of the SAP systems that are targeted by all applications that he has access to. He can enter these credentials on his device and they will be securely transferred to the hub service where they will be encrypted and linked with the Sitrion user account.
When using Active Directory Authentication Mode (ADFS authentication), a SAP system can be configured to use SSO via SNC. You have 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 a SAP user.
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 his Windows credentials for the SharePoint system on his device. These credentials will be securely transferred to the hub service where they will be encrypted and linked with the Sitrion 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.
All users must be authenticated to use Sitrion ONE. The Sitrion 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 Sitrion 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 Sitrion’s instance of Identity Server for the rest of their users).
Choosing which authentication option to use involves several variables. Sitrion team members 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 Sitrion ONE platform based on the response from the auth provider (e.g. the authentication response will include a unique identifier which is often email address, and if there is not a user record for this ID, the Sitrion 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 Sitrion-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 the general concepts.
- 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 Sitrion 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 login again.
- Token durations and refresh behaviors are typically controlled by the authentication provider. By default, the Sitrion-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 Sitrion ONE. In some cases, Sitrion 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.
This is one typical flow for a new user when the company is Sitrion’s instance of Identity Server. The user starts the application on his device for the first time, and is prompted to provide his company email address. Based on the email’s domain (e.g. @sitrion.com) being configured in the user’s tenant, the secure Sitrion Identity Server login page will be shown on the device and it prompts the user for his login credentials (email, password). After the user enters the credentials, the Sitrion 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.
Using Sitrion’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 he can do a batch import from a CSV – file (or users can be added by calling an endpoint on the Sitrion 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.
- Go to .
- 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
- When the user confirms his email address using the link, he will be marked as authenticated in the system and receive an initial password via email.
- The user can now logon with the provided password from his device.
- Go to .
- Login as an administrator.
- Click on “Users” in the Tenant Admin section
- Click on “Import Users”.
- Choose a file on your 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.
Users will be able to register an account with Sitrion ONE from inside the Sitrion ONE application on their device. They will be provisioned to the company’s tenant based on their email address (e.g. @sitrion.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.
Sitrion 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. Administrator users 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 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 Sitrion ONE) and Cloud Communications (creating messages and related tasks with the Cloud Comm portion of the Sitrion ONE platform).
Sitrion 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.
In order to use ADFS as an auth provider, your 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.
In order to use ADFS, a trust relationship must be created between Sitrion ONE and the customer’s ADFS server. This process is performed in coordination with Sitrion technical staff. Below are typical steps for configuring ADFS.
In the ADFS configuration, add a Relaying Party Trust and load the metadata from:
This will automatically import the required certificates onto the machine that runs the ADFS server. Afterwards, 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
Click OK to create the rule.
Sitrion is responsible to setup the corresponding rules in Sitrion ONE. After that, users should be transferred to the login page of the ADFS
As mentioned above, if a customer has implemented multi-factor authentication on their ADFS server, this will be enforced when users login in their Sitrion ONE clients.
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.
Sitrion 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:
The following questions have come up frequently in security conversations.
When using Sitrion’s instance of Identity Server, how are the password complexity rules defined and set within the Sitrion ONE logon server?
Customers can provide settings on password length and complexity which are enforced by Identity Server.
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 logon as an administrator? For example, only someone from within the company’s network could authenticate using an account with administrator authorizations?
Sitrion ONE will always use the customer-designated authentication provider. Sitrion’s instance of Identity Server does not have mechanisms to enforce these behaviors, but the customer’s enterprise auth platform may.
If a customer enterprise authentication provider is used, does it prevent the use of managing users separately within the Sitrion ONE cloud logon server?
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.
What controls, other than the username and password, are in place to prevent attackers on the Internet from authenticating with the Sitrion ONE Logon server using one of our company user accounts? I.e., are the mobile devices supplied with certificates that are trusted and used to authenticate?
With regards to things like password strength and authentication provider, customers choose based on their risk assessment of the data. Separately, Sitrion does threat assessment and regular review of the Sitrion ONE platform along with annual SOC 2 assessment to validate overall platform security.
How does the Sitrion ONE Hub ensure the authenticity of the Sitrion ONE cloud, i.e., how do you prevent other potentially malicious external sources from authenticating with the Sitrion ONE hub and masquerading as the Sitrion ONE cloud?
The Sitrion ONE Hub uses the Microsoft Azure Service Bus technology. Between the Sitrion ONE Hub and the Microsoft Azure cloud a secure relay access token is used.
I noticed there is a shared key provided. I assume the encryption uses symmetric key algorithm which may not be completely safe.
The shared key is mainly used to authenticate the Hub with your personal ONE tenant, but it’s not used for encryption.
Please elaborate more about the data at rest in Sitrion ONE cloud. Are the credentials and results data stored in Sitrion ONE Cloud ?
The main type of business data that could be stored in the Sitrion ONE cloud is “card data”. This is the data used to display cards in the Sitrion 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 Sitrion ONE production environment via the Sitrion ONE production code. So the cutomer business data is stored encrypted with no way for Sitrion personnel to read it.
User credentials for backend systems are stored in the database of the Hub, which is installed on premise. We persist user credentials using symmetric encryption in the database you 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 Sitrion ONE user.
When Sitrion’s instance of Identity Server is used, the user’s login credentials to ONE itself are stored in the cloud, but we only save 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.
What controls are in place to protect the company account passwords that are being passed through the Sitrion Cloud?
The communication between the mobile device and the Azure cloud is SSL secured. The communication between the Azure cloud and the Sitrion ONE Hub is secured by the Azure Service Bus using a secure relay access token.
In case a user has to provide backend credentials, where are these credentials stored?
The credentials are stored in the SQL database which is connected to the Sitrion ONE Hub. Based on the fact that the Sitrion ONE Hub is usually installed on premise, this SQL database itself will be most likely also in your data center. The credentials itself are of course stored encrypted.
What level of encryption does Sitrion ONE use?
Based on the different components, Sitrion 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 an own tenant.
ONE Hub: We encrypt maybe given backend credentials using AES 256bit in the Hub SQL database
Do any controls in AppBuilder use external resources or pass data through external services?
These questions are specific to the SAP Connector / Collector.
Does the solution require system/communication accounts to be present in SAP if the SAP collector is used? If so, what authorizations are required?
This isn’t required. If users access SAP through the SAP connector, their personal SAP account is used to perform the given SAP call.
Does the solution require any development or customization in the SAP landscape?
This isn’t required. Only for the SAP collector this might be required. For more details please review the documentation.
Please describe the network segment using RFC/SNC in both Sitrion authentication mode and in Active Directory authentication mode for the SAP connector.
SNC is used for Windows integration. For the “Sitrion authentication” username/password is used against SAP.