Applications Versus Account Stores

As previously discussed, Account Stores in EmpowerID refer to external directories or applications that have their own accounts and groups. To manage these accounts and groups, EmpowerID has an AccountStore table and a ProtectedApplicationResource table, which store EmpowerID's definition of applications. Understanding the relationship between these two entities can be complex, so let's clarify it further.

In the IT landscape, applications often have their own internal directory feature for accounts and groups, which is not shared between different applications. This is referred to as the "internal directory" model. To inventory the accounts from these applications, EmpowerID requires an Account Store and Resource System connection. In contrast, some applications utilize a centralized directory for security, relying on a shared LDAP directory used by multiple applications. This is known as the "external directory" model, where the management of these functions is delegated 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 the internal directory scenario described above, when onboarding these applications in EmpowerID, the admin would select the Account Store defined for the app's internal directory. This lets EmpowerID know which Account Store contains the accounts and groups that can access 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.

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

https://youtu.be/Ag2cgtu2GLw

 

Key Takeaways:

  1. Most applications have a one-to-one relationship with an Account Store that represents their internal directory.

  2. Applications that share an Account Store would use EmpowerID as the Account Store and then link the specific groups they wish to grant access to their application.

  3. An application object is not automatically created for each Account Store in EmpowerID.

  4. Any application configured for SSO requires an application object in EmpowerID.

  5. The component for applications and their subcomponents is named ProtectedApplicationResource.

  6. 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.