Versions Compared

Old Version 4

changes.mady.by.user Steve Conrad

Saved on

compared with

New Version 5

changes.mady.by.user Steve Conrad

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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

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

Aare - also need a definition for ‘organization’

PubSub/Rooms

Aleksander Reitsakas

15 minutes

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

Next steps/AOB

Steve Conrad

5 minutes

What should we prioritize?

...