Agenda

Presenter

Duration

Discussion

Manage Access Authorization to BB APIs

@Jaume DUBOIS

30 minutes

• Types of accessors checked (human, back-end systems, apps or browser, robots, hardware, ..)

• Granularity of access control (Building block, module, API, single API service, single API service for specific tenant or data)

From Technical Committee Meeting:

BBs should not own RBAC - the calling applications are responsible for it. 

Are we using token based authorization within the request to BB?

How to get candidates bypass its own RBAC?

1. Superuser access to be given when merging with IM backend?

2. Or control to switch off existing RBAC in target BBs

3. option to have api token registered in IM at max permission level for specific member entities

4. come up with a concrete example for this case

Sandbox/Kubernetes/IM

@Satyajit Suri

30 minutes

Issues related to the implementation of Building Blocks and the Information Mediator within a Kubernetes cluster.

Vasil: In order to make deployments cloud agnostic, Sandbox is using Kubernetes. BBs are deployable images that can run in the Kubernetes cluster. Applications are packaged and run in the same way.

What if an BB requires multiple images?

Taylor: A BB should just expose a set of services. And it may require other applications/services behind the scenes.

If the APIs/services are spread across multiple instances/containers, an adaptor should be used to mediate the different API calls.

Every BB should expose 1 single service for its various APIs. The containers/services that it relies can be in the same environment/sandbox but don’t have to be.

Open

Wes: This type of implementation may not be needed in the sandbox (with full isolation, etc). Sandbox should be a simpler demonstration of implementing use cases using GovStack-compliant building blocks.

We need clear guidance like the above on how a real GovStack implementation should work, and also a path forward for getting the sandbox up and running quickly - and define the requirements (ie. multi-tenancy not necessary)Act

Action items:

1. BB providers under contract to document the challenges/complexity in customizing their applications to be compliant - @Allan Bernard @Jane Rose Anthony @karim.jindani

2. Sandbox to define clear scope - what is in/out of scope - @Nico Lueck and defining how to get the contracted candidates running in Sandbox

3. Arch team to provide guidance (like the above) on what real world implementation should look like

Technical Reviews of BB specs

@Steve Conrad

5 minutes

Arch team to review UI/UX work: https://app.gitbook.com/o/pxmRWOPoaU8fUAbbcrus/s/Xygp83qW0E147CCaqsI0/

GERA Update

@Aare Laponin @PSRAMKUMAR

15 minutes

Update on changes to GERA document and progress/next steps

Next steps/AOB

@Steve Conrad

5 minutes

What should we prioritize?

• GERA document/review - articulate core concerns

• Workflows/Core Capabilities

• Testing with Information Mediator

• Revisit Security Specifications

• Mapping out BB interactions/domain diagrams

  • Aleksander has some resources/starting point

    • Overall structure of GovStack solution

  • Sandbox team has happy flow document that we can walk through

    • Minimum Viable Product (MVP) eg. Happy Flow