Applications Versus Account Stores

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.

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