locked
ADFS 3.0 and SAML / IDP Initiated Sign-On (With RelayState) RRS feed

  • Question

  • Hi All,

    I am just seeking clarification on how the SSO is expected to work in ADFS when the other end requires RelayState.  As I understand it, the only way to access the URl is with a special crafted URL containing the relaystate paramter, such as:

    https://adfs.contoso.com/adfs/ls/idpinitiatedsignon.aspx?RelayState=RPID%3DURI%253ARelyingParty%26RelayState%3Dhttps%253A%252F%252Fapp.relyingparty.com

    1. Is there another way to initiate the SSO, such as using a shorter URL?

    2. Is there a way to "embed" the RelayState-containing URL in the STS website dropdown menu?

    Or is it true that single sign on can only be accomplished with the URL format above?

    Wednesday, August 10, 2016 2:15 PM

Answers

All replies

  • Thanks nzpcmad1.  Since we have several other relying trusts in ADFS that do not use relay state, I'm not sure if this is an option, or am I missing something?
    Wednesday, August 10, 2016 7:12 PM
  • This is per RP not across the whole of ADFS.

    Wednesday, August 10, 2016 7:21 PM
  • So it seems to be working with the new link, but now we have a new problem

    The SSO application delivers e-mails with links to the application.  However , these links generate an error on their site, presumably because the link is direct to their website and not our ADFS sts website.  What options are there for this scenario?

    Thursday, August 11, 2016 8:36 PM
  • I imagine this is a question for the vendor of the SSO application.

    What error does it generate?

    Thursday, August 11, 2016 9:42 PM
  • Strangely enough, the following gets logged when an e-mail link is clicked (shown from ADFS event log)

    Encountered error during federation passive request. 

    Additional Data 

    Protocol Name: 
    Saml 

    Relying Party: 
    https://app.com/loginsp 

    Exception details: 
    Microsoft.IdentityServer.Service.SecurityTokenService.RevocationValidationException: MSIS7098: The certificate identified by thumbprint '71254624653A9A06AC6175565' is not valid. It might indicate that the certificate has been revoked, has expired, or that the certificate chain is not trusted.

    However, this error is not logged when using the STS URL with relaystate, only clicking a link to the vendor's application via e-mail link.

    I also tried to run this:

    Set-ADFSRelyingPartyTrust -TargetName Jobvite -EncryptionCertificateRevocationCheck None 

    When using the STS URL with relaystate that works, the SAML trace shows a status of:

    <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" />

    And when using the e-mail link that generates the error:

    <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Responder" />

    Thursday, August 11, 2016 9:50 PM
  • This is SP Initiated.

    What might be happening is that the RP is not configured with a valid certificate - either signing and / or encryption.

    SP Initiated sends an AuthnRequest and this request has to be correctly signed etc.

    IP Initiated just sends an AuthnResponse so this step is skipped.

    Does the vendor support SP Initiated?

    Thursday, August 11, 2016 10:38 PM
  • It is strange regarding the certificate, that it works when using the full RelayState Url, no error. But appears when using a hyperlink. I'm not sure offhand if sp initiated is supported. They only provided the sp entity id, and sp assertion url (and RelayState id)
    Friday, August 12, 2016 12:03 AM
  • What's the hyperlink?

    Suitably redacted if need be.

    • Edited by nzpcmad1 Friday, August 12, 2016 12:33 AM Expand
    Friday, August 12, 2016 12:32 AM
  • https://app.contoso.com/em?747462525999 In a SAML trace I see it tries to authenticate back to STS , but it fails regardless of if the user is already logged into the app or not
    Friday, August 12, 2016 1:21 AM
  • Exactly - that's SP Initiated and you haven't configured any certificates hence the error.

    Friday, August 12, 2016 1:26 AM
  • The vendors relying party configuration does contain a certificate in its properties. Is additional configuration needed?
    Friday, August 12, 2016 1:36 AM
  • In the ADFS RP, is the certificate under the signing or encryption tab?

    When you view the certificate, is its thumbprint '71254624653A9A06AC6175565'?

    Is that certificate still valid e.g. not expired?

    Friday, August 12, 2016 1:59 AM
  • It looks like the same certificate is under both the signing and encryption tab. It does not Expire til next year. I have confirmed that the thumbprint does match
    Friday, August 12, 2016 2:17 AM
  • Right so have you done SigningCertificateRevocationCheck None?

    Friday, August 12, 2016 2:33 AM
  • That's correct. And by doing that we no longer see the error when logging in with STS, yet it is still logged when attempting these embedded links
    Friday, August 12, 2016 2:38 AM
  • Just to double check:

    You have run:

    EncryptionCertificateRevocationCheck None

    and

    SigningCertificateRevocationCheck None?

    Friday, August 12, 2016 2:46 AM
  • It looks like I will have to run the second one, as only the first command was issued. I will follow up once this has been done
    Friday, August 12, 2016 2:51 AM
  • Just to double check:

    You have run:

    EncryptionCertificateRevocationCheck None

    and

    SigningCertificateRevocationCheck None?

    SigningCertificateRecovationCheck has been set to None.  Embedded links still fail, but now with a different error in ADFS:

    Exception details: 
    Microsoft.IdentityServer.Protocols.Saml.SamlProtocolSignatureAlgorithmMismatchException: MSIS7093: The message is not signed with expected signature algorithm. Message is signed with signature algorithm http://www.w3.org/2000/09/xmldsig#rsa-sha1. Expected signature algorithm http://www.w3.org/2001/04/xmldsig-more#rsa-sha256.
       at 

    Friday, August 12, 2016 6:22 PM
  • To clarify, if the user first logs into the STS Relaystate URL, and then clicks the link from the e-mail, the page displays normally. 

    It is only if the user has not authenticated to the STS Relaystate URL that they receive the error opening the e-mail

    Friday, August 12, 2016 10:20 PM
  • You can select SHA-1 or SHA-256 under the Advanced tab for the RP.

    Friday, August 12, 2016 10:31 PM
  • I switched from SHA-256 to SHA-1 and it seems to be working now?  How could that have caused this?  Bizarre..
    Friday, August 12, 2016 10:40 PM
  • As per the error - "The message is not signed with expected signature algorithm."

    Friday, August 12, 2016 10:50 PM
  • Now if I can just come up with a way to turn that extremely long relaystate URL into something short and easy to remember
    Friday, August 12, 2016 11:03 PM
  • You could use something like bit.ly.

    Friday, August 12, 2016 11:13 PM