2

I'm using a Shibboleth IDP to authenticate to Salesforce as the service provider. My desired implementation would be to have the IDP encrypt the SAML Assertion AND provide the identity (salesforce user id) as an attribute.

I can get either to work individually but not both at the same time.

By this I mean that if I have the IDP use the salesforce logon id as the 'principal' and therefore configure the SAML Single Sign-On Setting for SAML Identity Location as Identity is in the NameIdentifier element of the Subject statement; I can 'single sign on' to salesforce with an encrypted assertion.

If I configure the IDP to use a different 'principal' (meaning the id the IDP knows the user as), and add the salesforce login id as an Attribute, and configure the SAML Single Sign-On Setting as Identity is in an Attribute element; I can only successfully 'single sign on' if the IDP is not encrypting the Assertion.

With both Assertion Decryption on, and using Identity is in an Attribute element; the IDP seems to think everything worked fine (only successful log messages), but I get the error in my browser:

Login Error Your login attempt using single sign-on with an identity provider certificate has failed. Please contact your salesforce.com administrator for more information.

The Salesforce user login history doesn't show the failed attempt (or anything). The SAML Validator appears to show that everything in the SAML Response/Assertion was 'OK'.

I got a hint that the user identity must be in the Subject element of the assertion from this page of release notes from salesforce:

http://docs.releasenotes.salesforce.com/en-us/spring14/release-notes/rn_forcecom_security_encrypt_assert.htm

Finally the question: Does anyone know if I can do both Identity as an Attribute and Encrypted Assertions as part of the same config? I really need to encrypt the assertion and not have to have my IDP use the salesforce login id as the principal on the assertion.

Improve this question

1 Answer 1

Reset to default
0

This is a documented limitation of the SAML implementation. #3 under "Setting up an identity provider to encrypt SAML assertions" in Configuring SAML Settings for Single Sign-On says:

Set the SAML Identity Location to Identity is in the NameIdentifier element of the Subject statement.

For a successful authentication, the user must be identified in the <Subject> statement of the assertion. For more information, see Identity Provider Values.

We're looking into removing this limitation in a future release.

Improve this answer
5
  • 1
    When you say "read the config based on the URL parameter" are you referring to the "?so=00Dj0000001oj6b&sc=0LEj000000003pL" url parameters? To the best of my knowledge I'm configuring the IdP properly and was thinking that the SAML Validator is backing me up on that to some extent.
    – jefmckenzie
    Commented Jan 7, 2015 at 22:53
  • Exactly - the parameters on the URL in the incoming request tell us (Salesforce) which IdP this is, so we know to decrypt the assertion. You should file a case, as this is either a bug or some subtle config issue.
    – metadaddy
    Commented Jan 7, 2015 at 22:55
  • If you do file a case, let me have the case number, and I'll pass it on to R&D to close the loop here.
    – metadaddy
    Commented Jan 7, 2015 at 22:58
  • I'm using the developer edition to try to prove the concept so I'm not sure I can open a case. I'll keep trying and if I figure a way I'll get you the ticket number. But either way, thanks for confirming this approach should be possible. I'll keep at it until something clicks.
    – jefmckenzie
    Commented Jan 7, 2015 at 23:39
  • So it turns out that this is a documented limitation - I'll update my answer.
    – metadaddy
    Commented Jan 8, 2015 at 0:19

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .