Memority Tenant Project Structure
A tenant project is a Maven multi-module project that contains all the configuration settings for one Memority instance (tenant). The project manages configuration as code: it stores every object type (policies, rules, connectors, etc.) as an XML or JSON file, versions each file in Git, and deploys them through a Maven build.
Project layout
<tenant-name>/
├── pom.xml ← Root POM: declares modules, environment profiles, dependency versions
├── assembly/ ← Aggregates all modules into a single deployable artifact
├── am/ ← Access Management
│ ├── amcp/ ← Authentication & portal configuration
│ └── rba/ ← Risk-Based Authentication
├── im/ ← Identity Management
│ ├── idm/ ← Identity data model
│ ├── bum/ ← Business User Management / UI policies
│ └── sync/ ← Synchronization & provisioning connectors
└── shared/ ← Cross-cutting services
├── aud/ ← Audit settings
├── i18n/ ← Internationalization / translations
├── ntf/ ← Email notifications
├── rep/ ← Reporting definitions
└── tcf/ ← Themes & custom assets
Each sub-module follows the same pattern:
<module>/
├── pom.xml
├── src/main/resources/ ← Configuration objects (XML files)
├── src/main/data/ ← Seed data (JSON) — only in idm and amcp
├── vars.properties ← Variables common to all environments
└── vars_<env>.properties ← Environment-specific variable overrides
Resource organization — You can organize configuration files inside
src/main/resources/in any folder structure. By default, the project groups them by configuration type (one directory per object type, e.g.AttributeDefinition/,Rule/), which makes individual objects easy to locate. You can add sub-folders freely within those type directories to further classify files by functional area, application, or any other criteria relevant to your project.
am — Access Management
Configures how users authenticate and how the portal behaves.
amcp — Authentication & Portal Configuration
Authentication and access configurations.
|
Folder |
Contains |
|---|---|
|
|
Login page appearance |
|
|
Session timeout and renewal rules |
|
|
Authentication mechanisms (MFA, OTP, SAML, OIDC) |
|
|
Authentication chains (modules combining mechanisms) |
|
|
User attributes managed by the AM layer |
|
|
OAuth2 clients and scopes |
|
|
WebAuthn / passkey settings |
|
|
Module-level settings |
|
|
Federation definitions ( |
rba — Risk-Based Authentication
Risk based authentication configurations.
|
Folder |
Contains |
|---|---|
|
|
Step-up authentication rules based on risk score |
|
|
Risk evaluation based on environment context (IP, geolocation…) |
|
|
Risk rules tied to user behaviour |
|
|
Module-level settings |
im — Identity Management
Defines the identity model, the business rules applied to it, and the connectors that push/pull data to external systems.
idm — Identity Data Model
Data model configurations.
|
Folder |
Contains |
|---|---|
|
|
Identity attributes (name, email, custom fields…) |
|
|
Identity type definitions (employee, contractor, service account…) |
|
|
Organizational unit types |
|
|
Lifecycle transitions (hire, transfer, departure…) |
|
|
Calculation and derivation rules for attributes |
|
|
Rules to detect and merge duplicate identities |
|
|
Role types (application roles, business roles…) |
|
|
Rules for publishing roles to end users |
|
|
Fine-grained entitlements |
|
|
Resource type definitions |
|
|
Password complexity and rotation rules |
|
|
Reference data (country codes, job codes, etc.) |
|
|
Groovy scripts / derivation rules |
|
|
Module-level settings |
|
|
Seed data: |
bum — Business User Management
Portal and features configurations.
|
Folder |
Contains |
|---|---|
|
|
Activates / configures portal features |
|
|
Controls which identities can access which features |
|
|
UI forms for viewing and editing identity attributes |
|
|
Business validation rules for user actions |
|
|
Policies governing role request and approval workflows |
|
|
Approval workflow definitions |
|
|
Settings for public (unauthenticated) access |
|
|
Groovy scripts |
|
|
Module-level settings |
sync — Synchronization & Provisioning
Synchronization & Provisioning configurations.
|
Folder |
Contains |
|---|---|
|
|
Target application definitions |
|
|
How identities are represented in each application |
|
|
Generic connector configurations |
|
|
REST-based connector configurations |
|
|
Tasks that push changes to target applications |
|
|
Tasks that import data from authoritative sources |
|
|
Post-processing steps after a sync task |
|
|
Tasks that export data |
|
|
Tasks that discover existing accounts in targets |
|
|
Post-processing after account discovery |
|
|
Module-level settings |
shared — Cross-cutting Services
All shared sub-modules.
|
Module |
Contains |
|---|---|
|
|
Audit configuration and settings |
|
|
Translation bundles for all languages |
|
|
Email notification templates ( |
|
|
Report definitions (XML) for identity, recertification, and resource reports |
|
|
UI themes and static assets ( |
assembly — Deployment Artifact
The assembly module depends on all other sub-modules and uses the Maven Assembly Plugin to package every dataset into a single deployable directory. This artifact is what the Memority Integration Tool (MIT) deploys to the platform.
Environment management
The root pom.xml defines one Maven profile per environment:
|
Profile |
Environment |
Purpose |
|---|---|---|
|
|
Integration |
Development & integration testing |
|
|
Pre-production |
Staging / UAT |
|
|
Production |
Live environment |
Each profile sets the platform API URL, SSO URL, stack name, and environment identifier.
Variable substitution — within any XML resource file, variables use the @{variable.name} syntax. Maven replaces them at build time using values from:
-
vars.properties(shared across all environments) -
vars_<env>.properties(environment-specific overrides)
Example:
<email>@{setting.idm.system.user.email.value}</email>
resolves to the value set in vars.properties or vars_prod.properties depending on the active profile.