-
Notifications
You must be signed in to change notification settings - Fork 48
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
(PXP-6339): RAS visa validation #933
Conversation
The style in this PR agrees with This formatting comment was generated automatically by a script in uc-cdis/wool. |
Pull Request Test Coverage Report for Build 11239
💛 - Coveralls |
c774b71
to
5ff476c
Compare
) | ||
continue # Not raise: If visa malformed, does not make sense to retry | ||
|
||
# See if pkey is in cronjob cache; if not, update cache. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note: Most of this code is very similar to the code from this recent authutils commit.
The authutils utils rely on keeping a public key cache in the flask app context, and the cronjob runs without one, so this code is here.
The plan is to implement a more persistent cache than this, so here I have taken the simplest and dumbest approach of just repeating much of the authutils code instead of refactoring authutils.
decoded_visa = validate_jwt( | ||
encoded_visa, | ||
public_key, | ||
# Embedded token must not contain aud claim |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is this based on the AAI spec?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yup! https://github.com/ga4gh/data-security/blob/master/AAI/AAIConnectProfile.md#embedded-access-token-format The payload claims MUST NOT include aud.
(Edit: permalink )
@@ -134,7 +134,7 @@ def test_update_visa_token( | |||
}, | |||
} | |||
|
|||
headers = {"kid": kid_2} | |||
headers = {"kid": kid} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note: I couldn't tell if there was a particular reason to be using a different key for the second visa, so figured I'd just use the same one to reduce noise/readability and make it more evident what is being tested. But if I simply missed something, I can definitely switch this back.
Same goes for the rest of this file!
fence/config-default.yaml
Outdated
@@ -824,6 +824,9 @@ ASSUME_ROLE_CACHE_SECONDS: 1800 | |||
|
|||
# RAS refresh_tokens expire in 15 days | |||
RAS_REFRESH_EXPIRATION: 1296000 | |||
# List of JWT issuers from which Fence will accept GA4GH visas | |||
GA4GH_VISA_ISSUER_WHITELIST: [] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can this populate itself with the "issuers" from well-known for configured logins on startup? might be overkill, but would be really convenient to not have to keep this up to date. Or, maybe even just adding the RAS issuer and ourselves into the default 🤷♂️ ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Line 18 in d75257e
def post_process(self): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh I figured more explicit was better for a visa whitelist but I can look into this--do you mean like, on app startup, maybe during the client init, hit all of the configured idps' well-known endpoints and add(?) the "issuer" values to this config value?
(Edit: 🤦♂️ only saw the first comment, GH didn't refresh with the second)(I'm slightly leaning towards the second approach, partly because the first approach might become sort of an anti-feature if we ever want to exclude an idp from being a visa issuer, partly just because KISS)
Otherwise if taking the second approach--that sounds fine; would you use stsstg
or prod RAS or both?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed, very good points. For the second approach, we should probably add both? whatever issuers RAS has for staging and prod
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh! Minor suggestion, I've been trying to move towards "ALLOWLIST" vs "WHITELIST" but up to you
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Word! Thank you 🙏
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
see comments
b4d02cf
to
a868796
Compare
Jira Ticket: PXP-6339
minor version bump to 5.2.0
New Features
Breaking Changes
Bug Fixes
Improvements
Dependency updates
Deployment changes