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)

Management of UX switching

PSRAMKUMAR

Steve Conrad

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.

• 3 options are outlined - should we make a recommendation as to which approach is preferred?

  • OIDC is called out in the cross-BB auth as well

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.

1. Registration Building Block UI switching to PayBB for capturing Secure Financial Data.

2. During a Voucher redemption PayBB UI redirecting to IDBB (e-signet)

   1. https://govstack.gitbook.io/bb-identity/8-apis-and-services#authorize

 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

Steve Conrad

Vasil Kolev

20 minutes

• 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?

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

Next steps/AOB

Steve Conrad

5 minutes

What should we prioritize?

• 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