Attendees
...
...
Agenda
...
Presenter
...
Duration
...
Discussion
...
Sandbox
...
...
40 minutes
...
Vasil has a couple of topics from the Sandbox team for the arch team to discuss.
State vs stateless services - do we allow the receiving BB to validate roles/permissions?
Authenticating as a specific user when calling a DPG/product acting as a BB?
Service discovery
Other topics:
Real testing strategy and separation of responsibility for integration testing, calls to sandboxed BBs, Mocks vs Emulators (ready to use products like Mocoon vs Emulator implementation, deployability in sandbox)
Address in testing meeting
BBs that are cloud dependent or bigger than our infrastructure (installation and adaptation to specification, strategies to use, remote installations, tenant aware applications as BBs)
How can we deploy without DPG owners having access to our AWS environment?
Vendors need to provide configuration/deployment scripts (Helm charts, entrypoint scripts, etc). They should test in their own environment before ‘handing over’ to GovStack
How do we handle DPGs that are tied to specific cloud providers (AWS)? Is it a requirement that they be cloud agnostic? How do we handle on-prem requirements?
Need to identify infrastructure plan (TC and/or infrastructure team?)
Ramkumar to connect with Hani/Nico on infra requirements
Plugin API for BBs - related to service discovery, portal integration, infrastructure management, use case deployment and overall user experience once presented with the portal UI to manage what we are offering.
Portal application showing use cases available in the sandbox, allowing users to swap out BBs
Need APIs to determine what BBs are available, whether they are ready/running.
Define a standard set of APIs that are needed for any BB (arch team)
Do we need a BB registry?
Building block types, separation of requirements, UI building blocks, vertical stack BBs
Foundational vs functional
Identity BB vs Authorization services (security spec)
Steve/Ramkumar - Walk through authentication docs, UX docs, application concept with Vasil Kolev
Identify and address any gaps
Use case management and implementation strategies, showcase vs use case, reusability of components, unification of the UC applications
Align on terminology
Some of this will be addressed as part of the Capabilities conversation in TC
Apologies
Agenda | Presenter | Duration | Discussion | ||
Manage access authorization to BB APIs | 30 minutes |
| |||
Management of UX switching | 10 minutes | Review synchronous and async flows for UX switching. Review self-service and agent-led workflows as well. Documentation from Ramkumar: UX Switching Architecture team to review and provide feedback.
| Service Discovery | Steve Conrad Karim: In context of Payment BB, I have come across 2 requirements - 1 in which PayBB is the UI on which a party will redirect and another in which PayBB has to redirect to other UI.
Ramkumar: For this scenario, the user needs to be registered/onboarded already. This UX switching mechanism validates that the user is valid using JWT/token (option 1). We can validate the application should have access using the third option. Ramkumar to update UX switching to prioritize the first and third option (possibly move the 3rd option above the iframe option) and document that both OIDC and IM can be used together. Uwe: Is the ID BB used for both foundational ID as well as functional ID in this workflow? Ramkumar: The application should hold the functional ID and roles for a particular user Vasil: How does a BB understand what role a particular user has when making a call? Ramkumar: The application will control the access to the various BBs Vasil: Existing applications will already have roles and permissions defined and access control. We should not fully open up access to an external application. Ramkumar: A BB is not an application, but should expose the API layer. An application like DIIA will have to separate out different BB functionalities as APIs Vasil: SSO usually means that each different application/component will manage the roles/permissions that the user will have. Ramkumar: may need to revisit the overall portal concept that provides access to different applications/services | |
Infrastructure APIs | 20 minutes |
| |||
Mutual auth of ID/Registration | 15 minutes | When going through a redirection, how do we provide authentication for both ID and Registration | |||
Capabilities | 15 minutes | How should we define Capabilities? Document from Jaume: https://docs.google.com/presentation/d/11zg0PQQKbpWFxwAc_oK12iM83ax8hUpBqlJHwB-kLGk/edit#slide=id.g1ab9444641b_0_218 In Sandbox, if we want to run multiple instances of a BB (giving user ability to swap out BBs), we need to have a mechanism to map the IP/URL/endpoints of the new BB. What is needed for a ‘general GovStack’ implementation vs what is specific to Sandbox. Conversation started last year but was deprioritized: administrative APIs and audit APIs What APIs should be a part of BB specifications?
Do we need an authorize endpoint that will allow a user to access a BB (authorize will return a token for subsequent calls)? Or just a single client key for an application to use for all access? | |||
Next steps/AOB | 5 minutes | What should we prioritize?
|
...
Ramkumar to connect with Hani/Nico on infra requirements
Ramkumar /Steve to meet with Vasilto update UX switching document
Arch team members to review UX Switching document: UX Switching
...