Roles Based Access Control (RBAC)

Every organization and team would typically have a very well defined role for each of its employees. Some people in the team may play multiple roles. For example, a typical company may have roles such as administrators, managers, executives, marketers, sales, engineers, and support.

Modern companies assemble and dismantle small short-lived agile teams to work on specific projects to meet customer/market's needs quickly. Resources such as servers, databases are assigned to those short-lived teams when created and recovered from them when the teams are dismantled.

An employee may be part of multiple teams and projects and may have to play a different role in each team or project. An engineer, for example, may play the following different roles in different projects:

• developer
• tester
• admin
• project lead
• customer support

Organizations typically use an Identity Provider(IdP) such as Okta, Keycloak, Google Workspace, Microsoft Entra (or Azure Active Directory), or AWS IAM to manage user and their group (or team) membership information. Modern IdPs act as a "single point of truth" for all information about organizational resources including, employees and their group membership information.

Roles and Logins

BastionXP supports Role Based Access Control(RBAC). The Roles and Logins feature in BastionXP PKI/CA can be used to define roles corresponding to the IdP group in your organization. It is simple, yet very flexible in defining user roles and logins.

Using the Roles feature, you can define new roles. For each role, you can define the logins needed to access servers or compute resources that belong to your team.

For example: People with their role defined as db-admins would usually login to a server using the login name admin or root or ec2-admin or gcp-admin or simply using their email ID. So all db-admins role players would have their logins defined as: [admin, root, ec2-admin, gcp-admin]

In the BastionXP web portal's Roles section, you can add a new role (Eg: db-admins) and the corresponding server login names for the role (Eg: admin, root, ec2-admin, gcp-admin) as logins and save the role. A new role will be defined now.

You need to add login names one by one to the role being defined.

Establish Group to Role Mappings

Each role should be mapped to a specific SCIM provisioned IdP user group. So that, all users who belong to that group will get the role assigned.

Note:

We recommend creating a unique role for each and every unique IdP user group. We also recommend creating the role name to be the same name as the IdP group's displayName. This will create a one-to-one mapping between IdP group and the role. This will help simplify group-role-logins management and control.

You can apply the role to an IdP user group that performs that role in your team or organization. For example, IdP user group db-admins needs to be assigned the role db-admins. So you need to go to the "Groups" tab from the web portal, simply select and edit the SCIM provisioned group db-admins, use the dropdown box to select and add the role db-admins to it and save it.

You can apply more than one role to a user group, if required.

Now, going back to our example, when user James, who is part of the SCIM IdP user group db-admins, executes the bsh login --proxy bastionxp.example.com command to generate short-lived SSH client certificates, the BastionXP gateway would retrieve his group membership from SCIM IdP DB, finds the corresponding group-to-roles mappings, finds the corresponding logins or login names for each role and uses the logins to create a new SSH client certificate. For example, an SSH client certificate generated for James will have the following principals: [james, admin, root, ec2-admin, gcp-admin] in it.

The generated SSH client certificate can be used to login to any server or VM in your organization that trusts BastionXP PKI/CA and has a login user named james, admin, root, ec2-admin or gcp-admin. James cannot login to the server as any other login user using the SSH client certificate.

$ ssh-keygen -L -f ssh_user-cert.pub 
ssh_user-cert.pub:
        Type: [email protected] user certificate
        Public key: RSA-CERT SHA256:7RwjelOCPQ9wuWzC8Qdus1F6lU0oLB6adE2xlJE7/D4
        Signing CA: RSA SHA256:qTBhxUpEk0ldS0uTJJJYNOKygEsfLM1d+u1wcVjCBqI (using rsa-sha2-512)
        Key ID: "[email protected]"
        Serial: 0
        Valid: from 2023-03-08T17:26:07 to 2023-03-09T01:26:07
        Principals:
                james
                admin
                root
                ec2-admin
                gcp-admin
        Critical Options: (none)
        Extensions: 
                permit-X11-forwarding
                permit-agent-forwarding
                permit-port-forwarding
                permit-pty
                permit-user-rc