Forum Discussion
daboochmeister
Cirrus
CirrusAPM session username/password vars not copied in from iRule? Not showing in session report, and auth always fails
I am setting up a clientless mode policy for a web service, where the caller passes in a basic auth header, and I want to pass the provided username/password into the policy. The iRule I'm using to do this is as follows:
when HTTP_REQUEST {
HTTP::header insert "clientless-mode" 1
if { not ( [HTTP::header exists Authorization] ) } {
HTTP::respond 401 WWW-Authenticate "Basic realm=\"FISERV Credentials\""
return
}
if { [HTTP::username] eq "" or [HTTP::password] eq "" } {
HTTP::respond 401 WWW-Authenticate "Basic realm=\"FISERV Credentials\""
return
}
log local0. "In HTTP_REQUEST, FISERV Username [HTTP::username], pw [HTTP::password]"}
when ACCESS_SESSION_STARTED {
log local0. "In APM session, FISERV Username [HTTP::username], pw [HTTP::password]"
ACCESS::session data set session.logon.last.username [HTTP::username]
ACCESS::session data set session.logon.last.password [HTTP::password]}
(Sorry, can't figure out how to do a clean code block).
The LTM log shows the correct HTTP vars, in both events in the iRule. In the policy, i have a logging agent that dumps session.logon.*, but last.username and last.password are never present (the only session.logon vars shown are captcha.tracking, page.errorcode, and page.challenge, all blank). And my local user db auth agent always denies access, going down the "locked out" branch (even though the user is not locked out per the local user DB info elsewhere in the APM menues). I get the following errors associated with the auth attempt:
"unable to decrypt user password due to invalid ciphertext" "Login for user FISERV, instance /Common/ESB-Fiserv rejected - Account locked out."
Again, the account doesn't show as locked out, and attempts is 0.
This is on 11.5.1HF5.
Thoughts? Suggestions on how to debug? Should I put in a var assignment agent in the policy, and if so, how to I acccess the HTTP vars in that context?
thx!
Amit_KarnikNimbostratus
-
Make sure you have the "ACCESS::restrict_irule_events disable" in an iRule on CLIENT_ACCEPTED. This will make sure that your iRule is actually executing while the policy is under evaluation.
-
Assuming that your iRule is working before the policy evaluation and you are still not getting the results, I can suggest a different approaach. a. Put the "Landing URI" policy element as the first check in the policy so that you ensure policy evaluation. b. Put an iRule event policy element as the second thing in the policy.
Step b will trigger the ACCESS_POLICY_AGENT_EVENT in the iRule which you will have to apply on the virtual. In this iRule you have access to the entire payload using the session variable session.server.initial_req_body.
Now since you are in the middle of the policy evaluation you can access both the HTTP content as well as APM session variables before you end the policy in an Allow or Deny.
Take a look at "ACCESS::session data get|set"
Best !!
-
daboochmeisterThank you, Amit - adding the "ACCESS::restrict_irule_events disable" didn't have any effect (in and of itself, but I left it in for your 2nd part, just in case).
I think I may be running into security restrictions on setting session.logon.last.password (" target="_blank">discussed here). I did your part 2 (though the HTTP:: vars weren't accessible in ACCESS_POLICY_AGENT_EVENT, so i had to create irule vars in ACCESS_SESSION_STARTED and copied from those). Then in the policy, i have a var assignment agent to copy those session.custom.username/password vars to session.logon.last.username/password. That gets me farther - the LocalDB auth agent at least checks the correct userid now. BUT - the password value appears not to have assigned. The password check always fails.
In the session report, I get an error msg like:
LOCALDB agent: (logon attempt:0) authenticate with '$CK$8JkcxNSl$6pu1Rjb3KxeNCSl7TmYsdQ==' failed
I'm not sure what that hash is ... but I do know I'm entering the correct password, and in the iRule that password is correctly present in the irule var that I assign to session.custom.password.
Hmm. Did something change in recent versions in session variable security protections or something?
- daboochmeisterThat link should be: https://devcentral.f5.com/s/feed/0D51T00006i7LsPSAU
- Amit_Karnik_269Indeed that has changed, to access secure variables you have to use the -secure flag ACCESS::session data get -secure Even then I think it may not allow you to set session.logon.last.password. What is your final intent ? If you want to do a SSO assignment, you could do a variable assign to a new variable, lets say session.logon.last.newpassword and then use that. Remember to mark it as secure otherwise the password is visible in reports and such.
- daboochmeisterIntent is to use basic authentication against a local user db for a web service, in clientless mode, since the web service clients may not support the standard APM session redirections. I just need some way to feed the HTTP::password, plucked from the Authorization header, into the Local DB auth agent. It sounds like this used to be easy, just do the stuff I've tried. Does anyone have such a scheme working on 11.5.1 or later?
- daboochmeister
Hmm. As a test, I replaced the policy with a simple one that uses a default logon page and LocalDB Auth agent - and it works. So nothing obvious wrong with my LocalDB or user accounts.
Comparing the sessions, using the logon page vs. clientless - during the LocalDB Auth agent processing, the clientless session report shows the following line:
LOCALDB agent: (logon attempt:0) authenticate with '$CK$WjQg31Du$NFM7lGxd9YAawb4+ZTwpcA==' failed
In its place in the similar report when using the logon page is simply "Username 'FISERV'" and nothing else. Maybe you need to prime vars other than session.logon.last.username and session.logon.last.password?
- Amit_Karnik_269In your clientless option, can you create an iRule event and access session.server.initial_eq_body ? If you can , then the request parameters are accessible but you still may not be able to set the "password" attribute.