We are trying to expose Auth API in CA SPS 12.7 SP 02, we were able to successfully expose the API following a post by Ujwol, this is working perfectly fine while using SOAP UI, but when we try the same Using Angular Client Via a Browser we are getting a HTTP 403 error. We are not able to set the Cookie SMCHALLENGE=YES programmatically in the API Client . We tried it on the Apache in CA SPS , but it is posting as a response from the server, we want to pas it as a request to the API and not as a response. Has any one tried to call the Auth API in CA SPS via CA SSO , using a browser instead of Soap UI or Postman.
The other link was: https://communities.ca.com/community/ca-security/ca-single-sign-on/blog/2016/11/23/tech-tip-ca-single-sign-on-ca-access-gateway-protecting-authaz-web-services
We are using Angular JS, and Ajax Request, where XHR is not allowing us a cookie.
The version of Angular is Angular 4.
If when accessing /authazws you are getting a set-cookie with SMCHALLENGE= and 403 result, then would means the webservice URL /authazws is protected and it is asking you for authentication before it will let you submit your login webservice (REST or SOAP).
That may mean you need to build the Authenicate: header, with UN/PW to get access - but it depends on what auth scheme you have setup protecting those /authazws. You can enable the webagent tracing in the SPS to see what happened.
Generally for developing usage of the webservice, it is best to start with your webservice "unprotected" ie ACO entry : Requireagentenforcement=no then once you have that working add a protection layer over it (either SSL or basic auth) to restrict access to it.
There is a bit of discussion about it at this point in the link in Ujwol's blog:
Once you have access to make a REST call you should get a 200 http status not 403 status.
Has any one tried to call the Auth API in CA SPS via CA SSO , using a browser instead of Soap UI or Postman.
Cheers - Mark
We have it working in REST or SOAP UI, when we set the SM Challenge=YES and passing the ID and Password in Base 64, we were able to get back HTTP 200, or success login message. The issue we are encountering is when we use a browser based client, we are not able to send the SMCHALLENGE=YES as a cookie in a browser when we are requesting the API , as the browser is rejecting it as per the security standards on the browser. We are not facing any issues when we use Soap UI
I didn't look into this area for a while, but SMCHALLENGE=YES didn't used to be a requirement - but I know how the usage of that cookie has changed, so I can see how it could be required now for Basic login.
1) One possible soln.
If you want to generate the SMCHALLENGE=YES cookie via the webserver, then you could not send the Authorization: header, and it will return a 401 response, and presumable set the cookie. Then you could send the request with the header, and the cookie. For angular you would need something like this :
angularjs - Capture HTTP 401 with Angular.js interceptor - Stack Overflow
2) Another possible soln.
Since it is the authazws on the Access Gateway, it would be possible to write some mod_rewrite entries in the httpd.conf to add the cookie to specific requests, say if the Authorisation: header is present.
RewriteRule Flags - Apache HTTP Server Version 2.4
Somethign like the following (but not tested) :
RewriteRule "^/authazws/.*" "-" [CO=SMCHALLENGE:YES:.example.com:0:/]
But also, it seems odd you are sending a login request to the authws URL, which is protected and you need UN/PW in the Authenticate: header to logon (lets call them UN1 and PW1). Once you've done that you will get an SMSESSION cookie, which will be for the UN1/PW1.
But then once you have a session and access to the /authazws URL, I presume you are going to call and pass in another pair of user & password UN2/PW2 and get back as the response a session token (effectively SMSESSION2 - but this one will not be a cookie).
Is that what you are after: where some sort of "admin" login that has access to be able to login other users; or are you after a mechanism where a single user fills in some (angular) form, posts it and gets a valid browser smsession cookie?
As per CA Documents and Various other Posts we saw SM CHALLENGE=YES. Our Use case , is we call the Auth API, to get a SM Session Cookie, we use that Cookie, to initiate a IDP Initiated SSO . So we are issuing a 302 redirect from the browser to the IDP Initiated URL to get the SAML Token, and post it to Datapower.
Thanks a lot for your valuable feedback, we will try this out in our environment, and will let you know our results.
I added the following lines in the httpd.conf:
RewriteEngine OnRewriteRule "^/authazws/.*" "-" [CO=SMCHALLENGE:YES]
Still we were not able to see the SMCHALLENGE=YES, in the access logs and also on the browser, the other link related to angular js, also did not work, as we deployed in the code. Can you please let me know, If I am missing anything in the above mentioned
Hi Avi, I have been away the last week. The SMCHALLENGE=YES cookie should only be needed on the GET where you send in the Authenticate: header. This is not specific to authazws service and it should return you a set-cookie SMSESSION.
1) Your use case
The call you make to /authazws/AuthRestService/login/appID/Resource when you make the call to the URL, you will need to pass in Authenticate: header with UN and PW, to let you access it, and then you pass in the contents another UN2 and PW2 that rest call runs a login and if successful, it will return you a sessionToken, which is essentially another SMSESSION.
The first user is the user with permissions to allow you to make the login rest calls, the second is the user you are doing the proxy login for.
I am just not sure what you are after is that two level login process. And I wonder if what you really need is a Basic protected resource, and to navigate that first login.
2) The methods,
Ujwols method should have worked.
unless you have some restriction of httponly cookies. Fiddler should confirm the request sends the cookie.
The cookie only needs to be added to the request, it does not need to be set back in the browser (and would not be).
Some combination of that or my methods should work, although it may take some tinkering to get them to work.
I will come back and have a look, but it will take a few days before I am available.
Please do let us know if you have taken a look at this issue.
Are you using withCredentails request option?
This is needed to send cookies to server.
Thanks a lot Ujwol. We tried this before the cookie is being carried in the sequential request's. But this is not creating the cookie the first time, i.e , if the cookie is being created the first time, and the sent to the client as response this is working, but we wanted to send the cookie as a request back to the browser.
More info regarding what I meant can be found at
You may also have to set httpOnly=no in ACO for auth/az web service.
I have this in my ACO, UseHTTPOnlyCookies I am using R 12.7 SP02, is the same setting provided by you?
Regarding the Session Token to be sent for the second request, we have a quick question, should the session token be sent as a Cookie or a Token in the Request to the second URL, and what should be the value , should it be SMSESSION, or something else.
Sorry Avi could not set up webex today as I got caught up in sev1 case.
For your use case, you will need to set the Session Token received from AuthAZ login call as SMSESSION cookie.
Sent from my iPhone
Thanks a lot Ujwol, we will work on this today, and reply back with our findings.