FASP Collaboration on Passports

Chairs: Brian O’Connor, Max Barkley, Ian Fore

​

Presenters: Nicolas Malfroy-Camine

ga4gh.org

1.0 Background: The Reality Today

Analysis

Results

Biomedical

Platform UI

1

2

3

4

How do we authenticate for API access?

ga4gh.org

Next Step

We want this flexibility

(and more)

​

This is harder to do if each arrow uses different authorization

Datasets

Analysis

Results

Workflow

API

1

2

3

4

Standard

Client

ga4gh.org

Authorization in DRS

DRS 1.2 recommends OAuth2 Bearer tokens or a “passport” attribute in the request payload.

​

But we know there are still challenges around standardized authorization:

• How you discover an authorization server or passport broker?
• When does an interactive user login happen in a system?
• Other thorny issues around delegating authorization

​

​

It’s good that we started off simple! But now there are use cases that require answering these questions in an automated way

ga4gh.org

DRS-Passport Use Case

DRS server objects from multiple datasets

​

Datasets have different authorities granting access

​

Need a passport with particular visas signed by particular authorities

​

Possibly also from particular broker

Passport Broker 1

Authority 1

Authority 2

Passport Broker 2

Authority 3

Where do I get a Passport?

ga4gh.org

Discovery-Passport Use Case

There are probably some unique challenges for integrating with some discovery APIs

​

But likely many of the problems will be shared by any GA4GH API that integrates with Passport

Passport Broker 1

Authority 1

Authority 2

Passport Broker 2

Authority 3

Where do I get a Passport?

ga4gh.org

2.0 Framing

• TLDR Problem
• Several multi-tenant DRS implementation exist today (e.g. Cavatica, Terra Data Repository, etc.)
• Different sets of DRS addressable files are grouped in each tenant
• Each tenant has different auth capabilities - though all DRS requests require some form of authorization
• Some but not all tenants are configured to accept passport-based authorization
• TLDR Proposal
• Add an anonymous HTTP OPTIONS endpoint for the GetObject endpoint
• Endpoint returns information that describes what authorization methods are supported for the GetObject endpoint
• GetObject response adds a field to tell users how to authenticate for GetAccessUrl endpoint
• Pull Request and related conversation is here
• Issue with related conversation is here

ga4gh.org

3.0 DRS & Passports

• Do developments in Passports enable Passport-based authorization to DRS?
• Identification of short-term needs
• Long-term vision of work order tokens

​

​

ga4gh.org

3.0 DRS & Passports

Miro Board: https://miro.com/app/board/uXjVO6oM3RQ=/

​

​

​

ga4gh.org

Authorizations in workflow

1. How do I determine where the files are that I need to compute on?

​

2. Where can I get the compute done? (influenced by cost and convenience on the user end, and by download/transfer restrictions).

​

3. How is my authorization from step 1 passed to the place I have determined in step 2?

​

​

• How is the authorization to do the compute passed to where I have determined in step 2.

​

​

5. How is authorization to save and access the objects that result from the compute dealt with?

​

File

Storage

Compute

access

Dataset

access

Next Steps?

It seems to me that the group looking at DRS and Passport have been looking intensively at step 3. Are their assumptions for 3 likely to be the common reality?

Unless one considers 1 and 2 one can’t tell

We should be asking what the common reality is

The case where the compute has to be sent to the data seems quite common

That changes the authorization scenario

The compute platform has been chosen because it has access to the data

How does that change the role of the passport?

​

Given that the group has spent several cycles in the depths of 3 my suggestion is that we 

1. Pull back to the big picture
2. Understand how what has been done helps the big picture
3. Think what else is needed for the big picture, and any perspective that throws on #3.

Or we could spend more time in the detail of #3.

Key to icons and colors

Data Access Committee

IRB

Subject

dbGaP

Data Commons Framework (Gen3)

Workflow Platform

User

Visa/Authorization Issuer

Broker

File

access

Visa

Authorizations needed in a workflow

dbGaP

Data Commons Framework (Gen3)

User

Password�login

Passport

(contains authz for dataset)

Access

Authorized based

Workflow platform

Passport

Files

Storage

auth

Dataset

auth

Dataset

auth

Compute

auth

Dataset

auth

Workflow platform

Workflow platform

Password�login

Compute

auth

Compute

auth

4.0 Discovery and DRS & Passports

Auth granularity in Data Connect

Alignment with DRS auth granularity

Authorization in Data Connect

See the documentation

Relevance of Passport to Authorization in Data Connect

How Discovery changes the landscape of the question

Selection object functionality

ga4gh.org

Reserve slides

ga4gh.org

Pre passport – Authorization for APIs

dbGaP

Data Commons Framework (Gen3)

User

Authorizations for data sets

“White Lists”

Password�login

(RAS)

API�key

(json)

API�key

(json)

Access

token

Access

token

Graphical User Interface

Authorization API

Access

Authorization based

Files

With passport

dbGaP

Data Commons Framework (Gen3)

User

Password�login

(RAS)

Visas

(contains authz for dataset)

​

Passport

(contains authz for dataset)

Graphical User Interface

Access

Authorization based

Files

Dataset

auth

Dataset

auth

With passport (third party use of visa)

dbGaP

Data Commons Framework (Gen3)

User

Password�login

(RAS)

Visa

(contains authz for dataset)

​

Passport

(contains authz for dataset)

Access

Authorized based

Workflow platform

Visa

Files

Dataset

auth

Dataset

auth

Dataset

auth