This page describes a conceptual model for security and access control. This does not describe the implementation of the current releases of Photo Organizer. However, it may become the design for future versions. For more information on current developments regarding the Photo Organizer permission model see FS#8 - Better permission hierarchy and new permission model.
The topic of security is rather broad as it encompasses different parts of the system. These are the areas where there is a need to consider security:
Let us first focus on the permission model which underlies the mechanics of access control to information in the database.
Permission modeling can be approached as a two part system. On the one hand you have the physical entities that describe items from the real world. On the other hand you have logical entities that define the logical relationships between the physical entities.
Physical entities that have a place in the database are:
Users relate to physical beings in the real world, that is: us humans (although I do not necessarily rule out other intelligent life forms). However, it may be more practical to relate users to the role they have in the system. So a single person can be multiple users in the database system as well as that a single user in the system may be owned by more than one person. An example of the former would be a person having access to both the administrator account as well as his own personal account. An example of the latter may be the administrator account that is being used by two persons who both are responsible for maintaining the system. Another example of the latter would be a guest account which is the default for anyone who is not registered in the system as a specific user.
In essence, the user entity in the database is the unique identification of the person using the system. No action can be performed unless it is related to a specific user. What it all boils down to is that we need a form of identity management.
As this system is designed to manage a repository of photographs the next physical entity in the system is the photo. A photo can be in a multitude of physical formats (where for the sake of simplicity a digital original as retrieved from a digital still camera is also considered a physical format). The list of physical formats includes:
When we talk about a photo, we always talk about the original.
Equipment is all the tools we have for taking photographs. This includes more than just the camera.
A list of equipment items contains:
There may be more physical entities. A possible candidate is location.
Logical entities that have a place in the database are:
Grouping is a mechanism to define sharing of properties between different entities. Grouping can have a structural meaning, such as with folders and albums. It can also have a logical meaning such as groups.
Groups are the structural building blocks of permission management. In theory, anything can belong to a group. This way a group can define a relationship between various entities in the database.
A group can contain any number of users, which translates in those users being a member of that group. When a user is a member of a group it means that the permissions that the group has on some entity are also granted to that user.
At the same time, various photos can also be contained in the group. For each photo the permissions on it for other members of that group can be set. Now, where a group can hold multiple photos, a single photo can also be a part of multiple groups. So between an photo and a group exists a many to many relationship and permissions are set on each relationship individually.
Groups cannot contain other groups.
The relationship between folders and photos is one to many. A photo can only be a member of a single folder. A folder can contain multiple photos as well as multiple other folders. Folders define the logical structuring of the repository that contains all the photographs. Typically this structuring is based on time and place of taking the photographs for example.
Where folders and photos have a one to many relationship, photos and albums have a many to many relationship. Albums perform a logical structure for viewing of photos in the repository. This structuring is based on the representation environment in which the photos are used.
Albums can be static, in which case individual photos are added to the album. Albums can also be dynamic based on a search rule. The result of the search can be cached (in a similar manner as the static album) for speed. However, the contents of the album can be recreated from scratch by repeating the search. (This is a great feature of gthumb).
Should we allow albums to contain albums?
Ownership is always unique. There can be only one owner who is god over the entities he/she owns. An owner is always a user making it a unique identity. All entities apart from users can in theory be owned. Typical examples are photos, folders, albums, equipment and groups.
Membership is not unique. The owner can grant membership of an entity to a group. With the membership comes the granting of permissions. The permissions granted to membership can go as liberal as giving a member the same rights as the owner (although never permission to change the ownership).
There are two kinds of permissions:
The owner can always change his or her own permissions. The reason to set owner permissions is that this way a user can set the entities he owns to read-only for example to protect him-/herself from accidentally damaging his/her own data.
The group permission can also always be changed by the owner of the group, but also by any user member that has the right permissions on the group.
The relationships between the various entities in the database define the framework for our permission management. What actions are allowed to be performed by whom? And who is allowed to manage these permissions? And this is circular as changing permissions is also an action that is controlled by permissions.
Identity management describes the methods used to verify that someone using the system is who he/she claims to be. All identities are stored as user entities in the database. The first thing that the system needs is the identity name, or more commonly called the user name. This is how a person using the system tells it who he or she is (or as discussed above, in what role he or she is acting).
Just telling the system who you are is not enough. I could claim to be anyone. How would the system know I'm telling the truth? This is where authentication is needed. Good authentication verifies the identity by checking the following related information:
In practice, most systems only use the first one: something you know. Which most commonly is known as a password.
The authentication steps described here are usually implemented as a login.