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.
Identity Provider (IdP)
Every team has an Identity Provider (such as Google, Okta, Active Directory, or LDAP) which 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. 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.).
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..
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.
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.
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.
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.
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:
- The Advanced Server Access project for which the certificate was issued
- The username to be used on the server of the Advanced Server Access user to whom the certificate was issued
- 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