Federated Identity Management for the context of storage

Bart Kerver - Bart.Kerver@surfnet.nl

TERENA Storage-meeting, Amsterdam, 29 June 2007

2

Agenda (ca 30 minutes)

Introduction

Authentication & Authorization Infrastructures- What is an AAI?- Why the need for an AAI?

Federations- What is federation?- Why federate?- Federations are happening!- Global flow- Limitations current feds’

Storage- requirements for storage- SURFnet GRIDdrive project

(no summary )

3

users network resources identities

authenticate

authorization

provisioningaccess control

loggingmonitoring

registration

management

accountingidentificationsso

network

database

SAML

SPML

directory

XACML

dirxml

dsml

WS*

ID-FF

Introduction

4

What is an AAI?

AAI: Authentication and Authorization Infrastructure:- identification/authentication of users;- gathering of identity information of a user (attributes);- authorize users (apply and release attributes);- transport of the assertions;

important component: ‘trust’.

…and if this is all in place, you’re able to:- provision (eg. create a ‘profile’ for an ELO);- personalize (eg. apply a ‘role’ in an ELO);- control access to resources.

Examples:Star Alliance, banking, eduroam, CreditCard …

5

Why the need for an AAI?

- Ease of use: less passwords, Single Sign-On, authenticate at home institute;

- Collaboration of institutes (national/international);

- Mobility of users on the network and among institute(Bologna act, European Credit Transfer System - ECTS);

- Growing need for access control and personalization;

- Centralized AAI has great (positive) impact on for maintenance/management/security/costs, etcetera.;

- Easy to add additional services (resources/content).

6

What is federation?

1. It’s a formal federation (‘collaboration’) of organizations focused on creating a common framework for trust in support of research and education.

2. A federation is an association of organizations that use a common set of attributes, practices and policies to exchange information about their users and resources in order to enable collaborations and transactions.

So… it’s all about sharing resources

- Federation has two main pillars:- procedures/policies (fe. schema, trust, …)- technical implementation (fe. pki, eduperson, metadata,

technology)

- Federations are not about a certain product but should be build on standards (fe. SAML/Liberty/WS*).

7

Why federate?

AAI on different levels with own complexity, eg.:A. Faculty (local management of identities)B. University (centralize identities / setup IdM!)C. National (federate)D. International (con-federate)

Growing number of service providers and inter-institutional communication results in 1 to N relationships...

service provider

central components for federation

Identity provider

A B wanted ? C D

8

Federations are happening

HAKA

JISC federation

DK-AAI

- Applications outsourcing their users

- To the home institution of the user

- To a single place at the home institution

- Academic identity federations are operational

- Real services used everyday by large amount of users

- Research and educational applications are federated

- Federation software available in the marketplace

- Identity2.0 aka CardSpace

- Making "identity" tangible to users

- Convergence is there

- With SAML as lingua franca

- How to connect all of these federations

- ‘Con-federate’

10

Global flow (web!)

1: Access resource at SP2: you are not authenticated, go to federation4: Select your IdP (WAYF)3: What IdP’s are available? 5: I want to authenticate6: Please supply credentials to authenticate7: You are authenticated and authorized, go back to the federation and carry the authentication assertion

8: Redirect to SP with authentication assertion

9: Access to resource granted

11

Limitations current ‘feds’.

- Federations focus on either network (eduroam - RADIUS) or access to

web (http) resources (aka Shibboleth) or are build for GRIDs (fe.

Globus/GRID).

- Different versions of federations do not interact well (better to say are

‘different worlds’). Good initiative: GRID-Shibboleth (GRIDSHIB).

- Commonly federations implement only profiles/bindings for web (http)

resources: eg: web-redirects, but standard (SAML) does support others;

- Identity Management solutions at Identity Providers commonly only

support authentication for federated access based on web (fe.

PubCookie, CAS, mod_ldap, A-Select, PAPI);

12

Requirements for storage?

Suggestions, idea’s, challenges!?

- Mixed access?

- Application/API level (webservice?)

- Webbrowser access (webdav?)

- Persistent identity for storage profile (fe. other federated identity shouldn’t mean

loss of profile and therefore data!)

- Initially dual identification/authentication methods (both federated and local)?

- Use of federation standards, not really converging standards of GRID and

federations for web (fe. certificates vs SAML) – how to cover/choose?

13

Project GRIDdrive

- SURFnet technology scouting for GRID;

- End-to-End security (encryption);

- Both web service interface (applications) and browser interface (web) client;

- Initially Amazon S3 storage provider, but back-end to other storage

providers (storage grids) possible;

- Runs virtualized in Amazon EC2 (Elastic Computing Cloud); (bigger load

more virtual hardware);

- Access only through SURFfederation.

14

Architecture GRIDdrive

DATABASE SERVER S3 BUCKETWEB SERVER S3 BUCKET

Client

FILE STORAGE S3 BUCKET

WEBSERVER EC2 ENVIRONMENT

Web Server

DATABASE EC2 ENVIRONMENT

Database

User Data User Data User Data User Data User Data

A-Select & Federation

Legend

Amazon Components

Specific SURFnet Components

External

15

Federated IdM (authN)

16

Interface (web)

18

Questions ?