IDIM CORPORATE PROVISIONING ARCHITECTURE Architecture and Standards Branch Office of the CIO Province of BC People Collaboration Innovation

IDIM CORPORATE PROVISIONING ARCHITECTURE Architecture and Standards Branch Office of the CIO Province of BC People Collaboration Innovation Creation Date: Last Updated: Version: 2010-01-27 2010-12-21 1.0

Architecture and Standards Branch Office of the CIO Province of BC People Collaboration Innovation -- This page left intentionally blank -- IDIM Corporate Provisioning Architecture - version 1.0 Page ii

Architecture and Standards Branch Office of the CIO Province of BC People Collaboration Innovation Reviewed By Name Derek Rutherford Ian Bailey ASRB Title & Organization Director of Application Architecture and Standards, ASB, Office of the CIO Executive Director, Architecture and Standards Branch, Office of the CIO Architecture and Standards Review Board Revision History Version Date Changed By Description of Change 0.1 2010-01-24 R Mitchell Initial Draft 0.2 2010-02-16 R Mitchell Revised after internal review 0.3 2010-03-19 A Wilhelm Use Case variants updated/recommendations 0.4 2010-04-13 Albert Wilhelm; R Mitchell; Doug Collinge Edits for preview copy for ICON II 0.5 2010-05-14 R Mitchell; Doug Collinge; Albert Wilhelm 0.55 2010-07-12 R Mitchell; A Wilhelm 0.6 2010-11-30 R Mitchell; A Wilhelm 0.7 2010-12-03 R Mitchell; A Wilhelm 0.9 2010-12-07 R Mitchell; A Wilhelm 0.9 2010-12-09 R Mitchell, A Wilhelm Incorporated feedback from ICON II and ASB Review #1 feedback Feedback from ASRB review #1 Revisions & additions for re-publish to ASRB for approval Revisions & additions for re-publish to ASRB for approval revisions for pre-vote review to ASRB Final revisions for ASRB review 1.0 2010-12-21 R Mitchell Final for OCIO Approval IDIM Corporate Provisioning Architecture - version 1.0 Page iii

Architecture and Standards Branch Office of the CIO Province of BC People Collaboration Innovation Acknowledgment The authors of this document would like to acknowledge the work of the United States Federal Government ICAMSC (Identity, Credential, and Access Management Subcommittee) and their team in developing and producing the FICAM (Federal Identity, Credential and Access Management) Roadmap & Implementation Guidance document on which this document is based. 1 Document Purpose This document is intended to provide a corporate provisioning architecture for the BC Provincial Identity Information Management System (IDIM) for the benefit of program owners, architects, ministry IM/IT development staff, system integrators and other IT service providers to aid their planning and building of solutions in the areas outlined in this document. It captures and conveys the purpose, architecture and design intent of the IDIM corporate provisioning architecture and the services it provides. As such this document is a general description of architecture principles and patterns to be followed by provincial ministries; it is a corporate architecture blueprint for government. It is focused on an overview of the logical architecture of the IDIM as designed to support the development of Provincial IM/IT services. This architecture, although reflecting architectural target states and transitional milestones, does not define the implementation schedule nor the specific technological implementation of the architecture. Subsequent standards issued from this office will form the basis of any specific design decisions and implementation timelines. 1 Appendix C FICAM Roadmap & Implementation Guidance IDIM Corporate Provisioning Architecture - version 1.0 Page iv

Architecture and Standards Branch Office of the CIO Province of BC People Collaboration Innovation TABLE OF CONTENTS 1 Executive Summary... 9 2 Business Context... 13 2.1 Assessment Report...14 3 Overview of Identity & Access Management Framework... 17 3.1 IDIM in the Provincial Government...17 4 Provisioning Architecture... 20 4.1 Business Architecture...20 4.2 Data Architecture...22 4.3 Service Architecture...24 4.4 Technical Architecture...31 5 Provisioning Use Cases... 38 5.1 Create and Maintain Digital Identity Record for Internal User...39 5.2 Create, Issue, and Maintain Password...46 5.3 Create, Issue, and Maintain Biometric Credential...48 5.4 Provision / De-provision User Account for an Application...50 5.5 Grant Logical Access...57 5.6 Create, Issue and Maintain Smart Card...70 5.7 Create, Issue and Maintain PKI Credential...71 5.8 Grant Physical Access to Worker...72 IDIM Corporate Provisioning Architecture - version 1.0 Page v

Architecture and Standards Branch Office of the CIO Province of BC People Collaboration Innovation 5.9 Provision/Modify/De-provision Physical Entitlement for an Internal User...74 6 Supporting Standards... 80 6.1 Identity Standards:...80 6.2 Authoritative Data Sources Standard...80 6.3 Privilege Management Standard...80 6.4 Audit and Reporting Standard...80 7 Appendix A - Acronym List... 81 8 Appendix B - Glossary... 81 9 Appendix C Related Standards and Guidance... 85 9.1 Documentation from the Office of the Chief Information Officer...85 9.2 Other Documents...87 IDIM Corporate Provisioning Architecture - version 1.0 Page vi

Architecture and Standards Branch Office of the CIO Province of BC People Collaboration Innovation TABLE OF FIGURES Figure 1: IDIM Conceptual Diagram...18 Figure 2 : Use Case & Business Value Chain Relationship...22 Figure 3: Cross Government Repositories and Systems...23 Figure 4: IDIM Services Framework...25 Figure 5: Technical Architecture Target State IDIM User Perspective model...32 Figure 6: Provisioning Technical Architecture Target State - Conceptual Model...34 Figure 7: Provisioning System Administration - Conceptual Model...36 Figure 8: Use Case 1 (Part 1) Target State - Create Digital Identity...43 Figure 9: Use Case 1 (Part 2) Target State - Modify Digital Identity...44 Figure 10: Use Case 4 (Part 1) Target State Provision/Modify Account and Permissions...54 Figure 11: Use Case 4 (Part 2) Target State - Deprovision Account...55 Figure 12: Use Case 5 Target State - Grant Logical Access (Internal User)...60 Figure 13: Use Case 5 Target State - Grant Logical Access (Federated User)...61 Figure 14: Use Case 10 (Part 1) Target State Provision/Modify Physical Permissions...77 Figure 15: Use Case 10 (Part 2) Target State - Deprovision Physical Permissions...78 IDIM Corporate Provisioning Architecture - version 1.0 Page vii

Notes to the reader This architecture does not reflect specific implementation details (e.g. audit, administration model, corporate on-boarding process etc). Supporting standards released after this document will include more specific implementation details. Although this document may imply a sequencing or implementation schedule it is not to be taken as authoritative, subsequent standards based on this architecture will specify implementation schedules and specific program obligations. Please refer to Appendix C: Related Standards & Guidance for schedule of planned standards. Page 8

1 Executive Summary The OCIO is implementing an Information Management/Information Technology (IM/IT) plan for government to improve information sharing to better achieve citizen outcomes. The IM/IT plan is about securely connecting systems and people, identifying evidence-based outcomes and making sound investment decisions, all supported by a next generation information structure. A key enabler of the next generation information structure is the Province s Identity Information Management Program (IDIM). At the heart of information sharing, connecting people, and providing access to information systems is the knowledge of who we are sharing the information with, what organizations they we are working for, what roles and privileges they have been granted, and, for many public services, assurances of whom the information is about. Identity information management provides this knowledge and assurance so that we can share information securely and confidentially, connecting the workforce and providing access only when appropriate. A key element is providing access only when appropriate is the underlying identity management infrastructure. The province engaged the services of The Burton Group (an acknowledged industry expert) to assess the current state with respect to its identity management capabilities. Although in their assessment there were areas that were well aligned with industry best practices, the Province s User Provisioning environment was far from being fully integrated and required significant improvements. In essence, there is no agreed to architecture to guide the requirements, interests, and needs of the government. From an architectural perspective, the requirements and needs of government are reflected in the multiple actions within a business that are chained together. The business process chains deliver value through a link back to one or more of the E-Government service domains: Government to Citizen (G2C), Government to Business (G2B) and Internal Efficiency and Effectiveness (IEE). All 3 domains have common outcomes of improved interaction between government and the public, with the IEE domain driving internal processes and activities to become more friendly, convenient, transparent, and cost-effective. In order to deliver the business value more cost-effectively a services framework needs to be established to provide a common set of services to support needs across ministries, agencies and broader public sector. The service architecture provides a functional framework for identifying and evaluating government-wide opportunities to leverage IT investments and assets from a service perspective. The architecture describes in detail each of these service components, categorized by service type and includes: Digital Identity Credentialing Privilege Management Authentication Authorization and Access Page 9

Cryptography Audit and reporting User provisioning falls within the privilege management class of services, but is highly dependent on all other IDIM services. High-level use cases outline the components of the architecture within the business functions that they support. Each use case describes a series of actions taking place, the actors involved and the data being exchanged Use Case Name Use Case Description 1- Create and maintain digital identity record for internal user 2- Create, issue, and maintain password 3- Create, issue and maintain a biometric credential 4- Provision and deprovision user account for an application Provides the high-level process steps for establishing a digital identity for an internal user and modifying the digital identity record over time as the user's attributes change Provides the high-level process steps for creating, issuing, and maintaining a password token over the credential lifecycle. Provides the high-level process steps associated with creating and issuing a biometric credential to a user. Biometric credentials are seen as one of many factors involved in a strong or multi factor authentication or authorization model. Provides the high-level process steps for provisioning and de-provisioning a user account and establishing the access privileges and entitlements for the user in an application 5- Grant logical access Provides the high-level process steps for authenticating and authorizing or denying a user logical access to systems, applications, and data. The use case provides alternate process flows to address authentication mechanisms at all four levels of assurance. 6- Create, issue, and maintain Smart Card 7- Create, issue, and maintain PKI credential 8- Grant physical access to worker 9- Provision physical entitlements to an internal user Provides the high-level process steps for creating and issuing a Smart Card credential to an employee or contractor and maintaining it over the credential lifecycle. Provides the high-level process steps for creating, issuing, and maintaining a PKI certificate over the credential lifecycle in compliance with PKI standards. Provides the high-level process steps for authenticating and authorizing or denying a worker physical access to a facility or site. Provide the high-level process steps for provisioning & de-provisioning the physical entitlements (e.g. work space, phone, computer etc.) to a worker. Page 10

The provisioning system may rely on either Corporate or Sector authoritative data sources to trigger a provisioning event, these events will create, modify or delete an attribute related to an Identity, Credential, User Account, Logical Access to an Application, or Logical Access to a Physical Resource, on the target resource. This will enable an individual to request and receive services and entitlements they are preapproved for or submit requests for approval which will be subsequently provisioned. The provisioning system will interact with expert ordering and management systems using the provisioning policy repository to facilitate the requesting and ordering of services and products. The provisioning repository will be updated to reflect all the logical and physical accesses and entitlements to a user to facilitate de-provisioning of a user when necessary. In the realm of physical access, the provisioning system will interoperate with a single, government wide building access management system to facilitate access based on the established roles and entitlements within the provisioning system. A multi tenanted model with delegated administration will allow Provisioning Application Administrators of the provisioning system and Privilege Managers to create, modify, delete attributes and associated roles and rules policies leveraged by the provisioning system. Page 11

The need to establish administrative boundaries within the provisioning system will be a balance between the corporate need for a common solution with centralized decision making to reduce complexity and costs relative to the requirement to enable adequate localized decision making. In the context of provisioning, an organization can be a ministry, sector, or group of applications that utilize common administrative resources and have a consistent set of provisioning requirements, which may include: business knowledge for privilege management provisioning processes workflow role definitions and assignments access policy existing system administration boundaries Page 12

This architecture does not reflect specific implementation details (e.g. audit, administration model, corporate on-boarding process etc) subsequent standards based on this architecture will specify detailed designs and implementation schedules and specific program obligations. 2 Business Context The B.C. government s commitment to transforming citizens access to their government and public services is the driving force behind the recently published Gov 2.0 strategy, Citizens @ the Centre. Information Management and Information technology (IM/IT) are key enablers of the innovation that is required to realize this vision and establish a modern BC Public Service. The IM/IT Enablers Strategy for Citizens @ the Centre provides a corporate, prioritized roadmap to help guide how we manage our resources (people and money), based on a long-term vision. It assesses the emerging trends and the associated opportunities and challenges for the B.C. government, and it articulates the strategic directions that are most capable of supporting the three strategic shifts identified in Citizens @ the Centre: Citizen Participation, Self Service, and Business Innovation. Technology trends and directions were a major consideration of the Deputy Ministers Committee on Transformation and Technology (DMCTT) in developing Citizens @ the Centre. This reflects a general acknowledgement that the full power of technology and information must be leveraged to enable the vision of a modernized BC Public Service. A clearly articulated corporate IM/IT Enablers Strategy is required - one that is considered, deliberate and long-term, with the flexibility to respond quickly to changing realities. Further, success with these IM/IT enablers will come through acknowledging the need for cultural change, and embracing innovative ways of delivering services. The B.C. government recognizes that to deliver maximum value and support for the government s transformational agenda it must think and act as a single enterprise. The recently issued Citizens @ the Centre and instructions for completing Transformation and Technology Plans aim to establish that culture. The aim is to ensure investments are aligned with corporate priorities and that there is a corporate approach to managing IM/IT investments. There are three key strategies within the Identity Information Management enablers stream: 1. Establish Corporate Trusted Identity Services 2. Establish Corporate Provisioning Services for Identities and Roles 3. Develop an Identity Federation Establish Corporate Provisioning Services for Identities and Roles strategy is the focus of this architecture document and has the following linkage to Government s strategic shifts and primary enablers: Links to Citizens @ the Centre: Shift 3 - Business Innovation Links to IM/IT Enablers Strategy: Identity Information Management Page 13

Key Actions Supporting the Strategy: Publish corporate provisioning architecture Define clear authorities, related accountabilities and standards for identity, roles and authoritative sources of information Build corporate provisioning capability for first tenant Extend corporate provisioning capability to facilitate on-boarding of all government and broader public services 2.1 Assessment Report 2 The Province of British Columbia contracted with Burton Group to conduct an objective and independent assessment of its current User Provisioning environment and capabilities relative to its requirements. The purpose of this assessment was to better understand the government s current posture relative to User Provisioning best practices and provide feedback to consider as part of developing the Province s User Provisioning strategy and platform. The following is an extract from the Burton Group report: Burton Group observed some aspects of IDIM governance established within the Province in the form of standards supporting the core IM/IT policy and applying to government-wide corporate and ministry information-systems solutions. An example of this is the standard surrounding the use of the Enterprise Security Gateway services and technology for user identity, authentication, common logon, and user-management support. Burton Group also found that the Province has kept a few key elements of the IDIM infrastructure aligned with technical best practices, including: Segmenting internal and external-facing user groups in different physical identity repositories i.e. IDIR and BCeID Trying to improve data quality by defining some authoritative sources and using synchronization techniques. This is implemented today using a custom meta directory based on batch synchronization processes. Moving towards a shared services model for service delivery However, the Province s User Provisioning environment is far from being fully integrated and requires significant improvements in the governance, process, as well as in technology areas of identity, credentialing and access management. In essence, there is no agreed to enterprise strategy, architecture, or roadmap for IDIM that can guide the requirements, interests, and needs of the government forward 2 Appendix C Burton Group User Provisioning Rapid Assessment Report Page 14

This implies that the province needs: An incremental strategy and implementation roadmap surrounding User Provisioning. To establish processes and policies to establish an identity data ownership framework and improve identity data quality (following a government-wide identity data model) over time to provide robust provisioning capabilities. Work toward improving, simplifying and harmonizing business processes that span the province. In addition, the inability of systems across multiple organizations to securely exchange appropriate information is unnecessarily complicating the delivery of services to citizens across the province. A consistent definition of identities, roles and entitlements across government and the broader public sector is necessary for government to attain its goal of information sharing which leads directly to better service. The IDIM corporate provisioning architecture addresses the following concerns: The Province is facing the loss of thousands of employees to retirement; problems around provisioning will only be heightened in the years ahead unless the government implements a new provisioning solution to retain corporate capability to provision. Identity should be established once in government and be consistent with other public bodies so that the identities can be understood as equal for the purposes of identifying, establishing roles, and hence entitlements, where appropriate. Automated provisioning should be based on corporate events: This architecture makes use of corporate events that are already available (e.g. HRMS add new employee transaction) to trigger the provisioning processes, where appropriate, and create clear process for provisioning outside of those events. Reliable, consistent corporate events are preferred over human intervention. A single view of user entitlements and accesses (logical and physical): This architecture enables our ability to provide a holistic view of all users logical accesses and, when implemented, physical accesses. A single access control record tied to a real world identity will enable effective de-provisioning and, where required, more effective attestation to ensure compliance. Authoritative sources of employees and contractors should be established and leveraged. The subject of a forthcoming standard (Authoritative Sources Standard) An identity record will be defined according to the requirements of the Identity Information Standards Managed processes that are compliant with all the standards of the Package will be created for the management of these records Workers (contractors and employees) will be identified to at least a level 2 identity assurance. Individual government programs may also specify level 3 and 4 where these are required. This architecture is intended to support all levels of assurance for workers. Specific supports for higher levels of assurance will be defined once specific business use cases have been identified. Page 15

The following architecture is intended to address these gaps and concerns. Page 16

3 Overview of Identity & Access Management Framework 3.1 IDIM in the Provincial Government Although the topic of corporate provisioning is but one topic in the identity management framework, it is tightly integrated into, or affects, nearly every aspect of the identity and access management lifecycle. A corporate approach for processes, attribute models, and toolsets for the provisioning and de-provisioning of identity, credentials and access (logical & physical) is foundational to a successful identity and information access management strategy. The following section describes the identity and access management framework for the reader to better understand the scope of the architecture and the integration to provisioning. The Identity Information Management system (IDIM) comprises the programs, processes, technologies, and personnel used to create trusted digital identity representations of individuals, bind those identities to credentials that may serve as a proxy for the individual, and leverage the credentials to provide authorized access to resources. IDIM cuts across numerous ministries, programs, and systems within government, which are typically directed and managed separately. As a result, many of the aspects of IDIM within the government have traditionally been managed within individual silos. The following figure (Figure 1) provides a high-level overview of the complementary nature of different parts of IDIM and how identity management concepts that were once viewed as silos can intersect to provide a corporate capability. Page 17

Figure 1: IDIM Conceptual Diagram This high-level view of IDIM depicts the interdependencies between each area, which are combined to create a corporate solution. The activities performed in one area are leveraged and built upon in the others. For example, the processes developed and implemented for onboarding and background investigations can be leveraged to establish authoritative data for the creation of a digital identity. The authoritative data, once collected, may be used to populate an Page 18

on-boarding package to generate a credential. The digital identity can also be associated with a credential for enabling various levels of identity authentication as the basis for authorizing access to applications and facilities. Lifecycle management of the digital identity and its related credentials happens outside of those access processes and solutions but helps facilitate a strong level of trust in the enterprise identity when making access control decisions. 3 The existence of clearly established identity enables the recording of the authority under which every transaction is committed for audit and reporting purposes. Behind the technology and the solutions that are deployed is the governance and policies needed for solutions to be successful from a business and security perspective. For example, each activity depicted must also support policies and accommodate remediation activities for individuals denied access or services. This requires long term strategic initiatives across ministries and Broader Public sector which focus on all aspects of IDIM, and not just the technology to be deployed. It also requires the application of trust models across ministries and external entities such as broader public sector, ensuring that assurance levels are uniform for authentication purposes, and defining security policies around authorization and access management. 3 Appendix C Identity Assurance Standard Page 19

4 Provisioning Architecture The following architecture describes four layers that offer different views of the architecture: Business, Data, Service, and Technology. These layers are interrelated and mapped to one another to illustrate the ways in which the different aspects of the architecture impact the others. 4.1 Business Architecture The business architecture is a functional perspective of the operations conducted within the IDIM segment of the enterprise architecture. Enterprise architecture is driven by business management and delivers products that improve the delivery of business services to citizens and government staff. As such, the business architecture provides the main viewpoint for the analysis of data, service components, and technology at the lower layers of the architecture. The provisioning business architecture consists of the following components: Business Value Chain: Identifies the high-level logical ordering of the chain of processes that deliver value. Current state and Target Use Cases: Provide the high-level common business processes that support IDIM functionality. The use cases provide the structure for the detailed architectural information at the Data, Service, and Technology layers of the architecture. Business Value Chain From an architectural perspective, the business processes for User Provisioning include multiple actions that are chained together. The business process chains deliver value through a link back to one or more of the E-Government service domains (G2C, G2B, and IEE). The domains are: External - Government to Citizen (G2C) E-Government aims to facilitate improved interaction between government and the public. E- Government aims to facilitate improved interaction between government and citizens. For example, the delivery of secure citizen e-services using the BCeID registration and authentication services. The provisioning and de-provisioning of this web application access, in particular enabling logical system access through corporate role and rules based access control, is enabled by this architecture. External - Government to Business (G2B) E-Government aims to facilitate improved interaction between government and private sector businesses. For example, the delivery of secure business e-services using the BCeID registration and authentication services. Internal - Efficiency and Effectiveness (IEE) Page 20

This drives internal processes and activities to become more friendly, convenient, transparent, and cost-effective. The GCIO is directing a common approach, processes, attribute models, and toolsets for the provisioning and de-provisioning of logical and physical access of the following internal classes of users: Government Employees, Broader Public Sector Employees Service Contractors and Strategic Service Partners Note: For the purposes of this architecture employees and contractors will collectively be referred to as workers. Use Case and Business Value Chain Overview As the main component of the User Provisioning business architecture, the use cases are not ministry specific and instead are intended to capture the common set of activities and challenges facing government today in the current state and the ways in which those challenges can be addressed in a desired target state. The GCIO will work collaboratively with ministries, agencies and broader public sector to further develop use cases to support their business needs while ensuring alignment with this architecture. Use Case Name 1- Create and maintain digital identity record for internal user E-Government Alignment IEE G2B G2C Use Case Description Provides the high-level process steps for establishing a digital identity for an internal user and modifying the digital identity record over time as the user's attributes change 2- Create, issue, and maintain password Provides the high-level process steps for creating, issuing, and maintaining a password token over the credential lifecycle. 3- Create, issue and maintain a biometric credential 4- Provision and deprovision user account for an application Provides the high-level process steps associated with creating and issuing a biometric credential to a user. Biometric credentials are seen as one of many factors involved in a strong or multi factor authentication or authorization model. Provides the high-level process steps for provisioning and de-provisioning a user account and establishing the access privileges and entitlements for the user in an application Page 21

Use Case Name 5- Grant logical access 6- Create, issue, and maintain Smart Card 7- Create, issue, and maintain PKI credential 8- Grant physical access to worker 9- Provision physical entitlements to an internal user E-Government Alignment IEE G2B G2C Use Case Description Provides the high-level process steps for authenticating and authorizing or denying a user logical access to systems, applications, and data. The use case provides alternate process flows to address authentication mechanisms at all four levels of assurance. Provides the high-level process steps for creating and issuing a Smart Card credential to an employee or contractor and maintaining it over the credential lifecycle. Provides the high-level process steps for creating, issuing, and maintaining a PKI certificate over the credential lifecycle in compliance with PKI standards. Provides the high-level process steps for authenticating and authorizing or denying a worker physical access to a facility or site. Provide the high-level process steps for provisioning & deprovisioning the physical entitlements (e.g. work space, phone, computer etc.) to a worker. Figure 2 : Use Case & Business Value Chain Relationship 4.2 Data Architecture Data architecture is the planning and implementation of data assets including the set of data, the processes that use that data and the technologies selected for the creation and operation of information systems. From a corporate architecture perspective, data architecture is not the set of detailed models of individual systems; instead, it provides the big picture, including the information/data stored across the enterprise, the information that needs to be shared, and the ways in which that information should be shared through the use of exchange standards. The data architecture consists of the following components: Enterprise Data Sources and Data Elements. Describes the major cross-government data repositories, the information contained in them, and the E-Government domains they service. This component is provided in Section 4.2.1 below. Target Information Flow Diagrams. Depicts the key information flows found in the business processes and assists in discovery of opportunities for re-use of information in Page 22

the form of information-sharing services. This component is provided in the use cases in Section 5. 4.2.1 Enterprise Data Sources and Elements Cross-government repositories are those that are used between many ministries or sectors and include systems and data stores. In many cases these may be thought of as the source of truth or the authoritative data source (ADS) for the enterprise. Ministry or sector specific systems are unique to a particular ministry or sector and do not serve as an authoritative source outside of that ministry or sector. Below are examples of these types of data sources and the associated data types and alignment to business value chains. Data Types E-Government Alignment Repository or System Description Personal Info Privileges Access Rules G2B G2C IEE IDIR BCeID IDIR is a government Active Directory user store containing user accounts for all internal BC Government users. It is also the central user directory into which domain dependant services are integrated, including E-Mail (Exchange), collaboration (OCS), file shares, printers and government workstations. An online service that allows the public (Businesses and Citizens) to create and maintain user accounts and use those accounts to access government online services in a secure manner CHIPS A PeopleSoft based system providing HRMS services for BC government employees. TOL The timekeeping system for BC government employees. GTDS Government telephone directory for BC government employees. Meta- Directory A custom identity data synchronization solution that acts as a hub for imports and exports of identity data between corporate systems. Figure 3: Cross Government Repositories and Systems Page 23

4.3 Service Architecture The service architecture provides a functional framework for identifying and evaluating government-wide opportunities to leverage IT investments and assets from a service perspective. This model helps understand the services delivered by the government and assess whether there is an opportunity to group like services and create opportunities for reuse or shared services. The service architecture consists of the Services Framework, a functional framework that describes service components with respect to how they support business and/or performance objectives. The following subsections provide detailed descriptions of each of the service components, categorized by service type. It is important to note that the Services Framework seeks to provide a common set of services to support common needs across ministries, agencies and broader public sector. Provisioning as a service component is found within the Privilege Management service type and may likely interact at some service component level with all other service types depicted. 4.3.1 Services Framework The figure below represents the two main layers of the services framework: Service Type: Provides a layer of categorization that defines the context of a specific set of service components. Service Component: A self-contained business process or service with predetermined and well-defined functionality, which may be exposed through a well-defined and documented business or technology interface. Page 24

IDIM Services Framework Digital Identity Credentialing Privilege Management Identity Proofing Digital Identity Lifecycle Management Linking/Association Master Data Exchange (MDX) Sponsorship Enrollment/ Registration Issuance Credential Lifecycle Management Self Service Account Management Bind/Unbind Provisioning Privilege Administration Resource Attribute/ Metadata Management Authentication Credential Validation Biometric Validation Session Management Federation Authorization & Access Backend Attribute Retrieval (BAE) Policy Administration Policy Decision Policy Enforcement Cryptography Encryption/ Decryption Digital Signature Key Management Auditing & Reporting Audit Trail Reports Management Figure 4: IDIM Services Framework 4.3.2 Digital Identity Service Descriptions Digital identity is the electronic representation of an individual's identity. Digital Identity Services comprise the processes required to capture and validate information to uniquely identify an individual, determine suitability/fitness, and create and manage a digital identity over the lifecycle. These service components will align with the Identity Information Management Standards Package. Service Component Identity Proofing Description Process of verifying sufficient information (e.g., identity history, credentials, documents) to establish an individual s right Page 25

Service Component Description to a claimed identity; initiates chain of trust in establishing a digital identity and binding it to an individual. Digital Identity Lifecycle Management Identity Attribute Discovery Linking/Association Master Data Exchange (MDX) Process of establishing and maintaining the attributes that comprise an individual s digital identity; supports general updates to an identity such as a name change or biometric update. Process of mapping pathways and creating indexes or directories that allows identification of authoritative data sources (ADS) of identity data. Process of linking one identity record with another across multiple systems; activation and deactivation of user objects and attributes as they exist in one or more systems, directories, or applications in response to an automated or interactive process; used in conjunction with Master Data Exchange. For example, for employee working in both government and a HA, the linking of canonical id s in the Health Authority with the government identity record store for employee. Provides capability to connect various authoritative data sources and share identity and other attributes with the shared infrastructure. Note Identity Assurance Std does not apply to this service. 4.3.3 Credentialing Service Descriptions Credentialing is the process of binding an identity to a physical or electronic credential, which can subsequently be used as a proxy for the identity or proof of having particular attributes. Service Component Sponsorship Description Process for establishing the need for a card/credential by an authorized official. Page 26

Service Component Enrolment / Registration Issuance Credential Lifecycle Management Self-Service Description Process of collecting and storing identity information of a person in a registry/ repository; associates the person with minimal information representing the person within a specific context and allows the person to be distinguished from any other individual in the context. For example a PKI cert to an IDIR account or to a BCeID. Process by which possession of a credential is passed to an individual. Service characteristics vary by credential type. Refers to maintenance of a credential and associated support over the lifecycle; common processes include renewal, reissuance, suspension, blocking and unblocking, revocation, etc. Lifecycle support activities vary depending on the credential type, and may include a Self Service component. Request access to logical and physical resources based on established credentials, reset forgotten passwords, update identity and credential status information, and view corporate and organizational identity information using electronic interfaces and without supervisory intervention. 4.3.4 Privilege Management Service Descriptions Privilege Management is the definition and management of policies and processes that define the ways in which the user is provided access rights to resources. It governs the management of the data that constitutes the user s privileges and other attributes, including the storage, organization and access to information in directories. Service Component Account Management Description Supports user account synchronization with application user repositories and authoritative sources; establishes baseline knowledge of the asset being provisioned such as rules for access, credential Page 27

Service Component Description requirements, etc. Bind/Unbind Provisioning Resource Attribute/ Metadata Management Building or removing a relationship between a person s identity and further attribute information on the individual (e.g., properties, status, or credentials). Creating user access accounts and assigning privileges or entitlements within the scope of a defined process or interaction; provide users with access rights to applications and other resources that may be available in an environment; may include the creation, modification, deletion, suspension, or restoration of a defined set of privileges. Process for establishing and maintaining data (such as rules for access, credential requirements, etc.) for a resource/asset being provisioned to define the access, protection, and handling controls. 4.3.5 Authentication Service Descriptions Authentication is the process of verifying that a claimed identity is genuine and based on valid credentials. Authentication typically leads to a mutually shared level of assurance by the relying parties in the identity. Authentication may occur through a variety of mechanisms including challenge/response, biometric comparison, PKI or other techniques. Service Component Description Credential Validation Establishes the validity of the identity credential presented as part of the authentication transaction; PKI certificates are validated using techniques such as revocation status checking and certificate path validation. Validation of other credentials can include PIN check, mutual SSL/TLS, the validation of digital signatures, or other non-biometric and noncryptographic mechanisms. Page 28

Service Component Description Biometric Validation Session Management Federation Services to support capturing, extracting, comparing and matching a measurable, physical characteristic or personal behavioral trait used to recognize the identity or verify the claimed identity of a person. Biometrics modalities include face, fingerprint, and iris recognition and can be matched on card, on reader, or on server. Allows for the sharing of data among multiple relying parties as part of an authenticated user session; includes protocol translation services for access to systems needing different authentication protocols; manages automatic time-outs and requests for re-authentication. Federation is a mechanism for users to authenticate within one organization, and be trusted to use applications within another organization. This is made possible by having the authenticating organization pass a security token that the other organization understands and trusts. The security token contains claims of information about the user s identity and the authenticating organization. See Identity Claims Architecture and Standards for further detail. 4 4.3.6 Authorization and Access Service Descriptions Authorization and Access are the processes of granting or denying specific requests for obtaining and using information processing services or data and to enter specific physical facilities. It ensures individuals can only use those resources they are entitled to use and then only for approved purposes, enforcing security policies that govern access throughout the enterprise. 4 Appendix C Related Standards and Guidance, Identity Information Management Standards Package Page 29

Service Component Backend Attribute Retrieval Policy Administration Policy Enforcement Policy Decision Description Acquires additional information not found in the authenticated credential that is required by a relying party to make an access based decision. Provides a standard policy exchange format to compose, modify, manage, and control access control policies. Restricts access to specific systems or content in accordance with policy decisions that are made. For example coarse grained policy enforcement today is done by the Enterprise Security Gateway (Siteminder). Serves as an access control authorization authority for evaluating access control policies based on a variety of inputs. 4.3.7 Auditing & Reporting Service Descriptions Auditing and Reporting addresses the review and examination of records and activities to assess adequacy of system controls and the presentation of logged data in a meaningful context. Service Component Audit Trail Reports Management Description Capture user management audit and logging data; a record showing who has accessed a system and what operations the user has performed. Group of reports that detail information about users and information systems, user and system activity, identity audit information and identity management related system information; includes ad hoc and standardized reporting. Page 30

4.4 Technical Architecture The technical architecture provides the foundation for the components of the Services Framework, which in turn support the business layer and business-driven approach of the use cases. Specifically, the technical architecture is used to describe proposed technical solutions using a standard vocabulary and categorization scheme. As ministries propose solutions to fulfill the segment, the technical architecture allows those solutions to be analyzed for their fit with the desired target state, for duplication with other efforts, and for the architectural gaps they might fill. In addition, it facilitates the re-use of technology across government. The technical architecture consists of the following component: Target State System Diagrams. Provide a depiction of the high level target state - conceptual solution architecture, which shows the proposed systems and services in the target state and identifies the relationships between them. Standards and technologies listed in the use cases (Section 5) are not normative or exclusive but should be considered prior to implementing local system architectures at a ministry level. In order to maintain government-wide applicability, the technical architecture is provided at a higher level than would typically be expected for a segment. As each ministry aligns with the segment, the technical architecture may be translated to a more detailed level as needed by a ministry to map the specific products and standards supporting IDIM systems to the overarching framework. 4.4.1 IDIM User Perspective In order to achieve the IDIM goals and objectives identified for the Government, system changes must be made at both the ministry and government-wide levels to create increased automation and interoperability within and across IDIM systems. Figure 5 below shows the target system interfaces as viewed from the user perspective. Page 31

Figure 5: Technical Architecture Target State IDIM User Perspective model IDIM functions are handled in the shared infrastructure rather than independently in each system. Authoritative Data Sources (ADS) such as Human Resources (HR) systems are also integrated into the shared infrastructure so that enrolment and provisioning can be automated rather than manually entered through various application specific administrative interfaces. The shared infrastructure also exposes user interfaces so that end user can authenticate to the shared infrastructure once, then access various systems without the need to re-authenticate. The key transition between the current ministry architecture and the target state is the ongoing introduction of a common infrastructure providing IDIM functions in place of independent functionality in every system. The infrastructure should have the following characteristics: The shared infrastructure should provide identity management related services to users, such as authentication, federation, and user self-service. Applications should access the shared infrastructure to leverage shared identity, credentialing, provisioning, authorization, and auditing services. The Master Data Exchange service (MDX) should be used to connect various Authoritative Data Sources (ADS) and share data with the shared infrastructure. Page 32

Users authenticated into the shared infrastructure should have seamless access to all integrated applications for which they have permission to access. Authenticated user will have access to data within infrastructure based on attributes (e.g. roles, entitlements, location, time of day). Page 33

4.4.2 Provisioning Conceptual Diagram The high level diagram below (Figure 6) depicts the target state conceptual provisioning architecture. Figure 6: Provisioning Technical Architecture Target State - Conceptual Model The provisioning system may rely on either Corporate or Sector authoritative data sources to trigger a provisioning event or to exchange data to/from the authoritative source as a result of some other triggered provisioning event. Corporate authoritative data sources may be of enterprise scope in that they are leveraged across the enterprise as the source of truth for particular data. Sector authoritative data sources have authoritative scope for data which is relevant and consumed by a sector or sector members. Provisioning events will create, modify or delete an attribute related to an Identity, Credential, User Account, Logical Access to an Application, or Logical Access to a Physical Resource, on the target resource. Page 34