Security Services Lifecycle Management
in
On-Demand Infrastructure Services Provisioning
Yuri Demchenko
System and Network Engineering Group
University of Amsterdam
CPSRT 2010 Workshop
2 December 2010
CloudCom2010 Conference
30 October - 3 December 2010, Indianapolis
Outline
• Background for this research
• On-Demand Infrastructure Services Provisioning and Composable
Services Architecture (CSA)

CSA Service Delivery Framework and Services Lifecycle Management
• Proposed Security Services Lifecycle Management and related security
mechanisms
• Implementation – GAAA Toolkit and Security sessions management
• Summary and Discussion
CPSRT2010 Workshop, 2 December 2010
Security Services Lifecycle Management
Slide_2
Background to this research
• Current projects

GEANT3 JRA3 Composable Services
– European NREN infrastructure

GEYSERS – On-demand Optical + IT infrastructure resources provisioning
– Wide participation from large European network (Telefonika, Alcatel-Lucent,
Interoute) and application providers (SAP)
• Past projects
EGEE Grid Security middleware – gLite Java Authorisation Framework
 Phosphorus project Security architecture for multi-domain Network Resource
Provisioning

– GAAA-NRP and XACML-NRP profile
– Multidomain Network Resource Provisioning (NRP) model and workflow
CPSRT2010 Workshop, 2 December 2010
Security Services Lifecycle Management
Slide_3
Use Case – e-Science infrastructure
Control &
Monitoring
User A
Grid
Center
Grid
Storage T1
Initial effort to build –
estimated 2 Yrs
Outsource to current telco
provider – approx. 2
months
Grid
Center
Grid
Storage T1
Target with new business
model – 2 hrs
Instrument
(Manufactoring)
Grid
Storage T0
Visualisation
User K
User P
Visualisation
Computing
Cloud
Cloud
Storage
Permanent link
High Speed link provisioned on demand
Link provisioned on-demand
Components of the typical e-Science infrastructure involving multidomain and multi-tier Grid
and Cloud resources and network infrastructure
CPSRT2010 Workshop, 2 December 2010
Security Services Lifecycle Management
Slide_4
Use Case – e-Science infrastructure
Control &
Monitoring
User A
Instrument
(Manufactoring)
Grid
Storage T0
Grid
Center
Grid
Storage T1
Grid
Center
Grid
Storage T1
Visualisation
User K
User P
Visualisation
Computing
Cloud
Cloud
Storage
Permanent link
High Speed link provisioned on demand
Link provisioned on-demand
On-demand infrastructure
services provisioning
environment
• Security along the whole
provisioning process and
service/infrastructure
lifecycle
• Manageable/user
controlled security
• Securing remote
executing environment
• Security context/session
management
Components of the typical e-Science infrastructure involving multidomain and multi-tier Grid
and Cloud resources and network infrastructure
CPSRT2010 Workshop, 2 December 2010
Security Services Lifecycle Management
Slide_5
GEYSERS Reference Model for Infrastructure
Virtualisation
Roles:
•
•
•
CPSRT2010 Workshop, 2 December 2010
Security Services Lifecycle Management
VIO – Virtual
Infrastructure
Operator
VIP - Virtual
Infrastructure
Provider
PIP - Physical
Infrastructure
Provider
Slide_6
Security Service Lifecycle Management
in On-Demand Resources/Services Provisioning
• On-Demand Infrastructure Services Provisioning requires definition of
Services Lifecycle Management


Multidomain multi-provider environment
Includes standard virtualisation procedures and mechanisms
• Requires dynamic creation of Security/Trust Federations in multi-domain
environment

Based on available Trust Anchors
– Physical Resources (hosting platforms)
– SLA or SLA negotiators/contractors
– All other security context/credentials/keys should be derived from them
• Access control infrastructure dynamically created and policy/attributes
dynamically configured

Access/authorisation session/context management
• Composable Services Architecture (CSA) as a platform for dynamically
configurable composable services provisioning
CPSRT2010 Workshop, 2 December 2010
Security Services Lifecycle Management
Slide_7
Composable Services Architecture
User
Client
Applications and User Terminals
Virtual Infrastructure/Resources level
Proxy (adaptors/containers) – Composed/Virtualised Services and Resources
Control &
Management
Plane
Composition
Layer/Serv
Composable Services Middleware
(GEMBus)
(Reservation
SLA
Negotiatn)
(Operation,
Orchestration)
MD SLC
Registry Logging
Composable Services
lifecycle/provisioning
stages
(1) Request
(2) Composition/ Reservation
(3) Deployment
(4) Operation
(5) Decommissioning
Security
Separation of Data
Plane, Control Plane,
Management Plane
Logical Abstraction Layer for Component
Services and Resources
Proxy (adaptors/containers) - Component Services and Resources
Storage
Resources
Compute
Resources
Network Infrastructure
Component Services & Resources – Physical Resources level
CPSRT2010 Workshop, 2 December 2010
Security Services Lifecycle Management
Control/
Mngnt Links
Data Links
Slide_8
CSA Services Delivery Framework (SDF)
Composable Services Provisioning Workflow
Main stages/phases
Service Request/
SLA Negotiation
•
•
Composition/
Reservation
Re-Compo
sition
•
Service
Lifecycle
Metadata
Service
(SL MD)
Deployment
•
•
Additional stages
•
Registr&Synchro
Recovery/
Migration
Operation
(Monitoring)
Decommissioning
Service Request (including SLA
negotiation)
Composition/Reservation (aka
design)
Deployment, including
Reqistration/Synchronisation
Operation (including Monitoring)
Decommissioning
•
Provisiong
Session
Managnt
Re-Composition should address
incremental infrastructure changes
Recovery/Migration can use SL-MD
to initiate resources resynchronisation but may require recomposition
The whole workflow is supported by the
Service Lifecycle Metadata Service
(SL MD)
Based on the TMF SDF
CPSRT2010 Workshop, 2 December 2010
Security Services Lifecycle Management
Slide_9
TMF Service Delivery Framework (SDF)
Goal: Automation of the whole service delivery and operation process
(TMF SDF, http://www.tmforum.org/ServiceDeliveryFramework/4664/home.html)
End-to-end service management in a multi-service providers environment
End-to-end service management in a composite, hosted and/or syndicated
service environment
Management functions to support a highly distributed service environment,
for example unified or federated security, user profile management,
charging etc.
Any other scenario that pertains to a given phase of the service lifecycle
challenges, such as on-boarding, provisioning, or service creation
CPSRT2010 Workshop, 2 December 2010
Security Services Lifecycle Management
Slide_10
SDF Reference Architecture (refactored from SDF)
Design
16
SDF Service Design
Management (ISS)
Deploy
SDF Service
Repository (ISS)
9
10
SDF Service
Lifecycle Metadata
Repository (ISS)
17
11
SDF Service Lifecycle
Metadata
Coordination (ISS)
SDF Service
Deployment
Management (ISS)
2
Operate
SDF Service State
Monitor (ISS)
6
SDF Service Provisng
Mngnt (MSS)
SDF Service
Instance
6
SDF Service Quality/
Problem Mngnt (MSS)
1
3
SDF Service Resource
Fulfillment (ISS)
SDF Service Resource
Monitor (ISS)
7
SDF Service Usage
Mngnt (MSS)
SDF MSS
Composite Services
provisioned on-demand
4
CPSRT2010 Workshop, 2 December 2010
12
13
14
15
SDF Service Resource
Usage Monitor (ISS)
SDF ISS
Security Services Lifecycle Management
8
1 – Service Instance
2 - Service Management Interface
3 – Service Functional Interface
4 - Management Support Service (SDF
MSS)
8 - Infrastructure Support Service (ISS)
DESIGN stage
9 - Service Repository
10 - Service Lifecycle Metadata
Repository
16 - Service Design Management
DEPLOYMENT stage
10 - Service Lifecycle Metadata
Repository
11 - Service Lifecycle Metadata
Coordinator
17 - Service Deployment Management
OPERATION stage
5 - Service Provisioning Management
6 - Service Quality/Problem Management
7 - Service Usage Monitor
12 - Service State Monitor
13 - Service Resource Fulfillment
14 - Service Resource Monitor
15 - Resource Usage Monitor
Slide_11
Composable Services Architecture –
Lifecycle stages workflow
4
4
Serv
User
Client
Serv
Applications and User Terminals
Serv
Proxy (adaptors/containers) – Composed/Virtualised Services and Resources
4
3
1
3
2
2
3
Control &
Management
Plane
1
(Operation,
Orchestration)
4
(Reservation
SLA
Negotiatn)
2
MD SLC
(1) Request
(2) Composition/
Reservation
(3) Deployment
(4) Operation
(5) Decommissioning
Composition
Layer /Serv
Composable Services Middleware
(GEMBus/GESB)
Registry
Logging
Composable
Services
lifecycle/provisioning
stages
Security
3 2
MD SLC – Service
Lifecycle Metadata
Logical Abstraction Layer for Component
Services and Resources
3 2
4
4
Proxy (adaptors/containers) - Component Services and Resources
Storage
Resources
Compute
Resources
CPSRT2010 Workshop, 2 December 2010
3 2
Network Infrastructure
Component Services & Resources
Security Services Lifecycle Management
GEMBus – GEANT
Multidomain Bus
Control/
Mngnt Links
Data Links
Slide_12
Security Services Lifecycle Management Model
(compliant to CSA SDF/lifecycle model)
Security Service request and generation of the GRI that will serve as a provisioning session identifier
and will bind all other stages and related security context.
Reservation session binding that provides support for complex reservation process including required
access control and policy enforcement.
Deployment stage begins after all component resources have been reserved and includes distribution
of the security context and binding the reserved resources or services to GRI as a common
provisioning session ID.
Registration&Synchronisation stage (optional) specifically targets possible scenarios with the
provisioned services migration or failover/interruption. In a simple case, the Registration stage binds
the local resource or hosting platform run-time process ID to the GRI as a provisioning session ID.
Operation stage - security services provide access control to the provisioned services and maintain the
service access or usage session.
Decommissioning stage ensures that all sessions are terminated, data are cleaned up and session
security context is recycled.
Service
Request
(GRI)
CPSRT2010 Workshop, 2 December 2010
Reserv
Session
Binding
Deployment &
RsrBind
Registr
Synchro
(Opt)
Security Services Lifecycle Management
Operatn
Access
Decommision
Slide_13
Relation between SecuritySLM and general SLM
(a)
Services
Lifecycle
Stages
(b) Security
Services
Lifecycle
Stages
Service
Request
(GRI)
Design
Development
Reservation
SecServ
Request
(GRI)
Reserv
Session
Binding
Deployment
Deployment &
RsrBind
Registr
Synchro
(Ext)
Operate
Maintain
Decommision
Operatn
Access
Decommision
Additional SSLM stages and mechanisms to ensure consistency of the security context management
Security Service Request that initiates creation of the dynamic security association and may use SLA
security context.
Reservation Session Binding with GRI (as part of Planning stage) that provides support for complex
reservation process including required access control and policy enforcement.
Registration&Synchronisation stage (as part Deployment stage) specifically targets possible
scenarios with the provisioned services migration or failover/interruption. In a simple case, the
Registration stage binds the local resource or hosting platform run-time process ID to the GRI as a
provisioning session ID.
CPSRT2010 Workshop, 2 December 2010
Security Services Lifecycle Management
Slide_14
Relation between SSLM/SLM stages and supporting
general and security mechanisms
SLM
stages
Request
Process/
Activity
SLA
tiation
Nego
Design/Reservation
Development
Deployment
Operation
Decomissioni
ng
Service/
Resource
Composition Reservation
Composition
Configuration
Orchestration/
Session
Management
Logoff
Accounting
Mechanisms/Methods
SLA
V
Workflow
Metadata
V
(V)
V
V
V
V
V
Dynamic
Security
Associatn
(V)
V
V
AuthZ Session
Context
V
(V)
V
Logging
(V)
(V)
V
CPSRT2010 Workshop, 2 December 2010
Security Services Lifecycle Management
V
Slide_15
Implementation suggestions
Extend existing GAAA-Toolkit pluggable Java library to support dynamic
Security/AAI infrastructure creation and integration with provisioned VI
• Provides GAAA Authorisation API (GAAAPI) functions with extended AuthZ and
session management functionality
Support for SDF workflow and Security Services Lifecycle Management
• Needs general infrastructure services such as Metadata SLM
Define and implement Common Security Service Interface (CSSI)
• Supports both internal applications calls and Web service integration via Spring
security
• Implements GSS-API and extends it with GAAAPI functionality
Use standard Messaging, Transport and Network security mechanisms provided
by implementation platform
• Implementation platform selection – ESB/WS/SOA (Fuse, Apache ServiceMix, etc.)
CPSRT2010 Workshop, 2 December 2010
Security Services Lifecycle Management
Slide_16
Multidomain Network/Complex Resource Provisioning (NRP/CRP) –
Provisioning sequences
Agent
(AAA)
A
R
Provisioning sequences
NSP/AAA
NSP/AAA
PAP
PAP
PDP
PDP
P
User
Client
TVS
NSP/AAA
PAP
PDP
TVS
TVS
PEP
PEP
DC/NRPS
DC/NRPS
DC/NRPS
NE
NRPS – Network Resource Provisioning System
NSP – Network Service Plain
DC – Domain Controller
IDC – Interdomain Controller
GridNets2009, 8-9 September 2009, Athens
Service
(AAA)
plane
Dest
Host
Applicatio
n
NE





Agent (A)
Polling (P)
Relay (R)
Token based policy
enforcement
Control
plane
PEP
NE
DC/A
AA



GRI – Global Reservation ID
AuthZ tickets for multidomain
context mngnt
T - Token
Network
plane
AAA – AuthN, AuthZ, Accounting Server
PDP – Policy Decision Point
PEP – Policy Enforcement Point
TVS – Token Validation Service
KGS – Key Generation Service
Multidomain Complex Resource Provisioning (СRP) –
Stage 1 – Path building and Advance Reservation
Token based signalling and
access control
IDC/AAA
PAP
GRI
PAP
GRI
PDP
PDP
TVS
User
Client
IDC/AAA
IDC/AAA
PAP GRI
PDP
TVS
TVS
PEP
PEP
DC/NRPS
DC/NRPS
DC/NRPS
NE
IDC – Interdomain Controller
DC – Domain Controller
NRPS – Network Resource Provisioning System
NE - Network Element
GridNets2009, 8-9 September 2009, Athens
NE
Service
(AAA)
plane
Dest
Host
Control
plane
PEP
NE
DC/A
AA
GRI – Global Reservation ID
AzTicket – AuthZ ticket for
multidomain context mngnt
AT – Access Token
Pilot Token type 3 used at the Stage
1 Reservation for signalling
and interdomain context
communication
* As container for GRI and AzTicket
Applicatio
n
Network
plane
Pilot Token type 4 used at the Stage
2 for setup information
communication
AAA – AuthN, AuthZ, Accounting Server
PDP – Policy Decision Point
PEP – Policy Enforcement Point
TVS – Token Validation Service
Multidomain Complex Resource Provisioning (СRP) –
Stage 2 – Deployment (setup and key distribution)
Token based signalling and
access control
IDC/AAA
PAP
GRI
PAP
GRI
PDP
PDP
TVS
User
Client
IDC/AAA
IDC/AAA
PT4(AzTick)
PAP GRI
PDP
TVS
PT4(AzTick)
TVS
PEP
PEP
DC/NRPS
DC/NRPS
DC/NRPS
NE
IDC – Interdomain Controller
DC – Domain Controller
NRPS – Network Resource Provisioning System
NE - Network Element
GridNets2009, 8-9 September 2009, Athens
NE
Service
(AAA)
plane
Dest
Host
Control
plane
PEP
NE
DC/A
AA
GRI – Global Reservation ID
AzTicket – AuthZ ticket for
multidomain context mngnt
AT – Access Token
Pilot Token type 3 used at the Stage
1 Reservation for signalling
and interdomain context
communication
* As container for GRI and AzTicket
Applicatio
n
Network
plane
Pilot Token type 4 used at the Stage
2 for setup information
communication
AAA – AuthN, AuthZ, Accounting Server
PDP – Policy Decision Point
PEP – Policy Enforcement Point
TVS – Token Validation Service
Multidomain Complex Resource Provisioning (СRP) –
Stage 3 – Access Control (using access tokens)
Token based signalling and
access control
IDC/AAA
PAP
IDC/AAA
IDC/AAA
GRI
PAP
GRI
PDP
PDP
PDP
PT4(AzTick)
PT4(AzTick)
AT
User
Client
TVS
AT
PAP GRI
TVS
AT
TVS
AT
PEP
PEP
PEP
DC/NRPS
DC/NRPS
DC/NRPS
NE
NE
IDC – Interdomain Controller
DC – Domain Controller
NRPS – Network Resource Provisioning System
NE - Network Element
GridNets2009, 8-9 September 2009, Athens
DC/A
AA
NE
Service
(AAA)
plane
Dest
Host
Control
plane
GRI – Global Reservation ID
AzTicket – AuthZ ticket for
multidomain context mngnt
AT – Access Token
Pilot Token type 3 used at the
Stage 1 Reservation for
signalling and interdomain
context communication
* As container for GRI and
AzTicket
Applicatio
n
Network
plane
Pilot Token type 4 used at the
Stage 2 for setup
information communication
AAA – AuthN, AuthZ, Accounting Server
PDP – Policy Decision Point
PEP – Policy Enforcement Point
TVS – Token Validation Service
СRP Stages and Authorisation Session Types
SLA, WSAgreement
Access Control
Policy
GRI generated
Accounting,
Billing
Network
Config.
Reservation
Deployment
Access/Use
Decommissioning
AccessToken
PilotToken0-3
PilotToken4
Reservation
Session
Access
Session
Provisioning session
Requires consistent security and session context management
Global Reservation ID (GRI) is created at the beginning of the provisioning session (Reservation stage) and
binds all sessions
GridNets2009, 8-9 September 2009, Athens
Access Token and Pilot Token Types
AType 0 – Simple access token (refers to the reserved resources context)
AType 1 – Access token containing Obligations collected from previous domains
PType 0 – Container for GRI only
PType 1 – Container for communicating the GRI during the reservation stage
• Contains the mandatory SessionId=GRI attribute and an optional Condition element
PType 2 – Origin/requestor authenticating token
• TokenValue element contains a value that can be used as the authentication value for the token
origin
• TokenValue may be calculated of the (GRI, IssuerId, TokenId) by applying e.g. HMAC function
with the requestor’s symmetric or private key.
PType 3 – Extends Type 2 with the Domains element that allows collecting domains security
context information when passing multiple domains during the reservation process
• Domains’ context may include the previous token and the domain’s trust anchor or public key
PType 4 – Used at the deployment stage and can communicate between domains security
context information about all participating in the provisioned lightpath or network
infrastructure resources
• Can be used for programming/setting up a TVS infrastructure for consistent access control
tokens processing at the resource access stage
GridNets2009, 8-9 September 2009, Athens
XML Token Format – Access and Pilot Tokens
 Support inter-domain security/session context communication to allows
multidomain provisioning scenarios
 Ensure Integrity of the AuthZ decision
 Keeps AuthN/AuthZ context
 Allow Obligated Decisions (e.g. XACML Obligations)
 Supports simple delegation scenarios
 Can be used for establish session-based trust relations between domains
 Allows easy mapping to SAML and XACML related elements
GridNets2009, 8-9 September 2009, Athens
Chaining Pilot Tokens in multidomain signalling
Requestor
Domain1
“viola”
Domain2
“uva”
Domain3
“uclp”
Resource
* Pilot Token type 3 issued
by domain UVA
<AAA:AuthzToken xmlns:AAA="http://www.aaauthreach.org/ns/AAA"
Issuer=http://testbed.ist-phosphorus.eu/uva/AAA/TVS/tokenpilot
SessionId="740b241e711ece3b128c97f990c282adcbf476bb"
TokenId="dc58b505f9690692f7a6312912d0fb4c" type="pilot-type3">
<AAA:TokenValue>190a3c1554a500e912ea75a367c822c09eceaa2f </AAA:TokenValue>
<AAA:Conditions NotBefore="2009-01-30T08:57:40.462Z" NotOnOrAfter="2009-01-30T09:21:40.462Z"/>
<AAA:DomainsContext>
<AAA:Domain domainId="http://testbed.ist-phosphorus.eu/viola">
<AAA:AuthzToken Issuer="http://testbed.ist-phosphorus.eu/viola/aaa/TVS/token-pilot«
SessionId="2515ab7803a86397f3d60c670d199010aa96cb51"
TokenId="c44a2f5f70346fdc2a2244fecbcdd244">
<AAA:TokenValue>dee1c29719b9098b361cab4cfcd086700ca2f414
</AAA:TokenValue>
<AAA:Conditions NotBefore="2009-01-30T07:57:35.227Z"
NotOnOrAfter="2009-01-31T07:57:35.227Z"/>
</AAA:AuthzToken>
<AAA:KeyInfo> http://testbed.ist-phosphorus.eu/viola/_public_key_ </AAA:KeyInfo>
</AAA:Domain>
</AAA:DomainsContext>
</AAA:AuthzToken>
GridNets2009, 8-9 September 2009, Athens
Future work and Discussion
• Definition of and reference implementation of the Common Security
Services Interface (CSSI)
As extension to industry adopted GSS-API
 Incorporate GAAA-AuthZ (RFC2904) Authorisation interface
 Extends for Session Security Context Management and dynamic
trust/security association management

• Wide range of formalisation and modeling work
• Implementation in projects GEANT3 and GEYSERS
• CSA and Security Services Lifecycle Management model is proposed as
a possible deliverable for OGF ISOD RG
CPSRT2010 Workshop, 2 December 2010
Security Services Lifecycle Management
Slide_25
Additional Information
• TMF SDF Lifecycle Management model
CPSRT2010 Workshop, 2 December 2010
Security Services Lifecycle Management
Slide_26
AuthN/AuthZ Infrastructure (AAI) in GEYSERS
CSSI
Basic CSSI services
SML
NIPS-UNI
NIPS Server
SLI
NCP
CCI
LICL
NLI
GEYSERS Security (AAI)
VITM
LPI
Data encryption
Digital signature
Authentication
Authorization
Policy management
Security session and context
management
Called from services (or part of
core interfaces)
SLI (SML-LICL)
CCI (NCP-LICL)
NLI (NCP-LICL)
LPI (LICL-PHY)
NIPS-UNI
PHY
CPSRT2010 Workshop, 2 December 2010
Security Services Lifecycle Management
Slide_27
GEYSERS AAI Reference Model
AAI Gateway
Common Security Services Interface (CSSI)
PEP
AuthN Service
SecCtx Handler
Token Validation
Service (TVS)
PDP
AuthN DB
PAP
Dyn AC
Service
Mngnt
Config,
Attr
Trust/Key
Mngnt
PEP: Policy Enforcement Point
PDP: Policy Decision Point
PAP: Policy Administration Point
DACS: Dynamic Access Control Service
CPSRT2010 Workshop, 2 December 2010
Security Services Lifecycle Management
Slide_28
GEMBus Infrastructure for Composable Service
GEMBus Component Services
Service 1
Service 2
Service 3
Service 4
(CSrvID,
SesID)
(CSrvID,
SesID)
(CSrvID,
SesID)
(CSrvID,
SesID)
Message Handling
Routing
Configur
ation
Interceptors
(AspOrient)
ESB
GEMBus Messaging
Infrastructure (GMI)
GEMBus
Registry
Composition &
Orchestration
Security
Service
Logging
Service
GEMBus Infrastructure Services
CPSRT2010 Workshop, 2 December 2010
Security Services Lifecycle Management
GMI provides common dynamically
configurable messaging infrastructure
for Composable services
communication
Slide_29
Example Service Composition – Service NX
Service 4
Composed Service NX
(CSrvID,SesID)
(CSrvID,SesID)
UserClient
Service 3
Service 1
Service 2
(CSrvID,SesID)
(CSrvID,SesID)
(CSrvID,SesID)
(CSrvID,SesID)
Service 4
Composed Service NX
(CSrvID,SesID)
(CSrvID,SesID)
User Interface
UserClient
Frontend
CompSrvNX
(CSrvID,SesID)
(CSrvID,SesID)
CPSRT2010 Workshop, 2 December 2010
Service 3
Service 1
Service 2
(CSrvID,SesID)
(CSrvID,SesID)
(CSrvID,SesID)
Security Services Lifecycle Management
Role and place for
Composition and
Orchestration
* Composable
services or GEMBus
infrastructure
service
CSrvID, SesID – bind
component
services into the
on-demand
provisioned
Composed
service NX
Slide_30
GEYSERS Reference Model
Role:
• VIO
• VIP
• PIP
CPSRT2010 Workshop, 2 December 2010
Security Services Lifecycle Management
Slide_31
Role of GEYSERS actors
with respect to its architectural layers
CPSRT2010 Workshop, 2 December 2010
Security Services Lifecycle Management
Slide_32
GEYSERS Service Delivery Framework (SDF)
• Service provisioning workflow by VIP:


Creation of the Virtual Infrastructure (VI)
May include more engineers support
• Service provisioning workflow by VIO:


Creation and operation of the Virtual Infrastructure on-demand for specific project,
tasks or user groups
Should be completely automatic
• Should also include activities/stages for infrastructure re-planning, restoration
and migration
• Adopted TeleManagement Forum Service Delivery Framework (TMF SDF)
• GEYSERS Project - http://www.geysers.eu/
CPSRT2010 Workshop, 2 December 2010
Security Services Lifecycle Management
Slide_33
GEYSSERS Service Delivery Framework/Workflow
Service Request/
SLA Negotiation
Replanning
Services
Provisioning
Workflow
by VIP
Service Request/
SLA Negotiation
Planning
(Compos/Reserv)
Planning
(Design)
Geysers SDF supports both
Geysers infrastructure
development and
deployments and its
operation for on-demand
Infrastructure services
provisioning by VIO
RePlanning
Deployment
Deployment
(Instant&
Config&Synchro)
Recovery/
Migration
Operation
&Monitoring
(by VIO)
Network+IT
Services
Provisioning
Workflow
by VIO
Registr&Synchro
Recovery/
Migration
Operation
(Monitoring)
Decommissioning
Decommissioning
CPSRT2010 Workshop, 2 December 2010
Security Services Lifecycle Management
Slide_34
Existing framework in on-Demand Infrastructure
Services Provisioning and Lifecylce Management
TMF standardised frameworks, practices and procedures
• SDF - Service Delivery Framework
• SLA management
• NGOSS – New Generation Operations System Services (including eTOM)
Microsoft Security Development Lifecycle (SDL) Framework
• Primarily focused on the product development process by engineers/programmers
(Training) – Requirements – Design – Implementation – Verification – Release –
(Response)
CPSRT2010 Workshop, 2 December 2010
Security Services Lifecycle Management
Slide_35
SDF main stages and phases
Main stages/phases
•
•
•
•
•
Service Request (including SLA negotiation)
Planning (including Composition, Reservation and Design)
Deployment (including Reqistration/Synchronisation)
Operation (including Monitoring)
Decommissioning
Additional stages
• Re-Composition should address incremental infrastructure changes
• Recovery/Migration can use SL-MD to initiate resources re-synchronisation but may require recomposition
The whole workflow should be supported by the Service Lifecycle Metadata Service (SL MD)
CPSRT2010 Workshop, 2 December 2010
Security Services Lifecycle Management
Slide_36