IBM Security Verify Access (ISVA) (formerly IBM Security Access Manager – ISAM) has been around for a fair while, and has made a series of assumptions over it’s time, starting fresh, you might not make those assumptions if you were deploying ISVA today. Upgrades for existing customers rarely bring onboard these changes to avoid backwards compatibility issues, but if you have the chance to make these changes or starting fresh, take a look at my list of better defaults, config and archtiectural considerations you should consider.
Short authsvc URLs
Things that always make me pause is seeing the URL in the wild containing “urn:ibm:security:authentication:asf:”. The good news is this is not mandatory, and short URLs look a million times better. It just takes one config parameter change, and you’ll be able to get a few advantages.
Leo wrote about this here back in 2019:
https://community.ibm.com/community/user/security/blogs/leo-farrell/2019/05/26/isam-path-based-authentication-service-kickoff
But it is more generally documented in a really good section on REST API interaction with ISVA here:
One of the other features of this – is the ability to ressurect a timed out authentication flow – (StateID not found) experience much easier since you can determine the authsvc policy that the user was interacting with in the URL since it no longer disappears as a query string parameter.
Change the TAM_OP macro name
Lots of times I see TAM_OP in the wild, you can change this up!
Change it to something unique to your organisation and customise the look.
While you’re at it, change the default cookie names too, PD-SESSION-ID is old school cool – but what about a Llama-ID?
Use the apiauthsvc
In this age of JavaScript, don’t feel it necessary to use the HTML templates that ISVA provides for all flows, get crafty with the UX and interact with the authentication service with REST. Its an easy conversion between authsvc and apiauthsvc and gives you much more flexibilty with how the user interacts with your site.
This URL talks about it in more detail:
https://www.ibm.com/docs/en/sva/10.0.5?topic=developing-authentication-service-framework-rest-api-clients
You might want to look into the cookieless authsvc interactions too, or familiarize yourself with our OAuth Session configuration for management with an Authorization Header.
Don’t use the ISVA Reverse Proxy for Junctions
“What?” I hear you say? But isn’t that what it’s for – well – yes, but we now have the IBM Application Gateway (IAG), this is the better way to deploy junctions, use the ISVA as your monolithic Identity source, with comprehensive authentication policy flows etc, and deploy an IAG in front of you applications with OIDC as the handoff. This will reduce the burden of load through your central (and most important) piece of your Access Management architecture, and allow you to manage each application (or group of applications) on a separate SLA. Need to change a junction tuning parameter? Don’t worry about enterprise wide change windows, just apply the change now – and have little to no impact on your broader organization.
As a bonus, it has a range of neat integrations into your container environment – meaning that it can perform alot of it’s configuration automatically with Kubernetes operators and rolling restarts!
There is an easy to use wizard to help bootstrap your IAG deployment from existing junctions, take a look at the “Export to IAG” command.
Learn more about the IAG here:
https://docs.verify.ibm.com/gateway
Configure MFA
If you’re presenting a web experience to your users, and you’re not enabling MFA, you’re living in the past. MFA is essential for internet security. Good news though ISVA has you covered supporting most major types of MFA mechanisms.
MFA is good – but tying it together with context based access is even better. Challenge users for MFA when you need to – not everytime. Tag their browser so you only do it for new devices, tie it to the accessing context – just looking at something – let ’em look – changing something – step ’em up!
Go turn it on… and while you’re at it – look at the next section.
Stop using username & password logins
Passkeys are here! Go into your AAC configuration and deploy the FIDO2 Platform Authenticator Inline Registration (FIDO2 PAIR) scenario.
Or you can do the more flexible Identifier First Authentication (IFA) scenario:
And start migrating your users that have Passkeys (FIDO2/WebAuthn powered authentication) to a better experience!
The policy is fairly straightforward, it simply logs the user in using their ‘legacy username and password’ and if they are on a platform that supports Passkeys, it will take them through the enrollment process. Subsequent logins can be password free! More secure and phishing resistant.
There is a whole world of Passkey related tweaks and improvements – especially with browsers adding more features and UX changes to the passkey experience regularly. So take some time to get familiar with it.
Containerize your deployment
This one isn’t really a default, but the future of the platform lies in containerisation. In the container world, clusters don’t exist, scaling is easy and devops is the norm. ISVA has been available in container form since 2018, and brings with it a range of useful/functional improvements.
Its really too big a topic to go through here, but you can read more here:
https://www.ibm.com/docs/en/sva/10.0.5?topic=support-scenarios
Federated Registries
This is an oldie but there still plenty of folks deploying with full “TAM” users. I’ve written about it in the past, you can see my write up here:
Federate Everything
This is really a superset of my mention of the IBM Application Gateway (IAG) above as well as the right way to integrate into applications. When an application must use “Junction SSO” – use the IAG, where the application supports SAML or OIDC – federate. (And since the IAG supports OIDC – federate to it!).
Use a developer portal to get an even more admin free approach to application deployment! There is a sample version that you can tweak in the IBM Security App Exchange. Its just an infomap, so you can add whatever lifecycle process to it that you like!
https://exchange.xforce.ibmcloud.com/hub/extension/fb70e33db9b85b20d94f48fae77120e
OpenID Connect
Doing something cool in OIDC? Look at the dedicated OIDC container:
IBM Security Verify Access OIDC Provider is a containerized lightweight OIDC provider, which supports advanced OIDC and OAuth standards out of the box and can be deployed and scaled using any modern orchestration system, including Kubernetes. It supports best-in-class security controls and advanced flows, such as pushed authorization request and client-initiated back-channel authentication along with pre-defined security profiles (or recipes) for Open Banking and other compliance.
https://docs.verify.ibm.com/ibm-security-verify-access/docs/overview
This is where the good stuff is for scalability, advanced features and easy management. Designed to work alongside your existing ISVA deployment, it’s the perfect sandbox for rapidly developing the latest and greatest OIDC scenarios.
Its conformant and certified in all the major FAPI profiles too!
Conclusion
Thats it for now, there are always more things you can do to improve your deployment, and I might iterate on this list as time goes on. If you have any other ideas, let me know either through this site, or on LinkedIn.
Philip Nye 