feat: add support for saml encrypted assertions #1752
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
hf
force-pushed
the
hf/saml-encrypted-assertions
branch
from
9f90a99 to
b614d68
Compare
hf
changed the title
Pull Request Test Coverage Report for Build 10663458667Details
💛 - Coveralls |
J0
reviewed
Sep 2, 2024
J0
approved these changes
Sep 2, 2024
hf
force-pushed
the
hf/saml-encrypted-assertions
branch
from
b614d68 to
5aa39cb
Compare
hf
pushed a commit
that referenced
this pull request
Sep 2, 2024
🤖 I have created a release *beep* *boop* --- ## [2.160.0](v2.159.2...v2.160.0) (2024-09-02) ### Features * add authorized email address support ([#1757](#1757)) ([f3a28d1](f3a28d1)) * add option to disable magic links ([#1756](#1756)) ([2ad0737](2ad0737)) * add support for saml encrypted assertions ([#1752](#1752)) ([c5480ef](c5480ef)) ### Bug Fixes * apply shared limiters before email / sms is sent ([#1748](#1748)) ([bf276ab](bf276ab)) * simplify WaitForCleanup ([#1747](#1747)) ([0084625](0084625)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please). Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
uxodb
pushed a commit
to uxodb/auth
that referenced
this pull request
Nov 13, 2024
By setting the `GOTRUE_SAML_ALLOW_ENCRYPTED_ASSERTIONS` to `true` the SAML private key will be advertised as usable with encryption too. Encrypted assertions are fairly rare these days because: - They make it very hard to debug what's going on. - HTTPS is the default protocol on the web for over 10 years, including in intranets. **Why not use a separate key?** The underlying library [does not support it](https://pkg.go.dev/github.com/crewjam/saml@v0.4.14/samlsp#Options) and there are no significant cryptological issues using the same RSA key for signatures and encryption, especially in a limited setting like this.
uxodb
pushed a commit
to uxodb/auth
that referenced
this pull request
Nov 13, 2024
🤖 I have created a release *beep* *boop* --- ## [2.160.0](supabase/auth@v2.159.2...v2.160.0) (2024-09-02) ### Features * add authorized email address support ([supabase#1757](supabase#1757)) ([f3a28d1](supabase@f3a28d1)) * add option to disable magic links ([supabase#1756](supabase#1756)) ([2ad0737](supabase@2ad0737)) * add support for saml encrypted assertions ([supabase#1752](supabase#1752)) ([c5480ef](supabase@c5480ef)) ### Bug Fixes * apply shared limiters before email / sms is sent ([supabase#1748](supabase#1748)) ([bf276ab](supabase@bf276ab)) * simplify WaitForCleanup ([supabase#1747](supabase#1747)) ([0084625](supabase@0084625)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please). Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
LashaJini
pushed a commit
to LashaJini/auth
that referenced
this pull request
Nov 13, 2024
By setting the `GOTRUE_SAML_ALLOW_ENCRYPTED_ASSERTIONS` to `true` the SAML private key will be advertised as usable with encryption too. Encrypted assertions are fairly rare these days because: - They make it very hard to debug what's going on. - HTTPS is the default protocol on the web for over 10 years, including in intranets. **Why not use a separate key?** The underlying library [does not support it](https://pkg.go.dev/github.com/crewjam/saml@v0.4.14/samlsp#Options) and there are no significant cryptological issues using the same RSA key for signatures and encryption, especially in a limited setting like this.
LashaJini
pushed a commit
to LashaJini/auth
that referenced
this pull request
Nov 13, 2024
🤖 I have created a release *beep* *boop* --- ## [2.160.0](supabase/auth@v2.159.2...v2.160.0) (2024-09-02) ### Features * add authorized email address support ([supabase#1757](supabase#1757)) ([f3a28d1](supabase@f3a28d1)) * add option to disable magic links ([supabase#1756](supabase#1756)) ([2ad0737](supabase@2ad0737)) * add support for saml encrypted assertions ([supabase#1752](supabase#1752)) ([c5480ef](supabase@c5480ef)) ### Bug Fixes * apply shared limiters before email / sms is sent ([supabase#1748](supabase#1748)) ([bf276ab](supabase@bf276ab)) * simplify WaitForCleanup ([supabase#1747](supabase#1747)) ([0084625](supabase@0084625)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please). Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
By setting the
GOTRUE_SAML_ALLOW_ENCRYPTED_ASSERTIONStotruethe SAML private key will be advertised as usable with encryption too.Encrypted assertions are fairly rare these days because:
Why not use a separate key?
The underlying library does not support it and there are no significant cryptological issues using the same RSA key for signatures and encryption, especially in a limited setting like this.