| | 31 | |
| | 32 | '''Session Summary''': |
| | 33 | |
| | 34 | At the session, Aaron and Tom demonstrated the GENI Portal and GENI Clearinghouse. The portal is a web tool for calling the new GENI |
| | 35 | Clearinghouse's open APIs, but which is also a recognized !InCommon service provider. The portal is intended to be the first tool that |
| | 36 | GENI experimenters use, and so is being built to make it easy to get started with GENI. The Clearinghouse is the implementation of the GENI |
| | 37 | Software Architecture, built to enable trusted interactions in the GENI Federation. These systems are in development, and will be available for early adopters around GEC15. |
| | 38 | |
| | 39 | There were a number of good questions raised during the session. |
| | 40 | |
| | 41 | These systems do not currently use ABAC, but all authorization decisions are made based on assertions that in future could be |
| | 42 | represented using ABAC. The GENI authorization framework is and must be flexible. The portal is mostly just a tool, and others could write |
| | 43 | their own tools that talk to the Clearinghouse APIs (as well as the GENI Aggregate Manager API) - the only special piece of the portal is |
| | 44 | that it is a recognized !InCommon service provider, enabling single sign on authentication. |
| | 45 | |
| | 46 | For aggregates to work with the clearinghouse, they must simply trust another slice authority. GENI racks will trust the Clearinghouse. Other aggregates will likely also trust the Clearinghouse, but may also continue to trust other slice authorities. |
| | 47 | |
| | 48 | The services of the clearinghouse are built to be distributed, supporting load balancing, etc. But we have not done this yet. |
| | 49 | |
| | 50 | The portal caches experimenter authorization information for performance, using a short and tunable cache timeout. |
| | 51 | |
| | 52 | Ken Klingenstein noted that we should make the portal and clearinghouse support collaboration tools, particularly based on groups. |
