Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Access Control Use Cases

Revision as of 23:32, 8 July 2008 by Paul.socialphysics.org (Talk | contribs) (HR directory)

{{#eclipseproject:technology.higgins}}

Higgins logo 76Wx100H.jpg

This page is a collection point for IdAS access control use cases. It is really just fodder for discussion for the "access control work area" that we're working on as part of Higgins 1.1

We need to collect a set of representative use cases and see just how powerful a mechanism is needed in Higgins.

Please add new use cases at the end so as not to mess up the numbering.

HR directory

Each person listed in the directory can:

  • update ex:fullname and ex:email attributes of their own entry (Entity)
  • read ex:employeeId (and the above two kinds of attributes) of their own entry

Members of the HR department (group) can:

  • edit all three kinds of attributes of every entry

Attempted modeling of this use case: HR Directory Access Control Policy

HR directory delegation (Enterprise reporting chain)

Scenario

Chuck, Bob's manager, needs to update Bob's profile at work to indicate he is on vacation. Unfortunately, Chuck is out sick. Chuck's manager, Jane, make the profile updates to Bob's work profile.

Use cases

  • Bob's manager, Chuck, can update most attributes
  • Chuck's manager (and any manager up the reporting chain) can update most of Bob's attributes

HR directory access by entity type/attributes

Scenario

When Bob searches the directory of company contacts for folks working on Government contracts, the results include regular employees, contractors, and business partners. Bob's secretary, on hire from a temp agency, can only see regular employees in the same search.

Use cases

  • Bob, whose profile indicated he is a regular employee, can see all unique identifiers returned from a search, including sensitive business information like sub-contractors and business partners. regular employees can view all attributes
  • An employee whose attributes identify them as a non-regular employee can only see the unique identifiers of entries in the white pages of full-time employees. non-regular employees can only view limited information of regular employee white pages entries.

Doc Searl's "Vendor Relationship Management"

Each customer of British Airways can:

  • update selected attributes of their Node (e.g. email address)
  • see/read selected attributes of their own entry

British Airways administrators can:

  • update all attributes except "customer" attributes

Find privileged user

  • Use a key to uniquely lookup a user in the backing store as a sufficiently privileged user and then use the authorization characteristics of that user for all subsequent requests.

Social B2C/Website

Scenario

Bob is interested in using the ACME CD Swapr website to connect to folks locally and nationally to swap CDs and participate in music oriented meet-ups. Bob may also Buy new CDs through the ACME CD/MP3 store. First, Bob checks the Google Maps mash-up that shows the number of ACME CD Swapr members in his City and the surrounding zip codes. Bob thinks the members in his city are sparse, but just there are a bunch of members just down the road in Medfield. Bob enrols and creates a profile. Bob can access the CD/MP3 store with his free "Bronze" membership. but to link to other folks in the area, Bob needs to upgrade to the "Silver" level for $9.99 a month through the on-line upgrade program. Now Bob can browse the network for folks near by and send "friend" requests via the nick-name displayed. Bob sends Alice a friend request. She accepts. Bob can now see Alice home address and phone number and the list of CDs she is looking to swap. Bob can also see Alice has Ted as a friend, Bob can not see Ted's contact information, but he can see that Ted is willing to swap any of his AC/DC collection of CDs for Amy Winehouse. Bob sends Ted a friend request.

Use cases

  • Unauthenticated user of a social website or B2C portal can create a limited profile with a subset of attributes needed to enroll into the service
  • User of a social/B2C website can view all attributes of their profile
  • User of a social website can update most attributes of their profile: phone number and email, but not membership level
  • Friends of the User can view the entire profile
  • Friends of friends can only see limited profile
  • The rest of the "Unfriendly" network can only see "city/zip", "nick name", and "Photo" (default policy for authenticated users)
  • Anyone outside the network can only see "city/zip" (default policy for unauthenticated users)
  • Help desk administer of social/B2C site can update most attributes (group based role)
  • Business application can update membership level attribute (agent or group based role)

Family plan management

Scenario

Bob enrolls with his telco to manage his Family Phone Plan. The telco website lets Bob set up additional profile/accounts for each of his family members, one per phone. The family accounts has passwords, and Bob can change the passwords on any sub-account. Later that year, Bob decides to delete his on-line presences with the telco. All the his family's profiles are deleted as well. (Same scenario applies to B2C healthcare records, and B2B delegation)

Use cases

  • Telco admin/helpdesk can change all attributes for Bob's profile and his family's profiles.
  • Bob can view/update all the attributes in his profile, as well as any of his family's profiles
  • Bob's wife and kids can view/update only their own profile

Delegation

Scenario

Bob is going out of town and will be vacationing where there is no internet access. While out of contact, Bob and wants to delegate the administration of his telco account to his Lawyer.

Use cases

  • Carol, Bob's lawyer, can view/update all the attributes in his profile, as well as any of his family's profiles until Bob removes the delegation.

Application programming scenario

Scenario

Marjorie is writing a new interface to the white pages directory. With the new UI, the employees will be able to navigate through the reporting hierarchy. not all branches of the org tree are visible to all employees. Marjorie's application needs to detect if there are any entries in a subtree that can be viewed by the user. If not then the subtree "folder" icon on the UI is grayed out. When the user selects an entry, the profile for that entry is displayed. Attributes that the user can read but not change appear in a grayed out text box.

Use cases

  • Application programmers use a scalable indicator/API to determine access privileges for an object and set of objects that are related in a structure (e.g. Org tree, friends network).

Facebook R-Card

Assume we implement an R-Card whose context provider provides (e.g. via the Facebook F8 API) access to the user's Facebook profile data. The Facebook terms of service state that the attributes of this provide can be viewed (read) but cannot be cached. We need to be able to express in the access control policy that the user's data can be read but not permanently written. It is critical that data values from the Facebook R-Card are never copied into any other i-card.

R-Cards

Note: this section needs to be rewritten into std use case form.

  1. We need a way for a Context to express what operations are permitted on attribute values
  2. We need to be able to control access to the following resources:
    1. Value(s) of all instances of a given attribute in a given Context
    2. Value(s) of all instances of an attribute on any Entity represented by the "requesting" IdAS consumer [called a "subject" in XACML]
    3. Value(s) of an attribute on a specified Entity [<--would be nice, not strictly needed for R-Cards]
  3. We need to be able to control access based on the OpenID/i-name/i-number of other Entities (e.g. the Bob, Charles and David mentioned in the example below) although these Entities may not be resolvable

Here is an example policy.

  • We have a Person Entity representing "Alice" in a Context
  • In this Context each Person Entity has a http://fabrikam.com/shoe-size attribute
  • On all Person Entities, all values of the shoe-size attribute can be:
    • Modified by Alice
  • On the Person Entity representing the user="Alice", the values of the shoe-size attribute can be:
    • Modified by Alice
    • Readable by Bob, Charles and David <-- Alice has shared this attribute with Bob, Charles and David

See Also

Links

Back to the top