We need more detailed information besides "it not working".

Did this work with the prior version of both mod_auth_mellon and lasso?

What specifically is not working?

What SAML profile are you using?

What is the IdP and SP metadata?

Are there log messages in /var/log/http/error_log related to this problem? If so what are they?

If there are no log messages you may need to turn up the verbosity of the logging to the debug level. To do this edit /etc/httpd/conf/httpd.conf and change the LogLevel to debug and they restart your Apache server.

What specifically is not working? - SHA 256 (SAML request is not signed with expected signature algorithm. SAML request is signed with signature algorithm http://www.w3.org/2001/04/xmldsig-more#rsa-sha256 . Expected signature algorithm is http://www.w3.org/2000/09/xmldsig#rsa-sha1  is the error)

IDP - ADFS
SP - Mod_auth_mellon

The Lasso 2.5.0 should accept SHA 256, but it still throws above mentioned error in the log. The previous version of Lasso (2.4.1) is not supported for SHA 256. 

Thank you.

I'm having trouble parsing comment #3. You say Lasso 2.5.0 should accept SHA 256 but that is not what the paragraph above implies. If I'm reading it correctly what is happening is mellon is signing the request with SHA 256 and the ADFS IdP is rejecting it because it wants rsa-sha1. Did I get that correct?

Part of the problem is both the SP and the IdP can sign messages and both have an opportunity to reject a signature, so far there isn't enough information in this bug report to disambiguate. 

Apparently the ASFS IdP is very fussy with what signatures it will accepts and defaults to rsa-sha1 (but this can be controlled with configuration options).

It would really help if you provided:

* The exact error message and where it came from (e.g. was the error message in the Apache log file or was it returned by the IdP?)

* The metadata you're using for both the SP and the IdP (as requested in comment #2).

If the above is not sufficient to diagnose the problem I may need you to capture the SAML exchange (in fact this would really help because it allows me to see the dialog between the SP and IdP). The easiest way to do this is with the Firefox SAML Tracer Add-On (https://addons.mozilla.org/en-US/firefox/addon/saml-tracer/). Install the add-on into your Firefox browser and activate it. Then make your request that triggers SAML SSO. In the SAML Tracer window find the request and click on it, click on the SAML tab, you'll see the decoded SAML request, copy it and attach it to this bug report. Do the same for the SAML Response. If there is anything sensitive you don't want to expose in a public bug report you can email the information to me instead.

For me to make progress on this I need to see the SAML conversation between the SP and the IdP. Can you capture the SAML exchange and attach it to this bug report? Thank you.

Is there any update on the request for information from comment#5?  We need this information to proceed on investigation of this issue.

No additional information has been supplied. The reason I need to see the protocol exchanges is because the algorithms are embedded in the cert and possibly in the metadata ds KeyInfo. Unless I can see these values I can't determine who in the process is complaining or why or for that matter reproduce it.

The original reporter believes it's a SHA-2 issue, which it may very well be but without seeing the data nor being able to reproduce it (given the data) it's tough to fix. In essence what I'm asking for is a reproducer.

"While using ADFS IDP with SHA-256, it not working" is not sufficient information to proceed.

This is most likely caused by a bug in the lasso package.

See https://dev.entrouvert.org/issues/10019

When you configure to generate a sha256 hash, it would always generate a sha1

Fixed in upstream with commit 74e8705b which is part of 2.5.1 release.

*** This bug has been marked as a duplicate of bug 1310860 ***

Hi,
 As far as I can tell, this bug is still open.
We are using Mod_mellon .12 which uses lasso 2.5.1 and when your adfs server is configured for SHA-256 as the signing for the SP trust, it fails to decrypt with the error in the logs that Thiyagu provided in comment #3 above. That text in the comment is what is IN the logs.
This appears to be a known bug in lasso, but we went to the lasso 10019 thread an pulled that patch released and appear to be generating the same error.

What information would you like to be able to understand the problem.
Teh gist is that the sp-idp trust is failing because the metadata exchange is failing because the signing algorithm (sha1 or sha256) are not matching, works fine if adfs is set to sha1, and we have tested with PING in sha-256 an that works, but adfs sha-256 throws the error in lasso that:

"SAML request is not signed with expected signature algorithm. SAML request is signed with signature algorithm http://www.w3.org/2001/04/xmldsig-more#rsa-sha256 . Expected signature algorithm is http://www.w3.org/2000/09/xmldsig#rsa-sha1"

The aDFS is configured with SHA256, yet Lasso is defaulting to sha1 and rejecting the IDP metadata signed with sha256, saying it wants Sha1.
in your comment 4 you were backwards on your assumption.
sorry for the long time in reply, thiyagu left our firm and we weren't aware he had started this thread until we were googling for help with this error.
Mark

Are you are saying you cannot load the ADFS metadata into mellon because the ADFS metadata is signed with SHA256 and the signature verification is failing on the ADFS metadata? That implies you never even got to the point of exchanging SAML messages for authentication. Did I get that right?

Supplying the failing ADFS metadata would be a good step in allowing us to diagnose the problem.

That is correct. We cannot exchange saml because the trust won't establish because it can't decipher the metadata.

Please supply the metadata. Thank you.

both sides? or one in particular?
and it may be tomorrow as I am buried in meetings the rest of today. 
sorry for the delay.. I have to rest a test site back to sha256 to do this..

Since you claim it's the IdP metadata that is failing that would be the metadata we would need to reproduce the problem.

Signature validation requires access to the public key (i.e. cert) of the signer. Sometimes this is included in the document in the <KeyInfo><X509Certificate> element, but it is not mandatory in SAML. If the metadata does not contain the X509 cert then we'll need that as well (plus any other certs in the chain).

Created attachment 1267536 [details]
adfsmetadatasha256

Here is the adfs metadata setup for 256.
We tested with a build of mod mellon 13 and also 12, and using lasso.x86_64 2.5.1.
Thanks

Here is what we pulled from todays log.

Error processing authn response. Lasso error: [-432] Status code is not success, referer: https://adfsus.exterro.info/adfs/ls/?SAMLRequest=jZJfa8IwFMW%2FSsm7trVoXagFbScIboj787CXEeotBtKky71x7tsvrXNzL25PgZN7kvM73AxFo1o%2Bd7TXW3hzgBQcG6WR9xcz5qzmRqBErkUDyKniD%2FO7NR8NI95aQ6Yyil1YrjsEIliSRrNgVc7Y6zwZLcskWsTTpLhNp%2BV4MkkmN8UiTdNlFI8XLHgGi35%2BxrzdmxAdrDSS0OSlKE4HUTJIosc44fGIR9MXFpSeQWpBvWtP1CIPQ7Gr0eEQjgTWmqHUtem1UGHIgsJohO7Fa9mr0xCvnLX%2BHMimVbKSxIKlsRX0Fc5YLRRCF3TjWeUBvpX5Gb37zDVgH8AeZAVP2%2FVPzB0cEA15gnPUShm3O%2BX9UvxA2BqkLWDbRWJ51hXP%2B25s%2Fp%2BnsvDSkZ124N4Tr8qN8VAfHVIj%2FiikU%2BRuUPejnKzQKH0xHlUp815YEOTxyTpgYX768vem5Z8%3D&RelayState=https%3A%2F%2Fdevssotest.exterrocloud.info%2Ffusion%2Fui%2Fpages%2FadminLogin.htm&SigAlg=http%3A%2F%2Fwww.w3.org%2F2000%2F09%2Fxmldsig%23rsa-sha1&Signature=d7t16IJOffXMOOxhc0neE4boGIHqbxl13oviTd0aSU%2BMTB4wddqpam9K1CPV%2FQzy9mcUUiKI9GSmJQW1ZGt%2FWj7eQhhLEcL0Lgin%2BE00LTnv%2B7p15J5zI3IfkTPxN1FbQOorEaIW%2BUpzVSb2YtIgu61iDO5VD1xMK7hbDRfhs5vSfK0gk2gC4oxqWNu8m9NY6EQrIjJcux26VhefwRxx%2BCzSQWJDF0SvkqC6Rkeaasv8zORIYXdIuu%2BphPJXkxMmbM7dLXVacyN3EQ9K%2Bn%2BshDaAaT6HBpzTQdC3xxioggZ6whQCgoJxvjtoznsp6GpZgktDHy2AZJz9guuOCo4Mhw%3D%3D

Is there any further information about this error?  I encountered the same issue.  When ADF sets assertion signing with SHA1, it works...  But when ADF sets  assertion signing with SHA256, I get the same exact error.  My lasso package is the latest one lasso-devel-2.5.1-2.el7.x86_64 and lasso-2.5.1-2.el7.x86_64.  I even set the rpm macros file to ensure file digest with SHA256.  Is the bug resolved yet?

Hello, any update about this issue? We have same problem with the following setup:

IDP -> ADFS (Windows 2012 R2)

SP -> mod_auth_mellon (CentOS 7.3 + Apache 2.4.6 + lasso-2.5.1-2)

If SHA1 is set on the IDP then everything works fine, however if SHA256 is selected an Event 364 is logged by ADFS that is

The message is not signed with expected signature algorithm. Message is signed with signature algorithm http://www.w3.org/2000/09/xmldsig#rsa-sha1. Expected signature algorithm http://www.w3.org/2001/04/xmldsig-more#rsa-sha256.

Apache logs the following:

Error processing auth response. Lasso error: [-432] Status code is not success

Comment #21 seems to be the relevant information, the problem is not occurring on the Mellon/Lasso side, it's with the IdP (e.g. ADFS) Mellon is communicating with, or so I believe based on that message and what I've been able to Google concerning ADFS. I will also add this caveat in advance, I'm not familiar with ADFS or for that matter most Microsoft products, but I do know SAML. We currently have no evidence the updated Lasso package is not able to process received signatures with SHA-256, more to the point that does not seem to be the issue. Let me explain what I think is going on.

In SAML there are two parties, an SP (role played by Mellon) and an IdP (role played by ADFS). In SAML parlance the SP is a "relying party" because it "relies" on assertions provided by the IdP and the IdP is called the "asserting party".

Each party can sign their messages. How each party signs their messages is at the sole discretion of the party signing the message. When configuration information is exchanged by the parties (e.g. SAML metadata) they DO NOT specify the signature mechanism, the extent of the signature configuration information is limited to "I want signed messages", "I will sign messges" and if I'm signing here is the public key I will use. The digest algorithm is never part of this configuration information. The digest appears in the SIGNED MESSAGE once the message is received.

The signing properties of the SP (relying party) and the IdP (asserting party) are completely INDEPENDENT of one another.

The ADFS error in comment #21 is stating the SP (relying party) sent a signed AuthnRequest with a signature it did not like hence it's is rejecting it. This is NOT related to Mellon/Lasso being able to validate a signed message received from the IdP.

Apparently ADFS has a configuration option to set the expected (required) digest algorithm for EACH RELYING PARTY. Currently it accepts only 2 values, SHA-1 and SHA-256. This is NOT (or should not be) the configuration option for how ADFS signs it's messages sent to the relying parties. Or at least I don't believe so, this really a question to be answered by Microsoft, the key point is sending a signed message and receiving a signed message are 2 independent things (I don't know if Microsoft has conflated the two concepts or not, I could not find any definitive information in my searching).

Mellon is hardcoded to send it's messages signed with SHA-1. I believe the solution is to modify the relying party configuration in ADFS for your Mellon SP to be SHA-1 since that is what Mellon is sending. This tech article from Microsoft show the details of setting the relying party digest configuration.

https://docs.microsoft.com/en-us/azure/active-directory/active-directory-federation-sha256-guidance

If modifying this configuration option also changes how ADFS signs it's messages then that would seem to violate the principal each party is independent, there should be a separate setting controlling only how ADFS signs.

Many IdP's simply accept valid signature from their relying parties without forcing a specific digest, apparently ADFS wants to be EXPLICIT as to what digest the relying party will use. Once again this is a question for Microsoft. Also I want to reiterate this is independent of Mellon's ability to properly validate a signature received from ADFS using SHA-256.

I would be good if Mellon had a configuration option to set the signature method it uses, but that's an RFE not a bug. My suggestion is someone open a RFE bug requesting this feature.

It would be helpful if we could find explicit documentation on this part of ADFS behavior or have someone from Microsoft confirm whether the signature methods between the parties is independent or co-related. If this isn't in their public documentation somewhere then I suspect only an engineer is going to know this at this level of detail.

I have a patched build of mod_auth_mellon for RHEL7.4 which includes the ability to set the signature method used by mellon to sign it's requests. Previously it defaulted to rsa-sha1, now it defaults to rsa-sha256 but can also be explicitly set via the new MellonSignatureMethod configuration directive.

The hope and expectation is this should solve the problem when authenticating against ADFS when the ADFS provider signature algorithm set to SHA-256. With this fix ADFS should no longer complain and the authentication will be successful.

This has been successfully tested against RH-SSO, but we n

If you are affected by this bug contact Red Hat Global Support Services and request the test build.

Fixed in mod_auth_mellon-0.13.1-2.el7_5 by the addition of the MellonSignatureMethod config directive.

Verified.

Version ::

mod_auth_mellon-0.14.0-2.el7.x86_64

Results ::

Followed verification from bug #1564573.  

[root@sp1 adfs]# openssl req -new -newkey rsa:2048 -keyout mellon.key -nodes -out mellon.csr -subj '/CN=sp1.keycloak.test'
Generating a 2048 bit RSA private key
.....................+++
...............................+++
writing new private key to 'mellon.key'
-----

[root@sp1 adfs]# cat mellon.csr
-----BEGIN CERTIFICATE REQUEST-----
MIICYTCCAUkCAQAwHDEaMBgGA1UEAwwRc3AxLmtleWNsb2FrLnRlc3QwggEiMA0G
CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+ZGX0Ua1MkAt2srsZtGhB6uJSeH82
ODSkDbW2VCH8P+g6I2GktJpkppFAjIBQUPKWaPeg6nPifjOEh/TVH7rdIN2brFwz
4V9mBHdWqSpZJoXx6XQDBi0VcJkpRqgfJN6Do0OyOsUzZD6qK9ab1SZR+7ZGm0/y
VobV9VcH6VBOAE487AQtb6ju3sESx9oum3R3vaKK40dnReC/JxayKmwt8Ify7ule
bfid4BverXp5oNxJYwfxdk2ufskwB3fVa/ts7kWXb3LUi0Md365AroFhbFrOFFhi
/IM8CM6MF94LohrhbtUwHAp/LIj/MzQQgmJ3ZehzThBPSXFFK+5+B5u3AgMBAAGg
ADANBgkqhkiG9w0BAQsFAAOCAQEAFBxtmmM9e+i1sEoAHeppySn99EjgN9pZW2Br
pXAq1w05Bgl0q5mUZXhkSf2YoSGqYQGtBRFi291enzb/0hqTGg8wVXd2/Oc+BVC7
MzVcjA4r3GE8JnqrU7gSgIraG71GyFCPb/OEiaMc3JqZe7Kh8Re5uvUYJOd6qs8d
aZcNxyquQ+NBd2uA1Xw+N5WmuSurFeC2njMOGlh+8yYbWmCugwifKqB6hLO7frfm
XfpciWH/uCYKLacnAvXJF6SCP0wo0qwcbXUTL523X1rXOCuIqs1xBwzUFn0XNzqM
Hn/F88967ne59qELTz2DOMNLGRozq1VQpyWne+AMvZTbKS9RpA==
-----END CERTIFICATE REQUEST-----

Signed my key with ADCS via web interface at:

https://win1.ad.test/certsrv
> Request a Cert
> Advanced
> paste into saved request
> change template to custom Web Server one previously configured
> save to local machine then copy to /root/adfs on sp1

[root@sp1 adfs]# cp mellon.crt /etc/pki/tls/certs
[root@sp1 adfs]# cp mellon.key /etc/pki/tls/private
[root@sp1 adfs]# cp /etc/httpd/conf.d/ssl.conf ssl.conf.orig
[root@sp1 adfs]# vim /etc/httpd/conf.d/ssl.conf 
[root@sp1 adfs]# diff ssl.conf.orig /etc/httpd/conf.d/ssl.conf
60a61
> ServerName sp1.keycloak.test
100c101
< SSLCertificateFile /etc/pki/tls/certs/localhost.crt
---
> SSLCertificateFile /etc/pki/tls/certs/mellon.crt
107c108
< SSLCertificateKeyFile /etc/pki/tls/private/localhost.key
---
> SSLCertificateKeyFile /etc/pki/tls/private/mellon.key


[root@sp1 adfs]# mkdir /var/www/html/{mellon,private}
[root@sp1 adfs]# mkdir /etc/httpd/saml2
[root@sp1 adfs]# cd /etc/httpd/saml2

[root@sp1 saml2]# /usr/libexec/mod_auth_mellon/mellon_create_metadata.sh "https://sp1.keycloak.test" "https://sp1.keycloak.test/mellon"
Output files:
Private key:                              https_sp_.keycloak.test.key
Certificate:                              https_sp_.keycloak.test.cert
Metadata:                                 https_sp_.keycloak.test.xml
Host:                                     sp1.keycloak.test

Endpoints:
SingleLogoutService (SOAP):               https://sp1.keycloak.test/mellon/logout
SingleLogoutService (HTTP-Redirect):      https://sp1.keycloak.test/mellon/logout
AssertionConsumerService (HTTP-POST):     https://sp1.keycloak.test/mellon/postResponse
AssertionConsumerService (HTTP-Artifact): https://sp1.keycloak.test/mellon/artifactResponse
AssertionConsumerService (PAOS):          https://sp1.keycloak.test/mellon/paosResponse

[root@sp1 saml2]# curl -kL -o https_win1.ad.test.xml https://win1.ad.test/FederationMetadata/2007-06/FederationMetadata.xml
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 71029    0 71029    0     0   242k      0 --:--:-- --:--:-- --:--:--  243k


[root@sp1 ~]# cat /etc/httpd/conf.d/auth_mellon.conf
MellonCacheSize 100
MellonLockFile "/run/mod_auth_mellon/lock"

<Location />
  MellonEnable info
  MellonEndpointPath /mellon/

  MellonSignatureMethod rsa-sha256
  #MellonSignatureMethod rsa-sha1

  # The mellon metadata
  MellonSPMetadataFile /etc/httpd/saml2/https_sp_.keycloak.test.xml
  MellonSPPrivateKeyFile /etc/httpd/saml2/https_sp_.keycloak.test.key
  MellonSPCertFile /etc/httpd/saml2/https_sp_.keycloak.test.cert

  # The ADFS metadata
  MellonIdPMetadataFile /etc/httpd/saml2/https_win1.ad.test.xml
</Location>

<Location /private>
  AuthType Mellon
  MellonEnable auth
  Require valid-user
</Location>

[root@sp1 saml2]# systemctl restart httpd


# ON ADFS Management console
> Delete old entry for sp1.keycloak.test
> Add new one like this:
- Trust Relationships -> Relying Party Trusts
- Add Relying Party Trust
- Start
- Import data about relying party published online...
- Enter metadata URI: https://sp1.keycloak.test/mellon/metadata
- Next
- Ok that some features aren't supported
- Next on Specify Display Name screen
- Next on Configure Multi-Factor Authentication screen
- Next on Choose Issuance Authorization Rules screen
- Next on Ready to Add Trust screen
- Configure on Finish screen
- Should see option to edit claim rule, make sure it's selected

> Edit Claim rule
- Issuance Transform Rules
- Add rule
- choose Transform an Incoming Claim
- Next
- Claim rule name: Name your rule. I named mine "Send Windows Name as NameID"
- Incoming claim type: Windows account name
- Outgoing claim type: Name ID
- Outgoing name ID format: Transient Identifier
- Make sure that the Pass through all claim values option is chosen.
- Finish
- OK


# testing by accessing https://sp1.keycloak.test/private/.  If it works, I will see login and be able to sign in with an AD user account in the domain.

# logout with https://sp1.keycloak.test/mellon/logout?ReturnTo=https://sp1.keycloak.test/


So, testing with:

* Mellon=SHA-256 ADFS=SHA-256 ::  PASS
* Mellon=SHA-256 ADFS=SHA-1 :: PASS
* Mellon=SHA-1 ADFS=SHA-1 :: PASS
* Mellon=SHA-1 ADFS=SHA-256 :: FAIL (expected)


Note to change mellon to SHA-1 I changed this line in /etc/httpd/conf.d/auth_mellon.conf:

  MellonSignatureMethod rsa-sha1

And to change the Signature Algorithm in ADFS, select relying party trust entry and change on advanced tab.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2018:3143

*** Bug 1605657 has been marked as a duplicate of this bug. ***