Mobiz Security

Mobiz Security System explained.

Understanding Mobiz Security

MobizSecurity implements a traditional approach to software service security implementation in the way we implement the standard concepts:

  • Permissions
  • Roles
  • Groups

Mobiz Security differs however from more traditional (simpler) security implementations by supporting scoping.

Scoping is a way to assign security to users against a given Organization membership.

Essentially resulting in the capabilities to support scenarios like these:

  • System has built-in groups for Organization members: Owner, Admin, User.
  • User A is an Owner of own Organization (PersonalAccount).
  • User A is also an employee for Organization X and in the Group “User” when workin in the context of this Organization X.
  • User A also an owner of a small business Y and therefore in the Group “Owner” as an owner he also inherits roles: Admin and User. Again, when working in the scope of the given Organization Y.

In addition Mobiz Security system provides support for Organization administrators to add their own Groups (if the Mobiz powered SaaS developers choose to support it).

The Plumbings

Let’s look at things from data structure level. The following plumbing makes this possible.

Permissions

A very basic authorization item.

Permissions are registerd in code and are simple string keys.

Permissions are not stored in the database per-se. The are simply a string identifying a given security authorization.

Example: “ReadStuff”, “ManageEmail”

New Permissions are registered by an extension during initialization using IMobizExtensionHost.RegisterBuiltInModuleSecurity

Mobiz comes built in with three permissions: “Owner”, “Admin” and “User”.

This is the simples permission model we need to roll out basic Mobiz features. More permissions are then registered by extensions - representing corresponding business requirements.

Remember in a simpler security systems, like Django and similar you might be able to assign Permission directly to a User but in Mobiz we don’t support that - and for a reason. We want to have the power to manage complex setup of Users with access to multiple Organizations.

Now, let’s look at how permissions are assigned to a User against a given Organization.

Roles and Groups

Roles are a collection of Permissions.

Roles are stored in the database table “Role”.

Groups are a collection of Roles.

Groups are stored in the database table “Group”.

Users are added to Groups via Membership.

Assignment “User 2 Group for a given Org” is stored in database table “OrganizationGroupMembership”

BaseLine DataSet

Mobiz migrator installs a base-line dataset for bootstrapping an install.

The baseline data-set provides the following simplified structure:

  • Group “Owner”
    • Scope: “Built-in”
    • Role: “Owner”
      • Permission “Owner”
    • Role “Admin”
      • Permission “Admin”
    • Role “User”
      • Permission “User”
  • Group “Admin”
    • Scope: “Built-in”
    • Role “Admin”
      • Permission “Admin”
    • Role “User”
      • Permission “User”
  • Group “User”
    • Scope: “Built-in”
    • Role “User”
      • Permission “User”

Using the above data set you can manage the simple requirements that a User can be Owner, Admin or User for different Organizations. Also you can see that Owner also has Admin and User permission, Admin is User, etc.

Of course this is a simplified model.

Real world example

Let’s consider a bit more real world example.

Let’s say you are implementing a corporate banking service your might have permission structure like this.

  • Roles
    • Owner
      • Permissions: ManageOrganizationConfiguration, ManageBilling, Owner
    • Admin
      • Permissions: ManageUsers, ManageAccounts
    • Supervisor
      • PrintAccounts
    • Staff
      • ViewAccounts
  • Groups
    • Owner
      • Roles: Owner, Admin, Supervisor, Staff
    • Admin:
      • Roles: Admin, Supervisor, Staff
    • Supervisor
      • Roles: Supervisor, Staff
    • Staff
      • Roles: Staff

There is one trick here.

Mobiz supports assigning User to multiple Groups.

This might lead to confusion but we support multiple groups to make the system flexible.

Our best practice reccomendation is to limit this in the UI: One Group Per User Membership!

In most SaaS implementations it should be sufficient to limit this in the UI and allow only selecting a single Group per membership. This should be powerful enough. Then developers can maintain freedom to manage more groups behind the scenes if needs requires.

Understanding scope

It is important to fully understand the scope-mechanism of security data like Roles and Groups.

Built-in scope

Built-in refers to security structures which are provided as root level, built-in configuration defaults.

Built-in roles and groups cannot be changed. They can only be utilised as-is.

Built-in Roles and Groups are available for all Organizations across the whole system. (Global)

AdminDomain scope

A brief recap on AdminDomains and their purposes:

  • AdminDomain is a construct for managing enterprise customers or divisions inside the hosting infrastructure where customers might have different service levels or configurations.
  • For enterprise customers we might want to utilise the override mechanism of the settings system to enable custom email templates and other configurations for the given customer.
  • For enterprise customers you might also want to provide richer structure of roles and groups.
  • Last but not least an AdminDomain is a mechanism to create a kind of islolated service container around a groups of Organizations. This is very usefull for enterprise customers which operate multiple business units.

Roles and Groups defined on an AdminDomain level (Scope = AdminDomain) only become available to Organizations belonging to the given AdminDomain.

Organization scope

Mobiz supports for Organization to have own Groups and Roles. This can be very powerful when the service grows over time. It might be a good idea to not expose this feature to customers until it is absolutely required.

Such Roles and Groups have scope = Organization.

Managing Security

You can manage all aspects of security visually using the MobizAdministrator.

The following APIs are your friends for managing this from code:

REST 

// Return all available permissions
api/v1/security/permission
  
///
/// Roles
///

// Return all built-in roles (Global roles available for everyone)
api/v1/security/role
// Return all roles available for a given AdminDomain (built-in + AD roles)
api/v1/admin-domain/{adminDomainId:guid}/security/role
// Return all roles available for a given Organization (built-in + AD + custom Organization roles)
api/v1/organization/{organizationId:guid}/security/role

// GET/POST/PUT/DELETE a given built-in role by id
api/v1/security/role/{roleId:guid}
// GET/POST/PUT/DELETE a given AdminDomain scoped role by id
api/v1/admin-domain/{adminDomainId:guid}/security/role/{roleId:guid}
// GET/POST/PUT/DELETE a given Organization scoped role by id
api/v1/organization/{organizationId:guid}/security/role/{roleId:guid}

///
/// Groups
///

// Return all built-in groups (Global groups available for everyone)
api/v1/security/group
// Return all groups available for a given AdminDomain (built-in + AD groups)
api/v1/admin-domain/{adminDomainId:guid}/security/group
// Return all groups available for a given Organization (built-in + AD + custom Organization groups)
api/v1/organization/{organizationId:guid}/security/group

// GET/POST/PUT/DELETE a given built-in group by id
api/v1/security/group/{groupId:guid}
// GET/POST/PUT/DELETE a given AdminDomain scoped group by id
api/v1/admin-domain/{adminDomainId:guid}/security/group/{groupId:guid}
// GET/POST/PUT/DELETE a given Organization scoped group by id
api/v1/organization/{organizationId:guid}/security/group/{groupId:guid}

///
/// Group 2 Membership
///

// Return all Membership associated with a given group
api/v1/security/group/{groupId:guid}/membership
  
// PUT Update membership groups assignment
api/v1/membership/{membershipId:guid}/group

C# Mobiz API 

IMobizRepository.Security property exposes:  IMobizSecurityRepository exposing all above mentioned features.

Mobiz Security Attributes are the final piece of the puzzle.

Added to WebAPI endpoints the provide the validation required for ensuring proper authorization for operations and access.

/// Assumption: Route contains argument {organizationId:guid}
///  Results: Only permits access to endpoint if request User is authorized and is a member ///  of the given Organization.  No permission, roles nor groups requested. 
[OrganizationAuthorize]

/// Assumption: Route contains argument {organizationId:guid}
///  Results: Only permits access to endpoint if request User is authorized and is a member ///  of the given Organization and has assignment for permission "Owner".
[OrganizationAuthorize(OrganizationPermissionsAllowed = new []{"Owner"})]
← User Invites
Elastic Index →