As security system, I should ensure AC-2(8) Dynamic account management

[olivierlemee]

FTEST_198: https://www.notion.so/cybnity/198-6dde495085b94fb3a1e4ee01d46b4d44?pvs=4

PRD: https://www.notion.so/cybnity/AC-2-8-Dynamic-account-management-72d42a96723c48e5b254c59fd24b6bc8?pvs=4
Approaches for dynamically creating, activating, managing, and deactivating system accounts rely on automatically provisioning the accounts at runtime for entities that were previously unknown. Organizations plan for the dynamic management, creation, activation, and deactivation of system accounts by establishing trust relationships, business rules (e.g security missions), and mechanisms with appropriate authorities (e.g security team owner; sub-division team) to validate related authorizations and privileges.

AC-2(8): Create, activate, manage, and deactivate [Assignment: organization-defined system accounts] dynamically.
Family : ACCESS CONTROL

Used capabilities: Stakeholders and responsibilities UI Module server

USE CASES DESIGN

• Tenant and Account Registration Flow design in terms of requirements (at AC-2(8) )
  Registration flow and process (activities diagram about global registration flow with scenario identification)
  • about unknown tenant (e.g new organization to register as tenant with new account) with new account
  • about known tenant with new account registration
  • enhancement of account registration designed flow to introduce the multilayer delegation (backend-side vs direct front adapter link to keycloack)
  • identification of key data required during registration per scenario
  • general design sequence diagram in design documentation stored into the implementation project (domain-access-control) regarding collaboration between Keycloak( via admin client NodeJS and/or Java library) and domain-access-control UI layer
  • customer journey specification
• Account Activation performed by an organization’s manager (e.g CISO) via CYBNITY UI after a successful account creation and mail verification finished during an account registration process.
  • Customer journey
  • Sequence diagram
• Account Managing performed via Access Control capabilities provided over CYBNITY roles & responsibilities UI.
  • Customer journey
  • Sequence diagram
• Account Deactivation performed on-demand (e.g by a CISO team regarding one or several on his team’s members) or automatically executed by security controls during a doubt of usage violations (e.g attempt to reuse account by password attack) detected that shall take prevention measures to deactivate the attacked account with notification of his owner and/or his team manager.
  • Customer journey
  • Sequence diagram

PROTOTYPING

• UX/UI system design cost/plan
• UX/UI design by Jeremy about registration screen, homeUI, confirmation of activated account message, login screen from home screen according to the use case customer journey and flows

CODING

• Organization and Tenant registration coding
  • service activator, repositories, components standardized collaboration over UIS, pipelines process
  • keycloak admin api connector and integration for dynamic configuration creation
• Account registration scenario coding
  • Coding of structure and packaging of deployable components
    • components at keycloak side
      • identification of events and key data location in terms of storage (keycloak persistence vs domain persistence system)
    • components at domain-access-control side
      • ui layer
        • Evaluate, decide and code usage of Redis native serialization (map based) regarding the fact events exchanged on UIS without performance impact relative to 3rd-party serialization (eg avro) from NodeJS > Redis > Capability Features
      • application layer
      • domain layer
      • infrastructure layer
        • see fact edge generic persistence structure allowing traceability implementation regarding facts occurred on a write model or on a read model for registration of access control domain's elements (e.g tenant facts) and design the persistence system global repositories and stores area (per domain; transversal knowledge db between domains)
        • READMODEL / EVENT SOURCING PATTERN AccessControlRepository: IDomainRepositoryAccessControl JanusGraph / Cassandra impl (graph repository which maintain history of a type of domain fact) as access control readModel (extending domain Repository class) = IDomainRepository that represent a persistence-oriented repository (= Domain Event's Sourcing pattern implementation into the AccessControl bounded context = domain operational data stream as append-only based as change history)
        • WRITEMODEL / EVENT SOURCING PATTERN AccessControlEventStore : IDomainStoreAccessControl Redis streamimpl (Fact domain store, extending EventStore impl class); RedisStream dedicated schema for bounded domain (access control write model, in streaming approach with appendOnly inserts backuped for possible future restoration of writemodel history; sharded database in files-based system; e.g sharded database for a tenant) + notification of changes in Redis event topics (with application domain CDC approach about observed data changes to other domains' views like repositories; real-time domain data changed event; notified in real-time to any other domain regarding a scope of knowledge in relation with access domain informations)
        • READMODEL VIEW / CQRS PATTERN: other domains read models required by access control domain = append-only operations in persistent Janusgraph (graph db with quick read capabilities) per domain (materializing current/last domain data state or representing another domain's view model relative to external domain) based on the received notifications (via Redis) of data changes relative other domain's write models + Cassandra backup (restoration capability of last read model status by DRP)
        • design and write documentation about standard restoration process about any domain: backup of events stores (in case of DRP, the restoration process is Redis topics > MongoDB backup per domain > DRP restoration of Redis event store (history of facts) from MongoDB > auto update/rebuild of graph db read models rehydration by Janusgraph according to the DRP scenario based on re-read of all history of restored writemodel facts that is more speed; or based on last backup of Cassandra db that is more long and with more integrity guarantee)
  • account and tenant registration about unknown organization
    • automatic creation of dedicated tenant, client scopes configuration (reusable by applications for interactions with keycloak)
    • automatic creation of application roles and permissions set allowed to organization's account types usable by domains (e.g organization level roles like tenant administrator, tenant operator, organization member, service roles like log/audit...)
    • automatic creation of organization into the application domains (as usable by final user in skateholders management domain)
    • automatic creation of basis applicative roles in domains for the organization object and allocation to the user (e.g default organization root manager allowing to define what NIST/ISO framework or other roles can be generated for this organization or sub-divisions) including default authorizations and privileges (managed by the access-control domain and futurely managed via missions)
      • first listener of access control domain: multi-domains shared tenant configuration (from Redis cache or AC read-model repo) allowing keycloak access from any domain in I/O layer
  • account registration on existing organization
    • automatic check of valid email address owner
    • request of acceptance to the CISO responsible of the tenant (organization and tenant owner via generation of task/mission relative to stakeholders management)
  • existing account activation after registration controls (e.g mail address confirmation)
  • tenant activation at first organization's user connection
  • deactivation of existing user account (e.g by organization manager)
  • account registration reject about unactivated previous similar account (e.g by organization manager, by security control)
• Technical documentation update
  • inventory mapping (table of events mapping into implementation doc) with data object referential managed in Notion, and implementation documentation identified in implementation project (inventory of data standardized documentation for any impl project repository)
  • Collaborative event required by registration processes as storage EventRecord (e.g in Kafka's fact repository as writeModel equals to access control domain fact repository)

TEST & NON REGRESSION CAMPAIGN

• Behavior tests of scenario into QA environment
• CI/CD workflow to production version

DOCUMENTATION

• refactoring of realigned documentations about deployed implementation
• Evaluation of Midpoint solution integration and positioning into the use case (and opportunity to introduce it into the current implementation)

Component: Application System Security Control Implementation Component
Implementation deployable system: Access control & sso server
Technology layer: user interface area
Technologies: nodeJS, keycloack, java, javascript, ReactJS

[olivierlemee]

evaluation of UX/UI design cost requested for tenant and account registration, sign-up, home

[olivierlemee]

key events serialization and adaptation over UIS (redis) from access-control domain backend to UI Capabilities gateway

[olivierlemee]

1. créer composant gateway (application domain IO module) AccessControlIOGateway

   • DONE: process de délégation issue des entrées globale dans le module RTS et déclenchement du process module (embarqué ou délégué vers un autre stream redis) en charge d'implémenter les règles avec keycloack/la couche métier envers l'aggrégat...) : vertx worker implémenté côté reception des recipients list

   • DONE préparation du projet de composant server Access Control Process Module (normalement écoutant toutes les demandes de capacités d'UI, comme gestionnaire de déploy verticle) qui intègre/déploy en interne des Verticles dédiés et embarqués gérant chaque capabilité spécifique (externalizable ultérieurement en modules vertx server indépendants implémentés des ac-service (services applicatifs) packagées en verticles. Normalement ce process module devrait être en écouté depuis kafka lorsque le io gateway de AC saura faire du routage des recipients reçus vers kafka (plutôt que vers des topics redis comme actuellement)

[olivierlemee]

DONE: first feature (tenant registration) processing unit and common reusable classes (by any domain IO gateway, any domain feature processing unit) and collaboration functions regarding the implementation of Dynamic recipient routing list (routes between UI layer gateway > UI capability features) are developed.

[olivierlemee]

DONE: dynamic routing between domain IO gateway and Feature modules over the UIS space (Redis) with unit test validating the first functional implementation (by AC IO domain gateway realizing the domain routing/delegation + TenantRegistration feature module realizing the registration pipeline) reusing the common components developed into the framework

[olivierlemee]

DONE: generic extension of process module and pipeline module functions (e.g regarding all the collaboration, instantiation, configuration methods and behaviors) into common classes + refactoring of RTS module of access control as first impl + unit test validating with success the integration model

[olivierlemee]

DONE: structure of registration service, tenants read model repository, tenants write model store and standardized coupling. Unit test preparation regarding organization registration scenario according to requirements

[olivierlemee]

DONE: tenant registration service process coding according to the design model

[olivierlemee]

DONE:

• event sourcing reusable components and capabilities per common fact implementation classes (framework, domain) for tenant storage in stream (write-model), and automatic notification to read-model
• evolution of domain data layer's objects (tenant aggregate) for event sourcing support
• test in-memory store implementation and repository allowing unit tests coding including persistence capability

[olivierlemee]

DONE:

• event sourcing with store implementation (in-memory based)
• event sourcing repository and snapshots use during rehydration of events
• unit tests of registered organization, retrieved from repository and read-model projection (based on in-memory repo and store)

[olivierlemee]

DONE

• standalone use case tests regarding the TenantRegistration service supported by in-memory store and repository
• coding of notification events publications regarding service execution results (output channels observable by callers)

[olivierlemee]

DONE

• refactoring of helm projects and K8S development cluster project
• packaging of Janusgraph server and cassandra db systems over Helm project + deployment test

[olivierlemee]

DONE

• JanusGraph read-model repository + unit test + coding example of future other domains' repositories
• Unit tests and refactoring of Tenant Registration Service using queryable AC read-model projections (JanusGraph)
• Refactoring and codes cleaning of janugraph adapter/client lib, AC RTS project, ac-service-impl and api
• Technical documentation of implementation components and developer support doc