Organization Setup Examples

The below examples are meant to illustrate various options of how you can organize your tenant's services.

Example 1: FunBank

FunBank has 1 customer portal, where they use AXN Verify for account opening and AXN Manage for ongoing Adaptive Authentication.

Notes

  • To handle this scenario, FunBank created 2 relying parties - 1 for the account opening use case, and a second for the adaptive authentication use case. See Relying Party
  • This way - it is simple for FunBank administrators to differentiate between verification services associated with each use case.
  • From a reporting perspective, FunBank can filter by "Relying Party" to see transactions from different use cases. See Transaction Report
  • FunBank receives their bills at the Relying Party level, to differentiate spend between account opening and login.

Example 2: GreenCorp

GreenCorp is a large company, and has hundreds of internal applications. They are using AXN Manage for adaptive authentication. They want to be able to differentiate between the internal applications, but they do not want to have to create hundreds of services in ID DataWeb. Instead, they have 1 Relying party for Adaptive Authentication, and have instructed their application teams to use AppID with their integrations to ID DataWeb.

Notes

  • Each application sends in a unique AppID for each interaction with ID DataWeb.
  • From the administrators perspective, it is easy to filter transactions based on AppID, or to see the total volume with no filters.
  • Billing can be broken down by appID, so that individual application teams can see their usage. This can also be used to facilitate internal chargeback, where a central shared services provider in a company charges internal teams for their usage.

Example 3: ABC Corp (Reseller, Community Manager)

ABC Corp is a technology provider for multiple downstream subgroups. They need their subgroup admins and application teams to have access to only specific workflows for their subgroup, which ABC Corp helps create, manage and maintain for them. In turn - ABC Corp needs super-adminstrators (ABC Corp administrators) to be able to see and manage all services. For this - ABC Corp is set as the organization, and each subgroup is set as a relying party. ABC Corp employees are invited as organization administrators, so they can have access to everything in the ABC Corp organization. When subgroup administrators are added, they are invited with Relying Party restrictions. This guarantees that they will only ever have access to their subgroup's services and data. This way - ABC Corp can offer ID Dataweb services to multiple subgroups from a single organization, while maintaining least privilege, subgroup authorization, etc.

Notes

  • Organization set up for ABC Corp.
  • ABC Corp employees invited as Organization adminstrators.
  • Each subgroup created as a Relying Party under the ABC Corp organization.
  • Each subgroup administrator invited with correct relying party restriction.
  • All access to services, workflows, reporting and actions are restricted by Relying Party for the subgroup admins, while Organization admins maintain full access and visibility.