handler
The Policy Handler specifies how incoming requests are processed. The handler can, for example, be used to specify authentication methods, authorization rules, post-AAA actions and logging. Multiple handlers can be defined within a policy.
The handler is made from two execution pipelines: @execute, which is executed for incoming requests, and @final-execute, which is always executed after the reply has been sent regardless of the result in @execute, which is usually used for logging. See Execution Pipelines for details on pipeline syntax and control flow.
Only one policy and handler can be selected for each incoming request. Use the conditions blocks to control the selection. If no handlers match, the pipeline result is ignore.
Example
Here is an example configuration of a policy with two handlers, one for RADIUS authentication and one for accounting:
policy "AUTHENTICATION" {
conditions all {
radius.server == "RADSEC_SERVER";
radius.request.code == radius.ACCESS_REQUEST;
}
handler "AUTHENTICATION" {
@execute {
backend {
name "SQL";
query "FIND_USER";
}
pap;
}
# Final execute is executed after the response has been sent to the client.
@final-execute {
invoke "LOG_AUTHENTICATION";
}
}
}
policy "ACCOUNTING" {
conditions all {
radius.server == "RADSEC_SERVER";
radius.request.code == radius.ACCOUNTING_REQUEST;
}
handler "ACCOUNTING_START" {
conditions all {
radius.request.attr.Acct-Status-Type == radius.dict.Acct-Status-Type.Start;
}
@execute {
backend {
name "SQL";
query "MARK_SESSION_START";
}
accept;
}
@final-execute {
invoke "LOG_ACCOUNTING";
}
}
handler "ACCOUNTING_ALIVE" {
conditions all {
radius.request.attr.Acct-Status-Type == radius.dict.Acct-Status-Type.Alive;
}
@execute {
backend {
name "SQL";
query "MARK_SESSION_ALIVE";
}
accept;
}
@final-execute {
log "ACCOUNTING" {
json {
"user" aaa.identity;
"result" aaa.result;
"reason" aaa.reason;
"errors" aaa.errors;
}
}
}
}
handler "ACCOUNTING_STOP" {
conditions all {
radius.request.attr.Acct-Status-Type == radius.dict.Acct-Status-Type.Stop;
}
@execute {
backend {
name "SQL";
query "MARK_SESSION_STOP";
}
accept;
}
@final-execute {
invoke "LOG_ACCOUNTING";
}
}
}
Request Processing Flow
Here's a sequence diagram illustrating the request processing flow for the AUTHENTICATION handler in the example configuration: