The below examples are meant to illustrate various options of how you can organize your tenant's services.
FunBank has 1 customer portal, where they use AXN Verify for account opening and AXN Manage for ongoing Adaptive Authentication.
- 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.
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.
- 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.
Updated over 1 year ago