1 / 22

Contrail and Federated Identity Management

Contrail and Federated Identity Management. Philip Kershaw, RAL Space, STFC Jens Jensen, e-Science, STFC (and others: XLab , CNR , INRIA …). contrail is co-funded by the EC 7th Framework Programme. 1. Outline. Contrail overview and goals Architecture S ingle sign -on

ray
Download Presentation

Contrail and Federated Identity Management

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Contrail and Federated Identity Management Philip Kershaw, RAL Space, STFC Jens Jensen, e-Science, STFC (and others: XLab, CNR, INRIA …) contrailis co-funded by the EC 7th Framework Programme 1

  2. Outline • Contrailoverview and goals • Architecture • Single sign-on • Delegationrequirements • Delegation solutions • OAuth flow • Conclusions • Collaborations 2

  3. Contrail Overview and Goals • EC FP7 Project, led by INRIA, 36 month, completes Sept 2013 • Federationof cloud providers • FederationwithexternalIdPs • “Elastic” CAs for dynamically created services • Autonomous SLA management from SLA@SOI project • IaaSand PaaSintegration • Reuseof existing open standards: OVF OCCI CDMI WS-Security SLA@SOI models 3

  4. Contrail Overview and Goals+ • EC FP7 Project, led by INRIA, 36 month, completes Sept 2013 • Federationof cloud providers • FederationwithexternalIdPs • “Elastic” CAs for dynamically created services • Autonomous SLA management from SLA@SOI project • IaaSand PaaSintegration • Reuseof existing open standards: OVF OCCI CDMI WS-Security SLA@SOI models Federated access to resources, building on existing identity federations 4

  5. Architecture Federation CLI Browser Browser and rich client access Federation Web Portal Online CA  REST API  Federation Identity Provider Federation core Federation of Cloud Providers 5

  6. Architecture – Single Sign-on Federation CLI Browser Single Sign-on Single Sign-on Federation Web Portal Credentials mapping Online CA  REST API  Federation Identity Provider Federation core Single Sign-on Cloud Providers 6

  7. Architecture - Delegation Federation CLI Browser Multiple delegation hops Federation Web Portal Online CA  REST API  Federation Identity Provider Federation core Cloud Providers 7

  8. Delegation … but how? • Delegator, delegates authority to another, a delegatee • Rights that the delegatee inherits can vary e.g. • Identity-based – inherits all the rights of the user • Inherit rights to access a single resource • Some technology options: • GSI Proxy certificates • OAuth 1.0 (CILogon), OAuth 2.0? • Others…

  9. Delegation: technology options • GSI Proxy certificates • Delegateeinheritsall the rights of the user • Custom SSL extensions needed to support verification • OAuth 1.0 • Gained traction in commercial environment: Twitter etc… • Digital signature of HTTP header artifacts – canonicalisationcanbeproblematic • OAuth 2.0 • Simplified flow • Use SSL: no digital signature implementationnecessary • CILogon • Use OAuth to protect a short-livedcredentialservice (SLCS) but based on OAuth 1.0 • Delegateesobtain a standard End EntityCertificate • SLCS + OAuth 2.0✔ 9

  10. OAuthFlow (1) Browser Objective: get delegated credential for portal to make onward requests to the federation core [OAuthAuthorisation Server] 1. User request Federation Web Portal [OAuth Client] Online CA [OAuth Resource Server] Federation Identity Provider Federation core Cloud Providers 10

  11. OAuth Flow (2  3) Browser 2. Portal requests authorisation for delegation from user 3. User is redirected to authorisation server [OAuthAuthorisation Server] Federation Web Portal [OAuth Client] Online CA [OAuth Resource Server] Federation Identity Provider Federation core Cloud Providers 11

  12. OAuth Flow (4) Browser 4. User authenticates and approves the delegation request [OAuthAuthorisation Server] Federation Web Portal [OAuth Client] Online CA [OAuth Resource Server] Federation Identity Provider Federation core Cloud Providers 12

  13. OAuth Flow (5) Browser 5. Return authorisation grant to portal via a redirect [OAuthAuthorisation Server] … redirect back to portal Federation Web Portal [OAuth Client] Online CA [OAuth Resource Server] Federation Identity Provider Federation core Cloud Providers 13

  14. OAuth Flow (6) Browser [OAuthAuthorisation Server] 6. Portal requests certificate (oauth access token) passing authorisation grant as proof of user approval Federation Web Portal [OAuth Client] Online CA [OAuth Resource Server] Federation Identity Provider Federation core Cloud Providers 14

  15. OAuth Flow (7) Browser [OAuthAuthorisation Server] Federation Web Portal [OAuth Client] Online CA [OAuth Resource Server] 7. Online CA authenticates portal and returns certificate Federation Identity Provider Federation core Cloud Providers 15

  16. OAuth Flow (8) Browser [OAuthAuthorisation Server] Federation Web Portal [OAuth Client] Online CA [OAuth Resource Server] 8. Portal uses certificate to authenticate with core services Federation Identity Provider Federation core Cloud Providers 16

  17. OAuth Flow (9) Browser [OAuthAuthorisation Server] Federation Web Portal [OAuth Client] Online CA [OAuth Resource Server] Federation Identity Provider Federation core 9. Further delegation needed: ‘2-legged’ OAuth Cloud Providers 17

  18. Development Status • Web portal and federation SSO demonstratedwith support for: • SAML • OpenID • Command line SSO withshell script client to Short-LivedCredential Service (X.509 EECs) • Delegationwith 2-legged OAuth-like interface, full OAuth to beintegrated 18

  19. Technology used • Federation Web • User interface: Python 2.7+ / Django 1.4 / buildout / Apache2 • SAML2: Djangosaml2 v0.5 • OpenID: Django-authopenid • Federation IdP • IdP: SimpleSAMLphp 1.9 rc2 • User DB: Java 6 / JPA subclipse / Tomcat

  20. Conclusion • Single sign-on support with: • Browser: SAML2 and OpenID • Other client: X.509 short-lived end entity certificates • Delegation with OAuth 2.0 protected Short-Lived Credential Service • Can we offer Federation-in-a-box or federation-as-a-service ? • => Federated access to resources, building on existing identity federations.

  21. Contrail collaborations • Contrail evaluation with: • EUDAT, CLARIN, ENES • EGI federated cloud task force • Climate science and Earth Observation communities: OAuth solution for workflows • OGF groups • FEDSEC-CG: federated identity for grids and clouds • IDEL-WG: working group on identity delegation • Cloud security activities • ... Moonshot

  22. contrail is co-funded by the EC 7th Framework Programme Funded under: FP7 (Seventh Framework Programme) Area: Internet of Services, Software & virtualization (ICT-2009.1.2) Project reference: 257438 Total cost: 11,29 million euro EU contribution: 8,3 million euro Execution: From 2010-10-01 till 2013-09-30 Duration: 36 months Contract type: Collaborative project (generic) 22

More Related