[Cascavel-pm] [Projeto]: API de Autenticação Versátil e Auto-Extensível

[Daniel Ruoso]

Acredito que para ser versátil, o uso da API não deve amarrar a
determinado método de autenticação. Acho que é interessante pensar em
"security-domains", como é o PAM. Cada security domain tem a sua
configuração de que métodos são necessários, para se autenticar um
usuário, como por exemplo, dizer que se o cara está dentro de um
ssh-agent e ele faz uma chamada utilizando uma chave autorizada, ele não
precisa digitar a senha para entrar.

No que isto implica?

Basicamente, seria necessária a implementação de dois conjuntos, um
conjunto de Subjects, Principals e Credentials (vou explicar o que é
isso) e um conjunto de Login Modules, configurados para um Security
Domain.

Subject: uma pessoa, um indivíduo que terá acesso ao sistema.

Principal: Uma das formas de identificar o Subject, por exemplo: uma
chave dsa de ssh, ou uma chave GPG, ou um login.

Credential: A forma de validação de um principal, por exemplo a senha
para aquele login.

Login Module: Um dos serviços de autenticação, por exemplo, validar
login e senha, checar uma assinatura GPG

Security Domain: Um determinado conjunto de definições de quais Login
Modules são requeridos para a autenticação do usuário.

Resumindo.

O software que quisesse consultar a autenticação teria que construir o
conjunto de Principals e Credentials e passar para o security domain
específico e esperar a resposta.

O security domain iria ser responsável por pegar estes Principals e
Credentials,  chamar os Login Modules e obter as resposta.

Acredito que desta forma seria possível se fazer uma autenticação bem
versátil, e ainda com uma vantagem, que é a de seguir um padrão de
autenticação com conceito mais do que provado que é o PAM e o JAAS (Java
Authentication and Authorization Service)

[]'s

daniel

Em Ter, 2003-10-07 às 09:36, Luis Campos de Carvalho escreveu:
> Nelson C. T. Ferraz wrote:
> > Luis Campos de Carvalho wrote:
> > 
> >>   e gostaria que isso funcionasse em qualquer situação. Mas existem 
> >> pequenos problemas. Por exemplo, o LDAP precisa de mais informação do 
> >> que isso para funcionar. Da mesma forma, o DBI e o CGI também 
> >> precisarão. Como codificar isso tudo em um URI fácil de usar e simples 
> >> de resolver?
> > 
> > 
> > Você poderia passar estas informacões usando um hash:
> > 
> > my $auth = new Auth (
> >             type => "DBI",
> >             db_name => "test",
> >             db_host => "localhost"
> > );
> > 
> > Se você quiser muito usar uma string, pode usar uma estrutura como esta:
> > 
> > "type:DBI db_name:test db_host:localhost"
> > 
> > Aí é só transformar a string em um hash.
> > 
> 
>    Obrigado, Nelson, mas ainda não cheguei lá.
>    Eu não tenho problema para codificar coisas como o query de SQL que 
> deve ser utilizado pelo Auth::DBI nem o URL que deve ser utilizado pelo 
> Auth::CGI para autenticar o sujeito. Meu problema é codificar isso tudo 
> de forma que eu possa instanciar automaticamente o tipo correto, sem 
> precisar de muito esforço.
> 
>    Caso eu precise passar parâmetros como estamos vendo, não conseguirei 
> a tão desejada *uniformidade*, característica sem a qual uma interface 
> não tem razão de ser.
> 
>    Eu pensei em usar um esquema parecido com nossos URI's:
> 
>    pop://host
> 
>    cgi://true_answer:false_answer@URL
> 
>    htpp://www.authentication.via.apache.org
> 
>    sql://dbuser:dbpasswd:SELECT user, passwd FROM table WHERE user = ? 
> AND passwd = PASSWD(?) LIMIT 1 em host
> 
>    Vejam como este esquema funciona bem para a maior parte das formas 
> utilizadas. Meu problema é que ainda não é bom para SQL, ou eu ainda não 
> consegui encontrar um padrão descente para codificar um URI para Auth::DBI.
> 
>    Sugestões, palpites, encorajamentos, piadinhas (engraçadas) e 
> críticas são muito bem-vindas...