PingFederate SLO - Status Message: Invalid signature - single-sign-on

After I invoke single-log-out (SLO), by calling 'GET' on https://[PingFederate Server Instance]:[Port]/sp/startSLO.ping, my PingFederate server begins making requests to my SP logout services. [I know this because I can see it happening in Fiddler.]
But when one my SPs invokes “https://<PingFederate DNS>:XXXX” + request.getParameter(“resume”); (per #Scott T.'s answer here), I get an error message:
Error - Single Logout Nonsuccess Response status:
urn:oasis:names:tc:SAML:2.0:status:Requester Status Message: Invalid
signature Your Single Logout request did not complete successfully. To
logout out of your Identity Provider and each Service Provider, close
all your browser windows. Partner: XXXX:IDP Target Resource:
http://<domain>/<default SLO endpoint>
My Questions:
What is this error message referring to?
How can I resolve this error condition?

This error is likely due to a mismatch in configuration between IdP and SP. The signing keys/certificate for SAML messages used at one end, must match the verification certificate at the other end. Check your Credentials configuration on your connection for both IdP and SP. See this section in the PingFederate Administration Guide for some details.

Related

Identity provider oauth callback error to keycloak 502

I am running keycloak 19.0.2 in dev mode. When trying to login to microsoft from keycloak (SSO) using the oauth2 flow, I get 502 error in the browser on the callback to keycloak. The code param has a strange value also.
I believe it has something to do with user permissions, but I can clearly see I have defined them.
The callback to the keycloak server throws a 502 error and has strange values in the code params.
The keycloak server errors with the following logs:
2022-10-17 13:08:46,517 ERROR
[org.keycloak.broker.oidc.AbstractOAuth2IdentityProvider] (executor-thread-42)
Failed to make identity provider oauth callback:
org.keycloak.broker.provider.IdentityBrokerException: Could not obtain user profile
from Microsoft Graph
2022-10-17 13:08:46,542 WARN [org.keycloak.events] (executor-thread-42)
type=IDENTITY_PROVIDER_LOGIN_ERROR, realmId=8ca06b23-d544-4464-a3bf-448be5308802,
clientId=recruit-api, userId=null, ipAddress=127.0.0.1,
error=identity_provider_login_failure, code_id=62aaf7bf-9c08-4c88-a7c3-e6f7af282de1,
authSessionParentId=62aaf7bf-9c08-4c88-a7c3-e6f7af282de1,
authSessionTabId=WjArYJ99WyM

WSO2 identity server - SAML2 Response Issuer verification failed

I am using the wso2 sample apps (saml2-web-app-pickup-dispatch and saml2-web-app-pickup-manager) to test single sign on through WSO2 identity server version 5.10.0
The deployment is fine and on clicking the application's login, it redirects to the WSO2 login page successfully.
User logs in successfully but receives error below.
HTTP Status 500 – Internal Server Error
Type Exception Report
Message SAML2 Response Issuer verification failed
Description The server encountered an unexpected condition that prevented it from fulfilling the request.
Exception
org.wso2.carbon.identity.sso.agent.exception.SSOAgentException: SAML2 Response Issuer verification failed
org.wso2.carbon.identity.sso.agent.saml.SAML2SSOManager.processSSOResponse(SAML2SSOManager.java:569)
org.wso2.carbon.identity.sso.agent.saml.SAML2SSOManager.processSSOResponse(SAML2SSOManager.java:525)
org.wso2.carbon.identity.sso.agent.saml.SAML2SSOManager.processResponse(SAML2SSOManager.java:358)
org.wso2.carbon.identity.sso.agent.SAML2SSOAgentFilter.doFilter(SAML2SSOAgentFilter.java:98)
Note The full stack trace of the root cause is available in the server logs.
Apache Tomcat/8.5.53
Logs from the server
TID: [-1234] [2020-04-25 19:16:55,881] [7e977cfd-8304-44ba-ab4f-4644baff988e] INFO {AUDIT_LOG} -
Initiator : wickrema | Action : Login | Target : ApplicationAuthenticationFramework |
Data : {
"ContextIdentifier" : "51f93b05-68cf-4bf4-b62b-51e3e2502889",
"AuthenticatedUser" : "wickrema",
"AuthenticatedUserTenantDomain" : "carbon.super",
"ServiceProviderName" : "saml2-web-app-pickup-dispatch",
"RequestType" : "samlsso",
"RelyingParty" : "saml2-web-app-pickup-dispatch.com",
"AuthenticatedIdPs" : "eyJ0eXAiOiJKV1QiLCAiYWxnIjoibm9uZSJ9.eyJpc3MiOiJ3c28yIiwiZXhwIjoxNTg3ODMxNDE1ODA0MzAwMCwiaWF0IjoxNTg3ODMxNDE1ODA0LCJpZHBzIjpbeyJpZHAiOiJMT0NBTCIsImF1dGhlbnRpY2F0b3IiOiJCYXNpY0F1dGhlbnRpY2F0b3IifV19."
} | Result : Success
Your Service Provider application(Pickup-Dispatch) is trying to verify if the received SAML response is issued by the expected SAML Identity Provider. WSO2 includes its ID in the SAML response's <saml:Issuer> tag.
Your application has a pre-configured entity ID for WSO2 in the saml2-web-app-pickup-dispatch.com/WEB-INF/classes/sso.properties file as below.
SAML2.IdPEntityId=localhost
Likewise, WSO2 IS populates its SAML response's issuer with the value you've configured in the Resident Identity Provider's Home Realm Identifier.
But you can override the Home realm identifier with the IdP Entity ID Alias of your Service Provider SAML configurations as below.
Bottom line, the Issuer ID of the SAML response should be the same as what you've configured in the Application as the IdP Entity ID.
Change either value to make them the same.
Code for your reference

SP-Initiated SLO Generating multiple SLO requests

I'm using the sustainsys saml2 owin package, and I'm having problems with SP-initiated SLO. I'm new to the saml process, so there's a good chance I'm doing something wrong.
Our signout workflow is as follows:
User hits myapp.com/signout
myapp redirects to myapp.com/saml2/logout
The owin package generates a saml request and sends it to the Idp's slo route
The Idp responds with a successful saml response to the same url: myapp.com/saml2/logout
At this point, the owin package is generating another saml request to sign the user out of the idp. It would get stuck in an infinite redirect, if the Idp didn't halt the process.
Here's a snapshot of my network panel in chrome:
I'm using https://github.com/mcguinness/saml-idp as a development Idp, and here's a stub of my owin configuration:
I suspect I've misconfigured something or I'm using the saml2/logout route inappropriately, but I also find it odd that the owin package would generate another request when it gets a successful response.
Update 11.9.2018
Here's my verbose log starting from the logout process:
Expanded Saml2Url
AssertionConsumerServiceUrl: http://locala.foliotek.com/saml2/linuxdev/Acs
SignInUrl: http://locala.foliotek.com/saml2/linuxdev/SignIn
LogoutUrl: http://locala.foliotek.com/saml2/linuxdev/Logout
ApplicationUrl: http://locala.foliotek.com/
=================
Initiating logout, checking requirements for federated logout
Issuer of LogoutNameIdentifier claim (should be Idp entity id): http://myidentityprovider.com
Issuer is a known Idp: True
Session index claim (should have a value): http://Sustainsys.se/Saml2/SessionIndex: 1926000282
Idp has SingleLogoutServiceUrl: http://myidentityprovider.com/saml/slo
There is a signingCertificate in SPOptions: True
Idp configured to DisableOutboundLogoutRequests (should be false): False
=================
Expanded Saml2Url
AssertionConsumerServiceUrl: http://myserviceprovider.com/saml2/linuxdev/Acs
SignInUrl: http://myserviceprovider.com/saml2/linuxdev/SignIn
LogoutUrl: http://myserviceprovider.com/saml2/linuxdev/Logout
ApplicationUrl: http://myserviceprovider.com/
=================
Initiating logout, checking requirements for federated logout
Issuer of LogoutNameIdentifier claim (should be Idp entity id): http://myidentityprovider.com
Issuer is a known Idp: True
Session index claim (should have a value): http://Sustainsys.se/Saml2/SessionIndex: 1926000282
Idp has SingleLogoutServiceUrl: http://myidentityprovider.com/saml/slo
There is a signingCertificate in SPOptions: True
Idp configured to DisableOutboundLogoutRequests (should be false): False
=================
Expanded Saml2Url
AssertionConsumerServiceUrl: http://myserviceprovider.com/saml2/samltestid/Acs
SignInUrl: http://myserviceprovider.com/saml2/samltestid/SignIn
LogoutUrl: http://myserviceprovider.com/saml2/samltestid/Logout
ApplicationUrl: http://myserviceprovider.com/
=================
Initiating logout, checking requirements for federated logout
Issuer of LogoutNameIdentifier claim (should be Idp entity id): http://myidentityprovider.com
Issuer is a known Idp: False
Session index claim (should have a value): http://Sustainsys.se/Saml2/SessionIndex: 1926000282
Idp has SingleLogoutServiceUrl:
There is a signingCertificate in SPOptions: True
Idp configured to DisableOutboundLogoutRequests (should be false):
=================
Expanded Saml2Url
AssertionConsumerServiceUrl: http://myserviceprovider.com/saml2/linuxdev/Acs
SignInUrl: http://myserviceprovider.com/saml2/linuxdev/SignIn
LogoutUrl: http://myserviceprovider.com/saml2/linuxdev/Logout
ApplicationUrl: http://myserviceprovider.com/
=================
Http POST binding extracted message
<samlp:LogoutResponse xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" ID="_d02d42fbb8ed00bbee02" InResponseTo="idf75b17a7713e4f698f891edf1fcca117" Version="2.0" IssueInstant="2018-11-09T16:44:01Z" Destination="http://myserviceprovider.com/saml2/linuxdev/logout"><saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">http://myidentityprovider.com</saml:Issuer><Signature xmlns="http://www.w3.org/2000/09/xmldsig#"><SignedInfo><CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /><SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256" /><Reference URI="#_d02d42fbb8ed00bbee02"><Transforms><Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" /><Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /></Transforms><DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" /><DigestValue>X+93fiv6vuuy8sIhmFFxIVxNgAy/f1Zk62RRh/rn91I=</DigestValue></Reference></SignedInfo><SignatureValue>qXMlLe2fciQR6u7Ddx40RFI51IJ5r8A3m7X7mrgIMHBdFf2vypiCFxqOrEOKCSIqWzDUxVXujWyMQzO/zZtVyZlm6xXnb3lId0VDHLEIUT/8kyNsodzvzPIyTMaMMV/cmhQ3UZlYRv9BeyPswpkosFTn/xc6c+BX9z+w4AN4KDMFfYlTeu/uyDBa1u5zr/Ze6OXwP7///Mo/zdy2ZXyHJhia+yscWZ+Hrb49ekI9csJvuic0p6ttJPjS72tmEesGR1vLT0Y/5T+SqOVmmbmN8hZygRxrEwgfo9oNI+8BBC7aYK2PCtTZZFwoO3KsEEttQjxzKTbzja9s8XslGxfKkw==</SignatureValue><KeyInfo><X509Data><X509Certificate>MIIDgzCCAmugAwIBAgIJALOc35pt94LuMA0GCSqGSIb3DQEBCwUAMFgxCzAJBgNVBAYTAlVTMREwDwYDVQQIDAhNaXNzb3VyaTERMA8GA1UEBwwIQ29sdW1iaWExFTATBgNVBAoMDEZvbGlvdGVrIEluYzEMMAoGA1UEAwwDSWRwMB4XDTE4MTEwOTE1MDI0MVoXDTM4MTEwNDE1MDI0MVowWDELMAkGA1UEBhMCVVMxETAPBgNVBAgMCE1pc3NvdXJpMREwDwYDVQQHDAhDb2x1bWJpYTEVMBMGA1UECgwMRm9saW90ZWsgSW5jMQwwCgYDVQQDDANJZHAwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDhX8PX+C/1orPpFnOIRy7UkrLU7YCq6DNzB5QSUzT366++ZCWFzx+Ub+HFxbR/htY/EAramlCNFawOSGS6mnWev/tiokGObXdMK6tAXyZZMc/u9Rg65EjM892Oep6gIEWgjnE+l7M8v84QOWqAl+GaeM8YZJKHXAZ+7MVMgkMWeYKrksvQdKrQjhyzqoLmBNL5yGBgEH1KEtFy0A0qYdiwdWptvaeWkTk6tp3kfminRaQ1bj/BmMwAWeDbE7EFkk7wF1ig4QhTINoVFQhPGa/+sPg+NuDNlGszDBV3fmfpHwPpjRr4zzoNyJnMvf3u1+C63c7DPSC+uKGvYlgeWbc/AgMBAAGjUDBOMB0GA1UdDgQWBBQvczxcOnaazyGJ8H3vi1vY6g24xDAfBgNVHSMEGDAWgBQvczxcOnaazyGJ8H3vi1vY6g24xDAMBgNVHRMEBTADAQH/MA0GCSqGSIb3DQEBCwUAA4IBAQAoMsoDnrEPCS+VIqVlnlbxxd4lx5AYMvUTZPugJ88+Jjp/1kkKbxWzbJBR1yl0v9quLoQ/u5XkYoSI3u/azydywpADlgsKHrL7Ger+ZU2pdSCK9LTbOP3gnginmPldB7LW6jxWxuEYadWLpYocEFU6Ua7XJUDOzMpO3SXxmhiyhvQC2PF0Q1uehNkwIpUP+9I9ulAXxjScyputgYjkWjiLYu+gcWYW6DmeWqJKyYR6XSwaa+QV4/UPupBmSc1Bx7BuF29+1RwJyTEI6Uz5wQe+lbzZ5ay3J3oa3lilwYg/HYq4mQzVucHEhQLsU9ZIfuGStMHX23sdzWuEBbcQgCCd</X509Certificate></X509Data></KeyInfo></Signature><samlp:Status><samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" /></samlp:Status></samlp:LogoutResponse>
=================
Here's my info log from the logout process
Sending logout request to http://myidentityprovider.com
=================
Sending logout request to http://myidentityprovider.com
=================
Federated logout not possible, redirecting to post-logout and clearing local session
=================
Received logout response Microsoft.IdentityModel.Tokens.Saml2.Saml2Id, redirecting to http://myidentityprovider.com/saml/slo?SAMLRequest=fZJdS8MwFIbvB%2FsPJbeyNv3Y1oatOBhCYXrhxAvvYpKu0XzUnlT2803rJpugkJvz8bznPYesgGqVtGRnD7Z3j%2BKjF%2BCCo1YGyHdpjfrOEEtBAjFUCyCOkf3mfkeSEJO2s84yq9Al8z9CAUTnpDUoqLZrJHmRFuw1LnKcUpYt2JImC1rXOc94yuZpnaHgWXTggTXyvKcAelEZcNQ4n8JxPovjGS6e4gXJUjLPX1Cw9WtIQ91INc61JIpqq6R%2Fpj9y8RmOkRPvIbOaLPESR4P3CJRF5XQSBKtxFTIO68qThLKMKnrFjlgSnXVX0RV3ofTgL1Ftgzvbaer%2BPlEcxmNG8lk9thKhqVQbzjsBgErXCN4Py4GWrrlxjdUU3m4PQ9Pg52zge9yFgZbsvYA%2FSGW4OJZxkSwwxkmenIhf9enkJ3%2F1Ocov&RelayState=MnZ2DPYtc9cY8CkEaR5CRJDz&SigAlg=http:%2F%2Fwww.w3.org%2F2001%2F04%2Fxmldsig-more%23rsa-sha256&Signature=LS0QmYpXX2utWqmEKQJmMeQukm%2FFFVUZCP8I0C7sIt1LklVK0NzuqrJgG9VGwO6uPBZObpZ%2FU9%2BZVddCoIGmg3FCKrhhW7hspsQNN%2FGqpf0QY3kxW%2Bt956TqgynW0yM4I9%2Fc7X%2F9Sy4keFu1uxihjemm%2BCNlZdRS71ch4SyG4YStmKZrWJns1T6H4m8d2eBK7O2KVn9iqwIh6OaV5S6obhpMH9gzx5Y01uc5fTm2gfdoExuVNsKbZB8ycois1MEEz7Uox5zRm09gEfCNMHKf2Dp%2Fwd7GmQoK84VvPoNrxl5047WxfKxkhQPTRFbM5h50peFjOlnFN0yKw9C3DARSBw%3D%3D
=================
After digging into the code a little, I've found if I do the following:
GetLogoutResponseState = (req) => { return null; }
...in my Saml2AuthenticationOptions.Notifications, it works as expected.
From here, I still suspect I'm configuring something wrong, or the IDP is sending the wrong data, but I don't know where StoredRequestState is being initialized. It appears that it contains the wrong returnUrl.
Looking at the logs, I think that this is the sequence of events.
SignOut on your application is hit and redirects to the logout endpoint in the Saml2 library.
The logout endpoint is hit and initiates a logout request to the Idp.
The Idp renders a page (that probably contains some kind of SAML response - but might be incorrect).
The logout endpoint is hit again and this is wrong
Either this is a duplicate request.
Or it is a response that doesn't get properly detected by the Sustainsys.Saml2 library
What makes me really confused is that in the second run all the requirements for a federated logout are fulfilled. Specifically it does find the LogoutNameIdentifier. That shouldn't be possible, as the local session cookie is normally cleared when the redirect to the Idp is done.
To understand further what is happening I recommend that you download the Sustainsy.Saml2 source, link directly to the project and set a breakpoint at LogoutCommand.Run. That should help you understand better and be able to further examine the requests.
I tracked my problem down to the LogoutCommand.Run being called twice during the initial GET request to /saml2/logout. Once from the Saml2AuthenticationHandler .ApplyResponseGrantAsync method, and once from the Saml2AuthenticationHandler.InvokeAsync.
The solution was to set Compatibility = new Compatibility { StrictOwinAuthenticationMode = true } in my SPOptions. Which prevents the LogoutCommand from executing within the ApplyResponseGrantAsync method.
I'm a little unclear on the Passive vs Active authentication modes, but my guess is that I'm indicating to the Sustainsys package that I'm controlling the authentication (including signing out) manually. Maybe Anders can clear that up?

OpenAM error 500 "Unable to do Single Sign On or Federation" when browser loads successURL

I just installed OpenAM 13.0.0, created an hosted IDP, and registered a remote SP.
Within the remote SP (a product called Questetra), I configured the entityID, login URL, logout URL, and certificate using values found in the XML at http://idp:8080/openam/saml2/jsp/exportmetadata.jsp?entityid=http://idp:8080/openam&realm=/
Problem: OpenAM says 500 Internal Server Error at the step where the browser loads the successURL.
Any idea what is happening?
Any tips on how to debug? There is nothing special in the Tomcat and OpenAM logs.
Shortened Wireshark trace
HTTP/1.1 200 OK
[...]
{"successURL":"/SSORedirect/metaAlias/idp?ReqID=a41de50e29c99ff3422f82b7g660ch6&index=null&acsURL=http%3A%2F%2Fthesp%3A8080%2Fuserweb%2Fsaml%2FSSO%2Falias%2Fbpm&spEntityID=http%3A%2F%2Fthesp%3A8080%2Fuserweb%2F&binding=urn%3Aoasis%3Anames%3Atc%3ASAML%3A2.0%3Abindings%3AHTTP-POST"}
GET /openam/SSORedirect/metaAlias/idp?ReqID=a41de50e29c99ff3422f82b7g660ch6&index=null&acsURL=http%3A%2F%2Fthesp%3A8080%2Fuserweb%2Fsaml%2FSSO%2Falias%2Fbpm&spEntityID=http%3A%2F%2Fthesp%3A8080%2Fuserweb%2F&binding=urn%3Aoasis%3Anames%3Atc%3ASAML%3A2.0%3Abindings%3AHTTP-POST HTTP/1.1
[...]
HTTP/1.1 500 Internal Server Error
[...]
<html>[...]HTTP Status 500 - Unable to do Single Sign On or Federation[...]</html>
Full trace at https://gist.github.com/nicolas-raoul/5ff26f37a95bc8088c6af7fe6ea5e468
Tomcat 7.0.72, Ubuntu 2016.04.1 LTS, Firefox 50.1.0
I solved this same error by taking the Certificate value directly from the metadata file exported from OpenAM and entering that directly again, to ensure that it was the exact same.

SAML 2 Signature error in ADFS 2.0

In our SSO scenario, we are using ADFS 2.0 as IDP and Shibboleth as SP. It is an SP-initiated sign-on. After configuring, when I try to establish communication between Shibboleth and ADFS 2.0(throw browser redirect), ADFS 2.0 is throwing the below error.
The verification of the SAML message signature failed.
Message issuer: http://sampleserver/adfs/services/trust
Exception details:
MSIS1015: Server required signed SAML AuthenticationRequest but no signature present.
Event id - 320
Related Event id - 364
> Microsoft.IdentityServer.Service.SamlProtocol.SamlProtocolSignatureVerificationException:
> MSIS1015: Server required signed SAML AuthenticationRequest but no
> signature present. at
> Microsoft.IdentityServer.Service.SamlProtocol.SamlProtocolService.ValidateSignatureRequirements(SamlMessage
> samlMessage) at
> Microsoft.IdentityServer.Service.SamlProtocol.SamlProtocolService.Issue(IssueRequest
> issueRequest) at
> Microsoft.IdentityServer.Service.SamlProtocol.SamlProtocolService.ProcessRequest(Message
> requestMessage)
We haven't used any signature yet. I also have made SignedSamlRequest to false in ADFS properties. Signing of SAML at Shibboleth was also disabled.
I could not find any information in Microsoft site - apart from generic guide for this sort of errors.
Please advice on this error.
I was able to find the solution after a lot analysis. This is a Shibboleth configuration issue. In the application defaults section, the entity ID should be unique to the application.
ApplicationDefaults signing="false" entityID="http://URL of the protected Application "
REMOTE_USER="eppn persistent-id targeted-id"
Another variation of this error happens when sigining is set to true. It will result in Signature mismatch error in ADFS.