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.
- 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
- ACL-type of permission system with allow/deny and priorities
- Setting permissions at the content item or instance level
- 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
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)
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.
- 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
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.
- 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
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.
- Administer contents through XML-RPC APIs
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.
- 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
- 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"
2. Name and configure permissions for the new role
3. The role is created
Add a user
1. Click "Add a user"
2. Set a user name, password and configure permissions
3. The user is created
1. Click "Manage users"
2. View existing users
3. Update the user account with new role
4. User has been updated
1. Click "Manage roles"
2. View existing roles
3. Update the role with new permissions
4. Role has been updated
1. User clicks "log on"
2. User clicks "create an account"
3. User chooses a name and password
4. User logs in