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.

Fedcloud-tf:WorkGroups: Federated AAI

From EGIWiki
Revision as of 11:01, 2 December 2011 by Bjoernh (talk | contribs) (Work in progress.)
Jump to navigation Jump to search
Main Roadmap and Innovation Technology For Users For Resource Providers Media


Workbenches: Open issues
Scenario 1
VM Management
Scenario 2
Data Management
Scenario 3
Information Systems
Scenario 4
Accounting
Scenario 5
Monitoring
Scenario 6
Notification
Scenario 7
Federated AAI
Scenario 8
VM Image Management
Scenario 9
Brokering
Scenario 10
Contextualisation
Scenario 11
Security



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?


Technical details

Identity providers

X.509 certificates

Delegation