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.
Difference between revisions of "Federated AAI Implementation"
| Line 4: | Line 4: | ||
work in these directions is surfacing for instance in OpenStack (ADD REFERENCES!). | work in these directions is surfacing for instance in OpenStack (ADD REFERENCES!). | ||
== VM Management == | == [[Fedcloud-tf:WorkGroups:Scenario1|VM Management]] == | ||
=== OpenStack === | === OpenStack === | ||
| Line 24: | Line 24: | ||
=== Okeanos === | === Okeanos === | ||
== Data == | == [[Fedcloud-tf:WorkGroups:Scenario2|Data]] == | ||
== | === AuthZ scenario === | ||
== | === Implementation (Deployment) === | ||
== | == [[Fedcloud-tf:WorkGroups:VM Marketplace|Marketplace]] == | ||
== | === AuthZ scenario === | ||
== | === Implementation (Deployment) === | ||
== [[Fedcloud-tf:WorkGroups:Scenario4|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. | |||
== [[Fedcloud-tf:WorkGroups:Scenario5|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. | |||
== [[Fedcloud-tf:WorkGroups:Scenario6|Notification]] == | |||
This service is not expected to be covered by this working group. | |||
== [[Fedcloud-tf:WorkGroups:Scenario3|Information]] == | |||
This service is not expected to be covered by this working group. | |||
Revision as of 15:56, 5 June 2012
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
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.