AMAAIS (Phase 4)
|Long Title:||Accounting and Monitoring of AAI Services (Phase 4)|
SWITCH - Teleinformatikdienste für Lehre und Forschung
|Project Leader:||M. Waldburger|
|Final AMAAIS solution||Maven repository (public with username/password combination of amaais/amaais; access details made available on project website). The sofware is licensed under Apache version 2.0 (open source).|
|AMAAIS Deliverable D1||Scenarios, Requirements, and High-Level Architecture|
|AMAAIS Deliverable D2||Architecture Design Implementation|
|AMAAIS Deliverable D3||Workflow, Accounting Model, and API Model, and API|
|AMAAIS Deliverable D4||Final solution documentation and trial results|
|AMAAIS prototype (from phase 2)||Code base available in SVN repository at (public with username/password combination of amaais/amaais; access details made available on project website)|
|Extending Monitoring and Accounting Infrastructure Towards Constrained Devices in Internet-of-Things Applications||Technical report: O. Mazhelis, M. Waldburger, G. Machado, B. Stiller, P. Tyrväinen|
|Retrieving Monitoring and Accounting Information From Constrained Devices in Internet-of-Things Applications||Conference paper: O. Mazhelis, M. Waldburger, G. Machado, B. Stiller, P. Tyrväinen. 7th International Conference on Autonomous Infrastructure, Management and Security (AIMS 2013), pages 137-148, June
Several other publications have been created.
The AMAAIS project provides a solution that extends Shibboleth-based identity federations, such as the SWITCHaai service,
with accounting and monitoring functionality.
In a federation, a member institution may offer resources or services to users from other federation members. For instance, a university may offer a printing service not only to its home users but also to users of other universities. While existing Shibboleth solutions enable a correct authentication and authorization of home and roaming users in a federation, the AMAAIS accounting and monitoring extensions provide additional information to service providers and identity providers in the federation: The AMAAIS solution allows the collection, aggregation, processing, and persistent storage of all events of interest that document when, how, and by whom a resource in the federation was used. Resource usage data as accounted by AMAAIS, thus, forms the essential basis for producing statistical reports, for monitoring federation resources in a timely manner, and for longer-term strategic planning in a federation.
Members of the Swiss academic community profit from a well-tested, documented, Shibboleth-compatible, trialed, and proven to work accounting and monitoring solution that is available today as free software for download, configuration, and deployment in a Shibboleth-based environment.
During the AMAAIS project, the solution has been used and trialed for two service-dependent accounting use cases at the ETHZ, namely its SMS and printing services, and it was used and trialed for an IdP server run by SWITCH.
The AMAAIS solution bases on an implementation framework that was developed by the (former) main developer of the Shibboleth IdP for the project. This implementation framework reflects the coding and quality standards of Shibboleth, which allows the AMAAIS solution to be integrated into the Shibboleth project and its solutions. Towards this goal, SWITCH plans to do a pilot with some IdPs from the federation and is about to perform a code review with a Shibboleth developer.
The primary goal of extending the AMAAIS project is long-term project sustainability.
With the availability of a SWITCH-funded, Shibboleth-driven implementation framework, the opportunity for an integration of AMAAIS results into the Shibboleth project becomes feasible. The new implementation framework - which became available in mid February 2012, hence, when the implementation phase of the ongoing project Phase 3 had just started - is fully supported by all project partners due to its strong focus a fully functional, well tested and trialed, and Shibboleth-compatible solution.
The implementation according to the implementation framework requires considerable effort. The new implementation framework implies changes in the entire system design, the implementation of all components, their testing, and it has an impact on all trials. Especially, the newly planned for use of the Spring framework (for configuration purposes) and the use of the IdP3 API will result in a larger and additional effort (including an initial study period) before starting the new implementation.
The implementation in phase 4 is largely extended to accommodate all necessary changes in the system design, to attribute more time to testing, and to attribute dedicated time for configuration (via Spring) tasks. New concepts are introduced in the implementation framework which implies them to be integrated in the new system design as well as in the new implementation, configuration, testing, and bug fixing: Events, Sources/Sinks, Stages, Channels (in the previous design, similar concepts existed, but the introduction of these new concepts implies substantial changes in the design, workflow, and implementation details). Accounting Server and Accounting Client are more closely matched to the previous system design and planning, but they need to be substantially adapted to the implementation framework and the use of new concepts.
The study period is newly introduced for phase 4 as a consequence of making as much use as possible of the IdP3 API and of the Spring framework.
The security analysis is narrowed in its focus. Phase 4 planning foresees a security specification that focuses exclusively on five security mechanisms of relevance. For each security mechanism, the specification determines if and how the mechanism is used for the AMAAIS use cases (regulatory analysis has been dropped).
This work item remains unchanged, but it is planned for at a later stage.
This work item is planned at an early stage in Phase 4. The charging component design is in most parts independent from the accounting implementation. A new additional item is the plan for publishing a paper on the design of the charging component.
Due to an altered system design and a changed implementation, the end-to-end test cases (trials) need to be changed too. These test cases will endorse dimensions of functionality and performance. The planning for trials remains unchanged, but trials are planned for at a later stage.
A single deliverable (D4) is now planned at the end of Phase 4. The final solution documentation will integrate centrally all output of tasks in Phase 4 (new system architecture, security specification, full implementation details, trial specification and results. A Paper specifying the design of the charging component is added as an annex).