Agenda

Presenter

Duration

Discussion

Authentication and Cross-BB Authorization

Steve Conrad

PSRAMKUMAR

40 minutes

For a Use Case, how does user authenticate and how is authorization passed between BBs?

• This should be documented in non-functional requirements

Authentication

• Is authentication provided by ID BB? What is returned - a JWT?

Cross-BB Authorization

• How can we make a request from one BB to another and pass authorization? How does a BB know this is a valid request?

• How are we thinking about IAM/RBAC? How do we differentiate between different users and what they can do?

• How does this work with IM? Without IM?

• Ensure that adaptors pass authorization/tokens through?

Ramkumar - background on previous conversations:

• 2 distinct topics - one is around user permissions and one around bb-to-bb permissions

  • IM can manage those bb-to-bb permissions, but doesn’t account for user permissions

  • There is a difference between ‘foundational' registration and registration into a specific program/use case

  • ID building block provides a token that corresponds to a foundational ID, as well as data about a specific program that they are authorized to access

  • Additional role-based access needs to be provided - by specific BBs

  • There is a separate JWT token that is passed between services

Questions - where are roles configured and assigned for users? How do we align these 2 different tokens?

Aare - abstract conversation is different than what happens in reality. Services are offered by a specific organization.

• Estonia - IM is the gateway for an organization. It is not concerned with individual users.

• Individual roles/permissions are stored in an organization’s registry - stored in a token

• Organizations have strict hierarchies with specific roles - this needs to be managed within the org context

• 4 different scenarios:

  • Individual requests services on their own behalf - just need foundational ID

  • Public officer is doing their work - roles assigned within that organization

  • Individual acting on behalf of company - need commercial registry

  • Individual who has consent from outside organization

• We shouldn’t need authentication to communicate between BBs - IM should do that

Authorization is based on context, just just role - it can be dynamic (ie. a doctor may have limited access to a patient record or an auditor can have limited access to an individual’s tax record)

Policies can be used to manually enable functionality

There are different scenarios - co-located services (behind the same IM) as well as across different organizations (through IM)

Aleksander - IM sits between applications, not BBs. Apps are composed of one or more BBs (co-located). An authorization mechanism is needed for an application, and another is needed for cross-application/cross-organization communication.

• Authorization should be managed by the application, as well as roles - OpenID connect? Should we choose a standard mechanism?

Question - should we have a standard authorization and/or API security mechanism that we define? Is this the token that is provided by ID BB?

Question - should an application have its own authorization mechanism, or should it always use ID BB? Is there a ‘local’/functional ID? How does it tie to foundational ID?

• Roles should be tied to functional IDs

• Does ID BB handle both foundational and functional ID?

Uwe - we don’t have a definition of an ‘application’ within GovStack

Aare - also need a definition for ‘organization’

Ramkumar - how does consent fit in? Dynamic permissions

Sreepathy - Is IM used to protect between 2 different applications? Applications may have multiple BBs

• Will every application have an API gateway to route requests from a client to ID BB and to other BBs?

• Different applications may have different mechanisms, but there must be some way/token/etc to pass info between BBs - some may be RBAC, others may have different policies

Next steps: Steve to consolidate into a first rough draft to present next week

PubSub/Rooms

Aleksander Reitsakas

15 minutes

How should we define Rooms – are they oriented around Event Types or more broadly?

Push to next week

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