Difference between revisions of "Fedcloud-tf:WorkGroups: Federated AAI"
Line 78: | Line 78: | ||
===== UVOS ===== | ===== UVOS ===== | ||
[http://uvos.chemomentum.org/ UNICORE VO Service (UVOS)] is a client-server system, developed to be used as an additional tool for large distributed systems. Grid systems, especially UNICORE grid middleware, are the mainspring of the UVOS system. Although UVOS can be used with different systems, however is designed primarly to support UNICORE grid middleware. | |||
===== VOMS ===== | ===== VOMS ===== | ||
[http://www.globus.org/grid_software/security/voms.php VOMS] is a system for managing authorization data within multi-institutional collaborations. VOMS provides a database of user roles and capabilities and a set of tools for accessing and manipulating the database and using the database contents to generate Grid credentials for users when needed. | |||
==== Cloud Product Support ==== | ==== Cloud Product Support ==== |
Revision as of 09:32, 17 January 2012
Main | Roadmap and Innovation | Technology | For Users | For Resource Providers | Media |
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?
Standards
SAML
OAuth
x.509 Certificates
incl. Proxies
OpenID
AAI Products
Shibboleth
The Shibboleth System is a standards based, open source software package for web single sign-on across or within organizational boundaries. It allows sites to make informed authorization decisions for individual access of protected online resources in a privacy-preserving manner.
UVOS
UNICORE VO Service (UVOS) is a client-server system, developed to be used as an additional tool for large distributed systems. Grid systems, especially UNICORE grid middleware, are the mainspring of the UVOS system. Although UVOS can be used with different systems, however is designed primarly to support UNICORE grid middleware.
VOMS
VOMS is a system for managing authorization data within multi-institutional collaborations. VOMS provides a database of user roles and capabilities and a set of tools for accessing and manipulating the database and using the database contents to generate Grid credentials for users when needed.
Cloud 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
cf. Fedcloud-tf:Blueprint:Capabilities:Authentication and Authorisation#OpenNebula
CloudSigma
Infrastructure
EGI SSO
- What does it use?
- Possible integration?