I have a requirement to maintain session credential attribute information across multiple authentication levels.  In my case, the user first authenticates to a cert required webseal instance and hence the first auth level is ssl.  During this authentication, I use the user name mapping module XSLT (could just as easily use LUA) to grab various x509 attributes, such as the cert fingerprint and valid to/from information, and put in various session credential attributes.  These attributes are then passed to backend applications using HTTP headers or other means as they are required to either present information to the backend for authorization decisions or user informational screens.

When the user changes authentication levels upwards to another level, for example password or EAI, these session credential attributes are not preserved.  I have tried both using the user name mapping module and LUA to try to preserve these attributes with no success.  During the user name mapping module, if stepping up to password, the x509 attributes are not available during the password step-up authentication.  For LUA, the same applies.

Regarding LUA, I turned on every stage of transformation on a test LUA rule that outputs the entire context.  I then enabled debugging on pdweb.http.transformation (level 9) and collected the output to try to determine during the POST /pkmslogin.form if I could grab the previous session credential attributes before the authentication occurred and then set them back later.  Unfortunately it seems the pkmslogin.form can only be transformed at the request and postauthn:password stage.  At the request stage, there are no session attributes available.  At the postauthn stage, the authentication has already occurred and I've lost the x509 data I need.

I then had the idea of perhaps I could set actual session attributes, not session credential attributes.  However, if I try to use Session.setSessionAttribute() in the LUA rule at the response stage, I get "service unavailable" from webseal and see DSC issues in the webseal logs.  If I try to set it at the postauthn:ssl stage, there is no session ID and there is a message reported in the debug that notes "Not adding the session attribute: ... (no session)".  Note, I can successfully set session credential attributes using Session.setCredentialAttribute.  I was hoping, however, that perhaps if I set an actual session attribute it would be preserved after the credential changes from ssl to password, and hence in the postauthn:password stage I might be able to retrieve those session attributes from the ssl stage and put them on the session password credential attributes.

In my case, my requirement is to make the ssl x509 information available after a step-up password authentication has occurred, and to not to make a call to an external dependency (i.e. the runtime) to reduce potential impacts to authentication (latency and reliability).  One of my other thoughts was to try coding a LUA EAI for the password authentication, but this would also mean having to handle password changes, etc. which would be a lot of code to maintain and hence complexity.  In addition, from what I've seen, I still don't think the x509 attributes would be available even to the EAI when the step-up occurs.  The only other thought was to use LUA to make use of some external means to store the x509 information between the authentication levels, meaning, using a database, LDAP, Redis, or something custom to maintain the cert data in between the authentication levels.  However, using an external store introduces a dependency into the authentication flow which is against my initial set of requirements.

I'm hoping that perhaps someone else has had to preserve x509 attributes from an ssl authentication for a later stage of authentication, such as after additional MFA occurs.  Any thoughts would be greatly appreciated.  Thus far I have hit a dead end on this, yet this is a customer requirement I have to meet.

Cert EAI auth is not working on v11.0.0.0_IF1 following the example in the knowledge center.  The LUA is never called and it goes into an endless redirect loop (likely due to LRR).

At first I just tried to use eai-uri = %lua-eai% in the [certificate] stanza and setup the transform.  That didn't work so I moved forward with setting up all the trigger URLs and LRR according to the docs.  Even with a simple LUA it would not invoke the transform rule.  I made sure to disable the user-map-authn and disable all other transform rules to rule anything else out.

If I could just use the eai-uri in cert things would not be so complicated.  However, messing around with the LRRs is just introducing a whole new complexity into our authN flow where things could go sideways.  In any case, I can't get either to work, simply using just eai-uri or using it in conjunction with all the LRR stuff.

I assume you used Session.setSessionAttribute() in the postazn and Session.getSessionAttribute() in the postauthn:password stage?  I assume setSessionAttribute must only work during the postazn which from what I recall I could not get to fire on /pkmslogin.form.  I could only get the password authN to fire request, postauthn:password, and response, and I couldn't set the session credential in any place.

I have an idea/RFE out there for you all to enhance the product to carry the session credential attributes (or x509 attributes) into the next credential attributes when a step-up occurs.  From what I am seeing, it still doesn't look feasible with LUA since I can't get the LUA in this case to be an EAI for cert auth.

Here is the config I used:

[http-transformations]
pkmslogin.lua = cert-eai.lua

[http-transformations:pkmslogin.lua]
request-match = postazn:GET /pkmslogin.lua*

[certificate]
accept-client-certs = required
eai-uri = %lua-eai%

[eai-trigger-urls]
trigger = /pkmslogin.lua*

[acnt-mgt]
enable-local-response-redirect = yes

[local-response-redirect]
local-response-redirect-uri = [login] /pkmslogin.lua

[user-map-authn]
# rules-file = 


In cert-eai.lua:
Authentication.setUserIdentity(Client.getCertificateField("SubjectDN"), false)