PAPI - Frequently Asked Questions

USING PAPI

Is it possible to run a PAPI AS and a PAPI PoA in the same Web server?

Yes. You can run as many ASs and PoAs as you wish in the same server, sharing or not their configuration files.

Is it possible to mix authentication methods in a PAPI AS?

Yes. The PAPI Authentication Server incorporates several hooks for functions that perform user authentication and provide the PoAs a user can connect to. You can, for example, use a POP-3 username/password pair to validate that a user is who (s)he pretends to be, and LDAP to retrieve the list of PoAs (s)he has access to.

I have some resources accessed through remote terminal/desktop emulations. Can I control the access to them with PAPI?

As far as we know, yes. We have successfully tested a PAPI setup for accessing resources through Citrix Winframe, and we are working on a general framework for this kind of resources. Since this software is not part of the standard PAPI distribution, drop us a message (papones@rediris.es) if you need it.

How deals PAPI with password-protected resources?

Well, PAPI is a replacement for locally protecting resources by username/password pairs, so the administrator of the resource does not need to worry about remote users anymore.

Anyway, if you are trying to use a PAPI PoA as a proxy for a password-protected resource, you have a couple of alternatives (see the corresponding sections in the Guide for Beginners):

From version 1.2, a PAPI PoA in proxy mode incorporates the configuration directive HTTP_Auth, that can be used for specifying parameters for HTTP Authentication methods (either Simple or Digest) for different realms in a remote server or proxy.

From version 1.3, it is also possible to use a PAPI PoA in proxy mode to automatically fill forms at the remote servers (by means of the configuration directive Form_Processor). Apart from other purposes, this can also be used for providing access control information (usernames, passwords, etc.) at a remote resource.

And remember that:

1. You can use internal variables of the PAPI PoA (either from the configuration or read from the access tokens) in the directives if you set the directive Eval_Proxy_Redirects to 1. In that case, the values of most proxy configuration directives are passed through Perl eval prior to their application.

2. It is possible to derive internal values for the access tokens (using data that are fully local to the PoA) from the contents of the assertions received from the AS by means of the directive Hcook_Generator.

3. It is possible to use a specific program for issuing the correct password from the PAPI access tokens, by means of the Hcook_Handler directive.

What URL do the users see for accessing a PoA protecting a remote resource? What about absolute URLs inside this remote site?

Users see the URL of the PoA. If a PoA at http://my.poa is giving access to http://remote.resource, the configuration directives of PAPI allow to redirect any request for http://my.poa/apage.html to http://remote.resource/apage.html.

Furthermore, if inside the requested information is a URL pointing to http://another.resource/otherpage.html and we know that access to this resource is controlled by a PoA at http://my.other.poa, it is possible to make PAPI rewrite the URL before delivering the page to the user, so the URL points to http://my.other.poa/otherpage.html

What happens if the user goes to the resource first, without going through the AS first?

If a user goes to a resource without going to the AS first you have three scenarios:

The tokens installed by the PoAs live for a fixed amount of time. So if the user authenticated some time ago at the AS and this time is still within the lifetime of the tokens (the Hcook) for the PoA, access to the resource will be automatically granted.

You can configure a PAPI PoA to directly query the authentication server for user's attributes (and authenticate them if necessary). If the PoA is able to recognize more than one authentication server, an intermediate service known as WAYF (the initials of the question ``Where Are You From?'') must be used in order to determine the appropriate AS. PAPI provides a built-in WAYF facility, although any URL can be used as long as the interface between the PoA and the WAYF service is preserved.

If the cases above are not applicable, a PAPI PoA simply makes the Apache server to send a ``403 Forbidden'' response to the client. You can configure the server to include quite a lot of information when rejecting a request with a ``403'' code using the Apache config directive ErrorDocument.

I'd like to change the images the PoA sends to signal acceptance of a request from the AS: the red and blue balls do not fit the style of my pages.

From version 1.1.0, the AS can indicate each PoA a couple of URLs where the content to be loaded in case of acceptance/reject can be found. These URLs may be defined using the papiSiteAcceptURL and papiSiteRejectURL of the papiSite LDAP class (if you are using a PAPI version higher than 1.2), and/or by the values of acceptURL and rejectURL in the AS configuration file. Bear in mind that these URL does not need to point to images. You can use any object able to be embedded into HTML. Several installations of PAPI have reported the use of JavaScript and/or CSS to accomplish useful and impressive effects.

Some of my users report problems accessing resources through PAPI at certain locations

PAPI is directly based on HTTP cookies, used to hold the authorization tokens required by a PoA for granting access. Different privacy-protection settings in Web browsers, specific programs, or even ``firewalls'' (acting above the network layer) may be blocking these cookies. Always discard this cause before further investigations.

Do I need the AS to make a connection to each PoA its users has access to? What if I need to give access to one hundred PoAs?

This scalability problem was solved in PAPI 1.1. This version introduces the concept of a Groupwide-PoA (GPoA). A GPoA integrates a group of PoAs with similar access policies. Thus the AS only has to know about the GPoA, making life easier for AS administrators and for users.

What about data sent to a GPoA? It is forwarding data about my users to any subordinated PoA that requests so?

From PAPI 1.2.1 a GPoA can control what data about users is sending to any particular child PoA. As far as the GPoA applies a privacy policy compatible with yours, data will not leak to unappropriate locations.

I need to perform attribute-based authorization. What can PAPI do for me?

PAPI assertions are free-format text strings and can carry any user attribute, as long as you can express it inside a text string (think of Base64 if you need to pass binary attributes). At the (G)PoA, assertions are validated against filters, expressed in terms of regular expressions. This filters allow you to express a rich set of attribute-based authorization decissions.

As a simple example, consider a PAPI PoA that is going to receive assertions of the format:

 uid=USERNAME,group=GROUPNAME,o=ORGANIZATION

This couple of filters will allow only users in group coolUsers of organization rightOrg to access the protected resources:

 PAPI_Filter group=coolUsers,o=rightOrg => accept
 PAPI_Filter .* => reject

I have checked the access to a PAPI-protected resource and there is no difference whether accessing it with or without authentication. It is PAPI not protecting my resource?

Apart from other reasons, there is a situation that has been reported several times in which a PAPI PoA may decline to protect resources. There is a set of required configuration parameters that, if not defined, cause PoA unpredictable behavior. These parameters are HKEY_File, LKEY_File, Pubkeys_Path, Service_ID, Hcook_DB, Accept_File, and Reject_File. If a GPoA is defined, Req_DB is also required.

You must provide at least default values, inside a <PAPI_Main> section, for these parameters.

I have upgraded PAPI version to 1.3.0 (or higher) and LDAP authentication is not working. Why?

From version 1.3.0, LDAP-based authentication uses a more powerful procedure to verify user identity and rights. This new procedure require a new set of configuration variables. Refer to the Guide for Beginners, the documentation of the LDAPAuth module, and the Release Notes of your PAPI installation for more details.

BUILDING AND INSTALLING PAPI

Perl complains about unavailable modules when installing PAPI (and they are not included in your list of required modules)

We are sorry of hearing that, but each Perl installation is a world of its own. Nevertheless, drop us a note (papones@rediris.es) about it.

The list of modules in the Guide includes all modules we know are required, using their standard names. Please refer to CPAN, and download and install the required modules from there.

When building the software, a lot of include files are missing

Several users have reported this when trying to build PAPI on Linux systems. The typical error message is like:

 In file included from
 /usr/lib/perl5/.../include/modules/perl/mod_perl.h:165,
  from Conf.xs:1:
 /usr/lib/perl5/.../include/modules/perl/apache_inc.h:113:20:
  httpd.h: No such file or directory

It seems that some Linux distributions do not update properly the Perl directory tree when Apache (including mod_perl) is installed using RPM. To solve this, simply copy all the Apache include files to the appropriate location under the Perl directory tree, like this:

 cp /usr/include/apache/* \
 /usr/lib/perl5/site_perl/5.6.0/i386-linux/auto/Apache/include/modules/perl/

Alternatively, edit the file Conf/Makefile.PL and change it so that the element INC contains /usr/include/apache:

 WriteMakefile(
    'NAME'      => 'PAPI::Conf',
    'VERSION_FROM' => 'Conf.pm',
    'LIBS'      => [''],
    'DEFINE'    => '',
    'INC'       => '-I$(SITEARCHEXP)/auto/Apache/include
    -I$(SITEARCHEXP)/auto/Apache/include/include
    -I$(SITEARCHEXP)/auto/Apache/include/os/unix
    -I$(SITELIBEXP)/auto/Apache/include
    -I$(SITELIBEXP)/auto/Apache/include/include
    -I$(SITELIBEXP)/auto/Apache/include/os/unix
    -I/usr/include/apache',

In certain Linux distributions you may need to directly locate the Apache modules, like:

 WriteMakefile(
    'NAME'      => 'PAPI::Conf',
    'VERSION_FROM' => 'Conf.pm',
    'LIBS'      => [''],
    'DEFINE'    => '',
    'INC'       => '-I/usr/lib/perl5/5.6.1/i386-linux/auto/Apache/include 
    -I/usr/lib/perl5/5.6.1/i386-linux/auto/Apache/include/include 
    -I/usr/libperl5/5.6.1/i386-linux/auto/Apache/include/os/unix
    -I$(SITEARCHEXP)/auto/Apache/include
    -I$(SITEARCHEXP)/auto/Apache/include/include
    -I$(SITEARCHEXP)/auto/Apache/include/os/unix
    -I$(SITELIBEXP)/auto/Apache/include
    -I$(SITELIBEXP)/auto/Apache/include/include
    -I$(SITELIBEXP)/auto/Apache/include/os/unix',

This has been reported to be needed for Mandrake 8.2.

Or like:

 WriteMakefile(
    'NAME'      => 'PAPI::Conf',
    'VERSION_FROM' => 'Conf.pm',
    'LIBS'      => [''],
    'DEFINE'    => '',
    'INC'       => '-I$(SITEARCHEXP)/auto/Apache/include
    -I$(SITEARCHEXP)/auto/Apache/include/include
    -I$(SITEARCHEXP)/auto/Apache/include/os/unix
    -I$(SITELIBEXP)/auto/Apache/include
    -I$(SITELIBEXP)/auto/Apache/include/include
    -I$(SITELIBEXP)/auto/Apache/include/os/unix
    -I/usr/lib/perl5/auto/Apache/include -I/usr/include/apache-1.3',

This has been reported to be needed for Debian 3.0 (Woody). For this distribution, PAPI also requires the installation of the package apache-dev and those related with the Perl SSL interface (libio-socket-ssl-perl and libnet-ssleay-perl).

I cannot find the PAPI/cookie_handler.cgi that is inside the AS configuration file

There is no such PAPI/cookie_handler.cgi. This is the default URI used for requesting PAPI access tokens from a PoA. When the PoA receives a request for this URI it does not perform the usual access token checking, but verifies the parameters it has received along with the request (including the encrypted part that authenticates the AS) and generates the access tokens if appropriate, sending them to the user browser. See the Guide for Beginners for more information.

How can I generate keys for the AS and the PoA?

The PAPI distribution include some sample keys, but we do not recommend that you use them (even for testing).

PAPI uses two kind of keys. The AS uses a public/private key pair, that you can generate using openssl and install in the appropriate locations (as described in the Guide for Beginners). The PoA uses a couple of symmetric keys for encrypting the access tokens. The keys are read by the PoA as strings of up to 32 hexadecimal characters. A suggestion for automating the process of generating these keys is to employ a GNU program called md5sum on a couple of temporary files in your system, redirecting the output to the files that store the keys. The output of the command is a string of 32 hexadecimal characters, so it perfectly fits to the format of the PoA key files.

How can I generate the Berkeley-format database for the PoA Hcook_DB?

You do not need to generate this file. The PoA software will use it as needed, provided you set the appropriate permissions for it. This means that you should grant write permission to the UID the PoA runs with in the corresponding directory.