The flexible IAM platform

Transcription

1 WHITEPAPER The flexible IAM platform Author: Nils Meulemans, CTO Date: February 2019 Version: 2.2

2 Contents TrustBuilder the first flexible IAM platform...3 IAM solutions the current state...3 A new approach the TrustBuilder ID-Hub...4 A common IAM architecture, yet a unique, easily configurable engine...6 The TrustBuilder ID-Hub a closer look...7 The TrustBuilder Gateway...8 The TrustBuilder Server...8 Orchestrator...9 Authentication Server...9 Federation Server...9 Authorisation Server Self Service and Administration Portal / API Logging and Auditing Adapters and Services Workflow Engine The TrustBuilder Repository TrustBuilder on Docker Conclusion Whitepaper The flexible IAM platform February 2019 Version: 2.2

3 TrustBuilder the first flexible IAM platform Over the past two decades, the need to safeguard data and applications has risen constantly. To keep up with the everevolving global cyber threat landscape, IT security solutions had to evolve at a great pace. This also applies to the digital gatekeeper of every web infrastructure, which controls the identities of users and what they are allowed to access: its Identity and Access Management (IAM) solution. During this time, the tasks that IAM solutions have to deal with have grown significantly. They have become complex systems. They have advanced to be able to tackle a broadening variety of issues. Yet, most of them, to the present day, have one fundamental flaw: Usually, when an IAM product is developed, the focus lies on one simple principle: the product shall become THE leading self-contained solution on the market. This is understandable as vendors aim at gaining the highest market share possible. Yet, by doing so, the product they develop understandably becomes isolated as it is not well designed to interact with the IAM solutions and components of other vendors. Also, it is usually not constructed to adapt to a customer s specific IAM requirements easily. In the ever-evolving field of IT security, this confers a significant disadvantage. In 2015, a new solution was introduced to the market: the TrustBuilder Identity-Hub (ID-Hub). It is the first and only flexible IAM platform. This means that the TrustBuilder ID-Hub can easily be connected to, and interact with, external repositories, 3rd party authentication technologies and federate with external vendor solutions. As a result, customers benefit from an IAM solution that needs fewer investments in resources and management time to keep the access to their data and applications under control. IAM solutions the current state In recent years, IAM vendors had to deal with a wide range of challenges: the quantitative and qualitative evolution of the global cyber threat landscape, the growing number of different types of applications, IT infrastructures and devices to safeguard, the steadily increasing number of users and different types of access privileges, In the context of these challenges, a broad range of different solutions were developed and put onto the global IAM market. Yet, even though advanced, these solutions also were and are still highly isolated and static. Each of them has been developed to become their customer s sole provider of IAM services. So, for their customers, integrating those IAM solutions into their existing corporate back-ends and specific applications was frequently accompanied by difficulties. the increasing usage of identity federations, and the growing demand for more customer- and userfriendly interactions TrustBuilder Corporation

4 A new approach the TrustBuilder ID-Hub The TrustBuilder ID-Hub is the first flexible IAM solution on the market. Like other IAM solutions, it provides resilient and secure IAM services. Yet, in distinction from them, its services are not solely based on its embedded technologies, but also on technologies from other vendors. Even in-house built solutions and newlyintroduced solutions can be integrated an outstanding and unique feature on the global IAM market. TrustBuilder ID-Hub is the only IAM product on the market that allows organisations to leverage the investments they have made in 3 rd party authentication technology. It allows the TrustBuilder ID-Hub to enforce the security policy that its users prefer, no matter what that policy is. Its policy engine is linked to a set of adapters, which can be connected to every internal or external authentication mechanism or back-end repository the customer requests. By using this engine and architecture, TrustBuilder s ID- Hub becomes the optimal solution for tackling today s IAM requirements. An open system architecture provides the basis for this unique flexibility: 4 Whitepaper The flexible IAM platform February 2019 Version: 2.2

5 A common IAM architecture, yet The TrustBuilder ID-Hub is provided as a software appliance consisting of three main components: the TrustBuilder Gateway, the TrustBuilder Server, and the TrustBuilder Repository. The TrustBuilder Gateway verifies, whether the client has properly authenticated and identified to access the application and whether the client has the privileges required to use the services exposed by the application. However, the TrustBuilder Gateway only enforces this process. The knowledge to make this decision lies at the TrustBuilder Server. This component knows everything about authentication, identification and authorisation policies. However, it also does not hold the key data for making these decisions. This data is stored either in the TrustBuilder Repository or in internal back-end systems that expose a standardised interface, like LDAP, SQL, REST or web services. In a development or test environment, all three components can be deployed on a single server. Yet, for production systems, it is recommended to split them for performance, security and resilience reasons. The following figure illustrates how the TrustBuilder ID-Hub is set up in a typical environment that deals with onpremises and cloud applications. This may look just like a usual set-up. Yet, in the following section, you ll understand why the TrustBuilder ID-Hub is something else a truly unique IAM solution TrustBuilder Corporation

6 a unique, easily configurable engine These days, most IAM tools hardcode policies and leave little room for variations in orchestration logic, used attributes and risk scoring. They do not provide a configurable engine that supports implementing the security policies of a customer and combining different security services. The architecture of the TrustBuilder ID-Hub has been specifically designed to deliver this feature. As basis of its authorization framework, the TrustBuilder ID-Hub uses the Request for Comments (RFC) 2904 AAA architectural framework. Originally, this framework was defined solely for authorisation purposes. TrustBuilder extends the security scope of the RFC to all three main IAM functions: authorization, authentication and identification. By doing so, all functions can interact with each other, allowing a much broader variety of granulated access control. Here are just a few examples of how TrustBuilder s combination of functions can raise the security level of a company s data and applications significantly: When giving a bank the order to transfer money by using a mobile banking application, simple PIN-based authentication can be considered secure enough. But what if the bank account the money shall be sent to is not trusted by the bank? In this case, the TrustBuilder ID-Hub can contact the user via an out-of-band channel and let him or her mark that account as trusted thereby strengthening the authentication assurance. To enter sensitive applications, users usually must pass strong multi-factor authentication, using for instance a hardware token that generates One-Time passwords. Yet, what if he or she wants to access via a mobile device? If allowed by his organization, the user can also register his or her mobile device and run a corporate mobile authentication application and use it as an alternative to its hardware token. Mobile becomes a part of the multi-factor authentication mechanism thereby, again, preserving the authentication assurance, while simultaneously rising the user-friendliness. A user accesses regular applications by using a Single-Sign-On (SSO) authentication mechanism. But what if the user wants to access applications that hold highly sensitive data? When using the TrustBuilder ID-Hub, a security guideline can be implemented that dictates that SSO sessions for such applications are restricted in time and that users must reauthenticate after periods of inactivity thereby, again, strengthening the authentication mechanism. To enable its customers to easily implement such advantages without the need to code or build complex customizations TrustBuilder developed the TrustBuilder Workflow Hooks. These exit hooks to a workflow play an integral part in many of TrustBuilder s internal Out-Of-The-Box (OOTB) concepts. They provide the capability to augment the native capabilities of the built-in product, and tailor it to the customer s needs. Using TrustBuilder Workflow Hooks, users can easily, for example: Integrate specific authentication policies into TrustBuilder s authentication offering, gather extra user information to enrich the user context within a session, perform specific identity verification check before enrolment of a new user, generate an auditing event after a specific user action. So, no matter how complex a customer wants its access control policy to be, the TrustBuilder ID-Hub can provide it. To work with the workflow hooks concept is as already said quite simple as an editor is attached: the TrustBuilder ID-Hub Workflow Editor. It enables the customer to design, simulate and deploy almost any security IAM policy by using the TrustBuilder Workflow Hooks concept. 6 Whitepaper The flexible IAM platform February 2019 Version: 2.2

7 The TrustBuilder ID-Hub a closer look As mentioned earlier, the TrustBuilder ID-Hub consists of three main components: the TrustBuilder Gateway, the TrustBuilder Server, and the TrustBuilder Repository. The following figure illustrates the threefold architecture of the TrustBuilder ID-Hub in detail. In the context of the above-mentioned RFC 2904 AAA authorization framework, the TrustBuilder Gateway plays the role the Policy Enforcement Point (PEP). The TrustBuilder Server is the Policy Decision Point (PDP) and Policy Administration Point (PAP). Finally, the Policy Information Point (PIP) is represented by the TrustBuilder Repository. Yet, also other resources that expose a standardised interface, like LDAP, SQL, REST or web services, can work as such TrustBuilder Corporation

8 The TrustBuilder Gateway The TrustBuilder Gateway usually resides in a Demilitarized Zone (DMZ) in case of external clients or behind a firewall in case of internal clients. It consists essentially of a web and API proxy. The web and API proxy sits between the client and the application. It enforces the authentication, identification and authorisation processes. However, the TrustBuilder Gateway is agnostic of the associated security policies or methods as it performs its task under control of the TrustBuilder Server. Nevertheless, it is worth to mention that the TrustBuilder Gateway has some unique authorization features: First, it allows the caching of dynamic privileges. Usually, IAM solutions only support caching of static privileges. By doing so, the performance of authorisation checks can be improved significantly. Yet, this only works when classical Role Based Access Control (RBAC) rules that define a role or group membership are in use. Attribute-Based Access Control (ABAC) rules that The TrustBuilder ID-Hub provides unmatched performance and security by applying dynamic and time-constrained caching of ABAC privileges allow dynamic privileges usually are excluded from this support. The TrustBuilder Gateway, however, has a dynamic authorisation cache on board. The combination of caching and native support of ABAC allows TrustBuilder to provide compared to traditional web reverse proxy solutions an enormous performance advantage regarding controlling inline traffic. Second, not all exposed applications share the same level of sensitivity. While caching of privileges is necessary to increase performance, for more sensitive applications the caching time should be reduced. With Timeconstrained Privilege Caching, the TrustBuilder Gateway provides a very flexible solution for this challenge. Also, finegraining time-constrained caching allows keeping control of security for very sensitive transactions. Most solutions only support a global time-out mechanism, sometimes on a per application basis, but not on a per-rule basis. The TrustBuilder Server The core security component of the TrustBuilder ID-Hub is the TrustBuilder Server. It provides the following functionalities: orchestration, authentication, federation, authorisation, self-service and administration, logging and auditing, adapters and services, and workflow engine. These functionalities are configured with a Graphic User Interface (GUI) by the administrator of the TrustBuilder ID-Hub. The following section explains how these functionalities operate to fully understand the value they provide to TrustBuilder s unique IAM solution. 8 Whitepaper The flexible IAM platform February 2019 Version: 2.2

9 Orchestration The orchestrator is the heart of the TrustBuilder ID-Hub. It picks up all requests, analyses, and forwards them to the targeted service. Furthermore, it implements all protocols that are required to communicate with these services. The orchestrator mainly deals with two types of requests: application or API access requests coming from the TrustBuilder Gateway and federated authentication requests coming from an identity or service provider. The first type of request occurs when the TrustBuilder Gateway cannot decide whether the user has the privileges to access the application or API he or she requested. Depending on the case, this will trigger the orchestrator to activate the authentication and/or authorisation server. The second type of request occurs when the TrustBuilder ID-Hub is involved in a federation scenario dealing with an identity or service provider. This could be a SAML authentication request, an OAuth authorisation request or any other standardised request dealing with SAML, OAuth, OpenID Connect or WS-Federation. In this case, the orchestrator will activate the federation server. Authentication Several common authentication mechanisms are provided OOTB by the TrustBuilder ID-Hub. Currently, the supported OOTB authentication mechanisms include: username/password, One-Time-Password (OTP) using OATH via SMS, or mobile App (TrustBuilder for Mobile), X.509-based authentication using both soft and hard tokens, and OTP using OneSpan DigiPass. Most of the rival IAM solutions support similar mechanisms. However, there is a significant difference with TrustBuilder. While most of the other vendors try to push their onboard mechanisms, it is the TrustBuilder ID- Hub policy to use these onboard mechanisms only if the customer has no other solution in place. Federation While federation standards like SAML, WS-Federation and OAuth/OpenID Connect are incompatible protocols, they do share the same foundation. Where a service provider relies on an Identity Provider to vouch for the identity and privileges of a user or client, the Federation Server of the TrustBuilder ID-Hub provides a platform that makes an abstraction of the protocol. Not only does this allow for the introduction of new standards but at the same time, it provides a framework for bridging between different protocols and authentication mechanisms. This is illustrated by two examples: An organisation might allow users access to less sensitive information on SharePoint/Office 365 by using their Facebook account. This can easily be achieved with TrustBuilder ID-Hub by bridging between OAuth and WS-Federation. An organisation wants to provide an SSO-login option for their salespersons at Salesforce. The Federation Server of TrustBuilder ID-Hub can achieve this by bridging between Kerberos (desktop sign on) and SAML. Bridging is controlled by an authentication and authorisation policy. So, instead of explicitly stating which identity provider shall allow access to which service provider, an organisation can configure implicit rules stating which authentication mechanism is required (like OTP or X.509), which information is needed (for example the verification of an address) and under which circumstances (for example an access request from an unregistered device) stronger authentication becomes necessary. Using Federated Protocol Bridging technology, TrustBuilder ID-Hub becomes your unique identity brokering solution linking any Service Provider to any Identity Provider TrustBuilder Corporation

10 Authorisation Server The authorisation server is based on the already described ABAC model. It allows specifying authorisation rules by using a regular expression that can take any attribute into account. While the authorisation model is based on XACML, the authorisation server comes with a GUI that hides the complexity of the underlying model behind a very intuitive interface as can be seen below. The authorisation server is mainly used by the TrustBuilder Gateway to control the access to web and API based applications. For making the final access control decision, any information about the user, the session and the accessed resources are accessible to the authorisation server. If there is a need for an application to support a more finegrained access control decision, it can use the authorisation API that is exposed by the authorisation server. This API is called JALT (JSON Authorisation Language for TrustBuilder). It is a simplified, yet more powerful, version of XACML. However, using the TrustBuilder ID-Hub workflow engine, it can also expose this API as XACML. Self-Service and Administration Portal / API The TrustBuilder ID-Hub provides a self-service and an administration service. These services are both available through a brandable web portal and an OAuth protected REST API. The latter allows these services to be integrated in already existing Customer-Relationship-Management (CRM) systems or internal web portal platforms a customer already has put in place. 10 Whitepaper The flexible IAM platform February 2019 Version: 2.2

11 Self-Service Some of the main features provided by the self-serviceinterface are: user registration, credential change, attribute change, credential reset with out-of-band validation, application access request, and consent management (GDPR). However, this is just a subset of the services provided. As self-service also uses the TrustBuilder Workflow Hooks concept, customers can tailor further services to their own requirements. Administration Service Some of the main features provided by the administration service are: user management, attribute management, identity and service provider management, authentication rules management, and authorisation rules management. However, also here, services can easily be extended with customer-specific requirements by using the TrustBuilder Workflow Hooks. Logging and Auditing By default, the TrustBuilder ID-Hub writes any kind of logging data into log files. These log files can be consolidated on the TrustBuilder Server or sent to syslog. It is worth to note that a powerful feature of the TrustBuilder ID-Hub is that it can selectively send any logging and auditing data to external repositories or reporting systems TrustBuilder Corporation

12 Adapters and Services Adapters Adapters are the functional building blocks of the TrustBuilder ID-Hub. They implement either a standard protocol or an API from major vendors (like Gemalto, Kobil, Oberthur, RSA, OneSpan, ). TrustBuilder Adapters and Services enable IAM policies to be broken down into microservices that can be tied together with TrustBuilder Workflows to perfectly match a customer s requirement. Services The TrustBuilder ID-Hub provides huge flexibility in managing and deploying IAM-related services. However, there will always be a special customer requirement that cannot be dealt with out-of-the-box. For this purpose, the TrustBuilder ID-Hub developed a services concept for its customers. Services extend the functionality of the TrustBuilder solution by plugging in custom Java code. Examples of commonly used security services are encryption/ decryption, signing/signature validation and integration of a Hardware Security Module (HSM). Workflow Engine Even the simplest authentication scenario can turn into a nightmare when trying to implement it with out-of-the-box functionality provided by most of today s IAM solutions. As soon as a customer wants a feature that does not 100% match the standard functionality, he or she will be forced to either make a compromise or apply some customisation to the solution. The TrustBuilder ID-Hub is the only solution on the market where this is not the case thanks to the TrustBuilder workflow engine that can be seen in action in the figure below. 12 Whitepaper The flexible IAM platform February 2019 Version: 2.2

13 The depiction, taken from the TrustBuilder Workflow Editor, shows an authentication policy supporting both username/ password and One-Time Password (OTP) authentication. The logic is simple and easy to derive. The user can log in by using a simple username/ password combination, when he or she is using an already registered device. If the device is not yet registered by the system, the user will receive an OTP at his address. When the user has logged in by entering this OTP, he or she will get access to the system and the device will be registered. This example shows how easily an authentication policy can be implemented by using the TrustBuilder Workflow Editor. It also shows how easy it would be to replace OTP delivery via by delivery via SMS or mobile App. For this purpose, the customer just would have to change the adapter. So, implementing an authentication and any other security policy is as simple as firstly breaking down this policy into micro-services that are represented by either adapters or services. In a second step, workflow hooks are used to glue these micro-services together again to form an effective IAM solution. It is as simple as that. The whole process can easily be controlled by the customer, using the TrustBuilder Workflows Editor. This approach has several unique advantages: Apart from some occasional scripting, the TrustBuilder Workflows Editor does not require any coding. The TrustBuilder Workflow Editor provides a graphical visualisation of the IAM policy. This visualisation does not require any expert knowledge. Hence, the logic can easily be understood by all kinds of business and security teams. Before putting any IAM policy into production, the TrustBuilder Workflow Editor can simulate the whole scenario. This allows detecting any anomalies that might otherwise have interrupted a company s production process TrustBuilder Corporation

14 The TrustBuilder Repository The TrustBuilder Repository contains all information that is required to run the TrustBuilder ID-Hub. As well as holding end-user information, it also stores information related to both internal and external protected applications and APIs (service providers) and information about registered internal and external authentication services (identity providers). With the TrustBuilder ID-Hub, the answer is plain and simple: No. The TrustBuilder ID-Hub can work with an empty user base if it can retrieve the user identification information from an existing internal or external source. The virtual directory technology that sits at the core of the TrustBuilder Repository makes it possible. It also uses the TrustBuilder Workflow Hooks concept, as can be seen in the figure below. Often, when introducing a new IAM solution, organisations ask: Do we have to synchronise our user data with the new repository again? The figure shows that the user s address, which would be required to be part of an SAML token being sent to an application, is retrieved from already existing repositories. For internal users, this would be Active Directory while external users would more likely be stored in an LDAP Directory. 14 Whitepaper The flexible IAM platform February 2019 Version: 2.2

15 TrustBuilder on Docker Since its inception, ID_Hub has been delivered as a software appliance, that runs all the different components described previously. The newest available form factor of the TrustBuilder ID-Hub is TrustBuilder on Docker, a solution that allows TrustBuilder customers to run their ID-Hub on container technology. To run their applications, more and more companies are switching from virtualization to container technology. Compared to virtualization, container technology saves resources, is easier to adjust and maintain, and provides a higher grade of adaptability to different platforms and devices. TrustBuilder recognized this trend and developed a solution to run its ID-Hub on this alternative, more cost-effective technology. It is operational not just in the Cloud but also On-Premises. The first container technology supported is Docker currently the most popular container technology on the market and a leader in the enterprise container platform category. Furthermore, TrustBuilder on Docker also supports orchestration solutions. As companies usually operate a large number of containerized applications, they need an orchestration solution to manage them. Docker provides Docker Swarm for this purpose. Yet, currently, two other orchestration solutions for Docker containerization are the leaders in this field: Kubernetes and Openshift. Especially large companies that need enterprise-class features often favour these two solutions. That is why TrustBuilder on Docker also supports Kubernetes and Openshift a decision that will also help mitigating customers security concerns. TrustBuilder on Docker comes with several advantages. These include among others: Reduced TCO As the containerized ID-Hub needs fewer resources than the virtualized version, the company saves a significant amount of its IT resources. Easy to implement, adjust, and maintain The development, testing, acceptance and production process of a new application is simplified as container applications can easily be transferred from one IT environment to another. Furthermore, application maintenance is significantly simplified. Automatic scaling up of containers Containers can scale up dynamically. They can adapt to peak load almost instantaneously, and offload capacity that the client does not have On-Premises to the cloud. In doing so, peak traffic can be handled easily. High security As a CIAM product vendor, TrustBuilder is committed to operating only within the most secure technologies like Kubernetes and Openshift. For Kubernetes leaves it up to its users to run their Docker containers without risky root-level privileges and Openshift does not allow them at all. Portability to cloud and On-Premises Most cloud-based infrastructure as a service- and platform as a service-solutions are compatible with Docker, allowing the containerized ID-Hub to run easily in the cloud TrustBuilder Corporation

16 Conclusion It is clear that the TrustBuilder ID-Hub is much more than just another IAM solution. It is a multi-vendor plugin and brokering framework for identity and access control a true IAM platform. It is one of the few solutions on the IAM market that has not been developed as a static standalone technology. Its product-flexible architecture and engine and its easily configurable security policy allow it to link different authentication and federation technologies together making it an IAM solution capable of interrelating with solutions of different vendors active in digital identity. By using the TrustBuilder Workflow Hooks concept and its Workflow Editor, the platform can easily be tailored and implemented to users needs. Later on, it can be enhanced to grow and evolve with its customer s access requirements. The management process is so simple, even non-coders can handle it. Most of today s TrustBuilder customers ultimately chose the ID-Hub for exactly this reason. Besides its reliability, its product flexibility and its user-friendliness are its biggest assets. Its customers know that they can rely at all times on its ability to quickly adapt to their ever-advancing access requirements. They recognize that the TrustBuilder ID-Hub is an IAM solution that is actually capable of growing with their organisation. Over 40 million users are speaking for themselves. Contact us: info@trustbuilder.com Visit us: TrustBuilder Corporation