Controlling Access Functionality
With LeZa you can easily customise and configure hierarchical access control functionality to fit your application structure and API workflow needs.
Last updated
With LeZa you can easily customise and configure hierarchical access control functionality to fit your application structure and API workflow needs.
Last updated
Services are protected resources and capable of accepting and responding to protected resource requests. Ultimately, your endpoints become your protected resources, essentially turning your client application into the resource server.
"A resource server is a server hosting the protected resources and capable of accepting and responding to protected resource requests." - OAuth2 specification.
LeZa enables you to configure granular authorization for protecting resources, where resource scopes can be defined and authorization decisions can be made based on different verbs (GET, POST, PUT, DELETE).
A service can be a web page, a RESTful resource, a file in your file system. Services represent a group of resources or they can represent a single and specific resource.
LeZa allows you to create custom policies and permissions based on the granular authorizations protecting your resources and these policies can be organized into permissions (granting evaluated access to protected resources) for all the application services that are registered.
Once you have defined your protected resources you can configure the below:
Policies define the conditions that must be satisfied to access or perform operations on your services (resource or scope), but they are not bound to what they are protecting. They are generic and can be reused to build permission combinations or even more complex policies
Policies are ultimately, a convenient grouping of permissions that allows access to a group of protected services that can be easily issued and managed in a centralised manner.
LeZa allows you to create custom permissions to define all the granted access points of your application. Permissions are bound to the service they protecting. With LeZa you specify what protected service access you will allow by assigning the policies that must be satisfied in order to grant or deny permission.
Visualize:
Joe can View his Balance
Joe: represents one or more users, groups or roles.
View: represents the actions that can be taken.
Balance: represents that service that is being protected "/balance"
Roles are useful when you need more constrained or hierarchically structured access grants to protected resources (RBAC - Role-Based Access Control). Configuring roles allows you to assign users or a group of users to receive a specific set of permissions and policies that must be satisfied to access or perform operations on your services (resource or scope).
Using the LeZa cloud platform you can easily invite and manage users, assign roles and permissions. This gives you the full flexibility you require to control how users and clients access your services.
We allow each organization (see below: Organizations) the functionality to invite and manage users, assign roles and permissions independently.
This is a convenient feature whereby users can be grouped into user groups, which allows you to centrally issue those users a set of permission and/or policies in a group fashion instead of individually repeating tasks for each user.
LeZa provides you with some valuable organisational centric functionality that separates your customers (user accounts) into organizations (Primary Account Space). Each organisation can be customized and self-managed by the Organization Admin (any users with admin rights in the organisation). Organizations contained their own context/settings which allow for custom configurations to be self-administered by their admin users. (also see)
This out of the box feature gives you the full flexibility of IAM should your project require it.
Example 1: Let's say you've built a great web service that your customers subscribe to and you are looking to test your latest beta-service with select customers only. Those Organisations that you have invited to your new service can subscribe without having to resign up their users to this new service (self-managed subscriptions).
Example 2: You have two customer accounts both using your Web Application but each customer has different IT policies. One requires that password refresh tokens are expired within 1hr (this client also requires it's user to use 2-factor authentication) and the other perferrs 24hrs (with no 2FA). No Problem! The each customer can manage this in the Organisation settings.
Organizations can be further divided into organization units (sub-account spaces). This follows a logic tree format allowing you to organize your resources in a hierarchical logical structure.
"A great benefit of organisation units is they have their own assigned identifier which allows you to filter response results without having to cater for this in your code".
Custom themes, colours and logos can be set independently for every Organization. Giving your users a personalized experience whilst all using the same service
