Users and Roles

This is preliminary documentation, to be implemented in the current iteration

Orchard will include a user and role management system and a means for assigning permissions to users in the system. Eventually this feature will be used as the basis for publishing workflow as well.

Requirements

  • Do not couple authentication to membership and profile data
  • Ability to plug-in and combine multiple authentication schemes (internal AD, OpenID, etc.)
  • Must enable creation of roles by administrators and modules
  • Must be able to store custom and extensible information about users
  • Ability for areas to extend user profiles
  • Allow administrators to set-up user permissions in a scalable manner (adding more users and features do not result in non-linear growth of workload for the administrator)
  • Allows modules to expose permissions
  • Permission checking logic can be replaced
Non-requirements
  • ACL-type of permission system with allow/deny and priorities
  • Setting permissions at the content item or instance level

User Stories

  • A user can log into the application using his existing OpenID account
  • A user can create a new user account - This should include a default captcha mechanism and provide extensibility points to replace it.
  • An administrator can create a new user account - The account verification is bypassed in this case.
  • A user can access and modify all his profile information - This is by law in many countries. This includes subscriptions, etc.
  • A user can delete his account
  • An administrator can create new roles and assign users to roles
  • A module author can add new roles and profile properties
  • An administrator can manage user membership in groups
  • An administrator can modify a user's profile
  • An administrator can delete or ban a user
  • User creation can be configured to require validation and/or confirmation
  • A user can recover a lost password - If not using OpenID.
  • An administrator can personalize automatic e-mail messages to the users - Messages include welcome message (with or without approval), approval notices, password recovery, account activation, account banned or account deleted.
  • A module can expose permissions
  • A module exposes what operations can be configured to be allowed or denied to specific groups
  • An administrator can configure what groups are allowed to perform operations

Default Roles

Orchard comes installed with some default roles. New packages should provide default permission settings for those default roles to minimize the administrator's workload when adding a new package to the system.

Those roles are:
  • Anonymous users (cannot be removed)
  • Authenticated users (cannot be removed)
  • Administrators (cannot be removed)
  • Authors (typically create new contents)
  • Managers (typically manage existing contents and contents created by authors)

Permissions

As part of our initial implementation of the permission system, we are retrofitting the following permissions into the existing Orchard packages. These permission can be assigned to roles in the system.
Administration Permissions
  • Access to the administration UI
CMS Page Permissions
  • View pages
  • Create pages
  • Create draft pages
  • Modify any page
  • Delete any page
  • Modify own pages
  • Delete own pages
  • Publish any page
  • Publish own pages
  • Unpublish any page
  • Unpublish own pages
  • Schedule any page
  • Schedule own pages

Note: Granting "modify any page" for example, trumps the "modify own pages" permission. In other words, in the code, the "any" permission is checked first in code and if it checks, the second permission is skipped.
Media Permissions
  • Upload any media
  • Modify any media
  • Delete any media
  • Modify own media
  • Delete own media
  • Create media folder
  • Delete any media folder
  • Rename any media folder
  • Delete own media folders
  • Rename own media folders

Note: Uploaded media are public. There is no permission to read media. ASP.NET permissions can be applied from web.config to specific folders if necessary.
XML-RPC Permissions
  • Administer contents through XML-RPC APIs
Note: The specific rights for each content type and operation are also checked in addition to this right. If this right is not granted, none of the operations work.
User/Role/Permission editing
  • Permission administrator (the administrators group has this permission by default and it cannot be revoked from this group, which is a special case)
  • Create a user
  • Modify a user
  • Create a role
  • Modify a role
  • Assign users to roles

Error messages

  • When an operation can't be performed due to a permission issue, the user gets the following message if he's not authenticated: "You are not allowed to perform this operation. Please log into the site and try again."
  • If the user is authenticated: "You are not allowed to perform this operation. Please contact the site administrator if you think this is an error."

User Experience Walkthroughs

Add a role

1. Click "add a role"
Add a role
2. Name and configure permissions for the new role
Name and configure
3. The role is created
The role is created

Add a user

1. Click "Add a user"
Add a role
2. Set a user name, password and configure permissions
Configure user
3. The user is created
User created

Manage users

1. Click "Manage users"
Manage users
2. View existing users
View users
3. Update the user account with new role
Update users
4. User has been updated
User updated

Manage roles

1. Click "Manage roles"
Manage roles
2. View existing roles
View roles
3. Update the role with new permissions
Update permissions
4. Role has been updated
Role updated

User self-creation

1. User clicks "log on"
log on
2. User clicks "create an account"
create an account
3. User chooses a name and password
Choose name and password
4. User logs in
user logs in

Last edited Nov 11, 2009 at 12:40 AM by BertrandLeRoy, version 9