Contents


Use PLAM to speed distributed transactions

How the Pluggable Authorization Module architecture reduces security overhead

Comments

Legacy products such as the IBM Distributed Computing Environment (DCE) provide secure distributed transactions, but they also come bundled with other heavyweight services that can consume loads of system resources and be difficult to administer. With that in mind, administrators often want to separate DCE services (barring RPC) from file services such as DFS. Because of this, some third-party applications have been supplanted and several new components are being developed to integrate the new services.

Pluggable Authorization Module (PLAM) is a newly developed authorization module responsible for the efficient caching and flow of authorization information between the various entities involved in a distributed transaction. It is also designed to make that information highly available to the service components.

Evolution of PLAM

The idea behind PLAM cropped up as part of a DCE-replacement strategy. The IBM Pittsburgh Lab (in collaboration with IBM India Software Lab, Pune) started two separate projects:

  • SARPC (StandAlone RPC) is the mechanism solely responsible for segregating the DCE Security and Cell Directory services from the DCE RPC facility. SARPC rides on the same code base as DCE RPC but provides security through the Kerberos v5 protocol; it provides the Resource Location Service through ANS (this is a file-/DNS-based resource location service developed as part of the ADFS project). SARPC 1.0 was released in January 2005.
  • ADFS (Advanced Distributed File System) is a project designed to help disengage DCE Security and Cell Directory Services from DFS. As a replacement, ADFS originally employed the Kerberos v5 protocol (for authentication), a home-grown GroupServer (for authorization), and a file-/DNS-based resource location service called ANS. ADFS now uses SARPC for communication instead of the DCE RPC. The project work mainly involved integrating the new security infrastructure over the same distributed file service architecture as in DFS.

The PLAM framework was derived from the ADFS project. The ADFS team in India provided a proof of concept to enhance the performance of SARPC over the wire; they also supplied a dummy implementation of PLAM by integrating it with the SARPC code as it existed at the time. Later, the SARPC team implemented and integrated the actual PLAM source code into SARPC. It is now available in SARPC 1.0.

The integration of PLAM into SARPC requires ADFS GroupServer since the Network Group Membership information of users is provided by the GroupServer. PLAM/SARPC is now supported on AIX®, Solaris, and Windows® and is intended to be supported on Linux™ in the next scheduled release of SARPC.

Let's review the basics of authorization in a distributed environment and some PLAM architecture terminology.

Authorization basics

Authorization is the mechanism by which users or applications in a distributed environment establish their eligibility to use a particular resource (it could be either a service or filesystem data). Such a system operates on an authentication substrate in which users or client applications are required to validate their identity to a trusted authentication service component and subsequently acquire service tickets to gain authenticated access to resource managers.

In simpler terms, to gain access to any resource in a shared environment, the requesting entity must answer two questions for the target resource manager:

  • Are you who you say you are (are you authenticated)?
  • What operations are you allowed on the shared resources (are you authorized to access the resource)?

Authentication is provided in the form of a service ticket, issued by a trusted authentication service in the domain and encrypted with the target resource manager's secret key. Such a ticket is provided to any entity that can prove its identity to the authentication service by way of login to the domain through the secret password registered with the authentication service.

Authorization is provided in the form of group membership information. This information is stored by another trusted server in the domain that issues tamper-proof membership information to the requesting entity.

Ideally authorization information should be provided in the form of a list of network groups to which the requesting entity belongs; otherwise, it is difficult to maintain the access-control lists (ACLs) on each shared resource based on names of hundreds of entities. To make ACL storage manageable, entities are grouped, and these groups are then provided permissions on different shared resources.

The entities involved in authorization

In a fundamental distributed environment, access to a resource (whether a file, printer, database, etc.) is managed by resource managers (application servers). When a client attempts to perform an operation on the resource (whether an application service or data maintained by it), the resource manager examines the client's identity (presented as privilege attributes or PAs) and compares it with control attributes (traditionally an ACL) associated with the resource. It then accepts or denies the request.

The PAs are issued by a trusted system component to the clients in the form of a tamper-proof privilege attribute certificate (PAC). PACs are embedded securely into authentication service tickets (produced and issued by authentication service providers, also part of the trusted computing base of the distributed system), and they flow together on the wire whenever a client is required to gain access to a particular object.

Figure 1 illustrates the various entities involved in distributed authorization.

Figure 1. Entities in distributed authorization
Different entities in distributed authorization
Different entities in distributed authorization

The original DCE pull model

DCE provides a secure communication channel between a client and a server through an authenticated RPC mechanism.

The responsibility to initiate an authenticated RPC to the target server (through an appropriate DCE API call) lies with the client applications. The server's RPC runtime then assumes the responsibility of pulling in the requesting user's credential (such as Kerberos v5 Service Ticket, PAC) from the client through a WHO-ARE-YOU callback mechanism (also known as the WAY Challenge); then the server subsequently authorizes the request.

The server RPC runtime also does some minimal session-based caching of the user's credential information so that the WAY Challenge need not be repeated for every other RPCs from the same client session. Figure 2 illustrates the DCE security system.

Figure 2. The DCE security system architecture
The DCE security system architecture
The DCE security system architecture

Why build a new framework?

By pulling out DCE security services from distributed applications, the new replaced applications and services must fulfill a wide range of security requirements of the distributed environment. This includes the following:

  • Providing authentication facilities through Kerberos v5 Protocol
  • Offering a secure communication channel through remote procedure calls
  • Storing the entities' authorization information on trusted servers

But the basic problem of DCE's redundant flow of authorization information on the wire remains: Duplicate copies of the same user's PACs are being sent to resource managers on multiple logins by the user. For example, if Tom is accessing server T by logging in from machines A, B, and C or if he logs in three times from machine A, and the group-membership information between these logins remain unchanged, three copies of the same PAC would be sent to server T during the initial access request from these sessions. Figure 3 illustrates this.

Figure 3. Redundant PAC flow in DCE authorization
Redundant PAC flow in DCE authorization
Redundant PAC flow in DCE authorization

Figure 3 shows that when the user logs into the DCE cell from three different terminals:

  • The DCE Registry Server provides the user with his network identity in the form of a PAC.
  • From Session 1, the user sends a resource request to the DCE application server. The server pulls in the user's completed PAC structure for authorization.
  • From Session 2, the user again sends a resource request to the DCE app server, which again pulls in the user's completed PAC structure. Since the user network group membership information didn't change between the logins, the server pulls in the same PAC structure as in Session 1.
  • The server pulls in group information for the resource request in Session 3. Consequently, redundant information flows through the wire for the same user accessing the same server multiple times with similar credentials.

When many users do what Tom did, the following happens:

  • Request turnaround time slows down due to the huge information processing overhead. If Tom belongs to a large number of network groups, the PAC structure would grow simultaneously, and decrypting the entire structure would take much longer on the server.
  • The network clogs with redundant PACs.

Imagine 2,000 users logging into the system during the early working hours of the day, each having multiple sessions to the same server!

So how can we solve this overhead nightmare of redundant PACs?

The plug-n-play approach

The solution proposed in this article boils down to plugging in an authorization module in the client's and server's runtimes that handles the authorization requirement of the applications without their intervention. Also, to minimize the flow of giant PAC structures on the wire, a new data structure needs to be developed, one that could embed only the information needed to securely and uniquely identify the group membership information of the requesting entity.

A quick way to implement this solution is to let a PKI-based certificating authority issue a tamper-proof PAC identifier to the requesting clients. The identifiers (instead of the larger PAC structures) would then be produced by the client for the target application servers while requesting a resource access.

The identifiers are small compared to the PACs and could differentiate similar sessions (a user's different login sessions with identical group-membership information) by way of attaching an expiration time. The identifiers have the requesting entity's name inscribed so that any illegal use could be immediately identified by the target resource managers. Figure 4 shows how PLAM eliminates redundancy.

Figure 4. No redundancy on the wire with PLAM
No redundancy on the wire with PLAM
No redundancy on the wire with PLAM

In Figure 4, again the user logs in through three different terminals:

  • The ADFS GroupServer provides the user with his network identity in the form of a PAC and a PAC identifier.
  • In Session 1, the user sends a resource request to the resource manager. The server asks for the user's PAC ID. Since the PAC is not already cached on the server, as verified against the incoming PAC ID, the server pulls in the user's PAC (containing group-membership information) for authorization.
  • In Sessions 2 and 3, a resource request by the user should then require only that the PAC ID is to be sent to the server since the corresponding version (5.0) of the PAC is already cached by the server, bound by timeout.

Since PAC IDs are small compared to PACs, congestion on the wire is reduced and Tom and his 2,000 friends (with their obsessive need to log in from multiple machines) do not overwhelm the system; this approach definitely aids in removing redundancy as seen in the DCE authorization framework.

Now let's look at some of the components of this new framework.

Inside PLAM

Let's review these elements of the new framework:

  • The design principles
  • The pros of the model
  • The PAC identifier
  • How the components work
  • Caching concerns
  • Network congestion

The design principles

The proposed module is designed with these principles:

  • Any remote procedure call acts on behalf of user's requests.
  • It is the responsibility of the underlying layers to transparently associate every request with the user's authorization information.

It is also desirable to cache copies of the dynamic and domain-specific user's attribute lists at or near the target resource so it is easier to maintain high throughput. This information can be pulled in from clients or looked up on the cache whenever they are required for authoritative decision making.

Also in this model, authorization data has been separated from the authentication information so authorization data should not be embedded in authentication tickets. A separate caching and flowing mechanism should be provided for the application services.

Merits of the model

Benefits of this model include the following:

  • The framework is quite generic, so any third-party applications that communicate through RPC or sockets can make use of this security layer to transport their home-grown authorization data through callbacks. (Applications may chose to use different sets of parameters to uniquely identify a user's PAC ID.)
  • The framework provides a consistent method of transferring authorization data from both userspace applications and kernel modules. Consequently, distributed client/server applications such as NFS, DFS™, AFS®, TXSeries®, Encina®, MQSeries®, and the like can make use of this framework with little porting effort.
  • The model minimizes the risk of tampering with the authorization data so that servers do not spend more time in verifying the data. The authorization data is issued by a server that belongs to the trusted computing base of the system and is considered secure in its administrative domain.
  • The actual membership information flowing through the wire has been minimized to a large extent because of the use of PAC identifiers. This reduces the overhead that clogs the network with redundant packets required to pull in the user's PAC information.

The PAC identifier

PLAM requires an abridged version of the original PAC structure called the Privilege Attribute Certificate Identifier. This identifier allows effective caching of the authorization information on the PLAM's server runtime for high availability; it also reduces the network bandwidth consumption for floating the authorization information on the wire. The structure is as follows:

PAC-ID: {User, Realm, Version, Expiry, Signature}

Realm refers to the local domain of the user where the account was originally created. This information is necessary while accessing resources belonging to a foreign domain, so that the namespace of the user remains unique.

Version refers to a version of the user's group list. PAC versions should be maintained by the certificate-issuing authority; the version should change when the user's group membership information changes. So at any time, the same user logged in from different machines might get the PAC with the same version number but with different expiration times.

Expiry refers to the time when the PAC ID becomes unusable.

Signature refers to the data that is the checksum of User, Realm, Version, Expiry, encrypted with the issuing authority's private key in PKI framework. The private key is contained securely by the certification-issuing authority, and the corresponding public key is disseminated generously to the application servers so that the altered PAC identifiers can be rejected, and only authentic users are granted access.

Overview of the framework

The new authorization model in PLAM can be integrated into the communication layer (RPC/Sockets) to securely transmit authorization information to the target resource manager. It sits between the application and the network layers and facilitates access to its cached repository on the resource provider through a set of APIs.

The in-memory cache repository in PLAM is maintained on the application server's runtime and minimizes the number of times the requesting user's group-membership information needs to be flowed through the wire for authorization decisions. The repository grows when new users start accessing the PLAM-ified application servers; it is limited by the inactivity period and a threshold.

Secure communication sessions between a client and server start by pulling in the requestor's (user's and machine's) PAC identifier from the initiating host machine. This callback, apart from retrieving the authentication service ticket from the user's credential cache, also interacts with PLAM in the client's runtime to fetch the PAC identifier.

PAC ID signatures are verified by the resource managers; PAC versions are identified by opening up the PAC ID. If the group list corresponding to the user's version of PAC is found in the in-memory cache of PLAM, the user is granted access to the requested object based on permissions on the ACL.

A cache "miss" results in a callback to the client to pull in the user's group list (in the form of a PAC). The resulting information is then cached by the resource manager and is used during subsequent requests from the same user.

Figure 5 illustrated the PLAM/SARPC security architecture.

Figure 5. PLAM/SARPC security architecture
PLAM/SARPC security architecture
PLAM/SARPC security architecture

Notice in Figure 5 that the SARPC Runtime is a direct derivative of the DCE-RPC module, which was developed as a result of a DCE replacement strategy. Group Server is the PKI-based certification authority that replaced DCE Registry Service.

Efficient caching

During DCE days, redundant authorization information used to be cached on the server runtime even though the PAC containing similar group membership information was used across different sessions and machines for a particular user. This redundancy was induced because the PAC was embedded in service tickets and flowed as a single security entity from the client to the server. Thus, every cache miss on the server triggered a callback RPC that had to fetch the user's credential (STKT + PAC) in its entirety.

PLAM uses a different caching model that is more efficient because of:

  • The separation of Kerberos-provided service tickets from the certified privilege attribute
  • The introduction of a PAC identifier
  • The PAC versioning scheme used by GroupServer

PLAM caches single read-only copies of different versions of user's PAC in its repository. If the same version of user's attribute list is used from different communication sessions (and across machine boundaries), the target resource manager caches only one copy of that version for its reference. This reduces a lot of caching overhead and memory overuse in PLAM as compared to DCE.

Let's assume that Bob has logged in from 10 different machines or has 10 different logins from a single machine and has established an equal number of sessions with a target Resource Manager T. If Bob has received the version 8.000 of his PAC in all these sessions (because the network groups to which he belongs didn't change in GroupServer during the course of his login to these machines), then the PLAM runtime on the target server T caches version 8.000 of Bob's PAC only once during the first session; the remaining 9 sessions are not required to send their PAC to T.

Reducing network congestion

With this new architecture, the first secure authorization entity that flows in from a client to a server is a PAC ID. If the version of PAC mentioned by the identifier has already been cached by the PLAM-ed server, the session is set up and no PACs are required to be pulled in from the initiating host. This reduces a lot of network overhead since the size of a PAC ID is significantly smaller than a PAC (which embeds user's group membership information in it and is likely to grow bigger as membership spreads to a more groups in the network).

A particular version of PAC now flows to a target resource manager only once; other sessions of the same user establish their authority by sending in the PAC ID.

Conclusion

When you port generic distributed applications, remember:

  • The certification-issuing authority should maintain a version number per user in its repository. The version should increment every time the user is added to or deleted from a network group. The version could then be used to construct the authorization identifier. It is not necessary that the issuing authority be based on public key infrastructure. Shared secret key infrastructures could also be used to provide PAC identifiers.
  • Caching on the client and server side could be on disk or memory, based on the kind of loads generated in the system.

As a continuing effort to improve the existing model, PLAM also includes IP address-based ACLs in the architecture by extending the PAC identifier structure. The support has been provided by the ADFS GroupServer and the logic has been implemented in SARPC.


Downloadable resources


Related topics


Comments

Sign in or register to add and subscribe to comments.

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Linux
ArticleID=84123
ArticleTitle=Use PLAM to speed distributed transactions
publish-date=05182005