Upgrading crewjam/saml from v0.3.0 to v0.4.5 #6
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.
also in subspacecommunity#169
Background
There was a severe vulnerability in crewjam/saml v0.3.0 that allowed bypassing SAML SSO. Updating to v0.4.5 would solve the issue.
The way SAML works in subspace is to basically split the handler procedure encoded in
samlSP.RequreAccount
. This function is supposed to make it easy to use SAML SSO, however it requires the use of purenet/http
. As we usejulienschmidt/httprouter
. We have to handle it ourselves.The way this is done is basically split
samlSP.RequreAccount
in two. The first part is implemented in the two handlersssoHandler
andsamlHandler
.ssoHandler
, in turn handles specifically the authentication flow. Therefore, we must reimplement it usingsamlSP.HandleStartAuthFlow
. The code in it is almost the same as insamlSP.RequreAccount
. The difference is thatsamlSP. ServeHTTP
is reserved forsamlHandler
.The other modification was the refactoring of the procedure that extracts the subject name from the JWT Token. This changed quite drastically in 0.4.x. This version did away with the convenient function
GetAuthorizationToken
. Now we have to extract the session from the conext and use type assertion to cast it toJWTSessionClaims
. Without it, we would be left withsessionWithAttributes.GetAttributes
which in turn only returns the contents ofattrs
of the JWT Token. This cast restores the access to what was previously retrieved withtoken.StandardClaims
. Now we access it withjwtSessionClaim
directly, which is the complete decoded jwt token.Changes
Testing