Utilidade de um filtro absoluto em uma consulta LDAP?

3

Eu estava examinando a fonte do OpenLDAP e vi onde o DSE raiz suporta algo chamado de filtros absolutos. Parece que está especificado em RFC4526 Parece que o autor que originalmente o elaborou estava trabalhando no projeto OpenLDAP, então eu não Não sei se isso é algo útil para essa implementação específica ou o quê.

De qualquer forma, o RFC fornece esta definição:

   An 'and' filter consisting of an empty set of filters SHALL evaluate
   to True.  This filter is represented by the string "(&)".

   An 'or' filter consisting of an empty set of filters SHALL evaluate
   to False.  This filter is represented by the string "(|)"

Minha pergunta é: qual a utilidade disso? Não consigo pensar em nenhum exemplo em que isso forneça a capacidade de fazer algo que você não pudesse fazer antes. Se você quiser um AND absoluto, não poderá fazer um filtro (objectClass=*) , pois todas as entradas devem ter pelo menos uma classe de objeto?

O único que eu posso pensar em um uso é o Absolute False. Pode ser que você queira apenas fazer um noop no servidor para garantir que a comunicação ainda esteja funcionando normalmente. Isso ainda é meio redundante, já que eu pensaria em consultar o DSE raiz e descartar os resultados faria a mesma coisa e não poderia ser tão computacionalmente caro.

Usar o filtro em um ldapsearch produz os resultados, acho que devo esperar, dado o acima:

[root@hypervisor openldap]# ldapsearch -x -H ldap://policyServer.trunkator.com -b '' -s base "(|)" +
# extended LDIF
#
# LDAPv3
# base <> with scope baseObject
# filter: (|)
# requesting: +
#

# search result
search: 2
result: 0 Success

# numResponses: 1
[root@hypervisor openldap]#

Usar o filtro true absoluto retorna a mesma coisa que se eu tivesse feito um (objectClass=*) (que é o filtro padrão para o ldapsearch client do OpenLDAP se você não especificar um na linha de comando).

De acordo com o RFC, eles removeram estes do RFC LDAPv3 original e, assim, o autor teve o trabalho de recuperá-los em e estou curioso para saber por quê (tenho certeza há uma razão).

Alguma idéia?

EDITAR:

Um pouco de comentários iniciais: Quando digo "suporte a DSE raiz", uma maneira mais clara de dizer é que o DSE raiz no OpenLDAP é codificado para informar que ele suporta filtros absolutos.

    
por Bratchley 26.07.2013 / 21:46

2 respostas

3

As seções Abstract e Background do RFC afirmam claramente que esse recurso foi negligenciado no LDAP v3. O conceito de filtros absolutos aparentemente faz parte do X.500 / DAP e eles visam ajudar na consulta de entradas específicas do DSA, que podem não ter uma classe de objeto associada a elas. Embora isso obviamente não seja um recurso específico do fornecedor, sua implementação é deixada para o fornecedor (por exemplo, o OpenLDAP parece tê-lo implementado). Não parece ser muito útil se o software de diretório utilizado associe todas as entradas, incluindo as específicas de DSA com uma objectclass (por exemplo, top), o que faz com que o filtro '(objectclass = *)' funcione como se fosse um filtro absoluto Isso resulta em "verdade". Se o software de diretório não associar entradas específicas de DSA a uma classe de objeto ou outro atributo cujo valor específico será resolvido como 'true' em uma pesquisa, um filtro absoluto que atua como um comutador true / false se torna uma característica obrigatória ( a menos que o software de diretório forneça uma maneira proprietária de recuperar tais entradas, o que provavelmente não é uma boa idéia, já que a implementação fora do padrão forçará os clientes LDAP a serem limitados / específicos ao fornecedor).

    
por 28.07.2013 / 19:56
2

Eu suspeito que é para tornar certas construções de programação mais fáceis. Por exemplo, se você criar expressões de filtro em seu código da seguinte forma:

filter_string='(&'
for filter in filters:
    filter_string = filter_string + '(' + filter + ')'
filter_string = filter_string + ')'

... no caso em que você não tem filtros, você termina com (&) e a parte do RFC que você destacou define como isso deve se comportar. O mesmo raciocínio vale para (|) .

    
por 26.07.2013 / 22:05

Tags