IBM Security Verify Access v10.0.7.0 was released earlier today (15th December, 2023).  This release, among other things, contains a number of extensions to the WebSEAL HTTP transformation rules capability to make it more flexible and powerful.  

A video has been recorded which highlights these enhancements: https://community.ibm.com/community/user/security/viewdocument/ibm-security-verify-access-v1007?CommunityKey=e7c36119-46d7-42f2-97a9-b44f0cc89c6d&tab=librarydocuments.

I have yet to see a 2024 Roadmap for Security Verify.  Does this exist and if so, where?

Hi Rebecca, 
You can get roadmap information through your account team, or via our Early Access Program. 

https://community.ibm.com/community/user/security/blogs/ann-louise-bolger1/2020/11/01/ibm-security-verify-access-early-access

@Scott Exton I don't see in the WebSEAL configuration reference where the new [http-transformations:secrets] is mentioned.  Do you have some documentation on how to set and use those secrets?

I assume the LUA LDAP module can write to the LDAP?  If so, can it use the webseald instance bind credential?  We have a requirement to record the user's last login time and then deny authentication based on that value being too high.  I'm thinking this may allow us to do this without utilizing an EAI/InfoMap on the RTSS to reduce that external dependency.

Also, another question.  We had a use case where we were using the user name mapping module to pull attributes off an client cert (mTLS auth) and put them into the session (i.e. subject, fingerprint, etc.).  However, when a user steps up to a different authentication level above ssl, we are losing these attributes and hence they are not available to backends after a user changes authentication levels.  I had opened an idea/RFE to enhance the product so that the session attributes are not lost during step-up.  Would LUA potentially be able to be used here to somehow prevent these attributes from getting removed from the session?  We could either continue to use the user name mapping module, and then somehow invoke LUA to preserve the attributes, or we could replace the user name mapping module with LUA by what you describe and building on the client cert auth example you gave.  Specifically we are stepping "up" from ssl to password, as this was a legacy MFA that we implemented years ago and never went to EAI/InfoMap/AAC so that we did not have the tight dependency on the RTSS for these flows.

Thanks!

Matt

------------------------------
Matt Jenkins
------------------------------