KoM WP3 Task3.2
Overview and Next steps
Yuri Demchenko
University of Amsterdam

Task 3.2 Development of Security and AccessControl Mechanisms in a Multi-cloud Federated
Environment [M2-M24]

Task leader: Yuri Demchenko (UvA)
Mechanisms to be developed should allow users
to access all federated resources using their homeinstitution accountDevelop appropriate trust and identity
management mechanisms

KoM EU Brazil CC 12-14 Feb
2014

WP3 Task 3.2 Federated Access Control2Task 3.2 Activity Details(from DoW)
Design and implementation of federation mechanisms at the IaaS levelthat will allow cloud inter-provider federation
Usage scenario: Independent private cloud providers (members of afederation) that share the same API can reserve/allocate part of theirresources to be used in a communal pool of resources (aka distributedcommunity cloud) that can be used any user belonging to the federation.
Actually re-use/re-factor Grid VO model

The mechanisms to be developed should enable federated access control
and resource management
Authentication, authorization and auditing
Resource allocation prioritization - Control & signaling?
Support lightweight decentralized business models
Evaluate brokered federation operation and management

Leverage the experience with similar systems, such as the JiT Cloud andOurGrid middleware whose development are led by UFCG

KoM EU Brazil CC 12-14 Feb
2014

WP3 Task 3.2 Federated Access Control

3Task 3.2 interaction with othertasks
Task 3.1 Operation and Support of theProduction Infrastructure [M1-M24]
Task 3.2 Development of Security andAccess Control Mechanisms in a
Multi-cloud Federated Environment[M2-M24]
Task 3.3 Adaptation and Deploymentof Cloud Federation Mechanism [M1M24]
Task 3.4 Exploitation of Shared
Resources in an Opportunistic
Federated Cloud [M1-M24]
Task 3.5 Adaptation of CSGrid
middleware [M1-M24]
KoM EU Brazil CC 12-14 Feb
2014

Task 3.2 will contribute with thesecurity analysis and taxonomy[M2-M?]
Task 3.2 expect to receive fromother tasks use cases and scenarios[M?-M?]
Task 3.2 jointly with other tasks will
specify requirements and define
security/access control policy [M?M?]
Security interface definition, to be
implemented by applications
Security mechanisms developments
Security mechanisms integration

WP3 Task 3.2 Federated Access Control

4Interaction with other WPs
Should be done via general WP3 interaction
WP3 <-> WP5 Use cases

KoM EU Brazil CC 12-14 Feb
2014

WP3 Task 3.2 Federated Access Control

5How to enable effective
collaboration?
Knowing involved people
Planning work
Interaction
Common development platform

KoM EU Brazil CC 12-14 Feb
2014

WP3 Task 3.2 Federated Access Control

6Deliverables and Milestones:Security Issues need to be addressed
MS3.1: Infrastructure configured toallow access to users and developersof EUBrazilCC (M3)
All application users and systemdevelopers with access to a minimal
part of the infrastructure that allows
them to use it for their needs

MS3.2 Deployment of opportunistic
private cloud (M12)
Prototype able to connect desktops
within a LAN to a private cloud in an
opportunistic way

MS3.3 Deployment of federation
mechanisms (M16)
Prototype able to connect IaaS
providers that share the same API
using the Network of Favours
incentive mechanism
KoM EU Brazil CC 12-14 Feb
2014

D3.1 Adaptation Requirements
for CSGrid Middleware (M6)
D3.2 Infrastructure Assessment
Report (M12)
D3.3 Prototype of the CSGrid
Adaptation Mechanisms (M12)
D3.4 Implementation of theMechanisms to Federate Cloudsand Exploit Shared Resources
Opportunistically (M16)
D3.5 Final Infrastructure
Assessment Report (M24)

WP3 Task 3.2 Federated Access Control7

Initial Steps in Security
Development
Define what to protect
IaaS infrastructure or separate Compute, Storage, Network
Cloud applications
Collaborating user community

Identify/specify used protocols
Cloud management protocols: OCCI, CDMI, OVF
Grid resources access and management: SE, CE , VOMS, SLCP

Legacy security solutions and migration strategy
Grid on clouds vs native cloud solutions
VO based vs Cloud Identity Federation model

Access control models and policy platform/profile
RBAC/ABAC, Identity Federation/Delegation, Security TokenService, Trust establishment and delegation
KoM EU Brazil CC 12-14 Feb
2014

WP3 Task 3.2 Federated Access Control

8Federated Identity and Delegationin Clouds
Existing federated identity schemes can be used to create consistentauthentication between distributed computing resources (specificallycloud infrastructures) and a user/client
VOMS and (X509 Proxy Certificate or SAML VOMS credentials)
Shibboleth (with SAML assertions)
ABFAB and Moonshot project (Federated IdM and Trust Management)
CILogon and InCommon Federation (in US)
OpenID and similar services

Identity Federation in clouds
EGI Identity Federation
OpenStack KeyStone Identity Broker/gatewayAWS Identity and Access Management (IAM)

Traditional approach in clouds requires the Cloud Service Provider (CSP) tobe involved into federation establishment
Need to limit CSP role to an initial Trusted Introducer
Avoid CSP role as (identity) broker or (authorisation) gateway
KoM EU Brazil CC 12-14 Feb
2014

WP3 Task 3.2 Federated Access Control9Federation in Grid and Clouds: Grid
VO vs Cloud Virtual Infrastructure
Grid federates resources and users by creating Virtual
Organisations (VO)
VO membership is maintained by assigning VO membership
attributes to VO resources and members
Resources remain under control of the Grid Resource Centers
Users remain members of their Home Organisations (HO)AuthN happens at HO or Grid portal
To access VO resources, VO members need to obtain VOMS certificate
X.509 Proxy Certificate is used to AuthZ users/jobs at Grid resources

In clouds, both resources and user accounts are
created/provisioned on-demand as virtualised
components/entities
User accounts/identities can be provisioned together withaccess rights to virtual resources
KoM EU Brazil CC 12-14 Feb
2014

WP3 Task 3.2 Federated Access Control

10Cloud Federation – Scaling up anddown
Scalability is one of the main cloud feature
To be considered in the context of hybrid cloud service
model
Cloud burst and outsourcing enterprise services to cloud
Cloud services migration and replication between CSP

Scaling up
Identities provisioning
Populating sessions context

Scaling down
Identity de-provisioning: Credentials revocation?
Sessions invalidation vs restarting

Initiated by provider and by user/customer
KoM EU Brazil CC 12-14 Feb
2014

WP3 Task 3.2 Federated Access Control

11

Discussion how to proceed
Who is involved?
Design and development team cooperation

KoM EU Brazil CC 12-14 Feb
2014

WP3 Task 3.2 Federated Access Control

12Supporting material
Federated Identity and delegation
Approach and tools

Multi-tenant Access Control for Cloud Infrastructure Services
GAAA-TK (Generic AAA Toolkit)
Security context and session management, delegation
Policy and attribute profiles
Policy management and evaluationFederation in clouds and Intercloud Federation Framework (ICFF)
Operational models and components

Intercloud Architecture Framework (ICAF)
Multilayer Cloud Services Model (CSM)
ICCMP, ICFF, ICOMF, ICSF (Intercloud Security Framework)

KoM EU Brazil CC 12-14 Feb
2014

WP3 Task 3.2 Federated Access Control

13

Basic Cloud Federation model – CombinedUser side federation(a) Enterprise
Infrastructure(b) External Users(Open Internet)

User
User2
User
User1

(a) HO or(b) Custmr1
MgntSystem

Management(Ops&Sec)

User
User3
(a) IDP-HO1(b) 3rd PartyIDP

Direct or Dynamic link

Cloud accounts A1.1-3 are provisioned
for each user 1-3 from HO with 2
options
CSP IDP/Broker

CloudProvider A

User side Federation
KoM EU Brazil CC 12-14 Feb
2014

CSP – Customer – User
IDP/Broker

Federation relations

User UserUserXa
Xa.2 Xa.1 .3
IDP-XaCloudCustomer A1(Running Service Xa)

Simple/basic scenario 2: Federating
Home Organisation (HO) and Cloud
Service Provider (CSP) domains
Cloud based services created forexternal users (e.g. website) andmanaged by Customer 1
Involved major actors and roles

Individual accounts with new ID::pswd
Mapped/federated accounts that allows
SSO/login with user HO ID::pswd

Federated accounts may use Cloud
IDP/Broker (e.g. KeyStone) or those
IDP-Xa created for Service Xa
IDP-Xa can be implemented
as instantiated service of the CSP IDPWP3 Task 3.2 Federated Access Control

14

Basic Cloud Federation model – Federating
CSP’s/multi-provider cloud resources
HO1
Admin/Mngnt

User User User
HO1.2HO1.1
HO1.3

Cloud provider sidefederation for resources
sharing
Federation and Trust
relations are establishedbetween CSP’s via Identity
management services, e.g.
Identity Providers (IDP)

IDP-HO1

User side Infrastructure services

User User User
A1.2 A1.1 A1.3

Cloud
Service Xa

Cloud
Provider A
Rsr
Ak2

Rsr
Ak1

IDP-XaMay be bilateral or via 3rdparty/broker service

CSP IDP-A

Rsr
An1

Rsr
Am1

Includes translation orbrokering

Federation&Trust relations

Trust relations
Namespaces
Attributes semantics
Policies

Inter-provider federation for resources sharing
Rsr
Kn1
Rsr K2

Rsr N1
Rsr M1
RsrIDP-K
M2

Cloud
Provider K

Cloud
Provider M

Rsr N2
IDP-M

IDP-N

Cloud
Provider N
WP3 Task 3.2 Federated Access Control

Inter-provider federation istransparent tocustomers/users

Provider side Federation15

Authorisation in a Federated Cloud
Environment••••

KoM EU Brazil CC 12-14 Feb
2014

WP3 Task 3.2 Federated Access Control

PEP (PolicyEnforcement
Point)PDP (PolicyDecision Point)
PAP (PolicyAuthotity Point)
CVS (CredentialsValidationService)

16

GAAA Authorisation Frameworkand GAAA Toolkit (GAAA-TK)

KoM EU Brazil CC 12-14 Feb
2014

WP3 Task 3.2 Federated Access Control

17

GEYSERS project Network+IT IaaS infrastructure
provisioning Security Infrastructure•Logical Infrastructure Composition Layer (LICL)– FUSE ESB env, OSGi bundles– Packages: AuthN/AuhZ and Dynamic Access Control Infra (DACI)•ClientCSSI

Network Control Plane (NCP+)– AuthnSvc&AuthzSvc Web services– SecurityGateway library•CSSI
CSSI/GAAPI
Policy Enforcement PointGAAA Toolkit Java Library provides core functionality–VR service

SecurityGateway Library

GAAA-ISOD profile (Infrastructure Services On Demand )
AuthN

SecurityGateway
AuthnSvc

TokenSvcAuthzSvc

DACIPolicy
Man.

DACITrust

DACIMan.

DACIContext

AAI for LICL (eu.geysers.licl.aai.*)

AuthNSvc

DACS

DACI

GAAA-ISOD Toolkit

AuthZ

TokenSvc

AuthZSvc

TokenSvc

DACS instanceIntegration(via SecurityGateway)

AAI Components
KoM EU Brazil CC 12-14 Feb
2014

WP3 Task 3.2 Federated Access Control

18

Dynamic Access Control Infrastructure (DACI)
Common Security
Service Interface (CSSI)

Consolidate a common
interface to access security
services

SecurityGateway
DACS
instance[i]DACI Management

Authentication Authority

Attr DBSAML-XACML Layer

PIP (AuthzCtx Hdlr)

Obligation
Handler

PDP

PAP

Attribute
Authority

Identity Management
ServiceAuthorization ServiceAuthz-token
SvcAuthz-token
AuthorityAuthz
TokenService

DACI Configuration

DACI Monitoring

DACS
Man.
Service
DACI Policy
Management

DACI Context
Management

DACI TrustManagement

DACS Trust Manager

Provisioned on demand
security services (DACS)DACI: Dynamic Access Control Infrastructure
DACS: Dynamic Access Control Services
KoM EU Brazil CC 12-14 Feb
2014

Update authz-policies upon
reconfiguring Virtual
Infrastructure

WP3 Task 3.2 Federated Access Control

Dynamic Trust
Establishment: DSA,Bootstrapping
19Security Services Reference Model
Common Security
Service Interface(CSSI)Authentication &Identity Man.

Authorization &Policy Man.

Security Context Management
Trust establishment
protocol for VI,
Dynamic Security
Associations (DSA),bootstrapping
protocolTrust Management(Dynamic trust establishment, Bootstrapping)

Security Service Lifecycle
Management (SSLM)

Dynamic AccessControl Infrastructure(DACI)

Common Security Service Layer

SLA Management

Note: Integration with SLA management/negotiationis needed to ensure consistency
KoM EU Brazil CC 12-14 Feb
2014

WP3 Task 3.2 Federated Access Control20

Multi-tenant Access Control
for Cloud Infrastructure Services
Apply MT-AC in hierarchy
A high-level provider is a tenant of the low-level provider
Grant permissions -> Delegate granted permissions
Security context management using tokens as session credentials

Pa domain(1) authz request

ca i(2) grant token

UserPaPa Authz Service(3) grant token

Pbi Authz Service(4) access token

ca i

Pb1

Pb2

Pbk

(5) request | access token
Pbi Resource Service(6)response

Pbi domain

Exchanging tokens in Intercloud

Pc1

Pc2

MT-AC in hierarchy
Amsterdam, May 21, 2014

21

GAAA-TK Implementation for complex
infrastructure provisioning (GEYSERS project)AuthzService

End-users

request response

Authz Interface
LICL interface

Token Authority

Information Model
service

PEP

Obligation Service(e.g. accounting)Context Handler

PDP

TenantMgrSvc
interface (provider)

Token service

Provider’sDelegation
Policy DB

TokenService

Context DB

Tenant’s
Authz Policy
DB

TenantManagement
Service

Context resolution
serviceTenant’sdelegation
policy DB

ContextService

Policy Generator

Tenant DB

TenantAdmin
ServiceTenant administrationinterface (tenant)Amsterdam, May 21, 201422

InterCloud Architecture Framework (ICAF)
Multi-layer Cloud Services Model (CSM)
Combines IaaS, PaaS, SaaS into multi-layer model with inter-layer interfaces
Including interfaces definition between cloud service layers and virtualisation platform

InterCloud Control and Management Plane (ICCMP)
Allows signaling, monitoring, dynamic configuration and synchronisation of the distributed
heterogeneous clouds
Including management interface from applications to network infrastructure and virtualisation
platform

InterCloud Federation Framework (ICFF)
Defines set of protocols and mechanisms to ensure heterogeneous clouds integration atservice and business level
Addresses Identity Federation, federated network access, etc.

InterCloud Operations Framework (ICOF)
RORA model: Resource, Ownership, Role, Action
RORA model provides basis for business processes definition, SLA and access control

Broker and federation operation

Intercloud Security Framework (ICSF)
Dynamic Security Infrastructure provisioning and protocols

KoM EU Brazil CC 12-14 Feb
2014

WP3 Task 3.2 Federated Access Control

23

Multilayer Cloud Services Model (CSM)
http://www.ietf.org/id/draft-khasnabish-cloud-reference-framework-06.txt

Security InfrastructureManagementOperations Support SystemUser/Client Services* Identity services (IDP)* Visualisation

User/Customer Side Functions and Resources

Administration andManagement Functions(Client)

Content/Data Services* Data * Content * Sensor * Device

Functions
1Endpoint* Service Gateway* Portal/Desktop

Inter-cloud Functions* Registry and Discovery* Federation Infrastructure

Federated Access andDelivery Infrastructure (FADI)

SaaS

PaaS

Layer C5
Services
Access/Delivery

Layer C4Cloud Services(Infrastructure,Platforms,Applications,Software)

Cloud Services (Infrastructure, Platform, Application, Software)

IaaS

Layer C6
User/Customer side
Functions

PaaS-IaaS IF
PaaS-IaaS Interface

IaaS – Virtualisation Platform Interface

Cloud ManagementSoftware(Generic Functions)

Cloud Management Platforms
OpenStack

OpenNebula

Virtualisation Platform

KVM

VM

VM

VPN

OtherCMS

XEN

VMwareNetworkVirtualis

Proxy (adaptors/containers) - Component Services and Resources

StorageResources

ComputeResources

Contrl&Mngnt Links
KoM EU Brazil CC 12-14 Feb 2014

Hardware/PhysicalResources

Network
Infrastructure

Layer C3
Virtual Resources
Composition andControl(Orchestration)

CSM layers(C6) User/Customer side
Functions(C5) Intercloud Access andDelivery Infrastructure(C4) Cloud Services(Infrastructure, Platform,Applications)(C3) Virtual Resources
Composition and Orchestration(C2) Virtualisation Layer(C1) Hardware platform anddedicated network
infrastructure

Layer C2
Virtualisation

Layer C1
PhysicalHardware
Platform andNetworkControl/Mngnt Links

Data Links

Data Links

WP3 Task 3.2 Federated Access Control

Slide_24

General use case for infrastructure provisioning:
Workflow => Logical (Cloud) InfrastructureEnterprise/Scientific workflow
Storage
DataSpecial
Proc 1
Data
Filtering

Input
Data

VisualPresentSpecial
Proc 2

Instrum.
Data

Campus A

Data
Archive

Visualisation

Visualisation

CE

User
Group A

Campus B

CE

User
User
User

User
User
User

VR6
VR2

VR7

VR5

Resource/Service
ProviderKoM EU Brazil CC 12-14 Feb
2014

UserGroup B

VR4

VR1

Enterprise/Scientificworkflow
Is mapped
to heterogeneous cloudinfrastructure containing
IaaS, PaaS components

Cloud 2 PaaS

VR3Enterprise/Project basedIntercloud Infrastructure

Cloud 1 IaaS

Resource/ServiceProvider
CNCN
CN

CN
CN

CN

Cloud PaaS Provider

CN
CN

CN

CN
CN

Cloud IaaS Provider

WP3 Task 3.2 Federated Access Control

25

General use case for infrastructure provisioning:
Logical Infrastructure => Network Infrastructure (1)Resource and Cloud Provider Domains
Cloud 1 IaaS

Cloud 2 PaaS

VR5VR7VR3VR1
Campus A
Infrastructure

Campus BInfrastructure

VR2Campus A

VR4VR6

Cloud Carrier Network Infrastructure

Visualisation

Visualisation

CEUserGroup A

Campus B

CEUser
User
User

User
User
User

VR6
VR2

VR7

VR5Resource/
ServiceProvider

KoM EU Brazil CC 12-14 Feb
2014

User
Group B

VR4

VR1

Distributed
Resource/
heterogeneous cloud
ServiceProvider
infrastructure requires
separately provisioned
network infrastructure thatcan be outsourced to Cloud Carrier

Cloud 2 PaaS

VR3Enterprise/Project basedIntercloud Infrastructure

Cloud 1 IaaS

CN

CN
CN

CN
CN

CN

Cloud PaaS Provider

CN
CN

CN

CN
CN

Cloud IaaS Provider

WP3 Task 3.2 Federated Access Control26

General use case for infrastructure provisioning:
Logical Infrastructure => Network Infrastructure (2)Resource and Cloud Provider Domains
VR3VR1VR5

VR7Campus A
Infrastructure

Campus B
Infrastructure

VR2

VR4

Federated InterCloud
infratsructure

Network Provider 1

Campus A

Visualisation

Visualisation

Cloud Carrier or Network Provider 2

CEUserGroup A

VR6CE

User
User
User

User
User
User

VR6
VR2UserGroup B

VR7

VR5

Resource/Service
ProviderKoM EU Brazil CC 12-14 Feb
2014

Cloud 2 PaaS

VR4VR1

Provisioning network
infrastructure may
involve multiple providers
Introducing OCX(Open Cloud eXchange)

Campus B

VR3Enterprise/Project basedIntercloud Infrastructure

Cloud 1 IaaS

Resource/ServiceProvider
CNCN
CN

CN
CN

CN

Cloud PaaS Provider

CNCN

CNCN
CN

Cloud IaaS Provider

WP3 Task 3.2 Federated Access Control27

Intercloud Federation Infrastructure andOpen Cloud eXchange (OCX)
Federated Cloud
Instance Customer A(University A)

OCXServices

Cert Repo(TACAR) TTP Trusted
Introducer

TrustBroker

TrustBroker

BrokerBroker

OCX and federated
network infrastructure

Federated Cloud
Instance Customer B(University B)

Cloud ServiceBroker

DiscoveryDirectory
Directory(RepoSLA)(RepoSLA)FedIDP

GatewayGateway

Gateway

Gateway

AAA

AAA

AAA

AAA(I/P/S)aaS
Provider(I/P/S)aaS
Provider(I/P/S)aaS
Provider

IDP

IDP

IDP

KoM EU Brazil CC 12-14 Feb
2014…

WP3 Task 3.2 Federated Access Control(I/P/S)aaS
ProviderIDP

28

OCX Hierarchical Topology Model
GEANT

CSP

NREN

University

Visualisation

VR6CE

VR7OCX

VR4User
User
User

VR5
VR3DFlow
IP/L3
L2

Visualisation

VR6CE

VR7

L1

OCX

VR4User
User
User

VR5

L0

VR3KoM EU Brazil CC 12-14 Feb
2014

WP3 Task 3.2 Federated Access Control

29