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 "Fedcloud-tf:WorkGroups: Federated AAI"
(Work in progress.) |
(Work in progress.) |
||
| Line 22: | Line 22: | ||
== Scope == | == Scope == | ||
We have already defined | We have already defined that user authentication should be based on X.509 certificates rather than | ||
usernames and passwords or other credential material. Nevertheless, depending on the type of | |||
federation intended, this may not even be a real requirement. Any service should rely on | |||
an identity provider and | |||
== Questions == | == Questions == | ||
| Line 62: | Line 65: | ||
==== Infrastructure ==== | ==== Infrastructure ==== | ||
===== SSO ===== | ===== EGI SSO ===== | ||
* What does it use? | |||
* Possible integration? | * Possible integration? | ||
===== Product Support ===== | |||
One of the key factory influencing the choice of AAI will be the | |||
support in the already deployed Cloud products in the | |||
[[Fedcloud-tf:Testbed|Testbed]]. Most likely, support will not be | |||
directly available. But where it is, it will be valuable. Most | |||
probably, we will have to evaluate the effort required to integrate | |||
AA support into the products. | |||
====== OpenStack ====== | |||
====== OpenNebula ====== | |||
====== CloudSigma ====== | |||
| Line 72: | Line 92: | ||
=== X.509 certificates === | === X.509 certificates === | ||
=== SAML === | |||
=== Delegation === | === Delegation === | ||
Revision as of 13:50, 2 December 2011
| Main | Roadmap and Innovation | Technology | For Users | For Resource Providers | Media |
Leader: Bjoern Hagemeier, FZJ
Collaborators
| Role | Institution | Name |
|---|---|---|
| Scenario leader | FZJ | Bjoern Hagemeier |
| Collaborator | CESNET | Boris Parak |
Scope
We have already defined that user authentication should be based on X.509 certificates rather than usernames and passwords or other credential material. Nevertheless, depending on the type of federation intended, this may not even be a real requirement. Any service should rely on an identity provider and
Questions
Type of Federation
Thank you David W. for mentioning the difference in the information publishing document.
Before taking any decision about the requirements for a federated AAI, one needs to be sure what type of federation is desired. There are roughly two types that need to be considered, which have a strong influence on how to authenticate and authorize users.
Tight federation
The federated cloud systems are all the same for the user. He only interacts with a single point of entry. Consequently, there can (and probably should) be a single user database.
Loose federation
Every user has a home organization at which he can be authenticated (identity provider). Every service within the federation 'knows' a list of acceptable identity providers.
VO support
What's already there?
Products
Shibboleth
UVOS
VOMS
Infrastructure
EGI SSO
- What does it use?
- Possible integration?
Product Support
One of the key factory influencing the choice of AAI will be the support in the already deployed Cloud products in the Testbed. Most likely, support will not be directly available. But where it is, it will be valuable. Most probably, we will have to evaluate the effort required to integrate AA support into the products.