Get Rid of Account "Types"? and just use "Roles"?

[MI-DROZ]

After exploring LDAP integration and the way CS handles account and users I’m sort of confused as to why the system is using two designations for classifying accounts.

If you look in the account database table there are “account types” of:
system / admin = 1
Domain Admins = 2
Users = 0

Then there are multiple “Roles” that specify api access.

Some existing issues with “types” and “roles” include:

-If you try to change an account from a normal user’s role to the domain admin role in the UI and via API it fails. You can change it in the database but you must also alter the account “type” in the database.

-When you try to create a custom role you are presented with copying the permissions from either a “type” or a “role”. When you copy from a role you end up with a blank list of api permissions in the custom role, it doesn’t copy anything. Copying from a “role” works fine and gives you the api permission list from that role.

-When performing a “link domaintoldap” operation for automated account creation upon login you can only specify “accounttype” (2 or 0). This is limited and ignores any custom “roles” you might want to apply automatically.

With these issues, having multiple account classifications seems unnecessarily complex. It would seem simpler to just have account “roles” and manage permissions in one category. I might advocate for getting rid of account “types”, but I’m not sure how integrated they are in the system. They could possibly have a set of account roles reserved for the default system roles, something like (0,1,2) which can’t be altered but could be copied. The “link domaintoldap” operation could allow you to specify a role ID instead that will apply permissions upon login which would be much more useful.

[MI-DROZ]

I should update this based on the fact that the promotion of accounts from a User to a Domain Admin appears to now work in version 4.20.1.0. So this negates the first point.

The link domaintoldap function still has a bit of a flaw however as follows:
Applying method 2 (autoimport) from the documentation: https://docs.cloudstack.apache.org/en/latest/adminguide/accounts.html#using-an-ldap-server-for-user-authentication

In this scenario it seems that the accounts are auto assigned the default "User" role during first log on creation. The process of linking a domain to LDAP doesn't present the option to apply a custom role, only 0-User and 2-Domain Admin as a "type".

This creates a situation where the accounts would need to be periodically monitored for new accounts (since they aren't created until first logon) and manually altered to change their role to one of the customs/dynamic roles we would like to use. One solution would be to change the Rules on the default User role but cloudstack doesn't allow altering of the default roles.

It would seem more functional to have the link domaintoldap api allow the specification of "roleid". I might even say in place of "type" but perhaps "type" is there for backward compatibility.

[rohityadavcloud]

Good ideas and discussion. However, due to maintaining backward compatibility and supporting both static and dynamic role checkers, it's not possible to remove support for account types and therefore breaking support for static role checker (that used to use commands.properties) and several APIs that still rely on account type parameter.

The dynamic roles feature (https://cwiki.apache.org/confluence/display/CLOUDSTACK/Dynamic+Role+Based+API+Access+Checker+for+CloudStack) was introduced to provide more flexibility on the static account type based checker (and seem to be surpassed the use/support for static account-type based checker).

That said, it's not impossible to remove and deprecate the account type feature; but that would require hundreds if not thousands of hours of effort to plumb the codebase and create a gradual plan of deprecating the feature & break/rework APIs. The big question is - who's going to do it, or who's gonna support/sponsor that, and what scale of benefit would such an exercise achieve?

[MI-DROZ]

Thanks for the insight and the history.
Considering the backward compatibility, it does seem like removal of account types would be off the table.

Just thinking through this I wonder if some sort of override mechanism at the time of creation would be more feasible to allow for the mapping of dynamic roles.

Roughly something like this:

• The ldap_trust_map table would contain a role_id column.
• The “link domaintoldap” call would allow the optional specification of “roleid=” to populate the new column.
• Functions that establish mappings like “ldapTrustMapVO” might override accountType if role_id is not null.

Dynamic roles all have a “type” so when the mapping (account creation) occurs it might look something like this?

If ldap_trust_map.role_id not NULL then account.role_id = ldap_trust_map.role_id and account.type = 0 if the role_type of ldap_trust_map.role_id = “User” OR 2 if the role_type of ldap_trust_map.role_id = “Domain Admin”

I’m not a developer, just a rough attempt at pseudo code.
This preserves the account type as always being 0 or 2 for backwards compatibility when the account is created.

[GutoVeronezi]

@MI-DROZ @rohityadavcloud (cc @DaanHoogland)

This is an interesting discussion. One point that was not mentioned is that "account types" have another part in the system: they delimit the scope of access to resources. Accounts of type RootAdmin can manage the infra, resources and access for all accounts and projects; accounts of type DomainAdmin can manage resources and access to their domain and subdomains; accounts of type User can only manage their own resources and projects that their accounts belong to. If we remove this mechanism, we will not have a way to define the scope of access of the accounts.

I believe it makes sense to not define default permissions by account type and let it be managed by the role's rules alone (with perhaps an exception: IMO, some APIs related to the management of the infra should not be accessible by User and DomainAdmin types even if their roles' rules allow it); however, we still need them to define the scope of access.

Regarding the points @MI-DROZ mentioned in the description, I believe they require some adjustments and tweaks in the system rather than a rework. Adding the roleid parameter to link domaintoldap on its own should be simple, like it was pointed out in #10380 (reply in thread).