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 even more natural interactions with the possibility to use advanced Natural Language Processing (NLP) components embedded in chatbots or voicebots.
CUIs are being increasingly adopted in several domains such as ecommerce, customer service (as a direct communication channel between the company and end-users), eHealth (to automatize healthcare) or to support internal enterprise processes, among others. However, many of these domains are susceptible to trigger access-control risks. For instance, the following scenarios may cause several risky situations:
- Scenario 1: A bot for a Human Resource Intranet could disclose private data, such as salaries, to an unauthorized person;
- Scenario 2: A CUI embedded into an eLearning system could provide the same information for both teachers and students, although they have different roles and different needs; or
- Scenario 3: A CUI acting as the interface to a paying service could provide the same enriched answers to the non-paying users and the paying ones.
To avoid the above situations, we need to ensure the CUI is able, for instance, to disable potential queries for certain user profiles (scenario 1), to provide different answers for the same query depending on the user role (scenario 2) or to provide different information precision levels for the same queries depending on the user-specific privileges (scenario 3).
Several works (see some examples here) emphasize the importance of considering security, particularly access control in the definition of CUIs, as highlighted in the scenarios mentioned above. While some approaches exist to enhance security in general UML models or within specific contexts, such as web interfaces, we are lacking concrete solutions for enriching CUIs with robust access control mechanisms. Achieving a comprehensive intent-based control system that could be integrated with other components as part of a multiexperience user interface, which could be built together by using a Multiexperience Development Platform (MXDP), is still a remaining challenge.
To cover this gap, in our paper Modeling and enforcing access control policies in conversational user interfaces, co-authored by Elena Planas, Salvador Martínez, Marco Brambilla and Jordi Cabot, recently published in the International Journal on Software and Systems Modeling (SoSyM) and available in open acces, we propose to enrich CUI definitions with access-control primitives to enable the definition and enforcement of security policies. 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 model-based generation of such secure CUIs on top of different bot development platforms. This security extension was regarded as needed in other domains such as web services, XML documents or Internet of Things. This work enables the same type of support for the new type of interface that CUIs represent.
Our framework (see Fig. 1) is composed of two main components: (1) a design time component (right part of the figure) to enable the specification of the CUI authorization policy and decide on the evaluation strategies; and (2) a runtime component (left part of the figure) in charge of interacting with the user and, based on the specified policies, act accordingly either by allowing or denying the access to the resources depending on the user permissions.
Figure 1. Framework Overview.
Contents
Background
Conversational user interfaces (CUIs) aim to emulate a conversation with a real human. The most relevant examples of CUIs are 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. Bots are classified in different types depending on the channel employed to communicate with the user. For instance, in chatbots the user interaction is through textual messages, in voicebots is through speech, while in gesturebots is through interactive images. Note that in all cases bots are the mechanism to implement a conversation, it just changes the medium where this conversation takes place. The conversation capabilities of a bot are usually designed as a set of intents, where each intent represents a possible user’s goal when interacting with the bot. 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 or Watson Assistant). As part of the match, one or more parameters (called also entities in the bot terminology) in the user utterance can also be recognized, in a process known as named entity recognition. When there is a match, the bot back-end executes the required behavior, optionally calling external services; and finally, the bot produces a response that it is returned to the user. For non-trivial bots, the behavior 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, but also any active entity which may interact with it) 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 different 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.
Running example
In the following, we introduce a simplified version of an ecommerce chatbot, which will be used as a running example in the remainder of this post. Broadly, an ecommerce bot (see Fig. 2) interacts with the user to provide customer service, answer questions, recommend products, gather feedback, and track engagement, among many others. The simplified ecommerce chatbot we use in this paper addresses the user intentions described in Table 1.
Figure 2. ecommerce chatbot interaction with an anonymous user (left) and an employee (right).
| Intent | Description |
|---|---|
| 1. Find product | Searches for a product within the catalogue |
| 2. Get product details | Returns information about a product |
| 3. Buy product | Records an order |
| 4. Update shop catalogue | Updates the product catalogue |
Table 1. Intents of our ecommerce chatbot.
The user intentions match the corresponding chatbot intents and prompt the bot to trigger a specific behavior in response. This execution logic is specified using the UML state-machine formalism, which allows expressing the valid (conversational or event-driven) interaction flows between the user and the bot. The state-machine of our ecommerce chatbot (see Fig. 3) includes an initial state (Greet user), where the bot greets the user, after which automatically navigates to the main menu awaiting for a user request. In case the user request matches with the find a product intent, a transition to the Find product state is navigated. Once in that state, the user can ask for additional product details or go back to the main state. The same logic is applied to the rest of the states.
Figure 3. ecommerce bot state machine.
Clearly, not all intents of this ecommerce bot should be available to all users, as the bot is serving both internal and external users of the shop and, for instance, as can be seen in Fig. 2, we do not want external users to be able to modify the shop catalogue (or they could lower the price of a product before buying it).
Therefore, we should add proper access control to manage who is entitled to do what on which resource and protect the others. To this end, in this example, we differentiate between three roles (anonymous, registered, and employee), each of them able to interact with different resources according to the permissions detailed in Table 2. Note that the permissions do not only restrict what intents can be matched but also the possible navigational transitions and reachable states for a matched intent depending on the role.
| Role | Type | Permission |
|---|---|---|
| anonymous | Intent | Find product |
| Get product details | ||
| State | Greet user | |
| Show main menu | ||
| Find product | ||
| Get basic product details | ||
| Transition | from Greet user to Show main menu | |
| from Show main menu to Find product | ||
| from Find product to Get basic product details | ||
| from Find product to Show main menu | ||
| from Get basic product details to Find product | ||
| registered | All | GRANT ALL Permissions (ecommerceBot) |
| EXCEPT FOR | ||
| Intent Update shop catalog | ||
| State Get basic product details | ||
| employee | All | GRANT ALL Permissions(ecommerceBot) |
Table 2. ecommerce bot policy rules
For instance, according to these permissions, an anonymous user can only match two intents (Find product and Get product details) but, when matching the latter, an anonymous user will only be able to follow the transition leading to the Get basic product details as only registered users can see the full product details. On the opposite side, the employees have full permissions to use all types of the resources, while registered users can use all the resources, including buying products, except for the update of the catalogue (reserved to employees only) and the state Get basic product details, as registered users access the improved version on this state.
Note that, as can be seen in Table 2, to simplify the assignment of permissions, we can use global permissions that grant access to all bot components to a role including the potential use of an except for clause where we could list the few exceptions on a global role (when listing the exceptions we skip listing all impossible transitions, i.e. transitions between two states where at least one of them is not reachable by the role).
Modeling access-control policy rules for CUIs
The first part of our framework (see Fig. 1 right) consists of a design time component to enable the specification of the CUI authorization policy. This authorization policy is expressed via a policy language. To this end, in this paper we propose to extend a generic CUI language, based on our previous work, with new modeling primitives, inspired by other RBAC-like languages and tailored to the CUI domain, to add access-control semantics to CUIs.
As any DSL, this extended access-control-CUI DSL is defined through two main components:
- an abstract syntax (metamodel) which specifies the language concepts and their relationships, and
- a concrete syntax which provides a specific (textual or graphical) representation to specify models conforming to the abstract syntax.
Both aspects are platform-independent. This enables the analysis of the access-control information disregarding the specificities of the concrete CUIs security features and implementation and its deployment on top of different authorization libraries depending on the needs of the system as explained later.
In the following, we describe these elements in more detail, after an initial review of the core CUI modeling language that we are extending.
Figure 4. Access-control CUIs metamodel.
CUI metamodel
The CUI-specific metamodel part (colored in gray in Fig. 4) is a simplified version of the metamodel defined by the authors our previous work 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 goal 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 from several devices (which could also be restricted as part of the security policy).
States. Following the state-machine formalism, the metaclass State 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 evolutions 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 fine-grained control over the firing of the Transition.
Matchings. This part of the metamodel can be used to track the user requests at runtime and link them with the matched intents and recognized parameters. This is useful for the evaluation of the policies but could also be used for logging purposes. In particular, the metaclass UserRequest represents the user utterances, which may match with one or more Intents. In order to contextualize the requests and apply access-control we add several parameters such as the location and timestamp of the request. Each recognized intent is represented by the MatchedIntent metaclass, which stores the level of recognition confidence provided by an external intent recognition provider. For each Parameter of an Intent, the corresponding MatchedIntents keep its value in the association class ParameterValue. Each of these ParameterValues corresponds to a specific text fragment of the analogous UserRequest which has derived the MatchedInput.
RBAC metamodel
The RBAC metamodel part is an extended version of the metamodel presented in our previous work and extends the standard RBAC concepts mentioned in the Backgound to adapt it to CUIs. This is done by weaving the RBAC and CUI concepts through the definition of a set of permissions that 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 (intents, transitions, states, or all of the above). Its main elements are:
Resources. The metaclass Resource represents the objects that are part of a CUI and that we may want to protect. In the context of CUIs, we consider that resources are basically the different components of the bot, which can be of three types: Intents, Transitions or States. Protecting intents will prevent some roles matching part of the CUI’s intents. This may be necessary, for instance, to prevent specific users from asking for some specific functionality (if they do not have permissions to match the intent, their request will not be recognized by the bot). On the other hand, protecting transitions and states will allow, once an intent has been matched, to execute different behaviors depending on the role that triggered the intent. This may be useful, for instance, to provide different answers for an intent depending on the role of the user. We expand on this in the Action description below.
Note that, to simplify the definition of policies, we also consider the whole Bot as a resource itself. This enables granting certain roles permission for the whole bot, especially useful for roles that must be able to perform any action on any bot component, as is the case with the employees in our running example. This kind of GRANT ALL level permission follows the standard semantics of this type of permission as proposed in the database realm. Besides, for roles that should have almost all permissions, we can add an except for clause listing those bot components to whom the grant all permission does not apply. These global permissions will then be unfolded during the generation process and converted into a set of individual policies over concrete components as the other policies to simplify its treatment and provide a homogeneous environment for the policy enforcement mechanism.
Subjects. The metaclass Subject represents the active actors which interact with the CUI. Following an RBAC approach, we define two kinds of subjects: Users and Roles, where users get roles assigned. Role inheritance is supported. To stick to a pure RBAC approach, permissions cannot be assigned to individual users. Nevertheless, it is always possible to create a role that only such user would have and assign permissions to that role if needed.
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 as main possible actions performed by subjects are Matching an intent, Reaching of a state and Navigating (i.e., traversal) a transition. We would like to remark that, while the above list of actions are the most common ones, we could define additional ones. For instance, a Read action for intents. If we grant a role a Read action permission over an intent, the users with that role will be able to see the intent exists (e.g., as part of help functions) but will not be able to match it (similar to the concept of gray/disabled buttons or options in a Graphical User Interface). This could be used to push the user to perform the actions required to acquire more permissions (e.g., register in the web application).
Permissions. The metaclass Permission represents the right to perform a given Action (matching an intent, reaching a state or navigating a transition) on a given Resource (an intent, state or transition) granted to a specific Role (corresponding to a CUI user). Intent permissions enable users to trigger a bot behavior for certain intentions. State permissions control whether a certain state can be reached or not (even when an intention could lead the user to such state, if that is the case and the intent is matched, the user will be redirected to a different state also linked to the same intent or it will just stay in the same state if no alternative is available). Finally, transition permissions enable a more fine-grained control of the potential user interactions when needed; indeed, even after the match, we can restrict to which state that match should move the user to (e.g. even when a role has permissions to reach a certain state we may want to control the path a user with a given role has to follow to reach that state preventing the transition of navigations that could reach that same state but via other paths).
In order to easily define large permissions, our metamodel allows defining an All special permission at the bot level, implying that the role with such global permission will be able to perform all types of actions on the bot components. This can be expressed by relating the permission directly with the Bot metaclass, which includes all its components. Besides, our metamodel allows limiting these global permissions through the relationship exceptFor, which allows defining which resources of the bot will not be part of the global permission assigned to a specific role.
As we will see later, we can add a WFR to ensure that the bot components of an exceptFor relationship are part of the bot to which the permission that holds the exception is related to.
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 to restrict the permissions. Our metamodel explicitly includes some predefined types of constraints regarding the geographical location, the temporal periods when the user can express a certain request, the allowed devices for doing so or even the possible set of values for the parameters to be matched during the Intent recognition phase. But many other ad-hoc constraints could be defined as well using a generic constraint language such as OCL.
Concrete syntax
As mentioned before, domain-specific languages are usually equipped with a concrete syntax that enables users to create instances (i.e. models conforming to the DSL) without dealing directly with the abstract syntax.
In this case, we decided to provide our language with a textual syntax instead of a graphical or form-based one, as we believe it results in more compact policy specifications that are easier to create and understand. Nevertheless, we could have several alternative concrete syntaxes for the same metamodel, so it would be equally possible to define a graphical syntax for our language or even a mix of the two.
Textual syntaxes are defined via a grammar. As explained in more detail in the Modeling editor for RBAC policies section, our grammar is created with Xtext, a state-of-the-art language workbench. Thanks to the Xtext support we can provide advanced editing facilities to the bot designers interested in using our access-control language for their CUIs, e.g. to help them in the creation of valid instances.
As we will see in more detail later, Listings 3 and 4 show, respectively, the grammar for our language and a partial representation of the policy rules for our running example written in this grammar.
Policy validation and correctness
The correctness of a policy can be defined and checked at different levels.
The first level is to verify a policy is well-formed, i.e., to check that it is properly aligned with its metamodel and can be expressed as an instance of such metamodel. This is guaranteed by our implementation (see below). This would cover basic structural validations like the fact that permissions cannot be directly linked to users as there is no relationship between the Permission and User classes in the metamodel.
Additional well-formedness rules can be added by attaching to the metamodel OCL constraints (called, in this context, well-formedness rules, WFR). As will be seen in the next section, these WFRs are not purely decorative, instead, they are checked automatically by our editor as Eclipse also includes an OCL engine able to check OCL-based WFRs. As an example, the OCL rule of Listing 1 states that when granting global permission on a bot, the components that are listed as an exception must be components belonging to that same bot.
Listing 1. Consistency rule.
Beyond well-formedness we may also want to check that the policies make sense. Note that our permissions are always positive and additive in our model. However, several undesirable situations, such as redundancy between permissions could appear, for instance, if the policy includes a permission directly granted to an intent for a role that has also global access to all bot components (and therefore already has the permission to match the intent through this All access). Listing 2 shows an example OCL constraint that could prevent this by checking that a role has no global permissions for a role that already has individual ones. As this is a redundancy and not an error, we could decide to just show a warning instead of an error in this case.
Listing 2. No redundancy rule.
Despite the addition of WFR to check the correctness of the permission rules, the absence of conflicts does not guarantee the policies to be correct, as other anomalies may exist. For instance, the existence of empty roles (roles that have zero permissions) or isolated resources (resources where nobody can perform any action upon). These scenarios can also be checked by evaluating the policy once their definition has been completed. Similar to the WFRs above we could write an OCL query to return the potentially problematic roles and components.
Finally, we may also want to make sure that permissions are consistent with respect to arbitrary constraints attached to them. In the general case, i.e., when the constraints are arbitrary constraints written in a highly expressive language like OCL (that includes iterator expressions, null values, tuple types,…), the use of formal verification methods is required, each one with its own set of trade-offs.
Modeling editor for RBAC policies
To prove the feasibility of our approach, we describe in this section the tool support we provide to facilitate such policy modeling.
As mentioned before, we use the Xtext language workbench to provide our access-control language with a concrete textual syntax and an associated editing tool. The central artifact of Xtext is the grammar, which provides the syntactic rules valid textual instances must follow. Our grammar, shown in Listing 3, defines a textual language in which RBAC policies are composed by first a number of declarations (lines 1 to 15), and second a number of rules (lines 18 to 42) which refer to these declarations.
Listing 3. CUI-RBAC Xtext grammar.
Note that the definition of the bot itself (i.e., the state machine expressing the bot behavior with all the intents, transitions,…) is not part of this grammar. Here we just reference those elements, defined in a separate model with the corresponding CUI modeling language of choice. This way we achieve separation of concerns to facilitate the collaboration between CUI and security experts. Nevertheless, we believe our RBAC language is comprehensible enough to empower CUI designers without a deep security knowledge to still define the key security policies for their bots.
As an example, Listing 4 shows an instantiation of the above grammar to represent the access-control policy of our ecommerce bot policy (i.e., the rules showed in Table 2).
Listing 4. CUI-RBAC policy rules of our running example.
Xtext generates an Eclipse-based IDE which includes a textual editor of the grammar with auto-completion, syntax highlighting, and error detection with respect to the metamodel and its WFRs. Note that Xtext uses our metamodel as the abstract syntax for our language and thus, correct textual policies are internally represented as models conforming to it. As an example, Fig. 5 shows a screenshot of our textual editor, where two constraint violations have been introduced. First, the rule Grant All to register on eCommerceBot exceptFor… contains an intent in the except for list (the intent Get Monthly Goals) that is not part of the ecommerce bot. Second, the rule Grant Match to employee on eCommerceBot.I_BuyProduct is redundant with respect to the rule Grant All to employee on eCommerceBot, since the last gives permissions to the same role for the entire bot.
Figure 5. Screenshot of the Eclipse-based editor of our DSL.
Evaluating and enforcing policy rules for CUIs
As explained previously, the second part of our framework (see Fig. 1 left) consists of a runtime component in charge of interacting with the user and act accordingly either by allowing or denying the access to the resources depending on the user permissions.
The recommendation in the implementation of modern policy frameworks is to separate the infrastructure logic from the application logic by using a reference monitor architecture. This architecture consists of two basic components: a Policy Enforcement Point (PEP) and a Policy Decision Point (PDP). As shown in Fig.1, access requests to the bot resources 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. Note that values for attributes such as location or time (or any other contextual attribute referenced in the access conditions) must be attached to the access request (or directly taken from the runtime environment) in order for the PDP to evaluate the match.
There are several possible strategies to implement this architecture, depending on the level of internal access to the chatbot engine that the chatbot designer has. If modifying the execution logic of the chatbot engine is possible, we could embed the security checks as part of the engine itself. These checks would be part of standard elements of the chatbot execution logic and be implicitly verified upon every single intent matching or transition navigation request. But in most scenarios, chatbot designers will not have this option, as most chatbot platforms are not open source or are hidden behind an API offered to deploy the bot and interact with the engine. In these cases, access control must be explicitly added to the individual chatbot logic. Authorization verification becomes now explicit but, on the other hand, it can be easily added on top of many more chatbot engines.
In the following, we discuss both scenarios in more detail, especially the latter one as it will be the most common scenario for chatbot designers, which can not typically modify the chatbot engine themselves. Note that, as a trade-off, in this scenario the expressiveness of the rules we can evaluate may be restricted by the capabilities of the chosen external library (e.g., it may not support temporal or geographical or other types of complex constraints).
Enforcing RBAC policies via an external library
The first strategy we propose to enforce RBAC policies is by relying on a third-party library able to evaluate an access request against a policy. Then, based on this decision, the chatbot will need to act accordingly.
This enforcement strategy requires then two steps:
- Translate the modeled policies to the input language used by the external library.
- Integrate in the bot definition the calls to this external library.
Next, we see how we could implement each step. In particular, we will do it using Xatkit as chatbot framework and Casbin as a RBAC library. Casbin is an open-source access control library that provides support for enforcing authorization based on various access control models. Although Casbin itself supports many programming languages such as Go, Java, Nodejs, PHP, Python, Microsoft.NET, C++, and Rust, a similar approach could be followed to call our access-control rules from other chatbot frameworks and by relying on other external libraries such as Open Policy Agent or Ory.
Step 1: Generating RBAC policies
The policies written with our modeling editor are used at runtime in order to decide upon access requests. This can be done by either developing a brand new runtime component for our language or by re-using some existing authorization framework. In this paper, we opt for this second option as this is a more flexible and simple solution that avoids reinventing the wheel and facilitates the integration of our approach in different technical stacks.
As a proof of concept, we show how to policies written in our access-control for CUIs language will be translated to Casbin policies. A similar approach would be followed to translate them to other authorization systems.
In order to use Casbin with a specific access-control model, the developer needs to provide two configuration files. First, a .conf file containing an access-control model definition (e.g., ABAC, RBAC, etc). As an example, Listing 5 shows a .conf file that corresponds to the default RBAC model as provided by Casbin.
Listing 5. Casbin RBAC predefined configuration.
And second, the developer needs to provide a .csv file containing the actual access-control policy. As an example, Listing 6 shows the policy, in the form of comma-separated values, that corresponds to the aforementioned Casbin model. Each line corresponds to a policy rule that contains: (1) the identifier of a role; (2) the CUI resource on which the permission is going to be granted (an intent -I-, state -S- or transition -T-); and (3) the action on the resource (matching, reaching or navigating).
Listing 6. Excerpt of Casbin RBAC policy of our running example.
To generate Casbin policies from our policies written in our language (see Listing 4) we employ code generation techniques. The generation focuses on the .csv Casbin file. Note that the .conf file may be customized (notably to modify the types of elements used in the policy rules, the access requests, and the match process) but this configuration does not depend on the specific access-control policy of a given CUI, and thus, does not need to be (re)generated from it.
Again, we use Xtext facilities to implement our code generation. Xtext integrates code generation triggering options in the generated IDE, so policies are automatically (and transparently) translated to the target language (Casbin) as the policy file is saved. As our model and the Casbin model are very close the translation is straightforward. Listing 7 shows the actual code generator written in the Xtend Java dialect. It starts by retrieving the root of the policy model (line 5), creates a .csv file and then fills it by calling the genPolicy() method (line 7). This method iterates on the permissions contained in the policy model element and generates for each permission a Casbin RBAC permission rule (p, subject, object, action). Finally, note that our code generator performs the flattening of permissions (lines 18 to 24).
Listing 7. Excerpt of Casbin policy generator.
Step 2: Enforcing RBAC policies
Following this strategy, the security checks are explicitly added to each transition of the state machine of the running bot.
As an example, Listing 8 shows how the transition from the Show Main Menu state to the Update Shop Catalogue state has been modified to add a new condition that checks the user’s role is allowed to match the Update Shop Catalogue intent and only proceeds to the corresponding state when this condition is true (lines 3 to 5). Otherwise, as seen in Fig. 2 the bot inform the user she has not permissions to perform that action (lines 6-8). The complete implementation for our running example bot is available here.
Listing 8. Policy Enforcement Point (PEP) implementation.
Note that, even if access-control evaluation and enforcement are now explicit, they could still be automatically added to the concerned transitions. Given a security policy and a plain chatbot definition, we could automatically instrument all relevant transitions with the proper access-control checks. For Xatkit bots, and as Xatkit is a Java-based engine, a library such as JavaParser could be used to traverse the AST of the bot definition and modify it to add the Casbin calls on each transition.
Enforcing RBAC policies using a security-aware chatbot engine
A radically different strategy to enforce RBAC policies is to rely on a chatbot engine that
A radically different strategy to enforce RBAC policies is to rely on a chatbot engine that already offers RBAC primitives as part of its core engine execution. This would be ideal as our work would consist in translating our modeled policies into the chatbot engine definition language (same as we would need to do for the other chatbot components such as the intents, states,…) and we are done. The engine would take care of internally analyzing and evaluating the policies every time it is needed.
Unfortunately, there is none at the moment but if the engine is open source, you could implement this by yourself. Obviously, the way to modify the engine with access-control semantics depends on the engine. Here we briefly comment on how we are implementing this on an experimental branch of Xatkit as this is the chatbot engine we created ourselves and therefore we one we are more familiar with.
The first step is to extend Xatkit’s FluentAPI to enable the definition of security policies as part of the bot definition. Calls to this extended API would just store in the internal bot model of the chatbot engine the security of details of the chatbot execution same as it stores all the info on the intents, states and transitions to be able to execute the bot and evolve it from one state to the other in response to all types of events.
Listing 9 shows a small example of how the Update Shop Catalogue intent of our running example would be defined using this extended FluentAPI. Note how now the definition of the security policies is fully integrated with the own chatbot definition, feeling much more natural and easy to use. We first create the new role/s and then we just add the roles with permissions granted as part of the definition of the bot components, the update shop intent in the example. Moreover, now we do not need to manually modify the state machine part to include any external call, once the policy is defined, all the rest is taken care internally.
Listing 9. Defining security policies as part of the bot definition in Xatkit.
The next step is to dynamically filter the set of possible intents to match at any given moment depending on the user permissions. The concrete strategy depends on the features offered by the NLP Engine employed by the chatbot engine (Xatkit can be plugged to several NLP Engines, including DialogFlow, nlp.js or our own engine).
If the NLP Engine allows turning off and on the set of available intents automatically, we can then disable those intents that the current user should not be able to match. This is what DialogFlow supports so in this case we send to DialogFlow the set of Intents (the context in Xatkit terminology) that it should consider before every intent matching execution as shown in Listing 10. Starting from all intents that are linked to output transitions from the current state (as these are the only ones that could be potentially matched at this point) we filter out those for which the user has no permission. If the NLP Engine only allows an initial bot deployment that cannot dynamically evolve, we need to let the user match any possible intent and, a posteriori remove from the list of matches those that correspond to intents that should not be available based on the user’s role.
Listing 10. Dynamic enabling of intents before calling the DialogFlow NLP engine based on the state and user permissions.
Conclusions
In this work we have proposed 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) and proposed a concrete textual syntax to express and implement such access control policy rules. We also show the feasibility of our approach and applicability by showing how it can be implemented on top of an existing chatbot framework using two different strategies.
As further work, we plan to cover additional types of security concerns beyond access-control such as Confidentiality, Integrity, Availability, Non-repudiation, and many others. The requirements for each of these properties for a given bot should be modeled together with the bot definition, as we have done for access-control policies, via new extensions of our DSL. Then, the concrete implementation strategy will largely depend on the security concern. Some concerns can be delegated to the chatbot engine itself, e.g., protection against DDoS attacks could be taken care of by the engine embedding a rule to automatically disconnect clients sending too many requests, where the threshold is defined when modeling the chatbot. Others to the different clients and connectors to deploy the bots, e.g., encryption requirements could be implemented as the configuration of the communication libraries part of the chatbot widget embedded in webpages in charge of sending user requests to the chatbot server. Finally, GDPR (General Data Protection Regulation) compliance could be facilitated by providing standard conversations (e.g., to consent to the recording of the interaction) to be automatically added to any bot. Our code generation process should be extended for each of these situations accordingly.
Finally, we also plan to enrich the framework by supporting more expressive access control models and languages such as XACML and alternative implementation strategies that facilitate the adoption of our language to deploy secure bots in other environments. We will also start exploring the extension of testing, verification and validation techniques for secured CUIs, expanding on the initial discussion presented in this work.
I’m a lecturer at the Open University of Catalonia (UOC) and a researcher at SOM Research Lab (IN3-UOC). My research interests are mainly focused on model analysis under the Model-Driven Engineering (MDE) perspective.
Recent Comments