PAPI Archivos

The PAPI authentication and authorization framework


Opciones: Vista Forum

Use Monospaced Font
Por defecto enseñar Text Part
Mostrar todas las cabeceras de correo

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

Print Responder
"Diego R. Lopez" <[log in para visualizar]>
Reply To:
The PAPI authentication and authorization framework <[log in para visualizar]>
Mon, 12 Sep 2005 09:22:29 +0200
text/plain (130 lines)
Dear friends,

The PAPI Development Team is proud to announce the new PAPI 1.4.0. This
new version is available at the PAPI web site

This new relase is the first step in achieving PAPI interoperability
with existing infrastructures. We are working in integrating PAPI with
PHP and Tomcat, and with SAML-based systems (most notably, Shibboleth).
New connectors will soon be available, either as part of a new release
or as add-ons to the current one. We enclose here a list of the main
changes from the previous version (1.3.1) from the PAPI release notes:

- IMPORTANT: The license under which PAPI is distributed has changed.
   The Artisitic license is no longer applicable to PAPI from version
   1.4.0. Only the GPL license shall be applied.

- It is possible to access Athens-enabled resources
   ( through PAPI. The PADATH (PAPI Adaptor to
   Athens) allows a PAPI PoA to use Athens Devolved Authentication
   procedures for exchanging identity assertions with the Athens
   services. Thanks to the Eduserv staff, and specially to David Orrell,
   for their support in the development of PADATH.

- The SPOCP interface has been adapted to version 2 of the authorization
   system. This adaptation includes some changes in the format of the
   queries made by a PAPI PoA to a SPOCP server. Refer to the 
   documentation to see how to adapt your SPOCP rules accordingly.

- Extend some of the Makefile.PL so install procedures can also work
   with MakeMaker >= 6.17. Noted by Oriol Rico ([log in para visualizar]) and
   Jordi Prats ([log in para visualizar]) from UPC.

- Sites with a blank service identifier will not be included in the list
   of PoAs directly contacted upon successful authentication. This allows
   for including a comprehensive list of available sites in the data 
   (papiSite objects in LDAP, for example), but only contacting those
   relevant at the moment of authentication (only top-level GPoA(s), for
   example). Suggested by Luis Melendez ([log in para visualizar]) from the 
   of Cordoba.

- A new element for describing PoAs through "PAPI sites" (either in DB
   files or LDAP objects) has been introduced. The optional element
   accessURI can be used to define the initial page to be linked when the
   AS builds the list of contacted PoAs upon successful authentication.
   This element is modeled as an additional field in DB files and the new
   attribute papiSiteAccess in the PAPI LDAP schema. Suggested by Maja
   Gorecka-Wolniewicz ([log in para visualizar]), from the Nicolaus
   Copernicus University, Torun, Poland.

- Connection and configuration variables can now be substituted into
   LDAP search bases inside

- Correct a bug in that causes the PoA code to croak if no
   PAPI_Main section was defined inside the Apache configuration file for
   certain Perl installations. Noted by Antonio Ruiperez
   ([log in para visualizar]) from the UNED

- Correct some bugs about URI escaping and unescaping of URLs in the
   modules inside the Main_Handlers directory. Contributed by Maja
   Gorecka-Wolniewicz ([log in para visualizar]), from the Nicolaus
   Copernicus University, Torun, Poland.

- A GPoA receiving a CHECK request is able now to make the decision
   either based on HCook (as it did until now) or LCook (just as a normal
   PoA does), guaranteeing the coherence of PoA/GPoA interactions. Noted
   by Victor Hernandez ([log in para visualizar]), from the Pablo de Olavide

- Allow "chunked transfers" in proxy mode: When accessing large contents
   it is possible to do so in chunks, passing them to the requesting
   browser as they become available at the proxy. The directive
   Proxy_Chunk_Size controls this behavior.

- A completely new interface for the proxy form processor is provided.
   Contributed by Maja Gorecka-Wolniewicz ([log in para visualizar]),
   from the Nicolaus Copernicus University, Torun, Poland.
   WARNING: This new interface implies a complete change to the
   Form_Processor directive syntax and semantics. If you use this
   directive in your PAPI installation, update it according to the

- A PoA in proxy mode can now set the local IP address to be used when
   contacting remote site(s), via the new Local_IP_Address directive.
   Contributed by Valery Tschopp ([log in para visualizar]) from SWITCH.

- Proxy mode is able to deal with XHTML tags (including a mix of HTML
   and XHTML) and with any "on*" (JavScript-enabling) attribute.
   XML/XHTML processing mode can be deactivated by setting the No_XML
   new directive to 1. Thanks to Antonio Ruiperez ([log in para visualizar])
   from the UNED, and Alberto del Campo ([log in para visualizar]) from the
   University of Las Palmas de Gran Canaria for their support in testing

- Regular expressions applied in proxy mode are no longer passed through
   the Perl eval function, unless the new directive Eval_Proxy_Redirects
   is set to 1. This avoids (mostly unused) evaluations that clobber logs
   and may lead to security problems. Noted by Roman Medin
   ([log in para visualizar]) from Telefonica Moviles.

- A PoA in proxy mode is now able to work under a TLS connection. The
   rewriting functions can recognize and process both the http and https
   schemas in URLs. Contributed by Roman Medina ([log in para visualizar]) from
   Telefonica Moviles.

- Correct an error in the way in which the RewritingProxy deals with
   cookies when proxying a whole remote domain. Contributed by Luis
   Melendez ([log in para visualizar]) from the University of Cordoba.

- Correct several subtle flaws in RewritingProxy, dealing with form
   processing, header management and content type handling. Noted by Luis
   Melendez ([log in para visualizar]) from the University of Cordoba and Antonio
   Ruiperez ([log in para visualizar]) from the UNED.

"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