--- title: Members, groups, service users and roles description: The identities that can act in an organization, how each one gets its permissions, and what a member can do by default. url: https://hexelstudio.com/docs/identity/principals --- A principal is anything a policy can be attached to. An organization has four kinds: | Principal | What it is | Signs in with | Gets permissions from | | --- | --- | --- | --- | | **Member** | A Hexel account that belongs to the organization | The Hexel account, in the console | Its member role, policies attached to it, its groups, permission sets | | **Group** | A set of members that share policies | Nothing: a group never signs in | Policies attached to it, permission sets assigned to it | | **Service user** | A non-human identity owned by the organization | An API key or an OAuth client | Policies attached to it, permission sets assigned to it | | **Role** | An identity that members, service users or other roles assume for a limited time | Nothing: you get a role session by assuming it | Policies attached to the role | Every principal belongs to one organization, and its permissions apply only there. To give a person access to two organizations, make them a member of both, or let them assume a [role](https://hexelstudio.com/docs/identity/roles) in the other organization. ## Members A member is a [Hexel account](https://hexelstudio.com/docs/identity/accounts) in your organization. In policy attachments and group memberships, a member is identified by their user ID (`user_id` in the members list), with the target type `USER`. Each member has one **member role**: owner, admin, member or viewer. The role decides the member's default access. You set it when you invite or add the member and can change it later. See [Members and invitations](https://hexelstudio.com/docs/identity/members). ### What a member gets by default When you create an organization, Hexel Studio creates four **membership groups**, one per member role, and attaches managed policies to each. Every member is in exactly the group of their role. Changing a member's role moves them to the other group, and removing a member from the organization removes them from it. | Member role | Membership group (name) | Group ID | | --- | --- | --- | | Owner | `hexel-org-owners` | `grp_org_owner_` | | Admin | `hexel-org-admins` | `grp_org_admin_` | | Member | `hexel-org-members` | `grp_org_member_` | | Viewer | `hexel-org-viewers` | `grp_org_viewer_` | The policies attached to these groups give each role the following access: | Area | Owner | Admin | Member | Viewer | | --- | --- | --- | --- | --- | | Everything | Yes (`*`) | | | | | Organization details and settings | All | Read and update; read and change settings | Read | Read | | Members and invitations | All | Invite, remove and change roles | None | None | | Delete or restore the organization | Yes | No | No | No | | Organization audit log | Yes | Read | Read | Read | | Billing | All | Read and manage | Read | Read | | Workspaces | All | All (`workspace:*`) | All (`workspace:*`) | Read | | Environments | All | All (`env:*`) | All (`env:*`) | Read | | Policies, groups, roles and permission sets | All | Read and write ([IAM Admin Access](https://hexelstudio.com/docs/identity/policies#managed-policies)) | List policies, groups and roles only | Read | | Test access (`iam:authz:simulate`) | Yes | Yes | No | No | | Service users, API keys and OAuth clients | All | All | Read | Read | | Atlas | All | All | Read | None | | Hexel Managed Memory | All | All | Use stores; can't create, change or delete them | Read | | Skills Registry | All | All | Read, publish, move tags | Read | | Support tickets | All | Own tickets and every ticket of the organization | Own tickets | Own tickets | The managed policies behind each role: - **Owner:** Organization Owner Full Access (`pol_org_owner_full`). - **Admin:** `pol_billing_full`, `pol_compute_full`, `pol_data_full`, `pol_deploy_full`, `pol_dir_user_mgmt`, `pol_env_full`, `pol_iam_admin`, `pol_memory_full`, `pol_monitoring`, `pol_org_member`, `pol_skills_full`, `pol_support_customer`, `pol_support_org_admin`, `pol_svc_account`, `pol_tool_full`, `pol_ws_full`. - **Member:** `pol_compute_readonly`, `pol_data_readonly`, `pol_deploy_full`, `pol_dir_readonly`, `pol_env_full`, `pol_memory_user`, `pol_monitoring`, `pol_org_readonly`, `pol_skills_publisher`, `pol_support_customer`, `pol_tool_execute`, `pol_ws_full`. - **Viewer:** `pol_billing_readonly`, `pol_deploy_readonly`, `pol_dir_readonly`, `pol_env_readonly`, `pol_iam_readonly`, `pol_memory_readonly`, `pol_monitoring`, `pol_org_readonly`, `pol_skills_readonly`, `pol_support_customer`, `pol_ws_readonly`. Read any of them with `GET /v1/policies/`. You can't add or remove members of a membership group, or rename or delete it, through the groups API: use the member role instead. You can attach more policies to a membership group to give every member of that role more access. Detaching one of its default policies does not last: Hexel Studio attaches the default policies again whenever a member joins or changes role. The person who creates an organization also has Organization Owner Full Access attached to them directly, in addition to the owners group. If you change their member role later, that direct attachment stays and they keep full access. Detach it as described in [Detach a policy](https://hexelstudio.com/docs/identity/write-policies#detach-a-policy) if you want their member role to decide their access. ### Beyond the defaults To give a member more access than their role, attach a policy to them, add them to a [group](https://hexelstudio.com/docs/identity/groups) that has the policy, or assign them a [permission set](https://hexelstudio.com/docs/identity/policies#permission-sets). Their access is the union of all of these. Nothing you attach can take access away: `Deny` statements are not applied to API calls yet (see [Policies](https://hexelstudio.com/docs/identity/policies#what-is-not-enforced-yet)). To give someone less access than a role, give them a lower role and add what they need. Adding a member to a workspace's member list does not change their permissions. Workspace access comes from policies and permission sets only. ## Groups A group is a set of members. A policy attached to a group applies to every member of the group, and a permission set assigned to a group grants to every member. Groups are the simplest way to manage access for teams. See [Manage groups](https://hexelstudio.com/docs/identity/groups). `GET /v1/groups` returns three kinds of group: | `group_type` | Groups | Can you change it? | | --- | --- | --- | | `MEMBERSHIP` | The four [membership groups](#what-a-member-gets-by-default) | You can attach policies to it. Its members, name and deletion are managed by Hexel Studio. | | `TEAM` | `default` (display name "Default Team"), created with the organization. It has no policies, so it grants nothing unless you attach one. | Yes | | `TEAM` | Groups you create | Yes | Groups don't nest: `parent_group_id` is stored but a member of a child group does not get the parent group's policies. ## Service users A service user is a non-human identity for scripts, servers and CI jobs. It belongs to your organization, is not a member, and signs in with an [API key or an OAuth client](https://hexelstudio.com/docs/identity/authenticate). Its ID starts with `su_` and its target type is `SERVICE_USER`. A new service user has no permissions. It can do only what the policies attached to it, and permission sets assigned to it, allow. Give it the smallest set of actions its job needs. See [Service users and API keys](https://hexelstudio.com/docs/identity/service-users). ## Roles and role sessions A role is an identity that others assume for a limited time. It has its own policies (attached with target type `ROLE`) and a **trust policy** that says who may assume it. Assuming a role returns a **role session**: an access token whose caller is the role, not the person or service user who assumed it. - A role session gets only the policies attached to the role. The policies of whoever assumed it don't apply during the session. - Policies attached to a role you create grant nothing outside its sessions. Being trusted by a role does not give you its permissions until you assume it. - A role can be limited to one workspace or one environment. Its sessions then have its permissions in that scope only and none at organization level. - A role can have a permission boundary. Its sessions get only the actions that are both in the role's policies and in the boundary. - A session lasts up to the role's `max_session_duration` (900 to 43,200 seconds, default 3,600). You can revoke every session of a role at once. Roles are how you give temporary or cross-organization access. See [Roles and role sessions](https://hexelstudio.com/docs/identity/roles) to create one and assume it. ## How a principal gets a permission | Grant | Applies to | Scope | How | | --- | --- | --- | --- | | Policy attached with `target_type` `USER` | That member | Organization | [Attach a policy](https://hexelstudio.com/docs/identity/write-policies#attach-a-policy) | | Policy attached with `target_type` `GROUP` | Every member of the group | Organization | [Attach a policy](https://hexelstudio.com/docs/identity/write-policies#attach-a-policy) | | Policy attached with `target_type` `SERVICE_USER` | That service user | Organization | [Attach a policy](https://hexelstudio.com/docs/identity/write-policies#attach-a-policy) | | Policy attached with `target_type` `ROLE` | Sessions of that role | The role's scope | [Attach a policy](https://hexelstudio.com/docs/identity/write-policies#attach-a-policy) | | Permission set assigned to a member, group or service user | That principal, or every member of the group | Organization, one workspace or one environment | [Assign a permission set](https://hexelstudio.com/docs/identity/write-policies#grant-access-in-one-workspace-or-environment) | | Member role | That member | Organization | [Change a member's role](https://hexelstudio.com/docs/identity/members) | [Policies and permissions](https://hexelstudio.com/docs/identity/policies) explains how these grants combine into a decision.