Difference between revisions of "Federated AAI Implementation"
(10 intermediate revisions by 3 users not shown) | |||
Line 1: | Line 1: | ||
This page deals with the implementation of the AAI scenario in the various services. | 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!). | ||
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!). | |||
== [[Fedcloud-tf:WorkGroups:Scenario1|VM Management]] == | == [[Fedcloud-tf:WorkGroups:Scenario1|VM Management]] == | ||
=== OpenStack === | === OpenStack === | ||
'''Responsible:''' BHa | '''Responsible:''' BHa | ||
* Álvaro López García has implemented a Keystone backend for VOMS based authentication. It is available from his github repository<ref>https://github.com/alvarolopez/keystone</ref>. Documentation can be found as part of the sources or here<ref>https://github.com/alvarolopez/keystone/blob/voms_auth/doc/source/voms.rst</ref> | *Álvaro López García has implemented a Keystone backend for VOMS based authentication. It is available from his github repository<ref>https://github.com/alvarolopez/keystone</ref>. Documentation can be found as part of the sources or here<ref>https://github.com/alvarolopez/keystone/blob/voms_auth/doc/source/voms.rst</ref> | ||
* Keystone support for PKI | *Keystone support for PKI had also been scheduled for the Folsom release (2012-09-27), more specifically folsom-3 http://bit.ly/LKpeI2 (2012-08-16). However, we do not exploit this feature at the moment. | ||
* Authorization | *Authorization | ||
** Alvaro's implementation currently provides mappings of VO to tenants and roles. | **Alvaro's implementation currently provides mappings of VO to tenants and roles. | ||
** Alternative backends to Keystone may be possible to support more fine-grained authorization policies. | **Alternative backends to Keystone may be possible to support more fine-grained authorization policies. | ||
=== OpenNebula === | === [[Fedcloud-tf:WorkGroups: Federated AAI:OpenNebula|OpenNebula]] === | ||
=== StratusLab === | === StratusLab === | ||
=== WNoDeS === | === WNoDeS === | ||
=== Okeanos === | === Okeanos === | ||
== [[Fedcloud-tf:WorkGroups: | == [[Fedcloud-tf:WorkGroups:VM Marketplace|Marketplace]] == | ||
=== AuthZ scenario === | === 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. | |||
The scenario has actually been rejected by the MP developers. | |||
=== | === Implementation (Deployment) === | ||
No information available yet. | |||
== | == [[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. | |||
There is no implementation as of December 2012. | |||
== [[Fedcloud-tf:WorkGroups:Scenario5|Monitoring]] == | == [[Fedcloud-tf:WorkGroups:Scenario5|Monitoring]] == | ||
=== AuthN scenario === | === AuthN scenario === | ||
A user must be authenticated to access any monitoring information. | A user must be authenticated to access any monitoring information. | ||
=== AuthZ scenario === | === AuthZ scenario === | ||
For the most part, monitoring data is publicly readable for any authenticated user. However, there | 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. | ||
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) === | === Implementation (Deployment) === | ||
Assuming that the Monitoring interface is deployed in a Web-Server like Apache2, we | 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. | ||
expect generic AuthN and AuthZ modules to be available, see below. | |||
== [[Fedcloud-tf:WorkGroups:Scenario6|Notification]] == | == [[Fedcloud-tf:WorkGroups:Scenario6|Notification]] == | ||
This service is not expected to be covered by this working group. | This service is not expected to be covered by this working group. | ||
== [[Fedcloud-tf:WorkGroups: | == [[Fedcloud-tf:WorkGroups:Scenario2|Data]] == | ||
This service is not expected to be covered by this working group. | n/a | ||
== [[Fedcloud-tf:WorkGroups:Scenario3|Information]] == | |||
This service is not expected to be covered by this working group. | |||
== References == | |||
<references /> | |||
[[Category:Technology]] [[Category:Fedcloud-tf]] |
Latest revision as of 12:13, 13 February 2013
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
- Álvaro López García has implemented a Keystone backend for VOMS based authentication. It is available from his github repository[1]. Documentation can be found as part of the sources or here[2]
- Keystone support for PKI had also been scheduled for the Folsom release (2012-09-27), more specifically folsom-3 http://bit.ly/LKpeI2 (2012-08-16). However, we do not exploit this feature at the moment.
- Authorization
- Alvaro's implementation currently provides mappings of VO to tenants and roles.
- Alternative backends to Keystone may be possible to support more fine-grained authorization policies.
OpenNebula
StratusLab
WNoDeS
Okeanos
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.
The scenario has actually been rejected by the MP developers.
Implementation (Deployment)
No information available yet.
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.
There is no implementation as of December 2012.
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.
Data
n/a
Information
This service is not expected to be covered by this working group.