Difference between revisions of "Fedcloud-tf:WorkGroups: Federated AAI"
(Work in progress.) |
|||
Line 19: | Line 19: | ||
| Boris Parak | | Boris Parak | ||
|} | |} | ||
== Scope == | |||
We have already defined | |||
== 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 ==== | |||
===== SSO ===== | |||
* Possible integration? | |||
== Technical details == | |||
=== Identity providers === | |||
=== X.509 certificates === | |||
=== Delegation === |
Revision as of 11:01, 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
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
SSO
- Possible integration?