SAML 2.0
I'm trying to help a client figure this out. I do not have access to their ADFS server. I am the Service Provider they are trying to connect to.
IDP initiated SSO is working fine. The client picks our service from the drop-down list and their users log in seamlessly.
SP initiated is failing though. They hit our server, we send the auth request, the user makes their way through ADFS, ADFS POSTs to our ACS URL, and then fails because the assertion does not contain all of the required elements. Conditions, Audience, NameIDPolicy, etc are not there, but Cert and Signature are.
I've googled the crap out of this and can't find anything to share with my client. I am not 100% certain how experienced they are with ADFS and if they have been checking the event logs for errors. Ideas?
Below is the assertion with private info removed:
<samlp:Response ID="_2ffc76ad-1691-43-9b3a-0193d8348" Version="2.0" IssueInstant="2014-12-16T20:29:20.070Z" Destination="https://xxxx.com/samldefault.aspx" Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified" InResponseTo="_290a5f3-4c68-b101-589a07a02a7c" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" >
<Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">http://xxxxxxxx/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="#_2ffc76ad-1691-43f5-9b3a-01936ddd8348" >
<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>DPLGDmOWmjpoSdETBsPE=</ds:DigestValue >
</ds:Reference >
</ds:SignedInfo >
<ds:SignatureValue>xxxxxxxx</ds:SignatureValue >
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#" >
<ds:X509Data >
<ds:X509Certificate>xxxxxxxxx</ds:X509Certificate >
</ds:X509Data >
</KeyInfo >
</ds:Signature >
<samlp:Status >
<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Responder" / >
</samlp:Status >
</samlp:Response>
Figured this out. The client looked through their server logs and found this:
Log Name: AD FS/Admin
Source: AD FS
Date: 12/17/2014 3:53:30 PM
Event ID: 303
Task Category: None
Level: Error
Keywords: AD FS
User: AD\adfssvc
Computer: ADFS01.ad.he-equipment.com
Description:
The Federation Service encountered an error while processing the SAML authentication request.
Additional Data
Exception details:
Microsoft.IdentityModel.Protocols.XmlSignature.SignatureVerificationFailedException: ID4037: The key needed to verify the signature could not be resolved from the following security key identifier 'SecurityKeyIdentifier
Either from their configuration, or by default in ADFS, they needed to import our public certificate. It seems illogical that ADFS would pass the user through to the Service Provider with an incomplete SAML assertion due to it requiring a certificate. However, it works now.
Related
I have got the following SP's Request and IDP's reponse:
<samlp:LogoutRequest xmlns="urn:oasis:names:tc:SAML:2.0:metadata" Destination="https://dev-nnn.oktapreview.com/app/somename_hped800eportal_1/exk8dlkd0tCutHWlj0h7/slo/saml" ID="_af6eaa4a-9d5b-41ce-b265-d39dfdc5248e" Version="2.0" IssueInstant="2016-10-14T12:31:59Z" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"><saml:Issuer xmlns:saml="http://www.w3.org/2005/Atom">https://HPED800E:444/SynPortal/login.aspx</saml:Issuer><saml:NameID xmlns:saml="urn:oasis:names:tc:SAML:2.0:nameid-format:unspecified">CDA_Main\hjami</saml:NameID><samlp:SessionIndex>_d9f07562-3a7f-4c03-a62d-8a985f34058f</samlp:SessionIndex><Signature xmlns="http://www.w3.org/2000/09/xmldsig#"><SignedInfo><CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315" /><SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" /><Reference URI=""><Transforms><Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" /></Transforms><DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" /><DigestValue>bBbMvzSjRc0zc1jtIxmqmkO4bYo=</DigestValue></Reference></SignedInfo><SignatureValue>...5g==</SignatureValue><KeyInfo><X509Data><X509Certificate>...Cw==</X509Certificate></X509Data></KeyInfo></Signature></samlp:LogoutRequest>
<?xml version="1.0" encoding="UTF-8"?><saml2p:LogoutResponse xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" Destination="https://hped800e:444/SynPortal/logout.aspx" ID="id50277036872307661186452042" InResponseTo="_1eef2809-b49e-412e-a0c5-3596e3c0b158" IssueInstant="2016-10-14T00:32:05.949Z" 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://www.okta.com/exk8dlkd0tCutHWlj0h7</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="#id50277036872307661186452042"><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>3k7z8GF3kBemyYm+6+mEbZMSAYw=</ds:DigestValue></ds:Reference></ds:SignedInfo><ds:SignatureValue>...MA==</ds:SignatureValue><ds:KeyInfo><ds:X509Data><ds:X509Certificate>...VNm</ds:X509Certificate></ds:X509Data></ds:KeyInfo></ds:Signature><saml2p:Status xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol"><saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:AuthnFailed"/></saml2p:Status></saml2p:LogoutResponse>
the request is encoded base-64 and then sent via post binding.
I am getting the AuthnFailed response.
I have set up only one sp for the IDP for simplicity.
Does anyone know what I am doing wrong here?
This information is insufficient to determine as what has gone wrong in your implementation for single logout. Can you please provide following information
1) Your single logout settings in Okta that can be found under SAML Settings -> Advanced Settings under General tab of your app?
2) Based on above settings please make sure you have uploaded certificate to Okta?
3) Which SAML toolkit are you using? Can you provide toolkit settings for your toolkit?
See the working SLO request below.
<samlp:LogoutRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
ID="_d2be8c5de3aeeeac27c8xxxxyyyy"
Version="2.0"
IssueInstant="2016-04-27T16:15:06Z"
Destination="https://org-name.okta.com/app/simplesamlphpexample/exk4xxyyPcvdVq70x7/slo/saml"
>
<saml:Issuer>http://localhost:8888/simplesamlphp/www/module.php/saml/sp/metadata.php/example-okta-com</saml: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="#_d1be8c5dc2aeeeac27c8daf04b7xxxyyy6b36287bd6">
<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>{{some_value}}</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>{{some_value}}</ds:SignatureValue>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>{{some_value}}</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</ds:Signature>
<saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">{{email}}</saml:NameID>
<samlp:SessionIndex>{{some_value}}</samlp:SessionIndex>
Comparing the SLO settings for your request and mine few things stood out.
1) CanonicalizationMethod Algorithm in my case is set to http://www.w3.org/2001/10/xml-exc-c14n#. Yours is http://www.w3.org/TR/2001/REC-xml-c14n-20010315.
2) Name ID in your case is "CDA_Main\hjami". Can you please let me know which attribute in Okta is this? Also, have you overridden the userName of your app using the mappings from Okta to app (under profile editor -> your app mappings). For example, I am overriding the app userName from Okta login/email to be custom attribute.
If you are using another attribute (whose value is set to CDA_Main\hjami) from Okta as the username of the app, please make sure that you are overriding it like I am doing in the screenshot above.
I also had a hard time in making this Logout request successfully.
Here is the solution that worked for me:
You'll need the following keys:-
(a) Service provider's (your application's) private key, e.g. sp-pvt-key.pem
(b) Service provider's public key, e.g. sp-pub-key.pem
Note: You can generate these keys via openssl from your terminal.
Steps:
Provide SP's private key on SAML's configuration strategy in you application's code.
Upload SP's public key on okta's logout configuration.
Now you'll get successful logout response.
We have a Single Sign On service connects to our Node.js app on IBM Bluemix. We need to use SAML Enterprise as our identify source. When I upload the SAML 2.0 Identity Provider metadata file - I get the error saying:
Error executing REST service.
FBTRBA331E The action: Import Metadata failed because the metadata file or federation role is invalid.
I also found the error code from another IBM page, but it doesn't say how to fix it.
http://www.ibm.com/support/knowledgecenter/SSELE6_8.0.1.3/com.ibm.isam.doc/messages/messages/FBTRBA331E.html
According to this Bluemix SSO document (scroll down to the SAML metadata files section):
https://console.ng.bluemix.net/docs/services/SingleSignOn/saml_information.html#saml_information
IdP (Identify Provider) metadata file must contain both Signing and Encryption Key sections. If the encryption certificate is missing, you see an upload error indicating that the format of the metadata file is wrong or that improper federation roles exist.
Both of the following KeyDescriptor sections are required.
<md:KeyDescriptor use="signing">
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<X509Data>
<X509Certificate>(...signing certificate...)</X509Certificate>
</X509Data>
</KeyInfo>
</md:KeyDescriptor>
<md:KeyDescriptor use="encryption">
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<X509Data>
<X509Certificate>(...encryption certificate...)</X509Certificate>
</X509Data>
</KeyInfo>
<md:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
</md:KeyDescriptor>
Please double check the metadata file you received from your Identity Provider to see if the encryption section is missing.
I'm not able to make a secured ECP AuthnRequest to my Shibboleth IdP. I've got a small proof of concept SP running which is based heavily on the Spring SAML extension sample app. My SP metadata was generated using the Spring SAML extension sample app's metadata generator. The signing key being used is the apollo one included with the sample app samlKeystore.jks key store, all of which is also in my own small SP app.
In my SP metadata, I have the AuthnRequestsSigned attribute set to true like so :
<md:SPSSODescriptor AuthnRequestsSigned="true" WantAssertionsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
If I set AuthnRequestsSigned to false and make the ECP SOAP POST to the IdP, it works just fine. I get the proper SOAP message back from the IdP. But if that value is true, I get a non-descriptive error message:
<env:Fault>
<faultcode>env:Client</faultcode>
<faultstring>An error occurred processing the request.</faultstring>
<detail/>
</env:Fault>
I look in the Shibboleth (IdP) logs and see:
Attempting to extract credential from an X509Data
Found 1 X509Certificates
Found 0 X509CRLs
Single certificate was present, treating as end-entity certificate
Credentials successfully extracted from child {http://www.w3.org/2000/09/xmldsig#}X509Data by provider org.opensaml.xml.security.keyinfo.provider.InlineX509DataProvider
A total of 1 credentials were resolved
This displays twice in the log for my transaction. My assumption is because it's finding the certificate in the request and in my SP metadata. Further down in the log during this same transaction I see this followed by a stack trace:
Attempting to validate signature using key from supplied credential
Creating XMLSignature object
Validating signature with signature algorithm URI: http://www.w3.org/2000/09/xmldsig#rsa-sha1
Validation credential key algorithm 'RSA', key instance class 'sun.security.rsa.RSAPublicKeyImpl'
Signature did not validate against the credential's key
Signature validation using candidate validation credential failed
Signature did not validate against the credential's key
I compared the certificate that is in the ECP POST AuthnRequest to the one in my SP metadata used for "signing" and they are the same. So I'm not sure why I'm getting this error.
My understanding is that the IdP will take the certificate found in the <ds:X509Certificate> tag of the request (which is the public key) and make sure that's the same one defined in the SP metadata. Then use that cert to verify the signature value which is also in the request in the <ds:SignatureValue> element. If it validates then it moves forward with the AuthnRequest. Is this accurate?
What piece am I missing?
Update 1: I've added the logging lines as suggested and here's all it shows for the ECP requests:
signatureMethodURI = http://www.w3.org/2000/09/xmldsig#rsa-sha1
jceSigAlgorithm = SHA1withRSA
jceSigProvider = SunRsaSign
PublicKey = Sun RSA public key, 2048 bits
modulus: <long value here>
public exponent: 65537
Signature verification failed.
One thing of note, if I make a request to my SP via a browser and I'm not signed in, I get redirected to my IdP login page as expected. I check the IdP logs and see that that request was also signed and it validates. I looked at the form data sent to the IdP from the SP and see that AuthnRequest is also signed using the same certificate but the SignatureValue value are different of course. That non-ECP request data XML looks very similar to the ECP request SOAP XML yet the ECP one fails.
UPDATE 2: I'm using spring-security-saml-1.0.0.RELEASE, and Shibboleth IdP v2.4.0. Here's a sample message I'm sending to the IdP:
<?xml version="1.0" encoding="UTF-8"?>
<soap11:Envelope
xmlns:soap11="http://schemas.xmlsoap.org/soap/envelope/">
<soap11:Header>
</soap11:Header>
<soap11:Body>
<saml2p:AuthnRequest
xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" AssertionConsumerServiceURL="http://1XP21VRS.mydomain.com:8080/proofofconceptapp-sso/saml/SSO/alias/conceptSSO" ForceAuthn="false" ID="a3j6fd01d0ciahe25b56i326bhe212" IsPassive="false" IssueInstant="2014-10-24T19:37:43.207Z" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS" Version="2.0">
<saml2:Issuer
xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">http://1XP21VRS.mydomain.com:8080/proofofconceptapp-sso
</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="#a3j6fd01d0ciahe25b56i326bhe212">
<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>mMJbjpmWr6OMP9eU70RA9TtfXGY=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>I6rHpgjWgl5l5sjst+VHuSUnjUaOBnPIbUrWwcAfdTDSFY2wxUuNdHpXt/YqBfP9ZKdTWZV1IjbTR666T7sa1bZawgT3UO07FoBVAc5z+AH0nCvIz+UNSqpunPTaEdUhSaGmNHSItvFtvz2fDmvZl18GwXrTz4g6vvxKkdo/FijgvYldfYYuO+obcjof1SJmpOOr1iRNvpyGQMxcaH9e07QfJO9SDcLP2elvPvwbJsGGl/n/3sIG+kIm0MECU3hv/4pLx6+SyHDXjdhdOD2HyxGL1t7iIYG1AaDX4dkIt2wH2WOyzhfO2MyykqChhRcYWFdEdgqaQW/IBLPxsVjN9g==</ds:SignatureValue>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>MIIDUjCCAjqgAwIBAgIEUOLIQTANBgkqhkiG9w0BAQUFADBrMQswCQYDVQQGEwJGSTEQMA4GA1UE
CBMHVXVzaW1hYTERMA8GA1UEBxMISGVsc2lua2kxGDAWBgNVBAoTD1JNNSBTb2Z0d2FyZSBPeTEM
MAoGA1UECwwDUiZEMQ8wDQYDVQQDEwZhcG9sbG8wHhcNMTMwMTAxMTEyODAxWhcNMjIxMjMwMTEy
ODAxWjBrMQswCQYDVQQGEwJGSTEQMA4GA1UECBMHVXVzaW1hYTERMA8GA1UEBxMISGVsc2lua2kx
GDAWBgNVBAoTD1JNNSBTb2Z0d2FyZSBPeTEMMAoGA1UECwwDUiZEMQ8wDQYDVQQDEwZhcG9sbG8w
ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCXqP0wqL2Ai1haeTj0alwsLafhrDtUt00E
5xc7kdD7PISRA270ZmpYMB4W24Uk2QkuwaBp6dI/yRdUvPfOT45YZrqIxMe2451PAQWtEKWF5Z13
F0J4/lB71TtrzyH94RnqSHXFfvRN8EY/rzuEzrpZrHdtNs9LRyLqcRTXMMO4z7QghBuxh3K5gu7K
qxpHx6No83WNZj4B3gvWLRWv05nbXh/F9YMeQClTX1iBNAhLQxWhwXMKB4u1iPQ/KSaal3R26pON
UUmu1qVtU1quQozSTPD8HvsDqGG19v2+/N3uf5dRYtvEPfwXN3wIY+/R93vBA6lnl5nTctZIRsyg
0Gv5AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAFQwAAYUjso1VwjDc2kypK/RRcB8bMAUUIG0hLGL
82IvnKouGixGqAcULwQKIvTs6uGmlgbSG6Gn5ROb2mlBztXqQ49zRvi5qWNRttir6eyqwRFGOM6A
8rxj3Jhxi2Vb/MJn7XzeVHHLzA1sV5hwl/2PLnaL2h9WyG9QwBbwtmkMEqUt/dgixKb1Rvby/tBu
RogWgPONNSACiW+Z5o8UdAOqNMZQozD/i1gOjBXoF0F5OksjQN7xoQZLj9xXefxCFQ69FPcFDeEW
bHwSoBy5hLPNALaEUoa5zPDwlixwRjFQTc5XXaRpgIjy/2gsL8+Y5QRhyXnLqgO67BlLYW/GuHE=</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</ds:Signature>
</saml2p:AuthnRequest>
</soap11:Body>
</soap11:Envelope>
I'm pretty much just copying the response from the initial PAOS request to the SP (Spring SAML), removing the header innards, and sending that along to the Shibboleth IdP. The headers that I send are:
Content-Type: text/xml
Authorization: Basic <base64 encoded credential string here>
Update 3: Signed non-ECP AuthnRequests validate just fine. So it's only SOAP ECP AuthnRequests to the IdP where the signature fails. Any ideas?
Update 4: Still can't get this working. Any help would be appreciated.
I am using PingFederate to act both as IdP server and SP server. After which i have OpenToken adapters for each components. And i have created IdP-to-SP Adapter Mapping under Server Configuration setting using the newly created Adapters.
And moving forward to SP CONNECTIONS > IdP Configuration section , i have created a new connection.
After which in Server Configuration > Administrative Functions > MetaData Export , i have exported the newly created SP Connections.
Now when i tried to use the metadata in SP Configuration > IDP Connections > Create New , the export functionality works fine but the data that was supposed to be loaded from the .xml file is not happening.
Here is what my metadata.xml file looks like :
<?xml version="1.0"?>
-<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" entityID="localhost:default:entityId" cacheDuration="PT1440M" ID="Kuvm5eRQl_BYQ27ZVtV4OCcHb.1">
-<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="#Kuvm5eRQl_BYQ27ZVtV4OCcHb.1">
-<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>wn/+y44KVd1I0RfdGVnq7NGW9wc=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue> pX78c96Eq//dZQIRIzEFquvcnzlnrOh4Nnfdfc5BNgdpokdnBEE91Cr20YatuQqHg61XssjVoyLi 4HfzhAqf85ni+p/NyEi8iQx86W3JptmawzkA1nFY8+JD6m/WIblipHh/1l63tF1N0akoNwhbDhky jmiBpPgPc8FxJAOPE7k= </ds:SignatureValue>
-<ds:KeyInfo>
-<ds:X509Data>
<ds:X509Certificate> MIICRzCCAbCgAwIBAgIGAUIOacSJMA0GCSqGSIb3DQEBBQUAMGYxCzAJBgNVBAYTAlVTMQswCQYD VQQIEwJDTzEPMA0GA1UEBxMGRGVudmVyMQwwCgYDVQQKEwNEZXYxDTALBgNVBAsTBFBpbmcxHDAa BgNVBAMTE0NvbmZpZyBTaWduaW5nIENlcnQwIBcNMTMxMDMxMTIwODAxWhgPMjExMzEwMDcxMjA4 MDFaMGYxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJDTzEPMA0GA1UEBxMGRGVudmVyMQwwCgYDVQQK EwNEZXYxDTALBgNVBAsTBFBpbmcxHDAaBgNVBAMTE0NvbmZpZyBTaWduaW5nIENlcnQwgZ8wDQYJ KoZIhvcNAQEBBQADgY0AMIGJAoGBALD4NA4uYzAxWBih6BXwyPSFlw94dolpigT1FrTeT/SGAlAg teWp2Fy2LB0mVm2tSmRyYOi85c8M9jRjaB8SB688C1Q6TqNUvhfhje46GqDuUPxguCXHZsNS9XwM trWwGzm7IenVL1WJ4LHPJI0OYt8qH7nZ6FFUDW0fbuIMMLo/AgMBAAEwDQYJKoZIhvcNAQEFBQAD gYEAkzykqYJasH8Tms2QlFa5HNWL1q8dpbp6ksEOi4E1mL1SZGs7iWM8ltYfMro1mGF/SWWxfStJ EEWiA01AigehJn2w5VPysYZxODBO1jYzRSyZo8hU8ioMcSZTpwgokzUZmMlwDhrbzDQmdh//sbri 1QB59uqG0CwU2/AJV3KU2KM= </ds:X509Certificate>
</ds:X509Data>
-<ds:KeyValue>
-<ds:RSAKeyValue>
<ds:Modulus> sPg0Di5jMDFYGKHoFfDI9IWXD3h2iWmKBPUWtN5P9IYCUCC15anYXLYsHSZWba1KZHJg6Lzlzwz2 NGNoHxIHrzwLVDpOo1S+F+GN7joaoO5Q/GC4Jcdmw1L1fAy2tbAbObsh6dUvVYngsc8kjQ5i3yof udnoUVQNbR9u4gwwuj8= </ds:Modulus>
<ds:Exponent>AQAB</ds:Exponent>
</ds:RSAKeyValue>
</ds:KeyValue>
</ds:KeyInfo>
</ds:Signature>
-<md:IDPSSODescriptor WantAuthnRequestsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
-<md:KeyDescriptor use="signing">
-<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
-<ds:X509Data>
<ds:X509Certificate>MIICRzCCAbCgAwIBAgIGAUIOacSJMA0GCSqGSIb3DQEBBQUAMGYxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJDTzEPMA0GA1UEBxMGRGVudmVyMQwwCgYDVQQKEwNEZXYxDTALBgNVBAsTBFBpbmcxHDAaBgNVBAMTE0NvbmZpZyBTaWduaW5nIENlcnQwIBcNMTMxMDMxMTIwODAxWhgPMjExMzEwMDcxMjA4MDFaMGYxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJDTzEPMA0GA1UEBxMGRGVudmVyMQwwCgYDVQQKEwNEZXYxDTALBgNVBAsTBFBpbmcxHDAaBgNVBAMTE0NvbmZpZyBTaWduaW5nIENlcnQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALD4NA4uYzAxWBih6BXwyPSFlw94dolpigT1FrTeT/SGAlAgteWp2Fy2LB0mVm2tSmRyYOi85c8M9jRjaB8SB688C1Q6TqNUvhfhje46GqDuUPxguCXHZsNS9XwMtrWwGzm7IenVL1WJ4LHPJI0OYt8qH7nZ6FFUDW0fbuIMMLo/AgMBAAEwDQYJKoZIhvcNAQEFBQADgYEAkzykqYJasH8Tms2QlFa5HNWL1q8dpbp6ksEOi4E1mL1SZGs7iWM8ltYfMro1mGF/SWWxfStJEEWiA01AigehJn2w5VPysYZxODBO1jYzRSyZo8hU8ioMcSZTpwgokzUZmMlwDhrbzDQmdh//sbri1QB59uqG0CwU2/AJV3KU2KM=</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</md:KeyDescriptor>
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat>
<md:SingleSignOnService Location="https://localhost:9031/idp/SSO.saml2" Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"/>
</md:IDPSSODescriptor>
<md:ContactPerson contactType="administrative"/>
</md:EntityDescriptor>
And the entityId attribute in .xml file points to localhost:default:entityId but ain't it suppose to be the Partner's Entity Id of SP Connection. It looks like it is extracting value from Server Setting > Federal Info of global server setting.
Question :
So is the entityId supposed to be extracted from Federal Info or SP
Connection ?
How to map SP Connection and IdP connection ?
What are the field that are populated by the metadata.xml file ?
Reference :
Training Video
By default, your entityId is set globally under Server Setting > Federation Info. So that is what you will see when you export generic or connection level meta-data to share with Partners. The value you enter into the actual IDP or SP Connection is your PARTNER'S entityId. In this case, since you are acting as the IDP and SP at the same time, the entityId values will be the same (localhost:default:entityId) in your IDP and SP Connection which can be confusing.
If needed, you can override the server-level default entityId by utilizing the Virtual Server ID which will override the Issuer value for a given connection.
You can find more information on these fields in the PingFedate Admin Guide
--Ian
Building off of #Scott T.'s answer:
...PingFederate (acting as an IdP) knows which SPs you have
federated with in a given session. When the user kicks off SLO (from
the example you gave - at the IdP - it could also be initiated from an
SP) the users browser (assuming a Redirect or POST binding) is sent to
each SP with a SAML LogoutRequest.
When I request https://[PingFederateInstance]/idp/startSLO.ping?PartnerSpId=[PartnerSpId], according to server.log, PingFederate issues only one LogoutRequest.
<samlp:LogoutRequest Destination="https://[PingFederateServerInstance]:[PortNumber]/sp/SLO.saml2" NotOnOrAfter="2011-11-22T23:02:37.812Z" IssueInstant="2011-11-22T22:57:37.812Z" ID="NEDH4Khn4TvWsOwfAZxK_XiEc6f" Version="2.0" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
<saml:Issuer>XXX:IDP</saml: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="#NEDH4Khn4TvWsOwfAZxK_XiEc6f">
<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>Hnec0X3qfYlE2Z9+ooujtD1HKQk=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>L6wmw7RF82s8W2s4YSkwHpnQFo6tFRKUZ3pyK7JEl/7CZyJsxJ5lnfpdaaogm/Gl3S3Y7WoSjbp4
ssaNjtQ3x/nHsYI0zill66yhQ/DNaXAdRuKw6jDi9vqXemkYGx9cNxLkLvc14CUdn9qRA0gZcjyj
ncaZvvWL5Kzy9JOuWSg=</ds:SignatureValue>
</ds:Signature>
<saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">10072824</saml:NameID>
<samlp:SessionIndex>dWh6bd58GRgnbLgeYsTWSVXT7pO</samlp:SessionIndex>
</samlp:LogoutRequest>
My Question:
If I've federated with more than one SP, how should I configure PingFederate so that it issues one request per federated SP?
I'm inclined to believe that:
I need to configure something on this screen.
In agreement with the idea that the multiple SP logout requests are "chained together", the last endpoint URL should be /idp/SLO.saml2.
Let me revise that first answer:
PingFederate knows which SPs you have federated with in a given session.
Should be:
PingFederate acting as the IdP knows which SPs a user has signed into in a given session.
The configuration at PingFederate acting as the IdP would include SLO protocol configuration for each SP connection you have. The screenshot you linked to in (1.) is actually an IdP connection screen, that would be done at PingFederate playing the SP role (maybe that's what you're acting as - it wasn't clear to me in your original query, so I assumed IdP from the nature of your question). You will want to ensure you have configured each SP connection with appropriate SLO endpoints following these instructions. If PingFederate is the IdP it will know to redirect to all SP's that support SLO (and where the user has a session) when a user initiates SLO.
WRT to (2.): If users start the SLO process at the IdP, then yes - users will be redirected back to /idp/SLO.saml2 as the last step. In fact, each SP that you redirect to for logout, will redirect back to the IdP to logout of the next SP. If you start the SLO process from an SP, then the last place users will end up is at that SP's SLO endpoint.