Applications Versus Account Stores

As mentioned in a prior discussion, Account Stores are external directories or “applications aka apps” containing their own accounts and groups. In EmpowerID, there exists an AccountStore table and 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. To inventory the accounts from these applications, EmpowerID requires an Account store and Resource System connection to define how to connect, inventory, and 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 those that relied on a shared LDAP directory 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 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