-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
feat: add support for trust grants that can issue tokens for any subject #3012
feat: add support for trust grants that can issue tokens for any subject #3012
Conversation
I've seen that the documentation is now in another repository, and I'm not sure if I should update the docs now or wait for this PR to be merged in case there's any changes. |
Codecov Report
@@ Coverage Diff @@
## master #3012 +/- ##
==========================================
+ Coverage 79.40% 79.60% +0.19%
==========================================
Files 112 112
Lines 7890 7957 +67
==========================================
+ Hits 6265 6334 +69
+ Misses 1223 1222 -1
+ Partials 402 401 -1
Continue to review full report at Codecov.
|
Hi @aeneasr, I'm not sure why e2e tests are failing. I just ran them locally and everything seems to be working fine. The error it's throwing is
But that string has been deleted from the code, it's almost as if it was running on an older binary. Could it be related to the |
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.
Thank you! Sorry for the late review! This looks really good. The one thing I would like to change is that we store this "any" relationship explicitly in the database. An empty string could get into the DB with a number of things (e.g. broken migrations, rollbacks, ...) and we really need to prevent that this feature is enabled "on accident". Therefore, please add a SQL column to store this state :)
Thanks @jagobagascon for your time & effort 👏 👏 |
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.
Thank you so much! This looks great!
@grantzvolsky please take note that this PR introduces a schema change. We'll squash merge it so that it's just one commit which hopefully will make it easier to rebase. |
Previously, a trust relationship had to be setup for every subject before the issuer could sign a JWT token for it. This change will allow setting up token services that can issue tokens with any value in the subject field. Closes #2930
I added the tests as requested. |
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.
Thank you so much for your great work @jagobagascon ! I added a small test, and now this is ready to be merged! But, one last ask - could you please update the document https://github.com/ory/docs/edit/master/docs/hydra/guides/oauth2-grant-type-jwt-bearer.mdx to include your changes so that others know about this feature? Thank you so much!
Thank you @aeneasr! I updated the docs as requested: ory/docs#764 |
Added documentation describing how to setup trust relationships that allow signing tokens for any subject. This is a complement to ory/hydra#3012 and should be merged after linked PR.
🥳 |
Hello @jagobagascon |
Oh thanks for being so honest @jagobagascon, for some reason this showed up as your first PR 😅. |
Great job to all!! Cannot wait to see this working in prod! 🎉 🎉 |
Previously, a trust relationship had to be setup for every subject
before the issuer could sign a JWT token for it. This change will allow
setting up token services that can issue tokens with any value in the
subject field.
Related issue(s)
#2930
Checklist
introduces a new feature.
contributing code guidelines.
vulnerability. If this pull request addresses a security. vulnerability, I
confirm that I got green light (please contact
[email protected]) from the maintainers to push
the changes.
works.
Implementation details
REST api
This PR adds a new field to the trust creation request called
allow_any_subject
, and as long as this flag is set to false (or unset), the trust relationship creation service will behave just like it did before this change: thesubject
field will be required.When
allow_any_subject
is set to true, then the issuer will be allowed to sign tokens for any subject. Also, as a safety measure, thesubject
field MUST be empty (or unset), otherwise the validation will fail. This is done to avoid creating an issuer that can sign tokens for any subject by mistake.Database
When
allow_any_subject
is set to true, then the subject field is stored with an empty string value in the database. This allows us to keep (and benefit from) theUNIQUE
constraint that thehydra_oauth2_trusted_jwt_bearer_issuer
table has, requires no changes to the database schema and makes the database query used to find an issuer's public key really simple:subject = ? or subject = ''
.