DCE Spheres: How to administer large cells.

For the Energy Sciences Network, Distributed Computing Coordinating Committee

V 1.0, May 17, 1996

ABSTRACT

An administration unit inside of DCE is the cell. Unfortunately, the cell is not structured efficiently to support distributed administration. One solution is to carve the cell into administration units called spheres. A sphere allows for distributed administration, cost effective hardware deployment, scaleablility, and containment of security breaches. Spheres are part of the DCE architecture for the Stanford cell. A sphere architecture is layered on top of the standard DCE. This proposal enhances the university sphere environment to the level of quality required for the laboratories.

CONTACT INFORMATION

	Stanford	Ron Burback 	burback@stanford.edu
	Stanford Jie Wang	jiewang@leland.stanford.edu

	PNNL 		Tom Harper	ta_harper@pnl.gov
	PNNL		Troy Thompson
	SLAC 		Les Cottrell	cottrell@slac.stanford.edu
	SLAC		Andy Hanushevsky	abh@SLAC.Stanford.EDU
	Transarc 	Brian Herhusky	herhusky@leland.stanford.edu

DESCRIPTION OF PROPOSED WORK

PROBLEM STATEMENT

The Open Software Foundation (OSF) Distributed Computing Environment (DCE) defines the concept of a cell. The cell is the basic unit of system management consisting of the hardware to materialize the services of the cell and the definition of the cell administration group. This architecture does not scale well for large cells. In a large cell where the total number of principals, hosts, and applications may total over 10,000, you will need many cell administrators. Some of these cell administrators will manage the hardware but a much large number will manage day-to-day activities of changing passwords, creating accounts, configuring clients, and adding new applications. Current problems with large cells include:

• The DCEcp generates one list for every query. Thus, a cell with a large number of principals generates a very long, unmanageable list. The DCEcp, at its current state, was designed to handle tens of items in the list structures.
• The cell administrators can modify passwords for every one in the cell. There is no method, in standard DCEcp, to limit the number of individuals under the control of the cell administrators. The default security is that a principal has control over every thing or has control over nothing. There is no middle ground.
• If a user wishes to add another machine to the cell, it has to be done by a cell administrator. There is no local authority, using standard DCEcp, to delegate this task.
• Multiple cells with trust relationships don't really solve these problems. For each cell you need cell hardware. Thus if you split the cell into many cells you now need many more cell administrators to manage a larger number of hardware servers. Even if one administrator deals with many cells, he now has much more work to do keeping many more machines active. What is worse is that the trust relationship is administered by hand. Security in the collection of trusted cells is now governed by the weakest link.
• Hierarchical cells don't help much either. You still need cell hardware for each cell in the hierarchy and the DCE software to materialize hierarchical cells does not currently work and may not be fixed for several years.
• If a security breach occurs in a normally configured DCE cell, the scope of failure is the entire cell or trusted cell group. If the password is compromised, then there is no mechanism in place for stopping the individual from having access to the entire cell.
• An individual may have many valid roles. The roles may change frequently. Switching identities and roles is not well support under standard DCE. The use of an principal alias is cumbersome.

One solution is to divide the name space of a cell into many smaller name spaces.

There are six different name spaces in a cell. They are the application, the host, the principal, the group, the organization, and the file system name spaces. A sphere is a sub portion of each of these name spaces. A new administration group, called the sphere administrations, manage each one of these spaces. A sphere administrator can only alter things in his sphere. This is accomplished by ACLs. Now if a user needs a routine administration task to be accomplished he contacts his local sphere administrator. The sphere administrator does not run the hardware of the cell. This task is still accomplished by the cell administrator. The cell administrator is not overwhelmed by thousands of user request. An individual principal may belong to many spheres without having to change the DCE identity. The cell administrator acts as backup to the sphere administrators.

Spheres solve the following problems.

• A sphere query to the DCEcp now only has to return a much smaller number of users that are in one particular sphere. The list limitation of DCEcp is mitigated.
• A sphere administrator can only modify user passwords in one particular sphere. You don't have to grant cell privileges to all sphere administrators. The management of the cell is now distributed among many spheres administrators. The cell growth can now be distributed over many spheres in a scaleable fashion.
• A user now contacts the local sphere administrator to add a new client to the cell. The client machine enters the local sphere. If the user wants the client machine to enter other spheres, or the entire cell, he must contract other sphere administrators or the cell administrator.
• There is only one cell though there are many spheres. Trust relationships are not needed. You need to only manage one collection of cell hardware which lends itself to cost effective hardware deployment.
• There is only one cell thus hierarchical cells are not needed.
• By default, a user is in only one sphere. If his password is compromised, then only the sphere is compromised. This gives a natural containment of the breach.

PROPOSED WORK

Stanford University will provide for the laboratories a collection of TCL scripts written on top of DCEcp that create the concept of the spheres and cook book their management. A document describing the process will also be provided. Early testing by SLAC, as a sphere to the Stanford cell, will be encouraged. PNNL will influence the design of spheres to include their needs.

LEVERAGED RESOURCES

This works leverages the existing work already underway at Stanford University.

BUDGET

The following are provided as budgetary estimates.

$250,000 -Stanford, travel and development. $25,000 -PNNL for travel and sphere testing. $25,000 -SLAC for sphere testing.

Total $300,000.

Legal Disclaimer

The material contained herein is submitted for informational purposes and is not binding. Binding commitments can only be made by the submission of a formal contract which sets forth a specific Statement of Work, estimated cost and contract documents, and which is signed by a Contracting Officer.