> It seems to me now that your system architecture is very similar to
> Shibboleth. What can you comment on this? Do I miss any significant
> point? 

No, you don't miss anything on this. The ideas behind Shibboleth and PAPI
are quite similar. The only significant differences I can point are:

1) Shibboleth has commited from the beginning to SAML, while PAPI is
   currently using proprietary formats.

2) PAPI requires a pre-load of authorization tokens from the (G)PoAs while
   Shibboleth permits direct connections to the protected sites. This
   does not mean that a PAPI AS needs to know about *all* the sites a
   user has access to, but at least the "trust roots" (the GPoAs) for that
   sites. Furthermore, the "blind" approach of Shibboleth assumes the
   availability of the WAYF service, that may imply additional points of
   failure.

3) As far as I know, Shibboleth does not define a complete trust management
   model, and sometimes assumes the use of TLS and/or the existence of
   third parties acting as central authorities for the "clubs". PAPI bases
   trust management in the exchange of public keys between an AS and the
   GPoAs it provides access to.

4) The Shibboleth model is more dynamic that the PAPI current model, since
   each individual initial authorization is driven by on-line queries on
   user's attributes, through the SHAR-AA interaction.

Nevertheless, there is a collaboration framework between Shibboleth and PAPI.
We are working in making PAPI more dynamic and standard based, by means of
allowing a PoA to dynamically ask for user attributes and to do so (and
the encoding of assertions about users) using SAML. On the other side,
the Shibboleth team is interested in the use of PAPI tokens for implementing
their Resource Managers. I think that PAPI and Shibboleth will become
fully compatible in a short time.

> Does your AS store the authorisation tokens for each request as a
> signed entity already or you sign them on the fly? If the former, do
> you use X.509 Attribute Certificates for that or you have your own
> proprietary format? 

No. The authorization tokens (they are two: Hcook and Lcook) are built
by the PoA on-the-fly, and re-validated as needed. The same applies for
the signed assertion about the user that is sent to the (G)PoAs in order
to generate the first version of the authorization tokens.
Both formats (for tokens and assertion) are currently proprietary. We plan
to move assertions to SAML, but to keep the proprietary format for the
cookies, in order to keep them compact and concise.

> It seems that intercepting the traffic to and from the PoA would
> enable me doing the same as the real user, if I issue the second
> request before the real user does. Is this a possibility or I missed
> certain point? Of course, if the traffic is not within a TLS or SSL
> session. 

You are right in that this is a possibility. Some colleagues have pointed
a similar course for a DoS attack on PAPI protected systems. We are
going to include the address of the authorized system inside the
tokens, so you don't only have to intercept traffic but also to spoof
the client address. Although this will not fully avoid this kind of attack,
it will make the attack less likely and allow the user todetect it much
more easily.
Of course, you can decide the use of TLS to avoid this kind of attack. PAPI
is designed to be completely compatible with any other mean used for
securing the communication.

And now, a question for you. I knew about the PERMIS framework from a
presentation of David Chadwyck some time ago and it seemed to me quite
powerful and elegant. Do you envisage the possibility of making PERMIS
and PAPI work together in some way?

Best regards,


-- 
"Esta vez no fallaremos, Doctor Infierno"

Diego R. Lopez
[log in para visualizar]

RedIRIS
The Spanish NREN
Tel:    +34 955 056 621
Mobile: +34 669 898 094
-----------------------------------------