Shared Services Canada (SSC)
Cloud Computing Architecture
Identity, Credential & Access Management
Architecture Framework Advisory Committee
Transformation, Service Strategy and Design
Agenda
TIME TOPICS PRESENTERS
9:00 – 9:10 Opening Remarks, Objectives & July Meeting Review
B. Long, Chair
W. Daley, Vice-Chair
9:10 – 9:15 Cloud Computing:
Recap from July AFAC meeting
B. Long
9:15 – 9:40 Cloud Computing Architecture J. Danek
9:40 – 10:20 Round Table All
10:20 – 10:30 Health Break
10:30 – 11:00 Identity, Credential & Access Management
R. Thuppal
11:00 – 11:45 Round Table All
Shared Services Canada • Enterprise Architecture
Cloud Computing Architecture
AFAC
Meeting 2
August 29, 2013
Jirka Danek
SSC High Level Requirements
• Application mobility between private, public and hybrid cloud
environments
• Ability to manage, orchestrate, administrate, and provision
from a single open interoperable architectural framework
• Ability to provide an environment for open competition and
level playing field among vendors
• To ensure on-going competition (not just at contract award)
low cost / high value to the Crown over the contract life
• Agility – to have flexibility in the architecture that will allow
for scale – both from a capacity perspective and with
respect to change in technology directions driven by our
requirements and marketplace opportunities
Portal and Self Service Catalogue
Multi-Cloud Management Services
(Orchestration, Governance, Financial Control, Brokering, ICAM, Reporting)
GC Cloud Orchestration Architecture v1
GC Public Cloud Services GC Hybrid Cloud Services GC Community Cloud Services
Service, Security, Savings Agility & Mobility
July AFAC Cloud Computing Feedback
Did we hear you correctly??
• OpenStack was considered by some as not mature enough at this time • OpenStack was seen as a potential option for open cloud interoperability,
however, it was noted that there are very few significant production implementations at this time
• Fail fast – test it and try application mobility in small initial iterations
• Some participants felt that OpenStack would be good for selective non-mission critical workloads
• Some AFAC members suggested the cost of the systems integration work for OpenStack would out-weigh the benefit of application mobility
• OpenStack is complex and implementation skills are not readily available
• Others felt that OpenStack would be good as a long term strategy, but shouldn’t be the only plank in SSC’s approach to cloud interoperability
• It was observed that OpenStack is just one of a number of cloud open standards bodies, and no clear winner has emerged at this time
SSC DC Challenge Sample – Win/Lintel Only
Mgmt. Mgmt. Mgmt. Mgmt. Mgmt. Mgmt. Mgmt. Mgmt. Mgmt. Network Network Network Network Network NetworkNetwork Network Network
Network Network Network Network Network Cloud Computing Compute OS Hypervisor Hardware Compute OS Hypervisor Hardware Compute OS Hypervisor Hardware Hardware OS Hypervisor Compute Storage Storage Storage Storage Storage Storage
SSC DC Challenge Sample – Win/Lintel Only
Cloud Computing Integrated Mgmt. Network OS Hypervisor Compute Storage VCE Integrated Mgmt. Network OS Hypervisor Compute Storage FlexPod Integrated Mgmt. Network OS Hypervisor Compute Storage vStart Integrated Mgmt. Network OS Hypervisor Compute Storage CloudSystem Integrated Mgmt. Network OS Hypervisor Compute Storage HItachi Integrated Mgmt. Network OS Hypervisor Compute Storage PureFlex Integrated Infrastructure SystemsSSC DC Challenge Sample – Win/Lintel Only
Cloud Computing Integrated Mgmt. Network OS Hypervisor Compute Storage Oracle Exadata DBMS Integrated Application Systems Integrated Mgmt. Network OS Hypervisor Compute Storage IBM PureApplication Integrated Mgmt. Network OS Hypervisor Compute Storage HP AppSystemRoadmap of Cloud-based Services
• Enterprise HR Service
• Enterprise Finance Service
• Enterprise Document Management Service
• Enterprise Web Hosting Service
• GCNet Services
• Unified Communications Services
• Enterprise Data Centre IaaS and PaaS Services
• Partner-based SaaS implementations
(except ETI)• Multi-Services, Service Providers and Service Layers
• Private, Public and Hybrid Cloud Environments
The Emerging Broker Role
Cloud Broker Roles
1. Service Intermediation
• Enhances via value-added services
2. Service Aggregation
• Cloud services integration from multiple CSPs
3. Service Arbitrage
• Managing capacity dynamically, or managing service across a number of providers to meet, for example, SLA or optimum cost metrics.
Broker Use Cases
1. Management of New Hires:
• A new government employee joins the government. Their HR information is with Cloud Service Provider #1 (CSP #1) and their financial information and pay systems are with CSP #2. Their email is with CSP #3. How does SSC orchestrate interoperability among the systems? What is a broker role? How do we manage ICAM, and directory services? How do we manage custom
interoperability?
2. Fail Over and DR:
• SSC implements a mission critical application internally and
wishes to fail over based on capacity thresholds to a hybrid cloud or public cloud provider.
3. Dynamic Allocation:
• SSC implements an IaaS service for a government web site that is anticipating dramatic changes in capacity that cannot be
estimated. Can we implement a pool of cloud providers and allocate workloads based on price or capacity thresholds?
Questions
1. How do we architect to effectively manage the future
state environment?
2. Do we architect for separate management and
orchestration systems and processes for each service?
3. Are there mature enterprise reference architecture
models that bridge SaaS to PaaS from different service
providers?
4. How do we ensure vendor neutrality in this kind of
situation?
Shared Services Canada • Enterprise Architecture
Identity, Credential & Access
Management
AFAC
Meeting 2
August 29, 2013
Raj Thuppal
Purpose
•
Present GC ICAM proposed plan and Early
Releases
•
Seek feedback and input
July 2013 AFAC ICAM Feedback
• Build in increments according to need and priorities – make it as simple as possible
• Have very clear business goals
• Make it something “attractive” that users want to get
• Scaling to a new identity might be a challenge – incrementally connect the islands and migrate from the islands to a consolidated approach
• Consider all open standards, protocols (e.g. SAML and others)
• Awareness – one of the costs impacts of ICAM is the admin of credentials:
Consolidate credentials
Be cost effective
Bring as much capability as possible to Help Desk (SSC & Partner)
• Work on the security posture
• “Privacy by Design” – some provinces have some of the best privacy practices
IT Security Transformation (Draft)
Transformation from multiple network domains to single GC domain requires shift from network based security to identity and data based security.
IT Security Target State IT Security Current State
DEFENCE IN DEPTH
Focus on network, perimeter protection and network authentication
Focus on data, through layers of protection, separation and active detection
Dept … Dept … Dept … GCNet Data in Processing Data at Rest Data at Rest Data in Transit Unified Credential Single Identity Centralized Access Controls Multiple Identities
Multiple Identities Multiple Identities Multiple Credentials
Consolidated Back office Apps Mission Specific Apps Mission Specific Apps Consolidated Back office Apps Mission Specific Apps Mission Specific Apps Data at Rest Mission Specific Apps Mission Specific Apps Back office Apps Back office Apps Multiple Access Controls Multiple Access Controls Data in Transit Data in Processing
ICAM Challenges and Requirements
• Lack of comprehensive access controls and management of admin privileges, and dormant accounts
• Limited GC policy and standards enforcement capability SSC Initiatives • Blackberry 10 • GC-Wifi • GCNet • GC converged communications • GC Secret infrastructure • Data centre consolidation • Workplace technology devices TBS Initiatives • HR • Web • Fin • GCDocs • Mobility • Lack of single GC identity repository
• Partner specific ICAM, difficult to implement GC wide services
• Hard coded dependency on ICAM solutions inhibits service evolution
• Duplication and fragmented technologies, processes and service management
• Lack of GC wide capability forces application specific ICAM solutions (ex: ETI)
Increase Security
DRIVERS CHALLENGES EMERGING
REQUIREMENTS
Improve Service
19
GC ICAM – Scope (Proposed)
Scope:
• A Government of Canada solution
• Internal GC workers (e.g. employees, contractors, agents of the Crown, integrees, trusted guests, retirees) and non-person entities (e.g. devices, applications)
• Logical (IT systems/applications) and physical (building) access management
• Designated (to Protected B*) and Classified (to Secret) identities, credentials and resources will be managed
• Current ICAM-related processes and technologies will be transformed to the new ICAM solution, and new ones will be created as needed
Out-of-Scope:
• Individuals and businesses external to the Government of Canada
Program Management: Project Management, Reporting, Communications, Governance, Stakeholder Engagement, Finance
Jun.
2013 Sept Sep. Dec. 2015 Apr 2016 2017 2018 2019
GC ICAM – Schedule (Proposed)
Implement Rn (…) Detailed Plans Current State Requirements End State
Plan and Procure
Implement Rn (…) Implement Future State (…)
• Inventory of infrastructure and systems • Lessons learned
• Partner and enterprise requirements • End-state architecture and design • Service strategy, design, delivery model
• Business case(s)
• Consolidation and transformation roadmap • Implementation plan
Current State
PWGSC Industrial Security Program • Workers Security Clearance Attributes Email Transformation Initiative • Employee Attributes •ETI Onboarding PenMod • Employee Attributes GEDS • Employee Attributes Identity Management Access Management Credential Management
myKey ICM Service
• Person PKI Key & Onboarding • PKI Directory services
Departments (DND, RCMP, CRA) • Person PKI Key
• PKI Directory services • Others (e.g. SSL…) HR Applications (43 Partners ++)
• Employees Attributes
Line of Business Applications • Embedded credential
Departments tools and policies
Secure Remote Access
Departments
• Facilities Management
Requirements and Support to Transformation Programs (e.g. Network, Email, Data Centre…)
Opportunities
•
TBS back office application modernisation initiatives (HR, Fin, Web,
GCDocs)
•
IT service specific ICAM solutions are being designed due to lack of GC
wide solution (Ex: ETI), there is an urgent need for a GC ICAM solution
(SSC and TBS led initiatives)
•
Internal credential management system is already a GC wide service that
could be transformed (open standards, consolidation, decouple from
applications etc..) to end state service relatively quickly
•
ETI directory could be leveraged to populate GC ICAM
•
AFAC, industry feedback and previous GC attempts recommend building in
increments according to need and priorities and make it as simple as
Program Management: Project Management, Reporting, Communications, Governance, Stakeholder Engagement, Finance
Jun.
2013 Sept Sep. Dec. 2015 Apr 2016 2017 2018 2019
GC ICAM – Schedule (Proposed)
Implement Rn (…) Detailed Plans Current State Requirements End State
Plan and Procure
Implement Rn (…) Implement Future State (…)
• Inventory of infrastructure and systems • Lessons learned
• Partner and enterprise requirements • End-state architecture and design • Service strategy, design, delivery model
• Business case(s)
• Consolidation and transformation roadmap • Implementation plan
2014
ICAM Transformation Strategy
Release 1 ICAM:
Identity Management: •Attributes •Authoritative Sources •Onboarding process •Identity Manager Credential Management: •Applications Authentication (UserID/Pw or myKey) •PKI Transformation Access Management:
•PiV cards for SSC
•Simple Sign-On P oli ci es A na ly si s, A cces s M an ag emen t IO S IC A M D irect ory Release ....:
Identity Management Credential Management Access Management P oli ci es P rocess G ov ernan ce Te ch no lo gy GC ICAM Program Release 2:
Identity Management Credential Management Access Management P oli ci es P rocess G ov ernan ce Te ch no lo gy 2014 Dec. 2016...
GC ICAM Release 1 (Proposed)
Principles
•
Avoid development of application
specific ICAM services
•
Leverage existing enterprise ICAM
services (ETI, ICMS etc..)
•
Adopt open standards
•
Focus on foundation elements that
paves way for future GC ICAM
•
Consolidate identities
Scope
•
Identity Management
Identify attributes and their authoritative
sources
Build GC ICAM directory leveraging ETI
directory services and other sources
Establish GC identity manager that hosts
user identities and passwords
•
Credential Management
Transform GC-ICMS and other PKI services
Application authentication/decoupling (e.g. using SAML)
•
Access Management
Building access card standard and pilot
New GC ICAM Service Release 1 - Draft
PWGSC Industrial Security Program • Workers Security Clearance Attributes Email Transformation Initiative • Employee Attributes •ETI Onboarding PenMod • Employee Attributes GEDS • Employee Attributes
myKey ICM Service
• Person PKI Key & Onboarding • PKI Directory services
Departments (DND, RCMP, CRA) • Person PKI Key
• PKI Directory services • Others (e.g. SSL…) HR Applications (43 Partners ++)
• Employees Attributes
Line of Business Applications • Embedded credential
Departments tools and policies Departments • Facilities Management Credential Management: • Applications Authentication (UserID/Pw or myKey) • PKI Transformation Identity Management: • Attributes • Authoritative Sources • Onboarding process • Identity Manager New Enterprise Service Access Management:
• PiV cards for SSC •Simple Sign-On
Secure Remote Access Identity Management Access Management Credential Management
Requirements and Support to Transformation Programs and TBS Initiatives (e.g. HR, WEB, Fin, GCDOCS, Network, Email, Data Centre…)
