December 15, 2023 Architecture Team Meeting Notes
Attendees
@Vasil Kolev
@Aare Laponin
@Steve Conrad
@PSRAMKUMAR
@Trev Harmon
Apologies
Agenda | Presenter | Duration | Discussion |
Follow up on ID/Auth questions | @Steve Conrad @PSRAMKUMAR @smita.selot @Vasil Kolev | 30 minutes | Vasil: Unable to find complete flow for authentication and authorization.
Aare: being able to deliver a reference implementation would be helpful - without real software, not much value
Ramkumar: need to support multiple architectures - either a central portal, or a set of separate services with a common backend/auth framework
Vasil: From a citizen point of view, there should be a single credential that I use for all services
Ramkumar: IM provides many of these authorization services (between applications) - at an organizational, not user, level Current guidance puts authentication as the responsibility of each application. However, need to provide alternatives Aare: Building blocks are atomic components and should not deal with authorization. (The current auth document supports this approach)
Trev: Need to account for not just individual users or organizations, but also for government officers/workers.
Ramkumar: need to support authorization that is time-bound as well as for subsets of data within a system. These should be managed by the application itself. Vasil: The authorization rules may be complex, but should be offered as a simple service. Provide user context to authorization and it will return true/false. Can layer organization policies with user policies for all possible government services/applications.
Steve: We could develop an authorization BB that offers these services - has a standard footprint, but could be implemented in each application. Trev: managing authorization for all services in one place would be incredibly complex. Agencies want to be able to control their data and access to it. Ramkumar: Federated administration would require agreements between organizations - very difficult Vasil: We need to provide a standardized API to report available features/services provided by the BB - service discovery registry?
Ramkumar: IM already provides this across applications/organizations. But we don’t have this functionality for specific users
Potential next steps:
Vasil to develop a document that outlines the core questions/implementation concerns that you have. From there, could you work with Smita and Trev to outline the flow/process that is needed so that we can identify any gaps in the BB specs or documentation. Propose to use this document as a baseline - ensure that it accurately frames the issues: Authentication and Cross-BB Authorization Question: Should we frame multiple approaches or design patterns?
Additional Notes:
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?
|
|
|
|
|
Action Items
Ramkumar to connect with Hani/Nico on infra requirements
Additional Future Topics
SSO vs. central portal - can we provide guidance for both?
Define a standard set of APIs that are needed for any BB to indicate that they are running, configured and ready to use in the sandbox (or test harness). Do we need a BB registry?
Decoupling BBs into smaller pieces, as well as talking about an approach for existing products which span multiple BBs
How to articulate the different levels/scopes of building blocks - foundational/DPI, functional, and possibly application (things like eMarketplace). This should be clearly articulated in GovStack documentation. Also articulate how service blocks fit in to this paradigm.
Identify BBs that are missing/needed and develop plan to address those new BBs - get feedback from Egypt and Kenya meetings
Questions about IM from Egypt deep dive
Exchanging large amounts of data through IM (MRIs, etc)
Real-time streaming
Taylor: we'd likely need to find some experts on open-source video chat apps, see how Self-Hosting Guide - Debian/Ubuntu server | Jitsi Meet fits into the IM, and ALSO talk about things like email clients and servers
Defining user personas and journeys - outputs would be overall messaging, providing high-level guidance. How does GovStack work to deliver value.
Providing guidance on specific questions coming from country engagement
Example implementations - having BB groups work on them.