FreeRADIUS - Noções básicas - Parte III

Terceira parte do artigo sobre noções básicas de FreeRADIUS.

[ Hits: 7.516 ]

Por: Perfil removido em 15/07/2015


Tabela de ação



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.

Página anterior     Próxima página

Páginas do artigo
   1. Seções de processamento de pacotes
   2. Tabela de ação
   3. Contabilidade
Outros artigos deste autor

Servidores Debian ou Ubuntu integrados ao AD com cid-tty

Criando um servidor de impressão para residências e pequenas empresas com Linux

Como imprimir diretamente na porta de impressão

Banco de dados e Cloud Computing, melhor opção?

Verificando a temperatura do HD no Slackware

Leitura recomendada

Fazendo o sistema de peticionamento do TJSP funcionar no Arch Linux (2018)

Teclados USB e Linux

Configuração de Vídeo - SIS530, SIS620 e CIA...

Recuperando e/ou adaptando o GRUB do Sabayon Linux

Atualizando sua versão Slackware - upgrade de pacotes

  
Comentários

Nenhum comentário foi encontrado.


Contribuir com comentário




Patrocínio

Site hospedado pelo provedor RedeHost.
Linux banner
Linux banner
Linux banner

Destaques

Artigos

Dicas

Tópicos

Top 10 do mês

Scripts