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 1: Line 1:
{{Fedcloud-tf:Menu}} {{Fedcloud-tf:WorkGroups:Menu}} {{TOC_right}}
{{Fedcloud-tf:Menu}} {{Fedcloud-tf:WorkGroups:Menu}} {{TOC_right}}  


= Integrating authentication and authorisation across multiple resource providers  =
= Integrating authentication and authorisation across multiple resource providers  =


<font color="red">Leader: Bjoern Hagemeier, FZJ</font>
<font color="red">Leader: Bjoern Hagemeier, FZJ</font>  


== Collaborators  ==
== Collaborators  ==
Line 14: Line 14:
|-
|-
| Scenario leader  
| Scenario leader  
| FZJ
| FZJ  
| Bjoern Hagemeier
| Bjoern Hagemeier
|-
|-
| Collaborator  
| Collaborator  
| CESNET
| CESNET  
| Dan Kouřil
| Dan Kouřil
|-
|-
| Collaborator  
| Collaborator  
| OeRC
| OeRC  
| Matteo Turilli
| Matteo Turilli
|}
|}


== Scope ==
== Scope ==


We have already defined that user authentication should be based on X.509 certificates rather than
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 that is in charge of the type of credentials used for authentication.  
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 that is in charge of the type of credentials used for authentication.


== Degrees of Freedom ==
== Degrees of Freedom ==


=== Type of Federation ===
=== Type of Federation ===


Thank you David W. for mentioning the difference in the information publishing document.
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
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.  
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 ====
==== Tight federation ====


The federated cloud systems are all the same for the user. He only interacts with a single
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.  
point of entry. Consequently, there can (and probably should) be a single user database.


<br>


==== Loose federation ====
==== Loose federation ====


Every user has a home organization at which he can be authenticated (identity provider).
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.  
Every service within the federation 'knows' a list of acceptable identity providers.


=== VO support ===
=== VO support ===


=== Authentication -- What's already there? ===
=== Authentication -- What's already there? ===


==== Standards ====
==== Standards ====


===== SAML =====
===== SAML =====


" [http://en.wikipedia.org/wiki/Security_Assertion_Markup_Language Security Assertion Markup Language (SAML)] is an XML-based open standard for exchanging authentication and authorization data between security domains, that is, between an identity provider (a producer of assertions) and a service provider (a consumer of assertions)."
" [http://en.wikipedia.org/wiki/Security_Assertion_Markup_Language Security Assertion Markup Language (SAML)] is an XML-based open standard for exchanging authentication and authorization data between security domains, that is, between an identity provider (a producer of assertions) and a service provider (a consumer of assertions)."  


<br>


===== OAuth =====
===== OAuth =====


"[http://en.wikipedia.org/wiki/OAuth OAuth (Open Authorization)] is an open standard for authorization. It allows users to share their private resources (e.g., photos, videos, contact lists) stored on one site with another site without having to hand out their credentials, typically username and password.
"[http://en.wikipedia.org/wiki/OAuth OAuth (Open Authorization)] is an open standard for authorization. It allows users to share their private resources (e.g., photos, videos, contact lists) stored on one site with another site without having to hand out their credentials, typically username and password.  


...
...  


OAuth is a service that is complementary to, but distinct from, OpenID."
OAuth is a service that is complementary to, but distinct from, OpenID."  


===== x.509 Certificates =====
===== x.509 Certificates =====


incl. Proxies
incl. Proxies  


===== OpenID =====
===== OpenID =====


OpenID is an open standard that describes how users can be authenticated in a decentralized manner,
OpenID is an open standard that describes how users can be authenticated in a decentralized manner, eliminating the need for services to provide their own ad hoc systems and allowing users to consolidate their digital identities. Users may create accounts with their preferred OpenID identity providers, and then use those accounts as the basis for signing on to any website which accepts OpenID authentication. The OpenID standard provides a framework for the communication that must take place between the identity provider and the OpenID acceptor (the ‘relying party’). An extension to the standard (the OpenID Attribute Exchange) facilitates the transfer of user attributes, such as name and gender, from the OpenID identity provider to the relying party (each relying party may request a different set of attributes, depending on its requirements).  
eliminating the need for services to provide their own ad hoc systems and allowing users to consolidate
their digital identities. Users may create accounts with their preferred OpenID identity providers,
and then use those accounts as the basis for signing on to any website which accepts OpenID authentication.
The OpenID standard provides a framework for the communication that must take place between the identity
provider and the OpenID acceptor (the ‘relying party’). An extension to the standard (the OpenID
Attribute Exchange) facilitates the transfer of user attributes, such as name and gender, from the OpenID
identity provider to the relying party (each relying party may request a different set of attributes,
depending on its requirements).


==== AAI Products ====
==== AAI Products ====


===== Shibboleth  =====
===== 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.
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 =====
===== 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.  
[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.
[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  ====
Line 124: Line 110:
The [http://stratuslab.eu/doku.php/authentication authentication] uses the Jetty application server and the JAAS system to provide a wide variety of mechanisms for authenticating users. System administrators can choose to use:  
The [http://stratuslab.eu/doku.php/authentication authentication] uses the Jetty application server and the JAAS system to provide a wide variety of mechanisms for authenticating users. System administrators can choose to use:  


*Username/password pairs maintained in a configuration file
*Username/password pairs maintained in a configuration file  
*Username/password pairs from an LDAP server
*Username/password pairs from an LDAP server  
*Grid certificates
*Grid certificates  
*VOMS proxies created from grid certificates
*VOMS proxies created from grid certificates


===== WNoDeS =====
===== WNoDeS =====


==== Infrastructure ====
==== Infrastructure ====


===== EGI SSO =====
===== EGI SSO =====


* What does it use?
*What does it use?  
* Possible integration?
*Possible integration?


== Liaisons ==
=== Authorization ===


* Dan Kouřil is leader of [[VT_Federated_Identity_Providers_Assessment|VT Federated Identity Providers Assessment]]
Authorization is the second principle by which users gain access to resources. In the same way as the authentication infrastructure (identity management), an authorization infrastrucuture must be put in place. Authentication and authorization infrastructure go hand in hand, as authenticated users must be mapped to appropriate policies. The authorization infrastructure is federated in the same way as the authentication infrastructure, although policies can be expected to be more hirarchical.
* [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]
 
==== XACML ====
 
The predominant standard in terms of authorization is XACML.
 
*http://xacmlpdp.sourceforge.net/
*http://www.herasaf.org/
*http://sourceforge.net/projects/xacmllight/
*Others can be found at:&nbsp;http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml
 
== 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]

Revision as of 09:23, 21 February 2012

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 that is in charge of the type of credentials used for authentication.

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

Authentication -- What's already there?

Standards

SAML

" Security Assertion Markup Language (SAML) is an XML-based open standard for exchanging authentication and authorization data between security domains, that is, between an identity provider (a producer of assertions) and a service provider (a consumer of assertions)."


OAuth

"OAuth (Open Authorization) is an open standard for authorization. It allows users to share their private resources (e.g., photos, videos, contact lists) stored on one site with another site without having to hand out their credentials, typically username and password.

...

OAuth is a service that is complementary to, but distinct from, OpenID."

x.509 Certificates

incl. Proxies

OpenID

OpenID is an open standard that describes how users can be authenticated in a decentralized manner, eliminating the need for services to provide their own ad hoc systems and allowing users to consolidate their digital identities. Users may create accounts with their preferred OpenID identity providers, and then use those accounts as the basis for signing on to any website which accepts OpenID authentication. The OpenID standard provides a framework for the communication that must take place between the identity provider and the OpenID acceptor (the ‘relying party’). An extension to the standard (the OpenID Attribute Exchange) facilitates the transfer of user attributes, such as name and gender, from the OpenID identity provider to the relying party (each relying party may request a different set of attributes, depending on its requirements).

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.

OpenNebula

cf. Fedcloud-tf:Blueprint:Capabilities:Authentication and Authorisation#OpenNebula

OpenStack

Towards the end of 2010, OpenStack started their authn initiative to consolidate the various mechanisms available in the different components of OpenStack. The goal of this initiative was "to define a standard for authentication in OpenStack that enables services to support multiple authentication protocols in a pluggable manner".

Starting with its Diablo release, "Keystone is the identity service used by OpenStack for authentication (authN) and high-level authorization (authZ). It currently supports token-based authN and user-service authorization. It is scalable to include oAuth, SAML and openID in future versions.

Whereas in the Diablo release Keystone is an add-on component, the following Essex release provides Keystone as a core component.

StratusLab

The authentication uses the Jetty application server and the JAAS system to provide a wide variety of mechanisms for authenticating users. System administrators can choose to use:

  • Username/password pairs maintained in a configuration file
  • Username/password pairs from an LDAP server
  • Grid certificates
  • VOMS proxies created from grid certificates
WNoDeS

Infrastructure

EGI SSO
  • What does it use?
  • Possible integration?

Authorization

Authorization is the second principle by which users gain access to resources. In the same way as the authentication infrastructure (identity management), an authorization infrastrucuture must be put in place. Authentication and authorization infrastructure go hand in hand, as authenticated users must be mapped to appropriate policies. The authorization infrastructure is federated in the same way as the authentication infrastructure, although policies can be expected to be more hirarchical.

XACML

The predominant standard in terms of authorization is XACML.

Liaisons