Design Pattern: Role Based Access

Design Pattern Metadata

DRAFT: June 2016

Title

This pattern shows how a single web site can result in a very different user experience depending on the attributes of the user.

Status

Design Pattern Lifecycle Status

Contributed	Working Draft	Committee Review	Compilation	Approval	Publication
This Design Pattern is available for review by the User Experience Committee (UXC) with the goal of refining and completing the Design Pattern, see Identity Design Patterns for the current list of design patterns and their status.

Design Pattern Review Status

Contributed.

Expect changes before this pattern is final.

Design Pattern Category

Privacy, Trust/Assurance, Interoperability

Contributor

Tom Jones

Design Pattern Content

The terms used in creating design patterns follows the taxonomy described in the UXC_Use_Case_Mapping#Categories_used_in_User_Experience_Evaluations

Problem Description (meme)

There can be users with wildly different experiences depending on the role that they perform on one web site. This pattern is concerned only with users that access a web site from a standard user display device without special protection hardware from the internet. This pattern is concerned only with web sites that chose to provide access to users that have different roles with different user experiences.

When to use this Pattern (Context)

Any time a single site choses to support user access from the internet with different experiences depending on the user role based on user attributes bound to the user accessing the site.

Relationships with other Design Patterns

This pattern is specific to access of internet sites from common user devices without specific additional hardware security protections. See Design pattern: User Devices with Hardware Security Protections when the user is required to have a device with any specific configuration.

Actors

The following roles are present in any IDESG compliant ecosystem. Note that some of the roles may be collocated in a single site on the Internet. This section uses the "Entity" definition of the IDESG Functional Requirements as any organization providing or using identity services. Before all of this can be defined there needs to be an Identity Ecosystem, an online environment where individuals and organizations will be able to trust each other because they follow agreed upon standards to obtain and authenticate their digital identities—and the digital identities of devices. For this pattern the RP must be able to access sufficient attributes to determine the role that the user will fulfil. Any user that accesses the site will be able to understand the purpose of the site and its acceptance of IDESG principles while remaining anonymous.

1. User: An individual human being This does not include machines, algorithms, or other non-human agents or actors.
2. User Agent: in this case any piece of code that displays a user experience and obtains responses from the user in order to satisfy the privacy concerns of the user and the need for identity and attribute claims by the relying party.
3. Entities The collection of all internet based services with which a user will interact to create, supply and consume identity and attribute claims as required to complete the task that they have undertaken.
   1. Identity or Attribute Provider (IAP): An entity that contains identities or attributes of users that will be provided on demand in claims that the user can forward to a RP.
   2. Relying Party (RP): An entity that needs a collection of claims to provide that service; the RP will be using the attributes from one or more provider to determine the role that the user is performing and present a UX appropriate to that role.

Solution

Description of the Solution

In this design pattern, the user may be able to access some pages on the site anonymously, but the pattern only addresses the user experience when the user wants to perform a specific role with specific privileges.

1. The user establishes an account with one or more IAPs that are accredited with one or more IDESG Trustmarks. In this case there is no need to distinguish between identity providers and other attribute providers.
2. The user accesses a web site which at some point requires identity and attribute claims of some sort to determine what set of user experiences the user may access. That web site then transitions from providing purely anonymous access into a relying party.
3. The RP displays a request to the user for an identity.
4. The user selects an identity to use that will enable the role that needs to be performed.
5. Any request from the RP for user attributes to satisfy that role is intercepted by the user agent, or any privacy-enhancing technology intermediary.
   1. The user agent has or acquires the claims necessary to meet the site expectation.
   2. Format the set of requested claims into a response in a way the RP can evaluate the claims.
   3. Send the response to the RP who has sole responsibility to determine if sufficient claims have been proved to authorize the requested role access.
6. The RP displays the user experience appropriate to the role selected by the user and authorized by the RP.

Anti-patterns

TK

Error Conditions

The following are specific errors that the user might see.

1. User does not have credentials that can generate claims acceptable to the relying party for the role that they want to use.
   1. Mitigation option: The provider redirects the user to one or more sources of appropriate credentials that do meet the criteria for authorization at the RP.
   2. Mitigation option: The relying party redirects the user to one or more Identity Providers or trust frameworks that are acceptable. If a new framework is chosen, that may involve user acceptance or change the PET to meet those particular authorization requirements.
   3. Mitigation option: The user is allowed to back-out of the current path to one where they can succeed.
2. User cannot access the role that they want.
   1. It is often the case that the RP will not ask the user what their role is, but use the identifier presented to look up their attributes and assign a role based on that set of attributes.
   2. The user at least has the possibility that the RP can change their registration to accommodate their designed role.
   3. The user can change their attributes that are linked to the identifier that they used.
   4. The user can select a different identifier to use with that RP.

Usability Considerations

This section further refines the user experience defined in the User Experience Overview.

TK

Read the report of the IDESG experience committee on use case usability at UXC Use Case Mapping

Value Proposition

This pattern allows the RP to create a single web site for all users where the role of users directs them to the appropriate user experience.

References and Citations

TK

NSTIC Guiding Principles Considerations

User Experience Considerations

Whichever role the user is granted by the web site, it is necessary that the user understand the role and what the impact that role will have on the data they see on the site and the data that they provide to the site.

Privacy Considerations

It is always the responsibility of an IDESG compliant web side to provide information only to users who are authorized to see it. In this pattern the web site supports roles that have different levels of access to user data.

1. Having a single site RP with multiple roles may expose information to some users that are not appropriate to their role.
2. Evaluation of a site with multiple roles will be a challenge for the following reasons:
   1. The RP/site assessment tool is designed to ask questions of the assessor that will not have a single answer.
   2. The RP could create a different assessment form for each role on the site.
3. The site might chose to only assess for some roles, which would imply that only compliant roles would see the IDESG TrustMark.

Security Considerations

Security is more difficult on a web site that contains multiple roles. That disadvantage should be carefully weighed against the advantage of having a single site for multiple roles.

Interoperability Considerations

No special consideration was identified.

Specific Industry Examples

Health Care

• Several specific examples within the health care communities that have different levels of access based on their role:
  • Users of the healthcare system that is open to any person seeking healthcare. It is an open system.
  • Patients that want to access personal health information.
  • Guardians of others that are authorized to handle the patient's health choices typically with specific choices of the patient documented.
  • Providers of the health care system that is open only to persons with credentials appropriate to the care provided. It is a closed system.
  • Providers that are authorized to prescribe drugs or courses of treatment for patients.

The specific interest of the User Experience Committee is the open enrollment of any person looking for health care. This involves every range of user involvement and should be able to accommodate all comers, but may need to send the user to some other location for verification of some attribute as a part of authorizing health care. A user should have the capability to anonymously browse health care provider web sites to determine their qualifications and cost before providing private information. On the other hand the user should expect that health care information will not be released to them until they provide strong proof of identity.

No specific affinity group has been identified for health care users at this point, but there are several NSTIC pilot projects that show ways that users of health care can be accommodated with an IDESG compatible solution.

Education

• student
• teachers
• School Administration
• Parents or guardians (may have multiple sub roles depending on student's choice)
• Affinity groups like school clubs