Cada seção de processamento possui uma lista com as respostas padronizadas para vários códigos de retorno. Por exemplo, noop é usualmente ignorado, reject causa uma parada no processamento da lista etc.

Cada código de retorno possui uma prioridade: reject tem a maior prioridade que noop. A tabela a seguir, lista os códigos de retorno e as ações padronizadas que são tomadas em cada caso:

Algoritmo

Todos as peças necessárias para entender como o servidor processa uma requisição já foram apresentadas. O servidor inicia cada requisição com um código de retorno e uma prioridade padrão. Ele processa a requisição através de uma seção de processamento.

Cada declaração ou módulo é avaliado e o código de retorno é utilizado para atualizar o código de retorno final que será associado com a requisição. Quando a lista termina, o servidor continua para a próxima lista ou envia uma resposta ao requisitante.

O algoritmo utilizado para isso possui o seguinte pseudocódigo:

(code, 0) = action_table[default]

foreach (statement in section) {

	code' = evaluate(statement)
	(action, priority') = action_table[code']

	if (action == return) {
		code = code'
		break;
	}

	if (priority' >= priority) {
		(code, priority) = (code', priority')
	}
}
return (code, priority)

A função de avaliação no algoritmo deve ser vista como a execução de um dos módulos instalados ou ser interpretada como uma declaração escrita em Unlang.

Quando uma declaração em Unlang invoca uma subseção, o algoritmo é executado de forma recursiva nessa subseção. Deste modo, FreeRADIUS pode invocar uma ou mais das seguintes seções de processamento:

• authorize
• session
• authenticate
• post-auth
• preacct
• accounting
• pre-proxy
• post-proxy
• send-coa
• recv-coa

A imagem a seguir ilustra como as seções de processamento são invocadas em cada um dos cados de uso: Vejamos o que acontece quando um servidor FreeRADIUS recebe uma requisição de acesso e faz a autenticação de um usuário.

O nome da seção é "Authorize" por razões históricas, as versões menores de FreeRADIUS não possuem uma seção post-auth. Uma descrição mais acurada para essa seção seria pre-authentication.

A seção "Authorize" processa pacotes do tipo Access-Request, determinando qual o método de autenticação será utilizado e se a senha está correta. Uma vez que essa seção termina o processamento do pacote, o código de retorno da seção é examinado pelo servidor.

Se esse retorno é noop, notfound, ok ou updated, o processamento da requisição segue. Se o retorno é handled, ele presume que um ou mais módulos configuraram o conteúdo da resposta que o servidor enviará. Se o retorno é reject uma seção de post-auth é executada. Se a autenticação não é rejeitada, então o servidor segue o processamento procurando por um atributo Auth-Type na lista de controle.

Quando esse atributo é encontrado a subseção authenticate é executada. Para versões superiores a 2.0, o recomendado é utilizar declarações Unlang para criar políticas que são mais flexíveis e simples de entender.

A seção "sessão" (isso está certo!) é utilizada para realizar consultas a bancos de dados quando aplicando Simultaneous-Use ou detecção de duplo login. Isso é utilizado somente em pacotes Access-Request. A tabela a seguir lista os códigos e as ações adotadas na sessão. A seção de autenticação (authenticate) é utilizada somente quando o servidor estiver autenticando requisições localmente e será ignorada quando um pacote estiver ultrapassando o servidor com destino a um proxy.

Essa sessão é completamente diferente das demais: ela é composta por uma série de subseções, mas somente uma das quais é executada. A subseção é escolhida baseado no atributo Auth-Type encontrado na lista de controle. Quando a seção authenticate é finalizada, a seção post-auth é executada. A tabela a seguir lista os códigos e as ações na seção Authenticate. Uma seção post-auth contém as políticas que são aplicadas após o processo de autenticação acabar, independente do resultado final ser sucesso ou fracasso.

Quando a autenticação falha, o servidor procura por uma subseção chamada de Post-Auth-Type Reject e, se encontrada, executa somente as declarações que são escritas nessa subseção.

Se não há essa subseção, nada é feito. Para atualizar qualquer atributo na resposta, é recomendado usar somente a seção post-auth, o que pode ser difícil já que muitos módulos fornecem atributos de reply com o método authorize. Todavia, esses métodos podem ser chamados em post-auth usando module-name.authorize como, por exemplo, sql.authorize.