Federated Access Control in Heterogeneous
Intercloud Environment:
Basic Models and Architecture Patterns
Craig Lee, The Aerospace Corporation
On behalf of
Yuri 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 team
with wide consultation with Grid and Cloud community
• Research at the University of Amsterdam on developing
of the Intercloud Architecture Framework (ICAF)
– Where the Intercloud Federation Framework is defined as a
component for multi-provider infrastructure integration
• EGI (European Grid Initiative) Federated Cloud Task
Force
– Building Federated Cloud model based on Grid VO based
federation model
Intercloud2014 Cloud Federated Access Control Patterns 3
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 resource owner organisation 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 are created/provisioned on-demand as virtualisedcomponents/entities– User accounts/identities can be provisioned together with
access 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 registered
for 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)
• Simple/basic scenario 1: Federating Home Organisation (HO) and Cloud Service Provider (CSP) domains
• Cloud based services created for users from HO1 and managed by HO1 Admin/Management system
• Involved major actors and roles– CSP – Customer – User
– IDP/Broker
• Cloud accounts A1.1-3 are provisioned for each user 1-3 from HO with 2 options
– 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 created for Service Xa
• TODO: Extend with AuthN/AutnZservice in Virtual Service Environment
Intercloud2014 Cloud Federated Access Control Patterns 8
Customer Home
Organisation
(Infrastructure services)
Cloud
Customer A1
(Running Service Xa)
Management
(Ops&Sec)
IDP-HO
Cloud
Provider A
CSP
IDP/
Broker
HO1
Admin/Mngnt
System
User
HO1.2User
HO1.3
User
HO1.1
User
A1.2User
A1.3
User
A1.1
IDP-Xa
Federation relations
User side Federation IDP-Xa is a virtualised
service of the CSP IDP
Basic Cloud Federation model (1.2) – Federating
HO and CSP domains (IDP-HO1 and IDP-CSP)
• Simple/basic scenario 1: Federating Home Organisation (HO) and Cloud Service Provider (CSP) domains
• Cloud based services created for users from HO1 and managed by HO1 Admin/Management system
• Involved major actors and roles– CSP – Customer – User
– IDP/Broker
• Cloud accounts A1.1-3 are provisioned for each user 1-3 from HO with 2 options
– 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 created for Service Xa
• TODO: Extend with AuthN/AutnZservice in Virtual Service Environment
Intercloud2014 Cloud Federated Access Control Patterns 9
Customer Home
Organisation
(Infrastructure services)
Cloud
Customer A1
(Running Service Xa)
Management
(Ops&Sec)
IDP-HO1
Cloud
Provider A
CSP
IDP/
Broker
HO1
Admin/Mngnt
System
User
HO1.2User
HO1.3
User
HO1.1
User
A1.2User
A1.3
User
A1.1
IDP-Xa
Federation relations
User side FederationIDP-Xa can be implemented
as instantiated service of the CSP IDP
Basic Cloud Federation model (1.3) – Using 3rd
party IDP for external users
• Simple/basic scenario 2: Federating
Home Organisation (HO) and Cloud
Service Provider (CSP) domains
• Cloud based services created for
external users (e.g. website) and
managed by Customer 1
• Involved major actors and roles– CSP – Customer – User
– IDP/Broker
• Cloud accounts A1.1-3 are
provisioned for each user 1-3 from
HO with 2 options– 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
Intercloud2014 Cloud Federated Access Control Patterns 10
User side FederationIDP-Xa can be implemented
as instantiated service of the CSP IDP
External Users
(Open Internet)
Cloud
Customer A1
(Running Service Xa)
Management
(Ops&Sec)
Ext/3rdParty
IDP-HO1
Cloud
Provider A
CSP
IDP/
Broker
Customer 1
Admin/Mngnt
System
User
Xa.2UserX
a.3
User
Xa.1
IDP-Xa
Federation relations
Direct or Dynamic link
User
User2User
User3
User
User1
Basic Cloud Federation model – Combined User
side federation
• Simple/basic scenario 2: Federating
Home Organisation (HO) and Cloud
Service Provider (CSP) domains
• Cloud based services created for
external users (e.g. website) and
managed by Customer 1
• Involved major actors and roles– CSP – Customer – User
– IDP/Broker
• Cloud accounts A1.1-3 are
provisioned for each user 1-3 from
HO with 2 options– 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
Intercloud2014 Cloud Federated Access Control Patterns 11
Cloud
Customer A1
(Running Service Xa)
Cloud
Provider A
CSP
IDP/
Broker
User
Xa.2UserX
a.3
User
Xa.1
IDP-Xa
User side FederationIDP-Xa can be implemented
as instantiated service of the CSP IDP
(b) External Users
(Open Internet)
Management
(Ops&Sec)
(a) IDP-HO1
(b) 3rd Party
IDP
(a) HO or
(b) Custmr1
MgntSystem
Federation relationsDirect or Dynamic link
User
User2User
User3
User
User1
(a) Enterprise
Infrastructure
Basic Cloud Federation model (2.1) – Federating
CSP’s/multi-provider cloud resources
• Cloud provider side
federation for resources
sharing
• Federation and Trust
relations are established
between CSP’s via
Identity management
services, e.g. Identity
Providers (IDP)– May be bilateral or via 3rd
party/broker service
• Includes translation or
brokering – Trust relations
– Namespaces
– Attributes semantics
– Policies
• Inter-provider federation
is transparent to
customers/users
12Provider side Federation
Cloud
Provider M
Cloud
Service Xa
IDP-HO1
Cloud
Provider ACSP
IDP-A
HO1
Admin/MngntUser
HO1.2User
HO1.3
User
HO1.1
User
A1.2User
A1.3
User
A1.1
IDP-Xa
User side Infrastructure services
Cloud
Provider N
Rsr
M2
Rsr
M1
IDP-M
Rsr
N2
Rsr
N1
IDP-N
Cloud
Provider K
Rsr
K2
Rsr
Kn1
IDP-K
Rsr
Ak2 Rsr
Ak1Rsr
Am1
Inter-provider federation for resources sharing
Federation&Trust relationsRsr
An1
Intercloud2014 Cloud Federated Access Control Patterns
13
User side
federation
(b) External Users
(Open Internet)
(a) IDP-HO1
(b) 3rd Party
IDP
(a) HO or
(b) Custmr1
MgntSystem
User
User2User
User3
User
User1
(a) Enterprise
Infrastructure
Cloud
Provider M
Cloud
Service XaCloud
Provider A
Cloud
Provider N
Rsr
M2
Rsr
M1
IDP-M
Rsr
N2
Rsr
N1
IDP-N
Cloud
Provider K
Rsr
K2
Rsr
Kn1
IDP-K
Rsr
Ak2 Rsr
Ak1Rsr
Am1
Inter-provider federation for resources sharing
Federation &
Trust relations
Rsr
An1
Management
(Ops&Sec)
Direct or Dynamic linkFederation relations
CSP
IDP-A
IDP-
Xa
User
Xa.2User
Xa.3
User
Xa.1
Provider side
federation
Instantiated
IDP-A => IDP-Xa
Intercloud2014 Cloud Federated Access Control Patterns
Cloud Federation
Model - Combined
Basic AuthN and AuthZ services using Federated
IDPs – For additional Credentials validation
IDP-Fed*IDP-Fed*
UserRequester
Policy Management
Identity Attrs
Resource
Resource Attrs
AuthN
PEPPDP
PAP
(Policy)
2 AuthN & Attrs methods:
Push: Attrs obtained by User
Pull: Attrs fetched by AuthN
CVS
CtxHandler
Creds/Attrs Validation
with User Home IDP0
ID Creds & Attrs
AuthN Tok/Assert &
ID Attrs
Policy
Collection and Validating
AuthZ Attrs
AuthZ Attrs
IDP0
Creds/Attrs Validation
with Federated IDP*
Intercloud2014 Cloud Federated Access Control Patterns 14
PEP - Policy Enforcement Point
PDP/ADF - Policy Decision Point
IDP – Identity Provider
PAP - Policy Authority Point
CtxHandler - Context Handler
CVS – Credentials Validation
Service
Basic AuthN and AuthZ services using Federated
IDPs – Federation/Trust domains
IDP-Fed*
IDP-Fed
HO
Policy Management
Serv/Requester
User/Req Attrs
Resource
Resource Attrs
AuthN
PEPPDP
PAP
(Policy)
CVS
CtxHandler
Creds/Attrs Validation
with User Home IDP0
ID Creds & Attrs
AuthN Token/Assert
& ID Attrs
PolicyCollection and Validating
AuthZ Attrs
AuthZ Attrs
IDP0
Creds/Attrs Validation
with Federated IDP-HO
User
Identity Attrs
Federated
IDPs
Admin/Security
Domain 0
(User HO)
Admin/Security
Domain1 Service
Resource
Domain R
Intercloud2014 Cloud Federated Access Control Patterns 15
Implementation: Intercloud Federation Infrastructure
and Open Cloud eXchange (OCX)
Intercloud2014 Cloud Federated Access Control Patterns 16
Broker
Trust Broker
(I/P/S)aaS
Provider
AAA
Gateway
IDP
Broker
Trust Broker
(I/P/S)aaS
Provider
AAA
Gateway
IDP
(I/P/S)aaS
Provider
AAA
Gateway
IDP
(I/P/S)aaS
Provider
AAA
Gateway
IDP
FedIDP
OCX
Services
…
Directory(RepoSLA)
Directory(RepoSLA)
DiscoveryOCX and federated
network infrastructure
Cloud Service Broker
Cert Repo(TACAR) TTP Trusted
Introducer
Federated Cloud
Instance Customer A
(University A)
Federated Cloud
Instance Customer B
(University B) GEANT
Trans-
European
infrastructure
Summary and Future work
• The proposed Intercloud Federation Framework is a
part 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 and
cloud security community
• Currently the proposed approach and model are
being 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 model
Intercloud2014 Cloud Federated Access Control Patterns 20
Intercloud2014 Cloud Federated Access Control Patterns Slide_21
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 dynamic security 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 VO members
• Flexible/distributed VO management infrastructure
Intercloud2014 Cloud Federated Access Control Patterns Slide_22
VO2007: VO bridging inter-organisational barriers
• 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 static
User x1
User x2
Service xa
Virtual Organisation X
Service xb
Service xd
Service xe
User x5
User x4
VO users and services
Barrier
Organisation A
Service Ac User A3
User a1
Service Aa
Service Ba
Service Bc
Organisation B
User A1 User A2 Service Ab
User a1 User a1
User x4
User x5
Service Bb
Virtual Organisation X
Intercloud2014 Cloud Federated Access Control Patterns Slide_23
Example VO Security services operation
Tru
st
Virtual Organisation X
Authentication Service
VO Mngnt
Attribute Authority
Identity Provider
Policy Authority
Authorisation Service
Logging Accounting
Trust Mngnt VOMS*
Factory
AuthN AuthZ AttrA
Trust Directory
Policy
Organisation A
IP/STS
LogAcc
Requestor Service xa
Resource Service xd
Factory
AuthN AuthZ AttrA
Trust Directory
Policy
Organisation B
IP/STS
LogAcc
VO Context (VO ID/name)
(1a)
(4b) (2a)
(3) (2)
(4)
(4a)
Tru
st
UserDB
(1b)
Basic VOMS
functionality
in Grid
Clouds provide full
resources and infrastructure
services virtualisation
Intercloud2014 Cloud Federated Access Control Patterns Slide_24
VO2007: VOMS – standard-de-facto for VO
management
• 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 with
groups 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 3-
tuples
• 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_25
VO2007: Dynamic Security Associations
– Session – establishes security context in the form of session key that can 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 for longer time required to deliver a final product or service
• Job and workflow may contain decision points that switch alternative flows/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 time cooperation (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 long-term 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 of
federations
Intercloud2014 Cloud Federated Access Control Patterns Slide_26
VO2007: Conceptual VO Operational Models
– User-centric VO (VO-U) - manages user federation and
provide 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 inter-
domain agents operation, that process a request on
behalf of the user and provide required trust context to
interaction with the resource or service
– Project centric VO (VO-G) - combines User centric and
Provider centric features what actually corresponds to
current VO use in Grid projects
Intercloud2014 Cloud Federated Access Control Patterns Slide_27
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 be
required
• VO naming should provide uniqueness for the VO names
Intercloud2014 Cloud Federated Access Control Patterns Slide_28
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