CONTENTS About Tools4ever ......................................................................................................................................... 3

About Deloitte Risk Services ......................................................................................................................... 3

HelloID .......................................................................................................................................................... 4

Microsoft Azure ........................................................................................................................................ 5

HelloID Security Architecture ....................................................................................................................... 6

Scenarios....................................................................................................................................................... 8

SAML Identity Provider (IDP) .................................................................................................................... 8

Service Provider SAML (SP) ...................................................................................................................... 9

FORM post scenario ............................................................................................................................... 10

Portal Access ............................................................................................................................................... 11

Logging and Reporting ................................................................................................................................ 11

ABOUT TOOLS4EVER Since 2000 Tools4ever has offered a wide range of enterprise security-related solutions, specializing in Identity

Management. Within the Identity Management portfolio, in addition to their user provisioning solution (IAM),

Tools4ever offers a broad selection of password management products. HelloID is the most recent product in this

portfolio. Other products in the line are: password synchronization between Active Directory, Mainframe, AS/400,

Unix, Lotus Notes, SAP, etc. (PSM), password complexity within Active Directory (PCM) and self-service password

reset (SSRPM).

Thousands of clients around the world place their trust in Tools4ever and their software. The company attaches

enormous importance to the reliability and certification of its software. Tools4ever has partnerships with many

organizations with which their software is complimentary, including Microsoft, SAP, Citrix, IBM, Novell, and iGel.

Added to which, all relevant Tools4ever products are certified by Microsoft and Citrix.

Due to the fact that Tools4ever wants to uphold a high standard regarding security; the company has signed a

contract with Deloitte Risk Services. Deloitte Risk Services periodically tests HelloID for possible security issues.

ABOUT DELOITTE RISK SERVICES This document details the security structure of HelloID. To qualify and verify the security measures by Tools4ever

for HelloID, Tools4ever has setup an agreement with Deloitte Risk Services to verify these measures. Deloitte Risk

Services is the most respected party for security verification of cloud based platforms. HelloID is periodically tested

and verified by Deloitte Risk Services security professionals to make sure that HelloID complies to the highest security

standards. Every production release has passed the Deloitte Risk Services tests.

HelloID

HELLOID HelloID is Tools4ever’s Cloud single sign-on (SSO) portal solution. The primary function of this solution is to provide

unified access for end users to organizational resources, in the simplest way possible. The end user only needs to

remember one URL, instead of a unique URL for each web-based application. The end user also needs to identify

themselves only once with, for example their Active Directory Username and password, and is not required to

repeatedly enter credentials for each web-based application.

The end user first needs to authenticate themselves (login and, optionally, use two factor) before gaining access to

the portal with links to the web-based applications. The links to the web-based applications are presented as easy

to access icons to the end user. Based on the SSO functionality offered by the web-based application, HelloID uses

the correct protocol to identify the end user to the application. HelloID offers SAML SP, HTTP Post, browser plugins

and mobile device support. The diagram below shows the concept of the HelloID solution. This document details the

security setup for the components in the diagram.

Login Two factor

SMS Softtoken

Facial Social

Keycard ….

LDAP SAML

AD ADFS SQL …

E-SSOM

Plugin (CatchAll)

HTTPS POST SAML

SP JIP

End user

To be able to offer these features, HelloID needs access to the end-users’ usernames and passwords within the

organization. These credentials are stored by HelloID for future use, and are shared between the various

components of HelloID. Since these are critical organizational details, it is important that this data is managed with

the utmost care within HelloID. This white paper describes how this security is achieved within HelloID. Note: a

specific level of detail has been chosen to be shared, so that Tools4ever does not provide 100% insight, to prevent

malicious parties from understanding exactly how HelloID’s security model works and thus gaining unauthorized

access.

MICROSOFT AZURE

HelloID is hosted on Microsoft’s Azure cloud computing platform. This platform can be used to host many types of

services including webservers, databases, virtual machines, and many more. The webservers, databases, backup and

logging are all provided by Azure. Because Azure has datacenters around the world, it is possible to place the

customer database in any country desired. Tools4ever has a long lasting Microsoft Gold Partnership and has built up

specific security experience working with the Microsoft product suite.

HELLOID SECURITY ARCHITECTURE The HelloID environment consists of several components. The diagram below provides an overview of the most

important components and their interactions. Whether information is in transit or is stored (temporarily), the

information is always encrypted. The diagram shows which security mechanisms are applied for each level. The

degree of security differs per level and depends on the extent of impact, risk, and technical applicability.

Diagram

Item

Description

The Tools4ever database contains global configuration settings and customer information.

This information is encrypted using an RSA 1024 bit encryption key.

The customer database contains all of the customer specific configuration as well as the user

data. All sensitive data is encrypted using an RSA 1024 bit encryption key. Each customer has

their own separate database and encryption key. The location of the customer database

depends on the location of the customer. US based customers will use a database hosted in

the US., while customers from Europe will use a database hosted in the Netherlands.

Databases are on a continuous backup schedule. System admins can request an (incremental)

restore to any given point in time.

A

B

The HelloID webserver hosts the portal. It is hosted on Microsoft’s Azure cloud platform.

The HelloID webserver communicates with components over the internet using https. The

level of encryption is TLS 1.2, AES with 256 bit encryption.

HelloID can use various sources to authenticate users. One of these sources is Active

Directory. This feature is facilitated by the Active Directory Connector that is installed in the

organizational network. The connector does not synchronize credentials to the HelloID

portal. It only authenticates users against Active Directory on a per-use basis.

The Active Directory connector connects using https and authenticates to the portal using a

encrypted key.

The Active Directory Identity Provider is used to authenticate users from inside the corporate

network, allowing the user to log in without providing their credentials (so called integrated

Active Directory Login, AD SSO). If the user is logged on to Active Directory, the user will

automatically be logged in to HelloID.

HelloID can interact with a SAML capable Identity Provider allowing the users to authenticate

themselves in HelloID using an external Identity Provider. This method does not require any

form of credential synchronization with HelloID. HelloID does not store the credentials used

to logon to the identity provider. Authentication is purely based on SAML standards, and

HelloID redirects to the IDP portal for authentication and identification purposes. The

certificate for setting up a connection between IDP and HelloID is managed by a system

administrator of the client organization, and the certificate is stored in the customer

database. Please refer to the IDP scenario section for a detailed description of a SAML

connection with an external IDP.

No credentials or other personal information is stored locally in a browser plugin. For every

new session with an application, a request is made to the HelloID portal to verify if the user

is still logged in. A request is then made for credential details of the requested application by

the end user.

For every mobile platform (smartphones and tablets) HelloID has an app available to interact

with the HelloID portal for primary authentication and for SSO purposes on mobile websites.

The end user is required to identify themselves once in a configurable timeframe (standard

every 30 days). The timeframe can be 0 days to permanent. The IDP credentials are stored in

runtime memory. Credentials are never stored on the device. For credential management the

same mechanism as for plugins (see H above) is used. There is no local storage or caching of

application credentials.

C

D

A

E

F

G

H

I

HelloID can log on to applications using SAML. This allows HelloID to login to applications

without providing credentials. Please refer to the SP scenario section for a detailed

description of a SAML connection with an external service provider.

SCENARIOS The previous section explained the different components in the HelloID solution. This section will explain in more

detail the security items for end user authentication/SSO scenario. The main scenarios are detailed.

SAML IDENTITY PROVIDER (IDP)

The SAML IDP provides the mechanisms to identify an end user by another trusted party (the IDP). Known IDP parties

are Salesforce, Google and Amazon, but smaller/local hosting parties can also easily serve as a trusted IDP. The

protocol for IDP is SAML 2.0 and HelloID can be configured to trust the IDP. Certificates can be exchanged and set

by system administrators in the HelloID portal. The certificate information is stored in the customer database. The

diagram below shows the process flow.

1. The user accesses the HelloID portal over HTTPS. Each client will receive their own unique domain/URL.

The first step is authentication of the end user. Multiple authentication methods are available for

configuration. The diagram above explains the IDP SAML setup.

J

2. If no valid SAML session is detected, the user is redirected to the Identity Provider and is asked to identify

themselves (step 3). If a valid session is available, the end user is redirected to the HelloID portal and

applications are shown (step 6).

3. The user logs into the Identity Provider. HelloID fully trusts the authentication provided by this IDP (as

configured in HelloID).

4. After successful identification, a SAML session is created by the IDP and passed to HelloID.

5. The user is redirected to the HelloID portal and is logged in.

SERVICE PROVIDER SAML (SP)

The most common and accepted SSO mechanism for web based applications is SAML 2.0. The protocol is widely

adapted and implemented by many different software companies. HelloID can serve as a trusted IDP party for a

SAML enabled application. After successful HelloID portal authentication, HelloID will provide a SAML-session to the

SP. The diagram below shows the process flow.

1. The user browses to the HelloID portal over HTTPS. Each client will receive their own unique domain/URL.

The first step is authentication of the end user. The authentication method can vary and is not

determined by the SSO method from the portal. As an example, an end user can use the Active Directory

Connector identification and use SAML SP to SSO.

2. HelloID displays the users’ dashboard containing the applications that they can access.

3. The user chooses the service provider. (In this case Zendesk)

4. HelloID creates a SAML session and creates a session with the browser. The effective type of session is

determined by the SP. This can be a browser memory session or a session stored in a cookie.

5. The browser is instructed to redirect to the service provider.

6. The user is automatically logged into Zendesk.

FORM POST SCENARIO

The form post SSO mechanism relies on putting the username and password in the HTTP post header to the web

based application. This mechanism is also used if a user is using the normal provided login page. The login page posts

the credentials in the header (client side) and the application on server sides reads these credentials, verifies them,

and performs a login. The HelloID portal is using the same mechanism to perform SSO. The end user will experience

the same effect as with SAML (no login screen, transparent login). HelloID supports both HTTP and HTTPS, however

HTTPS is strongly preferred, as HTTP credentials are in clear text in transit. The use protocol however is determined

by the system admin setting up the HelloID configuration. The diagram below shows the process flow.

1. The user accesses the HelloID portal over HTTPS. Each client will receive their own unique domain/URL.

The first step is authentication of the end user.

2. HelloID displays the users’ dashboard containing the applications that the user can choose.

3. The user selects the application.

4. The user is redirected to the application with a form POST containing the users’ credentials.

5. The user is logged into the application.

PORTAL ACCESS Portal access may be restricted by various methods to prevent unauthorized access, hacking attempts, and/or access

outside of work hours. Access may be restricted to certain applications only. This feature is currently scheduled to

be released by the end of Q2 2016

Geographic restrictions: Ranges of IP addresses can be blocked to prevent access from certain

locations/countries. This feature increases security for companies that do not have the need to access the

portal from specified countries.

Time restrictions: Access to groups of users can be restricted based on the time of day, day of the week,

or specific dates.

Two factor Authentication: Users can be asked to perform two factor authentication based on the

previous restrictions allowing the users to login even though above restrictions apply.

LOGGING AND REPORTING HelloID logs all important events. These events include successful and failed logins, application access, and denied

access due to access policy. These events can be used to create detailed security reports. These reports may be used

to identify possible threats and/or provide an audit trail. This feature is currently scheduled to be released by the

end of Q2 2016

Reports can (among others) be created for the following scenarios:

Multiple login failures for specific accounts

Attempted access when access policies apply

Failed two factor authentication

Application access for specific account