Symantec Access Management

Team,

We have a requirement, where the client application is in domain, *.abc.com,  but the CA SPS is in the domain *.def.com. When Implementing Rest API between these two domains, we are running into CORS issue. More info on CORS can be found at : https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS.

We have implemented the following fix in Apache on CA SPS R 12.7 SP 2, on RHEL 7.3 platform to overcome the issue.

<IfModule headers_module>
Header always set Access-Control-Allow-Origin: *
Header always set Access-Control-Allow-Method: "POST, GET, OPTIONS, DELETE, PUT"
Header always set Access-Control-Max-Age "1000"
Header always set Access-Control-Allow-Headers: "x-requested-with, Content-Type, origin, authorization, accept, SMCHALLENGE"
Header set SMCHALLENGE "YES"
RewriteEngine On
RewriteRule "^/authazws/.*" "-"  [CO=SMCHALLENGE:YES]
RewriteCond %{REQUEST_METHOD} OPTIONS
RewriteRule ^(.*)$ $1 [R=200,L]
</IfModule>

We would like to find out if there is any better way to do and if this is approved by CA.

Thanks,

Avi

Team,

Please ignore:

Header set SMCHALLENGE "YES"
RewriteEngine On
RewriteRule "^/authazws/.*" "-"  [CO=SMCHALLENGE:YES]
RewriteCond %{REQUEST_METHOD} OPTIONS
RewriteRule ^(.*)$ $1 [R=200,L]

This fixed the CORS ISSUE:

Header always set Access-Control-Allow-Origin: *
Header always set Access-Control-Allow-Method: "POST, GET, OPTIONS, DELETE, PUT"
Header always set Access-Control-Max-Age "1000"
Header always set Access-Control-Allow-Headers: "x-requested-with, Content-Type, origin, authorization, accept, SMCHALLENGE"

Thanks,

Avi

Don't have an answer specifically since we don't use SPS (we have used it with CA API GW which supports good CORS handling)...but depending on other mitigating factors, I'd be hesitant to wide open your CORS to all domains; but really depends on what the API is doing and what all it is validating.

CORS is really a layer to protect the user, if you say have an API that only needs the user SSO session cookie (no other mitigations or authentication) with wide open CORS then a user visiting Malicious Site A could send an API call to YOURAPI.domain to take some action the user did not intend (e.g., post a comment or send email) simply because they were logged into your SSO environment.

You're basically removing the same origin policy protections browsers implement to avoid situations like that. CORS helps limit unintended actions taken on behalf of the user by ensuring same origin applies except where explicitly permitted; while the TLS/authN/etc protects the resource itself from access to unauthenticated/unapproved entities.

If you are going to do CORS, you should compare the origin of the request and only respond with a valid domain if it matches. Only exception being truly open APIs where there's no risk involved with invoking it from anywhere else (e.g., read unauthenticated public data that's already open).

Thanks a lot. We are using the Auth API provided by SPS, to authenticate the user and the SM Session as a token in the response, which we use to generate the SAML token. It seems CA does not support officially, CORS as it was not tested in the QA Environment.

We are planning to lock it down to the parent domain, of the API, we did this as part of our POC, but we are planning to lock it down, before we go Live. But since CA is not supporting this feature, we are planning to look at other options.