PAPI Archivos

The PAPI authentication and authorization framework

PAPI@LISTSERV.REDIRIS.ES

Opciones: Vista Forum

Use Monospaced Font
Por defecto enseñar Text Part
Esconda cabeceras de correo

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

Print Responder
Received:
by LISTSERV.REDIRIS.ES (LISTSERV-TCP/IP release 16.0) with spool id 1436080 for [log in para visualizar]; Sat, 26 Jun 2010 19:57:09 +0200 from cain.rediris.es (cain.rediris.es [130.206.24.1]) by listserv.rediris.es (Postfix) with ESMTP id 489ACEED8 for <[log in para visualizar]>; Sat, 26 Jun 2010 19:57:09 +0200 (CEST) from relay.uco.es ([150.214.110.216]) by cain.rediris.es with ESMTP; 26 Jun 2010 19:54:06 +0200 from 232.red-79-147-167.dynamicip.rima-tde.net (HELO [192.168.1.10]) ([79.147.167.232]) by mandarcorreo.uco.es with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 26 Jun 2010 19:54:10 +0200
Sender:
The PAPI authentication and authorization framework <[log in para visualizar]>
References:
<[log in para visualizar]> <1277569049.4873.6.camel@anfitrion>
Date:
Sat, 26 Jun 2010 19:55:15 +0200
X-IronPort-AV:
E=Sophos;i="4.53,487,1272837600"; d="scan'208";a="24311124" E=Sophos;i="4.53,487,1272837600"; d="scan'208";a="14069127"
Reply-To:
The PAPI authentication and authorization framework <[log in para visualizar]>
Message-ID:
Content-Transfer-Encoding:
8bit
X-IronPort-Anti-Spam-Filtered:
true true
Content-Type:
text/plain; charset=UTF-8; format=flowed
Subject:
Received-SPF:
None identity=mailfrom; client-ip=150.214.110.216; receiver=lsv.rediris.es; envelope-from="[log in para visualizar]"; x-sender="[log in para visualizar]"; x-conformance=spf_only None identity=helo; client-ip=150.214.110.216; receiver=lsv.rediris.es; envelope-from="[log in para visualizar]"; x-sender="[log in para visualizar]"; x-conformance=spf_only
Delivered-To:
Emisor:
Luis Meléndez <[log in para visualizar]>
User-Agent:
Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4
In-Reply-To:
<1277569049.4873.6.camel@anfitrion>
X-IronPort-Anti-Spam-Result:
AncCANPbJUyW1m7YmWdsb2JhbACDHZwOFQEBAQEBBg0KBxEir0yDF409gSmBTwEEgTVyBA ApIBAErcJUxPk6fo/2dsb2JhbAAHgxbMRYMXjT2BKYFPAQSBNXIE
MIME-Version:
1.0
Parts/Attachments:
text/plain (102 lines)
El 26/06/2010 18:17, Sergio Gómez Bachiller escribió:
> Si es una aplicación en c++,, entiendo que es un CGI.
>
> Lo que necesitáis es una nueva página que cree la cookie que necesita
> vuestra aplicación. Esa página puede estar en PHP y protegida con
> mod_papi o con phpPoa.
>
> El portal de entrada será esa nueva página, que irá al GPoA/AS a
> identificar al usuario. Cuando regrese con la identificación, la página
> creara la cookie para vuestro CGI y hará un redirect para cargarlo. Como
> ya tiene la cookie que necesita, entiendo que no debería haber problema.
>
> Espero que se entienda lo que quiero decir,
>
> Un saludo.
>
> Sergio.
>
>
> On Sat, 2010-06-26 at 16:31 +0200, Agustin Lopez wrote:
>    
>> Hola!
>>
>> Estoy pensando en validar con PAPI una aplicación web
>> nuestra escrita en C++. En ésta, el usuario hace un login
>> con un formulario user/pw y se crea un cookie que será el que
>> sirve para validar el resto de las páginas que se pidan hasta el
>> logout, donde se borra el cookie. En principio no sería conveniente
>> usas proxies de reescritura, por lo menos para toda la aplicación.
>>
>> ¿Cuál sería el mejor modo de PAPIzar esta aplicación?
>>
>> Saludos,
>> Agustín
>>      

Hola voy a proponer otra forma, que es como esta protegida 
http://consigna.uco.es
Si no hay que proteger el simple acceso a la aplicacion sino a parte de 
sus funciones
(por ejemplo se puede entrar, hacer algo pero para poder acceder a todo 
hay que
autenticarse) puedes sustituir el formulario login/password por un boton 
o enlace 'Login'
que fuerza la autenticacion PAPI. Esta forma de funcionamiento se llama 
'lazy' y la
soporta mod_papi pero no la version mod_perl (no se si alguna version 
moderna lo
hace).
Proteges el Location de tu aplicacion con mod_papi configurado en modo 
'lazy' y al
pinchar en Login, rediriges. Si vuelve ya autenticado, mod_papi te habra 
definido
$_SERVER['REMOTE_USER']. Por tanto una de las primeras cosas que debe hacer
tu aplicacion es ver si esa variable tiene valor y si es asi, considerar 
que ya esta
autenticado. No haria falta que mantengas cookies locales. Si lo haces, 
al pinchar el
usuario en 'logout' no basta con borrarlas, porque puede volver a 
pinchar en 'Login'
y volveria a entrar sin pedirle usuario/clave por las cookies de PAPI. 
El boton de
logout debe forzar el logout de PAPI para que no pase eso.

La config. es algo como:

<Location /cgi-bin/XXX>
     AuthType PAPI
     PAPILazySession On
     PAPIRemoteUserAttribute ePTI   # El atributo de PAPI del que sacar 
'REMOTE_USER'
     Require valid-user
     PAPIServiceID XXX_svcid
    ...
     PAPIGPoAURL ...
</Location>

Y en la aplicacion (Consigna es PHP pero es parecido):

     if (!array_key_exists('REMOTE_USER',$_SERVER)) {
         header("Location: " . <URL-de-tu-aplicacion>.
             "/PAPI/cookie_handler.cgi?target=" .
             urlencode($GLOBALS["script_name"]));
         exit;
     }

   // Aqui esta autenticado, solo algo 'superior' (mod_papi) ha podido 
poner $SERVER['REMOTE_USER']
   ...

Un saludo

P.D.: Disculpad la ausencia de acentos, mi PC tiene un problema con ellos...


-- 
"If you tolerate this, then your children will be next"

Luis Meléndez
Universidad de Córdoba - Servicio de Informática - Sistemas
Tel: +34 957 211022

ATOM RSS1 RSS2