Federated Access Control in HeterogeneousIntercloud Environment:
Basic Models and Architecture Patterns

Craig Lee, The Aerospace Corporation
On behalf ofYuri Demchenko, Craig Lee, Canh Ngo, Cees de Laat
Intercloud2014 Workshop
11 March 2014, Boston

Outline• Background to this work
• Federation in Grid and Clouds• InterCloud Federation Framework (ICFF) and federation infrastructure
patterns• Federated Access Control and Federated Identity Management in clouds• Additional information– VO based federations in Grid (retrospective view)

Intercloud2014

Cloud Federated Access Control Patterns

Slide_2

Background to this work• Cloud Federation BoF at OGF and follow on– As the main motivation motivated work of current author teamwith wide consultation with Grid and Cloud community• Research at the University of Amsterdam on developingof the Intercloud Architecture Framework (ICAF)– Where the Intercloud Federation Framework is defined as acomponent for multi-provider infrastructure integration• EGI (European Grid Initiative) Federated Cloud TaskForce– Building Federated Cloud model based on Grid VO based
federation modelIntercloud2014

Cloud Federated Access Control Patterns

3Federation in Grid and Clouds: Grid VO vs Cloud
Virtual Infrastructure• Grid federates resources and users by creating VirtualOrganisations (VO)
– VO membership is maintained by assigning VO membership
attributes to VO resources and members– Resources remain under control of the resource ownerorganisation Grid Centers– Users remain members of their Home Organisations (HO)• AuthN takes place at HO or Grid portal• To access VO resources, VO members need to obtain VOMS
certificate or VOMS credentials• In clouds, both resources and user accounts arecreated/provisioned on-demand as virtualised
components/entities– User accounts/identities can be provisioned together withaccess rights to virtual resources
Intercloud2014

Cloud Federated Access Control Patterns

4Cloud Federation: Actors and Roles• Cloud Service Provider (CSP)• Cloud Customer (organisational)– Multitenancy is provided by virtualisation of cloud
resources provided to all/multiple customers• Cloud User (end user)• Cloud (Service) Broker• Identity Provider (IDP)• Cloud Carrier• Cloud Service Operator• Cloud Auditor
Intercloud2014

Cloud Federated Access Control Patterns

5Cloud Federation – Scaling up and down
• 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 deprovisioning: Credentials revocation?
– Sessions invalidation vs restarting• Initiated by provider and by user/customer
Intercloud2014

Cloud Federated Access Control Patterns

6Cloud Federation Models – Identified models
User/customer side federation• (1.1) Federating users/HO and CSP/cloud domains– Customer doesn’t have own IDP (IDP-HO)– Cloud Provider’s IDP is used (IDP-CSP)• (1.2) Federating HO and CSP domains– Customer has own IDP-HO1– It needs to federate with IDP-CSP, i.e. have ability to use HO
identities at CSP services• (1.3) Using 3rd party IDP for external users– Example: Web server is run on cloud and external user are registeredfor services

Provider (resources) side federation• (2.1) Federating CSP’s/multi-provider cloud resources– Used to outsource and share resources between CSP– Typical for community clouds
Intercloud2014

Cloud Federated Access Control Patterns

7Basic Cloud Federation model (1.1) – Federating
users/HO and CSP/cloud domains (no IDP-HO)

HO1
Admin/Mngnt
SystemUser UserUser
HO1.1
HO1.2
HO1.3

Customer HomeOrganisation(Infrastructure services)••

IDP-HO•Management(Ops&Sec)

Federation relations

IDP-XaCloudCustomer A1(Running Service Xa)––•

User UserUser
A1.2 A1.1A1.3
CSP
IDP/Broker

CloudProvider A•Intercloud2014

IDP-Xa is a virtualised
service of the CSP IDP

CSP – Customer – User
IDP/Broker

Cloud accounts A1.1-3 areprovisioned for each user 1-3 fromHO with 2 options––•
User side Federation

Simple/basic scenario 1: Federating
Home Organisation (HO) and Cloud
Service Provider (CSP) domains
Cloud based services created forusers from HO1 and managed by
HO1 Admin/Management system
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 thosecreated for Service Xa
TODO: Extend with AuthN/AutnZ
service in Virtual ServiceEnvironment

Cloud Federated Access Control Patterns8Basic Cloud Federation model (1.2) – Federating
HO and CSP domains (IDP-HO1 and IDP-CSP)

HO1Admin/Mngnt
SystemUser UserUser
HO1.1
HO1.2
HO1.3

Customer Home
Organisation(Infrastructure services)••

IDP-HO1•Management(Ops&Sec)

Federation relations

IDP-XaCloudCustomer A1(Running Service Xa)––•

User UserUser
A1.2 A1.1A1.3
CSP
IDP/Broker

CloudProvider A•

Intercloud2014

IDP-Xa can be implemented
as instantiated service of the CSP IDP

CSP – Customer – User
IDP/Broker

Cloud accounts A1.1-3 areprovisioned for each user 1-3 fromHO with 2 options––•
User side Federation

Simple/basic scenario 1: Federating
Home Organisation (HO) and Cloud
Service Provider (CSP) domains
Cloud based services created forusers from HO1 and managed by
HO1 Admin/Management system
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 thosecreated for Service Xa
TODO: Extend with AuthN/AutnZ
service in Virtual ServiceEnvironment

Cloud Federated Access Control Patterns9Basic Cloud Federation model (1.3) – Using 3rdparty IDP for external users
External Users(Open Internet)
UserUser2

User
User3
User
User1

Customer 1
Admin/MngntSystem•

Ext/3rdParty
IDP-HO1

Direct or Dynamic link
Federation relations

Management(Ops&Sec)•––User User
UserX
Xa.1
Xa.2
a.3
IDP-XaCloud
Customer A1(Running Service Xa)••
CSP
IDP/Broker•

Intercloud2014

CSP – Customer – User
IDP/Broker

Cloud accounts A1.1-3 areprovisioned for each user 1-3 fromHO with 2 options––Cloud
Provider A

User side Federation

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 IDP
Cloud Federated Access Control Patterns10Basic Cloud Federation model – Combined Userside federation(a) Enterprise
Infrastructure(b) External Users(Open Internet)

UserUser2

Management(Ops&Sec)

User
User3
UserUser1(a) HO or(b) Custmr1
MgntSystem(a) IDP-HO1(b) 3rd Party
IDP••

Direct or Dynamic link

IDP-XaCloud
Customer A1(Running Service Xa)•CSP
IDP/Broker

Cloud
Provider A

User side Federation

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––Federation relations

User UserUserX
Xa.2 Xa.1 a.3

Intercloud2014•Cloud accounts A1.1-3 areprovisioned for each user 1-3 fromHO with 2 options––•

CSP – Customer – User
IDP/Broker

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 IDP
Cloud Federated Access Control Patterns

11Basic Cloud Federation model (2.1) – Federating
CSP’s/multi-provider cloud resources
HO1
Admin/Mngnt•

User UserUser
HO1.1
HO1.2
HO1.3

IDP-HO1•

User side Infrastructure services

User UserUser
A1.2 A1.1A1.3

Cloud
Service Xa

Cloud
Provider A
Rsr
Ak2

IDP-Xa

CSP
IDP-A

–

Federation&Trust relations
Rsr
Ak1

•Rsr
An1

Rsr
Am1

Rsr
K2

Rsr
IDP-K
M2

Cloud
Provider K
Intercloud2014

Rsr
N1

Rsr
M1

Cloud
Provider M

IDP-M

Rsr
N2

•
IDP-N

Cloud
Provider N

Cloud Federated Access Control Patterns

May be bilateral or via 3rdparty/broker service

Includes translation or
brokering––––Inter-provider federation for resources sharing
Rsr
Kn1

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

Trust relations
Namespaces
Attributes semantics
Policies

Inter-provider federationis transparent tocustomers/users

Provider side Federation12

(a) Enterprise
Infrastructure
User
User2
User
User1

(a) HO or(b) Custmr1
MgntSystem

Management(Ops&Sec)

CloudProvider A

Cloud Federation
Model - Combined(b) External Users(Open Internet)
User
User3(a) IDP-HO1(b) 3rd Party
IDP

Direct or Dynamic link

Federation relations
Instantiated
IDP-A => IDP-Xa

UserUserUser
Xa.2Xa.1Xa.3
IDPCloud
Xa
Service Xa

Rsr
Ak2 Rsr
Ak1

Rsr
Am1

Rsr
An1

User sidefederation
CSP
IDP-A
Federation &Trust relations

Provider sidefederation

Inter-provider federation for resources sharing
Rsr
Kn1

Rsr
K2

Cloud
Provider K

Intercloud2014

Rsr
IDP-K
M2

Rsr
N1

Rsr
M1

Cloud
Provider M

IDP-M

Rsr
N2

IDP-N
Cloud
Provider N

Cloud Federated Access Control Patterns

13Basic AuthN and AuthZ services using Federated
IDPs – For additional Credentials validation
2 AuthN & Attrs methods:
Push: Attrs obtained by UserPull: Attrs fetched by AuthN

IDP-Fed*IDP-Fed*UserRequester

IDP0Identity Attrs
ID Creds & Attrs

Creds/Attrs Validation
with Federated IDP*
Creds/Attrs Validation
with User Home IDP0AuthN
AuthN Tok/Assert &ID Attrs

CVS
AuthZ Attrs

PEP - Policy Enforcement Point
PDP/ADF - Policy Decision Point
IDP – Identity Provider
PAP - Policy Authority Point
CtxHandler - Context Handler
CVS – Credentials Validation
ServiceIntercloud2014

PDP

CtxHandler

PolicyPAP(Policy)

PEP

Collection and Validating
AuthZ Attrs
Policy Management

Cloud Federated Access Control Patterns

Resource
Resource Attrs

14

Basic AuthN and AuthZ services using Federated
IDPs – Federation/Trust domains
Admin/Security
Domain 0(User HO)

Admin/Security
Domain1 Service

Federated
IDPs

User

IDP-FedHO

Identity Attrs

IDP-Fed*Serv/Requester

IDP0

User/Req Attrs
ID Creds & Attrs
Creds/Attrs Validation
with Federated IDP-HO

Creds/Attrs Validation
with User Home IDP0AuthN
AuthN Token/Assert& ID Attrs

CVS
AuthZ Attrs

PDP

PolicyResource
Domain R

Intercloud2014

PAP(Policy)

CtxHandler

PEP

Collection and Validating
AuthZ Attrs
Policy Management

Cloud Federated Access Control Patterns

Resource
Resource Attrs

15Implementation: Intercloud Federation Infrastructure
and Open Cloud eXchange (OCX)
Federated Cloud
Instance Customer A(University A)

OCXServices

TrustBroker

TrustBroker

BrokerCert Repo(TACAR) TTP Trusted
Introducer

Broker

OCX and federated
network infrastructure

CloudServiceBroker

FedIDPIntercloud2014

Federated Cloud
Instance Customer B(University B)

Discovery
Directory

Directory(RepoSLA)(RepoSLA)

Gateway

Gateway

Gateway

Gateway

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

IDP

IDP

IDP

…

Cloud Federated Access Control Patterns

GEANT
TransEuropean
infrastructure(I/P/S)aaS
ProviderIDP

16

Summary and Future work
• The proposed Intercloud Federation Framework is apart of the general Intercloud Architecture
Framework and intends to provide a basis for further
API and protocols definition• It is based on wide discussion among OGF, EGI andcloud security community• Currently the proposed approach and model arebeing implemented as a part of the GEANT
infrastructure to support Intercloud services delivery
to member universities
Intercloud2014

Cloud Federated Access Control Patterns

17Discussion and Questions

Intercloud2014

Cloud Federated Access Control Patterns

18

Reference information and diagrams• VO based Grid federation model• AuthN and AuthZ services operation

Intercloud2014

Cloud Federated Access Control Patterns

19

VO based Grid federation modelIntercloud2014

Cloud Federated Access Control Patterns

20VO2007: VO in Collaborative applications and Complex
Resource Provisioning– Two basic use cases considered• Grid based Collaborative applications/environment (GCE) built using
Grid middleware and integrated into existing Grid infrastructure• Complex resource provisioning like Optical Lightpath provisioning(OLPP), or bandwidth-on-demand (BoD)– VO based functionality (and requirements) to support dynamicsecurity associations• Dynamic Trust management– Establishing dynamic trust management relations between VO members• Attribute and metadata resolution and mapping– VO-based access control service requires common VO-wide attributes
that however can be mapped to the original ones

• Policy combination and aggregation– To allow conflict resolution and policy harmonisation between VOmembers• Flexible/distributed VO management infrastructureIntercloud2014

Cloud Federated Access Control Patterns

Slide_21

VO2007: VO bridging inter-organisational barriers
VO users and services

Service xa

Service xd

User x1

Service xe
User x2
Service xb
User x5
User x4

Virtual Organisation X
User a1
User A2

Service Ab

User A1

User a1Service BbBarrier
User a1Service Bc

User A3
Service Ac
Organisation A•

Organisation BService Ba

Service Aa

VO allows bridging inter-organisational barriers without changing local policies– Requires VO Agreement and VO Security policy– VO dynamics depends on implementation but all current implementations are rather
staticIntercloud2014

Cloud Federated Access Control Patterns

Slide_22

Example VO Security services operation
VO Context(VO ID/name)
Requestor
Service xa(1a)Resource
Service xd

Basic VOMS
functionality
in Grid

(3)

(2)

(4)
Identity
Provider (2a)(1b)
Authentication
Service

Attribute
Authority (4b)Authorisation
Service

Clouds provide fullresources and infrastructureservices virtualisation

VO Mngnt
PolicyAuthority

UserDB

(4a)
Trust
Mngnt

Trust

Virtual Organisation X
AuthN

AuthN

IP/STS

AttrA

IP/STS

AuthZ

Directory
TrustPolicy

AttrAAuthZ

Factory

Factory
Directory

Logging
Accounting

Trust

VOMS*

Trust
PolicyLogAccLogAccOrganisation B
Organisation AIntercloud2014

Cloud Federated Access Control Patterns

Slide_23

VO2007: VOMS – standard-de-facto for VOmanagement• VO Membership Service (VOMS) is a standard-de-facto
for VO management and VO-based authorisation in Grid
– VO is represented as a complex, hierarchical structure withgroups and subgroups• Subgroup management may be delegated to different administrators– Every user in a VO is characterised by the set of attributes• Group/subgroup membership, roles and capabilities – so-called 3tuples• Combination of all 3-tuples for the user is expressed as a Fully
Qualified Attribute Name (FQAN)• FQAN is included into VOMS X.509 Attribute Certificate (AC)– VOMS infrastructure• May contain multiple VOMS serves and synchronised VODB’s• Supports user calls for VOMS AC’s and VOMS admin tasks– VOM Registration is developed by Open Science Grid (OSG)
project to support users self-registration
Intercloud2014

Cloud Federated Access Control Patterns

Slide_24

VO2007: Dynamic Security Associations– Session – establishes security context in the form of session key thatcan be a security token or simple UID bound to secure credential/context• Session may associate/federate users, resources and actions/processes– Job/workflow – more long-lived association and may include few
sessions• May need to associate more distributed collection of users and resources forlonger time required to deliver a final product or service• Job and workflow may contain decision points that switch alternativeflows/processes• Security context may change during workflow execution or Job lifetime• Job description may contain both user and resource lists and also provide
security policy and trust anchor(s) (TA)– Project or mission oriented cooperation – established for longer timecooperation (involving people and resources) to conduct some activity• This is actually the area of currently existing VO associations– Inter-organisational association or federation – established for longterm cooperation, may have a wide scope of cooperative areas• This is the area of inter-university associations– Shibboleth Attribute Authority Services (SAAS) is designed for this kind offederations
Intercloud2014

Cloud Federated Access Control Patterns

Slide_25

VO2007: Conceptual VO Operational Models– User-centric VO (VO-U) - manages user federation andprovide attribute assertions on user (client) request– Resource/Provider centric VO (VO-R) - supports
provider federation and allows SSO/access control
decision sharing between resource providers– Agent centric VO (VO-A) - provides a context for interdomain agents operation, that process a request on
behalf of the user and provide required trust context tointeraction with the resource or service– Project centric VO (VO-G) - combines User centric andProvider centric features what actually corresponds tocurrent VO use in Grid projects
Intercloud2014

Cloud Federated Access Control Patterns

Slide_26

VO2007: Conceptual VO Management
Framework– VO establishes own virtual administrative and security
domains• It may be separate or simply bridge VO-member domains– VO management service should provide the following
functionalities• Registration and association of users and groups with the VO• Management of user attributes (groups, roles, capabilities)• Association of services with the VO• Association of policies with the VO and its component services– VO Registry service for wider VO implementation may berequired• VO naming should provide uniqueness for the VO names

Intercloud2014

Cloud Federated Access Control Patterns

Slide_27

VO2007: VO Security Services– VO as a component of the Security infrastructure should
provide the following security services• Policy Authorities (e.g. GPBox)• Trust management service (GridPMA)• Identity Management Service (by HO)• Attribute Authorities (VOMS)• Authorization service (CAS)• Authentication service• Logging, Accounting

Intercloud2014

Cloud Federated Access Control Patterns

Slide_28