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
        • Evaluate and decide usage of Kafka serialization implementation technology regarding the facts and data exchanged on the DIS:
          • Apache Avro serializer/deserializer: https://avro.apache.org/ Avro schema file generations from java classes to IDL files (migration of POJO to IDL allowing to manage the schema generated as avro file for POJO mapping and Java classes auto-generation): https://www.instaclustr.com/blog/exploring-karapace-part-2/
            • AVRO ADVANTAGES
              • dynamic typing: Unlike Protobuf, Avro does not require code generation, which enables more flexibility and easier integration with dynamic languages like Python or Ruby.
              • Self-describing messages: Serialized data in Avro includes embedded schema information, making it possible to decode the data even if the reader does not have access to the original schema. As we have seen from the example, an Avro message must always be prefixed with some information about which schema was used to encode it or the decoder will either fail or create invalid data. Adding default values to the schema is very important to allow a value to be removed later.
                • Protobuf: Despite the slightly smaller encoded data size for Avro, the ability to update Protobuf message definitions in a compatible way without having to prefix the encoded data with a schema identifier makes it a better choice for the data transmission of where object versions shall be automatically and dynamically managed by the deserializer. More easy to debug than protobuf which is less humand-readable wire format. BUT: Slower serialization/deserialization performance due to dynamic typing nature and embedded schema information
              • Verbosity of schema definition in JSON
              • JAVA
                • IDL file (domain objects specification) > AVRO file (schema versioned, auto-generated java class)
                • Avro file usable by Producers/Consumers for POJO mapping (e.g exchange of serialized data over Kafka or Redis or filesystem)
                • Retrocompatibility test under Maven about schema and new generated classes: https://docs.confluent.io/platform/current/schema-registry/develop/maven-plugin.html#schema-registry-test-compatibility
                • Producer example with automatic schema version added: https://github.com/confluentinc/examples/blob/7.4.1-post/clients/avro/src/main/java/io/confluent/examples/clients/basicavro/ProducerExample.java
                • Consumer example with automatic schema version read: https://github.com/confluentinc/examples/blob/7.4.1-post/clients/avro/src/main/java/io/confluent/examples/clients/basicavro/ConsumerExample.java
              • NodeJS
                • JS encode/decode from avro-js module : https://blog.basyskom.com/2021/what-is-apache-avro-compared-to-protobuf
              • Karapace (Kafka REST and schema registry into a docker instance)
                • Karapace schema registry: https://www.instaclustr.com/blog/exploring-karapace-part-3/ supporting Avro, JSON schema and protobuf; with REST interface for schema management
                • Github project : https://github.com/Aiven-Open/karapace
      • 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 via FactRecord relative to registration of access control domain's elements (e.g tenant, account transaction facts) and design the persistence system global repositories and stores area (per domain; transversal knowledge db between domains)
        • WRITEMODEL / EVENT SOURCING PATTERN AccessControlRepository: IDomainRepositoryAccessControl impl (fact repository which maintain history of a type of domain fact) as access control writeModel (extending domain Repository class) = IDomainRepository that represent a persistence-oriented repository (also sometimes called Aggregate store, or Aggregate-Oriented database) basic contract for a bounded context = Domain Event's Sourcing pattern implementation into the AccessControl bounded context = Kafka domain operational data stream (append-only based as change history)
        • WRITEMODEL / EVENT SOURCING PATTERN AccessControlEventStore : IDomainStoreAccessControl impl (Fact domain store, extending EventStore impl class); MongoDB dedicated schema for bounded domain backup (access control write model, in streaming approach with appendOnly inserts backuped for possible future restoration of writemodel history; sharded database in mongodb or files-based system; e.g sharded database for a tenant) + notification of changes in Kafka event topics (with application domain CDC approach about observed data changes to other domains' views; 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 Kafka) 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 Kafka events stores (in case of DRP, the restoration process is kafka topics > MongoDB backup per domain > DRP restoration of kafka event store (history of facts) from MongoDB > update/rebuild of graph db read models from persistent Janusgraph according to the DRP scenario based on re-read of all history of mongodb 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 keycloack)
    • 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
    • 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: multidomains shared tenant configuration for keycloak access into Redis as "tenant read model" hosted by transversal 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