-
Notifications
You must be signed in to change notification settings - Fork 2
Account Manager Introduction
Account Manager is a multi-organization and multi-user management library. It defines a logically separated identity repository, generic data and grouping models, hierarchical authorization model utilizing roles, groups, and permissions, and a suite of business and process related objects intended to capture business process and identity management information.
AccountManager is in its fifth version. It was written to address a need for a lightweight service that could store variant data (a la a CRM) with different levels of permissions and encryption applied, and to support complex permission relationships. Over time it has evolved to support community-orientated vectors of identity and process information in order to analyze and manipulate complex identity management ecosystems, define policy evaluation across hierarchical entitlements, and protect designated information at rest.
The target consumer of this library are those desiring to stage multi-tenant identity services. While this library is not itself an identity management solution, lacking the bevy of integration points, interfaces, and workflow engines, it is able to ingest multiple dimensions of identity information from other identity management solutions.
Account Manager is built to support a number of operations and structures that are better expressed in a relational database than in a directory.
The Account Manager schema and factory layers has been evolving over twelve years, before NoSQL was available. It will certainly be considered in the future.
You can deploy this wherever you want.
See remark on directory service.
Custom UIs can be written using any preferred framework.
The example UI is just that - an example. I used my own framework for the example interface, and all of the basic CRUD views use this framework. However, everything is driven by the same set of common services so it was be straightforward to adapt to any desired UI framework.
The current version is Account Manager 5.2, and is written in Java. Maven compiler settings are set to Java 13, and certain transitive dependencies have been excluded to support this. Downgrading the Java version may require these dependencies to be included. Key project dependencies include Bouncy Castle crypto libraries, Tomcat 8.x application server, and PostgreSQL 9.x database server.
Alternate Java application containers may be used, such as IBM Liberty or RedHat JBoss, however the corresponding server configurations, libraries, and authentication integration must be specified and are not included here.
The previous version, Account Manager 4, is written in C# for both ASP.NET and Mono and SQL Server 2005 and later.
Account Manager 3 was written in both Java and .NET, and though a big hairy mess was the point at which the security model began to evolve. Account Manager 2 was written in Java and relied on a very proprietary data structure that is not worth going into much detail about.
Account Manager 1 was written in Java and relied on a lot of serialized objects and XML. It made the next big hairy mess look relatively clean.
There is a fair amount of repetition to the schema fields, stemming from the common root of NameIdType values: id (long), name (string), ownerid (long), parentid (long). The following schema highlight some key entities.
- Organizations are top level descriptors in which everything is created.
- Groups define hierarchical collections for use with most entity types. For example, directory groups are used to create a hierarchies similar to a filesystem. Most Account Manager entities use the group hierarchy for lineage. Some entities support both groups and parents, while a few of the original entities such as Roles and Permissions continue to use only a parent.
- Asymmetric/SymmetricKeys are binary stores of cryptographic keys.
- Accounts are aggregates of users and contact information. Accounts are unique by name and group. Accounts may be authorized to other entities with permissions, roles, and groups, but not system capabilities.
- Credentials are binary entities used to store different types of credential values by entity type.
- Persons are aggregates of accounts, users, and contact information. Persons are unique by name and group. Persons may be authorized to other entities with permissions, roles, and groups, but not system capabilities. Persons may also inherit entitlement from linked accounts.
- Users are discreet system actors. Users are unique by name and organization. Only users may be entity owners, authenticate to Account Manager, and be authorized to perform an underlying system activity.
- Data is a generic schema describing binary data by name and group, with deterministic compression, and optional multi-layered encryption. Data is unique by name and group.
- Roles define hierarchical collections for use with Accounts, Users, and Groups, and may be affected with permissions applied towards Groups and Data
- Permissions define entities for use with Accounts, Data, Groups, and Roles. Permission relationships are created as Effects between two or more entities.
- Spools define entities for queuing information such as messages and tokens.
- Tags define collections for use with Accounts, Users, and Data.
- Attributes may be stored for any NameIdType factory type.
- Normalized relationships are stored in participation tables.
- Policies aggregate rules. Policies are unique by name and group.
- Rules aggregate rules and patterns. Rules are unique by name and group.
- Patterns relate two facts with a comparator. Patterns are unique by name and group.
- Facts define or describe discovery of some type of data. Facts are unique by name and group.
- Operations are predefined processes that operate on facts. Operations are unique by name and group. Operations may require custom development.
- Functions and FunctionFacts are predefined procedures and service requests. Functions are unique by name and group. Function Facts describe a logical order of facts to function arguments. This feature is still in progress.
- Artifacts represent discrete process assets.
- Budgets represent a statement of time and cost.
- Cases represent use cases.
- Cost represents a value by currency type.
- Estimates are an alternate representation of a budget, also representing time and cost.
- Events describe the orchestration of traits, actors, objects, and locations over a specified time frame.
- Expenses describe budgets relative to actual time and cost.
- Forms describe compositions of fields, values, and validation patterns.
- Goals describe desired outcomes within a specified schedule and budget, relative to requirements, dependencies, and cases.
- Lifecycles describe the schedules, budgets, projects, and goals of an arbitrary program.
- Methodologies describe processes and subsequent process steps relative to budgets.
- Models describe artifacts with respect to cases, requirements, and dependencies.
- Modules describe work with respect to artifacts, time, and cost.
- Notes are lightweight data elements with both group and parental lineage.
- Processes are specific methodologies composed of budgets and steps.
- Projects describe scheduled stages of modules with respect to blueprints (modules), requirements, dependencies, and artifacts.
- Requirements describe semi-structured work inputs, inclusive of forms and notes.
- Resources describe a specific resources (such as a person or an object) with respect to a schedule and an estimate, and its utilization.
- Schedules describe goals and budgets with respect to a given time frame.
- Stages describe work with respect to a methodology, budget, and schedule.
- Tasks describe work activity with respect to requirements, artifacts, work, notes, estimates, time, cost, resources, and dependencies.
- Tickets describe work requests with respect to resource assignment, estimates, time, cost, dependencies, artifacts, notes, forms, and audit activity.
- Time represents a value by time basis.
- Work describes tasks with respect to resources, artifacts, and dependencies.
- A number of views are defined to return data, group, role, and user information augmented or filtered for effective authorization data.