As discussed in a prior module, Account Stores are external directories or “applications” “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.
...
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 apps app's internal directory. This lets EmpowerID know in which Account Store are 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 the Account Store of the external directory they relied on would be selected. In this scenario, where many applications in EmpowerID share the same Account Store for their security, the application owner can select which specific groups in that Account Store should be identified as granting access to that application.
...