cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
5339
Views
15
Helpful
18
Replies

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

PWJPW
Level 1
Level 1

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.
18 Replies 18

@Roger Kallberg not at all. I am configuring everything as per the documentation and it doesn't work, therefore it is either a bug or something extra is required that is not documented.

 

The point about CUCM is that it supports Google SSO without anything special, and logic therefore assumes that Expressway *shouldn't* require anything non-standard either.

 

The errors posted in the original post show the issue, in that Expressway is saying 

SAML message from IdP is not verifiable

but there is no further information it provides.

 

The strange thing is that the authentication through Google actually works (we can see it in the Google SAML logs our side), so it is the bit after where Expressway gets the reply where it fails.

 

So, definitely not ignoring advice but at present there isn't anything else that I can try.

 

Thanks

 

James

As mentioned by @b.winter the configuration in the IdP for Expressway differs from the one for other Cisco UC systems. You need to configure the trust in the IdP for Expressway differently than for the one for example CM.



Response Signature


I have, they are separately set up on the Google SSO (IDP) side, two diff apps and configured as such.

 

The screenshot I posted from the Google side is the one explicitly for Expressway, with the CUCM one being done a month prior.

There is no additional config that can be changed on the Google IDP side, so I'm stuck with the Expressway error...

 

Thanks

 

James

 

old thread, but I ran into this using Azure SSO, same error , just Expressway was giving same error.

I needed to fix in the Cert part 

 

 Sign SAML Response and Assertion.

 

it was set to Sign Assertion only.

This fixed it for me.

 

CCIE-Collaboration #24527