We're setting up SSO with Active Directory and Keycloak and trying to configure IdP initiated login. The Keycloak initiated login works, but the IdP initiated login does not, though the SAML responses for each of those is nearly identical (the only difference being inResponseTo on <SubjectConfirmationData> - this is present on the Keycloak initiated SAML response, but not on the IdP initiated SAML response). I've tried with Keycloak versions 4.3.0 and 4.4.0. The IdP settings can be seen here. The Keycloak error and SAML responses are copied below.
Anyone have any ideas on this error?
When trying to log in with the IdP initiated flow, Keycloak returns this error:
ERROR [org.keycloak.services.error.KeycloakErrorHandler] (default task-62)
Uncaught server error: org.keycloak.broker.provider.IdentityBrokerException:
Could not process response from SAML identity provider.
The SAML response that does get parsed (Keycloak initiated request) is:
<samlp:Response Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified"
Destination="https://localhost:8443/auth/realms/master/broker/saml/endpoint"
ID="_e531b61c-6523-401c-b267-4a0525c80542" InResponseTo="ID_5d20a349-5af1-4bc8-973d-c7186d0685cc"
IssueInstant="2018-09-26T18:15:25.260Z" Version="2.0"
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
<Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">http://greenhouse.westus2.cloudapp.azure.com/adfs/services/trust</Issuer>
<samlp:Status><samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/></samlp:Status>
<Assertion ID="_0afd4f01-b9a0-4819-865c-e96319da773b" IssueInstant="2018-09-26T18:15:25.260Z"
Version="2.0" xmlns="urn:oasis:names:tc:SAML:2.0:assertion">
<Issuer>http://greenhouse.westus2.cloudapp.azure.com/adfs/services/trust</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="#_0afd4f01-b9a0-4819-865c-e96319da773b">
<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>RGUuFFUrcb3z+ncO3nUsg79tnTjPeB4O/87lPVdw1Dw=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>qP+/5mL5Tln8NKu/Rvz0fWjzMQ1W74UtpULH2OCF88hQtJCO0fGEYlI0kaSk7RSCdbDKx8aWvxkIS0Mi+0vMNGtgs5vWvKzzelm6GTbv7PfOByNd6hsyxBttiaowAsF2JreFJYWBXLr1XQTegA5tCmpmBgKlEVLKGyReF/UJj2/afzPmCkt8ACXq7Dx+Af70sHHHm8WNWJ45P0SHy5Yg/CnyhxC3rNh2MgCe3h9JEJNjNCbrchT9jx97Po80f6KABAaejYtTiUdTtzh7ufFDZ78wami5Z5kpE93X3zKj+CCM2wAWqCu0lQLYeP2KGS1ndK4roFU8iEd4rjuQszXXSQ==</SignatureValue>
<KeyInfo>
<ds:X509Data xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:X509Certificate>MIIDBjCCAe6gAwIBAgIQaERD4XNSb6FBU03xlUaYqzANBgkqhkiG9w0BAQsFADA/MT0wOwYDVQQDEzRBREZTIFNpZ25pbmcgLSBncmVlbmhvdXNlLndlc3R1czIuY2xvdWRhcHAuYXp1cmUuY29tMB4XDTE4MDkxNTE2NDc0M1oXDTE5MDkxNTE2NDc0M1owPzE9MDsGA1UEAxM0QURGUyBTaWduaW5nIC0gZ3JlZW5ob3VzZS53ZXN0dXMyLmNsb3VkYXBwLmF6dXJlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAND/YMN2tASHJkCTQKfPW695H0Z0THDVTs6AL2y7NvxBgvwOQv5J9jr+QgQsNAr4QE0+jGZ7Z8TTySzySNn22LEGwOXiz4eW5clwtumHfghj1eN4rQDh+1AKxz0VYP4YXdjFemPrnfctlfEusn+/t2QzjrYzzMbC65AWAzPcCEe/udUZJ97ryzjnGx86SC9RR93d6C+HspRD2Sf+967FMG745czKI6paqQLzKe4iueRe+NEhFqLJgjfSQTwGRX8/dxL4KwNGtT0TxNQKiL6HhisyhwtLt3vDYTLBt4cmaalPJKJTFxwBBimb8L9og4IBMiDM5BHpOnQd68OlZLMCMi8CAwEAATANBgkqhkiG9w0BAQsFAAOCAQEAAqxWIayXbZh1TKQgzGK7fIegHV+hjdHenUdXwzesWv3Wg6tUG/AdVTBn7uPNWV/ne7nCOBN//zwsP/iDD2/FhNDBbHHZz2bU70RDoLPB1TpZ0UkQ6WXILQp57kn4sTCpih5mJ8EwTU17cmcWJps2hpATHbgrHzjOWRqPqgqsXi7/yCYyv4MYQn3efY+HfIgAGc7Ez84ai7OEB2RmRNG93EoUAAR0OZfF+vPelAsdb2lkcb7bji5YKP1lK1mdfI4byFoWyFsnTR0x67EpKu8bOAlIhCaI6tRLT5xi5hMwgEjAplpEF0F2x/KBLPHl829/Y3U6Ze8dUik22imQFwwsEA==</ds:X509Certificate>
</ds:X509Data>
</KeyInfo>
</Signature>
<Subject>
<NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">adminuser#example.com</NameID>
<SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"><SubjectConfirmationData InResponseTo="ID_5d20a349-5af1-4bc8-973d-c7186d0685cc"
NotOnOrAfter="2018-09-26T18:20:25.260Z"
Recipient="https://localhost:8443/auth/realms/master/broker/saml/endpoint"/></SubjectConfirmation>
</Subject>
<Conditions NotBefore="2018-09-26T18:15:25.260Z" NotOnOrAfter="2018-09-26T19:15:25.260Z">
<AudienceRestriction>
<Audience>https://localhost:8443/auth/realms/master</Audience>
</AudienceRestriction>
</Conditions>
<AttributeStatement>
<Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress">
<AttributeValue>adminuser#example.com</AttributeValue>
</Attribute>
</AttributeStatement>
<AuthnStatement AuthnInstant="2018-09-26T18:08:16.444Z"
SessionIndex="_0afd4f01-b9a0-4819-865c-e96319da773b">
<AuthnContext>
<AuthnContextClassRef>urn:federation:authentication:windows</AuthnContextClassRef>
</AuthnContext>
</AuthnStatement>
</Assertion>
</samlp:Response>
The SAML response that does not get parsed (IdP initiated) is:
<samlp:Response Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified"
Destination="https://localhost:8443/auth/realms/master/broker/saml/endpoint"
ID="_89868c3e-98a9-426a-8c49-53b128730584" IssueInstant="2018-09-25T21:22:34.653Z" Version="2.0"
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
<Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">http://greenhouse.westus2.cloudapp.azure.com/adfs/services/trust</Issuer>
<samlp:Status><samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/></samlp:Status>
<Assertion ID="_6968f4ad-d97e-4f46-af2f-cbae662702f8" IssueInstant="2018-09-25T21:22:34.653Z"
Version="2.0" xmlns="urn:oasis:names:tc:SAML:2.0:assertion">
<Issuer>http://greenhouse.westus2.cloudapp.azure.com/adfs/services/trust</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="#_6968f4ad-d97e-4f46-af2f-cbae662702f8">
<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>FyYk5PDcetumqiefCgrNErVTBi52tGJ8kPGMTCByvUA=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>wC9OsDUzNQthY2pLD3hJNgwBceSBvKDcR6AiL2IsQ0A4iGY5tSF0p/YVWyDbe9rLIDcLctn8MQI9FuNCCqMU1QamTtvV1nV9SoPTmMdeC2NgeWnW9HAdg8Sv5tn5bD42E6NAG73RE2fUgWI57rm/+tlt8P3ROdLqXmEaVq5b0wfbqan+QroDxrjn/8oQdUx08mf1P24p37fFtlKWBDW3Oh/gN/0p9MYJIMJ0VjM9jWmoZ0GLz+Zf7NykEB8GzXQfiSWDCiTQfA287TilqpdK1Ni40tUBr1ZEDdqlR1o1gdu4P9rkSJqg1KnB4wwHq1F+cDZ9xVSPBhIBG43jO11D3A==</SignatureValue>
<KeyInfo>
<ds:X509Data xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:X509Certificate>MIIDBjCCAe6gAwIBAgIQaERD4XNSb6FBU03xlUaYqzANBgkqhkiG9w0BAQsFADA/MT0wOwYDVQQDEzRBREZTIFNpZ25pbmcgLSBncmVlbmhvdXNlLndlc3R1czIuY2xvdWRhcHAuYXp1cmUuY29tMB4XDTE4MDkxNTE2NDc0M1oXDTE5MDkxNTE2NDc0M1owPzE9MDsGA1UEAxM0QURGUyBTaWduaW5nIC0gZ3JlZW5ob3VzZS53ZXN0dXMyLmNsb3VkYXBwLmF6dXJlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAND/YMN2tASHJkCTQKfPW695H0Z0THDVTs6AL2y7NvxBgvwOQv5J9jr+QgQsNAr4QE0+jGZ7Z8TTySzySNn22LEGwOXiz4eW5clwtumHfghj1eN4rQDh+1AKxz0VYP4YXdjFemPrnfctlfEusn+/t2QzjrYzzMbC65AWAzPcCEe/udUZJ97ryzjnGx86SC9RR93d6C+HspRD2Sf+967FMG745czKI6paqQLzKe4iueRe+NEhFqLJgjfSQTwGRX8/dxL4KwNGtT0TxNQKiL6HhisyhwtLt3vDYTLBt4cmaalPJKJTFxwBBimb8L9og4IBMiDM5BHpOnQd68OlZLMCMi8CAwEAATANBgkqhkiG9w0BAQsFAAOCAQEAAqxWIayXbZh1TKQgzGK7fIegHV+hjdHenUdXwzesWv3Wg6tUG/AdVTBn7uPNWV/ne7nCOBN//zwsP/iDD2/FhNDBbHHZz2bU70RDoLPB1TpZ0UkQ6WXILQp57kn4sTCpih5mJ8EwTU17cmcWJps2hpATHbgrHzjOWRqPqgqsXi7/yCYyv4MYQn3efY+HfIgAGc7Ez84ai7OEB2RmRNG93EoUAAR0OZfF+vPelAsdb2lkcb7bji5YKP1lK1mdfI4byFoWyFsnTR0x67EpKu8bOAlIhCaI6tRLT5xi5hMwgEjAplpEF0F2x/KBLPHl829/Y3U6Ze8dUik22imQFwwsEA==</ds:X509Certificate>
</ds:X509Data>
</KeyInfo>
</Signature>
<Subject>
<NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">adminuser#example.com</NameID>
<SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"><SubjectConfirmationData NotOnOrAfter="2018-09-25T21:27:34.653Z"
Recipient="https://localhost:8443/auth/realms/master/broker/saml/endpoint"/></SubjectConfirmation>
</Subject>
<Conditions NotBefore="2018-09-25T21:22:34.653Z" NotOnOrAfter="2018-09-25T22:22:34.653Z">
<AudienceRestriction>
<Audience>https://localhost:8443/auth/realms/master</Audience>
</AudienceRestriction>
</Conditions>
<AttributeStatement>
<Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress">
<AttributeValue>adminuser#example.com</AttributeValue>
</Attribute>
</AttributeStatement>
<AuthnStatement AuthnInstant="2018-09-25T20:20:26.139Z"
SessionIndex="_6968f4ad-d97e-4f46-af2f-cbae662702f8">
<AuthnContext>
<AuthnContextClassRef>urn:federation:authentication:windows</AuthnContextClassRef>
</AuthnContext>
</AuthnStatement>
</Assertion>
</samlp:Response>
Related
the following one is my SAML assertion from ADFS
<samlp:Response ID="_69ecb15f-97ad-4d68-b69e-8eb30a37af8e" Version="2.0" IssueInstant="2021-09-21T16:19:29.472Z" Destination="https://localhost:4200/auth/login" Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified" InResponseTo="ml101e1a-1d87-18dc-1b33-198e1d2a1459"
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
<Issuer
xmlns="urn:oasis:names:tc:SAML:2.0:assertion">http://saml.mlads.mi***ic.app/adfs/services/trust
</Issuer>
<samlp:Status>
<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" />
</samlp:Status>
<Assertion ID="_acced75d-5742-49ee-ad54-4f72049d3268" IssueInstant="2021-09-21T16:19:29.471Z" Version="2.0"
xmlns="urn:oasis:names:tc:SAML:2.0:assertion">
<Issuer>http://saml.mlads.m**ic.app/adfs/services/trust</Issuer>
<Subject>
<NameID>Administrator#mlads.m**.app</NameID>
<SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<SubjectConfirmationData InResponseTo="ml101e1a-1d87-18dc-1b33-198e1d2a1459" NotOnOrAfter="2021-09-21T16:24:29.472Z" Recipient="https://localhost:4200/auth/login" />
</SubjectConfirmation>
</Subject>
<Conditions NotBefore="2021-09-21T16:19:29.468Z" NotOnOrAfter="2021-09-21T17:19:29.468Z">
<AudienceRestriction>
<Audience>https://localhost:4200</Audience>
</AudienceRestriction>
</Conditions>
<AuthnStatement AuthnInstant="2021-09-21T16:19:29.404Z" SessionIndex="_acced75d-5742-49ee-ad54-4f72049d3268">
<AuthnContext>
<AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</AuthnContextClassRef>
</AuthnContext>
</AuthnStatement>
</Assertion>
</samlp:Response>
And my sso logout request
<samlp:LogoutRequest ID="_a78ea30f-b1a7-40fc-9a64-a41196d95582"
Version="2.0"
IssueInstant="'''+ datetime.now(pytz.utc).strftime('%Y-%m-%dT%H:%M:%SZ')+'''"
Destination="https://saml.mlads.mindlogic.app/adfs/ls/"
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
<Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">https://localhost:4200</Issuer>
<NameID xmlns="urn:oasis:names:tc:SAML:2.0:assertion">Administrator#mlads.m**.app</NameID>
<samlp:SessionIndex>_12c18cfe-6f98-4322-bdd3-a5685dca9399</samlp:SessionIndex>
</samlp:LogoutRequest>
BUT I AM getting below logout response
<samlp:LogoutResponse ID="_1ff3c824-2e33-4f29-b3d7-a6d52e8d9e41" Version="2.0" IssueInstant="2021-09-21T16:36:28.994Z" Destination="https://localhost:4200/auth/login" Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified" InResponseTo="_a78ea30f-b1a7-40fc-9a64-a41196d95582" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"><Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">http://saml.mlads.***.app/adfs/services/trust</Issuer><samlp:Status><samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Requester" /></samlp:Status></samlp:LogoutResponse>
My following adfs configuration rule
E-mail address -> NameID
but i am always getting "requestor" response instead of "success"
some points to notice
Saml logout request must contain some important parameters like Identity provider(ID), issuer.And this Id in the logout request must match the InResponseTo parameter in the logout response.
The NameID, including format, must exactly match the NameID of the assertion.
<samlp:LogoutRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
ID="ONELOGIN_********** "
Version="2.0" IssueInstant=" "
Destination="https://*******/adfs/services/trust">
<saml:Issuer>https://localhost:4200</saml:Issuer>
//
//
</samlp:LogoutRequest>
3.Check if the SAML request deflate (compression)and encoding is properly done.
though the session index and nameid are the same as long as we tried to initiate from the browser it's not working but if the same request is working when we triggered from the registered application I don't know why if someone explains it would be good.
I have problems with SAMLRequest not being authenticated by nextcloud
<samlp:Response ID="_7b0ef094-ae04-4d2c-a7d1-e9d5e698c278"
Version="2.0"
IssueInstant="2019-05-28T12:19:07.704Z"
Destination="https://192.168.1.136/index.php/apps/user_saml/saml/acs"
Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified"
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
<Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">http://WindowsServer19.server.net/adfs/services/trust</Issuer>
<samlp:Status>
<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" /></samlp:Status>
<Assertion ID="_3acf9e24-2f34-47bf-82fb-97f6d11ab652"
IssueInstant="2019-05-28T12:19:07.703Z"
Version="2.0"
xmlns="urn:oasis:names:tc:SAML:2.0:assertion">
<Issuer>http://WindowsServer19.server.net/adfs/services/trust</Issuer>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
<ds:Reference URI="#_3acf9e24-2f34-47bf-82fb-97f6d11ab652">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /></ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
<ds:DigestValue>0frZvK2y9o8WTDfpB3rBlK+82W4=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>
s4NAgv4ucV5xM6Ig+GsNunpNo5whkJljUec9KtNh00UbRZJ3q2KdzNQ3ZxhpvYudTDqlgzwnenaPmZIcpmgzuqaIiHTStBWUgafZDljZ4/WnQ8SRslMBgRNtuh3NU8qh+0Hgr3k+ngZc1YvlACy+sPeoBxZoFKTC+cwXVeezdlTnPW+IbZ2T1xeLmjz42oelqrnGbsnu6btNgTHzij302YCsbnlKe6wAEw9CvjFCtWPW1dV9iL6FLYkJfPporG9D7FkW+nZoYa8SHns8VRFM97sBKSBcX/csneJiX+7b+hZttw+MPsXmXBgXiU8D0boRjqKByv51fhlhLpKl3HRZZg==
</ds:SignatureValue>
<KeyInfo
xmlns="http://www.w3.org/2000/09/xmldsig#">
<ds:X509Data>
<ds:X509Certificate>
MIIC8DCCAdigAwIBAgIQMCGuwW//8oZPRuZYDplwVTANBgkqhkiG9w0BAQsFADA0MTIwMAYDVQQDEylBREZTIFNpZ25pbmcgLSBXaW5kb3dzU2VydmVyMTkuc2VydmVyLm5ldDAeFw0xOTA1MjMwMTM1MjJaFw0yMDA1MjIwMTM1MjJaMDQxMjAwBgNVBAMTKUFERlMgU2lnbmluZyAtIFdpbmRvd3NTZXJ2ZXIxOS5zZXJ2ZXIubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7VQR25k7qgmSYMhh40HYEdaki0Itff0QfjpABaNLJJYLB51ikpK/PctqXDy2StJqo4ai3wcrM2xjcLKm7pOGpNYYF2Brdf8ae3i+gjh3Ej6vDYWs/YWve2yZarBkUxTSFlCLsUACIu5nuo7JmVU9ptPcmcKqEZamU1U04qt6RJzxKvLOdFa4nT2Nx1jM8lGyo+x4oJ0agaSORURdQQVSfIJMUuEXWufp0qeCRt3KrQHf6NzJYGvDCdF6bu5lsrXma+nEIxvs88qg7P15ntA+HTdxut3M9vLm+P2nvZMfxU+BKScBWpBfKDAkABF3PibCjnlr0pJ0ZUwPGsya180NAQIDAQABMA0GCSqGSIb3DQEBCwUAA4IBAQAl1f4+rQ3jG+8TfTNtnT/VX8DgXLCop8yrypU/i5AHeS9Xwmi2vqPwEkJQLd84ictIVU43NxtQPvj9RT6IjrwSaDqQcwVOcL0ectlp4cy9DsJsGfMPc3LczX6n07dRweCibRT7+aOGUNuBAi5Qwa63e68DEaHbg+hZkAd0G5gfVLvuKLWcGNUhdGAyHSUCZEXKNeWAVcpeL0JQeEAdPoTR1LA78RUW5PH/VMiEwXrB22T535m3z6YoPyrrWQnDBcXWJ5rIHtJPT58sB3VVHnV2VjNSBH+hS5fFOQ8pABmW+Z5ajpfy2DxdhtTaLt0hXuLpFon7b7/5XJI8ut57yG0E
</ds:X509Certificate>
</ds:X509Data>
</KeyInfo>
</ds:Signature>
<Subject>
<NameID>Administrator</NameID>
<SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<SubjectConfirmationData NotOnOrAfter="2019-05-28T12:24:07.704Z"
Recipient="https://192.168.1.136/index.php/apps/user_saml/saml/acs" />
</SubjectConfirmation>
</Subject>
<Conditions NotBefore="2019-05-28T12:19:07.702Z"
NotOnOrAfter="2019-05-28T13:19:07.702Z">
<AudienceRestriction>
<Audience>https://192.168.1.136/index.php/apps/user_saml/saml/metadata</Audience>
</AudienceRestriction>
</Conditions>
<AttributeStatement>
<Attribute Name="http://schemas.microsoft.com/2012/12/certificatecontext/field/issuername">
<AttributeValue>Aleksandar</AttributeValue>
</Attribute>
<Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname">
<AttributeValue>Andric</AttributeValue>
</Attribute>
<Attribute Name="sAMAccountName">
<AttributeValue>Administrator</AttributeValue>
</Attribute>
</AttributeStatement>
<AuthnStatement AuthnInstant="2019-05-28T12:19:07.675Z"
SessionIndex="_3acf9e24-2f34-47bf-82fb-97f6d11ab652">
<AuthnContext>
<AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</AuthnContextClassRef>
</AuthnContext>
</AuthnStatement>
</Assertion>
</samlp:Response>
I am using ADFS as Identity provider and nextcloud as Service Provider, and I can't make them work for 2 weeks. When i click on the sso & saml button on nextcloud http://prntscr.com/nuevag this error occurs and after deleting SAMLRequest and RelayState query parameters and deleting cookies login page is shown http://prntscr.com/nuez9s and after signing in 'Account not provisioned' error appears http://prntscr.com/nuf01w. Log files show http://prntscr.com/nuf0qj but in ADFS, URL is set with https:// http://prntscr.com/nuf11w. Do you have any idea how to make this work. Thank you very much!
You need to trace the SAML request. Either ADFS does not know the Issuer of the SAML AuthnRequest or it may not be able to verify the signature of SAML AuthnRequest (if it was digitally signed).
IdP initiated SSO as shown in https://prnt.sc/nuez9s is a totally different flow, where the IdP only sends a SAML response, there is no SAML AuthnRequest.
ADFS event log would actually show (also sometimes in a somewhat cryptic way) why the SAML AuthnRequest could not be handled.
We need to setup ADFS as a service provider. So, we tried to send saml response to ADFS. We configured stubs for claims provider, RPT and created certs. We try to send saml to adfs/ls/IdpinitiatedSignon.aspx with RelayState.
Here is Saml Response example.
<samlp:Response ID="_6bcc31a5-fcc2-46a6-a84d-0df2cb5bed17" Version="2.0" IssueInstant="2019-03-27T12:37:34.839Z" Destination="https://srv2012-test-dc.testdomain.com/adfs/ls/idpinitiatedsignon.aspx" InResponseTo="_728ac076-7b14-4ce2-8efb-ed5c8c9b85f3" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
<Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">anthem.cn.com</Issuer>
<samlp:Status>
<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
</samlp:Status>
<Assertion ID="_eeaaab87-0fcc-4ec1-93d3-ed623b27130c" IssueInstant="2019-03-27T12:37:41.843Z" Version="2.0" xmlns="urn:oasis:names:tc:SAML:2.0:assertion">
<Issuer>anthem.cn.com</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/2000/09/xmldsig#rsa-sha1"/>
<Reference URI="#_eeaaab87-0fcc-4ec1-93d3-ed623b27130c">
<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/2000/09/xmldsig#sha1"/>
<DigestValue>MkByT8QpjpBFszlr74Rx0IZNewk=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>AYhBtCEl4CrsgsuWMaLEDP...</SignatureValue>
<KeyInfo>
<X509Data>
<X509Certificate>MII...</X509Certificate>
</X509Data>
</KeyInfo>
</Signature>
<Subject>
<NameID>VALERA</NameID>
<SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<SubjectConfirmationData InResponseTo="_728ac076-7b14-4ce2-8efb-ed5c8c9b85f3" NotBefore="2019-03-27T12:32:34.839Z" NotOnOrAfter="2019-03-27T13:37:34.847Z"/>
</SubjectConfirmation>
</Subject>
<Conditions>
<AudienceRestriction>
<Audience>https://beta3dev.test.com/</Audience>
</AudienceRestriction>
</Conditions>
<AuthnStatement AuthnInstant="2019-03-27T12:37:41.843Z" SessionIndex="_56b775bf-32a7-4f35-a370-d707a653a5aa">
<AuthnContext>
<AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</AuthnContextClassRef>
</AuthnContext>
</AuthnStatement>
<AttributeStatement>
<Attribute Name="FirstName">
<AttributeValue>valera</AttributeValue>
</Attribute>
</AttributeStatement>
</Assertion>
</samlp:Response>
It seems to be valid, we checked by online validators, but ADFS throws exception:
Microsoft.IdentityServer.Web.UnsupportedSamlResponseException: MSIS7029: The SAML response has content that is not supported.
So, The question is: What's wrong with saml?
P.S. Actually, we don't know how an idp intiated scenario works. Maybe there is some minimum pack of claims or we can't login because we don't have working stubs. It will be nice to get some more info about this dataflow.
Ok, it's working now.
There is no request in IdP initiated scenario, so we removed all InResponseTo attributes.
AuthnContext changed to PasswordProtectedTransport.
Name Id can be included but there should be no NotBefore attribute.
I've implemented Spring SAML SSO into a JEE6 web application on Wildfly 8.2 for autenticating with ADFS2/3, but at the moment I'm not able to have success into authorization process. Here is it the request/response ping/pong:
<saml2p:AuthnRequest xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol"
AssertionConsumerServiceURL="https://172.19.100.141:8443/saml/SSO"
Destination="MYIDP"
ForceAuthn="false"
ID="a1be1ie43303d6ei1fa8je1fdd1jhh4"
IsPassive="false"
IssueInstant="2015-10-05T16:52:54.680Z"
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Version="2.0"
>
<saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">SPENTITY</saml2:Issuer>
Response:
<samlp:Response ID="_c644ea1a-88e9-4022-a9fc-52071d0e67bc"
Version="2.0"
IssueInstant="2015-10-05T16:52:54.658Z"
Destination="https://172.19.100.141:8443/saml/SSO"
Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified"
InResponseTo="a1be1ie43303d6ei1fa8je1fdd1jhh4"
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
>
<Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">IDP/adfs/services/trust</Issuer>
<samlp:Status>
<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" />
</samlp:Status>
<EncryptedAssertion xmlns="urn:oasis:names:tc:SAML:2.0:assertion">
<xenc:EncryptedData Type="http://www.w3.org/2001/04/xmlenc#Element"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
>
<xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc" />
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<e:EncryptedKey xmlns:e="http://www.w3.org/2001/04/xmlenc#">
<e:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p">
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
</e:EncryptionMethod>
<KeyInfo>
<ds:X509Data xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:X509IssuerSerial>
<ds:X509IssuerName>MY ISSUER RDATA</ds:X509IssuerName>
<ds:X509SerialNumber>686142642</ds:X509SerialNumber>
</ds:X509IssuerSerial>
</ds:X509Data>
</KeyInfo>
<e:CipherData>
<e:CipherValue>VAL</e:CipherValue>
</e:CipherData>
</e:EncryptedKey>
</KeyInfo>
<xenc:CipherData>
<xenc:CipherValue>VAL</xenc:CipherValue>
</xenc:CipherData>
</xenc:EncryptedData>
</EncryptedAssertion>
When I reach more than 6 request in the last two minutes, ADFS drops the connection and I receive an error. What's the possible error? I've added all required keys to my keystore, why the client keeps on requesting even if the status code response's field has been successfull?
The problem was useReferer property setted to true for SavedRequestAwareAuthenticationSuccessHandler
<!-- Handler deciding where to redirect user after successful login -->
<beans:bean id="successRedirectHandler" class="org.springframework.security.web.authentication.SavedRequestAwareAuthenticationSuccessHandler">
<!-- <beans:property name="useReferer" value="true"/> -->
<beans:property name="defaultTargetUrl" value="/dispatcher"/>
</beans:bean>
We are currently implementing SSO in RightNow for customers in Customer Portal using SAML 2.0 with ADFS 2.0, but the process is returning the error code 17: "SSO_CONTACT_TOKEN_VALIDATE_FAILED"
IdP generates a signed SAML 2.0 assertion using contact info (the customer’s login name as the assertion subject).
ADFS 2.0 submits the follow assertion using HTTP POST binding:
<samlp:Response ID="_f1e96bb3-3585-4d38-b708-33c8c023a3f1"
Version="2.0"
IssueInstant="2015-02-17T12:20:03.666Z"
Destination="https://company.custhelp.com/ci/openlogin/saml/subject/contact.login"
Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified"
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
>
<Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">http://adfs.company.com/adfs/services/trust/</Issuer>
<samlp:Status>
<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" />
</samlp:Status>
<Assertion ID="_5cd4e6a7-0d5a-4010-9979-46cf372b8e35"
IssueInstant="2015-02-17T12:20:03.666Z"
Version="2.0"
xmlns="urn:oasis:names:tc:SAML:2.0:assertion"
>
<Issuer>http://adfs.company.com/adfs/services/trust/</Issuer>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
<ds:Reference URI="#_5cd4e6a7-0d5a-4010-9979-46cf372b8e35">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
<ds:DigestValue>QlfQBozfBOCdd4aKqfiqQPTftuQ=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>EEBAxrW+VHXofNuYPBpzlFR7FZ1Ty4UUOXPFGs3PneU9mSPTpoSAh3BaP/xt2smbmdcj0QWoz00pLZa4KLwUdPdJrKMSqeDwYMvKiNVyQoAbbcS8TzOiFmPdWEgVRIsOY5C/TXjq+aKjnKOwGndTCc9eDvgnlsmo622yP2zHdnLXHlvLfWaPX27CabbYWFjz2ubnpE7Cn5eIcwAZ3VA9qEy3vJvvuBcXfHZ180pHtazNPChI4VycLyNBxzJ92sxkEIsrJZ3X7rqfO6C2IlxTeOHFsvPWCqI05i/IGodGE03x+r1AOc+Qx1fkhAC7TnU96XWjdBJa0lkhQaZtmg7TvQ==</ds:SignatureValue>
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<ds:X509Data>
<ds:X509Certificate>MIIFjDCCBHSgAwIBAgIQevLn+V2Y03FErSWKT1CvDjANBgkqhkiG9w0BAQUFADB7MQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxLDAqBgNVBAMTI1N5bWFudGVjIENsYXNzIDMgRVYgU1NMIFNHQyBDQSAtIEcyMB4XDTE0MTAzMDAwMDAwMFoXDTE1MTEyNDIzNTk1OVowggEAMRMwEQYLKwYBBAGCNzwCAQMTAkNIMR0wGwYDVQQPExRQcml2YXRlIE9yZ2FuaXphdGlvbjEZMBcGA1UEBRMQQ0gtNjYwLTAzMzI5NzItNjELMAkGA1UEBhMCQ0gxDTALBgNVBBEUBDEyMTcxDzANBgNVBAgTBkdlbmV2YTEPMA0GA1UEBxQGTWV5cmluMR0wGwYDVQQJFBQ3LCBydWUgZGUgbGEgQmVyZ2VyZTEXMBUGA1UEChQORmlybWVuaWNoIFMuQS4xHDAaBgNVBAsUE0luZm9ybWF0aW9uIFN5c3RlbXMxGzAZBgNVBAMUEmFkZnMuZmlybWVuaWNoLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAIzG9LYQQxLWjyJ8y4i1DZ9ygSvEPM5jV3GE/J683bFijqt09amec/r3t7LtsZMBEcjyI5Z25vGV8jAcJgpD0Vf980iP9igaFEnlmE4LvPpGMc5uPOv2q+GhPa+TScCefB3HfSbk7d6KShdrAjtQyE+xS11gEHELTHVxyGFbK37Py0P31OTSAYcxP30M0569bl5D0YnkiKmyeEzjXG3novMGFU9xNye15xqmRyoZggc6y/M8QI6BAly9IRm2AiU+wqB0uIT+hUSOseFR/+QU10ZEhKGObro2gbk6x3MueF1MXwY4ngfqE/1eYm9hSte4RFFTox80CetZYlUudy9pqT0CAwEAAaOCAYMwggF/MB0GA1UdEQQWMBSCEmFkZnMuZmlybWVuaWNoLmNvbTAJBgNVHRMEAjAAMA4GA1UdDwEB/wQEAwIFoDA0BgNVHSUELTArBggrBgEFBQcDAQYIKwYBBQUHAwIGCWCGSAGG+EIEAQYKKwYBBAGCNwoDAzBmBgNVHSAEXzBdMFsGC2CGSAGG+EUBBxcGMEwwIwYIKwYBBQUHAgEWF2h0dHBzOi8vZC5zeW1jYi5jb20vY3BzMCUGCCsGAQUFBwICMBkaF2h0dHBzOi8vZC5zeW1jYi5jb20vcnBhMB8GA1UdIwQYMBaAFEZPweCI2n3TeJvIblkvsOT3HZDiMCsGA1UdHwQkMCIwIKAeoByGGmh0dHA6Ly9zdS5zeW1jYi5jb20vc3UuY3JsMFcGCCsGAQUFBwEBBEswSTAfBggrBgEFBQcwAYYTaHR0cDovL3N1LnN5bWNkLmNvbTAmBggrBgEFBQcwAoYaaHR0cDovL3N1LnN5bWNiLmNvbS9zdS5jcnQwDQYJKoZIhvcNAQEFBQADggEBAEjH4BlvVtmV5umudidFRNTTznHVKZD59O3rLGAtC9FoBptA5hstYCu2GxRd2GOouWPYPzoKmNmruSmJmHIzmzoalZ27g4cUYh4kMod/91OEkkFs0E7xXWSVQ1BjZXhdBeFbQ5/rjCEcV8i9uiJuBHioA7s16mkDqN6PFqATYFq2hvZbb0/yPfOrKGFGnz5IxgegSEos1sC6GmFqR5yGxnwXVC5/stXJYmflDFrD/jNZ1995SD4EMXto9SlUcoabj/EelA955x6tjxt9FQUdB9rUI5ahQSrQ/iT1vZ3iCRmlc1Wts/kuYhaq8khggRmmbuBCBh43PIPfvxmrRkdX7XQ=</ds:X509Certificate>
</ds:X509Data>
</KeyInfo>
</ds:Signature>
<Subject>
<NameID>PHL</NameID>
<SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<SubjectConfirmationData NotOnOrAfter="2015-02-17T12:25:03.666Z"
Recipient="https://xerox-firmenich.custhelp.com/ci/openlogin/saml/subject/contact.login"
/>
</SubjectConfirmation>
</Subject>
<Conditions NotBefore="2015-02-17T12:15:03.666Z"
NotOnOrAfter="2015-02-17T13:15:03.666Z"
>
<AudienceRestriction>
<Audience>https://company.custhelp.com</Audience>
</AudienceRestriction>
</Conditions>
<AuthnStatement AuthnInstant="2015-02-17T12:20:03.620Z"
SessionIndex="_5cd4e6a7-0d5a-4010-9979-46cf372b8e35"
>
<AuthnContext>
<AuthnContextClassRef>urn:federation:authentication:windows</AuthnContextClassRef>
</AuthnContext>
</AuthnStatement>
</Assertion>
Could be the problem in the SAML assertion?
Usually, this error means that your certificate is either not included in the assertion, or the thumbprint that you've added to your service cloud configuration doesn't match the certificate passed in the assertion. Since you have a certificate, I would focus on the thumbprint. Sometimes, people copy and paste the thumbprint into Service Cloud (RightNow) settings and accidentally copy a return carriage \n or invisible character. Service Cloud considers these characters as part of the thumbprint and will cause this error code if that is the case. Based on the certificate in your example above, that value should be:
39:c6:48:3b:4e:e3:dd:53:c1:58:88:11:c9:33:28:2a:d5:6c:7f:17