I am trying to set the signing and encryption option on my SP metadata to have AuthnRequestsSigned="true" but my AM server keeps throwing the below Error in the /debug/Federation log
Authentication Requests Signed option is the only one giving me issues.
Im running
ForgeRock Access Management 6.5.2
Tomcat 8.0.35
openjdk version "1.8.0_212"
AM Settings
Error Message
libSAML2:08/02/2019 03:16:50:299 PM UTC: Thread[http-nio-80-exec-8,5,main]: TransactionId[f1638b0a-6687-4953-ae04-8ce8c9299079-62363]
ERROR: UtilProxySAMLAuthenticator.authenticate: authn request destination verification failed for
IdpEntity: http://x.canadacentral.cloudapp.azure.com:80/opensso
MetaAlias: /idp Destination: http://x.canadacentral.cloudapp.azure.com/opensso/SSORedirect/metaAlias/idp
Location: http://x.canadacentral.cloudapp.azure.com:80/opensso/SSORedirect/metaAlias/idp
SP Meta-data
<?xml version="1.0"?>
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" validUntil="2019-08-02T12:04:36Z"
cacheDuration="PT604800S" entityID="nestjs-sp-signed-0070">
<md:SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="true"
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>...
</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</md:KeyDescriptor>
<md:KeyDescriptor use="encryption">
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:X509Data>
<ds:X509Certificate>...
</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
<md:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
</md:KeyDescriptor>
<md:NameIDFormat>
urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
</md:NameIDFormat>
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"
Location="http://localhost:3000/auth/logout/callback"/>
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Location="http://localhost:3000/auth/login/callback" index="0"/>
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:1.0:profiles:browser-post"
Location="http://localhost:3000/auth/login/callback" index="1"/>
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"
Location="http://localhost:3000/auth/login/callback" index="2"/>
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:1.0:profiles:artifact-01"
Location="http://localhost:3000/auth/login/callback" index="3"/>
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:profiles:holder-of-key:SSO:browser"
Location="http://localhost:3000/auth/login/callback" index="4"/>
</md:SPSSODescriptor>
</md:EntityDescriptor>
Passport Settings
export const samlPassportConf = {
issuer: 'nestjs-sp-signed-0070', // match metadata entityID
identifierFormat: 'urn:oasis:names:tc:SAML:2.0:nameid-format:persistent',
callbackUrl: 'http://localhost:3000/auth/login/callback',
entryPoint: 'http://x.canadacentral.cloudapp.azure.com/opensso/SSORedirect/metaAlias/idp',
logoutUrl: 'http://x.canadacentral.cloudapp.azure.com/opensso/IDPSloRedirect/metaAlias/idp',
privateCert: fs.readFileSync('cert/privatekey.pem', 'utf-8'),
decryptionPvk: fs.readFileSync('cert/privatekey.pem', 'utf-8'),
};
Question:
I am trying to set the signing and encryption option on my SP metadata to have AuthnRequestsSigned="true" but my AM server keeps throwing the below Error in the /debug/Federation log
(1) Authentication Requests Signed option is the only one giving me issues.
(2) I unchecked authentication requests signed and it works.
Answer:
(1) You unchecked authentication requests signed, indicating that OpenAM SAML IdP would never verify the signature of authentication request sent by your SAML SP, thus it works as you expected.
(2) Your SAML SP signs Authentication Request using a signing key.
OpenAM SAML IdP uses the corresponding public cert (which it extracts from your SAML SP metadata) to verify the signed Authentication Request sent by your SAML SP.
If the Authentication Request is signed, OpenAM SAML IdP MUST verify Destination (i.e., SAML Login URL/Entrypoint of SAML IdP) and entityID of SAML SP.
Two issues have been identified:
(I) Destination "http://x.canadacentral.cloudapp.azure.com/opensso/SSORedirect/metaAlias/idp"
does NOT exactly matches the location/entryPoint
"http://idp5.canadacentral.cloudapp.azure.com/opensso/SSORedirect/metaAlias/idp"
Your SAML SP sends "idp5.canadacentral", but OpenAM SAML IdP receives "x.canadacentral"
(II) issuer: 'nestjs-sp-signed-0070' in the Authentication Request sent by your SAML SP
does NOT match
entityID="nestjs-sp-signed-0090"
in your SAMP SP metadata uploaded to OpenAM SAML IdP.
Resolution:
In your Passport Settings, Replace 'nestjs-sp-signed-0070' with 'nestjs-sp-signed-0090', because OpenAM SAML IdP MUST verify that entityID of your SAML SP 'nestjs-sp-signed-0070' carried by the Authentication Request should be exactly equal to entityID of your SAML SP 'nestjs-sp-signed-0090' in your SAML SP metadata.
(III) You need to ensure that private key and public cert should be a key pair. that is,
private key "privateCert: fs.readFileSync('cert/privatekey.pem', 'utf-8')" in your Passport Settings
should be corresponding to
public cert in your SAML SP metadata
<md:KeyDescriptor use="signing">
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:X509Data>
<ds:X509Certificate>...
</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</md:KeyDescriptor>
Potential root cause of Authentication Requests Signed is that
OpenAM SAML IdP uses the public cert of encryption (carried by your SAML SP metadata) to verify the signed Authentication Request. That is, OpenAM SAML IdP uses the wrong public cert for signature verification.
Resolution:
Use the same key pair for both signing and encryption. In your SAML SP metadata, let both signing cert and encryption cert "" be the same, that is,
<md:KeyDescriptor use="signing">
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:X509Data>
<ds:X509Certificate>...
</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</md:KeyDescriptor>
is the same as
<md:KeyDescriptor use="encryption">
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:X509Data>
<ds:X509Certificate>...
</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
<md:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
</md:KeyDescriptor>
Related
I am trying to configure my application (SP) to work with remote IDP. The IDP provided me with a certificate to configure with SP. For SAML request.
I get this exception :
org.springframework.security.saml.trust.UntrustedCertificateException: Peer SSL/TLS certificate XXX, issued by XXX is not trusted, add the certificate or it's CA to your trust store and optionally update tlsKey in >extended metadata with the certificate's alias.
Follow certificates (in PEM format) presented by the peer. Content between being/end certificate (including) can be stored in a file and imported using keytool, e.g. 'keytool -importcert -file cert.cer -alias certAlias -keystore keystore.jks'). Make sure the presented certificates are issued by your trusted CA before adding them to the keystore.
why i get this exception?
I am using gluu server and it's shibboleth component.in SP there is an apollo.cert and a samlkeystore.jks . apollo.crt is imported in samlkeystore.jks .
I run SP and get metadadata.xml (it contains ds:X509Certificate) and import this file into gluu server .
I am confused , where is the problem ? IDP or SP?what can i do to fix that?
I really need help.
EDIT :
#Bernahrd,#Guillermo thank you so much for your reply.
I still working but can't find out what happen here.
I add metadata xml file in idp and sp .
this is gluu idp metadata , to generate idp metadata on gluu server I use https://hostname/idp/shibboleth
<?xml version="1.0" encoding="UTF-8"?>
<EntityDescriptor entityID="https://ubuntu.gluu.info/idp/shibboleth" xmlns="urn:oasis:names:tc:SAML:2.0:metadata"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:shibmd="urn:mace:shibboleth:metadata:1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<IDPSSODescriptor errorURL="https://ubuntu.gluu.info/identity/feedback.htm"
protocolSupportEnumeration="urn:mace:shibboleth:1.0 urn:oasis:names:tc:SAML:1.1:protocol urn:oasis:names:tc:SAML:2.0:protocol">
<Extensions>
<shibmd:Scope regexp="false">ubuntu.gluu.info</shibmd:Scope>
</Extensions>
<KeyDescriptor>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>MIIDaDCCAlACCQD165zhtG0q6DANBgkqhkiG9w0BAQsFADB2MQswCQYDVQQGEwJJ
UjELMAkGA1UECAwCVEgxDzANBgNVBAcMBnRlaHJhbjENMAsGA1UECgwER0xVVTEZ
MBcGA1UEAwwQdWJ1bnR1LmdsdXUuaW5mbzEfMB0GCSqGSIb3DQEJARYQc3VwcG9y
dEBnbHV1Lm9yZzAeFw0xNjA2MTcyMDMxMTlaFw0xNzA2MTcyMDMxMTlaMHYxCzAJ
BgNVBAYTAklSMQswCQYDVQQIDAJUSDEPMA0GA1UEBwwGdGVocmFuMQ0wCwYDVQQK
DARHTFVVMRkwFwYDVQQDDBB1YnVudHUuZ2x1dS5pbmZvMR8wHQYJKoZIhvcNAQkB
FhBzdXBwb3J0QGdsdXUub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC
AQEAuSkeEK+lK498Yc8OspdYoqoDQLDPs8cF0qE84hLRhdEHU1y++/dzaC6271sV
KtTXt/aG1PwBS7unPIMOEKFNJXdO0FHEgt4nkuhq7KUvcR4ckNvL+5Ys5r/3Egzh
8nm96Z0jtuUlu1e8b6iAsw+9tYq1olDZO9Hv6hR9V/ZlTolmuZqnXEy3p/47W25p
ROLVuR7jIH+cKDVJe8lW1702wWEQWDhxPBJ1fJsMuBA/RiB/J6SBAgkxs/9m513Y
+lYaobhqMfocwzt/GAqsq4Fnixf1PldJpi/ZJfnyJ0JOFcLj8YHY/CFRiRm8b3UE
1VUYZRTHK9Qc3ryd+KA14QTymwIDAQABMA0GCSqGSIb3DQEBCwUAA4IBAQBRS5aR
CSPS+3qoWI5wj3f97QEncv0Q80sb0tzumUJIWqDoYWW0ucyRWGiUSSVIBeVJmmmG
Yus9ML6Khb1WNCsXZW3GcBfoA8FImTtTBMyXWHpDtR6Ne156kSv2ymmdyipZo6OB
iItWjEgAOmRsynxkJASEPhH5RM8iqGAJVBCgU738so0X3e7N5pQSNMKLiCkf8afK
EsL9Q61f9RiLImlehkdw3m2B0wKQJZo1Q1D/L7sZzaOXiif3YkcVNO8t0CJpZSog
YSKS+2cM7LTDdiNS3YMpcRdcvZTixDMSAfO+7PDTfubio8ADAmjr7Gj7vwzG8sFi
PmIqbqM/Ii1e0kD7
</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</KeyDescriptor>
<ArtifactResolutionService Binding="urn:oasis:names:tc:SAML:1.0:bindings:SOAP-binding"
Location="https://ubuntu.gluu.info:9443/idp/profile/SAML1/SOAP/ArtifactResolution"
index="1"/>
<ArtifactResolutionService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"
Location="https://ubuntu.gluu.info:9443/idp/profile/SAML2/SOAP/ArtifactResolution"
index="2"/>
<NameIDFormat>urn:mace:shibboleth:1.0:nameIdentifier</NameIDFormat>
<NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</NameIDFormat>
<NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</NameIDFormat>
<SingleSignOnService Binding="urn:mace:shibboleth:1.0:profiles:AuthnRequest"
Location="https://ubuntu.gluu.info/idp/profile/Shibboleth/SSO"/>
<SingleSignOnService Binding="urn:mace:shibboleth:2.0:profiles:AuthnRequest"
Location="https://ubuntu.gluu.info/idp/profile/SAML2/Unsolicited/SSO"/>
<SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Location="https://ubuntu.gluu.info/idp/profile/SAML2/POST/SSO"/>
<SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign"
Location="https://ubuntu.gluu.info/idp/profile/SAML2/POST-SimpleSign/SSO"/>
<SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"
Location="https://ubuntu.gluu.info/idp/profile/SAML2/Redirect/SSO"/>
</IDPSSODescriptor>
<AttributeAuthorityDescriptor
protocolSupportEnumeration="urn:oasis:names:tc:SAML:1.1:protocol urn:oasis:names:tc:SAML:2.0:protocol">
<Extensions>
<shibmd:Scope regexp="false">ubuntu.gluu.info</shibmd:Scope>
</Extensions>
<KeyDescriptor>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>MIIDaDCCAlACCQD165zhtG0q6DANBgkqhkiG9w0BAQsFADB2MQswCQYDVQQGEwJJ
UjELMAkGA1UECAwCVEgxDzANBgNVBAcMBnRlaHJhbjENMAsGA1UECgwER0xVVTEZ
MBcGA1UEAwwQdWJ1bnR1LmdsdXUuaW5mbzEfMB0GCSqGSIb3DQEJARYQc3VwcG9y
dEBnbHV1Lm9yZzAeFw0xNjA2MTcyMDMxMTlaFw0xNzA2MTcyMDMxMTlaMHYxCzAJ
BgNVBAYTAklSMQswCQYDVQQIDAJUSDEPMA0GA1UEBwwGdGVocmFuMQ0wCwYDVQQK
DARHTFVVMRkwFwYDVQQDDBB1YnVudHUuZ2x1dS5pbmZvMR8wHQYJKoZIhvcNAQkB
FhBzdXBwb3J0QGdsdXUub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC
AQEAuSkeEK+lK498Yc8OspdYoqoDQLDPs8cF0qE84hLRhdEHU1y++/dzaC6271sV
KtTXt/aG1PwBS7unPIMOEKFNJXdO0FHEgt4nkuhq7KUvcR4ckNvL+5Ys5r/3Egzh
8nm96Z0jtuUlu1e8b6iAsw+9tYq1olDZO9Hv6hR9V/ZlTolmuZqnXEy3p/47W25p
ROLVuR7jIH+cKDVJe8lW1702wWEQWDhxPBJ1fJsMuBA/RiB/J6SBAgkxs/9m513Y
+lYaobhqMfocwzt/GAqsq4Fnixf1PldJpi/ZJfnyJ0JOFcLj8YHY/CFRiRm8b3UE
1VUYZRTHK9Qc3ryd+KA14QTymwIDAQABMA0GCSqGSIb3DQEBCwUAA4IBAQBRS5aR
CSPS+3qoWI5wj3f97QEncv0Q80sb0tzumUJIWqDoYWW0ucyRWGiUSSVIBeVJmmmG
Yus9ML6Khb1WNCsXZW3GcBfoA8FImTtTBMyXWHpDtR6Ne156kSv2ymmdyipZo6OB
iItWjEgAOmRsynxkJASEPhH5RM8iqGAJVBCgU738so0X3e7N5pQSNMKLiCkf8afK
EsL9Q61f9RiLImlehkdw3m2B0wKQJZo1Q1D/L7sZzaOXiif3YkcVNO8t0CJpZSog
YSKS+2cM7LTDdiNS3YMpcRdcvZTixDMSAfO+7PDTfubio8ADAmjr7Gj7vwzG8sFi
PmIqbqM/Ii1e0kD7
</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</KeyDescriptor>
<AttributeService Binding="urn:oasis:names:tc:SAML:1.0:bindings:SOAP-binding"
Location="https://ubuntu.gluu.info:9443/idp/profile/SAML1/SOAP/AttributeQuery"/>
<AttributeService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"
Location="https://ubuntu.gluu.info:9443/idp/profile/SAML2/SOAP/AttributeQuery"/>
<NameIDFormat>urn:mace:shibboleth:1.0:nameIdentifier</NameIDFormat>
<NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</NameIDFormat>
<NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</NameIDFormat>
</AttributeAuthorityDescriptor>
</EntityDescriptor>
Then I add it to SP in shibboleth-idb.xml
this is my SP metadata file that should be add to the gluu idp :
<?xml version="1.0" encoding="UTF-8"?>
<md:EntityDescriptor ID="http://ubuntu.gluu.info:9090/saml/metadata/alias/defaultAlias"
entityID="http://ubuntu.gluu.info:9090/saml/metadata/alias/defaultAlias"
xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata">
<md:SPSSODescriptor AuthnRequestsSigned="true" WantAssertionsSigned="true"
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>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>
</md:KeyDescriptor>
<md:KeyDescriptor use="encryption">
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<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>
</md:KeyDescriptor>
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Location="http://ubuntu.gluu.info:9090/saml/SingleLogout/alias/defaultAlias"/>
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"
Location="http://ubuntu.gluu.info:9090/saml/SingleLogout/alias/defaultAlias"/>
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat>
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat>
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</md:NameIDFormat>
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat>
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName</md:NameIDFormat>
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"
Location="http://ubuntu.gluu.info:9090/saml/SSO/alias/defaultAlias" index="0"
isDefault="true"/>
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Location="http://ubuntu.gluu.info:9090/saml/SSO/alias/defaultAlias" index="1"/>
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS"
Location="http://ubuntu.gluu.info:9090/saml/SSO/alias/defaultAlias" index="2"/>
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:profiles:holder-of-key:SSO:browser"
Location="http://ubuntu.gluu.info:9090/saml/HoKSSO/alias/defaultAlias"
hoksso:ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"
index="3"
xmlns:hoksso="urn:oasis:names:tc:SAML:2.0:profiles:holder-of-key:SSO:browser"/>
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:profiles:holder-of-key:SSO:browser"
Location="http://ubuntu.gluu.info:9090/saml/HoKSSO/alias/defaultAlias"
hoksso:ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" index="4"
xmlns:hoksso="urn:oasis:names:tc:SAML:2.0:profiles:holder-of-key:SSO:browser"/>
</md:SPSSODescriptor>
</md:EntityDescriptor>
in gluu server I add new trust relationship and add SP metadata file to it.
but some thing strange happen here,In SP index page i select shibolleth idp,then login page of shibolleth idp appears,after enter username and password it redirect to my SP and then Exception happen, according to the exception,idp send me this certificate and want me to add this to my trust store :
-----BEGIN CERTIFICATE-----
MIIDaDCCAlACCQDTFXuxD0vSJTANBgkqhkiG9w0BAQsFADB2MQswCQYDVQQGEwJJUjELMAkGA1UE
CAwCVEgxDzANBgNVBAcMBnRlaHJhbjENMAsGA1UECgwER0xVVTEZMBcGA1UEAwwQdWJ1bnR1Lmds
dXUuaW5mbzEfMB0GCSqGSIb3DQEJARYQc3VwcG9ydEBnbHV1Lm9yZzAeFw0xNjA2MTcyMDMxMTha
Fw0xNzA2MTcyMDMxMThaMHYxCzAJBgNVBAYTAklSMQswCQYDVQQIDAJUSDEPMA0GA1UEBwwGdGVo
cmFuMQ0wCwYDVQQKDARHTFVVMRkwFwYDVQQDDBB1YnVudHUuZ2x1dS5pbmZvMR8wHQYJKoZIhvcN
AQkBFhBzdXBwb3J0QGdsdXUub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvt/V
JO3o7LCwmgUSJg1CyTfSwUL28d2FaMsiiSUZ5Qs6kPHKwJ22IltBpIaJBgFcqyNxOgve3z7agJtJ
dBmyWJRoz7yMbtXmHJdk+XRs4LqRCl0CFprlPtfg9Avyb8tBqWa+c3VBbbhJ0dKpWpvzVLoRm33J
u9+/TnlM6a5UUHGsQIynjndFJSFnittNfDLQglooKyjUuiv0OrN5E7qG9bGe+w+EytYrzfx+AI/t
9wGIjMKyY9MWO4/ai0Ei7tX5CHS1GxFg2xp6Q6705YjFxrfFTbB+5XIbUCLi62nzas51hYeVzWHZ
B2XODA8ClE+U31EtwvVHbNJP5DOoM9441QIDAQABMA0GCSqGSIb3DQEBCwUAA4IBAQBBYAvHpshQ
8SH7wrPKNhFpbdxJ49PYmMDlCtKyU10umiEYmCSg9m4vado9MLrqblQ5qUMX1YYiIQbR47RXtSdG
AAr16JcBbiktrGv+KeGuLp7K0Ye3WsUS/uSrCimvW+lilNqAHj0MvqjQuSKCgOrmpxT55C8e21/h
piFjQF7ReCAeD0DV5ZGiDZQP0wdjJvHAMVQbQGeIpizZnOmmozsCiUDpSN2gZgu59TPimTD7rcfi
WZdaOr9L3pevZFLOrCXweyS6eiD2pTV1hWnfX6Ck3c0pM+yuA7Ug3BSFoOCXigKiA1EO4aqnGHLG
dswo1zee5kgF8oJbyYjVcYhZgc5w
-----END CERTIFICATE-----
Thanks.
You SP-metadata has
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"
Location="http://ubuntu.gluu.info:9090/saml/SSO/alias/defaultAlias" index="0"
isDefault="true"/>
hence artifact binding will be used.
--> The SP tries to connect to the Artifact Resolution service of the IdP (Location="https://ubuntu.gluu.info:9443/idp/profile/SAML2/SOAP/ArtifactResolution").
As this has scheme 'https' a secure SOAP call has to be performed.
Either you configure a JSSE truststore for your deployment container running the app (JVM-option -Djavax.net.ssl.trustStore=PATH_TO_JKS_TRUSTORE) and add the provided cert to hat truststore or remove artifact binding from your SP's meta data and only use front-channel bindings (where all communication goes through the user-agent)
Here is the part of SP metadata.
Reference: Metadata for the OASIS Security Assertion Markup Language (SAML) V2.0
...
<md:KeyDescriptor use="signing">
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:X509Data>
<ds:X509Certificate>
</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</md:KeyDescriptor>
<md:KeyDescriptor use="encryption">
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:X509Data>
<ds:X509Certificate>
</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</md:KeyDescriptor>
...
Are there any benefits to choose same (or different) certificate in both signing and encryption certificate ?
What is the purpose of including signing certificate here ?
If the message is sent through https, a transport layer encryption is provided. Do we still need to include encryption certificate here ?
In SAML 2.0 Web SSO's metadata providers typically declare the same certificate for both signing and encryption usage.
There are some use-cases where usage of different keys makes sense - e.g. when SP itself is not supposed to be able to decrypt data provided by IDP (e.g. nameID or attributes), but this is only done by the ultimate recipient of the Assertion; or when a different party provides content for creation of assertion than the party who actually creates the SAML messages - but those use-cases are rare and more relevant for other profiles than Web SSO.
The signing certificate is included in order to inform users of the metadata on how to verify messages provided by the issuer of the metadata. For example, when SP receives a message from IDP, it uses signing certificate defined in IDP's metadata in order to verify whether the message was created by the IDP and wasn't tampered with during transport.
You typically don't need to include the encryption certificate in case encryption is done on transport layer and you don't perform any encryption on message level (e.g. of whole message, assertion, nameID or attributes).
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
To configure Salesforce for SAML SSO you need to upload your organization's SAML certificate (step 7 here).
At the same time, I can see that SAML certificate is part of organization IdP metadata file:
<IDPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
<KeyDescriptor use="encryption">
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<X509Data>
<X509Certificate>...
</X509Certificate>
</X509Data>
</KeyInfo>
</KeyDescriptor>
...
</IDPSSODescriptor>
Doesn't that make SAML certificate upload redundant?
For SAML the certitifiate does not need to be send in any other form than metadata. Salesforce may need this for other puruposes though. The implementation may require the certificate to be installed. This is the case in OpenAM, a certificate file must then be installed in the machines java keystore
I am implementing an SP initiated web browser SAML SSO profile.
My application is the SP.
The customers ask me to supply them a metadata file.
I have a Shibboleth metadata file I used for testing my application against a local Shibboleth IDP server.
Now, When I sent this file to a non-Shibboleth customer, he said that this file is a Shibboleth file and he needs a different one.
My question is:
Is there a standard SP metadata file I can use which will fit all customers, no matter what IDP they are using?
I found an example:
<md:EntityDescriptor
xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
ID="_z7b6d339da96016iib0ed98ed476er3d7ae4dct5"
entityID="https://my.application.sp/login">
<md:SPSSODescriptor AuthnRequestsSigned="false"
WantAssertionsSigned="true"
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:X509SubjectName>CN=my.application.sp</ds:X509SubjectName>
<ds:X509Certificate>--my certificate--</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</md:KeyDescriptor>
<md:KeyDescriptor use="encryption">
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:X509Data>
<ds:X509Certificate>--my certificate--</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</md:KeyDescriptor>
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat>
<md:AssertionConsumerService
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Location="https://my.application.sp/handleLogin" index="0"/>
</md:SPSSODescriptor>
</md:EntityDescriptor>
Is this enough?
Can I use this as a general metadata for all the IDPs?
Thanks
The sp.xml is constrained by SAML which is an open protocol so there's no such thing as "Shibboleth metadata" - it is SAML metadata as used by Shibboleth.
The various details have to be negotiated between the two parties e.g. you have specified HTTP-POST.
What if the IDP prefers HTTP-Redirect?
What if they want the nameid-format to be persistent rather than transient and so on.
Or your certificate might be 1024 bit instead of 2048?
The metadata as it pertains to SAML can be used as a general example but it probably won't meet all the individual IDP requirements.