Skip to content
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

SAML2 HTTP-Redirect: Missing Signature and SigAlg parameters in SAMLRequest Url (AuthNRequest) #7711

Closed
berschmoe opened this issue Dec 9, 2019 · 9 comments
Assignees
Labels
in: saml2 An issue in SAML2 modules type: enhancement A general enhancement
Milestone

Comments

@berschmoe
Copy link

Summary

I'm currently update to Spring Security 5.2.1. and start to use the integrated SAML 2 implementation.

During the integration I noticed that my identity provider (Keycloak) does not accept the signed AuthNRequest.

The reason is that SAML 2 expects different signature for different bindings (POST or Redirect) - at least that's how I understand it.

I checked the Spring Security SAML Extension online demo (https://saml-federation.appspot.com) and here it works as expected.

GET Parameters:
SAMLRequest: fZLLbsIwEEV/JfI...
SigAlg: http://www.w3.org/2000/09/xmldsig#rsa-sha1
Signature: LAB/NahduGHr5ew...

and a none signed AuthNRequest

<saml2p:AuthnRequest xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol"
                     AssertionConsumerServiceURL="https://saml-federation.appspot.com:443/saml/SSO"
                     Destination="https://idp.ssocircle.com:443/sso/SSORedirect/metaAlias/ssocircle"
                     [...]
                     >
    <saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">saml-federation.appspot.com</saml2:Issuer>
</saml2p:AuthnRequest>

Currently the URL is created while using createSamlRequestRedirectUrl in Saml2WebSsoAuthenticationRequestFilter and these parameters aren't set.

private String createSamlRequestRedirectUrl(HttpServletRequest request, RelyingPartyRegistration relyingParty) {
	[...]
	String redirect = UriComponentsBuilder
			.fromUriString(relyingParty.getIdpWebSsoUrl())
			.queryParam("SAMLRequest", UriUtils.encode(encoded, StandardCharsets.ISO_8859_1))
			.queryParam("RelayState", UriUtils.encode(relayState, StandardCharsets.ISO_8859_1))
			.build(true)
			.toUriString();
	return redirect;
}

Expected Behavior

Using HTTP-Redirect binding SigAlg and Signature parameters are added to SAMLRequest Url and AuthNRequest XML is not signed.

Version

5.2.1.RELEASE

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Dec 9, 2019
@fhanik fhanik self-assigned this Dec 10, 2019
@fhanik fhanik added in: saml2 An issue in SAML2 modules type: enhancement A general enhancement and removed status: waiting-for-triage An issue we've not yet triaged labels Dec 10, 2019
@fhanik
Copy link
Contributor

fhanik commented Dec 20, 2019

@berschmoe

Thank you for your report. You are absolutely correct. I had originally implemented this as a POST binding and when I switched it to REDIRECT I didn't go back to the spec to check the signatures.

The BINDING spec covers this in detail in section 3.4.4.1 DEFLATE Encoding

Some Identity Providers, like Okta, ignore all signatures on the AuthNRequest message because they require the Service Provider ACS URL to be whitelisted. There is a possibility that Keycloak requires the same thing, and thus as a temporary mitigation you could turn off the signature requirement. You would have to double check this. Other providers, such as SimpleSAMLPhp, accept XML signatures in the message itself.

And that's probably why we haven't seen this bug reported until now.

I have prototyped two different solutions, in two different PRs for review.

  1. Option 1 - Simply fix the bug, changing current behavior, with a fallback to existing SAML AuthNRequest Signatures - Step 1 #7758
  2. Option 2 - Provide a configuration option for what BINDING should be used. And through configuration, remain backwards compatible. SAML AuthNRequest Signatures - Step 2 #7759 (this PR adds configuration on top of SAML AuthNRequest Signatures - Step 1 #7758)

Flagging @rwinch for consideration.

PS. During testing I discovered that java.util.Base64 is not sufficient for all IDPs, and we had a message that failed. So we changed the encoder/decoder back to Apache Commons Codec.
Each PR has this commit as a rider.

Test configuration as a gist

fhanik added a commit to fhanik/spring-security that referenced this issue Feb 11, 2020
…equest is signed

Has been tested with
- Keycloak
- SSOCircle
- Okta
- SimpleSAMLPhp

Further configuration options (POST vs REDIRECT) that build on top of
this PR can be found in:
spring-projects#7759

[fixes spring-projects#7711]
fhanik added a commit to fhanik/spring-security that referenced this issue Feb 12, 2020
Implements the following bindings for AuthNRequest
- REDIRECT
- POST (future PR)

Has been tested with
- Keycloak
- SSOCircle
- Okta
- SimpleSAMLPhp

Fixes spring-projectsgh-7711
@fhanik fhanik closed this as completed in a3e09fa Feb 12, 2020
fhanik added a commit to fhanik/spring-security that referenced this issue Feb 12, 2020
Implements the following bindings for AuthNRequest
- REDIRECT
- POST (future PR)

Has been tested with
- Keycloak
- SSOCircle
- Okta
- SimpleSAMLPhp

Fixes spring-projectsgh-7711
fhanik added a commit that referenced this issue Feb 12, 2020
Implements the following bindings for AuthNRequest
- REDIRECT
- POST (future PR)

Has been tested with
- Keycloak
- SSOCircle
- Okta
- SimpleSAMLPhp

Fixes gh-7711
@lilalinux
Copy link

Hi, thanks for fixing. When can we expect the fix to be released? Is there a workaround?

@fhanik
Copy link
Contributor

fhanik commented Mar 2, 2020

@lilalinux Most IDPs don't require signatures because they have the SSO URLs white listed and preconfigrued. The work around is to not require signatures. This will be part of the 5.3 release.

@lilalinux
Copy link

Unfortunately in SAP idP we can't disable that requirement 😕
Are there alternatives? Can we switch from Redirect to POST? (How?)

@jzheaux jzheaux added this to the 5.3.0 milestone Mar 4, 2020
@rwinch
Copy link
Member

rwinch commented Mar 4, 2020

Hi, thanks for fixing. When can we expect the fix to be released? Is there a workaround?

This is in the 5.3 release which will be out tomorrow. You can figure it out by looking at the milestone on the right hand side of the issue and clicking on it to see the scheduled date.

jzheaux added a commit that referenced this issue Mar 20, 2020
Removed one method as well as a parameter from another method

Issue gh-7711
jzheaux added a commit that referenced this issue Mar 20, 2020
- Removed reflection usage
- Simplified method signatures

Issue gh-7711
Fixes gh-8147
jzheaux added a commit that referenced this issue Mar 20, 2020
Removed one method as well as a parameter from another method

Issue gh-7711
jzheaux added a commit that referenced this issue Mar 20, 2020
- Removed reflection usage
- Simplified method signatures

Issue gh-7711
Fixes gh-8147
@fpagliar
Copy link

My understanding is that this fix is in 5.3.x and not in 5.2.x, is that correct?

@rwinch
Copy link
Member

rwinch commented Apr 14, 2020

@fpagliar Yes it is only in 5.3.x As an enhancement it does not get backported to patch releases (which are only bug fixes)

@fpagliar
Copy link

fpagliar commented Apr 14, 2020

I'm fine with it not being backported, but I'm trying to figure out the state and what to expect, so sorry to bother but I need to clarify the status.
My understanding on this issue is that 5.2 creates signed AuthNRequests that are not respecting the SAML standard. Is that correct?

@jzheaux
Copy link
Contributor

jzheaux commented Apr 15, 2020

Yes, @fpagliar, 5.2 deviates from HTTP-Redirect by omitting the SigAlg and Signature query parameters.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: saml2 An issue in SAML2 modules type: enhancement A general enhancement
Projects
None yet
Development

No branches or pull requests

7 participants