Version 1 of the AuthP library allowed you to create multi-tenant / SaaS applications and introduced the feature of a Tenant Admin who could manage users within a tenant. That reduces the work on the support people for your application.
In version 1 of AuthP library the Tenant Admin was limited to managing users in the Tenant Admin, BUT the Tenant Admin had access to every AuthP's Role (referred to a Role in this issue). This means the Tenant Admin could add roles to tenant users which gave total control over all its features, which is not a good idea.
In version 2 of the AuthP I will restrict the what a Tenant Admin can do, plus add a new feature so that you create different versions of your SaaS application (e.g. Free, Pro, Enterprise).
A Tenant admin cannot create / update / delete an Role
In version 1 of AuthP library I allowed a Tenant Admin to create / update / delete an Role, but they couldn't include advanced Permissions, which filters out advanced Permissions from a list of Permissions a Tenant Admin user. This stopped a Tenant Admin from creating a Role with an advanced Permissions.
But a problem existed in version 1 is if a Tenant Admin can create new Roles, then in Company1 could create a role that a Tenant Admin in Company2 would see. This is likely to cause confusion, especially if you have lots of tenants.
Therefore in AuthP version 2 a Tenant Admin should be barred from creating, updating or deleting a Role - only a App Admin (i.e. a user manages the whole application, not linked to tenant) can do that. The Tenant Admin's job is to manage tenant users and their Roles.
Restrict the more powerful Role from the Tenant Admin
In version 2 a Role will now have a new RoleType enum property with the following settings:
Normal, which means the Role can be used by any user. The Tenant Admin can only see Normal role.
HiddenFromTenant, which means the Role is not available to a user linked to a Tenant.
In AuthP version 2 a Role that contains a advanced Permission will, by default, have the RoleType property to HiddenFromTenant. A Role can also be set to HiddenFromTenant manually by the App Admin user.
Provide different versions of your application (e.g. Free, Pro, Enterprise).
Many SaaS applications have different versions, which allows you to get a range of income from different levels of users. In AuthP version 2 I introduce the concept of a Tenant Role.
Each Tenant will have a one-to-many link to the TenantRoles allocated to the Tenant. TenantRoles are created and added to a Tenant by the App Admin user, or it could be automated. The Tenant's TenantRoles be used in two ways:
For applications that provide the same features to all the users, e.g. Visual Studio with its Community, Pro, Enterprise versions, the Tenant's list of TenantRoles are automatically added to the Roles that a user has. In this case the Role's RoleType property is set to TenantAutoAdd.
For applications that has different types of users, e.g. Staff, Manager, CEO, then the Tenant's TenantRoles are manually added by a tenant admin user, e.g. an advanced paid-for TenantRole is only added to Managers. In this case the Role's RoleType property is set to TenantAdminAdd.
Version 1 of the AuthP library allowed you to create multi-tenant / SaaS applications and introduced the feature of a Tenant Admin who could manage users within a tenant. That reduces the work on the support people for your application.
In version 1 of AuthP library the Tenant Admin was limited to managing users in the Tenant Admin, BUT the Tenant Admin had access to every AuthP's Role (referred to a Role in this issue). This means the Tenant Admin could add roles to tenant users which gave total control over all its features, which is not a good idea.
In version 2 of the AuthP I will restrict the what a Tenant Admin can do, plus add a new feature so that you create different versions of your SaaS application (e.g. Free, Pro, Enterprise).
A Tenant admin cannot create / update / delete an Role
In version 1 of AuthP library I allowed a Tenant Admin to create / update / delete an Role, but they couldn't include advanced Permissions, which filters out advanced Permissions from a list of Permissions a Tenant Admin user. This stopped a Tenant Admin from creating a Role with an advanced Permissions.
But a problem existed in version 1 is if a Tenant Admin can create new Roles, then in Company1 could create a role that a Tenant Admin in Company2 would see. This is likely to cause confusion, especially if you have lots of tenants.
Therefore in AuthP version 2 a Tenant Admin should be barred from creating, updating or deleting a Role - only a App Admin (i.e. a user manages the whole application, not linked to tenant) can do that. The Tenant Admin's job is to manage tenant users and their Roles.
Restrict the more powerful Role from the Tenant Admin
In version 2 a Role will now have a new
RoleType
enum property with the following settings:Normal
, which means the Role can be used by any user. The Tenant Admin can only seeNormal
role.HiddenFromTenant
, which means the Role is not available to a user linked to a Tenant.In AuthP version 2 a Role that contains a advanced Permission will, by default, have the
RoleType
property toHiddenFromTenant
. A Role can also be set toHiddenFromTenant
manually by the App Admin user.Provide different versions of your application (e.g. Free, Pro, Enterprise).
Many SaaS applications have different versions, which allows you to get a range of income from different levels of users. In AuthP version 2 I introduce the concept of a Tenant Role.
Each Tenant will have a one-to-many link to the TenantRoles allocated to the Tenant. TenantRoles are created and added to a Tenant by the App Admin user, or it could be automated. The Tenant's TenantRoles be used in two ways:
RoleType
property is set toTenantAutoAdd
.RoleType
property is set toTenantAdminAdd
.