Skip to main content

 

 

Cisco Defense Orchestrator

Relationship Between the Identity Provider Acounts and Defense Orchestrator User Records

About the Identity Provider Account and Defense Orchestrator User Record

To log in to Defense Orchestrator, a user needs two things: an account with a SAML 2.0 compliant identity provider (IdP) and a user record in Defense Orchestrator. The IdP account contains the user's credentials and the IdP authenticates the user based on those credentials. The Defense Orchestrator user record primarily identifies the username, Defense Orchestrator tenant with which they are associated, and the user's role.

When a user logs in, Defense Orchestrator tries to map the IdP's SAML assertion that the user is authentic to an existing user record in Defense Orchestrator. 

Customers who do not manage their own IdP's use Defense Orchestrator's OneLogin IdP by default. Customers can integrate their own IdP with Defense Orchestrator if they choose. 

Login Workflow

This is a simplified description of how the IdP account interacts with the Defense Orchestrator user record to log in a Defense Orchestrator user: 

  1. The user requests access to Defense Orchestrator by trying to connect directly to the site https://defenseorchestrator.com or by connecting to a SAML 2.0 compliant identity provider (IdP) such as cdo.onelogin.com.
  2. The IdP authenticates the user.
  3. The IdP issues a SAML assertion that the user is authentic and redirects the user to https://defenseorchestrator.com.
  4. Defense Orchestrator validates the SAML assertion, extracts the username and attempts to find a user record corresponding to that username.
  • If the user has a user record on a single tenant on Defense Orchestrator, Defense Orchestrator grants the user access to the tenant and the user's role determines the actions they can take. 
  • If the user has a user record on more than one tenant, CDO presents the authenticated user with a list of tenants from which to choose. The user picks a tenant and is allowed to access the tenant. The user's role on that specific tenant determines the actions they can take. 
  • If Defense Orchestrator does not have a mapping for the authenticated user to a user record on a tenant, Defense Orchestrator rejects the attempted login.

Creating a user record in Defense Orchestrator does not create an account in the IdP and creating an account in the IdP does not create a user record in Defense Orchestrator.

Similarly, deleting an account on the IdP does not mean you have deleted the user record from Defense Orchestrator; although, without the IdP account, there is no way to authenticate a user to Defense Orchestrator. Deleting the Defense Orchestrator user record does not mean you have deleted the IdP account; although, without the Defense Orchestrator user record, there will be no way for an authenticated user to access a Defense Orchestrator tenant.

Implications of this Architecture

Customers Who Use Defense Orchestrator's OneLogin Identity Provider

For customers who use Defense Orchestrator's OneLogin identity provider, they continue to need to open a support ticket with Defense Orchestrator to create a new OneLogin account. If they do not have user with a Super User role, they will also need to open a support ticket to elevate the role of one of its users from Admin to Super Admin. After that, the Super Admin can create, edit, and delete Defense Orchestrator accounts on their tenant. 

Should the Super Admin ever need to prevent another user from accessing Defense Orchestrator, they can simply delete the Defense Orchestrator user's user record. The OneLogin account will still exist and if the Super Admin ever wants to restore the user, they can by creating a new Defense Orchestrator user record with the same username as the one used for OneLogin. 

Should a customer ever run into a problem with Defense Orchestrator that requires a call to our Technical Assistance Center (TAC), the customer could create a user record for the TAC engineer, in a read-only role, so they could investigate the tenant and report back to the customer with information and suggestions.

Customers Who Have Their Own Identity Provider

For customers who have their own identity provider, they control both the identity provider accounts and the Defense Orchestrator accounts. These customers can create and manage identity provider accounts and user records in Defense Orchestrator for their users without opening a support ticket with Defense Orchestrator. 

Should they ever need to prevent a user from accessing Defense Orchestrator, they can delete the IdP account, Defense Orchestrator user record, or both without opening a support ticket.

If they ever need help from Cisco TAC, they can create both the identity provider account and a Defense Orchestrator user record, with a read-only role, for their TAC engineer. The TAC engineer would then be able to access the customer's Defense Orchestrator tenant, investigate, and report back the customer with information and suggestions. 

Cisco Managed Service Providers

If Cisco Managed Service Providers (MSPs) use Defense Orchestrator's OneLogin IdP, they request IdP accounts for themselves and their customers by opening a ticket with Defense Orchestrator. They will also need to open a ticket to elevate the role of one user on every tenant they manage to a Super Admin. After that, the Super Admin can create, edit, and delete Defense Orchestrator accounts on the tenants with which they are associated. 

  • Was this article helpful?