Nowadays, user interfaces that allow fluid and natural communication between humans and machines are gaining popularity. Many of these interfaces, commonly referred to as Conversational User Interfaces (CUIs), are becoming complex software artifacts themselves, for instance, through AI-enhanced software components that enable the adoption of Natural Language Processing (NLP) features.

CUIs are being increasingly adopted in various domains such as e-commerce, customer service, eHealth or to support internal enterprise processes, among others. Many of these scenarios are susceptible to arise security risks of both the user and the system. For instance, we may need to add security when we need:

• To disable potential queries depending on the user (e.g. a bot for a Human Resource Intranet must be careful not to disclose private data, such as salaries, unless the request comes from an authorized person).
• To execute different behaviours depending on the user. For instance, a CUI embedded into an e-learning system will provide different answers depending on the user who queries the marks (teacher or student).
• To provide different information precision for the same query depending on the user privileges. For instance, a weather or financial CUI may provide a more detailed answer to paying users.

Several works (see some examples) emphasize the importance of considering security, and especially access-control as highlighted in the above scenarios. However, we don’t have concrete solutions proposing how to add access-control as part of the definition of a chatbot or, in general, any conversational interface.

Our work, to be presented at EMMSAD’22, proposes to enrich CUI definitions with access-control primitives to enable the definition of more secure CUIs. Our solution is based on the use of model-driven techniques to raise the abstraction level at which the CUIs (and the access-control extensions) are defined. This facilitates the generation of such secure CUIs on top of different development platforms. In particular, we extend our generic CUI language with new access-control modeling primitives adapted to the CUI domain and show how this extended models can be enforced as part of a policy evaluation component.

Background

Conversational User Interfaces (CUIs) aim to emulate a conversation with a real human. The most relevant examples of CUIs are the chatbots and voicebots. A bot wraps a CUI as a key component but complements it with a behavior specification that defines how the bot should react to a given user request. The conversation capabilities of a bot are usually designed as a set of intents, where each intent represents a possible user’s goal. The bot awaits for its CUI front-end to match the user’s input text (called utterance) with one of the intents the bot implements. The matching phase may rely on external Intent Recognition Providers (e.g. DialogFlow, Amazon Lex, Watson Assistant). When there is a match, the bot back-end executes the required behaviour, optionally calling external services; and finally, the bot produces a response that it is returned to the user. For non-trivial bots, the behaviour is modeled using a kind of state-machine expressing the valid interaction flows between the users and the bot.

On the other hand, access-control is a mechanism aimed at assuring that the resources within a given software system are available only to authorized parties, thus granting Confidentiality and Integrity properties on resources. Basically, access-control consists of assigning subjects (e.g., system users) the permission to perform actions (e.g., read, write, connect) on resources(e.g., files, services). Access-control policies are a pervasive mechanism in current information systems, and may be specified according to many models and languages, such as Mandatory Access-Control (MAC), Discretionary Access-Control (DAC), Attribute-Based Access-Control and Role-based Access-Control (RBAC). In this work, we focus on RBAC, where permissions are not directly assigned to users (which would be time-consuming and error-prone in large systems with many users), but granted to roles. Then, users are assigned to one or more roles, thus acquiring the respective permissions. To ease the administration of RBAC security policies, roles may be organized in hierarchies where permissions are inherited and possibly added to the more specific roles.

Access-control framework for CUIs

Figure 1 summarizes our framework to integrate access-control on CUIs, consisting of two components:

1. The policy specification, a design time component (RBAC Policy rules in Figure 1) to enable the specification of the bot authorization policy; and
2. The policy evaluation and enforcement, a runtime component (PEP and PDP in Figure 1) in charge of evaluating and enforcing that policy upon the resource’s access from users.

Policy specification

The authorization policy is expressed via a policy language. To this end, in this paper we propose to extend a generic CUI language with new modeling primitives adding access-control semantics to CUIs. As any DSL, this extended access-control-CUI DSL is defined through two main components: (i) an abstract syntax (metamodel) which specifies the language concepts and their relationships, and (ii) a concrete syntax which provides a specific (textual or graphical) representation to specify models conforming to the abstract syntax.

Figure 2 depicts our proposal for the language metamodel, combining all the RBAC basic concepts with CUIs specific elements.

In the following, we detail the main concepts of the above metamodel.

CUI metamodel

The CUI-specific metamodel (coloured in grey in the above figure is a simplified version from the metamodel previously defined by the authors and describes the set of concepts used for modeling the intent definitions of a bot and its execution logic. The main elements of this metamodel are:

• Intents. The metaclass Intent represents the possible user’s goals when interacting with the CUI. Intents, which are a specific type of Event (as bot interactions can also be triggered by external events), can optionally have Parameters which allow defining specific characteristics of the Intent. On the other hand, intents can be triggered using several devices.
• States. Following the state-machine formalism, this metaclass models a particular behavioral state in which the bot stays until a new intent triggers a transition to another state.
• Transitions. The metaclass Transition represents the potential bot changes from one state to another. We distinguish two types of Transitions: AutomaticTransitions (triggered automatically) and GuardedTransitions (triggered when a specific guard holds). A GuardedTransition may be triggered by one or more Events and include a Constraint to be satisfied for the transition to occur. This allows a fine-grained control over the firing of the Transition

RBAC metamodel

The RBAC metamodel is an extended version of the RBAC standard to adapt it to CUIs. This is done through the definition of a set of permissions which specify which roles are allowed to perform a specific action (a match to an intent or a transition navigation to a state) on a resource (intent, transition, or state). Its main elements are:

• Resources. The metaclass Resource represents the objects that can be accessed within the CUI and that we may want to protect. In the context of CUIs, resources are basically of three types: Intents, Transitions, and States. Protecting intents will allow hiding part of the CUI’s intents to specific roles. This may be necessary, for instance, to prevent specific users from accessing some intents. On the other hand, protecting transitions and states will allow, once an intent has been matched, to execute different behaviors depending on the role who triggered the intent. This may be useful, for instance, to provide different answers for an intent depending on the role of the user.
• Subjects. The metaclass Subject represents the active entities which interact with the CUI. Following a RBAC approach, we define two kinds of subjects: Users and Roles, where users get roles assigned and role inheritance is supported.
• Actions. The metaclass Action represents the access to the resources that may be performed by the subjects of the CUI. In this context, we consider the possible actions performed by subjects are Matchings (to an intent) and TransitionNavigations (to a state of the state machine). The latter enables a more fine-grained control to the potential user interaction when needed.
• Permissions. The metaclass Permission represents the right to perform a given action (a match or a transition navigation) on a given resource (an intent, transition or state) granted to a specific role (corresponding to a CUI user).
• Constraints. The metaclass Constraint restricts the permission to execute the corresponding action only when certain conditions hold. The metaclass RoleBasedConstraint, which extends the original RBAC standard model combining a concept from the ABAC model, represents specific context-based constraints (such as geographic location or the used device) to restrict the permissions.

Policy evaluation and enforcement

Given an RBAC policy, our framework needs to combine a number of runtime components to enforce it. The recommendation in the implementation of modern policy frameworks is separating the infrastructure logic from the application logic by using a reference monitor architecture. This architecture consists in two basic components: a Policy Enforcement Point (PEP) and a Policy Decision Point (PDP). Every access action requested by an user is intercepted by the PEP that, in turn, forwards it to the PDP to yield an access decision.

Our framework follows this architecture: access requests to the bot resources (intents, transitions and states) are intercepted. These requests are then forwarded to the PDP, which reads the policy rules to resolve the access. The access decision yielded by the PDP is returned to the bot through the PEP.

Conclusions

In this work we propose a new model-driven framework for enhancing the security of CUIs by integrating and adapting the semantics of the Role Based Access-Control (RBAC) protocol to Conversational User Interfaces (CUIs). In particular, we have extended a generic CUI metamodel with RBAC primitives that enable the definition of fine-grained access control policies for all key CUI elements (such as intents, states and transitions). As can be seen in the complete paper (to be published, check the pre-print version pre-print version), we also provide a preliminary proof of concept to demonstrate the feasibility of our approach implemented on top of the Xatkit open source chatbot platform.

As further work we plan to enrich the framework with other access-control models and improve the validation and tool support of the approach. Moreover, we see this work is a first step towards the modeling of other security-related aspects for CUIs, such as DDoS, privacy, encryption, and so on.