Well, since no one else is answering :)....My personal opinion on CA Access Gateway (aka SPS) in summary would be 'it's mediocre for my use cases'.
Obviously YMMV based on what all it will be used for and specific requirements. For basic uses we tried, it just didn't work out well and was not worth the maintenance effort for the most part; essentially only needing it to front-end authentication/authorization and insert user attribute values -- not doing things like SAML with it since there's other systems doing that already.
Just don't let it scare you away in case it does work out for your apps.
======================
Is it working for you?
- Eh, so-so. For the most part though it was buggy, used out-dated Apache / OpenSSL, and Java versions; this meant it could not be fully locked down to only TLS 1.1 and 1.2 (and the administration gui had SSLv3 on : /) etc; thus can't adhere to NIST / Federal requirements for apps that need it. At least on version 12.52 SP1 this was the case.
---------
How large is your enterprise? (how many apps? How many FQDNS on your SPS, etc.)
- SPS was fairly small use initially with potential to expand. But the few apps initially deployed with it are now moving off of it and went to Web Agents for now or being moved to other proxy solutions. Apps that might still need proxies will instead use other proxy software such as IIS / ARR or standard Apache reverse proxy with supported Web Agent on that system to handle authentication/authorization.
As a general concept, I like a properly implemented proxy model due to control for pre-authentication, inspection, etc before any traffic ever gets to an app server. But would prefer something other than SPS unless later versions are better.
---------
What are its strengths?
- The out of the box AuthN / AuthZ web services that come with it have been useful for mobile apps / non-web agent apps to generate and verify session tokens. It works well for username + password but not so much for certificates; the x509 auth scheme will accept any user x509 public certificate and generate a token for that user (no key exchange or actual authentication).
I'm sure if you're using other functions of it such as the different session options (i.e., mini-cookie, SSL ID, etc), federation services, or different routing based on some value it could provide more.
For most of what I've dealt with it though that stuff was not needed. Use cases for most of the apps was pretty straight forward in terms of proxy needs though; so the problems it created outweigh the strengths really.
---------
What are its weaknesses and/or limitations?
- Support wasn't great, outdated software versions, duplicated configuration values (Apache configs had both the legacy and new config parameters in the config)...really just don't like it much.
The AuthN/AuthZ service (as I mentioned above) works fine for username+password, but going to x509 is problematic. If you expose it for apps to use single-factor validation then you can't really apply an x509 cert auth to it anywhere because then they could just send any ol' person's certificate that exists in the directory and get a token for them with no proof of key. Depending on the security requirements and how you plan to lock it down with certs, can prove troublesome.
Also, may run into security scans flagging the older versions of Apache HTTPD / Tomcat and OpenSSL. Have to deal with some of that too.
---------
How have your upgrades gone?
- Poorly when running multiple instances of the SPS on a single box. Upgrading one broke it all. Had to do some very specific steps to make it work....been a while so can't recall the details offhand but just doing the upgrade install went kaboom.
Was fine when doing a single instance on a system though. So those went smoothly.
---------
What problems has it solved?
- SOAP/REST based authentication and authorization for userid+password and protecting the Admin UI with SiteMinder authentication/authorization. Probably could use it to front-end one-view monitor as well if needed.
---------
What problems has it created?
- The default deployment is not tuned at all and required a lot of tweaking to make it stable in any way. As with the other instability issues, under real-world load it was not very stable and proxy engine would hang randomly - major operational headache.
Not a huge problem (since you can edit files directly) but the UI can be buggy when setting configuration values there versus direct files; for example, every page load it would double the slash ' / '...so if you clicked through the config a few times you'd end up with like "C:\\\\\\\\mypath\\\\\\\\myfolder\\\\\\\\myfile" .
Security scan vulnerabilities, whether legit or not, show up due to outdated software versions. And since it's all bundled up you can't just go upgrade things like OpenSSL yourself, at least not while maintaining it being 'supported' .
Generally just no better than web agent + whatever proxy for us but with added issues for basic cases.
======================
And outside of the SPS product itself, the other major consideration is how you will secure between the SPS Server <--> App Server to ensure some entity can't just smoosh themselves between and inject headers or anything; IPSec, direct cert auth, whatever between those systems to ensure integrity of any data exchanged; have unfortunately seen this not properly considered before and results ain't pretty ....