| 67 | | |
| 68 | | |
| 69 | | = Overview = |
| | 67 | == Integrating Researcher Desktops == |
| | 68 | |
| | 69 | Often a researcher will want to directly interconnect their desktop or another computer into an experimental environment. This can enable an experimenter to debug effectively by importing their tools and environment easily, or to demonstrate the experiment to others by incorporating a display engine. |
| | 70 | |
| | 71 | This is a special case of combining specialized resources, but the lightweight system DETER uses to facilitate this is of particular interest. |
| | 72 | |
| | 73 | = The Software Architecture = |
| | 74 | |
| | 75 | The overall architecture of the DFA is shown below. Users specify their experiment environments to a system that coordinates access to multiple testbeds/resource providers. Each testbed may use different interfaces and have different policies for access. |
| | 76 | |
| | 77 | The plug-in system simplifies integration of different testbed interfaces to the DFA. Each plug-in translates from the local testbed's interface into a standard interface. |
| | 78 | |
| | 79 | The Attribute-based Access Control (ABAC) authorization logic and some associated DFA translation technology allows different policies to mesh. ABAC is a powerful, well-specified authentication logic that can encode a variety of policies. It allows sophisticated delegation and other access control rules to be expressed interoperably. It is in use both in the DFA and in the [http://geni.net GENI testbed]. |
| | 80 | |
| | 81 | In principle, testbeds can use the full power of ABAC to describe their policies, but in practice DFA tools allow simple configuration of access control for most testbeds. |
