-We prototype a policy-based dialog system for providing physical access control to secured facilities and smart buildings. In our prototype system, physical access control policies are specified using the eXtensible Access Control Markup Language. Based on the policy and the user's presence information, our dialog system automatically produces a series of questions and answers that, if correctly answered, permit the requester to enter the secure facility or smart building. The novelty of this work is the system's ability to generate questions appropriate to the physical location, time of day, and the requester's attributes.
We developed a prototype policy-based system for
guarding entry to physical facilities, such as smart
buildings. The system interacts with potential entrants
using a spoken dialogue. Our physical access control
system uses the OASIS consortium’s eXtensible Access
Control Markup Language (XACML) standard [
In order to generate dialogues from physical access control policies specified in XACML, we generate socalled “VXML Voice forms” from XACML policy rules. In this paper we describe our initial implementation of the prototype. Given that emerging mobile applications use interactive voice commands such as Apple’s Siri, Google’s Andriod S-Voice, and Microsoft Windows Speech Recognition, we envision that new applications would emerge for interactive voice-based access to resources.
The dialogues we generate are in the form of a
question and an (acceptable) answer. In our prototype,
questions are generated using a grammar for words or
phrases—belonging to a restricted vocabulary—that are
taken from an XACML rule’s subject-attribute values
[
For each question, user input is collected and stored in a variable. These variables are used to generate an XACML request that is passed to an XACML policy decision point (PDP). The PDP is responsible for the decision of either granting or denying access. If access is granted, the system sends a control-system message to an actuator that unlocks the entry door to the facility.
We succeeded in generating a question for each rule in
the policy. Our existing implementation uses a small
number of policy rules and their conversion. We are
currently working on scaling this implementation by
addressing the run-time and automatic conversion of a
large number of rules, in addition to developing the
capability to dynamically generate the grammars using
.grxml files [
Due to advancements in mobile applications and the emergence of voice user interfaces (VUI) as well as their being provided as a service in the cloud, new access control mechanisms are needed. When completed, our current architecture and implementation will serve as a testbed for further research and development.
The following are potential applications for our system:
Mobile computing: The adaptation of the voice technology and VUI in mobile computing (e.g., Apple’s Siri, Google’s Android S-Voice, Microsoft Windows Speech Recognition, 1 2 3 4 5 6
Research in Motion’s BlackBerry) introduces challenges in using the technology in order to accomplish more sophisticated tasks such as access control to either resources and services locally on the devices or remotely at data centers via cloud services. We envision this system to be useful for providing ubiquitous policy-based automated physical access control from mobile devices, where hands-free usage is valued or required.
Military and first-responder applications: It is
important to provide hands-free user interfaces to
military personnel, especially those participating
in combat operations, as well as first responders
(e.g., firefighters, police, paramedics). These
personnel have to access support facilities (e.g.,
gates at a forward operating bases or police
substations) and equipment (e.g., fire trucks) (see
[
control can be used to provide appropriate access to any information system using a VUI.
Electronic Commerce and Business: This new access control approach can be used in performing transactions in e-commerce applications accessed via mobile computing devices. Physical Access Control: Access control to critical facilities can be automated and access can be granted or denied based on an enterprise’s policy. Policy languages such as XACML are standardized to unify policies across enterprises and reduce administrative load. This is all handsfree and it only depends on answers to questions that represent the subject’s attributes. A sample dialogue for access control is illustrated in Table 1.
U S U S
Hello Welcome, Please Say who you are? I am User01 (Alice) Please say your Password or enter it using the key pad Pass01 Ok, I got that. Now tell me Why do you need to access the building (Role) Professor What is your office number 4429 In which floor is the dean’s meeting room 5th What is the time on the clock to your right 7:30 The original intention of access control policy languages such as XACML was to deal with systems and access control enforcement points, but not humans. In our approach we use XACML to drive human interaction through dialogues with the system. This new approach has implications on the way dialogues are generated and access control decisions are taken. As mentioned above, many potential applications might take advantage of this approach. To be applicable, many aspects of human voice interactions should be studied—more research on this but it is outside of the scope of the work we report on here.
One important aspect of such an approach is the scale of implementation, especially in case of physical control. The user of such a system will likely not use the system if the system takes a long time to make an access decision for each individual of a large number of humans waiting in crowds such as at a sporting event (e.g., a World Cup football match). The processing time of an access request initiated by a human entity is going to be different than the time initiated by an automated process or application. This is another area of research we have left to future work.
VoiceXML (VXML) is the Voice Markup Language
developed and standardized by the W3C’s Voice Browser
Working Group. It is intended for creating audio
dialogues that feature synthesized speech, digitized audio,
recognition of spoken and Dual Tone Multi-Frequency
(DTMF) key inputs, recording of spoken input, telephony,
and mixed initiative conversations. VXML is similar to
HTML in the textual arena in providing an interface
between a user and the Web, using a voice interface. Its
purpose is to bring the advantages of web-based
development and content delivery to interactive voice
response (IVR) applications. All Web technologies are
still relevant in any voice interface, such as services,
markup languages, linking, URIs, caching, standards,
accessibility, and cross-browser [
The most important terms in VXML are: Form: Forms define an interaction that collects values for a set of form-item variables. Each field may specify a grammar that defines the allowable inputs for that field. If a form-level grammar is present, it can be used to fill several fields from one utterance Block: An item is a component of a form that presents information by synthesizing a phrase of text into speech to the user. Field: An item is a component of a form that gathers input from the user by synthesizing a textual phrase into speech for the user. The user must provide a value for the field before proceeding to the next element in the form. Menu: A menu presents the user with a choice of options and then transitions to another dialog based on that choice
XACML is an OASIS standard XML-based language
for specifying access control policies [
Figure 1 contains the following entities: Policy Set: A set of policies. Policy: A set of rules, an identifier for the rulecombining algorithm, and (optionally) a set of obligations. May be a component of a policy set. Rule: A target, an effect, and a condition. A component of a policy. Combination Algorithm: The procedure for combining the decision and obligations from multiple policies. Subject: An actor whose attributes may be referenced by a predicate. Target: The set of decision requests, identified by definitions for resource, subject, and action that a rule, policy, or policy set is intended to evaluate. Resource: Data, service or system component. Attribute: All entities are identified using attributes.
Predicate: An evaluable statement about attributes.
PEP: Governing entity of a resource.
PDP: The entity that evaluates access requests. PIP: The entity that fetches attribute values for the PDP..
PAP: The entity that retains polices.
Context Handler: The entity that converts decision requests to XACML requests.
Some of the currently available implementations of the XACML specification are for example OpenXACML, enterprise-java-xacml from Google code, HERAS XACML, JBoss XACML, Sun Microsystem’s XACML, and WSO2 Identity Server, which is used in this implementation.
In this section we introduce briefly implementation platforms of the standards technologies used to implement our prototype. the and
Voxeo Prophecy is a standards-based platform for
speech, IVR, and Software Implemented Phone (SIP)
applications for Voice over Internet Protocol (VoIP)
applications [
WSO2 Identity Server [
In addition to the above two major platforms, programming languages such as Java, Java Server Pages (JSP), and Java Script (JS) were used to accomplish the integration and interoperability work between these platforms and thus enabled us to develop our prototype.
The core of our work transforms an access control policy into a voice platform supported voice language. We use XACML and W3C VXML for these two purposes.
In order to generate a dialogue between a user and an access control system to make it possible for the system to make a decision to whether grant or deny access, the access control policy is transformed into VXML. The rules in each policy are read and transformed into VoiceXML blocks and forms. The entire policy is parsed using a DOM parser and then each rule element is converted to a VXML block for the user interface translating text to speech (TTS), posing the question to the user, and then waiting for the user’s response through voice recognition. The details of how TTS and voice recognition technologies are outside the scope of our current work; we are implementing these services through an integrated Voice Application Development Environment introduced in Section III.A. Figure 2 depicts the high-level architecture for our prototype system.
A more detailed illustration of this policy voice (VXML) is shown in Figure 3.
We used the Voxeo Prophecy IVR platform (see www.voxeo.com/products/voicexml-ivr-platform.jsp)— including the webserver, designer, SIP, and application manager—to develop our application for voice recognition. We use a scenario to illustrate how the application works.
Our scenario starts with a XACML policy file, with the rule shown in Figure 4.
Using JSP, we load the XACML file into a Document Object Manager (DOM) object. We read the rules inside the XACML document and link each rule to a VXML block/form. The JSP script extracts the attribute’s value from the DOM’s rule element and passes it to the Voxeo designer application, which converts it to VXML. Figure 5 shows an example of a VXML file. <?xml version="1.0" encoding="UTF-8"?> <vxml xmlns="http://www.w3.org/2001/vxml" xmlns:xsi="http://www.w3.org/2001/ XMLSchema-instance" xsi:schemaLocation="http://www.w3.org/2001/vxml http://www.w3.org/TR/voicexml20/vxml.xsd" version="2.0"> <form> <field name="e-mail"> <prompt>What is your e-mail address? </prompt> <grammar src="email.grxml"
type="application/srgs+xml"/> </field> <block> <submit next="http://www.example.com/user.asp"/> </block> </form> </vxml>
Fig. 5. A sample VXML
In order to create the question, a phrase is inserted before the attribute value in the form of “What is?” or “Is your?” followed by the attribute name extracted from the RuleID of the DOM’s rule element. Our current implementation supports the yes/no answers to “Is your?” type of questions. We are in the process of enlarging the question formation syntax to support other question formats.
In this way a question will be generated for every rule in the policy file. The human user then needs to answer the questions posed by the system.
The next step is to collect attribute “VoiceXML variable” values generated throughout the dialogue and use them to generate an XACML request. Figure 6 shows an example of a request.
The XACML request will be sent to the XACML implantation of choice. In our case, we have chosen WSO2 Identity Server version 3.2. It has a distinguished, modern, and high-performance XACML implementation with a service-oriented implementation option. The Voxeo development environment supports both HTTP requests and web services. Our choice was to enforce the policy by accepting the XACML request through a web service interface with the WSO2 XACML PEP. The PDP will take a decision based on the attribute values collected from the dialogue and matches of values of subjects and resources in the XACML implementation (see Figure 1). The grant or deny decision will then be ready to be returned back to the application. In our current case, it should be translated to a physical access decision as to whether to open a door.
The XACML’s access decision is based on the output of the policy and rule combining algorithms. Following the standard, the rule and policy should evaluate to true in order to grant access; otherwise it would produce “indeterminate” or “not applicable.” In case there are multiple applicable rules and policies, the final access decision is the result of the logical combination of these algorithms.
Our work, in its final state, will illustrate the use of
XACML to control access to resources through building
dialogues with human users. There are efforts proposing
access control systems through XACML interfacing with
other data models. In the published literature, a majority
of this integration effort is with Web Services [
Security Assertion Markup Language (SAML) profile
for XACML is heavily relied on when there is a need to
use additional subject’s attributes that are administered by
other authorities to evaluate access control requests [
Finishing the XACML implementation Being able to generate requests and responses and execute them Determining the best way to use grammars Looking into the best way to generating VoiceXML from XACML: there are options to evaluate such as DOM and XSLT
Some of the follow-on research items we are pursuing are:
Integrating presence information with the dialog access control system. It is critical for an automated system to authenticate to the system the speaker or requester of access to avoid certain attacks, such as by verifying the physical presence and human nature of the speaker.
Making the dialog as short as possible. In a
spoken dialog or question-answer system, it is
different than filling a form using a keyboard and
a mouse. It can take more time to say the voice
block (form) than filling it by hand or via a
keyboard. In some cases, we might need to make
a quick access decision through dialog which
might require thinking of ways to reduce the time
required to collect attributes and make a correct
XACML decision. Maybe asking only the most
difficult or important questions according to their
weight can reduce the number of questions
without affecting the accuracy. An analysis
similar to the one in [
Some policy sets might have a large number of policies and rules with different combination algorithms. It would be interesting to see how this can affect our spoken policy-based access control (question-answer) system.
After being able to generate dialogues from policies, it would be interesting to see if we can generate rules from dialogues.
In any dialogue, it is important to guarantee the privacy of what is spoken. In order to answer a question the user has to say things that might be considered to be sensitive (e.g., a unique government identity card number, such as a social security number) and the user might be reluctant to answer the question in public, which might affect the attributes collected in order to build the request and thus the decision might not be correct.
In this work, we have presented a novel approach to generate a dialogue for the purpose of physical access control from a standard access control policy language. This policy language driven interaction with the user or authorization requester is generated at runtime and is implemented in a standard language.
This material is based upon work supported by the US Air Force Office of Scientific Research under grant FA9550-09-1-0421.
DUMINDA WIJESEKERA is an Associate Professor of Computer Science at George Mason University, where he serves as Program Director of the Doctor of Philosophy program in Information Security and Assurance. He is a member of the university’s Center for Security Information Systems.
JAMES BRET MICHAEL is a Professor of Computer Science and Electrical and Computer Engineering at the Naval Postgraduate School, Arlington, Virginia.