remove job arguments from authenticate
Feature Description
Authenticate requires a job name and mode version as parameters to identify whether a speed test is needed or not. This should however be done in a separate step.
Authentication with PyGrid
Method in worker library:
const worker = new syft({
url: 'https://localhost:3000',
auth_token: MY_AUTH_TOKEN
});
HTTP endpoint: POST /federated/authenticate
Socket "type": federated/authenticate
Request data:
{
"auth_token": "MY_AUTH_TOKEN"
}
Note that auth_token supplied above is an optional argument depending on the setup of PyGrid.
This endpoint is where the worker library (syft.js, KotlinSyft, or SwiftSyft) is attempting to authenticate as a worker with PyGrid.
In order to guarantee the identity of a worker, it's important to have some sort of authentication workflow present. While this isn't strictly required, it will prove an important mechanism in our federated learning workflow for preventing a variety of attacks, most notably a "Sybil attack". This would happen when a worker could generate multiple versions of themself, thus steering all model training to be done by the same worker on the same data, but with unique "worker id's" - which would overfit the model. To prevent this, we strongly suggest that every deployment of PyGrid's FL system implement some sort of oAuth 2.0 protocol.
In this circumstance, a worker would be logged in to their application via oAuth and would be given an authentication token with which to make secure web requests inside the app. Assuming that PyGrid has also been set up to include this same oAuth mechanism, a worker could forward this auth_token to PyGrid, which then validates that token as an actual user with the same oAuth provider. It's important to do this because it avoids putting the responsibility of having to incorporate our own authentication system with PyGrid, and instead farms this responsibility out to a third-party system.
In the event that the administrator of the PyGrid gateway does not want to add oAuth support, or there is no login capability within the web or mobile app the worker is running on, then this authentication process is skipped and a worker_id is assigned. This is insecure and open to attacks - it's not suggested, but is required as part of our system.
There are three possible responses, one success and two error responses:
Success - triggered when there is no oAuth flow required by PyGrid OR when there is a required oAuth flow in PyGrid and the auth_token sent by the worker validates the existence of that user by a third-party
{
"worker_id": "ID OF THE WORKER"
}
Error - triggered when there is an oAuth flow required by PyGrid and no auth_token is sent
{
"error": "Authentication is required, please pass an 'auth_token'."
}
Error - triggered, when there is an oAuth flow required by PyGrid and the auth_token that was sent, is invalid
{
"error": "The 'auth_token' that you passed is invalid."
}
The success response will include a worker_id which should be cached for long-term use. This will be passed with all subsequent calls to PyGrid.
SpeedTest status
Method in worker library:
const worker = requires_speed_test({
url: 'https://localhost:3000',
worker_id: "LONG_HASH_VALUE",
model_name: "name",
model_versiion: "version"
});
HTTP endpoint: POST /model_centric/requires_speed_test
Socket "type": model_centric/requires_speed_test
Request data:
{
"worker_id": "LONG_HASH_VALUE",
"model_name": "name",
"model_version": "version"
}
Is your feature request related to a problem?
This API allows pygrid to have multiple jobs per worker (as all the jobs have the same worker id)
Additional Context
part of multiple jobs per worker OpenMined/PyGrid#685 OpenMined/PyGrid#445
@vkkhare will we use this ticket to brainstorm worker-level auth? If so, could you update summary, please?
0.2 is no longer supported.