Janus’s Map

Janus’s Map is a location detection system developed for the Siebel Center and coded by Jodie Boyer. Janus’s map makes use of 2 pieces of the Siebel Center infrastructure, the electronic door locks and the occupancy sensors in all of the rooms. Janus’s Map provides a web interface to allow users to search for other people, manage rules protecting their own location information, view the history of events on the doors that they own, and open doors. Janus’s Map is written using a combination of Java and Perl.


Privacy Sensitive Location Information Systems in Smart Buildings
Jodie P. Boyer, Kaijun Tan and Carl A. Gunter
Springer Security in Pervasive Computing (SPC ’06), Lecture Notes in Computer Science, pages 149-164, York, UK, April 2006. [PPT][BIB]


There are 4 basic features in Janus's Map, user search, rule management, door search, and remote door unlock.
  • User Search: This feature allows users to try to find other people in the system. The results returned are filtered according to rules defined by the user who was searched for.
  • Rule Management: This feature allows users to define rules that are used for filter results returned when someone searches for them. Additionally, it also includes the ability to define user groups to aid in the rule definition process
  • Door Search: This feature allows users to search for events on doors that they own. As with user searches, the results are returned according to user's rules.
  • Remote Door Unlock: This feature allows user to send door unlock requests to doors they have access to.

Security Concepts

  • Mandatory Access Control: Mandatory Access Control (MAC) is when the system controls the access to an object and users cannot alter their rights in the system. Currently the door locks and proximity sensors are controlled by such a system. The system administrators control access to the information and users are currently not allowed to access the information at all.
  • Ownership: The concept of ownership of data is key to Janus's Map. Every piece of data that is available for the door lock system has an owner. If the data is about someone, such as valid access, that user owns the data. If the data is not about anyone, such as door ajar, the door owner owns the data.
  • Originator Controlled Access Control (OrCon): Originator Controlled Access Control basses access rights on the originator of the information. The access control model is based on OrCon. Users control access to the information that concerns them. Additionally, information that is not about anyone, such as the door ajar event, are owned by the door owner

Janus's Map Access Control Model

For Janus's Map, we elected to use a combination between MAC and OrCon. User's control the access to any data associated with them and can grant access to whom they choose, however, administrators can always view a list of doors that are unlocked by someone using the web interface, but this data is not available to users. This combination allows for good privacy in addition to good administration.

Privacy Principles

In any system with potentially sensitive information, such as a location detection system, it is important to consider privacy. Unfortunately, privacy is a very difficult concept to define in a formal way. Additionally, every user has a different idea about how much privacy they feel they need in different situations. As a result we choose to give users control over who can see what data about them.
  • Groups In order to aid in the process of defining rules a little easier, Janus's Map provides the ability for users to define groups. This will allows to define rules about groups of people easily. This way, a user can simply add someone to group and not have to worry about changing a rule.
  • Rule Structure A rule is split into 3 basic parts, targets, visibility and data access. The targets simply define who the rule applies to. For example, Alice could right a rule about what Bob can find out about her. Targets can also be user defined groups. The data access portion of the rule defines type of entries the system will return back to a requestor. You can filter entries based on event type, time, date (date and time are considered separately in rule application), day, and room number. Additionally, you can define how many past entries should be considered. This part of the rule is applied first so it defines the maximum number of entries that can be seen by the requesting user. Finally, the visibility part of the rule defines what fields are available to the rule target. The user can prevent any field from being shown and can also define the granularity level of the room information. The user can specify that only the building, floor or wing are visible.
  • An example rule: Owner: Alice Target: Bob Visible fields: Event Type, Event Time, Room Room Granularity: Wing Number of past entries: 5 Event types: Valid Access only Event time: Between 8am and 5pm Event date: From Jan. 1, 2005 to Jan 1, 2006 Event days: Monday - Friday Rooms: All
  • User Registration Before a user can be found using Janus, they must register. Registration happens the first time users login. Once a user is registered with Janus they can write access rules for people to decide who can find and cannot them. If there is no rule concerning that requestor, the request will return no results.
  • Rule Application Rule application is slightly different depending on what the search was for. If a user is searched for the system gets all the rule belonging that user. It then determines which rule is applicable to the search by checking the rule's targets against the person doing the searching. Once this happens, the result set is reduced to the size specified by the user. Then this resulting entries are filtered against the rule to determine which of these entries should be returned. Finally, the remaining entries are masked by removing invisible fields and masking the room number as requested by the user. If a door is searched for, the results are examined to see which users entries are included in the search results. For each user, the system acquires their records and applies filtering as described above. Then the door search results are compared against all of the user records (that have already been filtered) and returns only the events that show up in the users list. If an entry is present in a user's results, but the room has been masked, the entry is removed from the search results. This prevents a "covert channel" to determine a users location.

Database structure

The backend of Janus's Map is essentially a database. The database contains 10 tables.
  • DOORLOCK: This table contains all of the events that the doorlock system records. This table serves as a replacement for the actual doorlock database.
  • DOORACCESS:This table contains the door access rights for users in the system
  • DOOROWNER:This table stores the the door/owner relationship
  • OCCUPANCYSENSOR: This table stores the current state of the occupancy sensors in the rooms
  • JANUSUSERS:This table stores information about all registered users
  • GROUPS:This table stores user definded groups
  • RULES:This table stores users rules
  • OPENDOOR:This table logs requests for doors to be opened remotely.
  • ADMINISTRATOR: This table contains a list to of all administrators in the system
  • BLUESTEM:This table contains information about users that would be accessible to the system via the Bluestem authentication system.

Web Interface

The web interface is what users will use to interact with Janus's Map. The interface is implemented as a series of Perl scripts and a Java program that is used to interface with the database.

Janus Backend

To aid in development and for demo purposes, a backend simulator was designed. The purpose of the Janus Backend is to simulate Siebel Center. It does this by connecting to the database and adding events as they occur in the interface. Additionally, the backend polls the database to see if door unlock requests are pending and "unlocks" doors for users. This backend was written entirely in Java.

Administrative Interface

Janus's Map also has an administrative interface designed for the system administrators. Currently, administrators can use this interface to view an audit log of the doors that were opened remotely and also quickly discover which doors are open in the building and when they were opened. One could imagine also give administrators the ability to approve remote door open requests instead of letting them happen automatically.

Future Work

  • Extend Administrative Functions
  • Construct an Web Services API for Janus's Map to allow applications to interface with it. Functions will include:
    • Search
    • Register for call back when someone swipes into a room
    • Fire warning when a door has been opened too long
    • E-mail friends when you have entered the building

Last updated on Monday, July 25, 2011, 4:28 pm