Jump to content

HTTP Callout Policy not accepting AAA.User.Attribute

Thomas Klein

Recommended Posts

Hi guys,


i got inspired by the blog post of Johannes Norz (https://literatur.norz.at/?p=414 - many thanks for that ?) i deployed a PHP Script, which grabs via MS Graph API a Users calendar entrys from today and displays them in a simple HTML table. 

HTTP Callout is working by hardcoding the userprincipalname of the User in the script. The result of the HTTP Callout is used by a rewrite policy that replaces the HTML body. That works so far.


Now i'm getting stuck by passing the userprincipalname to the HTTP Callout for getting used by passing to the script. If i use "aaa.USER.ATTRIBUTE(1)" in the body Expression or trying to insert the same in a header, the change on the HTTP Callout Policy gives me the red card:




If i'm right in case of that, the HTTP Callout does not accept values of the AAA flow. Generally, i hope there is a solution... is there any chance to pass aaa.USER.ATTRIBUTE(1) value by the rewrite policy to the HTTP Callout?


Actually, the corresponding Rewrite Policy is quite simple:



Many thanks & best regards


Link to comment
Share on other sites

Which firmware are you on?

Do you have AAA integrated with the lb/cs vserver that you are invoking the callout for?


Can you share your callout definition that you are trying to create?  And the exact error message.  Is the error when creating the callout OR invoking the callout in the rewrite policy?

I'm not in an environment where I can test an actual AAA invocation, but I was able to create a callout with the username in a parameter field and a header field to pass to the callout destination. (May not work; but there wasn't a syntax warning.)  It might just be an issue with how the callout is structured.


The callout request to the callout server is what should extract the username from the AAA request on this lb vserver/cs vserver transaction.  Your callout return type/response is basically the function output to get data out that the callout returns.  So, when you invoke the callout, the callout request retrieves username and sends to callout server to act on and return an output to the adc.  So the AAA transaction is associate with the user's logon to the lb/cs vserver. 





Link to comment
Share on other sites

Hi Rhonda, 

thanks for you quick reply. 

I'm on firmware 13.0 - 83.29. Correct, the LB vServer (behind a CS) has Form based Authentication ON by using a CAG vServer for Authentication, which has a AAA Authentication Profile bound with a nFactor procedure (Group Extraction, Radius & LDAP Auth).


The Callout is structured as follows:





and the Rewrite Action:



... and the Rewrite Policy (which is bound to the LB vServer):



This works so far with a hardcoded Username in the script "calendar.php" on destination Server of the HTTP Callout. If i try to access /content.html via the CS / LB vServer, the Rewrite triggers the HTTP Callout which gets back the response from the PHP script and the HTML body is filled with the response sucessfully.


Now, by trying to modify the working Callout by filling aaa.user.name or aaa.user.attribute(1) in the HTTP Callout - in the body expression or as i try it here - in a header field, i get the following message thrown:




For me, is seems that the callout does generally not accept AAA expressions. 

I'm with you, that the HTTP Callout should "know" the aaa username in any way to use it for the Callout... actually i simply got stuck how to use add it in any way to the Callout Definition.


Many Thanks & regards


Link to comment
Share on other sites

I was able to configure the aaa expression in the header or parameter field for a callout on 13.0.62 build (a bit older).  But didn't have a domain controller or a backend app to see if it would actually work.  

But - reading the error it says incompatible change to callout for in use callout.

can you try either removing the callout from your rewrite policy or make a copy of the callout v2 and set value from beginning while not in use and see if it takes it? So is the issue invoking the aaa call here OR is it changing an existing callout to making this expression?


The second problem might be if your rewrite is occurring on the response THEN the callout might not be able to invoke the AAA during the web response and would need the web request to see the AAA user name of the session. I don't know if this is the case or not, but the error isn't just a syntax error so it may be about context.


See if any of these things help at all.


I can't repro the error on my build but I also don't have a live authentication server or live lb vserver, so its not a 1-to-1 of what you are trying.  


Last thought:

It might be build specific and if you can try a different build and it works, then we know it is a version issue.  Not sure what the criteria is.  You said you did the hardcoded name and the callout does in fact work, its just solving this last bit.  There might be another way to work it once you narrow down if this is the syntax or one of the other issues.

  • Like 1
Link to comment
Share on other sites

6 hours ago, Rhonda Rowland1709152125 said:


can you try either removing the callout from your rewrite policy or make a copy of the callout v2 and set value from beginning while not in use and see if it takes it? 



You made my day :D 

WTF.... Seems to be a ugly GUI bug... i added the policy with the same informations freshly and also inserted aaa.user.attribute(1) in the header association -in the same step... that went fine :)

Also the PHP Script is now working by reading the Username from the header and displaying the appointments as designed.


Many thanks for you help!

nice regards





Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Create New...