"Validate assertion failed" using assertion for webex XML API auth

I am a bit lost in this maze of Cisco support.  I just accidently posted this in the wrong area.  Sorry if anybody sees it twice.  Anyway...

What might I be doing wrong here?  My test webex account and my learning management system are both configured to use the same IdP.  I set up an SP to get the same attributes as those that the IdP sends to webex.  I configured the IdP to include the webex entityID in the AudienceRestriction part of the assertion.

After authenticating in my learning management system, I get the assertion (starting with <saml2:Assertion...)  and base64 encode it.  I then send that base64 encoded assertion to the webex in an AuthenticateUser call using the API test form.  I do that before the assertion expires.

Despite numerous attempts with minor adjustments, nothing works.  I always get "<serv:exceptionID>AS0062</serv:exceptionID><serv:reason>Validate assertion failed</serv:reason>".  Shouldn't these steps work?  Am I supposed to use a different assertion?

Hi Colin,

Make sure your request also includes <protocol>SAML2.0</protocol>.  The request will default to SAML 1.1.

Hi kinglewi - That seems to help.  I now get a different error, at least: "response message is incorrect"

The documentation says to pass an assertion, so that is all I am passing.  Do I need to wrap the assertion in a <Response> element?  If so, do you know what is the minimum I can get by with?  In other words, do I need only provide the SAML2 REQUIRED attributes?

After many hours of struggling with this, I feel as though I getting close to something that works.  Thanks!

Hi Colin,

Below is an example of what we would need for AuthenticateUser.  It actually needs to be the full response base64 encoded.  Is this for a single site, just trying to use the API with your SAML enabled site, or is this for an integration you are thinking about providing for other webex customers?

<?xml version="1.0" encoding="UTF-8"?>

<saml2p:Response xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" Destination="https://sitename.webex.com/dispatcher/SAML2AuthService?siteurl=sitename" ID="_e21d319b600d63a5f652e387c9556797" InResponseTo="s2c9da468dc20d8da8000ef1e7ee1590df0a317803" IssueInstant="2013-02-01T21:48:10.703Z" 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">https://idp/xyz</saml2:Issuer>

   <saml2p:Status>

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

   </saml2p:Status>

   <saml2:Assertion xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" ID="_865ace5313c44e9fb95b46c4aec8704c" IssueInstant="2013-02-01T21:48:10.703Z" Version="2.0" xmlns:xs="http://www.w3.org/2001/XMLSchema">

      <saml2:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">https://idp/xyz</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="#_865ace5313c44e9fb95b46c4aec8704c">

               <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#">

                     <ec:InclusiveNamespaces xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#" PrefixList="xs"/>

                  </ds:Transform>

               </ds:Transforms>

               <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>

               <ds:DigestValue>RU0eNId21Ijflly9/to7DM4l/o=</ds:DigestValue>

            </ds:Reference>

         </ds:SignedInfo>

         <ds:SignatureValue>PCNK7YfIaXveZ54fTX/fuq5hWJZXctnfic/1cPGjbdB8NvM+GGbJXhYzVI2RmX/7WC7ajVi/s9jkO1UqX33vp9cFZpcBK3ZYX/ZPyFmdsDmgmVFIJEugJbbzIu8e4UGmL/zgpSw5yMGnreN7gglxIaaz7bVId2mQbx2L3wQFlOHt0ibGqQh+3guDOY30cMfxZS7SdZdYGtN1lXikOTm6ywjZEdnlODQt3kfadTH+5BSI73VB+J+LJ9iuUQtVipnRgVE5TsHHGe2ymTSr8+2PfzEH24QNlTALYGakPZYBINAxnKmZiCNR8+gAK27oF8QeREhygb3aj8g==</ds:SignatureValue>

         <ds:KeyInfo>

            <ds:X509Data>

               <ds:X509Certificate>MIIDQDCCAiigAwIBAgIVAIdpxcroWKC1i/MfJuBhYNHIE/cKMA0GCSqGSIb3DQEBBQUAMCAxHjAc

BgNVBAMTFXd3dy5raW5nc2xleWxld2lzLmNvbTAeFw0xMjA0MjUxOTMwMjlaFw0zMjA0MjUxOTMw

MjlaMCAxHjAcBgNVBAMTFXd3dy5raW5nc2xleWxld2lzLmNvbTCCASIwDQYJKoZIhvcNAQEBBQAD

ggEPADCCAQoCggEXN+drdyl3reKfQkaMhKYuRrOj+WuoB4PtOvAHfpUZEeg

FzeneMt5XsX4T/9b61coIY3Y1cSsmMvG94Gnrn+S+0FRmX0ytVFb78aqaSui687VqvhC/cpYV6HA

seGI2V3A7K/x58qnYzgB8OhXqwBJMV/C1o+Jl8YuQcCAwEAAaNxMG8wTgYDVR0R

BEcwRYIVd3d3LmtpbmdzbGV5bGV3aXMuY29thixodHRwczovL3d3dy5raW5nc2xleWxld2lzLmNv

bS9pZHAvc2hpYmJvbGV0aDAdBgNVHQ4EFgQUCXOc5wpyEHmhJp7xofqK+Qlp9+MwDQYJKoZIhvcN

AQEFBQADggEBAG3XEOqHzv2D8KE5KBw0Uhdkmmz3RLYTeQWsIbdzcJlWsMAzHun2boRnQYmgWcer

dP7YQ5P/zQ6U0uizh538/AU96B8lVI1h9pKSNoAUHQyXlrzhmE6xyxIZOme6utO30m1vZMbWhce7

VK1X7o533Msoq9Xkb36368B71htsMwNzZKj7o5WZkAdfYfc2azn+ut1coDGJfXlw5s/Nz49/kzQd

imFn1g9iIjncZ0Znd1I0BFF8DQGha9ujvG+a74v8iFufs4ekYaGVD3rZ+fSJXvf4+ntEWYwaaOvj

zCNUyQrlGcdz8NoOUVBBHvNAeQOUW4JHYvg6ekClZ9JQxowO75s=</ds:X509Certificate>

            </ds:X509Data>

         </ds:KeyInfo>

      </ds:Signature>

      <saml2:Subject>

         <saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" NameQualifier="https://idp/xyz" SPNameQualifier="webex">username</saml2:NameID>

         <saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">

            <saml2:SubjectConfirmationData Address="173.37.18.235" InResponseTo="s2c9da468dc20d8da8000ef1e7ee1590df0a317803" NotOnOrAfter="2013-02-01T21:53:10.703Z" Recipient="https://sitename.webex.com/dispatcher/SAML2AuthService?siteurl=sitename"/>

         </saml2:SubjectConfirmation>

      </saml2:Subject>

      <saml2:Conditions NotBefore="2013-02-01T21:48:10.703Z" NotOnOrAfter="2013-02-01T21:53:10.703Z">

         <saml2:AudienceRestriction>

            <saml2:Audience>spid</saml2:Audience>

         </saml2:AudienceRestriction>

      </saml2:Conditions>

      <saml2:AuthnStatement AuthnInstant="2013-02-01T21:48:10.354Z" SessionIndex="adf7df394ba03c1953f53986669ab2774a3251dfdf60bbfd1b149aa27a63348d">

         <saml2:SubjectLocality Address="122.37.18.245"/>

         <saml2:AuthnContext>

            <saml2:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml2:AuthnContextClassRef>

         </saml2:AuthnContext>

      </saml2:AuthnStatement>

      <saml2:AttributeStatement>

         <saml2:Attribute Name="uid" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">

            <saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">username</saml2:AttributeValue>

         </saml2:Attribute>

         <saml2:Attribute Name="email" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">

            <saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">email@email.com</saml2:AttributeValue>

         </saml2:Attribute>

         <saml2:Attribute Name="lastname" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">

            <saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">Last</saml2:AttributeValue>

         </saml2:Attribute>

         <saml2:Attribute Name="firstname" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">

            <saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">First</saml2:AttributeValue>

         </saml2:Attribute>

      </saml2:AttributeStatement>

   </saml2:Assertion>

</saml2p:Response>

Hi kinglewi - This is for an integration that allows our local application (the Moodle LMS) to use the webex XML API for certain functions on behalf of the application users.  I work for a university.

Now,I can pass in a Response containing an assertion and I get back a "signature is invalid" error message.  Do you know if webex is picky about the kinds of signatures it accepts in the SAML assertion?

Also, your example has an InResponseTo attribute.  I found that I had to remove the one in my message because webex throws an error on it.  That makes sense because webex has not sent anything to respond to.

Hi Colin,

Good catch on the inResponseTo.  I pulled this from and old example, InResponseTo wouldn't be needed for AuthenticateUser.

Webex is pretty flexible with the signatures.  If this is the same signature algorithm that works when logging into the webex site, then it should also work with the AuthenticateUser API.

The few times I've seen this error is been because of one of the following reasons

Make sure you have a transform and canonicalization method of "http://www.w3.org/2001/10/xml-exc-c14n#".

A line break in one of the extra attributes (always when someone puts an address in the assertion)

A rare issue with InclusiveNamespaces when using Tivoli IDMS.

Also make sure that you aren't modifying the response in any way before base64ing it.  Once you get the SAML response from your IDMS it should be base64 encoded and sent to us as you received it.

Hi kinglewi - Yes.  I realized that the signature was broken because of the way I copied and pasted the assertion.  The extra whitespace messed it up.

You say that I shouldn't modify the response, but isn't it just the assertion that I should not modify.  If I don't modify the response, I get errors related to InResponseTo and the Destination.

Now I have come across an error that make me think this way of getting the assertion is wrong from the start.  I get "Recipient unmatched".  The recipient matches my local SP, not webex.  I don't believe I can get the IdP to send my local SP an assertion for a different Recipient in the assertion.  Is this whole approach wrong?

Hi kinglewi - I researched this Recipient problem further.  The parent element looks like this:

<saml2:SubjectConfirmationData Address="m.y.i.p" InResponseTo="_e511a355c86199a1c8b460267093de55" NotOnOrAfter="2016-01-08T19:53:07.509Z" Recipient="https://myserver.umn.edu/Shibboleth.sso/SAML2/POST"/>

Our IdP is Shibboleth.  It has no switches that we can find for NOT sending the SubjectConfirmationData or any of its attributes.  Do you know if anybody getting their assertions from a Shibboleth IdP has successfully used SAML2 assertions to authenticate with the XML API?

HI Colin,

I'm not familiar with anyone using Shibboleth in this format.  In fact authenticateUser is rarely used because it is very difficult to "hook" into a IDP and get an assertion on behalf of an individual.  Is it possible to use the IDP initiated entry point on the IDMS to get an assertion for the webex SP that way? 

Do you need for the API to login as individual host users or is it only for an admin account?  If its an admin account you can still use a admin username and password to access the API.

The other option is partner delegated authentication.  You'll need to write some code to create and sign SAML assertions, then your application or moodle will act as IDP on behalf of the users.  Your code will use a separate configuration then the one on the site.  I can send you more details on this method if its needed.

Hi kinglewi - Sounds like I need to step back and reassess my approach.  I am a developer supporting Moodle customization and integration.  We have tested our Moodle integration with webex using an admin username/password, but that is not acceptable to the business.  My task is to use some other form of API authentication so that Moodle can call the webex API on behalf of users.

If the question in your first paragraph is whether Moodle can somehow get the same assertion from the IdP that the IdP sent to webex, I am pretty sure the answer is "No".  Even if our Identity Management team was willing to do that, I guess it would require a new custom web service and would have significant security implications.  Or, do you mean something else?

In your third paragraph, you mention partner delegated authentication.  I looked it up in the documentation after reading your response, but I don't quite understand how that would work to support my use case.  I would appreciate any information you could send on that approach.  Would it interfere with our ability to use our central IdP for users' web authentication to webex?  If partner delegated authentication is an viable solution, I am familiar enough with SAML that I could create and sign SAML assertions.  Since Moodle is written in PHP, I would probably use the SimpleSAML saml2 library for that.  Thanks for any help you can provide.

Hi Colin,

You are correct in my assumption about accessing the IdP.   The answer is usually "No" from the security teams.  Your only option is for partner delegated authentication.  Please send an email to webex-meetings-api-dev@cisco.com and i'll send you the information for partner delegated authentication.

I am not sure if I have the same problem as Colin, because I am able to get an assertion on behalf of individual users. But I am getting the same errors as Colin did.
I was told to implement the authentication via SAML2 because the username/password authentication is not supported any more. So I tried. I have a Smartcard and I have access to our customers Federation Server and their WebEx-XML-API also. I already implemented a SSO via the customers Federation Server to my companys software successfully, so I tried to use the same SAMLResponse to authenticate to the WebEX-API.
First I had the same error "inResponseTo does not match with request", so I removed the field manually from the SAMLResponse, and now I am getting "Recipient unmatched"