About the component framework
What is a component?
A component is a collection of scripts and data that provide extra functionality to Bravura Security Fabric . Components rely on the component framework, which is built from a library of Python scripts and SQLite tables to store configuration. The component framework acts as a control layer between Bravura Security Fabric and individual components, ensuring that each installed component is run at the appropriate time and with the correct runtime parameters.
Each component is designed to implement or handle a specific feature or piece of functionality in Bravura Security Fabric ; for example, the AuthMod component adds a policy-driven system for controlling authorization for requests. A typical component comprises some or all of the following modules:
Manifest file – always present and essentially the ”backbone” of the component. It dictates what modules the component contains, what dependencies it requires, and how and when the various scripts interact with the product.
Python scripts – drive the computational logic of the component to dynamically change how the product should react to a user’s actions or workflow events. Data for these calculations can be derived from the SQLite tables.
SQLite Tables – used by the Bravura Security Fabric administrator to define policies and configurations for components. These components are stored in an
extdb, which is a SQLite database. See https://www.sqlite.org/ for more information about SQLite.
In addition to the default components provided as part of the Bravura Security Fabric install package, custom components can be written by those with sufficient understanding of Bravura Security Fabric and Python. Custom components can provide new functionality, or can override existing components to alter the default functionality.
There are also a few samples located within both the samples\idmlib and component directories.
Types of components
There are four main types of components, each having a different purpose:
Data – Data components contain product configurations such as target system, attribute, and request configuration elements. They contain no scripted logic, and can be modified by environment files.
Functional – Functional components provide script and policy extensions to enable additional functionality in Bravura Security Fabric , such as modifying the authorization workflow or managing authentication chains. On their own, functional components do nothing; they provide a library of functionality for other, generally higher-level, components. Functional components include data components or other functional components as dependencies.
Scenario – Scenario components extend functional components to implement a particular use case, or scenario. A scenario could be as simple as adding some specific configuration parameters for a functional component (so that it implements a use case) or as complex as adding several functional components, scripts, and many data components.
RefBuild – RefBuild components define a reference implementation as either a built-in Bravura Pattern edition or customer specific. They typically contain a collection of scenario components and independent data components. Refbuild components have no data or code, and should be a manifest file with dependencies defined.
What is a pattern?
A Bravura Pattern is a reference implementation of Bravura Security Fabric – a collection of scripts and components used to implement a set of identity and access management business processes for a specific type of organization. These components were designed around a multitude of common use cases, and provide an easily configurable method to implement these use cases. Bravura Security offers multiple editions of Bravura Pattern.
Bravura Pattern reference implementations are built from a number of process-driven scripts, which are typically controlled by a SQLite database accessible via the Manage external data store (DBE) module.
Bravura Security Fabric administrators can populate tables in the database to dictate the logic Bravura Security Fabric will apply when running a specific component.
Bravura Pattern is composed of inter-dependent components, which can be deployed individually when a full reference implementation is not appropriate. By installing these components together in the form of a reference implementation you are providing all the needed functionality to run specific business cases that you would otherwise have to research and install, and configure the necessary individual components.
The following editions are currently available:
Bravura Workforce Pattern
Bravura Workforce Pattern is a rapid deployment feature that can reduce implementation time by up to 75% by automating typical identity life cycle management requirements. Bravura Workforce Pattern reduces scripting for complex business logic such as SoR (system of record) onboarding. Initial and ongoing configuration of Identity Management is greatly minimized to lower costs and deployment time.
Patterns that are relevant for Bravura Workforce Pattern are:
RefBuild.im_corporate- reference implementation installs and configures the components used to implement common corporate user management scenariosRefBuild.im_corporate_functional- provides dependancy list for functional components needed for Bravura Workforce Pattern .RefBuild.im_corporate_scenario- provides dependancy list for scenario components needed for Bravura Workforce Pattern business cases.
Additional related patterns for Bravura Workforce Pattern are:
Refbuild.im_pm_demo- similar to the functionality of RefBuild.im_corporate, but includes additional targets, user classes and roles that may be needed for larger implementations or for sales engineering demos
See Bravura Workforce Pattern for configuration details.
Bravura Privilege Pattern
Bravura Privilege Pattern is a set of pre-defined policies and business rules built around Bravura Privilege, designed to simplify control over access to privileged accounts and security groups across a variety of systems.
Bravura Privilege Pattern incorporates two major components:
Policy rules that determine:
What privileged accounts and groups are visible to requesters.
Whether access is auto-approved or requires workflow approval.
Who has the responsibility to approve one-time access.
What disclosure mechanisms to offer users who have checked out access.
Whether to record user activity and what data streams to capture.
How to assign risk to access requests.
A delegated, team-based model for onboarding systems and accounts and for controlling visibility, pre-authorized access, approval workflows, disclosure methods and session monitoring.
Patterns included for Bravura Privilege Pattern are:
RefBuild.pam_request_risk_assessment- provides configuration for implementing risk management calculations to determine appropriate workflowRefBuild.pam_team_management- provides configuration for both system onboarding and vault managementRefBuild.pam_team_onboard_management- provides configuration for system onboarding onlyRefBuild.pam_team_vault_management- provides configuration for vault management only
See Bravura Privilege Pattern for configuration details.
Component and script priorities
Component manifest files define two types of priorities:
The first one, in the component element itself, determines the order of loading of components.
Component dependencies are installed before the component that lists them as dependencies.
Where there are "tie-breakers" required (several components with the same dependencies affecting the same policies, but with no cross-dependencies between them), the component priority also determines the component evaluation order.
The higher the priority setting, the later it is evaluated, so the higher its actual priority in evaluating its function (for example attribute calculation).
The second type of priority is that for scripts running inside exit traps or plugin points.
That script priority, similarly with the component priority, determines the order of running several components which are defined for the same plugin point or exit trap.
The higher the priority number, the later the script is run compared to the other ones defined by other components for the same event.