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.

Difference between revisions of "Fedcloud-tf:WorkGroups: Federated AAI"

From EGIWiki
Jump to navigation Jump to search
Line 19: Line 19:
| Collaborator  
| Collaborator  
| CESNET
| CESNET
| Boris Parak
| Dan Kouřil
|-
|-
| Collaborator  
| Collaborator  

Revision as of 09:27, 13 December 2011

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



Integrating authentication and authorisation across multiple resource providers

Leader: Bjoern Hagemeier, FZJ

Collaborators

Role Institution Name
Scenario leader FZJ Bjoern Hagemeier
Collaborator CESNET Dan Kouřil
Collaborator OeRC Matteo Turilli

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

Degrees of Freedom

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.

OpenStack
OpenNebula
CloudSigma

Collaboration Opportunities

Technical details

Identity providers

X.509 certificates

SAML

Delegation

Liaisons