Layer7 API Management

Summary : 

When trying to authenticate through AuthAzWS from CA API gateway the access gateway does not respond .

When is done through a web browser directly it works Issue is happening in the access gateway.

working:
   browser -> SSO Access Gateway/AuthAzWs
   SOAPUI -> SSO  Access Gateway/AuthAzWs   

not working : 
   SOAPUI -> CA API Gateway  ->   SSO Access Gateway/AuthAzWs 

Environment: 

CA API Gateway 9.2

CA SSO Access Gateway: R12.8
OS: CENTOS 7

Cause: 

The normal sequence of events for Basic UN/PW Authentication is actually two requests and responses if using a browser : 

This two step process is often not convenient for webservice calls, so with webservices often a shortcut is used where pre-emptivly the Authenticate; header is sent with the first request. 
 

For the CA SSO Access Gateway (formerly Secure Proxy Server).   When doing the browser two step process, the SSO Access Gateway on the first step, sets a cookie SMCHALLENGE=YES which then expects to see in the 2nd request - in addition to the Authenticate header.  

The CA SSO Access Gateway (formerly Secure Proxy Server) can do the shortened one step preemptive Basic authentication - but in additon to sending the Authenticate: header the cookie :  SMCHALLENGE=YES.  also needs to be sent. 

(The SMCHALLENGE cookie was introduced to CA SSO to stop some cases where failed Auth/Az would result in endless 302 redirect loop )

Resolution : 

Fix for API Gateway forward rule. 

We add the Cookie:SMCHALLENGE=YES header to the requests from the gateway 

And then the request via API Gateway works. 

Note1:  In SSO SDK community the need for the SMCHALLENGE cookie it is fairly well know.   But in this case it was comparing the network trace from working to not working case where for me it clicked that this was the cause - so I've put in some notes on what we compared for testing.  

Probably best location for SMCHALLENGE=YES, describing how it is needed from SSO webservices is from here : 

Note2:  In the above soln we added the SMCHALLENGE cookie in the API Gateway  in the Route via HTTP assertion.   But we could also have added it to the client and had the API Gateway pass the cookie through to the backend from the original request.

Additional Information: 

The way to debug differences in a working / not-working scenario - which often comes up when direct access works and when via a proxy the access does not work.   Is to compare the two requests as they are received at the back-end server.   In this case the requests were in cleartext, so just a tcpdump or wireshark trace will capture the relevant information. 

Our diagnostic process was as follows : 

1) Wireshark trace and compare. 
We captured the tcpdump on the SPS/ Access Gateway machine for the direct (success) and via Gateway (failure) cases and compare. 

We see that when direct SOAPUI sends request without credentials. A 401 response is received, with Set-Cookie SMCHALLENGE=YES 

And then SOAPUI sends second request this time with the credentials - and it also includes the Cookie: SMCHALLENGE=YES header. And the request is authenticated and returns correct result.. 

We see that via API Gateway, the Gateway preemtively sends the Authenticate: header - and this results in error returned from SPS/Ag. 

2) Simulate error in SOAPUI (direct) 
We change SOAPUI to pre-emtively send Authenticate: header (there is a setting when entering the auth UN/PW).   And we find direct request from SOAPUI then gives the same error that we get when we go via API Gateway. 

3) Simulate 2nd POST. 
We then work on SOAPUI to simulate the 2nd POST, the main issue is that 2nd POST contains the Cookie:SMCHALLENGE=YES header 
So we change SOAPUI to send SMCHALLENGE=YES cookie and to preemptively send Authenticate: header. 

And this works - so we have our soln to apply to request via API Gateway. 
 

Knowledge Article: 

https://comm.support.ca.com/kb/when-trying-to-authenticate-through-sso-authazws-from-ca-api-gateway-the-access-gateway-does-not-respond/kb000108638