MRA with SSO (Google Workspace) 403 Forbidden Invalid SAML response

PWJPW · ‎08-11-2021

Hi All

We have Webex Teams, Expressway E/C (using MRA), CUCM and are using Webex Calling for our employees (Unified CM Calling option)

Expressway X14.0.1

CUCM 11.5.1

We have set up SSO (Single Sign On) in CUCM and Expressway-C with our identity provider idP (Google Workspace) and for on-prem devices, it works great, the end user can authenticate using their Google credentials and receive phone services through Webex Teams app (desktop and mobile). However, our external employees (off-prem) that go through Expressway MRA are not able to log in properly through Google. This is affecting all users through MRA.

They open the webex teams app and it brings up the Google login page. They log in as normal but Expressway is throwing a 403 error afterwards and their phone service is not available.

We receive the error below in the Expressway debug logs

2021-08-09T21:58:38.344+00:00 cisco-vcs edgeconfigprovisioning: UTCTime="2021-08-09 21:58:38,344" 
Module="developer.edgeconfigprovisioning.server.sso" Level="WARN" CodeLocation="samlhelpers(784)" 
Service="OAuth/SSO" Detail="No InResponseTo attribute in Assertion"

2021-08-09T21:58:38.349+00:00 cisco-vcs edgeconfigprovisioning UTCTime="2021-08-09 21:58:38,349" 
Module="network.http.sso.server" Level="ERROR" Event="Invalid request" 
Service="OAuth/SSO" Detail="Invalid SAML Response" Local-ip="127.0.0.1" Local-port="22111" Reason="SAML message from IdP is not verifiable" Src-ip="127.0.0.1" Src-port="35230" Trackingid="88b0afe7-7af2-4147-a9a2-c3400ee700d3" Username="<unknown>"

2021-08-09T21:58:38.349+00:00 cisco-vcs edgeconfigprovisioning UTCTime="2021-08-09 21:58:38,349" 
Module="network.http.sso.server" Level="DEBUG" Action="Sent" Local-ip="127.0.0.1" Local-port="22111" Dst-ip="127.0.0.1" Dst-port="35230"
Code="403" TrackingID="88b0afe7-7af2-4147-a9a2-c3400ee700d3"

HTTPMSG:
|HTTP/1.1 403 Forbidden 
 Trackingid: ['88b0afe7-7af2-4147-a9a2-c3400ee700d3']
 Content-Security-Policy: ["default-src 'self';frame-ancestors 'none';base-uri 'self';block-all-mixed-content;"]
 Server: ['CE_C ECS']

Any ideas? As mentioned, the same iDP integration is working find direct to CUCM for on-prem (for the same user), but through Expressway fails.

Thank you.

Roger Kallberg · ‎08-11-2021

Have you configured the IdP in Expressway C?

PWJPW · ‎08-12-2021

Hi Roger

Indeed, both CUCM and Exp-C. CUCM is fine, Exp-C is throwing the 403 error. Details attached.

Thank you.

Roger Kallberg · ‎08-12-2021

As far as I know all Cisco UC things expects to get a response back for "uid", make sure that is what you pass from the IdP to the client for the login request. Have a look at this document for some more details. Configure Single Sign-On using CUCM and AD FS 2.0 (Windows Server 2008 R2) - Cisco It's not a perfect match as you use another IdP, but it should provide some useful information.

This document contains generic information about most UC systems from Cisco and how to enable SSO on them. SAML SSO Deployment Guide for Cisco Unified Communications Applications, Release 14 - Cisco

PWJPW · ‎08-12-2021

Thanks Roger. I will have a read.

Yes, we do have the uid mapping set just in case, though CUCM didn't need it specifically adding and it works with the default Google idp response. (image attached)

PWJPW · ‎08-12-2021

Unfortunately the problem still exists. It was also the case in Expressway 12.5 and 12.7, and no change in 14.0.

I decoded the response that came back from the idp (Google) and it all looks good including the extra uid attribute:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<saml2p:Response xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" Destination="https://cisco-expressway.redacted.net:8443/redacted/fedlet" ID="_75c0577849796cbee7d0cad847d51bd9" InResponseTo="id-3bb325487a1c8fd7da703de5ba8afccf825c174da7663e3bfac6283a2e768817" IssueInstant="2021-08-12T12:22:42.628Z" Version="2.0">
  <saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">https://accounts.google.com/o/saml2?idpid=redacted</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="_3e7a5fbec5288500b67978055ac89710" IssueInstant="2021-08-12T12:22:42.628Z" Version="2.0">
    <saml2:Issuer>https://accounts.google.com/o/saml2?idpid=redacted</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/2001/04/xmldsig-more#rsa-sha256"/>
        <ds:Reference URI="#_3e7a5fbec5288500b67978055ac89710">
          <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/2001/04/xmlenc#sha256"/>
          <ds:DigestValue>H6RQYVC+hSTX0L671pUHjTVgZciTKhctHv3Pd7Eoe4Y=</ds:DigestValue>
        </ds:Reference>
      </ds:SignedInfo>
      <ds:SignatureValue>Wb2T9ijeLtBM3MBgaXMsk1QXwqI3SfKXa/MTwNrzXntDHJCtfpX13bsXFIdmxDKovroq7luuep59 N+zeK/txcb15253Lfz6YepE36r1mEt7bobPtzFacyhPfu93cHs1ZSW700xosvO8Kea9xuu93iUjt 2jLpD1omOD7woWRSSvQaNIXMj8Ha6NuEA26PgKFWkoqOWTfB5l77GB/kAbhuRQVlBcyd6c/m5TCP H/9qSOToGWb1rkObflZfx/I/XNY7XPGIAFVgUHjvqalCbyH7QjEPBta38nkGEiiKg0S4mLXywn02 dpcWxG5AS1tDvQ0WPPw0Ar/uyRrPk98ficfFgQ==</ds:SignatureValue>
      <ds:KeyInfo>
        <ds:X509Data>
          <ds:X509SubjectName>ST=California,C=US,OU=Google For Work,CN=Google,L=Mountain View,O=Google Inc.</ds:X509SubjectName>
          <ds:X509Certificate>MIIDdDCCAlygAwIBAgIGAVx9+2FeMA0GCSqGSIb3DQEBCwUAMHsxFDASBgNVBAoTC0dvb2dsZSBJ bmMuMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MQ8wDQYDVQQDEwZHb29nbGUxGDAWBgNVBAsTD0dv b2dsZSBGb3IgV29yazELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWEwHhcNMTcwNjA2 MTUxNzIzWhcNMjIwNjA1MTUxNzIzWjB7MRQwEgYDVQQKEwtHb29nbGUgSW5jLjEWMBQGA1UEBxMN TW91bnRhaW4gVmlldzEPMA0GA1UEAxMGR29vZ2xlMRgwFgYDVQQLEw9Hb29nbGUgRm9yIFdvcmsx CzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEA7ET3eqLoI0gbRJxP8tTR0IqFAbRp4D2lc05wJbchLHuPFYuqcRJ78TdyGPdRpkQm 3wiDoo9U1vjOWqSpw9PooTYs6vor+T3Lq3oCUzPkfhMqQnDWmcJwAfMGywxncyxdkN9Tj+cXYSsU yh1SgJIYwWbBCT7dpzTlhkAtppfX0e+/3xuWt8gBO7N0vmohXbTFWaBn9in9qbnzVOS8Yfyjqlp3 /Pew5HzFJJns6DoMIJIzpzdzTZjd70/mK7BOyXSEgKT2FRV34+pD6t5sq8FhnugRltT5XOWlm9Hi uwr9q7PLzbPQAv69qKanPRzzjIylSP24cPSlqVgHRNskEln6RwIDAQABMA0GCSqGSIb3DQEBCwUA A4IBAQB5Vr53KOHMaGb/zHnQ6KMe/ddq1jes3ufj9nyeM5iflRgCMK30KxPWcyCnK8CH5BL0aLsp kCTypRLXzihKdrtvmXELi0ZIxg8Rql5H7uMK63xpO7dXOmWsA6Ye5ezxAcoDuQ12kqpN4n6gH7TD iRGhVTeMrgE9HNca1dpaZtKO4fyJdNEq7zwrPfqlUdUwo0WLySeZiD8ktLElutNS+LrdwljNvVEV 01XmJSqDMJ0WRVUHVpyafYaK+Uvr83ZSXhkK9IhXjyBW77lY4LsqCJOmACMormfZdTpCkabTbMv+ kA2ApNbMBhE7Nh2JYugFzdtOdSPaXQPiCzi3xrBKKXf1</ds:X509Certificate>
        </ds:X509Data>
      </ds:KeyInfo>
    </ds:Signature>
    <saml2:Subject>
      <saml2:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">james@redacted.net</saml2:NameID>
      <saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
        <saml2:SubjectConfirmationData InResponseTo="id-3bb325487a1c8fd7da703de5ba8afccf825c174da7663e3bfac6283a2e768817" NotOnOrAfter="2021-08-12T12:27:42.628Z" Recipient="https://cisco-expressway.redacted.net:8443/redacted/fedlet"/>
      </saml2:SubjectConfirmation>
    </saml2:Subject>
    <saml2:Conditions NotBefore="2021-08-12T12:17:42.628Z" NotOnOrAfter="2021-08-12T12:27:42.628Z">
      <saml2:AudienceRestriction>
        <saml2:Audience>redacted--FFA63844859FABCD</saml2:Audience>
      </saml2:AudienceRestriction>
    </saml2:Conditions>
    <saml2:AttributeStatement>
      <saml2:Attribute Name="uid">
        <saml2:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:anyType">james@redacted.net</saml2:AttributeValue>
      </saml2:Attribute>
    </saml2:AttributeStatement>
    <saml2:AuthnStatement AuthnInstant="2021-08-12T12:22:40.000Z" SessionIndex="_3e7a5fbec5288500b67978055ac89710">
      <saml2:AuthnContext>
        <saml2:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified</saml2:AuthnContextClassRef>
      </saml2:AuthnContext>
    </saml2:AuthnStatement>
  </saml2:Assertion>

Roger Kallberg · ‎08-12-2021

I’m by no means an expert in SAML or IdPs, but what do you mean by “including the extra uid attribute”. UID is the attribute that the IdP should return, it’s not extra, it’s what the Cisco system expects to see.

PWJPW · ‎08-13-2021

The docs show that the default NameID that is returned in the below snippet is what is expected, and that you have to add an extra mapping to pass back the "uid" as this is not passed back by any SAML2 idp by default...

<saml2:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">james@redacted.net</saml2:NameID>

Thank you

Roger Kallberg · ‎08-13-2021

By looking at what you shared earlier and comparing that to the picture in your last reply it would seem that your setup in the IdP isn't correct.

This is what you pass in the SAML traffic, or what ever it's actually called.

This is what the system expects to get. The user credentials should be, I believe, passed in the uid field, not in both as it seem in your outline.

PWJPW · ‎08-15-2021

Hi Roger

I believe NameID is a always present in the response, therefore you can't omit it, only change the format between transient, email or unspecified etc. In all teh cisco docs it shows the NameID present.

Your image doesn't look like it's wrong, as your image also shows both the NameID And uid present, just like my idp is sending back? Or did I misunderstand?

Note, this exact same setup and idP works fie in CUCM, so Cisco should certainly support this.

Thank you

Roger Kallberg · ‎08-15-2021

I might have been unclear, I did not mean that you should remove any fields. From what I can tell the content of the two, NameID and UID, seems in your outline to be incorrect. If you look at the first picture it shows the content of your NameID. It does not match the content in the second picture, that AFAIK shows the content that is expected by the Cisco UC systems. But as said before I’m by far no expert with IdP’s and SAML, so I could be way off with this.

b.winter · ‎08-26-2021

Hello James,

as far as I have in mind, there was an additional configuration step, when adding the Expressway in ADFS:

I don't know, if that also needs to be done on other IDP's or how this could be done.

Hope, that helps.

PWJPW · ‎08-31-2021

Thanks Bjoern

Can't see anything relating to this in Google other other IdP's - but the exact config I'm using works perfect for CUCM, so wouldn't expect Expressway needs anything custom in order for it to work...

Thanks

James

b.winter · ‎08-31-2021

Hi,

I was just trying to point out, that there is a difference in configuration between SSO with CUCM and SSO with Expressway, when using MS ADFS as IDP. So, someone can't just use the same SSO config tasks for CUCM and Expressway.

With that in mind, when I need to work with different IDP's, I would assume, that there could also be a difference. And therefore don't just rely on the config tasks for SSO with CUCM.

BR

Roger Kallberg · ‎08-31-2021

@PWJPW IMHO you seem to be unwilling to accept any suggestions from anybody in this community as you're constantly revolving around that your configuration works perfectly well for CM. Either you're willing to open minded take the advice given or you should not seek help with things that your already dead sure is working as it should. Just my 2 cents on this.