Concepts

Team

The team is the top-level organizational concept in Advanced Server Access. A team fundamentally consists of a unique name and an associated Identity Provider.

All other configuration objects in Advanced Server Access are scoped to a team.

Team documentation

Identity Provider (IdP)

Every team has an Identity Provider (such as Google, Okta, Active Directory, or LDAP) which users authenticate to using the team's authentication method (such as OAuth). The IdPAn acronym for Identity Provider. It is a service that manages end user accounts analogous to user directories such as LDAP and Active Directory, and can send SAML responses to SPs to authenticate end users. Within this scenario, the IdP is Okta. is the source of truth for that user's identity and current access. Different Identity Providers support different authentication methods (such as OAuth or SAMLAn acronym for Security Assertion Markup Language, SAML is an XML-based standard for exchanging authentication and authorization data between an identity provider (IdP) and a service provider (SP). The SAML standard addresses issues unique to the single sign-on (SSO) solution, and defines three roles: the end user, the IDP, and the SP. Here's how SAML works through Okta: SP-initiated flow: the end user requests (principally through a browser) a service from the SP. The SP requests and obtains an identity assertion from the IdP (in this case, Okta). On the basis of this assertion, the SP can decide whether or not to authorize or authenticate the service for the end user. IdP-initiated flow: with Okta as the IdP, an end user goes to the Okta browser and clicks on a chiclet, sending a SAMLResponse to the configured SP. A session is established with the SP, and the end user is authenticated.).

Authentication Method documentation

User

A user is a person who belongs to a team and authenticates with that team's identity provider. The permissions of a user in Advanced Server Access are determined by their group memberships.

Users authorize clients to be added to their clientEssentially, a client is anything that talks to the Okta service. Within the traditional client-server model, Okta is the server. The client might be an agent, an Okta mobile app, or a browser plugin. inventory so they can receive credentials.

Server User Accounts

User accounts on Linux and Windows servers can be managed by the Advanced Server Access AgentA software agent is a lightweight program that runs as a service outside of Okta. It is typically installed behind a firewall and allows Okta to tunnel communication between an on-premises service and Okta's cloud service. Okta employs several agent types: Active Directory, LDAP, RADIUS, RSA, Active Directory Password Sync, and IWA. For example, users can install multiple Active Directory agents to ensure that the integration is robust and highly available across geographic locations..

Server User Account Management documentation

Service User

A service user is an abstraction for services or software automation which can be granted specific authorizations in Advanced Server Access. Like users, service users belong to teams, and their permissions are determined by their group memberships. Service users can be used for automating actions against the Advanced Server Access API, or be granted credentials to servers.

Service User documentation

Client

The Advanced Server Access client is installed on a device (such as a laptop or workstation) which a user uses to access infrastructure. The Advanced Server Access client manages the dynamic credentials on the device so the user can transparently access Advanced Server Access-managed resources.

Client Enrollment documentation

Group

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. are used to grant permissions (such as administrative configuration rights) to users within the Advanced Server Access dashboard and API, and can be linked to projects to grant permissions within that project.

Group documentation

Project

The project is the organizational concept in Advanced Server Access which connects resources (such as servers or internal services) with RBAC configurations. You can think of it like a DomainA domain is an attribute of an Okta organization. Okta uses a fully-qualified domain name, meaning it always includes the top-level domain (.com, .eu, etc.), but does not include the protocol (https). in Active Directory or a Realm in Kerberos.

Project documentation

Dynamic Credentials

You can also think of projects as programmable Certificate Authorities which issue ephemeral certificates in accordance with your RBAC configurations.

Each of these certificates contains at least the following information:

  1. The Advanced Server Access project for which the certificate was issued
  2. The username to be used on the server of the Advanced Server Access user to whom the certificate was issued
  3. The time at which the certificate expires

Since Advanced Server Access credentials are short-lived, and scoped to a project, even if a credential is compromised by an attacker, the attacker has a very limited window of time to use the certificate before it expires, and it is only of use against resources in that project.

Top