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
(Redirected page to Federated Cloud Federated AAI)
 
(27 intermediate revisions by 4 users not shown)
Line 1: Line 1:
{{Fedcloud-tf:Menu}} {{Fedcloud-tf:WorkGroups:Menu}} {{TOC_right}}
#REDIRECT[[Federated_Cloud_Federated_AAI]]
 
= Integrating authentication and authorisation across multiple resource providers  =
 
<font color="red">Leader: Bjoern Hagemeier, FZJ</font>
 
== Collaborators  ==
 
{| border="1"
|-
! 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 [http://shibboleth.internet2.edu/ 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 =====
 
[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 =====
 
[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 ====
 
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 =====
 
cf. [[Fedcloud-tf:Blueprint:Capabilities:Authentication and Authorisation#OpenNebula]]
 
===== CloudSigma =====
 
 
==== Infrastructure ====
 
===== EGI SSO =====
 
* What does it use?
* Possible integration?
 
 
== Liaisons ==
 
* Dan Kouřil is leader of [[VT_Federated_Identity_Providers_Assessment|VT Federated Identity Providers Assessment]]
* [http://contrail-project.eu/ Contrail Project] [http://contrail-project.eu/downloads1/-/document_library_display/bM20/view/136157/2914?_110_INSTANCE_bM20_redirect=http%3A%2F%2Fcontrail-project.eu%2Fdownloads1%2F-%2Fdocument_library_display%2FbM20%2Fview%2F136157|D2.1 Requirements on Federation Management, Identity and Policy Management in Federations]

Latest revision as of 12:10, 8 June 2015