How a mainstream encryption scenario works in SAML: identity provider encrypts some elements of the SAML response with service provider's public key. (I am assuming an asymmetric cipher which is how most implementations incl. Salesforce do this). The service provider decrypts using the private key that corresponds to the public key used to encrypt. In other words, the service provider needs to own a keypair - private key and public key - for this use case to work.

The identity provider's metadata could also contain a KeyDescriptor element with use="encryption". This has nothing to do with the encryption scenario described above.

A JKS keystore can contain different types of entries. You can import a public key into the keystore. If you use Java keytool to list the entries in your keystore (keytool -list -keystore ), a public key-only entry will show up as a 'trustedCertEntry' type. Another type of entry is one that contains a keypair (private and public key). This type of entry will be listed as 'PrivateKeyEntry'.

When importing a JKS keystore under Certificate and Key Management section, Salesforce appears to only read entries of PrivateKeyEntry type. In the encryption scenario above, that's the only entry that could be used to import a keypair. If you stick your identity provider's private key and cert into the keystore as a PrivateKeyEntry, you will be able to import it . The public key (cert portion) of the entry will then show up on the list when you're creating a SAML service provider under SIngle Sign-On Settings.

How a mainstream encryption scenario works in SAML: identity provider encrypts some elements of the SAML response with service provider's public key. (I am assuming an asymmetric cipher which is how most implementations incl. Salesforce do this). The service provider decrypts using the private key that corresponds to the public key used to encrypt. In other words, the service provider needs to own a keypair - private key and public key - for this use case to work.

The identity provider's metadata could also contain a KeyDescriptor element with use="encryption". This has nothing to do with the encryption scenario described above.

A JKS keystore can contain different types of entries. You can import a public key into the keystore. If you use Java keytool to list the entries in your keystore (keytool -list -keystore), a public key-only entry will show up as a trustedCertEntry type. Another type of entry is one that contains a keypair (private and public key). This type of entry will be listed as 'PrivateKeyEntry'.

When importing a JKS keystore under Certificate and Key Management section, Salesforce appears to only read entries of PrivateKeyEntry type. In the encryption scenario above, that's the only entry that could be used to import a keypair. If you stick your identity provider's private key and cert into the keystore as a PrivateKeyEntry, you will be able to import it . The public key (cert portion) of the entry will then show up on the list when you're creating a SAML service provider under Single Sign-On Settings.

A JKS keystore can contain different types of entries. You can import a public key (aka cert) into the keystore. If you use Java 'keytool' to list the entries in your keystore (keytool -list -keystore ), this type of entry will show up as 'trustedCertEntry' type. Another type of entry is one that contains both private and public keys together. This type of entry will be listed as 'PrivateKeyEntry'.

When importing a JKS keystore under Certificate and Key Management section, Salesforce appears to only read entries of PrivateKeyEntry type. Technically speaking entries of 'trustedCertEntry' type could be read by the importer but they appear to be ignored. (I am guessing this is a disconnect between the general purpose intent of JKS import in Certificate and Key Management and SAML encryption scenario). If you stick your identity provider's private key and cert into the keystore as a PrivateKeyEntry, you will be able to import it . The public key (cert portion) of the entry will then show up on the list when you're creating a SAML service provider under SIngle Sign-On Settings.

How a mainstream encryption scenario works in SAML: identity provider encrypts some elements of the SAML response with service provider's public key. (I am assuming an asymmetric cipher which is how most implementations incl. Salesforce do this). The service provider decrypts using the private key that corresponds to the public key used to encrypt. In other words, the service provider needs to own a keypair - private key and public key - for this use case to work.

The identity provider's metadata could also contain a KeyDescriptor element with use="encryption". This has nothing to do with the encryption scenario described above.

A JKS keystore can contain different types of entries. You can import a public key into the keystore. If you use Java keytool to list the entries in your keystore (keytool -list -keystore ), a public key-only entry will show up as a 'trustedCertEntry' type. Another type of entry is one that contains a keypair (private and public key). This type of entry will be listed as 'PrivateKeyEntry'.

When importing a JKS keystore under Certificate and Key Management section, Salesforce appears to only read entries of PrivateKeyEntry type. In the encryption scenario above, that's the only entry that could be used to import a keypair. If you stick your identity provider's private key and cert into the keystore as a PrivateKeyEntry, you will be able to import it . The public key (cert portion) of the entry will then show up on the list when you're creating a SAML service provider under SIngle Sign-On Settings.