THE PROPOSAL
ISSUES TO RESOLVE
IMPLEMENTATION TASKS
USE CASES
PROBLEM USE CASES
USER EDUCATION/NOTIFICATION REQUIREMENTS

THE PROPOSAL

Throughout the process of trying to come up with a plan for access control, we have been pulled between two conflicting goals: privacy of content, and making it easy to share content. What we have decided is that in the short-term we need to emphasize privacy over convenience. We need a plan that is relatively simple in design, so we can build onto it, rather than coming up with something very complicated for convenience of the user, when we are not entirely sure we have it right yet. The plan below will require the user to do a lot of the management of items' permissions. While less convenient to the user, it is at least transparent, and hopefully relatively straightforward in concept. Over time we will take measures to improve user experience.

Privileges on Libraries and Items:

• READ
• DOWNLOAD (which implies read)
• WRITE (which implies download+read)
• ADMIN (which implies write+download+read) - You must have admin rights over an item or library to pass on permissions to others.

Privileges on Albums and slideshows:

Access control on albums and slideshows is completely different from the access control on libraries/items. Albums and slideshows are used to organize and present content, but not used for access control. We want to separate the terminoligies as far apart as possible. There are two levels of privileges on albums and slideshows:

• VIEWER (see the album/slideshow, but not edit it)
• COLLABORATOR (edit the album/slideshow and invite more people)
  

There are three different types of Albums/Slideshows

• owned and personal album/ss
• owned and shared album/ss
• Other people's album/ss (shared and not owned)

Since albums are not used for access control, we need to have strict rules on what items can go to each type of album:

1. if you have read access on an item, it can go to your owned and personal albums.
2. if you have admin access on an item or if the item is publicly readable, it can go to your owned and shared albums
3. if you want to share a personal album, the system will check to see if all the pictures in that album fit the conditions in 2, otherwise, the share is not allowd. An error message is returned saying "you cannot share this as you don't have permission to share all the items in this alb/ss". In some way the UI will hi-lite, or at least list, all the items the user does not have SHARE over, so they can remove them from the alb/ss if they still want to share it.
4. to put image into other people's album, you will have to 1. be a collaborator 2. the image has to be publicly readable or the album owner has admin access on the image. This is the most confusing part, but it actually makes sense. We need to use UI messages to help the users. For example, if the user is the owner of the images, but the album owner doesn't have admin access on the images, we should say "This is a shared album and its owner is xxx. You have to give xxx admin rights over the images in order to put those images in xxx's shared albums".
5. to share an album that you don't own, you will have to a collaborator on that album. 
   

The above access rights should be strictly followed before we allow people to put images in albums or to share albums. We don't make access rights changes for the users. As a result, if the album becomes unshared or images get deleted from albums, we also don't need to make any access rights changes on the items.

Item-specific permissions:

• Item-specific permissions can be set from within a library or an album or search result (but not within a slideshow)
• Items always still inherit permissions from the library they live in; you can use item-specific permissions to add privileges, but not to take away privileges.
• Album and Slideshow permissions will have NO impact on, or relationship to item-specific permissions. So, if you change privileges on an alb/ss, it has no impact on the items it contains.
• Users must explicitly set permissions on items. They do this by selecting one or more items in the thumbnail window (in either a library or album), and clicking the 'share' icon that we will add to the bottom of the screen, with the other item-level icons.
• In albums, and search results, there will be the option of applying "batch permissions" on all items.
• the domain admin can take ownership of a library or an item. If domain admin wants to take ownership of an item, he/she has the option of remove the library inheritance. This is used to limit access to questionable contents. For example, if user A has some images in his personal library that violates our term of usage, a domain admin can take ownership of those images and also remove the library inheritance, so even user A will not have access to those images.

User Experience Managing Item-specific permissions:

• Items that have privileges independent of their parent library will have a little share icon in the bottom right corner (or in some other way, will have a visual marker so its clear which ones have special privileges). This will make it easier to manage these privileges.
• Selecting an item, and then clicking the item-share icon will bring up the share window, and show existing privileges. User can then add or remove privileges.
  • Users other than the owner should be prohibited from removing privileges from the item owner - even though alfresco enforces this, we should give the user error message, so they know.
• If multiple items are selected, privileges they all have in common will appear, but not privileges that differ. If a single item is selected, all existing privileges on it will appear.
• If the user does not have share privileges over a particular item, then when they click the share icon, they will receive an error. We are unlikely to be able to check beforehand and make the icons disabled if they don't (which would be best); more likely we'll need to let the backend enforce this, and report errors after the fact. This is another area that could use some enhancement in future.
  
  

Revoking Privileges:

• In order to be able to take away privileges once they have been given, we will have to make thumbnails protected in albums and slideshows. In libraries and search results, thumbnails will be public. There will be 2 different URLs for thumbnails: one is the publicly accessible url, over http, that goes directly to alfresco. The other URL will go to the IME, and will be over https. For example:
  • Public URL:  http://isda-thalia6.mit.edu:8080/alfresco/guestDownload/direct/workspace/TEST/ac05bad4-7cba-11dc-a3e8-abc6d12769f5/thumbnail    (or /medium or /large)
  • Protected URL: https://hst.thalia.mit.edu/item/ac05bad4-7cba-11dc-a3e8-abc6d12769f5/map/b1de2507-7cba-11dc-a3e8-abc6d12769f5/thumbnail; (or /medium or /large) The URL contains both item id and the album/ss id.  We will use the album/ss id to find the album/ss owner. It guarantees that the user has at lease "viewer" permission on the album/ss. If the owner is different from the user, We also double check that the owner still has full admin rights over the item and then we use the owner's credential to retrieve the item thumbnail/medium/large. If the owner is the same as the user, we still use the user's credential to retrieve the item thumbnail/medium/large.  
• If READ privileges on items have been revoked for the album/ss owner, then everyone (including the owner) will see the 'not authorized' icon instead of the image. If ADMIN or WRITE privileges have been revoked, but READ remains, the items will still be visible to the owner only.
• If Admin privileges on the items have been revoked for the album/ss owner, then only the owner can see the items in the slideshow. All other users will get "not authorized". In a way, the shared album becomes a personal album.  Also the owner will not be able to further share the album/ss.
• In albums and slideshows, we will not put the URL to the items in the xml. Instead, we will construct the URL from the item id and album/ss id. The images will be served over https, which will have performance implications. But it allows us to enforce the access restrictions in the case where someone grants share rights to a user, that user shares the image with others, it gets into various albums and slideshows, and then the owner of the content revokes the share privileges. In this case, once a privilege is revoked, the item will show the 'not authorized' icon.
  

IMPLEMENTATION TASKS:

• UI Changes:
  • Add share button at item level in library, album and search results. Clicking on one or more items brings up share window for that item.
    • Button will always be hilited, backend will have to enforce what user can and cannot do
    • Make the message back from the server as user-friendly as possible
  • Add 'batch permissions' option in library, album, and search results
  • Album & Slideshow: Change permissions to 'viewer' and 'collaborator'
  • Ideally, on items that have their own item-level permissions, show a small icon in lower right corner of thumbnail, indicating that they have individual permissions distinct from the library
  • Dragging items to albums/slideshows, will need to add more complicated rules per this document. Item-level privileges will need to be checked by backend, though, as we wont have that information in the UI beforehand.

IME Changes:

• the authz servlet will be modified. If the user wants to create a new authorization (sharing) and the qualifier is an album or slideshow, the backend will first check:
  • if the user is the owner of the album/ss,  all items inside the album/ss need to be either publicly readble, or the user has to have admin rights over.
  • if the user is not the owner of the album/ss, the user needs to be a collaborator for the album

           If all the images pass the check, the share will be saved to the repository. If not, an error msg will be returned and it will include the detailed msg on which images failed the check and why.

• will add a servlet: map/xxx/add for adding items into album/ss. The back end will first check
  •  if the album/ss is not shared, the user needs to have read permission over the item to be added
  •  if the album/ss is shared and the user is the owner, the item needs to be public readable or the user needs to have admin rights over it
  •  if the album/ss is shared and the user is not the owner, the item needs to be publi readable or the album owner needs to have admin rights over it         For the items that pass the check, I will add it to the unuseditems section for slideshows and the page section for albums. I will save the content to the repository. The return xml will include the updated xml for the slideshow/album. It will also include a msg section which shows that which items (if any) failed the check and why.  

•  the authz servlet will also be modified to allow item level access control.
• Will add a new attribute to item to let the UI know if an item has custom permission or not.
  

USE CASES:

SAP & HST:

• Judy uploads files to a library. She creates an album, and gives Jamie Collaborator on it. Jamie makes changes, and then is ready to let the publisher know that they are ready. Jamie is able to share the album with the publishers. However, Jamie cannot give the publisher download rights unless Judy explicitly gives her ADMIN on either the library, or all the items in the album. The publishers will be able to see all the items in the album, but will need to ask for item-level download rights in order to download them.
• Everyone on the team needs to be an admin of the libraries where the content lives. Once we have groups, this will be very easy to make work.  

Stellar:

• Professor A gathers content from Rotch, and from Vue, and creates a slideshow. She is able to give her students READ on the slideshow, because all items in that slideshow is readable to public.
• Professor B has a library, and gives Professor A read access. Professor A takes some content from Prof B's library, and adds it to her slideshow. When she tries to share it, she is notified that she cannot, because she does not own all the content in the library. She must ask Professor B to give her Admin on the items/library. She must remember that Professor B is the one who gave her the content...
  

PSB:

• User called "PSB-Seller" (or something like that) is admin over all content. All content is readable by public.
• Public User creates an album, and drags images to it. They pay PSB and reference the album name (might need some kind of generic naming/number in albums) or they can share their albums with "PSB-Seller". They do a batch-permission on all items in the album, setting DOWNLOAD for that user, and the user can download the items. When PSB wants to restrict access, they do another batch permission assignment, and take away download on all the items.
  • One place for user confusion is that PSB Seller may think that deleting the album gets rid of privileges. Must be educated, so they know to remove the item-level privileges.

Public Domain:

• There was a big party, and 7 people each upload pictures to their personal libraries. All of their libraries are private. One of them creates an album, and gives all 7 people Collaborator rights on that album. Then everyone can drag images to the album. However before dragging images to the album, they must give the album owner Admin rights on the items. All 7 people are able to invite more people to view or collaborate in this album.

Need to lock down suspected bad content:

• If bad content is reported, a domain admin will investigate the content. If the content is indeed questionable, the domain admin will take ownership of its contents and cut off the parent inheritance. If there are additional rights on that item, the domain admin might choose to remove them so the domain admin will become the only person that can access the content.
• If the domain admin decide to give the rights back, he can give the ownership back to its original owner and also put the inheritance back. Any addtional rights he removed manually will have to be added manually.
  

PROBLEM CASES:

These are cases that raise issues we need to address, either in our model, or in other ways to avoid certain problems.

• An album collaborator put images in an album  if she gives album owner ADMIN rights over those items. This can be a problem, because users may want to share, and allow others to see their content, but probably don't want to give others the right to delete the item... If the album owner has read over their library, they could go in and delete the item. MAYBE... we only let the user do things in libraries that match the LIBRARY permission level. So, even if a user has share on an item, it only really allows them to give others read, it does not actually allow them to delete the items. In this way, granting "ADMIN" on an item is implicitly granting a different kind of 'share', that only allows others to read the item. We could even call it "share" instead of "admin" at the item level...

• When a user is given the error message that they cannot share something, because they don't have adequate access, there will not be an easy way for them to know how to do anything about it. I'd like to see a feature in the future where they can click to request access.

USER EDUCATION/NOTIFICATION REQUIREMENTS

• TBD