Alert.png The wiki is deprecated and due to be decommissioned by the end of September 2022.
The content is being migrated to other supports, new updates will be ignored and lost.
If needed you can get in touch with EGI SDIS team using operations @ egi.eu.

Federated AAI Implementation

From EGIWiki
Revision as of 15:09, 5 June 2012 by Bjoernh (talk | contribs)
Jump to navigation Jump to search

This page deals with the implementation of the AAI scenario in the various services. For one, we need to look into each of the middlewares and how to hook the authentication (X.509) and authorization (XACML) into them. Before that, we need to ensure that this is even possible, although at least some work in these directions is surfacing for instance in OpenStack (ADD REFERENCES!).

VM Management

OpenStack

Responsible: BHa

  • Authentication
    • Keystone support for PKI scheduled for the Folsom release (2012-09-27), more specifically folsom-3 http://bit.ly/LKpeI2 (2012-08-16)
  • Authorization
    • May be possible with alternative authZ backends to Keystone


OpenNebula

StratusLab

WNoDeS

Okeanos

Data

AuthZ scenario

Implementation (Deployment)

Marketplace

AuthZ scenario

The Marketplace seems to have the second most complex authorization scenario after VM Management. It is expected that each provider is represented by a group in the marketplace that only it can write to. Thus, write access to each of these groups must be controlled.

Implementation (Deployment)

Accounting

AuthN scenario

A user must be authenticated to access any accounting information.

AuthZ scenario

Access to accounting information must be restricted. Each provider must be able to see its own resource consumption, but not that of other providers. EGI staff shall only be allowed to view aggregated information.

Implementation (Deployment)

Assuming that the Accounting interface is deployed in a Web-Server like Apache2, we expect generic AuthN and AuthZ modules to be available, see below.

Monitoring

AuthN scenario

A user must be authenticated to access any monitoring information.

AuthZ scenario

For the most part, monitoring data is publicly readable for any authenticated user. However, there are some administrator actions defined on the interface, that should be restricted. As this is well covered in the Nagios tool, we will not worry about it for the time being.

Implementation (Deployment)

Assuming that the Monitoring interface is deployed in a Web-Server like Apache2, we expect generic AuthN and AuthZ modules to be available, see below.

Notification

This service is not expected to be covered by this working group.

Information

This service is not expected to be covered by this working group.