Point of Access for Providers of Information
Encyclopedia
PAPI is a system for providing access control to restricted information resources across the Internet. It intends to keep authentication
as an issue local to the organization the user belongs to, while leaving the information providers full control over the resources they offer. The authentication
mechanisms are designed to be as flexible as possible, allowing each organization to use its own authentication
schema, keeping user privacy, and offering information providers data enough for statistics. Moreover, access control mechanisms are transparent to the user and compatible with the most commonly employed Web browsers and any operating system.
The system consists of two independent elements: the authentication server (AS) and the point of access (PoA). This structure makes the final system much more flexible and able to be integrated to different environments. There is no need of a one-to-one mapping between ASes and PoAs: a given PoA may manage to deal with requests from any number of ASes and direct them to any number of web servers.
Other important property of this system is that it is completely compatible with any other access control system in use, since it does not impose any constraints on additional procedures used for these purposes. In other words, PAPI access control is completely orthogonal to procedures such as password protection, IP filters, TLS-based access control, etc.
The central motto for PAPI is Authentication is a local matter, and authorization too.
Authentication occurs at the user's organization, possibly accessing data that must not be disclosed in any case. Once authenticated, the user is automatically pointed to the entry point of the PoA. It is important to remark that the AS is not sending any user-provided data to the PoA. It prepares an assertion (as required by the PoA) about the user and signs it using its private key. The only constraint that any PoA imposes on an AS assertion about a user is that the identifier must be unique at least during the lifetime of the tokens the PoA is going to provide. Of course, information should be also enough to pass through the rules the PoA enforces, but the AS is never required to disclose any private information.
The PoA receives this chunk of information, signed by the AS, and decides whether to grant access to the user or not. It is important to note that when we refer to a PoA trusting an AS, we are not talking about a PoA permitting any access request coming from that AS, but about the PoA trusting the assertions the AS makes. That means that, if a PoA trusts an AS, the (digitally signed) assertion of ``This is user X of group Y‘‘ made by the AS is going to be trusted by the PoA. And the PoA decides, according to the assertion and its policy, to grant access or not. Authorization is, again, a local matter to the organization operating the PoA.
Authentication
Authentication is the act of confirming the truth of an attribute of a datum or entity...
as an issue local to the organization the user belongs to, while leaving the information providers full control over the resources they offer. The authentication
Authentication
Authentication is the act of confirming the truth of an attribute of a datum or entity...
mechanisms are designed to be as flexible as possible, allowing each organization to use its own authentication
Authentication
Authentication is the act of confirming the truth of an attribute of a datum or entity...
schema, keeping user privacy, and offering information providers data enough for statistics. Moreover, access control mechanisms are transparent to the user and compatible with the most commonly employed Web browsers and any operating system.
The system consists of two independent elements: the authentication server (AS) and the point of access (PoA). This structure makes the final system much more flexible and able to be integrated to different environments. There is no need of a one-to-one mapping between ASes and PoAs: a given PoA may manage to deal with requests from any number of ASes and direct them to any number of web servers.
Authentication Server (AS)
The purpose of the AS is to provide users with a single authentication point and make available to them (in a completely transparent manner) all the temporary keys that will let them access the services they are authorized to.Point of Access (PoA)
The PoA manages actual access control to a set of web locations for a given organization. The information provider (or the owner of the web servers) have the responsibility of managing this point of access. A PAPI PoA can be adapted to any web server, whatever its implementation is. Moreover, a given web server can have more than one PoA, and a PoA can control more than one web server. PoAs can be hierarchically combined into groups controlled by a group-wide PoA (a GPoA), where initial access attempts are to be validated. This way, only the temporary keys for the GPoAs at the top of the hierarchy must be initially loaded by the user's browser. A PoA can also be configured to directly query authentication servers for information about users, so no initial loading of temporary keys is needed. This ability can be, of course, integrated within PoA hierarchies as well.Other important property of this system is that it is completely compatible with any other access control system in use, since it does not impose any constraints on additional procedures used for these purposes. In other words, PAPI access control is completely orthogonal to procedures such as password protection, IP filters, TLS-based access control, etc.
The central motto for PAPI is Authentication is a local matter, and authorization too.
Authentication occurs at the user's organization, possibly accessing data that must not be disclosed in any case. Once authenticated, the user is automatically pointed to the entry point of the PoA. It is important to remark that the AS is not sending any user-provided data to the PoA. It prepares an assertion (as required by the PoA) about the user and signs it using its private key. The only constraint that any PoA imposes on an AS assertion about a user is that the identifier must be unique at least during the lifetime of the tokens the PoA is going to provide. Of course, information should be also enough to pass through the rules the PoA enforces, but the AS is never required to disclose any private information.
The PoA receives this chunk of information, signed by the AS, and decides whether to grant access to the user or not. It is important to note that when we refer to a PoA trusting an AS, we are not talking about a PoA permitting any access request coming from that AS, but about the PoA trusting the assertions the AS makes. That means that, if a PoA trusts an AS, the (digitally signed) assertion of ``This is user X of group Y‘‘ made by the AS is going to be trusted by the PoA. And the PoA decides, according to the assertion and its policy, to grant access or not. Authorization is, again, a local matter to the organization operating the PoA.