Upgrading crewjam/saml from v0.3.0 to v0.4.5

[gchamon]

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 pure net/http. As we use julienschmidt/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 handlers ssoHandler and samlHandler. ssoHandler, in turn handles specifically the authentication flow. Therefore, we must reimplement it using samlSP.HandleStartAuthFlow. The code in it is almost the same as in samlSP.RequreAccount. The difference is that samlSP. ServeHTTP is reserved for samlHandler.

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 to JWTSessionClaims. Without it, we would be left with sessionWithAttributes.GetAttributes which in turn only returns the contents of attrs of the JWT Token. This cast restores the access to what was previously retrieved with token.StandardClaims. Now we access it with jwtSessionClaim directly, which is the complete decoded jwt token.

Changes

• Updated crewjam/saml from v0.3.0 -> v0.4.5
• Applied necessary refactor to account for breaking changes.

Testing

• Build and start a fresh container
• Log in with an admin account
• Create a testing account on jumpcloud
• Configure SSO as explained in the documentation
• Log in with the created user in jumpcloud