| ABFAB | R. Smith |
| Internet-Draft | Cardiff University |
| Intended status: Informational | M. Donnelly |
| Expires: September 22, 2016 | Painless Security |
| March 21, 2016 |
Application Bridging for Federated Access Beyond web (ABFAB) Usability and User Interface Considerations
draft-ietf-abfab-usability-ui-considerations-04
The real world use of ABFAB-based technologies requires that any identity that is to be used for authentication has to be configured on the ABFAB-enabled client device. Achieving this requires software on that device (either built into the operating system or a standalone utility) that will interact with the user, managing their identity information and identity-to-service mappings. All designers of software to fulfil this role will face the same set of challenges. This document aims to document these challenges with the aim of producing well-thought out UIs with some degree of consistency between implementations.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 22, 2016.
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
The use of ABFAB-based technologies requires that any identity that is to be used for authentication has to be configured on the client device. Achieving this requires software on that device (either built into the operating system or a standalone utility) that will interact with the user, and manage the user's identities and credential-to-service mappings. Anyone designing that software will face the same set of challenges.
This document does not intend to supplant evidence-based UI design guidelines; implementers of identity selectors are strongly encouraged to understand the latest in HCI and UX thought and practice. Instead, it aims to document the common challenges faced by implementers with the aim of providing a common starting point for implementers in the hope that this aids in producing well-thought out UIs with some degree of consistency.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
Various items of terminology used in the document are heavily overloaded in that they mean a variety of different things to different people. In an attempt to minimise this problem, this section gives a brief description of the main items of terminology used in order to aid a consistent understanding of this document.
When using the ABFAB architecture (see [I-D.ietf-abfab-arch]) to perform federated authentication to some service, a user will need to provide identity information that they wish to use to authenticate to that particular service. This will happen through a process of the application calling the GSS-API, which will in turn gather the user's credentials through some process. We will call this process the "identity selector" in this document (though note that this is not a recommendation on terminology for the process).
The simplest way to achieve the desired effect would be a process that simply takes the credentials from the currently logged in user (e.g. the Windows Domain Credentials) and uses those for all services that request authenticate through ABFAB. This approach gives ultimate simplicity in terms of UI (it wouldn't have one) but the least flexibility (the user has to use a single identity for everything). If there is ever to be a requirement for a user to use a different set of credentials for a service, or a requirement for the user to use ABFAB to authenticate to the operating system, then something more complex will be needed.
Where there is a requirement for multiple credentials to be supported, there are at least two methods that could be employed to configure identities and associated information:
When designing an identity selector with a UI (or indeed, with a headless mode), any implementer will share a common set of usability considerations inherent to the context. This document aims to explore these considerations, and provide advice and guidance on addressing them where possible.
Anyone designing an identity selector will have to grapple with choosing terminology that the average user has some chance of understanding. This terminology can split into a few main functional areas, as discussed next.
The first area where terminology is needed is around the identity/identities of the user. Users are typically used to seeing a variety of terms for aspects of their identity in the federated sense, and an even larger variety in the wider Internet sense. For example, in the federated sense some of these terms include "username", "login", "network account", "institutional account", "home organisation account", "credentials", and a myriad of other such terms. However, NAI - the technically correct name for their identity in an ABFAB sense - is highly unlikely to be one of these terms that users are used to seeing. Further, given that the NAI superficially looks like an email address, there is a definite potential for confusion.
Implementers of an identity selector will need to carefully consider their intended audience for both their level of technical capability and the existing terminology that they may have been exposed to.
Beyond terminology, careful thought needs to be given to the paradigm to use when presenting identity to users, as identities and services are abstract concepts that some users may not find easily understandable. Implementers may wish to keep such abstract concepts despite this, or may wish to examine attempts to map to real world paradigms, e.g. the idea of using "Identity Cards" that are held in the user's "Wallet", as used by the now defunct Microsoft Cardspace ([MS-CS]).
Terminology around services is likely to be less of a problem than identity, but it will actually depend on what the service is. For example, each service could be simply described as "server", "system", etc. But for simplicity just the word "service" will probably usually suffice.
The basic functionality of the Identity Selector is to create the correct combination of Identity and Service, so that the correct identity is chosen to create the credential for the GSS-EAP connection with the given service. Mapping is the process of creating this relationship between identity and service.
Depending on your perspective either each identity may be mapped to multiple services, or each service has multiple identities mapped to it. Thus any UI could present either perspective, or both.
One of the core features of an identity selector is the management of a user's identities. This section first looks at what information associated with an identity will need to manage, and then looks in detail at various usability considerations of this area.
The bare minimum set of information that MUST be stored about each identity to allow ABFAB authentication to take place is a single item:
Next up is a small set of information that SHOULD be stored about each identity to allow the user to effectively select a particular identity:
Finally, there is a set of optional information that MAY be stored about each identity that represent useful information for the user to have and could make an identity selector more usable. Note that this list is neither intended to be exhaustive or even particularly correct; any implementer is free to use whatever make sense in their implementation and conforms to good HCI/UX guidelines. Instead, it is simply a suggested starting point.
Identity providers are entities that may be shared across multiple identities. For instance, a person at a university may have one identity as a student and another identity as an employee, but a single identity provider makes access management decisions about both. In these cases, the identity selector MUST consider it an error if the trust anchor for the identity provider is different between the various identities managed by the single identity provider.
The bare minimum set of information that MUST be stored about each identity provider is:
Identity providers also have a set of optional information that MAY be stored about each identify provider. This set includes, but is not limited to:
Note that the password changing URL and helpdesk URL somewhat mirror the definitions of the same fields in the identity. The distinction is that the URLs in the identity SHOULD apply to the individual identity, whereas the URLs in the identity provider SHOULD apply to all identities that the identity provider defines. For example, an identity password change URL would provide a personalized experience of changing the password for the given identity, but the identity provider password change URL would direct the user to a page where the user would need to enter the individual identity that needs a new password.
If the identity contains no password change URL or helpdesk URL, the identity selector MAY present any corresponding URL from the identity selector instead. However, if the identity contains the URL, the identity selector SHOULD present the URL from the identity.
Since some of the information that makes up the identity is sensitive in nature (e.g. containing passwords), then this information SHOULD be stored and accessed securely. This might involve ensuring the credential information is held in encrypted form on device and accessed using a passphrase. For deeper integration into the system, this could be done by using existing secure storage on the system such as Keychain on a Mac, the GNOME keyring on a GNOME based Linux device, or the Credentials Manager on Windows.
Users will have one or more identities given to them by organisations that they have a relationship with. One of the core tasks of an identity selector will be to learn about these identities and their identity providers in order to use them when it comes to authenticating to services on behalf of the user. Adding these identities could be done in one of three ways: manual addition, automated addition that is manually triggered, or automated addition that is automatically triggered. Each of these are discussed in more detail next.
Note that the term "association" or "addition" of an identity is used rather than "provisioning" of an identity, because while we actually are provisioning identities into the UI, provisioning is an overloaded term in the identity and access management space and could easily be confused with identity provisioning in the sense of the creation of the identity by the home organisation's identity management procedures.
Allowing users to add an identity provider manually is technically the easiest method to get this information, but it is a method that has the greatest usability drawbacks - including some that create potential security issues. Most of the information required is relatively technical and finding some way of explaining what each field is to an non-technical audience is challenging (to say the least). This especially is the case for trust anchor information. Thus this method should be considered as a power-user option only, or as a fall-back should the other methods not be applicable. Implementers may well decide not to offer the manual option due to these drawbacks.
When this method is used, careful consideration should be given to the UI presented to the user. The UI will have to ask for all of the information detailed in Section 6.2.
Trust anchors present a particularly onerous challenge for the user to enter. For this reason, many identity selectors will want to implement a leap-of-faith acquisition of the trust anchor. For these leap of faith acquisitions, the identity selector SHOULD present the user with the name of the realm that the identity selector is attempting to reach, the subject of the trust anchor certificate, details of the certification chain, and a fingerprint of the certificate. If the realm does not match the subject of the certificate, the identity selector MUST inform the user of the discrepency. The identity selector MAY reject the leap-of-faith on its own, or MAY allow the user to proceed anyway. If the user proceeds anyway, the identity selector SHOULD urge the user to reject the leap-of-faith.
The area of verification of trust anchors is very important. An Identity Selector that allows for manual addition of identity provider information SHOULD try to ensure that trust anchor information is gathered and checked in a secure a manner as possible - where users have to enter and confirm all trust anchor information, or be required to explicitly agree to an insecure configuration if this is not done properly.
One way to bypass the need for manual addition of an identity provider - and all of the usability and security issues inherent with that approach - is to provide some sort of manually triggered, but automated, addition process. One approach to accomplishing this, for example, could be for an organisation to have a section on their website where their users could visit and be given piece of data that contains much or all of the relevant identity provider information for importing into the identity selector.
Additionally, the user SHOULD be given the opportunity to:
In this case, trust anchors would be directly provided through the automated addition process to help establish the trust relationship in a secure manner.
Many organisations manage the machines of their users using enterprise management tools. Such organisations may wish to be able to automatically add a particular user's identity provider to the identity selector on their machine/network account so that the user has to do nothing.
This represents the best usability for the user - who wouldn't actually have to do anything. However, it can only work on machines centrally managed by the organisation.
Allowing users to add an identity manually is relatively easy in comparison to adding an identity provider manually. If the identity provider is already known in the identity selector, then the identity selector can construct the NAI from the identity provider and a username. Thus the manual addition of an identity in a known realm needs to prompt the user only to pick the realm, to enter the username, and to enter the credential. If the identity provider is not known to the identity selector, the identity selector will provide the user with a way to define a new one as part of the identity addition.
There are two points at which a user could manually add an identity:
Of course, implementers could support both styles of identity addition to gain the benefits of both and give flexibility to the user.
Much like in the case of the manually triggered automated identity provider addition Section 6.4.1.2, an identity could be added to the identity selector through a user-initiated mechanism. To follow the example in the identity provider section above, the organization could enhance the identity provider addition web service to prompt for the user part of the NAI. The web service could then generate all of the data needed for adding both the identity provider and the identity.
It is reasonable to assume that any such automated addition service is likely to be organisation specific, so that the Issuing Organisation and realm part of the NAI will be constant, as would be the trust anchor information. The user part of their NAI will have been input on the web service. The password could be provided as a part of the provided data or the identity selector could prompt the user to enter it.
If the identity provider data contained in this identity to be added conflicts with an existing identity provider known to the identity selector, the identity selector SHOULD present the discrepency to the user. The identity selector MAY reject the identity provider and identity on its own, or MAY allow the user to proceed anyway. If the identity selector allows the user to proceed anyway, the identity selector SHOULD urge the user to reject the leap-of-faith, and require the user to confirm the intent to proceed before proceeding.
Additionally, the user SHOULD be given the opportunity to:
Section Section 6.4.1.3 introduced the concept of using enterprise management tools to add an identity provider to the identity selector. These enterprise management tools could be used to add an identity that uses the identity provider added in the above manner. The user would not need to decipher difficult to understand data entry screens.
However, having an identity automatically provided, including its password, does have some particular usability issues. Users are used to having to provide their username and password to access remote services. When attempting to access services, authenticating to them completely transparently to the user could represent a source of confusion. User training within an organisation to explain that automated population of their identity has been enabled is the only way to counter this.
This process is conceptually fairly similar to adding an identity, and thus shares many of the usability issues with that process. Some particular things are discussed here.
An identity selector may allow a user to manually modify some or all of the information associated with each identity. The obvious items that SHOULD be allowed to be changed by the user are the friendly name, the friendly icon, and the credential, or password, associated with the identity.
The identity selector should restrict other modification of the information:
To ease usability, organisations may wish to automatically provide updates to identity provider or identity information. For example, if the user's password changes it could automatically update the password for the identity in the user's identity selector, or if the trust anchor information changes (e.g. if a certificate is changed) it could be automatically pushed out to all users.
An inherent by-product of the ABFAB architecture is that an identity cannot be verified during the addition process; it can only be verified while it is in use with a real service. This represents a definite usability issue no matter which method of identity addition is used (see Section 6.4):
Also, if the identity information is incorrect the user may not know where the error lies, and the error messages provided by the process may not be helpful enough to indicate the error and how to fix it (see Section 8).
This is fairly similar to adding or modifying an identity, and thus shares many of the usability issues with those processes. Some particular things are discussed here.
Allowing the user to manually delete an identity is probably the best way to achieve the goal. Any UI should allow for this option.
While automated removal of an identity is a way of achieving the goal without having to interact with the user, the consequence is that things may disappear from the user's identity selector without them realising.
Sometimes, a user may wish to have the identity they wish to use with a service stored by the identity selector, but not the credential (e.g. password) that goes along with that Identity. The consequence of this is that when a user attempts to authenticate to a service for which an identity, but no credential, is stored, then the user would need to be prompted to manually enter the credential.
A service to identity mapping tells the identity selector which identity should be used for a particular service. There is potentially a many-to-many association between identities and services since a user may wish to use one of their identities for many services, or more than one identity for a single service (e.g. if they have multiple roles on that service).
This potentially complex many-to-many association between identities and services is not easily comprehended by the user, and allowing the user to both manipulate it and control can be challenging. These obstacles are especially common when errors occur after an association has been made. In this scenario it is important that an identity can be disassociated with a service.
To further complicate the picture, users may wish for:
There needs to be a way for the user to create the service to identity association. It is advisable that this link be made only after the identity in question has authenticated with the service without any error.
There are a few ways this association could happen.
There are two ways in which manual association of an identity to a service could happen:
It would be beneficial from a usability perspective to minimise - or avoid entirely - situations where the user has to pick an identity for a particular service. This could be accomplished by having rules to describe services and their mapping to identities. Such a rule could match, for example, a particular identity for all IMAP servers, or a particular identity for all services in a given service realm. These rules could be configured as a part of the automated identity addition process described in Section 6.4.2.2 or Section 6.4.2.3.
The presence of rules-based associations brings with it potential conflicts in the rules. A non-exhaustive list of conflicts includes:
Identity selectors MUST order the precedence of rules as follows:
Identity selectors SHOULD notify the user whenever a new rule will take precedence over an existing rule.
A user MUST be able to disassociate an identity with a service - that is, to be able to remove the mapping without having to remove the identity.
For serious authentication errors, the identity selector SHOULD prompt the user to choose whether to disassociate the identity from the service or retain the association. The prompt SHOULD explain the nature of the error.
When such a serious authentication error occurs and the identity is selected by a rules-based association (Section 7.1.2), any disassociation prompt MUST inform the user that the identity was selected by a rule. The prompt SHOULD allow the user to retain the association, or to disassociate the rule altogether. The prompt MAY include a third choice, to create an exception so that the rule does not apply to this specific service.
As of this writing, there are no authentication failures that should cause the disassociation of an identity from a service.
A service listing should be considered in the identity selector which is both searchable and editable by the user.
When a user is attempting to authenticate to a service for the first time, there should be some indication given to the user as to which service is requesting authentication. In many cases, the service may be obvious (where the user has started the process of attempting to authenticate to a particular service), but in other cases this may not be obvious (e.g. if an authentication attempt is triggered by a timer or a specific event), and for this scenario some indication as to the requesting service is necessary.
It would be beneficial if, when using a service, the identity currently in use could be made visible to the user while they are using a specific service. This allows the user to identify which identity is used with a particular service at a particular time (the user may have more than one identity that they could use with a particular service) - so that they can then disassociate the pairing. This is especially useful when the identity is selected without any user prompt, because of a previous association.
Implementing such a feature may be hard, however, due to the layered nature of the ABFAB transaction - the identity selector will certainly know when successful (or failed) authentications to a particular service have happened, but after that it typically plays no further part in the use of the service. Therefore, knowing that a particular service is still using a particular identity in order to indicate this to the user would be challenging.
One approach that could be used would be to display OS notifications when an identity is used. The notification could include information such as the application requesting the identity, the service receiving the identity, and the identity used. Another approach could be for the identity selector to maintain a history of identity use.
An Identity Selector should be able to deal with the case where a user has multiple identities associated with a single service. For example, upon receiving a request for authentication to a service that multiple identities are configured for, ask the user which of the identities should be used in this instance.
There may be cases where a user does not wish to use ABFAB based authentication at all to a particular service, even though it is ABFAB enabled. To support this, the identity selector would have to allow the user to choose not to use ABFAB when they attempt to authenticate to a service. It would be desirable if the user could also flag that this should be remembered.
Errors during the ABFAB authentication process can happen at any of the many layers - they could be GSS-API errors, EAP errors, RADIUS/RadSec errors, SAML errors, application errors, etc. ABFAB based technologies are limited in error handling by the limitations in the protocols used.
All GSS-API calls are necessarily instantiated from within the calling application. For this reason, when an error occurs the error is passed back to the application in order for it to deal with it. To retry, the application needs to re-initiate the GSS-API call. Unless the application has been written to deal with this properly, this process can be very tedious for a user and cause them opt out of what they are trying to accomplish. In addition to this, the application may not display the error messages to the user. Even when the application does display the errors, the messages themselves may not be useful enough for the user to decipher what has gone wrong.
Two extensions to GSS-API are suggested for the consideration of the kitten working group:
The Identity Selector can improve the general GSS-API error reporting experience by displaying a list of errors experienced by ABFAB applications. When an application error occurs, the EAP mechanism MAY record that error. If the mechanism records these errors, the Identity Selector MAY display these errors to the user. Thus, the user will have a single place to go to view all of the errors that a user experiences across all applications. Therefore, an Identity Selector that implements an error display SHOULD present the user with the context of the error, including the calling application and the time.
To give an idea of the range of errors that might be seen, consider the following non-exhaustive set of potential errors.
Identity Association/Verification Errors:
Service Errors:
Other Errors:
It is of course hoped that the identity selector will have to occasionally handle successes as well as errors. This section has some brief discussion about some areas you might want to think about.
The first time an identity is used with a service, it would be good practice to visually indicate in some way that the process has been successful, in order that the user understands what is happening and is then prepared for future authentication attempts.
On an on-going basis you may or may not wish to indicate visually to the user a successful authentication to a service. This relates to Section 7.5.
This section briefly discusses other considerations that you might want to think about that don't fit in any of the other categories.
When an ABFAB authentication request is triggered, and where it needs input from the user, the Identity Selector should take focus in some way so that it is clear to the user that they need to do something to proceed.
For various reasons, an identity selector implementation might want to include functionality that allows for the export/import of identities and service to identity mappings. This could be for backup purposes, to allow a degree of mobility between identity selector instances, etc.
If providing this functionality, it would be advisable that the credential store that is the result of the export should be secure - encrypted and password protected - given the nature of the information.
Most security considerations are ones relevant to the use of GSS-EAP and are detailed in [I-D.ietf-abfab-arch]. There are, however, a few specific sets of security considerations related to the UI implementation.
First, as discussed earlier, the Identity Selector should use a Trust Anchor to authenticate the IdP before it sends the users credentials to it. Having no Trust Anchor information at all, or an incorrect Trust Anchor, can enable the possibility of someone spoofing the IdP and harvesting credentials sent to it. So, how this Trust Anchor is configured and managed can have major security implications:
Secondly, the storage of the user's credentials by the Identity Selector should be done in a secure manner to mitigate against people taking unauthorised control of the device being able to gather these credentials. Use of a secure credential storage mechanism, such as the GNOME Keyring on Linux, or Keychain on the Mac, are recommended.
Since the ABFAB system facilitates the sharing of identifying information about a user, the undesired sharing of information is a real concern. Most of the privacy considerations lie outside the scope of the Identity Selector UI, which neither controls nor sees which attributes of an identity will be shared with a service. In essence, the only control that the Identity Selector has is whether or not a given identity will be shared with the service.
However, the selection of identity does warrant privacy considerations. Any automated choice of identity for a service will share information, potentially inappropriately. Examples of this include:
Even appropriate choices of sharing an identity with a service leaks information about the user. The desired service and the identity provider must communicate with each other to perform an authentication. Even if the authentication fails, the service will know the realm of the user credential, and the Identity Provider will know the realm, and maybe the service, that the user tried to access. For services with fallback authentication mechanisms, the system may try and fail to authenticate the user, thus sharing the realm information noted above, without the user being aware this has happened.
This document does not require actions by IANA.
The following individuals made important contributions to the text of this document: Sam Hartman (Painless Security LLC), and Maria Turk (Codethink Ltd).
Thanks to Jim Schaad, Stefan Winter, David Chadwick, Kevin Wasserman, Alejandro Perez-Mendez, Ken Klingenstein, and Dave Crocker for feedback and suggestions.
| [MS-CS] | Brown, K., "The InfoCard Identity Revolution", July 2006. |
Note to RFC Editor: if this document does not obsolete an existing RFC, please remove this appendix before publication as an RFC.
IETF draft -03 to ietf draft -04
IETF draft -02 to ietf draft -03
IETF draft -01 to ietf draft -02
IETF draft -00 to ietf draft -01
Draft -04 to ietf draft -00
Draft -03 to draft -04
Draft -02 to draft -03
Draft -01 to draft -02
Draft -00 to draft -01
Note to RFC Editor: please remove this appendix before publication as an RFC.