ABOUT TOOLS4EVER ABOUT DELOITTE RISK SERVICES

Transcription

1

2 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 Portal Access Logging and Reporting... 11

3 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.

4 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. SMS Softtoken Facial Social Keycard. SAML SP JIP HTTPS POST E-SSOM HelloID Login Two factor End user LDAP SAML AD ADFS SQL Plugin (CatchAll)

5 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.

6 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 Description Item A B 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.

7 C The HelloID webserver hosts the portal. It is hosted on Microsoft s Azure cloud platform. D A E 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. F G H I 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.

8 J 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.

9 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)

10 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.

11 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 Q 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 Q 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

12