Hello, We have a use case in which we want users of our developed end applciation to be able to add new users and manage the access level of those users. We would not like to give those users access to IAM, because there is a possibility we want users from our customers to be able to do this. We know of the IAM API layer which you can use to:Add users to IAM Add a new user group Assign roles to a user groupWe are interested to know how far we can go with this API layer. Can we for example also create a new role in which we can grant access to very specific columns in a table? Or do those roles always have to be predefined in the SF, whereas we can only assign those predefined roles to existing or newly created user groups? Thanks in advance. If the question needs more clarification please let me know.

User Management via end application

Hello,

We have a use case in which we want users of our developed end applciation to be able to add new users and manage the access level of those users. We would not like to give those users access to IAM, because there is a possibility we want users from our customers to be able to do this.

We know of the IAM API layer which you can use to:

Add users to IAM
Add a new user group
Assign roles to a user group

We are interested to know how far we can go with this API layer. Can we for example also create a new role in which we can grant access to very specific columns in a table? Or do those roles always have to be predefined in the SF, whereas we can only assign those predefined roles to existing or newly created user groups?

Thanks in advance. If the question needs more clarification please let me know.

Page 1 / 1

Roles are always constructed in the SF. There are some customers who have build micro roles and by adding these micro roles to a group you sort of mimic the roles creation from the sf. You could automate this role creation using the dynamic model. However this will lead to an abundance of roles in the sf and IAM. You could also create a system like this within the application it self. But i'm not sure how secure that would really be, since you would still need to have access to more columns then assigned.

If someone who actually has build a system like this can provide additional information that would be greatly appreciated.

Note that IAM supports multi-tenancy. Because of this, an environment with multiple customers administrating their own user base shouldn’t be a problem.

User Administrators, User Group Owners and User Group Administrators can only see, manage and add users within their own tenant. In your scenario, a tenant would be a specific customer.

Thanks for both replies, this really helps.

I am exploring the multi-tenancy option and all the different administrator options:

I added a new tenant : “customer A” which I gave access to an app
I added a new user in this tenant and explored the following administrator privileges:
- Application admin
- Group admin
- User admin

Application admins are not interesting to us, as we have 1 application that we want to share with our customers. Group admin are interesting, as I can only see the user groups that are specifically linked to tenant “customer A”. For user admins, I see strange behavior: when adding a user from tenant “customer A” the user admin privileges specifically in tenant “customer A”, this user is able to see ALL users from all tenants. This user admin can even delete users from other tenants ..?

In the Thinkwise documentation (Tenants | Thinkwise Documentation (thinkwisesoftware.com) I found the following line:

In a multi-tenant SaaS environment, we strongly advise to add an application for each customer in IAM. If every customer has their own product database, an application for each customer is the only option.

In our situation, we only have one database which all customers will share. What are the benefits of using this approach exactly?

Hi Nick,

Multiple applications in IAM may use the same database. The upside of having multiple applications is that you can assign a tenant to a specific application and configure this application specifically for the current tenant. For instance, email providers, module authorization, public apis, PAT settings and application owners.

Regarding the strange behavior you mentioned; please ensure the latest hotfixes have been applied on your environment. If the issue persists, please log a TCP ticket.

Note that Application Administrators are indeed not limited to tenancy, but application owners are. More info here: Administrator roles | Thinkwise Documentation (thinkwisesoftware.com)

One more question: is it also possible to change the authorization data model in IAM?

For example, in IAM we have:

Application
Tenant
Module
User Group
Role
User

If we want to have a different structure, is it possible to change it?

The RBAC structure in IAM is fixed.

Can you give an example of what your structure would look like?

For example, we would like a user (with one login) to be assigned to multiple tenants.

This is currently not possible. Feel free to create an idea in the ideation section for this.

You can set up your own structures in your product or in an auxiliary application and synchronize user-, user group and role assignment information with the Intelligent Application Manager but this will take development and maintenance effort.

Reply

Sign up

Login to the Thinkwise Software Community

Scanning file for viruses.

This file cannot be downloaded