Users & Groups

All content in Liquid Site can be protected. This makes it possible to only allow access or modifications from certain users or groups of users. The authentication and authorization scheme has been designed to work in as many configurations as possible, while keeping complexity to a minimum. Below follows a list of the original requirements with a brief explanation of the current design.

• Control access for all content objects
  All managed content requires authorization in order to be accessed. Unauthenticated users may be allowed read or write access. This is achieved by checking every content read or write operation with the corresponding access control list.
• Allow access for single users or groups of users
  Access to content objects can be granted either for single users, groups of users, or any user. The list of users and groups are be specified in the access control list along with the permissions for each. If a user matches several of the items in the access control list, the union of the specified permissions are used.
• Separate permissions for read, write and publish
  In a content management system, it makes sense to distinguish between read, write and publish operations. Read is any non-modifying access, write is the operation of updating offline content, and publish being the operation of putting content online or offline. The system also has separate permissions for admin operations, required in order to modify the content access control list.
• Allow user accounts to span related web sites
  Multiple related web sites are typically hosted in the same installation, such as "www.domain.com" and "forum.domain.com". All such sites can share a single set of users and groups, making the user experience simpler while allowing more efficient administration. This is achieved by structuring user accounts into domains, where each domain may contain several (related) web sites.
• Separate user accounts for unrelated web sites
  Multiple unrelated web sites may be hosted in the same installation, allowing a hosting company to share the hardware and software setup between several customers. Full separation between the different web sites can be guaranteed and a user account for one site will in that case not overlap or conflict with a similarly named user account for another site. This is also achieved by using domains. The user accounts in one domains are completely separated from the accounts in another, allowing the same user name to refer to different users depending on the domain.
• Allow any number of users and groups
  User and group names have have no inherent meaning in the system. They are given meaning as they are added to the access control lists of content objects. Each user may be member in any number of groups, and each group may also have any number of users as members. Users and groups must be in the same domain to have a membership relation, though.
• Allow global administrators access everywhere
  System maintenance and configuration, requires at least one global administrator user. These users do not belong to any domain, and have full access to everything in the system. Global administrator accounts are also useful when hosting multiple domains in a single installation, such as a hosting company would do. It is important, however, to protect these accounts as much as possible.
• User authentication by password and IP address
  User authentication is done with passwords, while also allowing remote IP address checks for sensitive accounts. It is possible to specify a single IP address or a range or IP addresses, thereby limiting the access for that user to those addresses.
• Passwords only stored encrypted or hashed
  All passwords are protected in the database, making it impossible to access them even for a system administrator. This is achieved by only storing an MD5 hash of the password in the database. This makes it impossible to retrieve the original password, and requires new passwords to be created if the user has forgotten the previous one.
• Protection against password attacks
  Some protection is provided against password dictionary attacks. The database is protected by adding the user name to the password hash, effectively making every hash value different. The web login is protected by delaying responses to invalid logins, slowing down dictionary attacks by several orders of magnitude.