Page Comparison

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.

• Proposed to provide emulators for key building blocks to support easier delivery. This would allow Basic/foundational framework to be in place for auth

• Create a template application, which provides SSO, user registrations, IAM, auth services. These services are available for other BBs to consume out of the box

  • Configure helm charts/Kubernetes cluster to deliver this on demand in AWS

  • Deployment would have ‘one of everything’ available to users to start building on top of

  • This could be the core of a ‘government portal’

Aare: being able to deliver a reference implementation would be helpful - without real software, not much value

• Need to develop a clear understanding of authorization - both in public sector and private sector

• Need to build specs that address the complexity of real-world scenarios

Ramkumar: need to support multiple architectures - either a central portal, or a set of separate services with a common backend/auth framework

• Where to put RBAC/IAM services - centralized or per application?

Vasil: From a citizen point of view, there should be a single credential that I use for all services

• Need a mechanism to provide authorization for users for specific features

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)

• Authorization should happen at the service level (services may use multiple BBs)

Trev: Need to account for not just individual users or organizations, but also for government officers/workers.

• Central authentication makes sense in many cases, but authorization will likely need to be per application/service

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.

• Store users, store features, store computations for permissions for different services

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?

• Can be used to define what permissions/roles to give to a user

• Develop a standard service/API for permission computation

Ramkumar: IM already provides this across applications/organizations. But we don’t have this functionality for specific users

Potential next steps:

• Walk through a few specific use cases/scenarios to outline/document what authorization needs are

  • Develop design patterns to manage those scenarios

• Design/Develop reference application with central authentication, decentralized authorization

  • Who participates? What is the process?

• Draft at least one approach
  

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?

• Call out that in some cases, central authorization/authentication is desirable, in other cases we don’t want that.

Additional Notes:

• 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