Section 30.3. Designing Security Displays


30.3. Designing Security Displays

Information about security attributes can, in theory, occur almost anywhere in a user interface. This placement makes good sense from a task perspective. For example, users can find all their email configuration options in one place, from delegating access to their mail to changing the text placed automatically at the bottom of each mail message. Sometimes, though, users are looking for a security feature and are not sure what task or context it might be associated with. Or they are trying to get a better sense of the overall security picture of the application to form a useful mental model. This latter task is more likely to arise for evaluators, reviewers, and administrators, people who provide guidance to larger populations, than for individual end users.

In this section, we discuss the usability of two displays that provide useful centralized security information in Lotus Notes.

30.3.1. User Security Panel

User-related security information was brought together in a single security panel in Notes 6, as shown in Figure 30-1. The motivation behind consolidating that information in one place is to make it easier to find. For example, information in only one of the resulting tabs, the Mail Security tab, was gathered from five different places in the previous product version. Consolidation can also make it easier to understand, and can help users learn about security features that they might not have noticed otherwise. The Lotus Notes User Security panel was explicitly designed with an eye toward making difficult security concepts easier to understand and use. In addition, access to security-sensitive information is protected with a password prompt (to ensure that it is not viewed or manipulated by anyone other than the user). Interleaving sensitive security and other types of information meant that a user had to type his password unnecessarily in some circumstances. Therefore, localizing that information made the usability of other paths better. An informative and entertaining article also accompanied the change,[4] using humor to highlight the potential utility of the security information. Informal feedback from users and customers to both the panel and the article has been enthusiastic.

[4] Jane Marcus and Cara Haagenson, "Bonding with User Security in Notes 6," Lotus Software [cited Oct. 2004]; http://www-10.lotus.com/ldd/today.nsf/0/232e604b847d2cad88256ab90074e298?OpenDocument.

Figure 30-1. User Security panel


The initial design of the User Security panel was performed by a security engineer. This allowed someone knowledgeable about the content of the panel to provide initial organization and explanations. The dialogs were designed to explain topics and information directly to the user. Each was structured to highlight basic information or useful task-specific security procedures.

After the initial panel design by a security engineer, design walkthroughs were held with a usability expert. These walkthroughs found and corrected many visual design problems that impeded usability. They applied color and whitespace to make data items and the relationships between them more understandable. Visual design discussions included whether tabular information should be organized by concept (such as infrastructure and specific applications) or by the likelihood of being used. A mixed model of a single first tab for the most-used items, followed by a conceptual grouping for all of the other tabs, was adopted.

The walkthroughs also clarified basic security concepts useful to many users, because they were understood by the usability expert who could offer specific informed suggestions for improvement around them. Making terminology more understandable generated some robust discussions. Security features targeted at technology, not user artifacts, are often the most difficult to explain. For example, Lotus Domino supports several protocols, and therefore several methods of authentication. Notes authentication, as described earlier, uses a password to unlock a private key; subsequently, public key cryptography authenticates the Notes user to the Domino server. Browser access to the Domino server uses web-standard, password-based mechanisms with password checking against a hashed version stored in the directory. These two passwords can easily be unsynchronized, leaving the user with two different Domino passwords: one for Notes RPC and one for other protocols. Usability experts found the term Internet password, used by Notes developers to refer to one of the passwords, to be precise but not informative to users. They recommended web password, which they believed would be meaningful to the user, and descriptive. Administrative developers pointed out that the password is used for all supported Internet protocols: HTTP, IMAP, POP, and LDAP, making web password imprecise and therefore inaccurate. The resolution of the debate was to choose different terminology for the different types of users: the end user and the administrator. Domino web/Internet password is used in the Notes client for the end user, and Internet password is used in the administrative client for the administrator.

This small example shows the difficulty in balancing the needs of different user constituencies against the need for product consistency. The choice in this case was to tune terminology to each user group, but to make sure that the two terms were linked in some obvious fashion.

30.3.1.1 Displaying public key certificates

Even with detailed explanations from security experts, usability experts found it difficult to understand the more advanced security concepts. This made it difficult to apply usability knowledge to the domain. Display of public key certificates and tasks that use them continues to be a challenge when their use cannot be hidden.

One open design question on the "Your Certificates:" display in the Your Identity tab was just how much information about a certificate users need to see, and under what circumstances they would need to see it. Most users do not even know they have certificates (and that is a good thing). The decision was made to include help text directly on the dialog displaying all the certificates of a certain type (such as Notes, Internet, certification authority, and so on), explaining the type and what it is used for. This design approach is similar to some of the safe staging work in Lime.[5] The display of any specific certificate also contains most basic information that each type has in common: who it is issued to and by, when it was issued and when it expires, its type, and its identifier. All other information about a certificate in the general display panel was deemed intended for security experts only, and hidden behind an Advanced button.

[5] Alma Whitten, "Making Security Usable." Ph.D. dissertation, Carnegie Melon University, 2004, CMU-CS-04-135. See also Chapter 34, this volume.

In another example, in the context of configuring an Internet certificate for use, the Internet-style mail security options were hidden under a button to simplify the dialog. The motivating use cases for viewing this information would be error paths, not common tasks. We had little information about what information was most commonly needed in error cases.

One error case that is well thought through in the Notes security user interface is mistyping a password. Notes has a feature that attempts to help you catch password mistypes before you hit Return. The Notes password prompt dialog (shown in Figure 30-2) displays a changing picture of a keyring and keys on the lefthand side. Starting with the fifth character typed, the picture changes to one of a set of keyring pictures, determined by a hash of the current string of characters that have been typed. Mistyping a password will show an unexpected sequence of keyrings (and most likely a different final one). If the user does mistype his password and clicks OK, he is reminded of the most common error casethat passwords are case sensitive.

Figure 30-2. Password dialog


30.3.1.2 Limitations and results

The scope of the User Security panel design was to overlay a user interface on existing features. Bringing diverse security information together can highlight issues and opportunities in the existing security model, providing just the first step for enhanced usability of security. For example, the User Security panel displays all types of names that can be used to refer to the user. Some names are used for security (access control lists), and some names are used for sending email (either within a Domino domain or through the Internet). Further work could make the naming model more consistent, allowing either type of name in both functions, at least within the context of the Notes client and a Domino administrative domain.

Some useful manual security procedures were implemented as actions in the User Security panel dialogs. Because the scope of the task was only the user interface, in some situations, the procedures still require multiple steps for the user to execute. One example is the Compromised Password button in the Security Basics panel tab (see Figure 30-1). The procedure to recover from password compromise is usefully encapsulated in a single dialog. However, it requires four steps:

  1. Change the password that protects the private key.

  2. Ask your administrator to turn on extra password checks so that even someone with your private key and your old password cannot access your server data (a feature that takes the place of certificate revocation lists in our proprietary PKI).

  3. Get a new signing key.

  4. Update all the copies of your keyfile if you have them in multiple places.

The two automated steps are interleaved with procedures not currently automated in Notes: contacting your system administrator, and manually copying files to unspecified hosts. The former would be automatable if the system had some configured notion of how to contact the right system administrator on behalf of the user.

While security remains an area that requires deep domain expertise to understand, and while application of many usability techniques requires a full understanding of the domain applied to, deep cross-domain expertise in both areas will be needed to make progress using standard usability techniques, such as expert reviews and consultation. This exercise did find real value in the application of those techniques to the more commonly used security information displays.

30.3.2. Database Access Control Information

The other area that displays useful security information is the database Access Control List (ACL) dialog, shown in Figure 30-3. Each instance of a Notes application is associated with a specific database. The Access Control List dialog displays the overall control information for a database.[6]

[6] Rob Slapikoff and Russ Lipton, "The ABC's of Using the ACL," Iris Today Archives [cited Oct. 2004]; http://www-10.lotus.com/ldd/today.nsf/8a6d147cf55a7fd385256658007aacf1/be08e4acfc72cd72852565d9004cb61c?OpenDocument.

Domino database ACLs are quite simple, compared to the hierarchical access control features found elsewhere in the literature and in filesystem and directory products. The general approach here and elsewhere was to provide something basic, secure, and usable. There is a single list of users and groups who have access to the database. Attributes on those entries include access levels and their permissions. Seven access levels are defined, from No Access to Manager. Each of these levels has both implicit and explicit abilities or permissions. There are nine explicit permissions, represented as checkboxes. Some permissions are required to be enabled or disabled at a particular level, and others are optional. The default values for a new entry for both access level and permissions is taken from the entry selected when the new entry is added. One theme in customer requests in this area is the ability to create custom access levels. The concept of a level is quite useful in general, but each customer has his own notion of how fine-grained permissions should be allocated across his organizational roles.

There is no notion of the ability to deny a permission. Instead, the ACL evaluation algorithm proceeds from the most specific user entry found to the least specific matching entry (Anonymous), granting the permissions found at the first level of specificity where the user has a match. Thus, a user in a group with a powerful permission (level) can be denied that level by adding his name with a more restricted permission level to achieve deny-like semantics. This straightforward approach to both ACL evaluation and the ability to deny permissions has worked well in the majority of Notes applications.

Figure 30-3. Access Control List main tab


The large-grained, general database ACL is a useful and understandable starting point, but some applications need to grant and manage more fine-grained access. Over time, several mechanisms were added to provide more detailed control.

Other ACL display tabs cover role definition and the logging of changes to the ACL, shown in Figure 30-4. Notes roles are groups defined and managed locally in a specific database ACL (not in the directory where enterprise-wide groups are defined). They are used by Notes applications to provide application-specific custom semantics on application operations. For example, the Domino database application defines roles for UserCreator and GroupModifier. The Reader List on a document overrides the database ACL to specify a much more limited set of readers for sensitive documents. The Authors List on a document specifies which users who have Author access to the database also have the ability to modify a specific document as its author.

30.3.2.1 Adding power and complexity

In Notes 6, we added the Extended ACL (xACL) feature that allows sites to partition and delegate the access control administration of their Domino directory to allow for regional administrators and to enable hosting. We layered this support on the LDAP ACL standards

Figure 30-4. Notes ACL log


work that was proceeding in the IETF.[7] This access control model is a substantial increase in complexity over what we had provided before. It allows access control to be set at any point in the hierarchy of documents, on any type of document, on a field type within a document type, and on a per-document basis. This flexibility went beyond the targeted use case requests from customers, but was attractive because it could cover future use cases, and was anticipated as a standards-compliant approach.

[7] E. Stokes, B. Blakley, R. Byrne, R. Huber, and D. Rinkevich, "Access Control Model for LDAPv3," [cited Oct. 2004]; http://www.ietf.org/proceedings/01aug/I-D/draft-ietf-ldapext-acl-model-08.txt.

The very fine-grained and flexible model seemed that it might be an invitation to usability-related security problems. When an early version of the Extended ACL user interface was available, four experienced Notes administrators participated in a classic, lab-based usability test on the feature. They were given a scenario with 13 tasks to complete. A usability specialist constructed and ran the test, and worked with developers on the feedback and lessons learned from the testing. The tasks ranged from using xACLs to restrict a specific user to reading, but not changing, a particular field, through defining limited administrative delegation access to another user.

Generally, the test subjects were in favor of having the advanced features and controls. The usability tests found a number of user interface problems that were easily fixed with more straightforward or consistent terminology or with a simple rearrangement of dialog features. The most challenging scenario for the test users was to give a specified group only read and create access to a particular type of document (the Person form), but not to give them delete or modify permission access to that same type. Only one of the four test subjects was able to complete that task successfully.

One of the most substantial security-specific findings from this and other tasks in the scenario was that three out of the four test subjects could not figure out how permissions interacted between the extended ACL and the familiar database ACL. The Effective Access button was added to help with that confusion. It is available at the database level, and at any specific items protected by extended ACLs. It returns what access any specified user has to that data and, if groups are involved, shows the user's groups that were used to calculate that access.

Our experience with the usability methods applied to both security information displays is that they can find and correct a number of basic usability problems early in the design cycle. They did not address fundamentally complex models such as xACLs. The separation between the creation of the security model in a standards organization and the evaluation of the usability of the use cases of that model makes providing usable standards-based security particularly challenging. In neither of our usability evaluation contexts were deeper methods such as contextual interview and design applied to the more complex underlying security models. That approach has yielded good results in the research context,[8] when coupled with user interface models that tame and simplify the complexity of the models.

[8] Mary Ellen Zurko, Rich Simon, and Tom Sanfilippo, "A User-Centered, Modular Authorization Service Built on an RBAC Foundation," IEEE Symposium on Security and Privacy (1999), 5771.



Security and Usability. Designing Secure Systems that People Can Use
Security and Usability: Designing Secure Systems That People Can Use
ISBN: 0596008279
EAN: 2147483647
Year: 2004
Pages: 295

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net