PAPI Archivos

The PAPI authentication and authorization framework


Opciones: Vista Clásica

Use Monospaced Font
Mostrar las partes HTML
Mostrar todas las cabeceras de correo

Tema: [<< Primero] [< Prev] [Siguiente >] [Último >>]

Print Responder
"Diego R. Lopez" <[log in para visualizar]>
Mon, 18 May 2009 13:05:59 +0200
text/plain (64 lines)

On 16 May 2009, at 20:59, Roberto S. G. wrote:
> I've been using this "strange" ldap conf in for a while
> (with also a little modification in

Well, it's not that strange... You use LDAP to validate user credentials
and a default set of assertions.

>   $$cfg{authenticationHook} = \&PAPI::LDAPAuth::VerifyUser;
>   $$cfg{credentialHook} = \&PAPI::BasicAuth::DefCredentials;
>   $$cfg{attrRequestHook} = \&PAPI::BasicAuth::DefAttributes;
> so I could authenticate ldap users, without including PAPI  
> objectclasses
> in my ldap schema.

Our experience is that this has not been so unusual. PAPI classes make
sense mainly if you want to either:

+ Dynamically manage a great number of different permission sets  
through groups

+ Offer a simple interface to operation staff for dealing with  
assertions and
   access rights.

Otherwise, there are alternatives you can choose. The two that first  
come to
my mind are:

1) You put reference(s) to variable inside the default assertion  
templates, and
    you fill these variables according to the different cases you have  
inside the processing.

2) You change the LDAP filters and attribute refereces in use inside  
    module to avoid the need for PAPI objectlasses.

Both require some changes to the distribution code, but I don't think  
they are going
difficult to do (as the basic logic is not affected) or maintain (the  
modules are pretty stable).

Be goode,

"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez - RedIRIS
The Spanish NREN

e-mail: [log in para visualizar]
jid:        [log in para visualizar]
Tel:    +34 955 056 621
Mobile: +34 669 898 094