Dear Diego,


I am very grateful for your prompt reply. It really advanced me in
understanding your technology.


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?

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?


"Diego R. Lopez" wrote:

> Dear Sassa,
>
> > 1. How do you secure the communication to the Authentication Server
>
> The Authentication Server is currently a CGI (although it could be
> used as a module, or a servlet, etc.) and, as such, can be accessed
> through TLS. Furthermore, even in the case you don't use a direct
> TLS connection to it, the AS provides for what we call "split mode",
> in which the URL for the CGI processing user data is accessed through
> TLS, so authentication data (typically, passwords) are hidden from
> eavesdropping. We call it "split mode" because the TLS-based URL must
> redirect the request to a plain (non-TLS) URL once the authentication
> data have been verified, so the cookies coming from the (G)PoAs may
> be loaded.
>
> > 2. How do you secure the communication to the Point of Access.
>
> The communication from the AS to the PoA is secured by the fact
> that the assertions sent about the user (by redirection inside the
> HTML page sent from the AS to the user when authentication succeeds)
> are signed by the AS.
> Again, communication from the user browser to the PoA in normal use
> may be based in TLS if you require so.

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.


> > 3. How do you enforce that the links are requested through your PoA
> > only? What stops the user from accessing the desired web-site
> > directly?
>
> The PoA is in itself a access control module installed inside Apache.
> If you go to a PAPI-protected location inside a Web server, it will
> call the PAPI PoA in order to evaluate your access rights. If you are
> not able to present valid PAPI tokens (the pair of cookies), access
> will be denied.

Aha, I see. So the target system is running the PAPI PoA itself. OK.


> I hope this helps in your understanding of PAPI. Needless to say,
> we will be very happy in answering whatever further question you have.
>
> Best regards,
> --
> "Esta vez no fallaremos, Doctor Infierno"
>
> Diego R. Lopez
> [log in para visualizar]

Thanks


Sassa