Advanced Server Access uses groupsGroups allow you to organize your end users and the apps they can access. Assigning apps to large sets of end users is made easier with groups. to make it easy to grant permissions to collections of related usersIn Okta literature, we generally refer to "users" as the people who serve as Okta administrators. When we refer to "end users" we are generally referring to the people who the administrators serve. That is, those who use Okta chiclets to access their apps, but have no administrative control.. Every Advanced Server Access team comes with two pre-configured groups:
everyone: contains every user on your Advanced Server Access team.
owners: initially contains the user who created the Advanced Server Access Team, but any team administrator can add or remove users.
Team administrators (users who have the
access_adminAn abbreviation of administrator. This is the individual(s) who have access to the Okta Administrator Dashboard. They control the provisioning and deprovisioning of end users, the assigning of apps, the resetting of passwords, and the overall end user experience. Only administrators have the Administration button on the upper right side of the My Applications page. role granted by at least
one group) can create additional groups granting any combination of roles.
The permissions of a Advanced Server Access user are determined by their memberships in groups. There are two types of permissions:
- Team-wide roles
- Project memberships
Each group can have team-wide roles affiliated with it.
There are currently two roles supported by Advanced Server Access:
- Access user (
access_user) - users with this role may use Advanced Server Access to access servers.
- Access Admin (
access_admin) - users with this role ("team administrators") have full administrative permissions within their team.
In order to access a resource in a project, a Advanced Server Access user must be a member of a group that has been linked to that project.
A group's relationship to a project has two configurations:
server_access: members of this group may access servers in this project.
server_admin: members of this group will receive administrative (e.g. sudo) permissions on servers in this project.
Because these are parameters of the group's membership in a project, and not
properties of the group itself, it is possible for a single group to grant
different levels of access to different projects (for example, your "Intern"
group might have
sudo permissions on servers in the "Intern" Project, but only
login permissions on servers in the "Production" Project).
Group permissions are additive within a project. Users who are a member of a project via more than one group will receive permissions equivalent to those implied by their most permissive membership.
For example, if a user is a member of groups
B, and group
server_access on project
P, but group
B grants both
server_admin on project
P, the user will receive both
In order for a user to SSH to a server using Advanced Server Access:
- The user must be a member of a group.
- That group must be linked to the project which contains the server, and
the group must at least have the
server_accessrole set for that project.
The simplest way to get up and running with access to your server is to:
- Browse to your project in the Advanced Server Access Dashboard.
- Click "Link Group" from the "Permissions" tab.
everyoneas the name of the group. This will grant access to every user on your Advanced Server Access team (effectively disabling "default deny").
- Check the
Accesscheckbox in order to grant the users access to the servers in your project (the
- Optionally check the
Adminbox in order to grant the users administrative (i.e. sudo) permissions on servers in your project (the
- Click "Submit" to link the
everyonegroup to your project.