Radiator Server Documentation — v10.33.2

Pipeline Directives

Control flow for pipeline execution

Table of Contents
  • first
  • Example
  • any
  • Example
  • while - Default
  • Example
  • all
  • Example
  • none
  • each
  • Example

NOTE: The until action should be used instead of pipeline directives. The until action provides a readable and flexible way to control pipeline execution.

Pipeline directives control how a execution pipelines react to the action results. The directive can be explicitly requested using the standalone actions:

Or they can be used as parameters in these actions:

first

Stops on first accept or reject and returns that. If no accept or reject is encountered, ignore is returned.

Example

When you want the first non-ignoring action to provide a result to make the decision

first {
    backend "PRIMARY_AUTH"; # ignores if does not find user
    backend "FALLBACK_AUTH";
}

any

Stop on first accept. If no accept is encountered, return the last reject or ignore.

Example

When calling multile backends or methods where any success is sufficient

any {
    pap;
    chap;
}

while - Default

Stop on reject. Return the last accept or ignore.

NOTE: This is not a loop.

This the default behavior for pipelines. There is really no need to use the standalone while action but it can be used for clarity in the with action.

It should noted that if a policy handler returns ignore as the last action it will still reject the request.

Example

All must accept or ignore

while {
    backend "USER_EXISTS";
    script "CHECK_BUSINESS_HOURS";
}

or since this is the default behavior, you can simply write:

backend "USER_EXISTS";
script "CHECK_BUSINESS_HOURS";

all

All actions must accept. If any action returns ignore or reject, that is returned immediately.

Example

All verifications must succeed

all {
    backend "VALIDATE_USER";
    backend "CHECK_PERMISSIONS";
    backend "VERIFY_LICENSE";
}

none

🚨 None is known to be buggy. Do not use for now.

All actions must return reject, then returns accept. If any action returns accept or ignore then reject is returned immediately.

none {
    backend "EMPLOYEE_DB";
    backend "CONTRACTOR_DB";
    backend "VPN_USERS";
}
# must be guest user

each

Return the result of the last action.

Note that this does not capture errors. If you need to catch errors, use the try action.

Example

each {
    # does not matter if these reject or ignore
    backend "STORE_ANALYTICS";
    backend "LOG_ACCESS";

    # this result is returned
    backend "PRIMARY_AUTH";
}
Navigation
  • About Radiator software development security

  • Architecture Overview

  • Backend Load Balancing

  • Basic Installation

  • Built-in Environment Variables

  • Comparison Operators

  • Configuration Editor

  • Configuration Import and Export

  • Data Types

  • Duration Units

  • Environment Variables

  • Execution Context

  • Execution Pipelines

  • Filters

  • Getting a Radiator License

  • Health check /live and /ready

  • High Availability and Load Balancing

  • High availability identifiers

  • HTTP Basic Authentication

  • Introduction

  • Linux systemd support

  • Local AAA Backends

  • Log storage and formatting

  • Management API privilege levels

  • Namespaces

  • Password Hashing

  • Pipeline Directives

  • Probabilistic Sampling

  • Prometheus scraping

  • PROXY Protocol Support

  • Radiator server health and boot up logic

  • Radiator sizing

  • Radiator software releases

  • Rate Limiting

  • Rate Limiting Algorithms

  • Reverse Dynamic Authorization

  • Service Level Objective

  • TACACS+ Authentication, Authorization, and Accounting

  • Template Rendering CLI

  • Tools radiator-client

  • TOTP/HOTP Authentication

  • What is Radiator?

  • YubiKey Authentication

  • YubiKey Context Variables