This part 2 of 10 part series which outlines my
implementation of Multi-Tenant Claim Based Identity. For more details please
see my index post.
Below are the high level requirements (functional and non-functional) for this Multi-tenant claim based authentication
Multi-Tenancy
- Application should support Multi-Tenancy based on Company
- We should also support group companies, ie., there will be a parent company which has group of child companies
Claims
- Persist basic user details in Claims to avoid hitting database
- Use Claim based access control
- There will be anonymous claims
Roles
- Application should be permissioned by roles. As claims are narrow, it will be very hard to permission by claims
- A role can have multiple claims
- Roles should be dynamically created
Admin Roles
- System should provide some admin roles to provision super users who have higher access
- Have admin roles like CompanyAdmin who will have full permissions for a company. This role will have permission to all claims for that company
- A group admin can have permissions for all companies within that group. This is like a CompanyAdmin for every company
- Have a SuperAdmin role who will have full access for all companies
- Every Module in the system will have ModuleAdmin roles. Each module admins will have full permissions for that module
User
- User should be authenticated and authorized on every request
- A User can be part multiple companies
- User can have multiple claims types
- User can be denied a claim
- User can have multiple roles
- User can have admin roles for a company and custom (non-admin) roles for another company
- Ability to add additional claims for an user on top of assigned roles
- Ability to deny certain claims for a specific user from the assigned roles. This is like an override feature
Navigation & UI
- Menu should be dynamically driven by user permissions
- Every Page can be associated with multiple claims. There will atleast one claim per page. If the page is allowed access without restriction, then it will assigned with anonymous claim
- Every action (like button click) should be permissioned through claims
- Each company will have separate menu
Support User
- Log in As. Ability to login as a different user. System should still keep track of the current user
- Have a support company (or product company) which manages the entire product
Technical
- Profile object (Logged in User details) should be available across all layers
- In Development environment, bypass authentication/authorization or use a super user account. This reduces the debug time
No comments:
Post a Comment