Loop between ADFS and Spring-SAML application - wildfly

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>

Related

Getting Error while trying to access nextcloud through sso

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.

How to consume SAMLResponse using ADFS?

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.

Keycloak error parsing SAML response in IdP initiated SSO

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>

How to implement single logout using okta as IDP?

In Okta developer account I have enabled the SAML Single Logout and get Identity Provider Single Logout URL. I have created following logout request using NameID and SessionIndex obtained from SAML response that we get during single sign-on process.
Logout Request :
<?xml version="1.0" encoding="UTF-8"?>
<samlp:LogoutRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" Destination="https://dev-6#####.oktapreview.com/app/nepasoftdev660864_spdemo_1/exk606bnr5BZOBF7z0h7/slo/saml" ID="_b2be5dbd-928a-4554-a879-25a179e36ee2" IssueInstant="2016-03-25T10:20:47Z" Version="2.0">
<saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">http://192.###.###.##/spdemo</saml:Issuer>
<saml:NameID xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">ramesh.shrestha#nepasoft.com</saml:NameID>
<samlp:SessionIndex>id1458901238038.94596883</samlp:SessionIndex>
</samlp:LogoutRequest>
I am getting the following Logout Response with status code RequestDenied
<?xml version="1.0" encoding="UTF-8"?>
<saml2p:LogoutResponse xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" Destination="http://localhost:10262/Logout.aspx" ID="id1846510753301801884197562" InResponseTo="_b2be5dbd-928a-4554-a879-25a179e36ee2" IssueInstant="2016-03-25T10:22:40.389Z" Version="2.0">
<saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">http://192.###.###.##/spdemo</saml2: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="#id1846510753301801884197562">
<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>LQwvto+ERXvrQRUB7LOUUznSXII=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>P+T1K.....ZYvCw==</ds:SignatureValue>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>MIID.....7zK0rH</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</ds:Signature>
<saml2p:Status>
<saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:RequestDenied" />
</saml2p:Status>
</saml2p:LogoutResponse>
Why might be the reason for getting RequestDenied status? Did i missed something on logout request or misconfigured during enabling single logout in Okta?
Thanks in advanced.
You also need to sign the LogoutRequest so you would need to include a Signature element (similar to what you are getting back in the LogoutResponse).
That said, I'm running into the same issue you are. I have signed my LogoutRequest but am still getting a LogoutResponse with status RequestDenied.
I did find this thread (https://support.okta.com/help/answers?id=906F0000000I07YIAS) on Okta's support page which indicates that the HTTP-Redirect binding is not supported for logout so you may need to you HTTP-Post. I've not tried that yet.

RightNow SSO with ADFS 2.0

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