This example demonstrates how to use the new security system to implement the following security roles:
- Users (Joe, John) can view and edit tasks from their own department, but cannot delete them or create new ones. They also have readonly access to employees and other data of their own department.
- Managers (Sam, Mary) can fully manage (CRUD) their own department, its employees and tasks. However, they cannot access data from other departments.
- Administrators (Admin) can do everything within the application.
All users have empty passwords by default.
Steps to implement
1. Permissions at the type, object and member level (with a criteria) are configured in the MainDemo.Module/DatabaseUpdate/Updater file. Take special note that for building a complex criteria against associated objects, the ContainsOperator together with the built-in CurrentUserId and IsCurrentUserInRole criteria functions. For greater convenience, strongly typed criteria for permissions are accompanied with their string representation.
2. The SecuredObjectSpaceProvider is used in the CreateDefaultObjectSpaceProvider method of the XafApplication descendants located in the WinForms and ASP.NET projects.
3. Permission requests caching is enabled via the IsGrantedAdapter.Enable method in the MainDemo.Module\MainDemoModule.xx file (see the T241873 ticket for more details).
4. The Department, Employee and EmployeeTask classes are implemented in the MainDemo.Module/BusinessObjects folder. To quickly understand relationships between involved business classes, their class diagram is attached.
1. See also the functional tests in the MainDemo.EasyTests folder for more details on the tested scenarios.
2. For versions older than v15.2.5, be aware of the issue described in the Security - The "Entering state 'GetObjectsNonReenterant'" error may occur while saving data if a permission criteria involves a collection property thread.
3. The State of the New Security System