1
                                             2

                                             3

                        ...
2Washington State Enterprise Architecture Program                                                                         ...
6Washington State Enterprise Architecture Program                                                 March 9, 2007
 7Identity...
10Washington Enterprise Architecture Program                                                 March 9, 2007
 11Identity Man...
13Washington Enterprise Architecture Program                                                 March 9, 2007
 14Identity Man...
16Washington Enterprise Architecture Program                                                    March 9, 2007
 17Identity ...
19Washington Enterprise Architecture Program                                                 March 9, 2007
 20Identity Man...
22Washington Enterprise Architecture Program                                                  March 9, 2007
 23Identity Ma...
25Washington Enterprise Architecture Program                                                    March 9, 2007
 26Identity ...
28Washington Enterprise Architecture Program                                                March 9, 2007
 29Identity Mana...
31Washington Enterprise Architecture Program                                                 March 9, 2007
 32Identity Man...
34Washington Enterprise Architecture Program                                                  March 9, 2007
 35Identity Ma...
37Washington Enterprise Architecture Program                                                   March 9, 2007
 38Identity M...
40Washington Enterprise Architecture Program                                                    March 9, 2007
 41Identity ...
43Washington Enterprise Architecture Program                                                  March 9, 2007
 44Identity Ma...
46Washington Enterprise Architecture Program                                               March 9, 2007
 47Identity Manag...
49Washington Enterprise Architecture Program                                               March 9, 2007
50Identity Manage...
52Washington Enterprise Architecture Program                                                    March 9, 2007
 53Identity ...
55Washington Enterprise Architecture Program                                               March 9, 2007
56Identity Manage...
58Washington Enterprise Architecture Program                                                March 9, 2007
 59Identity Mana...
Upcoming SlideShare
Loading in...5
×

Identity Management Initiative Charter

613

Published on

Published in: Business, Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
613
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
25
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Identity Management Initiative Charter

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

×