As discussed in a prior module, Account Stores are external directories or “applications aka apps” containing their own accounts and groups. In EmpowerID, there exists an AccountStore table as well as a ProtectedApplicationResources table for storing EmpowerID’s definition of applications. The relationship between these two entities can be confusing, so we’ll attempt to clarify the concept here.
In the IT landscape, especially SaaS, many applications have their own internal and dedicated directory feature for accounts and groups that is not centralized or shared between different applications. Let’s refer to this scenario as the “internal directory” model. In order to inventory the accounts from these applications, EmpowerID requires an Account store and Resource System connection to define how to connect, what to inventory, and how to manage objects in these external systems. Another security model for applications is to utilize a centralized directory for security and not rely on a local store for accounts and groups. Let’s refer to this as the “external directory” model. Examples of this type of application would be any that relied on a shared LDAP directory that was used by multiple applications. In this case, the applications are delegating the management of these functions to the LDAP Directory or Account Store.
So far, we’ve determined that to manage an application containing its own Accounts and Groups, EmpowerID requires an Account Store and Resource System. What we haven’t defined yet is the purpose of the “Application” object in EmpowerID which would be created in the ProtectedApplicationResources table. Application objects in EmpowerID are the logical definition of what admins and end-users think of as an application. They typically contain the URL of the application, a description, icon and are what users see and request access to in the IT Shop.
In our internal directory scenario described above, the admin when onboarding these applications in EmpowerID would select the Account Store that had been defined for the app's internal directory. This lets EmpowerID know in which Account Store the accounts and groups are located that can be granted access to the application. However, in our eternal directory scenario, the admin would onboard multiple applications where EmpowerID would be selected as the Account Store for the application. In this scenario, where many applications in EmpowerID share the same Account Store for their security, the application owner can select specific groups in any Account Store to link as granting access to that application.
https://youtu.be/Ag2cgtu2GLw
Key Components Related to an EmpowerID Application:
Protected Application Resources like pages, controls, APIs
SSO Connections (SAML, OpenID Connect, etc.)
OAuth Scopes configuration
Multi-Factor Authentication settings
PBAC rights and roles
Groups and roles that should be requestable for this app in the IT Shop
Key Takeaways:
Most applications are a one to one with an Account Store that represents their internal directory.
Applications that share an Account Store would select to use EmpowerID as the Account Store and then link the specific groups to which they wish to grant access to their application.
An application object is not automatically created for each Account Store in EmpowerID.
Any application configured for SSO requires an application object in EmpowerID.
The component for applications and their subcomponents is named ProtectedApplicationResource.
During application onboarding selecting to create a Tracking Only Account Store will create a “logical” Account Store in EmpowerID for access requests and tracking that is not inventoried or managed.