identity management initiative charter
DESCRIPTION
TRANSCRIPT
Identity Management InitiativeCharter
ISB Document
Version 2.02.0
Department of Information ServicesEnterprise Architecture Program
Paul Warren Douglas, Acting Chief Enterprise Architect
1110 Jefferson Street SEP.O. Box 42445
Olympia, WA 98504-2445Phone 360/902.3471
Fax 360/[email protected]
Contributors:
Stephen Comfort-MasonAdministrative Office of the Courts
David HamrickDepartment of Transportation
Laura ParmaDepartment of Information Services
Paul Warren DouglasDepartment of Information Services
Initiative Documenter Team
Enterprise Architecture Committee
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
1
Washington State Enterprise Architecture Program March 9, 2007Identity Management Initiative Charter ISB Document—Version 2.0
March 9, 2007 Table of Contents
1. Document History....................................................................................................................... 3
2. Document Context...................................................................................................................... 3
3. Purpose...................................................................................................................................... 3
4. Description of the Initiative..........................................................................................................4
4.1. Introduction.......................................................................................................................... 4
4.2. Background.......................................................................................................................... 4
4.3. Business Drivers.................................................................................................................. 4
4.4. Objectives............................................................................................................................ 5
5. Key Issues or Decisions to be Addressed...................................................................................5
6. Scope: Expected Tier One Components.....................................................................................6
7. Key Stakeholders........................................................................................................................ 7
7.1. Enterprise Architecture Committee Stewards.......................................................................7
7.2. Business Sponsorship..........................................................................................................7
7.3. Documenter Team................................................................................................................7
7.4. Coordination with Related Efforts.........................................................................................8
8. Past Work on this Initiative..........................................................................................................8
9. Schedule: Document Process.....................................................................................................9
9.1. Key Dates............................................................................................................................. 9
9.2. Timeline................................................................................................................................ 9
9.3. Time Commitment of the Documenter Team.....................................................................10
10. Schedule: Review Process.....................................................................................................10
10.1. Key Dates......................................................................................................................... 10
10.2. Timeline............................................................................................................................ 11
11. Evolving a Single, Cohesive Enterprise Architecture..............................................................11
12. Initiative Status Reporting.......................................................................................................11
13. Initiative Sunset...................................................................................................................... 12
14. Glossary.................................................................................................................................. 12
15. References............................................................................................................................. 15
Page 2 of 20
234
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
5
Washington State Enterprise Architecture Program March 9, 2007Identity Management Initiative Charter ISB Document—Version 2.0
1. Document History
Date Version Editor Change
December 14, 2006 1.0 David Hamrick
Laura Parma
Paul Warren Douglas
Initial Draft
January 25, 2007 1.1 Paul Warren Douglas Documenter Team edits
January 25, 2007 1.2 Paul Warren Douglas Documenter Team edits
February 8, 2007 1.3 Paul Warren Douglas Documenter Team edits
February 16, 2007 1.4 Paul Warren Douglas Documenter Team final edits, ready for EAC review
February 28, 2007 1.5 Paul Warren Douglas DT final draft. Ready for EAC endorsement (see Section 2)
March 9, 2007 2.0 Trina Regan ISB approved charter
2. Document Context
This document currently has ISB document status. This status signifies that the document has been adopted by a vote of the Information Services Board. For more information about the ISB Enterprise Architecture Committee and its initiative, please visit the EA Committee website at:
http://isb.wa.gov/committees/enterprise/index.aspx..
3. Purpose
The IDENTITY MANAGEMENT initiative will seek proactive opportunities to build an Enterprise Architecture that guides and optimizes state technology resources. The purpose of this charter is to identify the deliverables, scope, resources, and timelines to achieve the initiatives objectives.
The Enterprise Architecture is defined as a logically consistent set of principles, practices, policies, models, standards, and guidelines that are derived from business requirements that guide decision-making and the engineering of an organization’s information systems and technical infrastructure.
The ISB Enterprise Architecture Standards, Guidelines, and related architectural documents are available at: http://isb.wa.gov/policies/eaprogram.aspx.
Page 3 of 20
678
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
9
Washington Enterprise Architecture Program March 9, 2007Identity Management Initiative Charter ISB Document—Version 2.0
4. Description of the Initiative
4.1. Introduction
The state of Washington is committed to providing an efficient and secure online experience for the public, businesses, and employees in Washington. Each month, millions of ‘users’ access government data and information electronically. Many services are available anonymously, like access to real-time traffic data, or information about an electrician or plumber. Other services; however, require a certain level of user AUTHENTICATION to ensure protection for both the users and the state, and may be external or internal to state government. For example:
External: An individual renews a driver license or ID card, and sets up a Guaranteed Education Tuition accounts for a student. A business owner registers for a license, files reports, and makes tax payments.
Internal: A state employee completes a time sheet, changes a payroll deduction for a retirement plan, sets up an automatic deduction for a charitable organization, or gains access to the network remotely as needed to work on projects after hours.
The primary focus of this initiative is to define an Enterprise Architecture to help guide decision-making and implementations of Identity Management solutions for both internal and external users.
4.2. Background
Identity Management (IdM) exists within the context of a larger subject area known as Identity and Access Management (IAM). IAM includes tools, policies, practices, procedures and applications that manage identities. In addition, IAM manages the identities’ access to a wide range of resources such as applications, data, physical assets, facilities, etc. IAM components include functions and services that fall into two major categories: Identity Management for Administration; and Access Management for Real Time Enforcement.
This initiative addresses statewide TIER ONE services within the area of Identity Management (IdM). It includes descriptions of IdM tools, services and components. Where there is an overlap or an interface between IdM and IAM, descriptions are documented.
4.3. Business Drivers
Business drivers highlight those characteristics that the technology environment must be responsive to, is constrained by, or should be flexible enough to handle. This section identifies several business drivers that influence Identity Management solutions.
Seamless Citizen Access: There is increased emphasis for self service functionality that is transforming the relationship between citizens and state government. Citizens expect unprecedented access to public information with an increase in speed of service delivery.
Privacy and Security: Agencies have a regulatory responsibility to protect the rights and privacy of citizens. This increases the need to secure data and information in all forms on systems and across networks.
Cost Management: Agencies have built a number of Identity Management solutions to establish and manage digital identities that secure access to networks, sensitive information and other business resources. While effective, these non-integrated solutions aren’t necessarily efficient from the constituent’s perspective. System users must remember various identifiers and PASSWORDS, while agencies manage multiple systems to authenticate, authorize, administer, and
Page 4 of 20
1011
71
72
73
74
75
76
77
7879
80
81
8283
84
85
8687
88
89
9091
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
12
Washington Enterprise Architecture Program March 9, 2007Identity Management Initiative Charter ISB Document—Version 2.0
audit user activity. InfoTech Research estimates that 45 percent of help desk calls are related to password reset assistance.
4.4. Objectives
The initiative aims to develop an Identity Management architecture framework that will:
Establish common terminology and key concepts that will help guide the design and development of Identity Management solutions.
Reduce the number of security CREDENTIALS required by a system user to access state resources and services.
Reduce the number of authentications and AUTHORIZATIONs required by a system user to access state resources and services.
Identify state standards to enable interoperability, user convenience, and reduce the number of disparate solutions. Align with ISB policies and standards.
Establish common definitions and IDENTITY PROOFING requirements for varying LEVELS OF ASSURANCE.
Identify common Identity Management services that promote reuse of government resources and minimize system redundancy.
Improve the protection of information resources from fraud and misuse by unwanted intruders.
5. Key Issues or Decisions to be Addressed
The purpose of this section is to document the key issues or decisions to be supported by the architectural components produced by this initiative. Key issues are statements or questions that are to be answered by the architecture. Decisions are statements that reflect the type of strategic technology decisions to be made in consultation to the defined architecture.
The first phase of the Identity Management Initiative will target the baseline (as/is, current) architecture to enable decision-making. Its goal is to gather and document relevant information related to the following questions:
What are the state’s current solutions, what solutions do they provide, how are they architected?
o i.e. Enterprise Active Directory (EAD), SecureAccess Washington™, Transact Washington™, University of Washington, and agency specific solutions as needed.
What components, models, applications, platforms (i.e. mainframe, client/server) and tools are agencies and educational entities currently using to provide IdM solutions?
o i.e. SINGLE SIGN-ON, Microsoft Active Directory, Public Key Infrastructure, Shibboleth, Pubcookie, Kerberos, ADAM/AZMAN, Service Level Agreements, Web services, Federated, External Trust, Secure ID, TOKEN, HRMS SAP, VPN, etc.
What audit and compliance policies exist (federal, state, private etc.) that guide Identity Management?
What requirements are necessary to ensure a successful user experience (i.e. convenience, Single Sign On, usability, accessibility, privacy, etc)?
What are the state’s ISB and EA related policies and standards, including security, audit, etc.?
Page 5 of 20
1314
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
15
Washington Enterprise Architecture Program March 9, 2007Identity Management Initiative Charter ISB Document—Version 2.0
What are the current statutory and regulatory requirements (i.e. RCWs, HIPAA, Sarbanes-Oxley, FERPA, etc)? What are their impacts to baseline and target solutions?
What standards, semantics, protocols, and processing rules enable the components of an identity management solution to interoperate? (i.e. LDAP, Active Directory/ LDAP, X.509, SAML, WS-Security, connectivity protocol, etc.)
What are the current pain points for system administration?
What domain-specific principles, are needed in addition to the EAC principles, to help guide decision-making?
What are the possible business impacts, and how can the business community be engaged in the solutions?
Which agencies, state-level offices, programs, etc. issue their own credentials?
Should the state define common user roles or capture common IDENTITY ATTRIBUTES for Tier One solutions?
What are the benefits of reducing the number of multiple user stores?
What risk criteria, related to IdM, should be used to assist in identification of the risk profile for applications?
6. Scope: Expected Tier One Components
The Identity Management initiative will define a statewide Enterprise Architecture to help guide decision-making and implementations of Identity Management solutions. The outcome of this effort will be a set of deliverables defining the baseline (current, as/is) technology environment and the target (future, to/be) Identity Management Architecture. Together, these deliverables will define principles, policies, models, standards, and guidelines for Identity Management solutions and provide the means to identify gaps and opportunities for future state standards and implementations of state enterprise services.
The Identity Management initiative will produce the following deliverables:
Phase I- Baseline: Documenter Team Deliverables
Identity Management Initiative Charter
Identity Management Domain document
Document existing Solution Sets for:
SecureAccess Washington™
Enterprise Active Directory
Transact Washington™
University of Washington
ROLE-BASED SECURITY implementations, as determined relevant to the Tier One Baseline architecture
Agency specific solutions determined relevant to the Tier One (i.e. ADAM/AZMAN) Baseline architecture
Phase II – Target Architecture: (i.e. Initiate Technical Reference Architecture, identify To/Be Solution Sets, governance, etc.)
Phase III – Gap and Opportunity Analysis: (i.e. Complete Conceptual Technical Reference Architecture, standards, patterns, reuse, etc.)
Page 6 of 20
1617
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183184
185186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
18
Washington Enterprise Architecture Program March 9, 2007Identity Management Initiative Charter ISB Document—Version 2.0
Phase IV – Migration Strategy: (i.e. Migration Strategy, Integration Standards, etc.)
7. Key Stakeholders
This section identifies key stakeholders of the initiative.
7.1. Enterprise Architecture Committee Stewards
Each initiative must have at least one steward from the Enterprise Architecture Committee.
Committee stewards can be considered as the executive sponsors of the initiative. As such, the stewards are responsible for coordinating communication with the Committee, coordinating communication with other executive stakeholders, assisting in removal of obstacles to the initiative’s progress, and assisting in making resources available to the initiative. In all of these responsibilities, the Enterprise Architecture Program will support the stewards as needed.
For this initiative, the stewards are:
David Hamrick, Department of Transportation
Laura Parma, Department of Information Services
Stephen Comfort-Mason, Administrative Office of the Courts
7.2. Business Sponsorship
Initially, this initiative has no additional business sponsorship beyond the Enterprise Architecture Committee and the Information Services Board; however, it has broad participation as noted in Appendix A.
The Enterprise Architecture Committee, Documenter Team members, and other participants will reach out to the business teams to communicate project information and review potential business impacts.
7.3. Documenter Team
The Documenter Team consists of subject-matter experts and other stakeholders that assist the Enterprise Architecture Program in drafting policies, standards, guidelines, and architectural components for Enterprise Architecture Committee endorsement and Information Service’s Board approval.
The term Documenter Team originates from the Documenter role in the National Association of Chief Information Officers (NASCIO) Enterprise Architecture Tool-kit; this is to signify that the team’s objective is to fill (or assist in filling) that role as defined in the framework, not that the team is responsible for all architectural documentation effort in the initiative.
Members of the Documenter Team for this initiative are identified in Appendix A. This initiative will not move forward until all of the roles below are satisfied by the team membership.
Each Documenter Team should ensure that the following roles are sufficiently covered. (These roles and their definitions are taken from the EA Program Management Plan.)
Role Definition/Purpose
Executive Sponsor Communicates with key stakeholders on behalf of the initiative
Ensures the Documenter Team has adequate resources to meet its milestones
Reports on initiative progress to the EA Committee
Page 7 of 20
1920
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
21
Washington Enterprise Architecture Program March 9, 2007Identity Management Initiative Charter ISB Document—Version 2.0
Role Definition/Purpose
Facilitates resolution of issues that cannot be resolved within the team
Subject-Matter Expert
Provides technical expertise in the initiative’s topic areas
Represents communities of interest
Brings best practices and lessons-learned from the statewide IT community to the initiative
Authors artifacts (supported by Architect and Policy Advisor)
Project Manager Monitors and reports initiative’s progress towards milestones
Provides logistical support to Documenter Team (meeting coordination, support resources, etc.)
Facilitates team meetings and ensures maximum meeting productivity/effectiveness
Architect Supports Documenter Team in identifying and using the correct framework artifacts, modeling notations, etc.
Supports executive sponsor in communicating with the EA Committee
Manages submission of team’s artifacts to central EA repository
Provides coordination across Documenter Teams
Authors artifacts (supported by SME and Policy Advisor)
Policy Advisor Supports Documenter Team in creation of Compliance Components (policies, standards, guidelines) in the Technology Architecture
Through artifact review, ensures Compliance Components meet ISB form and content standards
Supports SME and Architect in authoring of artifacts other than Compliance Components
Provides policy-oriented coordination across Documenter Teams
7.4. Coordination with Related Efforts
The Identity Management initiative is not currently related to other efforts; however, this section will be updated to reflect changes as needed. Preferably, representatives from potential related efforts will serve on the initiative’s Documenter Team.
8. Past Work on this Initiative
Several state and local agencies and educational entities have built Identity Management architectural solutions or components that comprise a suite of tools. As identified in the scope, Phase I will focus on documenting these solutions in the form of Solution Sets using the NASCIO Tool-Kit.
Page 8 of 20
2223
237
238
239
240
241
242
243
244
245
246
24
Washington Enterprise Architecture Program March 9, 2007Identity Management Initiative Charter ISB Document—Version 2.0
9. Schedule: Document Process
This section identifies the expected schedule for the initiative’s activities and deliverables in the Document Process.
9.1. Key Dates
This section identifies any key dates to which the initiative must align its activities.
Phase I - Baseline: Will focus on the following deliverables within the identified target dates:
Initiative Charter
February 8, Documenter Team endorsement
February 21, Enterprise Architecture Committee review
February 28, Enterprise Architecture Committee endorsement
March 8, Information Services Board adoption
Solution Sets:
SecureAccess Washington™
Expected May 2007
Enterprise Active Directory
Expected May 2007
University of Washington
Expected May 2007
Transact Washington™
Expected May or July 2007
Identity Management Domain Document
Expected July 2007
Phase II – Target Architecture: (i.e. Initiate Technical Reference Architecture, identify To/Be Solution Sets, identify Standards, identify Governance)
Expected July to September 2007
Phase III – Gap and Opportunity Analysis: (i.e. Complete Conceptual Technical Reference Architecture, identify patterns, identify reuse components, standards)
Expected Completion September 2007
Phase IV – Migration Strategy: (i.e. Migration Strategy, Integration Standards)
Expected Completion November 2007
9.2. Timeline
This section identifies the expected delivery timeline for the initiative’s deliverables. Each enterprise initiative must evolve architectural components (including policies, standards, and guidelines) in accordance with the Architecture Lifecycle documented in the Enterprise Architecture Program’s Program Management Plan. In particular, the evolution of components must follow a progression through specific levels of detail.
This initiative expects to evolve components through the lifecycle levels of detail on the following schedule:
Page 9 of 20
2526
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
27
Washington Enterprise Architecture Program March 9, 2007Identity Management Initiative Charter ISB Document—Version 2.0
Level of Detail Target Milestone Date
Contextual Phase I - March 2007
Conceptual Phase I - March 2007
Conceptual Phase I - May 2007
Phase II – July 2007
Phase III – September 2007
Phase IV - November 2007
Logical November 2007
Physical Generally not conducted at the Tier One state enterprise architecture level, but in Tier Two and Tier Three architectures.
The Enterprise Architecture Committee and Program recognize that by its very nature, the effort to reach architectural milestones is difficult to predict. At the same time, the Committee and Program have established that the Enterprise Architecture must be in the habit of frequently producing valuable deliverables. Therefore, initiatives must practice effective project management techniques, including time boxing of objectives as needed, to remain on-track with this schedule. Schedule deviations must be communicated and coordinated with the Enterprise Architecture Committee.
The target milestone dates listed above are the EA Program’s best estimate at the outset of the Contextual pass. At the conclusion of each level of detail, the Documenter Team and EA Program will have a much better estimate as to the time required to complete the initiative.
9.3. Time Commitment of the Documenter Team
This section sets forth the expectations of the Enterprise Architecture Committee and the Enterprise Architecture Program as to what commitment of time and resources will be requested of team members.
Documenter Team members should expect to devote 3-6 hours per month. The Enterprise Architecture Program is expected to devote 20 hours per week on this initiative.
10. Schedule: Review Process
This section identifies the expected schedule for the initiative’s activities and deliverables in the Review Process. Note that the Review Process need not follow the Document Process sequentially; some of the Review Process milestones may occur during the Document Process timeline.
10.1. Key Dates
Key stakeholder’s meeting schedules are:
Customer Advisory Board (CAB), 4th Monday of each month
CAB Infrastructure – Monthly, 3rd Wednesday of each month
Page 10 of 20
2829
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
30
Washington Enterprise Architecture Program March 9, 2007Identity Management Initiative Charter ISB Document—Version 2.0
EAD Steering Committee – Monthly
WACIRC – Monthly
10.2. Timeline
This section identifies the expected dates for the Review Process milestones. This section conforms to the existing ISB Policy Creation and Update Process maintained by MOSTD, which identifies a Comment and Review followed by an Endorsement Phase.
Phase I – Process Example Activity (note stakeholder group) Date
Comment/Revision Enterprise Architecture Committee review and endorsement of contextual artifact - Charter
Customer Advisory Board review of contextual artifact
February 2007
Information Services Board review of contextual artifact - Charter
Customer Advisory Board notification of contextual artifact
March 2007
Endorsement EAC – Contextual -Charter February 2007
ISB - Contextual - Charter March 2007
11. Evolving a Single, Cohesive Enterprise Architecture
The Enterprise Architecture Committee has established the goal of having all enterprise initiatives evolve a single, cohesive Tier One Enterprise Architecture for Washington State.
Members of the Documenter Team are asked to share in this goal with the Committee and the Enterprise Architecture Program. The Program will provide the coordination, leadership, and consulting expertise to ensure the achievement of this goal through development of standard architecture artifacts with standard tools and housed in a single repository. The Program will also ensure that artifacts from all initiatives are presented to the stakeholder community as a cohesive architecture, in accordance with the Program’s Communications Plan.
12. Initiative Status Reporting
The Enterprise Architecture Program will prepare an initiative status report for each Enterprise Architecture Committee meeting (every other Wednesday). The status report will contain, at a minimum:
Status of initiative versus expected timeline for each level of detail, established above
Page 11 of 20
3132
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
33
Washington Enterprise Architecture Program March 9, 2007Identity Management Initiative Charter ISB Document—Version 2.0
Indicator of whether this status is on track or not
If no progress has been made on the initiative in the past two weeks, the status report will indicate a reason
The Enterprise Architecture Program Director will circulate the status report for review by the Documenter Team.
13. Initiative Sunset
When the Documenter Team, Enterprise Architecture Committee, or Enterprise Architecture Program Director believe the initiative has achieved its initial objectives, the topic of closing out the initiative will be placed on the agenda of the Enterprise Architecture Committee. The initiative will be closed, or not, at the discretion of the Committee.
14. Glossary
ACCESS CONTROL An access control limits the use of a resource. Only those people, programs or devices that are specifically permitted to use the resource will have access. In addition, an access control will usually limit use to specific types of access; someone can read a file but not change it, for example.
ACCESS MANAGEMENT Access Management is the set of technologies, processes, rules, policies, etc. that provides the real-time enforcement of access control. That is, the mechanisms and procedures by which access to systems, applications, services, etc. is permitted to some users and not to others. This can operate at the macro level: e.g. all state employees (and only state employees) may access a given resource. It can also be implemented with fine granularity: e.g. certain people in DIS are permitted access to the DIS Groups Management System, but of these only a few may create new Groups, and once a Group is created, only a subset of those people are permitted to manage content on the Group site.
AUTHENTICATION Validation of identification credentials. This is a process where a person, device or a computer program proves their identity in order to access environments, systems, resources and information. The person’s identity is a simple assertion, the login ID for a particular computer application, for example. Proof is the most important part of the concept and that proof is generally something known, like a password; something possessed, like your ATM card; or something unique about your appearance or person, like a fingerprint.
AUTHORIZATION The act of granting a person or other entity permission to use resources in a secured environment. This is usually tightly linked to authentication. A person or other identity first authenticates and then is given pre-determined access rights. They now have the authority to take specific actions.
CA A CERTIFICATION AUTHORITY holds a trusted position because the certificate that it issues binds the identity of
Page 12 of 20
3435
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
36
Washington Enterprise Architecture Program March 9, 2007Identity Management Initiative Charter ISB Document—Version 2.0
a person or business to the public and private keys (asymmetric cryptography) that are used to secure most internet transactions.
CREDENTIALS Credentials are the components or attributes of identity that are assessed to prove a person, device, or computer program is who they claim to be. Common credential stores include databases, directories and smart cards.
DIGITAL CERTIFICATE In general use, a certificate is a document issued by some authority to attest to a truth or to offer certain evidence. A digital certificate is commonly used to offer evidence in electronic form about the holder of the certificate. In PKI it comes from a trusted third party, called a certification authority (CA) and it bears the digital signature of that authority.
DIRECTORY SERVICE A directory service, in the technical sense, is very much like a directory service in the real world. A real-world directory service lets you look up a telephone number when you know someone’s name and location. In the same way, directory services on computers let you look for other computers, e-mail addresses, files and folders, and many other objects and attributes.
IDENTIFICATION Represents the use of an identifier that allows a system to recognize a particular subject and distinguish it from other users of the system.
IDENTITY ATTRIBUTES Identity information collected during identity proofing for future use by the system. In this instance, identifying information (i.e., employer name, job title, affiliations, etc) carried in a claim to help distinguish an individual’s rights to a system.
IDENTITY MANAGEMENT Identity Management is the set of technologies, practices, and procedures that create and assign an identity credential to an individual person, computer, or asset. These may include: identity proofing procedures, account provisioning/credential creation and issuance, password setup, password strength rules, level-of-assurance assessment, password change management (self-service, helpdesk-mediated), password expiration, identity matching, authentication role management, rights management, metadirectory management, etc. All of this serves to support a more or less reliable assertion that a given credential belongs to a known person, and to the extent they keep their credential private, is used only by that person.
IDENTITY PROOFING Identity proofing is the process of validating the claimed identity of an individual. It is central to a secure and authoritative process for the issuance and use of identity credentials.
Identity proofing can be accomplished through a variety of processes that establish a history of identity by collecting identity information (e.g. personal, demographic, and biographical information) and
Page 13 of 20
3738
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
39
Washington Enterprise Architecture Program March 9, 2007Identity Management Initiative Charter ISB Document—Version 2.0
validating the accuracy and legitimacy of the information collected by conducting a face-to-face interaction and/or verifying the validity of identity source documents against third-party databases.
LEVEL OF ASSURANCE Level of Assurance describes the degree of certainty that the user has presented a valid set of identifier attributes (credentials, etc.) that refer to his or her identity. In this context, assurance is defined as:
The degree of confidence in the vetting process used to establish or validate the identity of the individual to whom the credential was issued, therefore establishing the degree of confidence (assurance) the person who accepts the credential should have, that the provider is the individual to whom the credential was issued.
METADIRECTORY MANAGEMENT The set of technologies, processes, rules, policies, etc. that facilitate the consolidation, creation and management of central repositories for verification of user identity, data and access control). This can be a physical or virtual directory implementation.
PASSWORD MANAGEMENT Processes, functions and features involved in the creation, issuance, control and change of identity credentials.
PROVISIONING Account provisioning describes the tasks and framework for authorizing and documenting access, privileges and rights. Provisioning components span across both Administration (IdM systems) and Real-Time Enforcement (Access Management).
PKI Public-Key Infrastructure is the infrastructure needed to support asymmetric cryptography. At a minimum, this includes the structure and services needed to do the following:
• Register and verify identities
• Build and store credentials
• Certify the credentials (issue digital certificates)
• Disseminate the public key
• Secure the private key and yet make it available for use
ROLE-BASED SECURITY Authorization to system resources based on a users defined role within the system. Role definitions are typically unique to a system (i.e., Admin, Reader, Writer, etc) and provide access control to restricted resources. Additionally, Group Security is the ability to assign a role or access controls to a group of users.
ROLE MANAGEMENT The creation and management of user roles, affiliations, relationships, etc. that drive access rights and entitlements.
SSO Single sign-on describes the ability to use one set of credentials, an ID and password or a passcode for example, to authenticate and access information across
Page 14 of 20
4041
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
42
Washington Enterprise Architecture Program March 9, 2007Identity Management Initiative Charter ISB Document—Version 2.0
system, application and even organizational boundaries. It may be called Web SSO when everything is accessed through a browser.
TIER ONE Business processes, data, or technologies that are common for the state. The various elements that are defined in the statewide Enterprise Architecture are comprised of business processes, data, or technologies. Those EA elements can be categorized into different tiers depending on the degree to which they should be common, and what other entities with which they should be common. A description of the state’s Tiers is available at: http://isb.wa.gov/committees/enterprise/concepts/
TOKEN A token (sometimes called a security token) is an object that controls access to a digital asset. Traditionally, this term has been used to describe a hardware authenticator, a small device used in a networked environment to create a one-time password that the owner enters into a login screen along with an ID and a PIN. However, in the context of web services and with the emerging need for devices and processes to authenticate to each other over open networks, the term token has been expanded to include software mechanisms, too.
15. References
NASCIO National Association of Chief Information Officers, Enterprise Architecture Tool Kit v 3, October 2003.
Page 15 of 20
4344
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
45
Washington Enterprise Architecture Program March 9, 2007Identity Management Initiative Charter ISB Document—Version 2.0
Appendix A: Documenter Team
This document was developed through the enterprise architecture Identity Management initiative, chartered March 8, 2007. The following individuals were members of the Documenter Team for this initiative, and participated in review of this document.
First Last Company Email Phone RoleKent Andrus Office of
Financial Management
360-664-7767 SME
Mark Borgaard Employment Security Department
360-438-4710 SME
Scott Boyd Legislative Service Center
360-786-7055 SME
Doug Buster Department of Social and Health Services
360-902-7509 SME
Kyle Chandler Department of Revenue
[email protected] 360-586-7913 SME
Dan Cole Office of Financial Management
360-902-0624 SME
Jeff Colorossi Department of Personnel
[email protected] 360-664-6361 SME
Stephen Comfort-Mason
Administrative Office of the Courts
360.705.5236 Steward
Brian Criss Department of Information Services
[email protected] 360-902-3555 SME
Jim Cristofono Community, Trade, and Economic Development
[email protected] 360.725.2712 SME
Marjorie Dausener Department of Labor and Industries
360-902-5659 SME
Mark Delaplane Department of Labor and Industries
[email protected] 360.902.5892 SME
John Ditto Department of Information Services
[email protected] 360-902-0349 SME
Chuck Dorsett Department of Transportation
360-705-7624 SME
Paul Douglas Department of Information Services
[email protected] 360-902-3471 Acting Chief Enterprise Architect
Gary Dubuque Department of Revenue
[email protected] 360-586-7981 SME
Yousef Fahoum Department of Health
360-236-4499 SME
Page 16 of 20
4647
511
512
513
514
48
Washington Enterprise Architecture Program March 9, 2007Identity Management Initiative Charter ISB Document—Version 2.0
First Last Company Email Phone RoleDan Francis Department of
360-236-4425 SME
Mike Frost Department of Social and Health Services
360-902-7506 SME
Tom Gigstead Office of Financial Management
360-664-7759 SME
Phil Grigg General Administration
[email protected] 360 902-7452 SME
Robin Griggs Department of Licensing
[email protected] 360-664-6537 SME
David Hamrick Department of Transportation
360-705-7602 Steward
Peter Jekel Department of Corrections
360-725-8471 SME
Joanna Jones Department of Transportation
360-705-7414 SME
Agnes Kirk Department of Information Services
[email protected] 360-902-3488 SME
Ila Kowalski Department of Personnel
[email protected] 360-664-9924 SME
Roger LaPrelle Liquor Control Board
[email protected] 360.664.1755 SME
Sharie McCafferty Department of Health
360-236-4432 SME
Fred McDowell Legislative Service Center
360-786-7034 SME
Randy Moore Department of Ecology
360-407-6598 SME
David Morris Department of Information Services
[email protected] 360-725-5218 SME
Miles Neale Department of Ecology
360-407-6592 SME
Bill Norris Department of Health
360-236-4426 SME
Laura Parma Department of Information Services
[email protected] 360-725-5321 Steward
Karen Peterson Department of Information Services
[email protected] 360-902-3123 SME
Julian Pietras South Puget Sound Community College
[email protected] 360-596-5272 SME
Aaren Purcell Employment Security Department
360 438-4742 SME
Pat Ramsdell Washington State Patrol
360 705-5170 SME
Trina Regan Department of [email protected] 360-902-2975 SME
Page 17 of 20
4950
51
Washington Enterprise Architecture Program March 9, 2007Identity Management Initiative Charter ISB Document—Version 2.0
First Last Company Email Phone RoleInformation Services
Laurie Ross Department of Transportation
[email protected] 360-705-7602 SME
John Sadie Department of Social and Health Services
360-902-8486 SME
Cliff Schiller Department of Labor and Industries
[email protected] 360-902-5856 SME
Carl Schwarmann Department of Revenue
[email protected] 360-596-3685 SME
Debbie Stewart Department of Ecology
360-407-7048 SME
Ian Taylor University of Washington
206-543-3565 SME
Lyle Tillett Department of Retirement Systems
[email protected] 360-664-7106 SME
Corey Wade Washington State Patrol
360 705-5196SME
Bill Wildprett Community, Trade, and Economic Development
[email protected] 360-725-2863 SME
Appendix B: Review Log
The following feedback on this document was received by the Enterprise Architecture Program; the response to each contribution is noted below.
Review by whom and when
Contribution Response
Documenter Team
January 25, 2007
Changed title to Identity and Access Management
Incorporated various documenter team edits,
Clarified introduction, and objectives
Moved Key Questions and Scope closer to Introduction and Objectives
Incorporated into document
Documenter Team comments
Added Section 3. Purpose
Added Glossary entries
Modified Background/Business Drivers
Modified Objectives to clearly state
Incorporated into document
Page 18 of 20
5253
515
516
517
518
54
Washington Enterprise Architecture Program March 9, 2007Identity Management Initiative Charter ISB Document—Version 2.0
the project objectives.
Changed document title and body to Identity Management, removed ‘and Access’
Added new separate definitions for Identity Management and Access Management
Minor changes for punctuation and grammar
Changed University of Washington to University of Washington Solution Set
Synchronized Section 6 Scope with Section 9.2 Timeline
Changed Glossary entry for Level of Assurance
Edits to Purpose, Objectives, Key Issues, Scope
Next phases to be determined, and provided a general outline of expected deliverables
Modified template language to read like a charter
Modified expected dates for Phase I deliverables
Added additional Glossary Terms
Formatted first instance of each term within document that is in Glossary
Added Background section to describe Identity and Access Management
Refined Background section
Minor edits to Business Drivers, to remove solutions
Modified and clarified Phases, and Milestones. Added target completion dates for each phase.
Added Tier One description to Glossary
Documenter Team Comments
February 16, 2007
Changed Education to University of Washington Solution Set
Added identification of user needs to Key Issues or Decisions section
Incorporated into document
Page 19 of 20
5556
57
Washington Enterprise Architecture Program March 9, 2007Identity Management Initiative Charter ISB Document—Version 2.0
Minor editorial changes
Added requirements for successful user experience to Key Issues or Decisions
Moved user roles and common identity attributes from Objectives to Key Issues or Decisions
Added reference to Phases II-IV in Section 6. Scope
Added Glossary entries for Identity Attributes, Role-Based and Group Security
Renamed NASCIO Framework, NASCIO Tool-Kit
Glossary edits to Identity Management, Access Management, and Level of Assurance
EAC comments from 2/21 Committee meeting, DT minor edits from 2/22 meeting
Add questions to Section 5
Aligned with ISB, EA, and audit and security policies
Added additional alignment with business teams
Modified Phases
Modified expected target dates
Incorporated into document
Page 20 of 20
5859
519
60