Kaa IAM User Management is an identity and access management system built on top of IAM Core.
The main goal of this tool is to provide a straightforward interface specifically designed for managing Kaa platform users and entities.
In this tutorial, we’ll introduce the basic terms and concepts used in Kaa IAM User Management, such as users, policies, groups, resources, and resource groups.
Understanding these concepts is essential before building access infrastructure.
A User in Kaa IAM is an individual who can access the platform and interact with its resources.
Users can have different permissions based on their assigned policies, which control their access levels.
First, log in to your Kaa platform and navigate to “User Management” -> “Users”.
Here, you should see a single user, which is your admin user.
For testing purposes, you’ll need to create a new user. To do so, click on Add user.
Pick a username for the new account.
The email doesn’t need to be real unless you want to walk through account activation.
The First Name and Last Name fields are optional.
The Active checkbox determines whether the account is active, leave it checked.
The User Directory field is used for advanced management of policies, which we’ll cover in the next tutorial.
For now, we’ll leave it empty.
After creating the account, try logging in with the new user credentials.
After logging into your newly created account, you’ll notice it doesn’t have access to anything.
That’s because it hasn’t been granted any actions from the admin account that created it.
An action is a specific permission that defines what a user is allowed (or denied) to do. Policies are sets of one or more actions that grant or deny access to specific entities and services within the Kaa platform.
To assign a policy to your user, log back into your admin account.
Navigate to “User Management” -> “Users”, select your user from the list, then open the Policies tab and attach a new policy.
In the policy assignment screen, you’ll be offered a list of default policies.
For now, attach the application-reader
policy to your user and log back in to see what’s changed.
This policy grants read access to all applications and their related resources that are owned by the admin account.
However, you’ll notice that the user still can’t view anything in the UI. Why?
Because read access to a resource allows access via the API, but viewing it in the UI requires additional permissions.
Let’s create a UI access policy for the user account.
To grant UI access to your user, navigate to “Policies” -> “Add New Policy”.
Provide a name for it (for example user-ui
).
In the Actions editor, choose the type of action.
Select Manual
to manually pick specific actions through the UI.
From the list of available actions that appears, check all items under UI-systems
.
Save the policy, then go back to the Users section, select your user, and attach the newly created policy.
Log in again with your user account.
You should now see the full Kaa UI, including all applications and endpoints, but without the ability to edit them.
If that’s the case, it confirms that the policies have been successfully applied.
Groups in Kaa IAM User Management are a tool that helps manage access when working with multiple users and policies.
A group allows you to assign policies once and automatically apply them to all users added to that group.
Any user assigned to a group will inherit its policies.
To create a group, navigate to “User Management” -> “Groups”, and click on “Create New Group”.
Pick a name for the group, then scroll down and assign a few policies (such as the UI policy we created earlier).
Next, add one or more users to the group.
And add a few policies.
After assigning a user to the group, you can verify the result by going to “User Management” -> “Users” -> [your-user] -> “Policies”.
You’ll see that policies from the group (e.g., Applications Read Only Group
) are now listed under the user’s policies.
In Kaa IAM User Management, a resource refers to nearly any entity within the platform. There are two main types of resources in the Kaa platform:
The key difference between these two types lies in how access to them is granted:
By default, a resource is owned by the user who created it, but it can be shared with other users depending on the policies and actions assigned.
Each resource in Kaa has its own unique identifier called an IRN (Internal Resource Name).
IRNs are used to reference specific resources when writing advanced policies, especially when you need to target individual resources or define precise access rules.
You can view the IRNs of Kaa Platform resources by navigating to “User Management” -> “Resources”.
Use the dropdown menu in the top-right corner to navigate between the types of resources.
IRNs for IAM Core resources are available in the User Management:
Resource Groups (also referred to as pools) allow you to group multiple resources together, making it easy to create reusable collections that can be referenced across different policies.
To create a Resource Group, navigate to “User Management” -> “Resource Group”, and click on “Create Resource Group”.
Give your group a name and add the relevant resources.
In this example, we’ll include only the [Test] Sensors
application and its endpoints.
Next, we need to create a policy that grants access to all resources in the group.
Navigate to “User Management” -> “Policies”, and click on Add policy.
For Actions, you can choose All actions
to grant full access to the selected resources.
For Resources, tick Manual
, scroll down and pick the Resource Group that you just created.
After creating the policy, go to your test user and attach it.
Also, don’t forget to attach the user-ui
policy we created earlier to grant UI access.
Log in again with your user account.
You should now see the resources specified in the Resource Group with full access to them.
Additionally, you can stack Resource Groups by assigning one group as a child of another.
The child group will inherit all resources from its parent, allowing you to create hierarchical access structures.
This is especially useful when designing permission levels that range from broad admin access to more restricted roles, such as basic users, with each level progressively narrowing access.