SAML 2 Signature error in ADFS 2.0 - single-sign-on

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.

Related

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

Keycloak "validate signature" fails with G Suite SAML

I am using Keycloak 5.0.0 as an identity broker. I have connected it to G Suite as a SAML app. I have connected other SAML apps to G Suite so I know the drill, and I imported the G Suite Metadata XML into SAML, so I am confident that the X.509 keys are correct, but for some reason, if I select "Validate Signature" in Keycloak, the validation fails. The log says
ERROR [org.keycloak.broker.saml.SAMLEndpoint] validation failed
WARN [org.keycloak.events] type=IDENTITY_PROVIDER_RESPONSE_ERROR, realmId=master, clientId=null, userId=null, ipAddress=10.10.2.1, error=invalid_signature
If I turn off "Signed Response" in G Suite or turn off "Want Assertions Signed" or "Validate Signature" in Keycloak then everything works, but I expect that is because Keycloak does not try to validate a signature in these situations (which of course is another bug when "Want Assertions Signed" and "Validate Signature" are on but "Signed Response" is off).
How do I fix this?
Turns out I was wrong about the meaning of "Signed Response". According to documentation from G Suite about setting up specific supported SAML apps, but not found in the "Set up your own custom SAML application" documentation, "Signed Response" does not mean what I thought it meant.
When the Signed Response checkbox is unchecked, only the assertion is signed. When the Signed Response checkbox is checked, the entire response is signed.
I verified (by changing the X.509 key and observing the results) that with "Signed Response" unchecked and "Want Assertions Signed" and "Validate Signature" turned on, Keycloak is validating that the assertions are signed. So that is the correct, valid, and secure configuration.

idp initiated sso using keycloak

This question is in the area of SAML based IDP initiated SSO. As a POC, I have two keycloak instances, say keycloak1 and keycloak2. I would want to achieve the below :
Authentication would be done at keycloak1
keycloak1 then directs to keycloak2 to access an keycloak2 client application.
To do so,
a) create a saml client at keycloak1 under realm1. With IdP initiated SSO Name set as some name without spaces) --> say, keycloakclientsaml. In the Fine Grain SAML Endpoint Configuration section, for Assertion Consumer Service POST Binding URL --> http://<keycloak2:port>/auth/realms/realm2/broker/saml/endpoint/clients/keycloakclientsaml
( https://www.keycloak.org/docs/latest/server_admin/index.html#idp-initiated-login)
b) click on above created saml client --> installation --> Export SAML Metadata IDPSSODescriptor and save as saml-metadata.xml ( say ).
c) Add a user in keycloak1, say user1/user#123
d) At the keycloak2, create a IDP ( identity providers tab). Import the above exported saml-metadata.xml and save.
e) In the browser hit, http://<keycloak1>/auth/realms/realm1/protocol/saml/clients/keycloakclientsaml
Prompt for username/pwd, give credentials for user1
f) URL in the browser now changes to
http://<keycloak2:port>/auth/realms/realm2/broker/saml/endpoint/clients/keycloakclientsaml
At keycloak2 instance, I get the error as :
09:20:46,775 INFO [org.keycloak.saml.validators.ConditionsValidator] (default task-6) Assertion ID_789213dd-24f9-425f-ae20-bcadef173bc6 is not addressed to this SP.
09:20:46,775 ERROR [org.keycloak.broker.saml.SAMLEndpoint] (default task-6) Assertion expired.
09:20:46,775 WARN [org.keycloak.events] (default task-6) type=IDENTITY_PROVIDER_RESPONSE_ERROR, realmId=realm2, clientId=null, userId=null, ipAddress=keycloak2, error=invalid_saml_response
Could someone help here.
Are the above given steps correct and complete.
What am I missing
If any other information is required, let me know. would be happy to provide.
Finally got it working.
So here is the answer to the above :
The error pasted above was related to Assertion expired. In my case, it was because of the clientid given in saml client of Keycloak1 was not recognized url of keycloak2. it should be pointing to the keycloak2 realm ( for example, http://<keycloak2:port>/realms/realm2
Then the condition section in the SAML response is VALIDATED at the keycloak2 broker idp.
(code : SAMLEndpoint.java --> handleLoginResponse method)
Leaving this thread here and for clarity the steps are given below in detail:
a) create a saml client at keycloak1 under realm1. With IdP initiated SSO Name set as some name without spaces) --> say, sso.
b) In the Fine Grain SAML Endpoint Configuration section of the above client, for Assertion Consumer Service (ASC) POST Binding URL --> http://<keycloak2:port>/auth/realms/realm2/broker/saml/endpoint/clients/keycloak2samlclient
( https://www.keycloak.org/docs/latest/server_admin/index.html#idp-initiated-login)
b) click on above created saml client --> installation --> Export SAML Metadata IDPSSODescriptor and save as saml-metadata.xml ( say ).
c) Add a user in keycloak1, say user1/user#123
d) At the keycloak2, create a IDP ( identity providers tab with name saml (refer ASC url). Import the above exported saml-metadata.xml and save.
e) At the keycloak2, create a saml client and in the IP initiated SSO url give name as keycloak2clientsaml
f) In the browser hit, http://<keycloak1>/auth/realms/realm1/protocol/saml/clients/sso
Prompt for username/pwd, give credentials for user1

SharePoint 2013 SSO with WSO2 Identity Server Passive STS

I'm trying to SSO to Share Point 2013 website usin WSO2 Identity Server passive sts support.
Following is the SAML response form Identity Server
<Attribute AttributeName="Email"
AttributeNamespace="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"
>
<AttributeValue>admin#wso2.com</AttributeValue>
</Attribute>
I am getting following log in Share Point side.
04/16/2015 11:40:13.61 w3wp.exe (0x0B18) 0x0640 SharePoint Foundation Claims Authentication ajau6 Verbose SPSecurityTokenServiceManager!GetProviderByName: Returning Trusted Login Provider for input WSO2PassiveSTS1 6130fd9c-aa57-b0ac-0000-0c3c2aa42924
04/16/2015 11:40:13.63 w3wp.exe (0x0B18) 0x0640 SharePoint Foundation Claims Authentication eu2n Monitorable Trusted login provider 'WSO2PassiveSTS1' is not sending configured input identity claim type 'http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress'. 6130fd9c-aa57-b0ac-0000-0c3c2aa42924
04/16/2015 11:40:13.65 w3wp.exe (0x0B18) 0x0640 SharePoint Foundation Claims Authentication fo1t Monitorable STS Call: Failed to issue new security token. Exception: System.ServiceModel.FaultException: The trusted login provider did not supply a token accepted by this farm. at Microsoft.SharePoint.IdentityModel.SPSecurityTokenService.SPRequestInfo.ValidateTrustedLoginRequest(SPRequestSecurityToken request) at Microsoft.SharePoint.IdentityModel.SPSecurityTokenService.GetTokenLifetime(Lifetime requestLifetime) at Microsoft.IdentityModel.SecurityTokenService.SecurityTokenService.Issue(IClaimsPrincipal principal, RequestSecurityToken request) at Microsoft.SharePoint.IdentityModel.SPSecurityTokenService.Issue(IClaimsPrincipal principal, RequestSecurityToken request) 6130fd9c-aa57-b0ac-0000-0c3c2aa42924
Follows is my IDP configuration in Sharepoint.
$map1 = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" -IncomingClaimTypeDisplayName "EmailAddress" -SameAsIncoming
$realm="http://win-3oo8vau2hv9:48077/_trust"
$ap=New-SPTrustedIdentityTokenIssuer -Name "WSO2PassiveSTS1" -Description "WSO2 Identity Server1" –Realm $realm -ClaimsMappings $map1 -ImportTrustCertificate $cert -SignInUrl "https://localhost:9443/passivests" -IdentifierClaim $map1.InputClaimType
Incomming claim type should be http://schemas.xmlsoap.org/ws/2005/05/identity/claims/email
NOT http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"
SAML Token should have a expiry time longer than 10 minutes.
SharePoint uses saml token validity period to determine the lifetime and if the LogonTokenCacheExpirationWindow (which is a setting in SharePoint 10 minutes default) is larger than the lifetime of the assertion, then SharePoint will not allow a user to logon and will redirect back to the IdP, which will redirect back to SharePoint in an endless loop.
Attribute in the SAML response should look like follows
<Attribute AttributeName="email"
AttributeNamespace="http://schemas.xmlsoap.org/ws/2005/05/identity/claims"
>
<AttributeValue>admin#wso2.com</AttributeValue>
</Attribute>

PingFederate SLO - Status Message: Invalid signature

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.