Agenda

Presenter

Duration

Discussion

ID deep dive

@Steve Conrad

@PSRAMKUMAR

@smita.selot

40 minutes

We need to answer core questions about ID - whether it is only foundational, or also functional ID.

How do we manage IAM/RBAC? Single Sign On?

How do we handle functional IDs

Ensure that we are aligned with Sandbox team

Note: Information about authorization has been documented here: https://app.gitbook.com/o/pxmRWOPoaU8fUAbbcrus/s/39QVhd0jD6S29Isr7KGF/security-requirements/7-auth-services

Vasil: How does the Sandbox retrieve a foundational ID? Does the user provide their foundational ID number when registering? Or does a BB need to search/filter for a foundational ID? How do we accurately link/map between a logged in user and their foundational ID?

Smita: ID BB has existing APIs for enrollment. Links provided to Sandbox team. Relating to authorization, OIDC supports this, but is not currently a part of the ID BB. Can use something like Keycloak for auth.

Ramkumar: Step 1 is to register/enroll and get a foundational ID (for GovStack?). For a particular use case, user will register into that use case/program.

Smita: Guidance for this functionality is provided in the ID white paper written by Smita. The ID BB should provide a ‘translation’/account mapper that can be used to access other BBs (like Payments)

Trev: We need to ensure that any functionality that is required is actually defined in the spec. ID as we are talking about it here is more functional ID, and not foundational ID as generally understood. There are questions/concerns with the ‘authorizing application or use case’ scenario.

Steve: Need to address the central portal question - and whether this is required

Smita: Account mapping and other workflows still need to be added to the ID BB - but don’t have resources to do this at the moment. ID BB spec (based around MOSIP) does manage foundational ID.

Vasil: In any third party auth, the authorizing entity has info on a person and shares it with the requesting app. Each application should not have it’s own functional ID that maps back to the foundational ID. There is missing functionality in the specs (IAM, Mapping, SSO) that keeps us from being able to build real implementations.

Vasil: There should be only one login for all GovStack services.

This guidance needs to be documented somewhere in GovStack - white paper from Smita, etc.

PAERA Update

@Aare Laponin @PSRAMKUMAR

10 minutes

Update on changes to PAERA document and progress/next steps

Working draft:

https://onedrive.live.com/Edit.aspx?resid=7B252BA6CB083436!9551&wdPid=5887d621&authkey=!AC4bdYfdJIaKi8M

Ready for review and comment (Sections 1-3). Steve and Wes to review.

Need to decide where this lives for the upcoming release (GitBook, linked, PDF)?

• Put summary/overview in GitBook (in cross-cutting section) and then link out to full content (ie. PDF in GitHub)?

Prioritize future topics

@Steve Conrad

10 minutes

• GovStack and central portal question

• Capabilities and Service blocks - develop a template

• Adaptor building block - what is it? Is it needed?

• Articulating different levels of building blocks - foundational, functional, application.

Future topic - Fall 2023

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