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 "Federated Cloud Federated AAI"

From EGIWiki
Jump to navigation Jump to search
(Created page with "{{Fedcloud_Menu}} {{FedCloud_TF_Menu}} {{TOC_right}} Category:Federated_Cloud = Integrating authentication and authorisation across multiple resource providers = <font ...")
 
 
(2 intermediate revisions by the same user not shown)
Line 3: Line 3:
{{FedCloud_TF_Menu}} {{TOC_right}}  
{{FedCloud_TF_Menu}} {{TOC_right}}  


[[Category:Federated_Cloud]]
= Integrating authentication and authorisation across multiple resource providers  =


<font color="red">Leader: Bjoern Hagemeier, FZJ</font>
= Scope =
 
Integrating authentication and authorisation across multiple resource providers
 


== Collaborators  ==
= Members=


{| border="1"
{| class="wikitable"
|-
|-
! Role  
! Role  
Line 29: Line 30:
|}
|}


== Scope  ==
 
=Roadmap=
 
=Documentation=


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.  
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.  
Line 37: Line 41:
A quick overview of AAI support in technologies and providers, as well as the specific settings for FCTF can be found at [[Federated AAI Integration Status]].
A quick overview of AAI support in technologies and providers, as well as the specific settings for FCTF can be found at [[Federated AAI Integration Status]].


There are also various technologies that support translating [[Fedcloud-tf:WorkGroups:Federated AAI:Credential Translation|Federated Identity to an X.509]]. In general, these allow a user to authenticate with some other technology (e.g., SAML), typically within a web portal, which then has an X.509 credential with which it can interact with EGI resources.
There are also various technologies that support translating Federated Identity to an X.509. In general, these allow a user to authenticate with some other technology (e.g., SAML), typically within a web portal, which then has an X.509 credential with which it can interact with EGI resources:
*STS is the Security Token Service (as defined in WS-Trust) allows translating one credential type to that of a different type.
*[[Fedcloud-tf:WorkGroups:Federated AAI:per-user sub-proxy|Per-user sub-proxy]] is a mechanism where a robot certificate can advertise a change of identity.
 
= Liaisons  =


== Quick links  ==
*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%7CD2.1 Requirements on Federation Management, Identity and Policy Management in Federations]


=References =
*[[Federated AAI Roadmap]]  
*[[Federated AAI Roadmap]]  
*[[Federated AAI Integration Status]]  
*[[Federated AAI Integration Status]]  
Line 49: Line 59:
*[[Federated AAI Survey of Credential Services]]
*[[Federated AAI Survey of Credential Services]]


<br>  
<references />


== Liaisons  ==
[[Category:Federated_Cloud]]
 
*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%7CD2.1 Requirements on Federation Management, Identity and Policy Management in Federations]
 
== References  ==
 
<references />

Latest revision as of 16:51, 5 May 2015

Overview For users For resource providers Infrastructure status Site-specific configuration Architecture



Scenarios: Federated AAI Accounting VM Image Management Brokering IntraCloud Networking
Monitoring VM Management Data Management Information Discovery Security




Scope

Integrating authentication and authorisation across multiple resource providers


Members

Role Institution Name
Scenario Leader DESY Paul Millar
Collaborator FZJ Bjoern Hagemeier
Collaborator CESNET Dan Kouřil


Roadmap

Documentation

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.

For the technical implementations of this scenario, please go to Federated AAI Implementation.

A quick overview of AAI support in technologies and providers, as well as the specific settings for FCTF can be found at Federated AAI Integration Status.

There are also various technologies that support translating Federated Identity to an X.509. In general, these allow a user to authenticate with some other technology (e.g., SAML), typically within a web portal, which then has an X.509 credential with which it can interact with EGI resources:

  • STS is the Security Token Service (as defined in WS-Trust) allows translating one credential type to that of a different type.
  • Per-user sub-proxy is a mechanism where a robot certificate can advertise a change of identity.

Liaisons

References