Refactor API Auth to support non X.509 identifiers #368
Conversation
Wait a minute... the test passed... ah, you can throw as many arguement to a function as you like... Well I'll edit the tests anyway... |
gregcorbett
force-pushed
the
typeless_API_Authentication
branch
from
7593956 to
a7cd245
Compare
Admins should probably be able to access the API by virtue of being admins. The message when an unauthorized request comes in should be changed. If it's a robot request it's not apporpriate to return "get a role", it should be along the lines of "a human should add your robot API identifier". This will probably be simplier if we remove the check the user ID check. |
Hmm... maybe not... we were vague and said we would "restrict the access to personal data to users with roles at sites or registered robots", no distinctions for access personal data in the portal or the API... |
gregcorbett
force-pushed
the
typeless_API_Authentication
branch
from
a7cd245 to
a8dd918
Compare
gregcorbett
force-pushed
the
typeless_API_Authentication
branch
3 times, most recently
from
d15bed2 to
2b7e112
Compare
|
I've rebased this over the conflict, to avoid a 3rd pass of #324, I will merge that one first. |
|
Converted to draft until #324 is merged. |
- not just X.509, we want to allow OIDC based access to the API. - change test cases appropriately - generalise language used, i.e. identifiers not DNs.
gregcorbett
force-pushed
the
typeless_API_Authentication
branch
from
1d12bd4 to
fd1aa88
Compare
|
Rebased to fix the conflicts. |
We want the API to allow access based on OIDC Identifiers in the future., so need to generalise getAPIAuthentication.
Still a work in progress, I should rename theauthByCertmethod at least and fix the tests.I also wonder wether we should remove this check, maybe API access should be a function of the API Identifiers alone - not something a user can browse by virtue of their roles?