Managing Roles, Accounts, Users and Domains¶

Roles, Accounts, Users, and Domains¶

Using Dynamic Roles¶

In addition to the four default roles, the dynamic role-based API checker feature allows CloudStack root admins to create new roles with customized permissions. The allow/deny rules can be configured dynamically during runtime without restarting the management server(s).

For backward compatiblity, all roles resolve to one of the four role types: admin, resource admin, domain admin and user. A new role can be created using the roles tab in the UI and specifying a name, a role type and optionally a description.

Role specific rules can be configured through the rules tab on role specific details page. A rule is either an API name or a wildcard string that are one of allow or deny permission and optionally a description.

When a user makes an API request, the backend checks the requested API against configured rules (in the order the rules were configured) for the caller user-account’s role. It will iterate through the rules and would allow the API request if the API matches an allow rule, else if it matches a deny rule it would deny the request. Next, if the request API fails to match any of the configured rules it would allow if the requested API’s default authorized annotaions allow that user role type and finally deny the user API request if it fails to be explicitly allowed/denied by the role permission rules or the default API authorize annotations. Note: to avoid root admin being locked out of the system, all root admin accounts are allowed all APIs.

The dynamic-roles feature is enabled by default only for all new CloudStack installations since version 4.9.x.

In 4.11.x and above, existing deployment without any commands.properties file will be automatically migrated to dynamic roles. Admins may also enable dynamic roles by setting the global setting ‘dynamic.apichecker.enabled’ to true.

After an upgrade, admins can also use this migration tool to migrate old rules from commands.properties file(s): /usr/share/cloudstack-common/scripts/util/migrate-dynamicroles.py.

During migration, this tool enables the global setting in the database and copies existing static role-based rules from provided commands.properties file (typically at /etc/cloudstack/management/commands.properties) to the database and renames the commands.properties file (typically to /etc/cloudstack/management/commands.properties.deprecated). The migration process does not require restarting the management server(s).

Usage: migrate-dynamicroles.py [options] [-h for help]

Options:

Examples:

sudo python /usr/share/cloudstack-common/scripts/util/migrate-dynamicroles.py -u cloud -p cloud -H localhost -P 3006 -f /etc/cloudstack/management/commands.properties

sudo python /usr/share/cloudstack-common/scripts/util/migrate-dynamicroles.py -u cloud -p cloud -H localhost -P 3006 -D

If you’ve multiple management servers, remove or rename the commands.properties file on the management servers typically in /etc/cloudstack/management path, after running the migration tool for the first management server.

给帐户和域分配专用资源¶

根管理员可以将资源分配给指定的域或为了保证额外的安全或性能从而需要单独基础架构帐户。为了一个指定的域或账号，区域、机架、群集或者主机可以被根管理员保留。只有域或它的子域中的用户可以使用这个基础架构。比如，只有域中的用户可以在其中的区域中创建来宾虚机。

这里有几种有效的分配方式：

• 明确的专用。根管理员在初始部署和配置期间给一个帐户或者域分配了一个区域、机架、群集或者主机。
• 严格的潜在专用：一个主机禁止通过多个账号共享。例如，严格私自共享对于部署的某些应用是有用处的，像没有软件授权主机不能在不同账号间进行桌面共享。
• 优先的潜在专用。如果可以的话，VM会被部署在专用的基础架构中。否则，VM可被部署在共享基础架构中。

如何给帐户或者域指定一个区域、群集、机架或者主机¶

对于明确的专用：当部署一个新的区域、机架、群集或者主机的时候，根管理员可以点击Dedicated选框，然后选择域或者帐户来拥有这些资源。

对于明确的专用一个已存在的区域、机架、群集或者主机：使用根管理员登录，在UI中找到资源，然后点击Dedicate按钮。

对于隐式的专用：管理员创建的计算服务方案和在部署规划区域选择ImplicitDedicationPlanner。然后在规划模型中，管理员按照是否允许一些人当没有专用资源可用的时候使用共享资源来选择严格的或者优先的。无论何时，用户基于这个服务方案创建的VM都会位于专用主机。

使用LDAP服务器用于用户验证¶

You can use an external LDAP server such as Microsoft Active Directory or ApacheDS to authenticate CloudStack end-users. CloudStack will search the external LDAP directory tree starting at a specified base directory and gets user info such as first name, last name, email and username.

To authenticate, username and password entered by the user are used. Cloudstack does a search for a user with the given username. If it exists, it does a bind request with DN and password.

To set up LDAP authentication in CloudStack, call the CloudStack API command addLdapConfiguration and provide Hostname or IP address and listening port of the LDAP server. You could configure multiple servers as well. These are expected to be replicas. If one fails, the next one is used.

The following global configurations should also be configured (the default values are for openldap)

• ldap.basedn: Sets the basedn for LDAP. Ex: OU=APAC,DC=company,DC=com
• ldap.bind.principal, ldap.bind.password: DN and password for a user who can list all the users in the above basedn. Ex: CN=Administrator, OU=APAC, DC=company, DC=com
• ldap.user.object: object type of users within LDAP. Defaults value is user for AD and inetorgperson for openldap.
• ldap.email.attribute: email attribute within ldap for a user. Default value for AD and openldap is mail.
• ldap.firstname.attribute: firstname attribute within ldap for a user. Default value for AD and openldap is givenname.
• ldap.lastname.attribute: lastname attribute within ldap for a user. Default value for AD and openldap is sn.
• ldap.username.attribute: username attribute for a user within LDAP. Default value is SAMAccountName for AD and uid for openldap.

LDAP groups:¶

• ldap.group.object: object type of groups within LDAP. Default value is group for AD and groupOfUniqueNames for openldap.
• ldap.group.user.uniquemember: attribute for uniquemembers within a group. Default value is member for AD and uniquemember for openldap.

Once configured, on Add Account page, you will see an “Add LDAP Account” button which opens a dialog and the selected users can be imported.

You could also use api commands: listLdapUsers, ldapCreateAccount and importLdapUsers.

Once LDAP is enabled, the users will not be allowed to changed password directly in cloudstack.

Using a SAML 2.0 Identity Provider for User Authentication¶

You can use a SAML 2.0 Identity Provider with CloudStack for user authentication. This will require enabling the SAML 2.0 service provider plugin in CloudStack. To do that first, enable the SAML plugin by setting saml2.enabled to true and restart management server.

Starting 4.5.2, the SAML plugin uses an authorization workflow where users should be authorized by an admin using authorizeSamlSso API before those users can use Single Sign On against a specific IDP. This can be done by ticking the enable SAML Single Sign On checkbox and selecting a IDP when adding or importing users. For existing users, admin can go to the user’s page and click on configure SAML SSO option to enable/disable SSO for a user and select a Identity Provider. A user can be authorized to authenticate against only one IDP.

The CloudStack service provider metadata is accessible using the getSPMetadata API command, or from the URL http://acs-server:8080/client/api?command=getSPMetadata where acs-server is the domain name or IP address of the management server. The IDP administrator can get the SP metadata from CloudStack and add it to their IDP server.

To start a SAML 2.0 Single Sign-On authentication, on the login page users need to select the Identity Provider or Institution/Department they can authenticate with and click on Login button. This action call the samlsso API command which will redirect the user to the Identity Provider’s login page. Upon successful authentication, the IdP will redirect the user to CloudStack. In case a user has multiple user accounts with the same username (across domains) for the same authorized IDP, that user would need to specify domainpath after selecting their IDP server from the dropdown list. By default, users don’t need to specify any domain path. After a user is successfully authenticated by an IDP server, the SAML authentication plugin finds user accounts whose username match the username attribute value returned by the SAML authentication response; it fails only when it finds that there are multiple user accounts with the same user name for the specific IDP otherwise the unique useraccount is allowed to proceed and the user is logged into their account.

Limitations:

• The plugin uses a user attribute returned by the IDP server in the SAML response to find and map the authorized user in CloudStack. The default attribute is uid.
• The SAML authentication plugin supports HTTP-Redirect and HTTP-Post bindings.
• Tested with Shibboleth 2.4, SSOCircle, Microsoft ADFS, OneLogin, Feide OpenIDP, PingIdentity.

The following global configuration should be configured:

• saml2.enabled: Indicates whether SAML SSO plugin is enabled or not true. Default is false
• saml2.sp.id: SAML2 Service Provider Identifier string
• saml2.idp.metadata.url: SAML2 Identity Provider Metadata XML Url or Filename. If a URL is not provided, it will look for a file in the config directory /etc/cloudstack/management
• saml2.default.idpid: The default IdP entity ID to use only in case of multiple IdPs
• saml2.sigalg: The algorithm to use to when signing a SAML request. Default is SHA1, allowed algorithms: SHA1, SHA256, SHA384, SHA512.
• saml2.redirect.url: The CloudStack UI url the SSO should redirected to when successful. Default is http://localhost:8080/client
• saml2.sp.org.name: SAML2 Service Provider Organization Name
• saml2.sp.org.url: SAML2 Service Provider Organization URL
• saml2.sp.contact.email: SAML2 Service Provider Contact Email Address
• saml2.sp.contact.person: SAML2 Service Provider Contact Person Name
• saml2.sp.slo.url: SAML2 CloudStack Service Provider Single Log Out URL
• saml2.sp.sso.url: SAML2 CloudStack Service Provider Single Sign On URL
• saml2.user.attribute: Attribute name to be looked for in SAML response that will contain the username. Default is uid
• saml2.timeout: SAML2 IDP Metadata refresh interval in seconds, minimum value is set to 300. Default is 1800