diff --git a/Access Control/PBAC-final.md b/Access Control/PBAC-final.md index c70e565..4177d47 100644 --- a/Access Control/PBAC-final.md +++ b/Access Control/PBAC-final.md @@ -1,12 +1,9 @@ -# Introduction to Policy-Based Access Controls (v2) - By Mary McKee -© 2022 IDPro, Mary McKee +© 2021, 2022, 2023 IDPro, Mary McKee -*For a primer on access controls, please see André Koot’s -[Introduction to Access -Control](https://bok.idpro.org/article/id/42/).* +*Please see André Koot’s [Introduction to Access Control for a primer +on access controls](https://bok.idpro.org/article/id/42/).* *To comment on this article, please visit our [GitHub repository](https://github.com/IDPros/bok) and [submit an @@ -20,107 +17,110 @@ technology and seek protection from more sophisticated threats, access management strategies are evolving to address modern concerns. Most early access management systems utilize what we now refer to as -**Discretionary Access Control** (**DAC)**.  With DAC systems (such as +**Discretionary Access Control** (**DAC)**. With DAC systems (such as access control lists), administrators manually assign privileges to users according to their understanding of need, appropriate use, and -organizational rules.  As DAC systems grow in users, resources, +organizational rules. As DAC systems grow in users, resources, administrators, and/or age, their reliance on ad hoc management leads to -inconsistencies in application and understanding of access.  As +inconsistencies in application and understanding of access. As inappropriate access often goes unnoticed and insufficient access creates visible business challenges, DAC administrators are increasingly incentivized to be liberal with authorizations and conservative with -access cleanup.  As a result, DAC is often too costly, too inconsistent, +access cleanup. As a result, DAC is often too costly, too inconsistent, and too inflexible for modern needs. Contemporary access control systems aim to promote consistency and -efficiency by granting access to resources through structured rules.  +efficiency by granting access to resources through structured rules. Perhaps the best-known model for abstracting access control so that permissions are based on rules is known as **Role-Based Access Control -(RBAC)**.  Through RBAC, permissions are associated with “roles” which -are assigned to users.  This model is effective in ensuring that users -with the same responsibilities are consistently granted the same -permissions and encourages governance by requiring that roles and their -associated permissions be defined before they can be used.  Further, -RBAC is suitable for use in federated authorization scenarios where -resource permissions depend on the information provided by an external -user authority. While these are improvements over DAC, RBAC permissions -are not resilient against shifts in responsibility structure within an -organization and are limited in how permissions can be defined.  These -drawbacks, covered later in this article, make it difficult for RBAC -systems to ensure that users do not have more access than they need to -perform intended business functions (also known as the *principle of -least privilege*\[1\]). +(RBAC)**. Through RBAC, permissions are associated with “roles” assigned +to users. This model effectively ensures that users with the same +responsibilities are consistently granted the same permissions. It +encourages governance by requiring that roles and their associated +permissions be defined before they can be used. + +Further, RBAC is suitable for use in federated authorization scenarios +where resource permissions depend on the information provided by an +external user authority. While these are improvements over DAC, RBAC +permissions are not resilient against shifts in responsibility structure +within an organization and are limited in how permissions can be +defined. These drawbacks, covered later in this article, make it +difficult for RBAC systems to ensure that users do not have more access +than they need to perform intended business functions (also known as the +*principle of least privilege*[1]). **Policy-Based Access Control (PBAC)** is a more robust paradigm for managing permissions through structured rules in federated or -non-federated contexts.  +non-federated contexts. While the RBAC model intentionally bundles permissions, PBAC builds on a concept known as **Attribute-based Access Control (ABAC)** to automate fine-grained, decoupled permissions. Leveraging ABAC’s approach of calculating permissions based on user information such as a job code or employment status, PBAC provides increased precision by supporting -appropriate conditions (or context) for access. +appropriate access conditions (or context). -# Terminology +Terminology +----------- - - **Access control system** – a structure that manages and helps +- **Access control system** – a structure that manages and helps enforce decisions about access within an organization. - - **User** or **Subject** – a person or entity who may receive access +- **User** or **Subject** – a person or entity who may receive access within an access control system. - - **Resource** or **Object** – an asset protected by access controls, +- **Resource** or **Object** – an asset protected by access controls, such as an application, system, or door. - - **Action** – a protected operation available for a resource, such as +- **Action** – a protected operation available for a resource, such as “view”, “edit”, or “submit”. - - **Permission** – a statement of authorization for one or more +- **Permission** – a statement of authorization for one or more subjects to perform one or more actions on one or more objects. - - **Context** – conditions under which an action on a resource is +- **Context** – conditions under which an action on a resource is authorized for a subject, such as time of access, location of access, or a compliance state. - - **Federated access controls** – an access control architecture that - accommodates separation of user/subject authority and +- **Federated access controls** – an access control architecture that + accommodates the separation of user/subject authority and resource/object authority. - - **Discretionary access control** – a pattern of access control +- **Discretionary access control** – a pattern of access control system involving static, manual definitions of permissions assigned directly to users. - - **Role-based access control** – a pattern of access control system +- **Role-based access control** – a pattern of access control system involving sets of static, manual definitions of permissions assigned to “roles”, which can be consistently and repeatably associated with users with common access needs. - - **Attribute-based access control (“ABAC”) / Claims-based access +- **Attribute-based access control (“ABAC”) / Claims-based access control (“CBAC”)** – a pattern of access control system involving dynamic definitions of permissions based on information - (“attributes”, or “claims”), such as job code, department, or - group membership. + (“attributes”, or “claims”), such as job code, department, or group + membership. - - **Policy-based access control** – a pattern of access control system +- **Policy-based access control** – a pattern of access control system involving dynamic definitions of access permissions based on user attributes (as in ABAC) and context variables for permitting or denying access. - - **Principle of least privilege** – an information security best +- **Principle of least privilege** – an information security best practice ensuring that users in an access control system do not have more access to resources than is necessary for their intended activities. - - **Segment** – a grouping of subjects that may be useful for +- **Segment** – a grouping of subjects that may be useful for authorizations, such as full-time employees, undergraduate students, IT administrators, or clinicians. - - **Abstraction** – the practice of identifying and isolating repeated +- **Abstraction** – the practice of identifying and isolating repeated aspects of operations or business logic so that they can be maintained in one place and referenced in many places. -# PBAC vs. RBAC: A Comparison +PBAC vs. RBAC: A Comparison +=========================== To better understand PBAC structures, it may be helpful to examine how they differ from RBAC. @@ -128,106 +128,108 @@ they differ from RBAC. While the primary focus of RBAC permissions is the user, the primary focus for PBAC permissions is the resource. -RBAC asks, “what types of users do I have, and what may they do in my -environment?”.  Controls are constructed with **subjects** (who is +RBAC asks, “What types of users do I have, and what may they do in my +environment?”. Controls are constructed with **subjects** (who is getting access), **permissions** (what is being accessed or used), and -**roles** (what permissions can be assigned to a subject)\[2\].  This -looks like: +**roles** (what permissions can be assigned to a subject)[2]. This looks +like: | | | | | | |-------------|-----|----------|-----|------------------| | **Subject** | | **Role** | | **Permission** | | Ada | as | Editor | may | Modify Documents | -PBAC asks, “what types of resources do I have, and who/how may they be -used or managed?”.  Controls are constructed with **subjects** (who is +PBAC asks, “What types of resources do I have, and who/how may they be +used or managed?” Controls are constructed with **subjects** (who is getting access), **actions** (what behavior is being discussed), **objects** (what resource is being accessed or used), and **context** -(environmental or other parameters defining acceptable access)\[3\].  -This looks like:  +(environmental or other parameters defining acceptable access)[3]. This +looks like:  | | | | | | | |------------|--------|------------|-----|------------------------------|--------------------| | **Object** | | **Action** | | **Subject** | **Context** | -| Documents | may be | Modified | by | Those with “Editor” job code | On managed devices | +| Documents | may be | Modified | by  | Those with “Editor” job code | On managed devices | Both examples abstract subjects to ensure that all editors are granted -the necessary permission.  In the RBAC example, Ada acquires the +the necessary permission. In the RBAC example, Ada acquires the permission because she has been assigned to the “Editor” role through a -manual or automated process.  In the PBAC example, Ada acquires the +manual or automated process. In the PBAC example, Ada acquires the permission because the subject definition matches her employee record, though the subject definition could also be a manual process, such as the assignment of a group membership. To make the most apples-to-apples comparison, imagine that an RBAC -system adds Ada to an “Editor” role and a PBAC system adds her to an -“Editor” group membership that is referenced in access policies.  -Though these actions may seem nearly equivalent, the PBAC architecture -offers the following advantages: the flexibility to support different +system adds Ada to an “Editor” role, and a PBAC system adds her to an +“Editor” group membership that is referenced in access policies. Though +these actions may seem nearly equivalent, the PBAC architecture offers +the following advantages: the flexibility to support different situations (context), the ability to discretely handle changes without impacting other permissions (modularity), and the capacity to handle real-time permission evaluation (symmetry). Each of these factors promotes an organizationally consistent and defensible approach to access control, as illustrated by the following examples: -## Context  +Context  +-------- Ada’s employer may be subject to legal or compliance concerns that -affect how resources may be accessed.  For example, when national +affect how resources may be accessed. For example, when national security regulation (such as export controls) restricts access from certain types of devices, relevant PBAC policies can be amended to include this stipulation. If the company requires some form of training before resources can be -accessed, this too can be articulated as context.  A “certification +accessed, this too can be articulated as context. A “certification status” attribute can be maintained for Ada based on records referenced from within or outside the authorizing organization. Ada’s permissions -can require that this status is current at the time of access.  Instead +can require that this status is current at the time of access. Instead of laborious audit processes or managing infrastructure to revoke and reassign permissions as compliance states change, Ada’s access is automatically blocked when she is not compliant with training and -automatically restored when she re-certifies her training.  Similarly, -if Ada must consent to terms and conditions for the access she has been +automatically restored when she re-certifies her training. Similarly, if +Ada must consent to terms and conditions for the access she has been granted, PBAC context can ensure that this has occurred in advance of any interaction with the resource. For security reasons, Ada may be expected to only access company resources from safe-listed network spaces or with multi-factor authentication requirements that are more stringent than those of users -with lesser permissions.  By codifying and enforcing these requirements +with lesser permissions. By codifying and enforcing these requirements within the scope of the permission, Ada’s employer can easily reference, manage, and adapt all access requirements in a single place. -## Modularity +Modularity +---------- Because permissions granted by PBAC policies are not inherently interconnected as they are with RBAC, they are highly modular and easier -to manage with confidence.  When an organization needs to add, remove, -or modify controls on a resource, policies for that resource can be -adapted exactly as needed without impact on other resources. +to manage with confidence. When an organization needs to add, remove, or +modify controls on a resource, policies for that resource can be adapted +exactly as needed without impacting other resources. When permissions are bundled together, as in RBAC, accommodating new business scenarios requires a broad analysis of existing permission -groupings.  Often, administrators are forced to choose between a “close -enough” access bundle that carries unneeded permissions with it, or -contributing to a proliferation of bundles that becomes increasingly +groupings. Often, administrators are forced to choose between a “close +enough” access bundle that carries unneeded permissions with it or +contributing to a proliferation of bundles that become increasingly difficult to understand and maintain. For example, if senior leadership at Ada’s company selected her to edit sensitive briefings for their investors, it is likely that she would -need access atypical for editors.  An RBAC system admin charged with +need access atypical for editors. An RBAC system admin charged with granting this access is likely to consider solutions such as: - - > Giving all editors the access Ada now needs, thus over-privileging +- Giving all editors the access Ada now needs, thus over-privileging > other editors. - - > Granting Ada a senior leadership role in addition to the editor +- Granting Ada a senior leadership role in addition to the editor > role, thus over-privileging Ada. - - > Creating a new role for permissions specific to this need, setting - > a precedent of provisional role creation for ad hoc needs. +- Creating a new role for permissions specific to this need, setting a + > precedent of provisional role creation for ad hoc needs. - - > Re-engineering roles to offer a cleaner solution for this business +- Re-engineering roles to offer a cleaner solution for this business > scenario, typically a costly exercise. Organizations with evolving access needs will generally not find it @@ -236,24 +238,25 @@ represented by an existing role. The alternatives – over-privileging or over-complicating – promote an increasingly lackadaisical approach to access management within the organization. -## Symmetry +Symmetry +-------- -When there is a divergence between criteria for granting access and +When there is a divergence between the criteria for granting access and criteria for revoking access in a system, it is common for the system to accumulate permissions that were at one time appropriate but would not be allowed under current policy. PBAC systems are not susceptible to -this permission spread because access control decisions are made in real -time based on current attributes and context. +this permission spread because access control decisions are made in +real-time based on current attributes and context. Since PBAC is an extension of ABAC, PBAC controls easily accommodate -fully or partially automated access based on attributes.  An institution +fully or partially automated access based on attributes. An institution may wish to automatically grant access to any current employee of a -company, or any employee who works at Office X, or any employee who -works at Office Y and is not currently on personal leave.   +company, any employee who works at Office X, or any employee who works +at Office Y and is not currently on personal leave. Automating how access is assigned simplifies the tasks of automating continuous monitoring of permission validity and revoking permissions -that are no longer allowable under current rules.  This creates symmetry +that are no longer allowable under current rules. This creates symmetry between provisioning and deprovisioning of access, minimizing system maintenance and remnant permissions. @@ -262,7 +265,7 @@ PBAC is Practical PBAC scales well because it is adaptable, and this adaptability can make it a practical option for organizations of any size. Time saved with streamlined RBAC roles can be quickly lost if the business impact of -modifying a role (or its many associated permissions) is unclear.  This +modifying a role (or its many associated permissions) is unclear. This can disincentivize active and responsible management of access controls and hamper growth in an organization of any size. @@ -270,26 +273,26 @@ To illustrate how PBAC can be preferable even in a small organization, consider the following scenario: JE Plumbing starts as a small business comprised of five plumbers and an -owner who handles all administration.  +owner who handles all administration. Thanks to an excellent reputation and growing customer base, the owner -is able to expand the staff to twenty plumbers who are supported by a +is able to expand the staff to twenty plumbers, who are supported by a business manager, three sales representatives, and two finance specialists. Over time, JE Plumbing sees an opportunity to expand the company’s -coverage area and offerings.  To accomplish this, they set up two new +coverage area and offerings. To accomplish this, they set up two new locations overseen by two new business managers (one of whom was an -internal promotion from a finance specialist position).  They grow their +internal promotion from a finance specialist position). They grow their residential plumber staff to seventy-five and hire twenty-five -commercial plumbers.   Finance and sales positions are replicated across -the two new offices, growing that team from two to six.  A dedicated +commercial plumbers. Finance and sales positions are replicated across +the two new offices, growing that team from two to six. A dedicated marketing specialist is hired to cover all three sites. An RBAC approach to this problem might start with two roles: an admin -role for the owner and a technician role for her staff.  As the company +role for the owner and a technician role for her staff. As the company grows, a business manager might be trusted with the admin role, but new -roles would need to be created for the sales and finance specialists.  +roles would need to be created for the sales and finance specialists. After doubling from two to four roles, the role count doubles again as the company splits the technician role into commercial technician and residential technician, splits the sales and marketing role into @@ -298,7 +301,7 @@ service, and retains the original admin and finance roles. Though this example looks at JE Plumbing’s development at three points in time, it is unlikely that the company would implement such broad -shifts overnight.  To preserve security through incremental shifts in +shifts overnight. To preserve security through incremental shifts in responsibility, a small business making strategic organizational adjustments with limited working capital should consider the absence of a role not included in this exercise: that of a full-time IT @@ -308,15 +311,15 @@ structures and adapt each system utilizing them. By contrast, a PBAC approach would start by looking at what resources JE Plumbing needs to secure: work orders, customer information, invoices, inventory, employee personal and licensing information, payroll data, -and expense reports.  Though responsibility for these functions changes -as the company adds staff, the functions themselves remain the same.  If -the company expanded the nature of their business in addition to the +and expense reports. Though responsibility for these functions changes +as the company adds staff, the functions themselves remain the same. If +the company expanded the nature of its business in addition to the scale, permissions could easily be added to support the new functions without interfering with existing functions. This simple shift from expressing access controls from user-focused to resource-focused allows for access control complexity to grow linearly -rather than exponentially.  As a result, JE Plumbing can adapt +rather than exponentially. As a result, JE Plumbing can adapt permissions in step with organizational shifts without managing a ballooning number of roles.  @@ -324,29 +327,29 @@ In addition to being more sustainable, PBAC also creates opportunities for the company to reduce risk by setting the context for access. For example: - - When technicians can see all customer information, customers are at +- When technicians can see all customer information, customers are at risk of privacy violations, and the company is at risk of an employee exfiltrating that information to help them start their own - competing company.  Perhaps technicians need to see addresses to + competing company. Perhaps technicians need to see addresses to navigate to job sites but only need to see information associated - with open jobs assigned to them.  Customer service may need to see + with open jobs assigned to them. Customer service may need to see phone numbers and email addresses for all customers but may not need address information. - - Only technicians making rounds need access to job information from +- Only technicians making rounds need access to job information from out of the office, so restricting other users’ access to internal IP addresses is an easy way to reduce the cyberattack surface for the company’s systems. - - Overexposure of work order information encourages employee +- Overexposure of work order information encourages employee speculation about how the business is being run, which can result in misunderstandings or inappropriate disclosures about operational practices. - - When technicians can be assigned to jobs at a business manager’s +- When technicians can be assigned to jobs at a business manager’s discretion, there is a risk of a technician being sent on the job - with a lapsed license.  Policy-based permissioning can require valid - licensing before job assignment can occur. + with a lapsed license. Policy-based permissioning can require valid + licensing before a job assignment can occur. Although organizations with modest access management needs may initially choose to forgo PBAC features such as context limitations on access @@ -355,7 +358,8 @@ allows for an organic and natural maturation of access management rules over time - whether it be to accommodate more users, more resources, and/or a more sophisticated security or risk management posture. -# When RBAC is Preferable +When RBAC is Preferable +======================= This article has primarily compared policy-based access controls to role-based access controls due to the prominence of RBAC as an access @@ -378,16 +382,17 @@ action results in the application of a defined set of permissions. Conversely, options for applying a notion of context to RBAC permissions are often limited. -While the increased flexibility and scalability of PBAC makes it a -strong choice for protecting sensitive resources, it may be less -approachable for casual users of an access management system. Systems -with straightforward and fairly static access controls and especially -those that delegate access management to end users rather than -administrators (such as those where content creators can authorize -collaborators) may find that the intuitiveness of a system like RBAC is -more advantageous than the flexibility of PBAC. +While the increased flexibility and scalability of PBAC make it a strong +choice for protecting sensitive resources, it may be less approachable +for casual users of an access management system. Systems with +straightforward and fairly static access controls, especially those that +delegate access management to end users rather than administrators (such +as those where content creators can authorize collaborators), may find +that the intuitiveness of a system like RBAC is more advantageous than +the flexibility of PBAC. -# Implementing PBAC +Implementing PBAC +================= The key to building a successful access control environment is accommodating changing business requirements. To promote ease and @@ -397,29 +402,29 @@ nor too abstract. To achieve this balance in a PBAC implementation, consider the following guiding principles: -## Build Reusable Components +Build Reusable Components +------------------------- Managing abstraction in PBAC means isolating parts of your policies that -may be applicable to other policies.  The most obvious place where this -applies is with user segmentation.  +may be applicable to other policies. The most obvious place where this +applies is with user segmentation. For example, if you are constructing a policy to say that: | | | | | | | |---------------|--------|------------|-----|-------------------|-------------------------| | **Object** | | **Action** | | **Subject** | **Context** | -| User profiles | may be | Updated | by | Business managers | For full-time employees | - +| User profiles | may be | Updated | by  | Business managers | For full-time employees | “Business managers” and “full-time employees” are very likely to be used -again in other policies.  Thus, creating a definition for these segments +again in other policies. Thus, creating a definition for these segments that can be used by one or more policies is wise. The ideal way to avoid these definitions becoming too granular and rigid is through access management system implementations that allow for set logic - particularly intersections (membership in set A AND set B), unions (membership in set A OR set B), and complements (membership in -set A, BUT NOT set B).   +set A, BUT NOT set B). To expand on the previous example, if the policy above requires the following update: @@ -447,13 +452,13 @@ at the Detroit office -The best way to solve this problem is usually\[4\] to keep definitions -of “business managers” and “full-time employees” and add a third: -“Detroit office.”  The “Detroit office” definition can then be used to -update the subject of your policy (granting access to the intersection -of “business managers” and “Detroit office”) as well as a context -variable (scoping that access to the intersection of “full-time -employees” and “Detroit office”). +The best way to solve this problem is usually[4] to keep definitions of +“business managers” and “full-time employees” and add a third: “Detroit +office.”  The “Detroit office” definition can then be used to update the +subject of your policy (granting access to the intersection of “business +managers” and “Detroit office”) as well as a context variable (scoping +that access to the intersection of “full-time employees” and “Detroit +office”). This approach makes it possible to achieve the same ease of assigning a permission to a group of individuals as you might in RBAC, with the @@ -462,40 +467,41 @@ cleanly segment objects as well as subjects, and supporting specificity through permission contexts (such as user groups, device identifiers, IP address ranges, or document classifications). -## Facilitate Governance and Audit +Facilitate Governance and Audit +------------------------------- A good access control system will allow auditors and business owners engaged in access governance to understand existing precedents in organizational access controls, analyze how they may need to be extended -or modified, and ascertain the business impact of proposed changes.   +or modified, and ascertain the business impact of proposed changes. When designing a PBAC system, it is important to make sure that subjects, actions, objects, and contexts are stored in a way that makes -it straightforward to report on access from any of these perspectives.  +it straightforward to report on access from any of these perspectives. Business owners and auditors should have easy access to reports that answer questions about access users have, users able to access resources of interest, and allowable contexts for any actions defined for a resource. The expressiveness of PBAC permissions makes it realistic to define all -access considerations within policies.  This flexibility is advantageous +access considerations within policies. This flexibility is advantageous over implementing additional security measures (such as IP restrictions) outside of an organizational access control system. It allows for a single source of truth about circumstances under which access is -allowed.   +allowed. Being able to report on permissions in this way facilitates the -examination of current rules for access to a resource.  Good reporting -may also include users who currently meet these criteria.  Though PBAC -is often used in federated contexts where identity (and other -contextual) information for all potential users is not available to the -resource administrator, such user reports can be helpful for -spot-checking, especially in the context of a proposed change.  Reports -on who would gain or lose access under a proposed policy support -business owners and auditors in refining controls to best facilitate -organizational needs and security. - -### Embrace States over Events +examination of current rules for access to a resource. Good reporting +may also include users who currently meet these criteria. Though PBAC is +often used in federated contexts where identity (and other contextual) +information for all potential users is not available to the resource +administrator, such user reports can be helpful for spot-checking, +especially in the context of a proposed change. Reports on who would +gain or lose access under a proposed policy support business owners and +auditors in refining controls to best facilitate organizational needs +and security. + +**Embrace States over Events** Business processes are often developed with flowcharts, which are focused on events. This often leads to access management systems that @@ -506,25 +512,25 @@ Being based on observable attributes, PBAC policies tend to be more focused on states, such as an employee’s current position. This offers several advantages: - - **Fewer states than events:** Access provisioning that is triggered +- **Fewer states than events:** Access provisioning that is triggered when an employee first enters a position may need to account for nuances between external hires, internal transfers, and promotions. - Unexpected events may occur, such as a cancelled termination. Rather + Unexpected events may occur, such as a canceled termination. Rather than tracking all potentially relevant business events, an access policy can simply apply to anyone currently holding the position. - - **Local process changes:** Access management teams are much more +- **Local process changes:** Access management teams are much more likely to be informed of changes to relevant states (e.g., employment, company policy, business functions) than to changes to events (e.g., how many processes can be used to hire staff, changes - to the company network, infrastructure upgrades, etc.).  + to the company network, infrastructure upgrades, etc.). - When departmental processes shift in ways that affect detection of - events driving access, access management teams become responsible + When departmental processes shift in ways that affect the detection + of events driving access, access management teams become responsible for investigating the resulting inconsistencies and may not be confident that their systems are functioning as intended. - - **States are more reconcilable:** Events occur at a point in time, +- **States are more reconcilable:** Events occur at a point in time, which makes them more difficult to audit for appropriateness. For example, someone might have access through a legacy process that has since been revised (and should retain access) or because a @@ -533,15 +539,15 @@ several advantages: very difficult to determine whether existing permissions are appropriate, further eroding trust in the system. - States are continuously observable, which allows for automated - reconciliation of access to ensure it is allowable under current - policy and analysis of impact of proposed changes to policies. + Because states are continuously observable, compliance with policies + defined by state can be easily validated, and the impact of proposed + changes to such policies can be easily measured. To workshop access rules that can generate robust PBAC policies, consider dropping the flowchart arrows and working only with circles -representing conditions.  Arranging these circles as a Venn or -Euler\[5\] diagram allows for a discussion of acceptable conditions for -access that will result in cleaner and more robust policies. +representing conditions. Arranging these circles as a Venn or Euler[5] +diagram allows for a discussion of acceptable conditions for access that +will result in cleaner and more robust policies. @@ -565,102 +571,103 @@ Looks like: Overlapping circles

-## Support Separation of Concerns +**Support Separation of Concerns** +---------------------------------- More advanced guidance around PBAC may include references to standards -such as OASIS’ eXtensible Access Control Markup Language (XACML)\[6\]. +such as OASIS’ eXtensible Access Control Markup Language (XACML)[6]. Such standards can be particularly useful when it is desirable to maintain separation between components of a PBAC system, such as -federated systems or when policies are based on sensitive data. +federated systems, or when policies are based on sensitive data. Consider the example of a scientific instrument subject to federal law requiring all users to be either a citizen or legal permanent resident of their country, and additionally with a clean background check performed within the last three years. To enforce this policy without -sharing citizenship, immigration status, and background check results to -the instrument. By maintaining separation between policy definition, -policy evaluation, and policy enforcement, the managing organization can -meet its legal obligations without propagating sensitive user data -across the resources it oversees (or, in federated contexts, across -organizational boundaries). - - +exposing sensitive information like citizenship, immigration status, and +background check results to the instrument, the managing organization +could implement a separation of policy evaluation and policy enforcement +such that the source systems for this data send the instrument a +compliance status rather than the raw information needed to make a local +access decision. In federated contexts, similar approaches are useful +for reducing sensitive data exchange across organizational boundaries. -# Conclusion +Conclusion Access control systems promote and implement an organization’s access control strategy as changes occur in users, personnel, responsibilities, -organizational structure, and legal obligations.  Most failures with +organizational structure, and legal obligations. Most failures with access management are due to a system implementation that is too manual to scale or too brittle to adapt to changing business needs without costly and time-consuming re-architecture efforts. While it is common to try to optimize access control systems for efficiency in *granting* access, a truer measure of a robust access -control system is how reliably it can *revoke* access.  Policy-based +control system is how reliably it can *revoke* access. Policy-based access controls support the security principle of least privilege by -offering logical symmetry between access assignment and revocation.  +offering logical symmetry between access assignment and revocation. Defining policy for access allows access to be dynamically evaluated for -validity, and automatically revoked or reported as soon as that access +validity and automatically revoked or reported as soon as that access becomes invalid under current policy. Developing access controls from a resource-first perspective and adding a notion of context to these controls allows PBAC systems to maximize -resource security over convenience of access assignment.  While these +resource security over convenience of access assignment. While these systems can initially be more complex than other approaches, the atomic -nature of policies and their relative resilience against buildup of +nature of policies and their relative resilience against the buildup of legacy permissions makes for a system that is much more maintainable over time as compared to more limited rule-based access management systems like RBAC. -# Author Bio + Author Bio +========== -Mary McKee works as Deputy Chief Information Security Officer and Senior -Director of Identity Management and Security Services at Duke -University, where she studied Computer Science as an undergraduate and -was subsequently hired as a web application developer. Her interest in -abstraction and interoperability brought her to Identity and Access -Management and subsequently, Information Security. +Mary McKee began her career as a web application developer, eventually +specializing in and leading teams dedicated to maturing processes in +Identity Management and Cybersecurity. She now works as Senior Director +of Engineering at Cirrus Identity. -# Acknowledgments +Acknowledgments The author would like to thank André Koot and Andrew Hindle for their thoughtful responses to earlier versions of this article, and Heather Flanagan, Christienna Fryar, Dave Wible, and Mary Ellen Wible for their feedback and support with its development. -# Change Log +Change Log +========== | Date | Change | -| ---------- | -------------------------------------------------------------------------------------------------------------------------------- | +|------------|----------------------------------------------------------------------------------------------------------------------------------| +| 2023-10-27 | V3 published; clarification to Embrace States over Events, Support Separation of Concerns, and author bio | | 2022-06-03 | V2 published; Clarified scope as an introductory article; replaced section on static access controls; removed section on privacy | | 2021-04-19 | V1 published | -1. “Least Privilege,” - [https://us-cert.cisa.gov/bsi/articles/knowledge/principles/least-privilege](https://us-cert.cisa.gov/bsi/articles/knowledge/principles/least-privilege) - (accessed February 10, 2020) - -2. “Role-based access control,” - [https://en.wikipedia.org/wiki/Role-based\_access\_control](https://en.wikipedia.org/wiki/Role-based_access_control) - (accessed February 10, 2020) - -3. “Attribute-based access control,” - [https://en.wikipedia.org/wiki/Attribute-based\_access\_control](https://en.wikipedia.org/wiki/Attribute-based_access_control) - (accessed February 10, 2020) - -4. The examples in this section are meant to illustrate optimizing for - set math capability within a context where both the identity - provider (or user attribute store) and the service provider (or - resource to be protected) exist within a common environment, and - does not extend to federated contexts where a service provider may - be interacting with one or more externally controlled identity - providers. It is, however, worth noting that PBAC (/ABAC/CBAC) can - easily accommodate these externalities. - -5. “Euler diagram,” - [https://en.wikipedia.org/wiki/Euler\_diagram](https://en.wikipedia.org/wiki/Euler_diagram), - (accessed February 25, 2020) - -6. “eXtensible Access Control Markup Language (XACML) Version 3.0 Plus - Errata 01,” - - (accessed May 20, 2022) +[1] “Least Privilege,” +[https://us-cert.cisa.gov/bsi/articles/knowledge/principles/least-privilege](https://us-cert.cisa.gov/bsi/articles/knowledge/principles/least-privilege) +(accessed February 10, 2020) + +[2] “Role-based access control,” +[https://en.wikipedia.org/wiki/Role-based\_access\_control](https://en.wikipedia.org/wiki/Role-based_access_control) +(accessed February 10, 2020) + +[3] “Attribute-based access control,” +[https://en.wikipedia.org/wiki/Attribute-based\_access\_control](https://en.wikipedia.org/wiki/Attribute-based_access_control) +(accessed February 10, 2020) + +[4] The examples in this section are meant to illustrate optimizing for +set math capability within a context where both the identity provider +(or user attribute store) and the service provider (or resource to be +protected) exist within a common environment, and does not extend to +federated contexts where a service provider may be interacting with one +or more externally controlled identity providers. It is, however, worth +noting that PBAC (/ABAC/CBAC) can easily accommodate these +externalities. + +[5] “Euler diagram,” +[https://en.wikipedia.org/wiki/Euler\_diagram](https://en.wikipedia.org/wiki/Euler_diagram), +(accessed February 25, 2020) + +[6] “eXtensible Access Control Markup Language (XACML) Version 3.0 Plus +Errata 01,” + +(accessed May 20, 2022) diff --git a/CIAM/intro-to-ciam.md b/CIAM/intro-to-ciam.md new file mode 100644 index 0000000..37678bf --- /dev/null +++ b/CIAM/intro-to-ciam.md @@ -0,0 +1,995 @@ +By Ian Glazer + +©2023 IDPro, Ian Glazer + +Introduction +============ + +Customer Identity and Access Management (CIAM) represents one of the +most notable opportunities for identity professionals to shine. Through +CIAM, identity professionals can help organizations reduce costs and +reach new customers. For commercial entities, this means growing both +the top and bottom lines. With these wide-ranging opportunities, CIAM is +different from workforce IAM. CIAM presents IAM professionals with new +challenges, vocabularies, processes, and requirements – all of which +serve to ensure that individuals can interact with organizations easily +and securely. + +Terminology +----------- + +*Many of these terms have been sourced from “Terminology in the IDPro +Body of Knowledge.”*[1] + +| **Term** | **Definition** | +|------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| Authentication | Authentication is the process of proving that the user with a digital identity who is requesting access is the rightful owner of that identity. Depending on the use-case, an ‘identity’ may represent a human or a non-human entity; may be either individual or organizational; and may be verified in the real world to a varying degree, including not at all.[2] | +| Authenticator | The means used to confirm the identity of a user, processor, or device, such as a password, a one-time pin, or a smart card.[3] | +| Authoritative Source | The system of record (SOR) for identity data; an organization may have more than one Authoritative Source of data in their environment.[4] | +| Authorization | Determining a user’s rights to access functionality or resources within a computer application and the level at which that access should be granted. In most cases, an ‘authority’ defines and grants access, but in some cases, access is granted because of inherent rights (like patient access to their own medical data).[5] | +| Consent | Permission for something to happen or agreement to do something.[6] | +| Customer Identity and Access Management (CIAM) | CIAM is the field of IAM that focuses on the Registration, Authentication, and Authorization services for an individual or entity receiving or purchasing services from an organization. | +| Credentials | In the context of CIAM, credentials are how individuals authenticate themselves to an organization’s CIAM system | +| Credential Stuffing | An attack in which an adversary tests lists of username and password pairs against a given CIAM system. | +| Identification | Uniquely establish a user of a system or application. | +| Identifier | An identifier is a means by which a system refers to a record (at the most abstract levels.) In this case, it could mean the string that a person provides that “names” their use account. | +| Lifecycle | In the context of CIAM, lifecycle refers to the stages that an individual or entity might experience over the course of their relationship with an organization, beginning with the formation of a relationship (such as being hired into an organization or signing up for service) and ending with the severance of that relationship (such as termination or closing an account) | +| Passwordless | Any means of authenticating a user account that does not require a static stored shared secret. Techniques include one-time passwords and passkeys. | +| Policy Store | A repository that houses configuration information for the CIAM system and serves as an Authoritative Source for that information. For example, OAuth token Lifecycle policies or Authorization policies. | +| Preferences | Choices that individuals or entities make in administering the relationship they have with an organization. These choices may include topics of interest or approved communication methods. Often, Preferences are stored with Profile information. | +| Profile | A collection of attributes about an individual. The individual may provide it directly, or the organization may gather it indirectly. | +| Progressive Profiling | A technique to reduce customer friction by gathering Profile, preference, and Consent information over time (when needed) rather than all at once. | +| Registration | The creation of a relationship between an individual and an online system that is initiated by the individual and results in the creation of a user account or Profile. | +| Workforce IAM | The application of IAM sub-disciplines such as access governance, authentication, and Authorization for employees as opposed to the applications of such disciplines for customers. | + +Acronyms +-------- + +| ATO | Account Takeover | +|-------|-----------------------------------------------| +| B2B | Business-to-Business | +| B2C | Business-to-Consumer | +| B2B2C | Business-to-Business-to-Consumer | +| CIAM | Customer Identity and Access Management | +| CRM | Customer Relationship Management | +| DAU | Daily Active Users | +| IAM | Identity and Access Management | +| IDP | Identity Provider | +| JML | Joiner, Mover, Leaver (used in Workforce IAM) | +| MAU | Monthly Active Users | +| OTP | One-Time Password (or Passcode) | + +What is CIAM? +============= + +Over the last decade, organizations in every industry, sector, and +geography have sought to provide services online. Trading under the name +“digital transformation” and “digital engagement,” organizations have +pushed to interact with people through websites, mobile apps, and +connected devices to reach new customers, offer more valuable services, +and lower service delivery costs. The COVID-19 pandemic further +amplified the need for all organizations to have a robust online +presence. + +But for people to interact with these online services, they need a means +to safely and efficiently identify themselves to those services. How +organizations offer sign-up and sign-in services is the core of CIAM. + +What Does the “C” Stand for? +---------------------------- + +Digital identity practitioners love abbreviations, but this can cause +confusion. The C in CIAM is just such an example. Despite [the +assertions of Sesame Street’s Cookie +Monster](https://youtu.be/Ye8mB6VsUHw?si=OI9cwn_qodW9CTfq),[7] C stands +for more than just cookie: in this context, it also stands for customer, +consumer, or citizen. The typical usage is customer, but that may have +inaccurate implications. For example, it may imply that CIAM systems +only apply to contexts in which the individual pays for a service from +an organization. This is not the case. + +All organizations need CIAM to interact with people who could or +do use their services. Such organizations include public sector agencies +that deliver on behalf of citizens and residents, universities that +empower students and researchers, and non-profits that serve communities +and engage with supporters. And yes, this also includes for-profit +businesses that sell goods and services. + +Why CIAM is Important +--------------------- + +CIAM enables organizations to reach more people and offer more valuable +services. In widening reach, CIAM provides a way for organizations to +expand their total addressable market while reducing service delivery +costs. As a result, an effective CIAM program improves both the top line +and the bottom line of organizations. These benefits are equally +relevant for public sector entities that aim to reach more citizens, +deliver more social services, and reduce taxpayer costs. While +traditional workforce IAM is an essential cost-center focused on +efficiency, security, and compliance requirements, CIAM can be seen as a +profit-center. + +How CIAM Differs from Workforce IAM +----------------------------------- + +Some readers may be more familiar with the primary goal of workforce IAM +to deliver the right access to the right people at the right place and +time. To meet this goal, IAM practitioners deploy, for example, +automated user provisioning, birthright policies triggered by a small +number of central authorities, access request systems, and authorization +policies governed by a central Identity Provider (IDP). + +CIAM has a different goal. It supports organizational digital engagement +efforts to deliver the right experience (in addition to access) to the +right people at the right place and time. In collaboration with Chief +Information Security Officers, Chief Digital Officers seek to ensure +engaging, personalized experiences at every touchpoint during an +individual's relationship with a given organization – and doing so +securely.[8] With this goal in mind, CIAM professionals deploy different +tools, including just-in-time user provisioning, social sign-on, and +user registration. This article will continue to draw out further +differences and similarities between workforce IAM and CIAM. + +B2C vs B2B vs B2B2C +------------------- + +Readers may have seen references to business-to-consumer (B2C)[9] and +business-to-business (B2B). In some cases, CIAM focuses primarily on B2C +use cases with a secondary focus on B2B. CIAM technology offerings tend +to help an organization offer sign-up and sign-in services optimized for +an individual to interact with an organization. Secondarily, a CIAM +technology offering might also provide B2B service to facilitate trust +between two different organizations, enabling employees from one to +access services from another. Knowing whether a problem or project +relates to a B2C or B2B context significantly impacts the requirements. + +There is a third B2\* permutation: business-to-business-to-consumer +(B2B2C). In this case, a technology service provider offers CIAM +capabilities to multiple organizations that use those services to engage +with their customers. In B2B2C scenarios, delivering CIAM services with +the correct brand experience is critical. This experience consists of +everything, from the logos and colors on the screens to the URLs that an +end-user would see. Instead of the upstream service provider brand, the +customer should always see the brand of the business with whom they have +a direct relationship. + +(The primary focus of this article is on B2C use cases, though it will +highlight some notable differences in B2B use cases. Unless otherwise +specified, the reader should assume examples and guidance are oriented +towards B2C use cases.) + +The Stakeholders and Measurements +================================= + +Successful digital engagement requires a successful CIAM strategy. +Successful digital engagement also requires a very different collection +of stakeholders than workforce IAM professionals might be used to. This +expanded set of stakeholders has a new vernacular and a different set of +goals from which the CIAM practitioner needs to derive requirements. +Furthermore, the varied perspectives of these audience members require +practitioners to translate the benefits and value of CIAM to different +contexts. The stakeholders in digital engagement include marketing, +digital, sales and distribution, product, privacy, legal, and customer +service. In addition to these players, CIAM teams will also see a more +familiar face: security. + +A shared digital engagement mission often includes the following goals: + +- **Increase Engagement**: Increase the number of people actively + using whatever the organization produces, be they physical, + informational, or digital + +- **Reduce Friction**: Reduce the number of steps and tasks that stand + in the way of an individual getting to use whatever the organization + produces + +- **Build Loyalty**: Ensure repeat use/engagement through products and + customer service + +CIAM practitioners partner to conduct this mission against a backdrop of +security, appropriate data usage, and operating costs. + +The stakeholders sharing this mission use different metrics than +workforce IAM practitioners. In digital channels, engagement is often +measured by the number of: + +- Unique visitors to an organization’s site or app + +- Page views + +- People actively using the products and services within a given time + frame, often referred to as “Monthly Active Users” (MAU) or “Daily + Active Users” (DAU) + +- Unknown visitors converting to either sales or registered accounts, + known as “Conversion Rate.” + +Further to these goals, building loyalty comes with its own set of +measures, including customer satisfaction, net promoter score, and +customer lifetime value. While CIAM teams might not be directly involved +in gathering these metrics, they will certainly hear about it if +customer satisfaction dips because of (or is inherently limited by) an +onerous login process. + +Although people recognize friction when they see it, defining and +quantifying it is more difficult. Often, CIAM teams hear statements such +as “It’s too hard to register for an account” or “It’s too many clicks +to get to the content.” Abandoned account sign-ups, the number of +screens or fields to register, failed logins, support calls, and even +password reset rates are all indicators of friction. The organization’s +need to reduce friction in its sign-up and sign-in flows demands a +careful, iterative design process that finds (and seeks to eliminate) +the places where people get stuck or give up in frustration. To add to +the challenge, security and privacy stakeholders often seek to introduce +*more* friction to thwart automated attacks, ensure regulatory +compliance, and avoid harmful user choices. The balancing act for +stakeholders and the implementation team is not simple. + +Authorities, Lifecycles, and Administration +=========================================== + +CIAM underpins digital engagement and enables organizations to offer +products and services via digital channels as a sole channel or in +addition to existing brick-and-mortar channels (e.g., phone or a +physical location). This difference in context means that the sources of +authoritative information about end-users, the lifecycle of those users, +and the methods by which those users are administered differ from +workforce sources, cycles, and techniques. + +Authoritative Sources +--------------------- + +In the workforce context, an IAM system can usually rely on human +resource systems or databases to be authoritative about who is an +employee, their demographics, and their roles and job responsibilities. +In CIAM, no such system is consistently present and reliable. While a +customer relationship management (CRM) system might exist and possess +customer profile data, it is not definitive. Similarly, an eCommerce +system, if present, might maintain shopper profile data that is, again, +not definitive. While either might have information about an individual, +neither is authoritative: the individual is the authoritative source of +information. After an individual creates a user account via the CIAM +system, their resulting profile is (ideally) linked to CRM, eCommerce, +Customer Support, etc., using one or more unique, verified identifiers +such as email, phone number, and account number. [10] One notable +exception is the B2B use case in which a CRM system might be considered +authoritative (about which individuals work for which organizations). + +Lifecycles +---------- + +The user lifecycle in CIAM may seem different from what the reader is +familiar with if they come from a workforce background. In workforce +scenarios, the reader might be familiar with the concept of “joiner”, +“mover,” “leaver” (JML), which reflects how a new employee joins the +organization, changes roles (aka moves) throughout their career, and +eventually leaves the organization. Such events are recorded in +authoritative sources, like a human resource system. + +However, the lifecycle for a customer looks quite different: they +register for an account and, ideally (from the organization's +perspective), never stop using that account. There is often no event +from an HR system equivalent to trigger user account creation, change, +or deletion. CIAM and associated authorization systems will often query +CRM systems to pull information such as “Is the person a Gold Level +member?” to determine access to downstream resources at the precise time +the resource is accessed. In this regard, CIAM tends to be a world of +just-in-time authentication and authorization instead of admin-time, in +which user accounts and associated resource access are set up in +advance.[11] + +Some readers might ask, “If my existing customers’ profiles exist in the +CRM, can we use that to automate user account creation and distribute +the credentials?” Do not do this. In a post-GDPR world (referring to the +European Union’s General Data Protection Regulation[12]), such an action +will be interpreted as a violation, i.e., signing the individual up for +an account without their consent. The individual is in control in B2C +CIAM use cases; thus, actions need to be taken just-in-time, not *a +priori*. + +Administration +-------------- + +The theme of individual control continues into the topic of +administration. The individual can and must be able to control and +update the information they have provided to the organization, including +name and contact information.[13] The data they must be able to control +includes their password, if they have one. The organization might also +grant workers similar abilities in their customer service organization +to help individuals who reach out to contact centers. These capabilities +come with significant security risks, and the reader is encouraged to +read IDPro’s BoK article entitled ”[Managing Identity in Customer +Service Operations](https://bok.idpro.org/article/id/65/).”[14] + +In B2B use cases, the organization not only needs to provide user +accounts and associated access to their business partners but also +enable specific people within the partner’s organization to manage their +own users’ access. Known as “Delegated Administration,” this capability +looks similar to granting different people within the organization the +ability to administer users in other parts of the organization. + +Profile, Preferences, and Consent +================================= + +CIAM systems are often used to enable information gathering, including +demographic data (such as age and address), contact preferences (if at +all), and their approved uses for any data collected. Organizations use +this information to personalize experiences, deliver goods and services, +as well as use data the individual shares for business purposes. + +Profile +------- + +A profile is a collection of attributes about the individual. The +individual may provide it directly or indirectly, such as in social +sign-up and sign-in experiences. This information enables personalized +user experiences, such as using an individual’s first name on the +welcome screen of a mobile app. This personalization can also include +providing specialized offers based on, for example, where they live. + +The profile can also include information that businesses require for +essential processes. For example, the individual might provide their +street address so the organization can send physical goods to their +home. In some cases, organizations’ business processes include evidence +that an individual is old enough to use the service itself. For example, +an online gambling site may have specific regulatory requirements to +verify that an individual is over 18. Alternatively, the organization +may be required to gather and verify legal identity information from the +individual. For example, a bank must verify an individual's legal +identity to adhere to “Know Your Customer” (KYC) regulations that +prevent money laundering and other financial crimes. + +Preferences +----------- + +Commonly, individuals are not interested in every possible product and +service an organization offers; similarly, the individual may prefer one +contact method over another (e.g., text message vs. email). This kind of +choice is captured in the form of preferences. Preferences may include +topics of interest related to an organization’s offerings (e.g., +sporting goods, elder care, etc.), approved communication channels +(e.g., “none” or “email but not text messaging”), and frequency of +communication (e.g., monthly emails not daily.) While this information +is not strictly required for business processes, it vastly improves the +individual’s experience with the organization. + +Consent +------- + +In response to questionable practices, an increasing number of +regulators require that an individual actively and positively chooses to +interact or share data with an organization. This proof is referred to +as consent. Said differently, an organization often needs to record +evidence that the individual asserted that they want to interact with +the organization. Organizations often bundle this consent with an +acknowledgment that individuals agree to terms of service and conditions +of use. The presentation of this choice must be clear: this means +visible and accessible as well as understandable. The granularity of +consent requirements varies from region to region and industry to +industry. The cadence with which an organization must gather consent +information may also differ. Organizations often bundle the gathering of +consent with an acknowledgment that individuals agree to terms of +service and conditions of use. Understanding the consent requirements +for any use case or jurisdiction is critical. + +Progressive Profiling +--------------------- + +The aggregate of profile, preferences, and consent data can be +considerable. Organizations are not advised to gather all this +information at any one moment, like when the individual signs up for a +new account or attempts to checkout during an e-commerce transaction. +Doing that would ask the individual to fill out too many fields and +screens. It puts too many hoops between them and the goal they set out +to achieve. In e-commerce scenarios, too much friction can lead to +dropouts when individuals give up and move on to a competitive offering. +In the CIAM world, friction is akin to inefficiency in workforce user +provisioning: it is the enemy. + +To combat this enemy, organizations can employ a technique by which they +ask for profile, preference, and consent information over time and not +all at once. They can ask for information, such as shipping address, at +the time they need it instead of when the individual first arrives at +the website or service. Known as “Progressive Profiling,” this technique +reduces friction by spreading it out across interactions and over a +longer period. + +Profile Versus Credential +------------------------- + +It is essential to keep clear in one’s head the relationship and +separation between a profile and a credential. Where a profile is a +collection of attributes related to an individual, the credential is the +means by which the individual identifies themselves to the website or +app with a certain degree of certainty. In its simplest and most basic +form, a credential is a username and password combination. On the other +hand, a profile can have a very rich data structure composed of many +attributes of different types. Because the purpose of these resources +differs, the techniques needed to manage and protect them are different. +At the highest levels, profile data is within the domain of data +management and privacy professionals and their tools, while credentials +are squarely in the domain of identity and security practitioners and +their associated tools. + +This distinction leads to a critical question about ownership within the +organization. In this context, do not think of ownership with a legal +mindset: we are not discussing ownership like one discusses owning a +candy bar. In this context, ownership is a conversation about who, +within an organization, is responsible for gathering, managing, +protecting, and making use of this data. Although a CIAM technology +stack may be able to obtain and store profile data, it does not mean +that a) the identity team owns the profile or b) that the profile is the +only form or representation of a customer within the organization. +Consider that organizations will have many “pictures” of a given +customer in systems such as the CIAM, customer support, marketing, and +operational systems. Profile data is legion within organizations. + +Why dwell here? Previously, this article discussed the various teams +involved in a digital engagement program. These teams will claim, with +good reason, that they own the customer profile and are thus responsible +for gathering and managing it. They are not wrong in this regard, and +their requirements, as foreign feeling to identity teams as they may +feel, are just as valid as security or regulatory requirements with +which an identity team may be more familiar. Partnership here is a must: +calories spent debating ownership are better applied to building better +experiences for the individual. + +In the case of credentials, however, these fit in the CIAM domain and +are the subject of the next section. + +Credentials +=========== + +Where profiles are information shared by individuals to help +organizations personalize their experience, credentials are how those +individuals make themselves known to an organization. Said differently, +credentials are how individuals authenticate themselves to an +organization’s CIAM system and, thus, the entire digital landscape. +Generally speaking, there are two parts to a credential: + +- An identifier + +- An authentication mechanism + +Identifier +---------- + +As the name implies, identifiers are the “name” an individual uses to +tell an organization’s CIAM, “I am HappyCustomer01@my.mail.” More often +than not, email addresses and phone numbers are used as identifiers. +Using them has a side benefit: it cuts down on the information an +individual has to provide as a part of their profile. Because +organizations want to communicate with the individual, they often ask +for their preferred email address or phone number. Using email and phone +as identifiers allows them to serve double duty as both an identifier +and a communication channel. Importantly, the identifier is the username +in the classic username and password combination. + +While seemingly straightforward, identifiers and the handling thereof +can be far more complicated than expected. It is strongly recommended +that the reader reviews the IDPro Body of Knowledge article +“[Identifiers and +Usernames](https://bok.idpro.org/article/id/16/).”[15] + +Authentication Mechanisms +------------------------- + +Having provided a valid identifier, the individual is prompted to +authenticate. The most well-known and entrenched are passwords, but +others exist. Increasingly, these alternatives to passwords are becoming +popular. + +### Passwords and One-Time Passwords + +The most familiar authentication mechanism is the password. Passwords +are shared secrets, meaning that both the individual and the CIAM system +maintain the secret to verify that the individual is who they claim to +be. + +Passwords are the somewhat unfortunate bedrock upon which authentication +has built its castle. Refer to the IDPro Body of Knowledge +“[Authentication and +Authorization](https://bok.idpro.org/article/id/64/)” for more on +authentication.[16] Read the National Institute of Standards [Special +Publication +800-63B](https://pages.nist.gov/800-63-3/sp800-63b.html#sec5), +section 5.1, to receive guidance on good practices for password +composition and treatment.[17] + +Because individuals’ memories are fallible, organizations need to +provide means for individuals to prove they are who they claim to be and +then set a new password. Known as either account recovery or password +reset, these processes are often overlooked and become attack vectors +for adversaries. Neglecting these processes leads to difficult user +experiences, constrains account protection, and increases customer +support interactions. Failing to protect password reset processes can +lead to account take-overs in which an adversary exploits a weak +password reset process, sets a new password known to them rather than +the account owner, and takes control of the account and its associated +resources (e.g., emails, photos, files, social media accounts, bank +accounts, etc.). Readers should review the IDPro Body of Knowledge +article “[Account +Recovery](https://bok.idpro.org/article/id/64/)” for more +information.[18] Additionally, it is strongly recommended that identity +professionals spend time at the *beginning* of a CIAM project +considering their account recovery processes across all channels (web, +mobile, phone, etc) through which their organization will interact with +individuals. + +Shared secrets are not the only game in town. Increasingly, +organizations are opting for one-time passwords (OTP). These are shared +secrets with a limited lifespan and, as the name implies, can only be +used once. Common examples of one-time passwords include sending a code +to a mobile phone or email address. OTPs can have a better user +experience; they do not require the individual to remember or store a +password, and operating systems and browsers perform better at +automatically filling in OTPs when they detect them. However, these +benefits can be outweighed by the risks of phishing and interception. +One thing to note, at this time, OTPs are often considered part of the +larger “passwordless” authentication world: this is both confusing and +inaccurate.[19] + +Passwordless +------------ + +Passwords and OTPs are not the only methods that a CIAM team can choose +to deploy. Increasingly, technology providers are offering truly +passwordless offerings. These offerings generally rely on a combination +of public key infrastructure (shielded from the user), trusted computing +mechanisms for storing those keys, and a dedicated app or browser or +operating system-provided user experience to strongly assert that the +individual is who they claim to be. From the individual’s perspective, +they either provide a biometric (such as TouchID or FaceID Apple-centric +environments) or interact with a mobile app protected by biometrics or +PIN. These interactions “unlock” access to the site or service. + +The interest and popularity of passwordless approaches are partially +fueled by the acknowledgment that passwords are poor solutions for +individuals and organizations. More recently, the industry is adopting +the WebAuthn standard (and associated standards). WebAuthn is a standard +overseen by the W3C,[20] and its implementations can be found in most +modern mainstream browsers and operating systems. Most recently, +agreements on how the cryptographic material needed to power +WebAuthn-based passwordless authentication can be synchronized between +devices and browsers to facilitate an “enroll once, use anywhere” +end-user experience, known as passkeys, have driven even more excitement +and interest. + +Challenges still exist with passwordless approaches, including how an +organization should trust an individual they have never seen before and +how an individual can get back to their user account in case of a lost +device. Additionally, passwordless approaches often require modern +smartphones or computers, which are unavailable to many. But that said, +passwordless approaches, especially those that are standards-based, +represent a path from passwords to something materially stronger with an +improved user experience. + +Social Login +------------ + +IAM professionals may choose to augment their password and passwordless +sign-on offerings with social sign-up and sign-on. In this case, an +individual identifies themselves to the organization by first +authenticating to another service, such as a social network or email +provider. In this case, the organization doesn’t hold any secrets (e.g., +passwords) from the user but instead records that the associate user +account needs to be authenticated by the external identity provider (the +social network, email provider, etc.) Organizations can not only use a +social credential to authenticate an individual but also use the +information that the external identity provider provides to create or +pre-populate a profile for the individual; this is social sign-up. + +While social sign-up can be very appealing, it does come with some +downsides. It is inherently exclusive in providing a different kind of +login experience to people who are members of a specific social network. +While claiming hundreds of millions of members, offering a specific +social network may not feel that exclusive; individuals will likely have +strong preferences. This means that organizations often offer login via +multiple social networks and email providers. In turn, this leads to the +[NASCAR problem](https://indieweb.org/NASCAR_problem) in which a site’s +login page starts to resemble a NASCAR car festooned with different +logos. Leaving the NASCAR problem aside, even having one social +credential option means the organization is putting another +organization’s brand on theirs. These choices, to some, can be +polarizing at the worst and off-putting. There is an inherent assumption +that the external identity provider can protect secrets and offer +recovery options that are superior to what the organization can do +itself. That is often a reasonable assumption, but it is worth +considering before deploying such offerings. + +Some organizations may require higher assurance about individuals for +regulatory or business process reasons. Such organizations can deploy a +user experience similar to social login – one that relies on an external +identity provider and is presented as a set of choices on sign-up and +sign-in screens. The key difference is that the external identity +provider is a government or financial sector service. This topic area is +robust and requires a more advanced examination in a future Body of +Knowledge article. + +Functions and Components +======================== + +Functions +--------- + +At their core, CIAM systems perform at least user registration and +authentication. User registration allows an individual to create an +account and establish a credential. It may also include collecting +profile, consent, and preference data. User authentication validates the +credential the individual provides when they access the organization’s +apps and services. It is important to note that CIAM systems usually do +not trigger a user provisioning process after establishing a new user +credential. However, this may be more common in utilities or B2B and +B2B2C scenarios. This stands in stark contrast to more traditional +workforce IAM scenarios in which the detection of a new employee in an +HR system often triggers user provisioning workflows. CIAM more often +relies on the just-in-time (JIT) creation of user accounts brokers by +single sign-on during run-time instead of user provisioning at +admin-time. + +Additionally, CIAM systems often provide two more capabilities: single +sign-on and OAuth token management. The single sign-on capabilities +offer individuals a seamless experience as they navigate across the +different websites and services an organization provides. For example, +this ensures that when the individual logs into the eCommerce site to +purchase something, they can access the customer support site without +logging in again. The OAuth token management capabilities are used to +issue OAuth tokens to the individual and their apps. These tokens are +used to access APIs that the organization provides. The individual may +not be aware that they have been issued tokens and are using them in +many interactions with the organization’s goods and services, but +identity professionals and their security peers need to be aware of this +– if only to take steps if an individual’s app or device is compromised. +In this case, revoking the issued token(s) will prevent further access +to the compromised app. + +Finally, the CIAM system may provide some form of orchestration service. +This service can build the user experience the individual sees as they +register and integrate third-party services into user experience flows. +Such integrations can further enhance the individual's experience, +perform progressive profiling, or even add higher assurance that the +individual is who they claim to be. + +Components +---------- + +While different technology suppliers’ specific architectures and +components' names will vary, they generally share the same notional +architecture. + + + +Figure 1: Components of CIAM Architecture + +### Credential and Profile Stores + +At a minimum, a CIAM system provides a credential store or integrates +with an existing one. This store is where user accounts are maintained +and shared secrets, if any, are housed. The implementation of the +credential store can range from a relational database to an LDAP +directory to a NoSQL database and beyond. + +The CIAM system may have a profile store that could contain profile, +preference, and consent data. Profile storage, however, is not a strict +requirement. Consider that organizations often centralize this kind of +information in a customer data platform or marketing automation system. +In such cases, the CIAM system will have the minimum amount of +information needed for personalization and communication (e.g., a +verified email address used to facilitate password resets) while the +rest of the profile information is stored elsewhere. + +### Policy Store and Admin Interface + +This repository houses configuration information for the CIAM system and +serves as an authoritative source of that information. Such information +could include single sign-on configurations, OAuth token lifecycle +policies, and user registration workflow definitions. It might also +house authorization policies that govern which resources an individual +can access. The artifacts in this repository are managed by the Admin +Interface or via changes to configuration files. The Admin Interface, if +provided, presents a user experience where identity professionals can +configure and manage the CIAM system. + +### Authentication and Orchestration Service + +This service can serve multiple roles. At a minimum, it authenticates +credentials. It can also manage the user’s session and broker single +sign-on. It may act as an OAuth authorization service. Lastly, it can +act as an orchestration service. In this final context, it relies on +policies in the policy store to determine, for example, what information +must be gathered from an individual as they register, when to present an +additional authentication challenge (often mediated by a third-party +risk modeling service), or the steps required to reset a password. + +### CIAM Component + +In each of the example websites in the above figure, the reader will +notice the CIAM Component. This is an optional component that can help +broker user registration and authentication. Often a piece of +JavaScript, web component, or library, this piece of the puzzle can +securely interact with the authentication and orchestration service. +Often, in cases where this component is not present, the individual is +redirected to a user experience that the authentication service provides +to register and authenticate; they are then redirected to the site or +app where they started. + +Constraints and Challenges +========================== + +Like other domains within the digital identity industry, CIAM comes with +its own unique set of hills to climb. What follows is not an exhaustive +list, and readers have likely discovered others. + +Risks of Being on the Internet +------------------------------ + +CIAM systems, by their very nature, are on the public internet. After +all, that’s where an organization’s customers are. It may go without +saying that the internet is a space fraught with adversaries and risks, +but it is especially important to say it about the identity systems of +the internet. Every major touchpoint in a customer journey is +susceptible to attack, especially sign-up, password reset, and login. +Three kinds of attacks to be aware of are: + +- Fraudulent Registration + +- Credential Stuffing (aka cred stuffing) + +- Account Takeover (ATO) + +### + +### Fraudulent Account Registration + +In this attack, the adversary (including bots) registers a new user +account in the CIAM system using either bogus or stolen personal +information. Their motivations vary from wanting to fill forums and chat +groups with spam and malware links to harvesting new customer discount +codes. Mitigations to these attacks can include anti-fraud systems for +detection and reCAPTCHA-type puzzles, although the latter have been +shown to be less effective than in years past. + +### Credential Stuffing + +In this attack, an adversary tests whether lists of username and +password pairs work in a given CIAM system. Often, adversaries acquire +credentials (e.g., they may purchase them on the dark web) and test +whether those credentials work at different online services. Their value +on the black market is determined by the types of services those +usernames and passwords can access. In many cases, the adversary is not +interested in abusing an organization’s service itself; instead, they +are testing to see if the credentials work with your service so that +they can sell it at a higher price. The reason why credential stuffing +is even a thing is because people have a habit of reusing passwords. +Mitigations to these attacks include specialized credential stuffing +detection technology (often closely aligned with bot management and +protection) and enforced multi-factor authentication (MFA). + +It is important to note that credential stuffing differs from brute +force attacks. In the brute force attack, the adversary is interested in +testing whether an array of passwords works with a specific username. +Brute force attacks can be mitigated in a variety of ways, including +failed login throttling, in which multiple failed logins for the same +user trigger either a slowdown in the number of times the user is +allowed to log in or even a cooldown period during which all logins for +the user are blocked. Credential stuffing cannot be mitigated with these +measures because a CIAM system will only see one failed login per +username/password pair. + +### Account Takeover + +In this attack, an adversary possesses the means to act like the genuine +authenticated user. The adversary may have the user’s password (e.g., +via a phishing campaign). The adversary might have found a weakness in +the password reset process and forced a password change on a genuine +user’s account. Regardless of the means, the outcomes are the same: the +adversary is in control of the user account – and may very quickly take +steps to block the user from regaining access (such as changing the +phone number). From that point forward, all means of nefarious actions +can happen. Early detection is important but not sufficient to mitigate +account recovery. Please refer to the IDPro Body of Knowledge article +“[Account Recovery](https://bok.idpro.org/article/id/64/)” for +more information. + +Migrating CIAM Systems +---------------------- + +Today, most organizations have an existing CIAM system. It might be +tightly bound to an eCommerce platform or collaboration platform. If the +organization has decided to modernize or replace its CIAM, then it is +likely that IAM team members will be confronted with a migration. While +migrating usernames is reasonably straightforward, migrating passwords +is not. Two significant challenges are exporting passwords from the old +system and getting them into the new one. + +Exporting passwords presents significant challenges. It is important to +note, for the avoidance of doubt, this article assumes that the word +“password,” in the context of secure storage, means a password hash: +systems should never store passwords in their recoverable plain text +form. If exports are allowed, further data must be exported, including +those comprising the security features known as “salt” and “pepper.”[21] +With all three, taking extensive protective measures during migration is +essential since they represent “loaded weapons.”[22] + +Importing passwords requires not only the appropriate “salt” and +“pepper” data but also the hashing scheme used by the previous system. +Some CIAM solutions have specific features that support this process, +but not all do. + +Not all systems allow password exports at all. When organizations cannot +migrate passwords, then at least two choices exist. Choice one involves +telling the users to reset their passwords. This is not a great choice – +it will certainly invite the attention of a grumpy Chief Digital Officer +or other stakeholder(s). Choice two involves keeping the old CIAM alive +and using it as a “dumb” credential store. When the user arrives and +attempts to log in, the new CIAM tests the provided username and +password against the old CIAM repository. If the credentials are good, +the new CIAM records the password and marks the user as migrated. This +approach is more complicated to deploy and requires that the old CIAM +stays operational for a much longer period of time than the team might +hope for (or want to pay for).[23] + +Budget and Ownership +-------------------- + +As discussed in the “The Team and Measurements” section, there are +multiple stakeholders at the CIAM table. Besides bringing a diverse set +of requirements and language, they bring their own teams and +stakeholders, their motivators, their priorities, and their opinions. +Who funds, operates, enhances, and is responsible for a CIAM stack can +become a difficult set of questions to answer. It is not unusual to have +the Chief Digital Officer take responsibility for the CIAM experience, a +large percentage of the requirements, and funding. Partnered with them +is the Security team, who have other requirements and are responsible +for monitoring and incident response. The Identity team might be part of +either organization or a separate Information Technology team. +Regardless, expect that upper management will need to establish clear +lines of demarcation between the various interested parties and, +furthermore, to ensure there is a clear set of priorities that aligns +the collective. + +Topics for Future Investigation +=============================== + +This Body of Knowledge article is meant to be an introduction to +Customer Identity and Access Management. The topic is both broad and +deep: exploring the entire landscape is beyond the scope of an +introductory article. The following is an incomplete list of what could +and should be explored in the future: + +- Incident response playbooks and documenting who to call when + customers cannot register or log in + +- Identity verification and proofing’s role in CIAM + +- High availability architectures for CIAM + +- The use of fraud prevention tools to protect sign-up and sign-in + +- Use of government- or financial services-issued credentials + +- Emergent trends in credentials, including verified credentials + +- Cross-channel or “omnichannel” CIAM + +Conclusion +========== + +CIAM represents one of the biggest opportunities for identity +professionals to demonstrate the value of their work. Through CIAM, +identity professionals can help organizations reach new customers and +grow the top and bottom lines. In this way, it is different from +workforce IAM. These differences invite stakeholders from new parts of +the organization – new partners, like Brand, Marketing, and Digital. +Each new stakeholder brings their own set of requirements, languages, +and business objectives. CIAM is, fundamentally, an internet-facing set +of identity services that brings unique risks to model and mitigate. For +more experienced identity professionals, CIAM may represent a fresh +opportunity to reinvigorate their passion for digital identity. For +newer members of the identity profession, it represents an exciting +opportunity to have a meaningful positive impact on their organizations. + +Author +====== + +Ian Glazer + +A person with a beard and mustache Description automatically generated + +Ian Glazer is the founder and president of Weave Identity – an advisory +services firm. Prior to founding Weave, Ian was the Senior Vice +President for Identity Product Management at Salesforce. His +responsibilities include leading the product management team, product +strategy, and identity standards work. Earlier in his career, Ian was a +research vice president and agenda manager on the Identity and Privacy +Strategies team at Gartner, where he oversaw the entire team’s research. +He is a Board Emeritus and the co-founder of IDPro and works to deliver +more services and value to the IDPro membership, raise funds for the +organization, and help identity management professionals learn from one +another. During his career in the identity industry, he has co-authored +a patent on federated user provisioning, co-authored and contributed to +user provisioning specifications, and is a noted blogger, speaker, and +photographer of his socks. + +[1] Flanagan (Editor), H., (2022) “Terminology in the IDPro Body of +Knowledge”, *IDPro Body of Knowledge* 1(11). +doi:  + +[2] Epping, M. & Morowczynski, M., (2021) “Authentication and +Authorization (v2)”, *IDPro Body of Knowledge* 1(10). +doi:  + +[3] Ibid + +[4] Glazer, I. & Robinson, L. & Hamlin, M., (2022) “User Provisioning in +the Enterprise”, *IDPro Body of Knowledge* 1(8). +doi:  + +[5] Koot, A., (2020) “Introduction to Access Control (v4)”, *IDPro Body +of Knowledge* 1(10). doi:  + +[6] Nelson, C., (2020) “Introduction to Privacy and Compliance for +Consumers (v3)”, *IDPro Body of Knowledge* 1(10). +doi:  + +[7] Sesame Street (2009) “Sesame Street: Cookie Monster Sings C is For +Cookie” + +[8] McKinsey and Company “Enhancing customer experience in the digital +age” +https://www.mckinsey.com/capabilities/growth-marketing-and-sales/our-insights/enhancing-customer-experience-in-the-digital-age + +[9] Yes, C in B2C stands for consumer and that only adds to the +confusion on what the C stands for in CIAM. The writer of this article +doesn’t create the terms of art, just relays them. + +[10] Cameron, A. & Grewe, O., (2022) “An Overview of the Digital +Identity Lifecycle (v2)”, *IDPro Body of Knowledge* 1(7). doi: +[https://doi.org/10.55621/idpro.31](https://doi.org/10.55621/idpro.31) + +[11] For more on admin-time versus runtime-time patterns, see: Bago +(Editor), E. & Glazer, I., (2021) “Introduction to Identity - Part 1: +Admin-time (v2)”, *IDPro Body of Knowledge* 1(5). +doi:  + +[12] See, for example: Hindle, A., (2020) “Impact of GDPR on Identity +and Access Management”, *IDPro Body of Knowledge* 1(1). +doi:  + +[13] Ibid. + +[14] Crow, A. & Rowan, J. P., (2021) “Managing Identity in Customer +Service Operations”, *IDPro Body of Knowledge* 1(4). +doi:  + +[15] Glazer, I., (2020) “Identifiers and Usernames”, *IDPro Body of +Knowledge* 1(1). doi: + +[16] Epping, M. & Morowczynski, M., (2021) “Authentication and +Authorization (v2)”, *IDPro Body of Knowledge* 1(10). doi: + + +[17] Grassi, Paul, James Fenton, Elaine Newton, Ray Perlner, Andrew +Regenscheid, William Burr, and Justin Richer. “Digital Identity +Guidelines Federation and Assertions: Authentication and Lifecycle +Management.” Sectino 5.1, National Institute of Standards and +Technology, U.S. Department of Commerce, June 2017. +[https://doi.org/10.6028/NIST.SP.800-63](https://doi.org/10.6028/NIST.SP.800-63b)b. + +[18] Saxe, D. H., (2021) “Account Recovery (v2)”, *IDPro Body of +Knowledge* 1(8). doi: + +[19] Again, the writer of this article doesn’t create the terms of art +but relays them with no small amount of cynicism. + +[20] Hodges, J., Jones, J.C., Jones, M.B., Kumar, .A., and Lundberg, E. +(2021) “Web Authentication: An API for accessing Public Key Credentials +Level 2” W3C https://www.w3.org/TR/webauthn-2/ + +[21] Salt and Pepper reference + +[22] Spacey, J. (2023) “Cryptography: Salt vs Pepper” Simplicable +(Accessed on October 19, 2023) https://simplicable.com/IT/salt-vs-pepper + +[23] If you didn’t like passwords before, going through a CIAM migration +will absolutely make you loathe them for certain. diff --git a/Digital Identity/idpro-account-recovery-final.md b/Digital Identity/idpro-account-recovery-final.md index bec8806..c2c7d8c 100644 --- a/Digital Identity/idpro-account-recovery-final.md +++ b/Digital Identity/idpro-account-recovery-final.md @@ -1,71 +1,73 @@ -# Account Recovery (v2) +Dean H. Saxe, Sr. Security Engineer, Amazon Web Services -By Dean H. Saxe, Sr. Security Engineer, Amazon Web Services - -© 2021, 2022 IDPro, Dean Saxe +© 2021, 2022, 2023 IDPro, Dean Saxe *To comment on this article, please visit our [GitHub repository](https://github.com/IDPros/bok) and [submit an issue](https://docs.github.com/en/github/managing-your-work-on-github/opening-an-issue-from-code).* -# Terminology/Glossary - - **Account Owner –** An entity that “owns” or claims responsibility +Terminology/Glossary +==================== + +- **Account Owner –** An entity that “owns” or claims responsibility for an account. Generally, an account is issued in the name of the owner(s) or their delegate(s) in the case of enterprises. - - **Account Recovery (AR) -** The process of returning account access +- **Account Recovery (AR) -** The process of returning account access to an account owner when they lose, forget, or cannot otherwise produce the account’s nominal credentials. This may be accomplished in person, remote, or in a hybrid format. - - **Account Takeover -** Account takeover is a form of identity theft +- **Account Takeover -** Account takeover is a form of identity theft and fraud, where a malicious third party successfully gains access - to a user’s account credentials.\[1\] + to a user’s account credentials.[1] - - **Agent (also “Customer Service Agent”)** - The person responsible +- **Agent (also “Customer Service Agent”)** - The person responsible for communicating with and solving problems on behalf of your customer or end-user.  - - **Credentials -** Any attribute or shared secret that can be used to +- **Credentials -** Any attribute or shared secret that can be used to authenticate a user. - - **Knowledge-Based Authentication (KBA) -** A method of +- **Knowledge-Based Authentication (KBA) -** A method of authentication that uses information known by both the end-user and the authentication service but is not necessarily a secret. - - **Multi-Factor Authentication (MFA) -** An approach whereby a user’s +- **Multi-Factor Authentication (MFA) -** An approach whereby a user’s identity is validated to the trust level required according to a security policy for a resource being accessed using more than one factor (something you know (e.g., password), something you have - (e.g., smartphone), something you are (e.g., fingerprint).\[2\] + (e.g., smartphone), something you are (e.g., fingerprint).[2] - - **Personal Data -** Personal data are any information which are - related to an identified or identifiable natural person.\[3\] +- **Personal Data -** Personal data are any information which are + related to an identified or identifiable natural person.[3] - - **Social engineering -** Social engineering is a method of +- **Social engineering -** Social engineering is a method of manipulating people so they give up confidential information, such as passwords or bank information, or grant access to their computer - to secretly install malicious software.\[4\] + to secretly install malicious software.[4] - - **Threat Modeling -** Threat modeling is an analysis technique used +- **Threat Modeling -** Threat modeling is an analysis technique used to help identify threats, attacks, vulnerabilities, and - countermeasures that could impact an application or process.\[5\] + countermeasures that could impact an application or process.[5] - - **Username -** An identifier unique to the authentication service +- **Username -** An identifier unique to the authentication service used in conjunction with a credential such as a password or FIDO authenticator to authenticate a user. -# Account Recovery +Account Recovery +================ -## Defining AR +Defining AR +----------- What is AR? You’ll see one definition above, but a fuller description follows. AR is a mechanism or collection of mechanisms that are used to maintain continuity of access to a user’s services. AR operates by providing an *alternative authentication mechanism* to *reestablish authentication credentials*, such as through re-identification of the -user. A key property of any AR mechanism is that it must meet or +user*.* A key property of any AR mechanism is that it must meet or exceed the security of the nominal authentication mechanism for the account that it serves to recover. If this property is not met, users may choose to execute the AR mechanism rather than remember their @@ -80,7 +82,7 @@ required two pieces of readily available information: my mother-in-law’s maiden name and my wife’s date of birth. Each year I would log in with these pieces of known information, collect the documents I needed, and logout. The password was not required, nor did the AR process require a -password reset or notify the account holder of the access\! +password reset or notify the account holder of the access! ### An Iron Triangle of Account Recovery @@ -89,13 +91,14 @@ concerns - Privacy, Access Continuity, and Security - that meet my needs within the constraints of the service I’m accessing. In an iron triangle, I can move away from any vertex toward another to obtain relatively more of one concern (e.g., privacy) at the cost of another -(e.g., security or access continuity).\[6\] +(e.g., security or access continuity).[6] In the stock example above, the system design focused on high access continuity exclusively to the detriment of security - the account is easy to access by malicious actors who could execute transactions - and privacy - the account owner is fully identified by the stock service, as -is the nature for most financial systems. ![](AR-Figure1.jpg) +is the nature for most financial systems. +![](AR-Figure1.jpg) In contrast, my current bank focuses on access continuity and security - it is hard to gain access to my account online due to strong @@ -105,7 +108,7 @@ identification. The bank is obligated to identify me based on my government-provided identity documents (e.g., passport, driver’s license) for conducting certain transactions and uses this same in-person authentication of my government-issued credentials to restore -access to my account if required. *This is an act of authentication\!* +access to my account if required. *This is an act of authentication!* The driver’s license looks normal, unaltered, anti-fraud elements are in place, the expiration date is valid, the image looks like the person standing in the bank, the document is machine-readable and matches the @@ -139,11 +142,12 @@ the appropriate vertex of the triangle.* In a nutshell, Identity architects can use the iron triangle to first identify where in the triangle the use case is situated and second to -identify the trade-offs that are made to meet the needs of the use case. -However, the devil is in the details, and those details will differ -wildly across different identity ecosystems. +identify the trade-offs that are made to meet the needs of the use +case.[7] However, the devil is in the details, and those details will +differ wildly across different identity ecosystems. -## Consumer AR +Consumer AR +----------- Consumer use cases are focused on end-users of commercial systems open to the general public. Depending on the nature of the consumer @@ -157,7 +161,8 @@ mechanisms for their users, the risk of compromise of each account type is significantly different. There is also a different set of information available to these different consumer services to enable AR. -## Enterprise AR +Enterprise AR +------------- In the enterprise, the focus is usually on access continuity – minimizing user downtime - and security for AR processes. AR is @@ -171,21 +176,24 @@ trusted intermediary (e.g., supervisor) to vouch for the employee, and intermediate the process of AR, using a quorum of trusted intermediaries to vouch for the employee, etc. -## Education AR +Education AR +------------ Similar to enterprises, the focus for education is on access continuity. On-campus staff and students can use in-person services for account recovery. Remote students and staff may use similar mechanisms to enterprises, adapted to their unique environment. -## Government AR +Government AR +------------- Due to the wide variations in government systems and services, there is little consistency in this realm. Implementers should be observant of local, national, and supranational laws, regulations, and cultural norms when working with account recovery in this space. -# AR Mechanisms +AR Mechanisms +============= Below we review common AR mechanisms. However, we would be remiss to not include as the first and primary mechanism *Make Losing Access @@ -202,19 +210,19 @@ At the most basic level, services should [nudge](https://www.amazon.com/Nudge-Improving-Decisions-Health-Happiness/dp/014311526X) their users into making good decisions. This can include: - - Baselining contact information – does the user have access to their +- Baselining contact information – does the user have access to their email, phone, or other contact channels? If not, is there a backup mechanism to reach the user? Did your identity system close the loop, ensuring access to the primary contact information to complete account registration? - - Baselining authentication mechanisms – Your users may have one or +- Baselining authentication mechanisms – Your users may have one or many devices used to authenticate to different services. Can the user access their authentication mechanism(s) such as FIDO authenticators, OTPs, and a phone number for SMS? Do the devices still work? Are the device and/or mechanisms still supported? - - Back-Up Authentication – How will your users authenticate if the +- Back-Up Authentication – How will your users authenticate if the primary authenticator is unavailable? The canonical example is a user who is flying – they have internet access but may not have SMS messaging. How will these users authenticate if the service requires @@ -224,15 +232,27 @@ their users into making good decisions. This can include: an AR event or limit the availability of the service. Limiting users to a single MFA mechanism *ensures* that that user will need to execute AR if the device is lost, broken, or temporarily - unavailable. *This is a user experience that should be avoided\!* + unavailable. *This is a user experience that should be avoided!* - - Remind users to set up one or more AR mechanisms early in the +- Remind users to set up one or more AR mechanisms early in the account lifecycle, and nudge users to baseline those mechanisms regularly. *Users without an AR mechanism may not be able to recover accounts.* If the user has not configured AR, use significant changes (e.g., exceptional growth in usage of a cloud service), security checkups, or other dashboards to drive user actions. +- Use synced passkeys. Synced passkeys enable the process of + credential recovery in addition to the existing account recovery + mechanisms. Credential recovery for synced passkeys, e.g., those + synchronized to a platform such as Apple or Google, or a third-party + passkey provider, such as 1Password or Dashlane, is facilitated by + the user's passkey provider. Functionally, credential recovery + operates by enabling the user to bootstrap a new device into the + provider's ecosystem after losing all prior access. Mechanisms are + non-standard and likely to vary between providers, therefore, the + security of these mechanisms must be assessed on a + provider-by-provider basis. + Identity providers should also guide their users to avoid single points of failure on the user side. For example, if the user places their credentials in a password safe and recovery codes are stored in the same @@ -249,21 +269,21 @@ experience. All actions that impact the user’s ability to maintain access continuity must be reported to the user. These include, but are not limited to: - - Changes to the account email address +- Changes to the account email address + +- Changes to the account phone number(s) - - Changes to the account phone number(s) +- Changes to the account credentials including, but not limited to - - Changes to the account credentials including, but not limited to - - - Passwords - - - MFA devices / mechanisms - - - Reset or re-issuance of recovery codes + - Passwords - - Removal or addition of trusted intermediaries + - MFA devices / mechanisms - - Account recovery (success or failure) + - Reset or re-issuance of recovery codes + +- Removal or addition of trusted intermediaries + +- Account recovery (success or failure) Due to the time-sensitive nature of these messages, they should be broadcast to all available channels which the use has consented to, such @@ -280,17 +300,17 @@ once to access a service in lieu of the user’s normal credentials. These bearer tokens take a few forms: - - Alphanumeric codes sent via email or SMS in response to an AR +- Alphanumeric codes sent via email or SMS in response to an AR request - - Magic links, a form of passwordless login, sent via email or SMS in +- Magic links, a form of passwordless login, sent via email or SMS in response to an AR request - - Recovery codes obtained prior to losing access and stored as +- Recovery codes obtained prior to losing access and stored as physical or digital copies in a safe place, such as a fireproof safe. - - Recovery code sent to the user via postal mail or private delivery +- Recovery code sent to the user via postal mail or private delivery service Grouping these mechanisms as bearer tokens allows us to reason about @@ -302,50 +322,50 @@ are stored by the user. **Benefits** - - An easy user experience that requires no specialized knowledge or +- An easy user experience that requires no specialized knowledge or hardware. After triggering an AR event, such as by entering a username into an AR workflow, the user cashes in the bearer token for the ability to reestablish credentials with the service. **Threats and Mitigations** - - Bearer tokens may be used by whoever bears them – this makes them +- Bearer tokens may be used by whoever bears them – this makes them easy to use and abuse, such as through phishing. - - - Minimize the validity window of all bearer tokens. - - - Keep state – is the user on the same device and same browser as + + - Minimize the validity window of all bearer tokens. + + - Keep state – is the user on the same device and same browser as when the request was triggered? Has the IP changed? What other data can be collected to ensure the user has not been phished for this information. - - The risk of bearer tokens also encompasses the risk of the medium by +- The risk of bearer tokens also encompasses the risk of the medium by which they are sent to the user. These threats cannot be mitigated by the identity provider. - - - Email is subject to interception, such as by phishing, leading + + - Email is subject to interception, such as by phishing, leading malicious actors to access the bearer tokens sent to the email address. - - - SMS is subject to interception, such as through SIM swapping + + - SMS is subject to interception, such as through SIM swapping attacks and SS7 vulnerabilities. - - - Email and SMS mechanisms are subject to threats against the + + - Email and SMS mechanisms are subject to threats against the providers and their infrastructure, as well. - - Users fail to copy recovery codes, fail to store the recovery codes +- Users fail to copy recovery codes, fail to store the recovery codes securely, or lose the recovery codes. - - - Providers can recommend mechanisms for storage and management of + + - Providers can recommend mechanisms for storage and management of codes, but the user may not follow the guidance. - - Users lose access to their email or phone number or enter incorrect +- Users lose access to their email or phone number or enter incorrect values which the user cannot access. - - - Verify the user has access to the email or phone number when + + - Verify the user has access to the email or phone number when they are submitted to the IdP. - - - Baseline the continued access to the email and phone number over + + - Baseline the continued access to the email and phone number over time. ### Knowledge-Based Authentication / Security Questions @@ -354,21 +374,22 @@ Both Knowledge-Based Authentication (KBA) and Security Questions are used as recovery mechanisms by having the user “prove” they are the legitimate owner by answering questions known only to the user. Unfortunately, both KBA, based on public information databases or recent -user transactions, previous passwords, and security questions, based on preconfigured -questions and answers provided by the user, are relatively weak recovery -mechanisms. +user transactions, previous passwords, and security questions, based on +preconfigured questions and answers provided by the user, are relatively +weak recovery mechanisms. KBA mechanisms often utilize information such as home addresses, loan dates/amounts, and credit report data to weakly identify the human owner of an account. However, due to numerous data breaches, this information is insufficiently secret and should not be depended upon as a recovery -mechanism for accounts with any significant value. +mechanism for accounts with any significant value. -Even in the absense of data breaches, information used for KBA may often be available to family members or other parties close to the user, reducing their efficacy. +Information used for KBA may often be available to family members or +other parties close to the user, reducing their efficacy. -Similarly, security -questions often have predictable or easily identifiable answers. -Questions such as favorite color have low entropy (according to +Similarly, security questions often have predictable or easily +identifiable answers. Questions such as favorite color have low entropy +(according to [this](https://www.huffpost.com/entry/house-beautiful-2012-color-report_n_1840383?guccounter=1#:~:text=According%20to%20House%20Beautiful's%20Color,purple%20tied%20at%208%20percent.) study, 64% of Americans choose one of four favorite colors, blue (29%), green (21%), purple (8%), and red (8%)), while questions about a @@ -380,42 +401,42 @@ recommended for the lowest-risk operations as a last resort. **Benefits** - - KBA and secret questions are easy to use, when they work. +- KBA and secret questions are easy to use, when they work. **Threats and Mitigations** - - KBA data may be obtained from breach corpuses, public databases. - - - Don’t use KBA for account recovery. +- KBA data may be obtained from breach corpuses, public databases. - - Insufficient protection in cases of domestic violence or intimate + - Don’t use KBA for account recovery. + +- Insufficient protection in cases of domestic violence or intimate partner violence where the KBA data may be known. - - - Don’t use KBA for account recovery. - - Customers may not remember details to answer KBA questions. A + - Don’t use KBA for account recovery. + +- Customers may not remember details to answer KBA questions. A customer’s inability to remember details such as financial transactions will trigger false negative matches for legitimate customers. Conversely, a user who answers all questions correctly may be a fraudster. - - - Don’t use KBA for account recovery. - - Security questions and answers may be forgotten. Users may fail to + - Don’t use KBA for account recovery. + +- Security questions and answers may be forgotten. Users may fail to recall the answers, misspell answers, misuse capitalization or punctuation, all of which could cause the user to fail authentication. - - - Baselining of security questions and answers to ensure access + + - Baselining of security questions and answers to ensure access continuity. - - Security questions and answers are alternative passwords and suffer +- Security questions and answers are alternative passwords and suffer the same risks as any password authentication scheme. - - - Users must never be asked to share KBA data or security + + - Users must never be asked to share KBA data or security questions and answers with CS agents to eliminate this risk. - - - Follow password storage guidance for all security questions and + + - Follow password storage guidance for all security questions and answers. ### Identity Verification / Identity Proofing @@ -443,45 +464,45 @@ human on the identity document (to some level of certainty). **Benefits** - - Establishes a binding between the natural person and the user +- Establishes a binding between the natural person and the user account that cannot be broken. Even if the user replaces their passport, identity verification can be re-executed to verify that the human is the “owner” of the account they are trying to recover (within certain confidence intervals). - - Resistance to scalable fraudulent mechanisms, though this depends +- Resistance to scalable fraudulent mechanisms, though this depends upon the specific mechanisms used. - - May be highly automated with Artificial Intelligence/Machine +- May be highly automated with Artificial Intelligence/Machine Learning (AI/ML); however, many providers still use manual review of less common identity documents first before using them to train AI/ML systems. **Threats and Mitigations** - - Users are uncomfortable sharing identity documents with online +- Users are uncomfortable sharing identity documents with online services. For example, the United States Internal Revenue Service (IRS) used ID.me to provided Identity Proofing services in 2022, resulting in a [significant - backlash](https://venturebeat.com/2022/04/15/the-irs-id-me-debacle-a-teaching-moment-for-tech/).\[7\] - - - Provide clear information on how the data provided will be used + backlash](https://venturebeat.com/2022/04/15/the-irs-id-me-debacle-a-teaching-moment-for-tech/).[8] + + - Provide clear information on how the data provided will be used and stored. - - - Provide an alternative mechanism for users who are unwilling or + + - Provide an alternative mechanism for users who are unwilling or unable to provide identity documents for remote ID Proofing. In-person, identity proofing, for example. - - Fraudulent documents - - - Today, there are no common criteria to assess identity document +- Fraudulent documents + + - Today, there are no common criteria to assess identity document verification/proofing services against one another. - - Presentation Attacks – presenting a static image or video of the +- Presentation Attacks – presenting a static image or video of the real person, rather than the person attempting fraudulent identity verification - - - Images and video selfies should use mechanisms of liveness + + - Images and video selfies should use mechanisms of liveness detection to ensure the images are real and being captured in real-time. @@ -514,23 +535,22 @@ using the AR process to gain access to unauthorized accounts. **Benefits** - - Distributes the work of AR amongst many possible trusted users, +- Distributes the work of AR amongst many possible trusted users, allowing for a high level of access continuity. **Threats and Mitigations** - - Malicious “trusted” intermediary takes over a targeted account. - - - Require quorums - - - Don’t pass recovery tokens, URLs, etc., through the trusted +- Malicious “trusted” intermediary takes over a targeted account. + + - Require quorums + + - Don’t pass recovery tokens, URLs, etc., through the trusted intermediary. Allow the intermediary to trigger sending the token to the subject of the AR action via email, SMS, or other - mechanisms. (Be careful, this could look like phishing\!) + mechanisms. (Be careful, this could look like phishing!) -## - -## Possession Factor +Possession Factor +----------------- Similar to the bearer token discussed above, a possession factor – such as the ability to sign a transaction with a specific private key – can @@ -539,7 +559,7 @@ expected to generate and manage their own keys securely. The addition of FIDO2 security keys and passkeys creates a secure mechanism for creating and managing account-specific key pairs. When used as a first-factor device (e.g., the passwordless flow), a security key or passkey can be -registered as a “recovery key” for the account.\[8\] Only the owner in +registered as a “recovery key” for the account.[9] Only the owner in possession of the key and with the biometric or PIN to unlock it can recover the account. Applications on a mobile device can be used as a possession factor when unlocked with the user’s biometric or PIN code. @@ -552,32 +572,34 @@ DID document, the owner can conceivably recover an account. **Benefits** - - Ease of AR if the possession factor is registered early in the +- Ease of AR if the possession factor is registered early in the lifecycle and can be made available when needed by the user. **Threats & Mitigations** - - Loss of the cryptographic key or its storage medium. - - - Implementers must consider the relative frequency of loss of a +- Loss of the cryptographic key or its storage medium. + + - Implementers must consider the relative frequency of loss of a phone, for example, vs. a hardware key vs. a public key generated on the user’s disk. This may be mitigated through passkeys synced via a cloud service. - - - Allow for multiple possession factors per account. - - - Periodically remind users to check their ability to recover with + + - Allow for multiple possession factors per account. + + - Periodically remind users to check their ability to recover with the possession factor(s) -## Customer Service +Customer Service +---------------- The final mechanism for AR is through a customer service mechanism, such as customer service for an enterprise. Customer service may use one or more of the mechanisms identified above to process an AR request. For additional information on using CS for AR, see “Managing Identity in -Customer Service Operations” by Arynn Crow and JP Rowan.\[9\] +Customer Service Operations” by Arynn Crow and JP Rowan.[10] -## No Account Recovery +No Account Recovery +------------------- In some scenarios, no account recovery may be the secure and private option. While not recommended for most use cases, not supporting any @@ -585,7 +607,8 @@ account recovery is seen in practice and may be the preferred option for some high-security services in order to minimize the risk of account takeover. -# Conclusion +Conclusion +========== Account recovery is a mechanism to support authentication for your service. Building an AR service requires service owners to consider what @@ -600,58 +623,64 @@ explicitly if they are to regain access to lost accounts. Therefore, AR is more than just a technical solution to be implemented; it is a user experience and human behavior problem to be solved. -# Acknowledgments +Acknowledgments +=============== - - Arynn Crow +- Arynn Crow - - JP Rowan +- JP Rowan - - David Brossard +- David Brossard - - Paul Figura +- Paul Figura -# Author Bio +Author Bio +========== Dean H. Saxe is a Senior Security Engineer with the AWS Identity team and a founding member of IDPro. He can be reached at -[dean@thesax.es](mailto:dean@thesax.es) or on Twitter -@n3rd1ty. + or on Twitter @n3rd1ty. -# Change Log +Change Log +========== -| Date | Change | -| --- | ---------- | +| | | +|------------|-----------------------------------------------------| +| Date | Change | +| 2023-10-27 | V3 published; addition of info on passkey recovery | | 2022-06-03 | V2 published; clarifications added to AR mechanisms | -| 2021-04-19 | V1 published | +| 2021-04-19 | V1 published | + +[1] Flanagan (Editor), H., (2021) “Terminology in the IDPro Body of +Knowledge”, *IDPro Body of Knowledge* 1(7). doi: +[https://doi.org/10.55621/idpro.41](https://doi.org/10.55621/idpro.41) -1. Flanagan (Editor), H., (2021) “Terminology in the IDPro Body of - Knowledge”, *IDPro Body of Knowledge* 1(7). doi: - [https://doi.org/10.55621/idpro.41](https://doi.org/10.55621/idpro.41) +[2] Ibid. -2. Ibid. +[3] Ibid. -3. Ibid. +[4] Ibid. -4. Ibid. +[5] Ibid. -5. Ibid. +[6] Caccamese, A. & Bragantini, D. (2012). “Beyond the iron triangle: +year zero.” Paper presented at PMI® Global Congress 2012—EMEA, +Marsailles, France. Newtown Square, PA: Project Management Institute, +[https://www.pmi.org/learning/library/beyond-iron-triangle-year-zero-6381](https://www.pmi.org/learning/library/beyond-iron-triangle-year-zero-6381) -6. Caccamese, A. & Bragantini, D. (2012). “Beyond the iron triangle: - year zero.” Paper presented at PMI® Global Congress 2012—EMEA, - Marsailles, France. Newtown Square, PA: Project Management - Institute, - [https://www.pmi.org/learning/library/beyond-iron-triangle-year-zero-6381](https://www.pmi.org/learning/library/beyond-iron-triangle-year-zero-6381) +[7] Bucci, Steven. “The Iron Triangle of Cybersecurity.” Security +Debrief. February 23, 2011. +. -7. Thimot, Tom, “The IRS/ID.me debacle: A teaching moment for tech,” - Venture Beat post, 15 April 2022, - . +[8] Thimot, Tom, “The IRS/ID.me debacle: A teaching moment for tech,” +Venture Beat post, 15 April 2022, +. -8. The astute reader will note that this is the same mechanism proposed - by the FIDO Alliance for recovering from loss of a security key. At - this time, there is no way to backup a security key, therefore - registering multiple keys is the specified mechanism of account - recovery. +[9] The astute reader will note that this is the same mechanism proposed +by the FIDO Alliance for recovering from loss of a security key. At this +time, there is no way to backup a security key, therefore registering +multiple keys is the specified mechanism of account recovery. -9. Crow, A. & Rowan, J. P., (2021) “Managing Identity in Customer - Service Operations”, *IDPro Body of Knowledge* 1(4). doi: - [https://doi.org/10.55621/idpro.65](https://doi.org/10.55621/idpro.65). +[10] Crow, A. & Rowan, J. P., (2021) “Managing Identity in Customer +Service Operations”, IDPro Body of Knowledge 1(4). doi: +[https://doi.org/10.55621/idpro.65](https://doi.org/10.55621/idpro.65). diff --git a/Introduction/businesscase-for-IAM.md b/Introduction/businesscase-for-IAM.md new file mode 100644 index 0000000..2bda464 --- /dev/null +++ b/Introduction/businesscase-for-IAM.md @@ -0,0 +1,561 @@ +By André Koot + +© 2023 IDPro, André Koot + +*To comment on this article, please visit our [GitHub +repository](https://github.com/IDPros/bok) and [submit an +issue](https://docs.github.com/en/github/managing-your-work-on-github/opening-an-issue-from-code).* + +**Please note: this article has large, complex tables viewable only in +the** [PDF](https://bok.idpro.org/article/97/galley/222/view)**.** + +Introduction +============ + +Identity and Access Management (IAM) is often seen as one of many +expenses that must be controlled within an organization. Businesses need +to see the benefits of an IAM program before they are willing to invest +in IAM programs. This circular demand can leave IAM improvements stuck +in a never-ending game of catch-up. Businesses fail to see the strategic +value in a solid IAM program until they see tactical improvements +directly attributed to IAM services. + +A solid business case helps break this deadlock by providing different +perspectives on the overall Return On Investment (ROI) that IAM can +bring to an organization. The best business cases include: + +- the concept of the quantitative versus the qualitative components of + the business case for IAM; + +- the perspective from different IAM domains (e.g., internally facing + IAM requirements from the enterprise, externally facing IAM + requirements from the customers, cybersecurity requirements); and + +- the recognition of the different strategic and operational + requirements for both IT and the business. + +Of course, different companies will respond better to different types of +business cases. Some will be driven purely by the finances, while others +will respond better by putting IAM in context with other services in an +organization. Some may instead be primarily driven by the regulatory +requirements governing their specific business operations (e.g., finance +industry regulations). + +Terminology +----------- + +| Term | Definition | +|------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| Attribute-Based Access Control (ABAC) | Attribute-Based Access Control is a pattern of access control involving dynamic definitions of permissions based on information (“attributes” or “claims”), such as job code, department, or group membership. | +| Business to Business (B2B) | Business to Business processes in the field of IAM involve business partner access to company resources using some form of remote access (e.g., federated access). | +| Business to Consumer (B2C) | Business to Consumer processes in the field of IAM are customer or consumer access to company resources. In B2C, consumers manage their own identity in a CIAM. The company still manages access to the resources, using ABAC or PBAC methods for access control | +| Business to Employee (B2E) | Business to Employee, also called workforce IAM, includes managing identities and accounts for employees and contractors following an identity lifecycle. | +| Consumer Identity and Access Management (CIAM) | Consumer Identity and Access Management, or Customer Identity and Access Management, involves providing access to company resources through a digital identity managed by the customer. | +| Identity Governance and Administration (IGA) | Identity Governance and Administration is a discipline focusing on identity life cycle management and access control from an administrative perspective. | +| Joiner, Mover, and Leaver (JML) | The joiner/mover/leaver lifecycle of an employee identity considers three stages in the life cycle: joining the organization, moving within the organization, and leaving the organization. | +| Policy-Based Access Control (PBAC) | Policy-Based Access Control is a pattern of access control involving dynamic definitions of access permissions based on attributes (as in ABAC) and context for authorized access. | +| Privileged Access Management (PAM) | Privileged Access Management is a mechanism for managing temporary access for accounts with high-risk permissions. PAM often involves check-out and check-in of a credential generated for a single use. | +| Role-Based Access Control (RBAC) | Role-Based Access Control involves using roles at run-time to govern control access. It is a pattern of access control involving sets of static, manual definitions of permissions assigned to “roles,” which can be consistently and repeatedly associated with users with common access needs. | +| Return on Investment (ROI) | Return on Investment is the economic measure of value of an investment, using costs, revenues, interest rates, and lifecycle as parameters. | +| Sunk cost | Expenses that have already been made in the past and that are unrecoverable. | + +Acronyms +-------- + +C-level Chief Executive Level, including Chief Executive Officer, Chief +Financial Officer, Chief Information Officer, etc. + +BC/DR Business Continuity/Disaster Recovery + +CI/CD Continuous Integration/Continuous Deployment + +GDPR General Data Protection Regulation + +HIPAA Health Insurance Portability and Accountability Act + +HR Human Resources + +IAM Identity and Access Management + +IT Information Technology + +ROI Return on Investment + +SSO Single Sign-On + +Y2K Year 2000 + +ZTA Zero Trust Authorization + +Starting an IAM program +======================= + +When working in IAM, the question often arises as to whether the costs +and investments of an IAM program are worthwhile. Organizations +generally ask for a financial business case since that is a traditional +way to argue for an investment decision. It takes significant effort to +convince decision-makers to look beyond the financial viewpoint. + +Most IAM programs are started to solve one of three enterprise problems: + +- Operations management (HR, IT) + + - for increasing employee efficiency, enhancing data quality, and + cost-effectiveness[1] + +- Enterprise, IT, or security architecture + + - for aligning with current best practices such as new controls + for API access, support for Zero Trust, and supporting + multi-factor authentication along with resolving issues of + technology debt + + - for realizing newly defined strategic business initiatives, such + as implementing a Consumer IAM (CIAM) strategy for revenue + generation, improving customer services, and easing digital + transformation[2] + +- Chief Executive Level (C-level) + + - for responding to audit findings in a management letter or + directives from a supervisory agency or as the result of a + security incident or data breach[3] + +Regardless of where the IAM program starts, a lot of money will be +required from multiple cost centers before the program is complete. It +often takes several budget cycles and significant organizational +commitment to realize an effective IAM initiative. The program's +sponsors must be prepared to make a business case to justify the +organizational effort and the financial costs. Even if the C-level +initiates the IAM efforts, a business case must often remind all +stakeholders why this initiative is critical to the organization. + +So, what elements of IAM investments can be identified that make an +investment worthwhile? + +This article looks at the business case for IAM from different +perspectives. + +- The first viewpoint is based on the difference between a business + case's quantitative and qualitative components. + + - Quantitative means an objective calculation of the financial + costs and benefits of an investment + + - Qualitative means that the costs and benefits of an investment + cannot be calculated objectively, but the components have value + for the business or bring additional trouble. + +- A second viewpoint looks at IAM from different domains: B2E (i.e., + Workforce IAM, Identity Governance and Administration (IGA)), B2C + and B2B (i.e., CIAM), and Privileged Access Management (PAM). + +- The third viewpoint is the organizational viewpoint: strategic, + tactical, and operational reasons for implementing IAM. + +There is no easy, complete formula for calculating the ROI of an +investment in IAM. But at least these views can help to convince the +stakeholders to look beyond the purely financial impact of IAM. + +The Added Value of IAM +====================== + +Preventing Negative Impacts +--------------------------- + +IAM strengthens businesses in many ways, from supporting business +continuity to protecting business resources and reputation. For example, +there are many reasons to consider IAM as a method for Business +Continuity and Disaster Recovery (BC/DR). As organizations grow, access +to resources becomes a liability: access to resources becomes more +challenging overall, and delegating tasks and responsibilities becomes a +bigger problem. If an organization is not in control of its data, +including information on who may access that data, its ability to +function in the case of significant business interruption is at risk. +Even in a disaster, maintaining a record of who has in the past and can +in the future access systems and data is critical. + +Possibly the most famous example of a disaster directly related to a +poorly managed and enforced IAM program is that of the Enron scandal in +the late 1990s.[4] In IAM terms, the scandal was partly a result of +executives circumventing management controls, possibly because of the +lack of fitting access controls. The best practice of Segregation of +Duties was circumvented by greed, organizational culture, and practices. + +At the same time, investments in IAM suffer from the prevention paradox. +Investing in IAM rarely brings immediate, visible improvements. Finding +the benefits (in terms of concrete cost savings) may be hard to achieve. +Would the effects be the same with fewer costs and efforts of the IAM +investment? It may seem like the Y2K crisis all over again.[5] + +Supporting Positive Impacts +--------------------------- + +Of course, not every organization suffers from the same malicious +drivers as Enron did. Still, that case highlights the need for access +control from the perspectives of business continuity, governance, and +compliance. To be in control, the need for managing identities and +especially the management of authorizations is demonstrated by this case +and many others. + +But there are more reasons for investing in IAM. In many organizations, +the need for IAM comes from the need for efficiency and high data +quality. Manually creating identities for personnel and adding and +revoking authorizations is inefficient, while the manual execution of +these tasks can result in a lack of data quality. Automating the process +can provide higher quality with less expensive results. + +Organizations will also find benefits in improving their user +experience. Developing single sign-on (SSO) services and self-service +access requests improves not just the efficiency of the process but also +the user’s satisfaction. The continuing development of external access +and the move toward API access led to the need for IAM-related programs. + +These lines of reasoning, while valid, may be too far away from daily +operations and immediate, visible improvements in efficiency. Businesses +and boards experience the need for short-term insight as well as +long-term improvements before they make further investments. In other +words, companies need a specific and complete business case for IAM. + +Different Dimensions of IAM Business Case +========================================= + +Quantitative versus Qualitative Business Case +--------------------------------------------- + +A simple formula for calculating the ROI looks thus: + +ROI="NetReturnonInvestment ⁄ Cost of Investment*100" \%" + +(see [Guide to calculating +ROI](https://www.investopedia.com/articles/basics/10/guide-to-calculating-roi.asp)) + +The simple formula can be used to calculate if an investment is anything +good, financially speaking. Suppose you want to invest 1 million and +later sell the investment for 1.1 million, resulting in a profit of +100,000; the ROI would then be + +(1,100000 – 1,000,000) / 1,000,000 \* 100% = 10% + +Of course, the calculation would be a little more complex for projects. +It is unlikely that you would invest 1 million in IAM and later sell the +investment, making a profit. This simple formula also hides the fact +that indirect returns are both critical for the overall measure of ROI +and extremely hard to quantify. + +First, let’s look at the distinction between the quantitative business +case and the qualitative business case. + +- The *Quantitative Business* *Case* is all about money. It is about + calculating the costs and benefits objectively, at least as much as + possible. This enumeration is relevant for managers to calculate all + investments in an organization to prioritize investments. To a + lesser degree, the business case can be input for a cash flow + analysis. In this article, we classify topics as objectively + quantifiable, but just like in risk management, some entries cannot + be calculated objectively. For example, the risk of penalties does + not result in an absolute value. It is an approximation of the cost + of the risk. The cost of the risk could be calculated as the chance + of discovery of the non-compliance times the potential maximal + amount of a fine. That means that, just like any approximation, it + has to be taken with a grain of salt. + +- For most governance, risk, and compliance managers, the *Qualitative + Business Case* will be the preferred justification for investments + in IAM solutions. The entries in the overview below may not be + objectively quantifiable, but that does not mean that they should + not be considered when prioritizing investments. + +- An interesting example of a financial business case is the situation + of banks and insurance companies who have to undergo a stress test + to find if they can survive a financial crisis. The capital + requirements are higher or lower depending on the risk level. High + capital requirements impact the money-making capabilities; a high + reserve is a lot of unused capital. These rules and regulations have + been defined in the EU Basel IV and Solvency 2 regulations, which + have also been adopted by the Federal Reserve in the US.[6] + +> If a bank has sufficient assurance about authorizations because of +> adequate access control, then data quality will be better, and risk +> (uncertainty about access) and capital requirements will be lower, +> resulting in a significant impact on revenue creation capabilities. + +The Business Case for Different IAM domains: IGA, PAM, and CIAM +--------------------------------------------------------------- + +Another view is that the business case for different types of +IAM-related programs may have different focal points because they focus +on different things. For example: + +- Identity Governance & Administration (IGA), which focuses on the + internal account and authorization management for employees and + contractors with enterprise access, has a root cause in automation, + efficiency of performing JML processes, and assigning and revoking + roles. While IGA investment decisions will benefit from a + quantitative approach to the business case, a purely quantitative + approach will not be enough to make the case. Costs and benefits + will probably lie in different cost centers that measure success in + different ways (e.g., in improved efficiency, in lower risk to + security, in regulatory compliance). So, unless the business case is + calculated companywide, the business case will be negative. + +- Privileged Access Management (PAM) is all about managing risks of + critical authorizations and remote access for internal accounts with + broad access to sensitive resources. Its focus lies in governance + and compliance. In this case, the business case is more likely to + start off with a qualitative focus and miss out on some of the + critical quantitative aspects that will strengthen the argument. The + business case will be qualitative at first sight, but a secondary + point of view may be limiting the risk of penalties and fines from + laws and regulations. + +- CIAM (used for B2C and B2B connections and also applicable for IoT + and OT access) focuses on self-service identity management of + consumers or customers. That moves convenience and consumer + appreciation into a competitive advantage. The quantitative approach + may not be sufficient; business continuity may be at risk for lack + of investment. + +This means that the business drivers for these domains are different and +that the business case will contain other components. + +Strategic, Tactical, and Operational Viewpoints +----------------------------------------------- + +The third way of looking at the concept of the business case is the +organization's viewpoint. In traditional organizational theory models +(e.g., the Anthony triangle[7]), we can identify the strategic, +tactical, and operational layers. And if we follow up on these separate +layers, there are also strategic, tactical, and operational +considerations for implementing IAM: + +### Strategic + +This topic is all about implementing business governance of Access, +putting the business in control of IAM, and taking IAM out of the realm +of IT. The underlying principles are: + +- Governance Risk and Compliance: to be able to show that the + organization is in control, to be compliant with laws and + regulations, and to prevent ‘Enron’ issues. + +- Competitor initiatives, competitive advantage: either to follow + industry best practices (for example, a competitor implemented IGA) + or to lead the market (for example, by implementing a leading CIAM + platform). + +These issues can also be seen as qualitative components in the business +case. + +### Tactical + +The tactical drivers may include enhancing business processes and +information flows, structuring the organization to be more agile, and +supporting merger and acquisition processes. But another driver could be +to reduce technical debt that prevents innovation and agility. Older +identity management solutions that are end-of-support or do not scale +well to the cloud should be replaced. + +The tactical components can be both quantitative and qualitative. + +### Operational + +Operational considerations are related to the effectiveness and +efficiency of people, processes, and technology. The automation of +manual processes, increasing efficiency through self-service activities, +and improving user experience are relevant topics for the business case. + +These manual processes can be automated: + +- User account management - In the JML processes, the workflow and the + lifecycle can be automated based on transactions in the source + system for identities (HR, student management, customer relationship + management (CRM), etc.). For example, when Role-Based Access Control + (RBAC) is implemented, granting and revoking of roles can also be + automated. So, user and account management, as well as role + management, can be automated, resulting in less manual work, faster + processing, better data quality, and cost savings. + +- Password reset – establishing a self-service mechanism for password + resets increases user satisfaction and customer service efficiency. + +- Reporting, certification, and attestation processes - these can be + automated, resulting in more transparency. + +- Data processing disclosure - Informing customers about the + processing of their data can be automated in CIAM portals. + +- Single Sign-on (SSO) – SSO enhances user convenience and reduces all + kinds of service desk-related calls. + +- Automated logging and auditing – Automated logging will facilitate + security operations and forensic readiness. + +Many of the operational issues can be regarded and calculated as +quantitative components in the business case. + +One Invalid View +---------------- + +One argument for not investing in IAM is the notion that an organization +may have already invested heavily in IAM solutions, resulting in capital +expenses that have not yet been written off. + +This is not how an organization should react to an identified need for +change. Costs based on decisions in the past should not be used in +future decision processes; past decisions would lead to lock-in or +in-agility for keeping up with the old choices. This kind of reasoning +is referred to as the ‘sunk cost fallacy’ where people as well as +organizations often continue with an action even as the costs outweigh +the benefits.[8] A useful counterargument to combat this fallacy is +that, in hindsight, individuals would make different decisions for their +organization. + +Overview of Business Case Topics +================================ + +This section offers an overview of the different components of the +business case for IAM. It is by no means a complete overview, but it +gives an indication of arguments for convincing anyone of the positive +effects of investing in an IAM program. The tables suggest both the +quantitative and the qualitative components of the business case for +each of the three example domains: IGA, CIAM, and PAM. These examples +can act as templates for other domains; practitioners will need to adapt +the specifics to suit their own organizations and use cases. The +strategic, tactical, and operational components can be recognized as +components in the qualitative and quantitative columns of the tables. + +The first table shows the components of the business case for Identity +Governance and Administration (automating JML and implementing RBAC). In +this table, both positive (green background) and negative (red +background) components of both the quantitative aspects (left column) +and qualitative aspects (right column) of the business case are +explained. + +The consecutive tables show comparable topics for both CIAM programs and +PAM programs. + +The negative financial components (investments, licenses, costs) are +comparable for all three domains. + +A basic cost savings formula is shown for some of the financial and +quantitative components as guidance. It will, however, be meaningless +without a good explanation of the benefits. + +***Please view the* +[PDF](https://bok.idpro.org/article/97/galley/222/view) *to see the +tables.*** + +*** +*** + +Closing Thoughts About the Business Case +======================================== + +As explained before, a short-term positive real quantifiable business +case can hardly ever be achieved. For instance, the real benefits of +automating the JML flow with RBAC will only be apparent after several +years, after adding multiple target systems across multiple lines of +business, thus generating more business value. When looking through +one-year project glasses, the outcome will not be financially +interesting enough. IAM cannot just be seen from a financial +perspective; there are many more considerations to be taken into +account. + +Pay attention to the following: + +The issue of just focusing on the financial business case is too +restrictive, more so when the investing stakeholder Is not the +stakeholder who benefits from the investment—as is often the case. In +many cases, the IT department is the cost center funding the investment. +But, as can be seen in the business case examples, other departments +profit from the investment in IAM. It is therefore essential to identify +all stakeholders and the advantages they gain from the investment in IAM +solutions, even if these benefits are not financial. + +A second topic that should not be ignored in the financial savings area. +Many manual activities are ‘hidden’ costs, including when users request +access, and managers review existing authorizations, approve new +requests, create accounts, and grant permissions or roles. These +activities disappear in the ‘normal’, daily tasks of employees and so +often go unaccounted for. By automating these tasks, employees can focus +on more valuable activities. In the financial business case, quantifying +this element may be an unwanted eye-opener. + +Considering a multi-faceted business case for IAM is essential for every +IAM program. A business case that goes beyond financial considerations +will build awareness and commitment for starting a multi-year program +that adds value to long-term business continuity. Approval is nice, but +do not make it depend on a financial business case only. + +Acknowledgments +=============== + +The author wishes to thank Robert Sherwood and IDPro Principal Editor +Heather Flanagan for their reviews and assistance in writing this +article, turning thoughts into words. + +Additional Reading +================== + +Beattie, Andrew. 2022. “How to Calculate Return on Investment (ROI).” +*Investopedia*, August. +https://www.investopedia.com/articles/basics/10/guide-to-calculating-roi.asp. + +Azmi, A. M. (2007). [Business cases for information technology +projects](https://www.pmi.org/learning/library/business-cases-information-technology-projects-7365). +Paper presented at PMI® Global Congress 2007—EMEA, Budapest, Hungary. +Newtown Square, PA: Project Management Institute. + +James Cook University (14th February 2020). [How to Write a Business +Case](https://online.jcu.edu.au/blog/how-to-write-business-case): +Tips, Resources and Examples. + +Wikipedia contributors, "Business case," *Wikipedia, The Free +Encyclopedia,* + +(accessed October 17, 2023). + +Author Bio +========== + +André Koot is principal consultant at and co-founder of SonicBee, a +Dutch IAM consultancy company (IDPro partner), focused on business +consultancy and giving IAM training courses. He is also a member of the +IDPro BoK committee and (co-)authored several articles in the BoK. + +  + +[1] Schueler, Chris. 2022. “Neglecting The IAM Process Is Fighting A +Losing Battle To Achieve Operational Excellence.” Forbes, April 8, 2022. +. + +[2] “Manage Technology Debt to Create Technology Wealth.” Gartner. +August 17, 2020. . + +[3] ​​ Shea, Sharon. “How IAM Systems Support Compliance.” *Security*, +July 2020. +. + +[4] Hayes, Adam. “What Was Enron? What Happened and Who Was +Responsible.” Investopedia, March 2023. +. + +[5] Allen, Frederick E. 2019. “Apocalypse Then: When Y2K Didn’t Lead To +The End Of Civilization.” *Forbes*, December 29, 2019. +. + +[6] “Basel IV Implementation in the EU: What Does the New Banking +Package Mean for Banks?” 2022. Oxford Law Blogs. February 3, 2022. + +and “Solvency II.” n.d. European Insurance and Occupational Pensions +Authority. +. + +[7] Larson, Theodore, and Daniel Friesen. n.d. “The Anthony Triangle and +an Analytics Framework: Developing a Business Analytics Curriculum +Conceptual Model.” *CERN European Organization for Nuclear Research*. +December 2020. . + +[8] “The Sunk Cost Fallacy - The Decision Lab.” n.d. The Decision Lab. +. diff --git a/Laws Regulations Standards/oauth2-introduction.md b/Laws Regulations Standards/oauth2-introduction.md new file mode 100644 index 0000000..3cb67f6 --- /dev/null +++ b/Laws Regulations Standards/oauth2-introduction.md @@ -0,0 +1,447 @@ +By Bertrand Carlier + +© 2023 IDPro, Bertrand Carlier + +*To comment on this article, please visit our [GitHub +repository](https://github.com/IDPros/bok) and [submit an +issue](https://docs.github.com/en/github/managing-your-work-on-github/opening-an-issue-from-code).* + +About OAuth2 +============ + +In a nutshell, this standard protocol aims to allow access from a +**client application** (a website, a mobile application, an +Internet-connected device, etc.) to a **protected resource** (e.g., an +API), possibly on behalf of a **resource owner** (e.g., the end-user). +It can be associated with several transport protocols but has been very +popular to secure REST web services. + +This article will focus on the current published standards; work is +underway in the [OAuth working +group](https://datatracker.ietf.org/wg/oauth/about/) in the IETF to +update some of this material. For more information on how OAuth came +about and its relationship with other authentication protocols, see +Pamela Dingle’s IDPro Body of Knowledge article, “Introduction to +Identity - Part 2: Access Management.”[1] + +OAuth2 can be considered a three-step protocol: + +1. Get an access token + +2. Use the access token + +3. Validate the access token + +A diagram of a software process Description automatically generated + +Figure 1: High-level diagram of OAuth2 flows + +When looking into the OAuth2 specification space, you are quickly +surrounded with many documents, making it difficult to determine the +easiest path to follow. + +Let’s see where to start the journey and where to head. + +Terminology +----------- + +| | | +|---------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------| +| **Term** | **Definition** | +| Client | A client application consuming an API | +| Protected Resource | An API in the OAuth2 terminology | +| Resource Owner | An end-user using the client application and granting it access to the protected resource | +| Authorization Server (AS) | The OAuth2 server is able to authorize a client, issue tokens, and potentially validate tokens | +| Scope | A string designating a (part) of a protected resource that a client is authorized to access | +| Bearer token | A token whose possession is sufficient to enable access to a protected resource | +| Sender constrained token | A token whose possession is not sufficient to enable access to a protected resource (additional proof of identity by the client application is required) | +| Access token | The OAuth2 token that allows a client to get access to a protected resource | +| Refresh token | The OAuth2 token that allows a client to renew an access token when it is expired without the user’s presence | + +**Where to start** +================== + +OAuth2 is defined through a series of IETF RFC documents that each +describe a specific aspect, use case, or profile of use of the protocol. + + + +Figure 2: An artistic rendering of OAuth and related standards, courtesy +of Aaron Parecki + +Everything starts with two RFC documents: + +- [RFC 6749 - The OAuth 2.0 Authorization + Framework](https://www.rfc-editor.org/info/rfc6749) defines four + ways for a client application to obtain a token from an + authorization server (two of those are now deprecated). Those are + called flows or authorization grants.[2] + +- [RFC 6750 - The OAuth 2.0 Authorization Framework: Bearer Token + Usage](https://www.rfc-editor.org/info/rfc6750) defines the way + for a client application to use a token in a subsequent request to a + protected resource.[3] + +- Later on, different documents would help with the validation step: + + - [RFC 7662 - OAuth 2.0 Token + Introspection](https://www.rfc-editor.org/info/rfc7662) + defining token introspection against the authorization server, + which can be used to verify token validity and extract data from + the token.[4] + + - or [RFC 9068 - JSON Web Token (JWT) Profile for OAuth 2.0 + Access Tokens](https://www.rfc-editor.org/info/rfc9068) + defining a JWT profile for the access token.[5] + +Let’s use this breakdown to see what OAuth2 offers. + +**Get a Token:** +---------------- + +This step can be seen as a two-step process: first, the client must be +authorized for an access token, then the client will perform a token +request. + +- As mentioned above, of the four initial ways to obtain a token, two + are deprecated following + [OAuth2.1](https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-1/) + (currently draft): + + - Resource Owner Password Credentials, which encouraged an + anti-pattern of sharing end-user credentials with the client + application + + - Implicit flow, which made extensive use of the browser’s front + channel and therefore introduced security issues + +- The two recommended flows remaining are the following: + + - **Authorization code flow** is the recommended way to obtain a + token when a resource owner is present and needs to authenticate + first and then consent to delegate access for the client + application to the protected resource. This flow uses + redirections within a user-agent, typically the user’s browser, + as well as a back-channel request to eventually obtain the + OAuth2 Access Token. + +> There is a first step to authorize the client to get an access token +> and then a second step where the client actually gets the token. +> +> An additional protection to the original Authorization Code flow is +> now recommended in order to tighten the security of OAuth2 +> authorization and deliver the Access Token to the legitimate client +> that initiated the request. The name of this additional protection is +> PKCE (for Proof Key Code Exchange, pronounced “pixie,” as defined in +> [RFC 7636](https://www.rfc-editor.org/info/rfc7636)) and is +> considered a good approach to handle public clients.[6] + +- **Client credentials** aim to authenticate the client application + only to deliver the access token (in that case, the AT is not linked + to an end user’s identity but only to the client application + identity). This flow is suited for application-to-application + access. + +**Use the Token** +----------------- + +This step aims to use the access token while calling the protected +resource. + +RFC 6750 describes how an access token should be conveyed to a protected +resource. In a very brief summary, and in order of preference, the token +should be passed as: + +- An HTTP header as a bearer token (Authorization: Bearer <access + token>) + +- A POST parameter + +- A GET parameter (aka Query String parameter) + +**Validate the Token** +---------------------- + +Finally, the protected resource receiving a token needs to check the +token’s validity. This token validation was, for a long time, left to +implementations to define how to proceed: + +- The token format is not specified and can be anything from a + randomly generated opaque string acting as a reference token to a + quite frequently witnessed JWT signed value token ([RFC + 7519](https://www.rfc-editor.org/info/rfc7519)), but it can be + anything that would fit the designers of any given + implementation.[7] + +- If the token is opaque to the client as per the RFC, no specific + instructions are defined regarding how the protected resource should + validate it. It relies on an out-of-band and + beyond-the-scope-of-the-specification process to agree between + protected resource and authorization server on how to validate a + token: digital signature validation and possibly decryption of a + self-contained token (see RFC 9068 for standardization of this + approach using JWT as the token format) or introspection of a + reference token against an Authorization Server (AS) endpoint (see + RFC 7662 for standardization of this approach). + +It is generally recommended to rely on one of those two documents to +help with interoperability between the protected resource and the +authorization server + +**Beyond the Basics** +--------------------- + +This section of the article now gives additional details on more aspects +of the OAuth2 protocol and additional specification documents. + +**Scopes** +---------- + +OAuth2 does not allow a client application to access any resource +without restriction once it has an access token. An authorization +request and, ultimately, the issued token holds a scope (which is a list +of space-delimited, case-sensitive strings) that will allow the +protected resource to determine if the authorization was indeed given to +access it. + +**Get a Token (Also)** +---------------------- + +A few additional ways to obtain an access token were later provided +through additional specifications: + +- [SAML profile](https://www.rfc-editor.org/info/rfc7522) and + [JWT profile](https://www.rfc-editor.org/info/rfc7523) will + allow the delivery of an access token in exchange for, respectively, + a SAML token or a JWT token issued for a specific end-user or + crafted by the client application itself in order to authenticate + itself.[8] + +- [Device flow](https://www.rfc-editor.org/info/rfc8628) will + allow Internet-connected devices to retrieve an access token even if + they can’t display a browser or are input-constrained.[9] This flow + will rely on the end-user using another device (e.g., a browser on a + smartphone) to complete part of the sequence. + +- [Token exchange](https://www.rfc-editor.org/info/rfc8693) + will enable an access token to be issued in exchange of any other + security token and will provide guidelines to correctly implement + delegation or impersonation.[10] + +**Tokens** +---------- + +Until now, only the access token was mentioned. It is the core token +that OAuth2 provides to client applications. This token is generally a +bearer token, meaning that any entity that gets access to it can use it +to access the protected resource. This characteristic has several +security implications: + +- The protected resource cannot be sure that the client application + currently requesting access is the same one that initially obtained + the token + +- The end user that may have had to be authenticated to allow the + token to be generated may not be present anymore + +Access tokens, therefore, can have different characteristics to mitigate +those implications: + +- Time-limited tokens. The specification recommends that the access + token has a limited lifetime. + +- Sender-constrained tokens. Recent specifications (mTLS, + [DPoP](https://www.rfc-editor.org/info/rfc9449), etc.) allow + that access tokens can be bound to the initial client application + using various mechanisms, generally involving proof-of-possession of + a cryptographic key both at the token request and at the token usage + and that the token is linked to that key material (through a public + key thumbprint for instance).[11] As a consequence, a + sender-constrained token can only be used by the application that + requested the token. It is worth noting that while approaches like + DPoP can protect against a stolen token, they do not protect against + a stolen client ID/secret for a client\_credential grant. + +OAuth2 also defines the concept of a **refresh token** issued by the +Authorization Server and shared with the client app. This refresh token +will allow the client app to request a fresh AT (e.g., once it expires) +and potentially a refreshed refresh token without having to involve the +end-user, for instance. This can be used to maintain a decent UX in a +single-page application (SPA) or to allow for offline access when the +user is not present anymore, but the client app needs access to the +protected resource. + +**Discovery** +------------- + +In order to help clients dynamically register against an authorization +server or programmatically get information about the authorization +server features and level of support, some discovery and dynamic +registration specifications are also available: + +- Client dynamic registration ([RFC + 7591](https://www.rfc-editor.org/info/rfc7591))[12] + +- Authorization Server Metadata ([RFC + 8414](https://www.rfc-editor.org/info/rfc8414))[13] + +**Beyond OAuth2** +================= + +Now that most OAuth2 specifications have been introduced, you can easily +imagine how difficult it can sometimes be to navigate through them and +ensure one’s implementation is solid and secure. OAuth2 working group +members created additional documents to help: + +- [RFC 6819](https://www.rfc-editor.org/info/rfc6819) - OAuth 2.0 + Threat Model and Security Considerations[14] + +- [OAuth 2.0 Security Best Current + Practice](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics) + (currently draft) + +- [OAuth + 2.1](https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-1/) + (currently draft) is a minor but important revision to the standard + that incorporates security best practices + +- [RFC 8252](https://www.rfc-editor.org/info/rfc8252) - OAuth 2.0 for + Native Apps for best practices around native application clients on + different platforms[15] + +- [OAuth 2.0 for Browser-Based + Apps](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps) + (currently draft) for best practices around Single Page Applications + +OAuth2 is also a foundation upon which other protocols were developed, +the most known among these being OpenID Connect. + +- [OpenID + Connect](https://openid.net/specs/openid-connect-core-1_0.html), + as described in the specification, is a “simple identity layer on + top of the OAuth 2.0 protocol.”[16] Contrary to OAuth2, which + focuses on authorization delegation, OIDC focuses on authentication. + It introduces another token (**ID Token**), which is shared between + the Authorization Server (or OpenID provider) and the client (or + Relying Party). This token is a JWT formatted token. It conveys + information about the authenticated identity through + standard-defined claims and information about the authentication + itself (time of authentication, method used, etc.). + +- [User-Managed Access + 2.0](https://docs.kantarainitiative.org/uma/wg/rec-oauth-uma-grant-2.0.html) + is another protocol defined on top of OAuth2 (as a new authorization + grant).[17] It introduces additional tokens, but most importantly, + it does introduce a new player in the picture: the **requesting + party,** which can be different from the resource owner (in OAuth2, + the resource owner is the requesting party). + +Additional Reading +================== + +For additional information on implementing OAuth2, these resources may +be of assistance: + +- Richer, Justin, and Antonio Sanso. 2017. *OAuth 2 in Action*. + Manning. + +- Parecki, Aaron. 2018. *OAUTH 2.0 Simplified*. Lulu.com. + +Author +====== + +Bertrand Carlier is a senior manager in the Cybersecurity & Digital +Trust practice at Wavestone consultancy with 20 years of experience. He +has been leading major Identity & Access Management projects, working +with many client companies in a variety of industries. + +He is devoted to promoting and encouraging the use of open standards and +has done so through leading projects and talks at various international +conferences. + +He likes nothing more than to tackle the newest problems in the Identity +and Access Management space: API & microservices security, IAM of +Things, AI for IAM and IAM for AI, and, of course, the longstanding +problem of “how to cope with both the legacy and the ever more shiny +(and accumulating) new toys?” + +[1] Dingle, P., (2020) “Introduction to Identity - Part 2: Access +Management”, *IDPro Body of Knowledge* 1(2). doi: + + +[2] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, +DOI 10.17487/RFC6749, October 2012, +<https://www.rfc-editor.org/info/rfc6749>. + +[3] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization Framework: +Bearer Token Usage", RFC 6750, DOI 10.17487/RFC6750, October 2012, +<https://www.rfc-editor.org/info/rfc6750>. + +[4] Richer, J., Ed., "OAuth 2.0 Token Introspection", RFC 7662, DOI +10.17487/RFC7662, October 2015, +<https://www.rfc-editor.org/info/rfc7662>. + +[5] Bertocci, V., "JSON Web Token (JWT) Profile for OAuth 2.0 Access +Tokens", RFC 9068, DOI 10.17487/RFC9068, October 2021, +<https://www.rfc-editor.org/info/rfc9068>. + +[6] Sakimura, N., Ed., Bradley, J., and N. Agarwal, "Proof Key for Code +Exchange by OAuth Public Clients", RFC 7636, DOI 10.17487/RFC7636, +September 2015, <https://www.rfc-editor.org/info/rfc7636>. + +[7] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC +7519, DOI 10.17487/RFC7519, May 2015, +<https://www.rfc-editor.org/info/rfc7519>. + +[8] Campbell, B., Mortimore, C., and M. Jones, "Security Assertion +Markup Language (SAML) 2.0 Profile for OAuth 2.0 Client Authentication +and Authorization Grants", RFC 7522, DOI 10.17487/RFC7522, May 2015, +<https://www.rfc-editor.org/info/rfc7522> and Jones, M., Campbell, +B., and C. Mortimore, "JSON Web Token (JWT) Profile for OAuth 2.0 Client +Authentication and Authorization Grants", RFC 7523, DOI +10.17487/RFC7523, May 2015, +<https://www.rfc-editor.org/info/rfc7523>. + +[9] Denniss, W., Bradley, J., Jones, M., and H. Tschofenig, "OAuth 2.0 +Device Authorization Grant", RFC 8628, DOI 10.17487/RFC8628, August +2019, <https://www.rfc-editor.org/info/rfc8628>. + +[10] Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J., and C. +Mortimore, "OAuth 2.0 Token Exchange", RFC 8693, DOI 10.17487/RFC8693, +January 2020, <https://www.rfc-editor.org/info/rfc8693>. + +[11] Campbell, B., Bradley, J., Sakimura, N., and T. Lodderstedt, "OAuth +2.0 Mutual-TLS Client Authentication and Certificate-Bound Access +Tokens", RFC 8705, DOI 10.17487/RFC8705, February 2020, +<https://www.rfc-editor.org/info/rfc8705> and Fett, D., Campbell, +B., Bradley, J., Lodderstedt, T., Jones, M., and D. Waite, "OAuth 2.0 +Demonstrating Proof of Possession (DPoP)", RFC 9449, DOI +10.17487/RFC9449, September 2023, +<https://www.rfc-editor.org/info/rfc9449>. + +[12] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and P. Hunt, +"OAuth 2.0 Dynamic Client Registration Protocol", RFC 7591, DOI +10.17487/RFC7591, July 2015, +<https://www.rfc-editor.org/info/rfc7591>. + +[13] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 Authorization +Server Metadata", RFC 8414, DOI 10.17487/RFC8414, June 2018, +<https://www.rfc-editor.org/info/rfc8414>. + +[14] Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0 Threat +Model and Security Considerations", RFC 6819, DOI 10.17487/RFC6819, +January 2013, <https://www.rfc-editor.org/info/rfc6819>. + +[15] Denniss, W. and J. Bradley, "OAuth 2.0 for Native Apps", BCP 212, +RFC 8252, DOI 10.17487/RFC8252, October 2017, +<https://www.rfc-editor.org/info/rfc8252>. + +[16] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, +C. “OpenID Connect Core 1.0 incorporating errata set 1,” OpenID +Foundation, November 2014, +. + +[17] Maler, E. (ed.), Machulak, M., Richer, J. “User-Managed Access +(UMA) 2.0 Grant for OAuth 2.0 Authorization,” Kantara Initiative, +January 2018, +. diff --git a/terminology.md b/terminology.md index f8d2061..6d6f8fe 100644 --- a/terminology.md +++ b/terminology.md @@ -9,9 +9,10 @@ the consolidated list here as a touchpoint for discussion. Article authors are encouraged to review and use existing definitions before offering new ones for terms already described in the BoK.* -*You are encouraged to also read the article, “Words of Identity” by -Espen Bago, for a cautious view of how, despite efforts like this -Terminology document, words in the IAM space are often ambiguous.* +*You are encouraged to also read the article, “*[Words of +Identity](https://bok.idpro.org/article/id/86/)*” by Espen Bago, for a +cautious view of how, despite efforts like this Terminology document, +words in the IAM space are often ambiguous.* *Please consider offering feedback to the articles that use these terms via the IDPro GitHub repository: .* @@ -89,167 +90,197 @@ via the IDPro GitHub repository: .* Introduction to Access Control +Access Token +The OAuth2 token that allows a client to get access to a protected resource +An Introduction to OAuth2.0 + + Account Owner An entity that “owns” or claims responsibility for an account. Generally, an account is issued in the name of the owner(s) or their delegate(s) in the case of enterprises. Account Recovery (v2) - + Account Recovery The process of returning account access to an account owner when they lose, forget, or cannot otherwise produce the account’s nominal credentials. This may be accomplished in person, remote, or in a hybrid format. Account Recovery (v2) - + Account Recovery The process of updating a user’s credentials within a scenario where the user cannot validate those credentials   Managing Identity in Customer Service Operations - + Account Takeover Account takeover is a form of identity theft and fraud, where a malicious third party successfully gains access to a user’s account credentials. Account Recovery (v2), Designing MFA for Humans, Techniques To Approach Least Privilege - + Accountability The obligation of a person to accept the results of one’s actions, be they positive or negative. This person is probably also a species of an owner. Introduction to Access Control - + Action a protected operation available for a resource, such as “view”, “edit”, or “submit”. Introduction to Policy-Based Access Controls (v2) - + Adaptive Authentication Adaptive authentication aims to determine and enforce the authentication level required at any time during a user session - when the session is commenced, during the session when access requirements force a re-evaluation, or when the session token expires. The factors to be used in achieving that authentication level are determined dynamically based on the access control policy governing the resources being accessed, and a variety of environmental conditions and risk factors in effect at that time for that user. Designing MFA for Humans - + Agent (also “Customer Service Agent”) The person responsible for communicating with and solving problems on behalf of customers or end-users.  Account Recovery (v2), Managing Identity in Customer Service Operations - + Agile Project Management A framework that uses a continuous, iterative process to deliver a defined piece of functionality, typically a component of a product or service. Scrum is a popular framework (https://www.scrumalliance.org/about-scrum/overview) Introduction to IAM Project Management - + Alignment the synchronization rate of processes and environments Strategic Alignment and Access Governance - + Applicant A subject undergoing the processes of enrollment and identity proofing. Defining the Problem – Identity Proofing Challenges - + Architecture Framework for the design, deployment, and operation of an information technology infrastructure. It provides a structure whereby an organization can standardize the technology it uses and align its IT infrastructure with digital transformation policy, IT development plans, and business goals. Introduction to IAM Architecture - + Architecture Overview Describes the architecture components required for supporting IAM across the enterprise. Introduction to IAM Architecture - + Architecture Patterns Identifies the essential patterns that categorize the IT infrastructure architecture in an organization and will guide the deployment choices for IAM solutions. Introduction to IAM Architecture - + Assertion A formal message or token that conveys information about a principal, typically including a level of assurance about an authentication event and sometimes additional attribute information. Sometimes this is called a Security Token. IAM Reference Architecture - + Assurance Level A category describing the strength of the identity proofing process and/or the authentication process. See NIST SP.800-63-3 for further information. IAM Reference Architecture - + Asymmetric Cryptography Any cryptographic algorithm which depends on pairs of keys for encryption and decryption. The entity that generates the keys shares one (see Public Key) and holds and protects the other (see Private Key). They are referred to as asymmetric because one key encrypts, and the other decrypts. Practical Implications of Public Key Infrastructure for Identity Professionals - + Attribute Provider Sometimes the authority for attributes is distinguished from the authority for identities. In this case, the term Attribute Provider is sometimes used. It is a subset or type of an Identity Information Authority. IAM Reference Architecture - + Attribute-Based Access Control (“ABAC”) / Claims-Based Access Control (“CBAC”) a pattern of access control system involving dynamic definitions of permissions based on information (“attributes”, or “claims”), such as job code, department, or group membership. -Introduction to Policy-Based Access Controls (v2) +Introduction to Policy-Based Access Controls (v2), The Business Case for IAM - + Attributes Key/value pairs relevant for the digital identity (username, first name, last name, etc.). An Overview of the Digital Identity Lifecycle (v2) - + Audit Repository A component that stores records about all sorts of events that may be useful later to determine if operations are according to policy, support forensic investigations, and allow for pattern analysis. Typically, this is highly controlled to prevent tampering. Audit Repository is the ISO name for this concept and is localized to the IDM. In this model, the term is generalized to indicate a service that supports event records from any part of the ecosystem. IAM Reference Architecture - + Authentication Authentication is the process of proving that the user with a digital identity who is requesting access is the rightful owner of that identity. Depending on the use-case, an ‘identity’ may represent a human or a non-human entity; may be either individual or organizational; and may be verified in the real world to a varying degree, including not at all.

Introduction to Access Control (v3),

-

Authentication and Authorization

+

Authentication and Authorization, Introduction to Consumer Identity and Access Management

- + Authentication (AuthN) The act of determining that to a level of assurance, the principal/subject is authentic. IAM Reference Architecture - + Authenticator The means used to confirm the identity of a user, processor, or device, such as a username and password, a one-time pin, or a smart card. -Identity and Access Management Workforce Planning +Identity and Access Management Workforce Planning, Introduction to Customer Identity and Access Management - + AuthN Assertion A security token whereby the IDP provides identity and authentication information securely to the RP. IAM Reference Architecture - + Authoritative Source The system of record (SOR) for identity data; an organization may have more than one authoritative source of data in their environment. -User Provisioning in the Enterprise +User Provisioning in the Enterprise, Introduction to Customer Identity and Access Management - + Authorization -Determining a user’s rights to access functionality with a computer application and the level at which that access should be granted. In most cases, an ‘authority’ defines and grants access, but in some cases, access is granted because of inherent rights (like patient access to their own medical data) -Introduction to Access Control, Authentication and Authorization +Determining a user’s rights to access functionality or resources within a computer application and the level at which that access should be granted. In most cases, an ‘authority’ defines and grants access, but in some cases, access is granted because of inherent rights (like patient access to their own medical data) +Introduction to Access Control, Authentication and Authorization, Introduction to Customer Identity and Access Management - + Authorization (AuthZ) Authorization is how a decision is made at run-time to allow access to a resource. We break this down into two types: shared and local. The FICAM framework includes this as a subcomponent of the Access Management System. AuthZ is not included in the ISO or Internet2 models. IAM Reference Architecture + +Authorization Server (AS) +The OAuth2 server is able to authorize a client, issue tokens, and potentially validate tokens +An Introduction to OAuth2.0 + Automatic Certificate Management Environment (ACME) A communication protocol for automating lifecycle management of PKI certificates. Significant providers like Let's Encrypt leverage ACME to support issuing TLS certificates for web servers. Practical Implications of Public Key Infrastructure for Identity Professionals +Bearer Token +A token whose possession is sufficient to enable access to a protected resource +An Introduction to OAuth2.0 + + Bilateral Federation A bilateral federation is one that consists of only two entities: one Identity Provider (IdP) and one Service Provider (SP). This is the most common model for an enterprise identity federation. Federation Simplified (v2) - + Binding Associating an authenticator with an identity.

Identity and Access Management Workforce Planning,

Defining the Problem – Identity Proofing Challenges

- + Bot Sometimes called an Internet bot, short for ‘robot’ but referring to a software routine that performs automated tasks over the Internet or a web robot referring to an autonomous network application, or simply a ‘bot’ referring to an automated, typically repetitive, task used for a specific purpose. Non-Human Account Management (v2) + +Business to Business (B2B) +Business to Business processes in the field of IAM involve business partner access to company resources using some form of remote access (e.g., federated access). +The Business Case for IAM + + +Business to Consumer (B2C) +Business to Consumer processes in the field of IAM are customer or consumer access to company resources. In B2C, consumers manage their own identity in a CIAM. The company still manages access to the resources, using ABAC or PBAC methods for access control +The Business Case for IAM + + +Business to Employee (B2E) +Business to Employee, also called workforce IAM, includes managing identities and accounts for employees and contractors following an identity lifecycle. +The Business Case for IAM + Ceremonies Predictable interactions that users can infrequently navigate in a well-watched place @@ -316,19 +347,29 @@ via the IDPro GitHub repository: .* Practical Implications of Public Key Infrastructure for Identity Professionals +Client +A client application consuming an API +An Introduction to OAuth2.0 + + Cloud Infrastructure Entitlement Management (CIEM) a categorization of technologies focused on managing the granting, verification, and refinement of permissions for cloud and hybrid technologies. CIEM is often seen as a component of Identity Governance and Administration (IGA) Techniques To Approach Least Privilege - + Competency Model A collection of tasks, knowledge, and skills (TKS) needed for effective job performance. A competency model is part of a workforce framework. Identity and Access Management Workforce Planning - + Consent Permission for something to happen or agreement to do something. -Introduction to Privacy and Compliance for Consumers +Introduction to Privacy and Compliance for Consumers, Introduction to Customer Identity and Access Management + + +Consumer (or Customer) Identity and Access Management (CIAM) +CIAM is the field of IAM that focuses on the Registration, Authentication, and Authorization services for an individual or entity receiving or purchasing services from an organization. +The Business Case for IAM, Introduction to Customer Identity and Access Management Consumer Protection Law @@ -381,10 +422,20 @@ via the IDPro GitHub repository: .* IAM Reference Architecture +Credential Stuffing +An attack in which an adversary tests lists of username and password pairs against a given CIAM system. +Introduction to Customer Identity and Access Management + + Credentials Any attribute or shared secret that can be used to authenticate a user. Account Recovery (v2) + +Credentials +In the context of CIAM, credentials are how individuals authenticate themselves to an organization’s CIAM system +Introduction to Customer Identity and Access Management + Cryptographic Module A hardware or software component that securely performs cryptographic operations within a logical boundary. Cryptographic Modules store private keys within this boundary and use them for cryptographic functions at the request of an authorized user or process. @@ -584,7 +635,7 @@ via the IDPro GitHub repository: .* Identification Uniquely establish a user of a system or application. -Introduction to Access Control +Introduction to Access Control, Introduction to Customer Identity and Access Management Identifier @@ -592,206 +643,216 @@ via the IDPro GitHub repository: .* Practical Implications of Public Key Infrastructure for Identity Professionals +Identifier +An identifier is a means by which a system refers to a record (at the most abstract levels.) In this case, it could mean the string that a person provides that “names” their use account. +Introduction to Customer Identity and Access Management + + Identity Defining attributes for a human user that may vary across domains, e.g., a user’s digital identity will have a different definition in a work environment as opposed to the user’s bank. A device identifier is sometimes referred to as its identity. Non-Human Account Management (v2) - + Identity An attribute or set of attributes that uniquely describes a subject within a given context. Defining the Problem – Identity Proofing Challenges - + Identity Analytics and Intelligence (IdA) Identity analytics and intelligence mean looking at entitlement data, looking at the assignment of that, and trying to figure out and define what risk looks like. IdA provides a risk-based approach for managing system identities and access, with the intention of centralizing governance, visibility, and reporting for access-based risk. Introduction to Identity - Part 1: Admin-time (v2) - + Identity and Access Management (IAM) Identity and Access Management (IAM) is the discipline used to ensure the correct access is defined for the correct users to the correct resources for the correct reasons. Authentication and Authorization - + Identity and Access Management (IAM) The discipline that enables the right individuals to access the right resources at the right times for the right reasons. Identity and Access Management Workforce Planning - + Identity and Access Management Workforce Planning Activities involved in ensuring an enterprise identity and access management team are staffed with the right talent to execute business and technical objectives. Identity and Access Management Workforce Planning - + Identity, Credential, and Access Management (ICAM) Programs, processes, technologies, and personnel used to create trusted digital identity representations of individuals and non-person entities, bind those identities to credentials that may serve as a proxy in access transactions, and leverage the credentials to provide authorized access to an organization’s resources. Identity and Access Management Workforce Planning - + Identity Evidence Information or documentation the applicant provides to support the claimed identity. Identity evidence may be physical (e.g., a driver’s license) or digital (e.g., an assertion generated and issued by a CSP based on the applicant successfully authenticating to the CSP). Defining the Problem – Identity Proofing Challenges - + Identity Federation

An identity federation is a group of computing or network providers that agree to operate using standard protocols and trust agreements. In a Single Sign-On (SSO) scenario, identity federation occurs when an Identity Provider (IdP) and Service Provider (SP) agree to communicate via a specific, standard protocol. The enterprise user will log into the application using their credentials from the enterprise rather than creating new, specific credentials within the application. By using one set of credentials, users need to manage only one credential, credential issues (such as password resets) can be managed in one location, and applications can rely on the appropriate enterprise systems (such as the HR system) to be the source of truth for a user’s status and affiliation.

Identity federations can take several forms. In academia, multilateral federations, where a trusted third party manages the metadata of multiple IdPs and SPs, are fairly common. 1 This article focuses, however, on the enterprise use case where bilateral federation arrangements, where the agreements are one-to-one between an IdP and an SP, are the most common form of identity federation in use today.

Federation Simplified (v2) - + Identity Governance and Administration (IGA) a discipline that focuses on identity life cycle management and access control from an administrative perspective. -Introduction to Identity - Part 1: Admin-time (v2) +Introduction to Identity - Part 1: Admin-time (v2), The Business Case for IAM - + Identity Governance and Administration (IGA) Includes the collection and use of identity information as well as the governance processes that ensure the right person has the right access to the right systems at the right time. Introduction to IAM Architecture - + Identity Governance and Administration (IGA) a solution for automating user management and authorizations in target systems, building on the organization’s customer and human resource processes. Strategic Alignment and Access Governance - + Identity Hub or Repository The place where users can store their encrypted identity-related information. An identity hub can be anywhere – on the edge, on the cloud, or on your own server. Its purpose is to store personal data. Some implementations may allow other entities to access the identity hub of the user if the user specifically grants such access. You can think of an identity hub as the individual’s personal data store. A Peek into the Future of Decentralized Identity - + Identity Information Authority (IIA) This represents one or more data sources used by the IDM as the basis for the master set of principal/subject identity records. Each IIA may supply a subset of records and a subset of attributes. Sometimes the IIA is distinguished from the Identity Information Provider or IIP. We use IIA to include the service that actually provides the information as well as the root authority. This corresponds to Identity Information Source in ISO/IEC 24760-2 and Identity Sources in Internet2. IAM Reference Architecture - + Identity Lifecycle Management A process that detects changes in authoritative systems of record and updates identity records based on policies. User Provisioning in the Enterprise - + Identity Management (IDM) A set of policies, procedures, technology, and other resources for maintaining identity information. The IDM contains information about principals/subjects, including credentials. It also includes other data such as metadata to enable interoperability with other components. The IDM is shown with a dotted line to indicate that it is a conceptual grouping of components, not a full-fledged system in itself. IAM Reference Architecture - + Identity Proofing accruing evidence to support “who this is.” Identity proofing is the last, but not the least, important part of this admin-time section. This is the process of collecting and verifying information about a person for the purpose of providing an account or a corresponding credential. This is typically performed before an account is created or the credential is issued, or a special privilege is granted. Introduction to Identity - Part 1: Admin-time (v2) - + Identity Proofing The process by which a CSP collects, validates, and verifies information about a person. Defining the Problem – Identity Proofing Challenges - + Identity Provider (IdP) An Identity Provider (IdP) performs a service that sends information about a user to an application. This information is typically held in a user store, so an identity provider will often take that information and transform it to be able to be passed to the service providers, AKA apps. The OASIS organization, which is responsible for the SAML specifications, defines an IdP as “A kind of SP that creates, maintains, and manages identity information for principals and provides principal authentication to other SPs within a federation, such as with web browser profiles.” Federation Simplified (v2), Authentication and Authorization - + Identity Provider (IDP) Identity Provider or IDP is a common term. We treat this as a subset of Identity Management. It consists of the service interfaces: AuthN/Assertion, Service Provisioning Agent, Session Management, Discovery Services, and Metadata Management. IAM Reference Architecture - + Identity Provider (IdP) The party that manages the subscriber’s primary authentication credentials and issues assertions derived from those credentials. This is commonly the CSP as discussed within this article. Defining the Problem – Identity Proofing Challenges - + Identity Register This is the datastore that contains the enrolled entities and their attributes, including credentials. See the IDM section for elaboration. The terms Directory, Identity Repository, and Attribute Store are sometimes used as synonyms. IAM Reference Architecture - + Identity Repository The identity repository is a directory or a database that can be referenced by external systems and services (such as authentication or authorization services). User Provisioning in the Enterprise - + Identity Theft Law Laws governing crimes in which the perpetrator gains access to sensitive personal information belonging to the victim (such as birth dates, passwords, email addresses, driver's license numbers, social security numbers, financial records, etc.), and then uses this information to impersonate the victim for personal gain, such as to commit fraud, establish credit in the victim’s name, or access the victim’s accounts. Laws Governing Identity Systems - + Impersonation A scenario where a user is able to perform actions as though they are a known user other than themself. Managing Identity in Customer Service Operations - + Infrastructure-as-code the process of managing and provisioning computer data centers through machine-readable definition files rather than physical hardware configuration or interactive configuration tools. Techniques To Approach Least Privilege - + Internet Key Exchange (IKE) A subordinate standard under IPsec specifying how to use X.509 certificates to establish symmetric keys for an IPsec tunnel.certificates to establish symmetric keys for an IPsec tunnel. Practical Implications of Public Key Infrastructure for Identity Professionals - + Internet Protocol Security (IPsec) A standard for communication between two machines providing confidentiality and integrity over the Internet Protocol. Practical Implications of Public Key Infrastructure for Identity Professionals - + Intra-organizational (Single Sign-On): A central digital identity, such as an account in a directory, is linked by downstream systems as authoritative for authentication. An Overview of the Digital Identity Lifecycle (v2) - + Inter-organizational (Federation) An organization relies on another organization’s digital identity and lifecycle management processes. An Overview of the Digital Identity Lifecycle (v2) - + Internal identifier The way an identity management system refers to a digital identity Identifiers and Usernames - + Issuer The entity that issues verifiable credentials about subjects to holders. Issuers are typically a government entity or corporation, but an issuer can also be a person or device. A Peek into the Future of Decentralized Identity - + Joiner/Mover/Leaver The joiner/mover/leaver lifecycle of an employee identity considers three stages in the life cycle: joining the organization, moving within the organization, and leaving the organization. -Introduction to Identity - Part 1: Admin-time (v2) +Introduction to Identity - Part 1: Admin-time (v2), The Business Case for IAM - + Journey-based Creation The process that guides a customer through a series of interactions prior to establishing a digital identity. For example, capturing the minimum basic information needed from a customer to enable creation of an identity. An Overview of the Digital Identity Lifecycle (v2) - + Just-in-time (JIT) Access a technique where a credential or a permission is granted to a principal for a temporary timeframe when they need the permission to perform an activity. Access is revoked once the activity is complete, limiting its usage. Techniques To Approach Least Privilege - + Key In a cryptosystem, a Key is a piece of information used to encrypt or decrypt data in a cryptographic algorithm. Practical Implications of Public Key Infrastructure for Identity Professionals - + Knowledge-Based Authentication (KBA) A method of authentication that uses information known by both the end-user and the authentication service but is not necessarily a secret. Account Recovery (v2), Managing Identity in Customer Service Operations - + Knowledge-Based Authentication (KBA) Identity-verification method based on knowledge of private information associated with the claimed identity. This is often referred to as knowledge-based verification (KBV) or knowledge-based proofing (KBP). Defining the Problem – Identity Proofing Challenges - + Least Privilege Also known as the Principle of Least Privilege; a resource, such as a user, must only be able to access the resources (e.g., applications, data) that are necessary for it to function. Introduction to Identity – Part 2: Access Management - + Least Privilege The principle that a security architecture should be designed so that each entity is granted the minimum system resources and authorizations that the entity needs to perform its function. (NIST Information Technology Laboratory) Techniques To Approach Least Privilege + +Lifecycle +In the context of CIAM, lifecycle refers to the stages that an individual or entity might experience over the course of their relationship with an organization, beginning with the formation of a relationship (such as being hired into an organization or signing up for service) and ending with the severance of that relationship (such as termination or closing an account) +Introduction to Customer Identity and Access Management + Local Authorization Local authorization is handled by the RP. @@ -840,7 +901,7 @@ via the IDPro GitHub repository: .* Online Certificate Status Protocol (OCSP) A protocol that allows a client to query the Certificate Authority or a Validation Authority for the status of an individual certificate rather than downloading a CRL. - +Practical Implications of Public Key Infrastructure for Identity Professionals OpenID Connect (OIDC) @@ -848,115 +909,145 @@ via the IDPro GitHub repository: .* Federation Simplified (v2) +Passwordless +Any means of authenticating a user account that does not require a static stored shared secret. Techniques include one-time passwords and passkeys. +Introduction to Customer Identity and Access Management + + Path Discovery and Validation (PDVal) The process to determine whether a certificate is valid and trusted by the validator. Practical Implications of Public Key Infrastructure for Identity Professionals - + Permission a statement of authorization for one or more subjects to perform one or more actions on one or more objects. Introduction to Policy-Based Access Controls (v2) - + Personal Data Defined in Article 4(1) of the GDPR: “‘personal data’ means any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person;”. Note: “natural person” (human) is used to distinguish from companies and other corporate entities that are “legal persons”. An Introduction to the GDPR - + Personal Data Personal data are any information which are related to an identified or identifiable natural person. Account Recovery (v2), Impact of GDPR on Identity and Access Management - + Personal Identification Number (PIN) A numeric secret commonly used to unlock a private key container in software or hardware. Practical Implications of Public Key Infrastructure for Identity Professionals - + Personal Identity Verification (PIV) A US Government program designed to enable strong authentication for all government employees and contractors, based on Public Key Infrastructure. Practical Implications of Public Key Infrastructure for Identity Professionals - + Policy Administration Point (PAP) The location where the different types of owners define the access policy. Introduction to Access Control - + Policy Decision Point (PDP) The policy engine validating Access requests and provided attributed against the Access Policy (as defined in the Policy Administration Point). Introduction to Access Control - + Policy Enforcement Point (PEP) The authority that will only let an Access Requester connect to the Access Supplier if the Policy Decision Point allows it. Introduction to Access Control - + Policy Engine It is a security component that validates whether an actor is allowed to access a protected resource, following the requirements in an access policy. Introduction to Access Control - + Policy Information Point The authority that refers to the (external) trusted providers of attributes that will be used in the Access Decision. An example is the myacclaim.com service that administers Open Badges of certifications, such as CISSP and MSCP. Introduction to Access Control + +Policy Store +A repository that houses configuration information for the CIAM system and serves as an Authoritative Source for that information. For example, OAuth token Lifecycle policies or Authorization policies. +Introduction to Customer Identity and Access Management + Policy-Based Access Control (PBAC) a pattern of access control system involving dynamic definitions of access permissions based on user attributes (as in ABAC) and context variables for permitting or denying access. -Introduction to Policy-Based Access Controls (v2) +Introduction to Policy-Based Access Controls (v2), The Business Case for IAM +Preferences +Choices that individuals or entities make in administering the relationship they have with an organization. These choices may include topics of interest or approved communication methods. Often, Preferences are stored with Profile information. +Introduction to Customer Identity and Access Management + + Principle of Least Privilege an information security best practice ensuring that users in an access control system do not have more access to resources than is necessary for their intended activities. Introduction to Policy-Based Access Controls (v2) - + Privacy An abstract concept, with no single, common definition Introduction to Privacy and Compliance for Consumers - + Privacy Law Laws that regulate the collection, use, storage, and transfer of personal data relating to identified or identifiable individuals. Laws Governing Identity Systems - + Private Key A key that a single entity exclusively and privately controls. It corresponds to a public key that the entity may share for data encryption or signature verification. Practical Implications of Public Key Infrastructure for Identity Professionals - + Privileged Access Management A mechanism for managing temporary access for accounts with high-risk permissions. PAM often involves check-out and check-in of a credential generated for a single use. -Techniques To Approach Least Privilege +Techniques To Approach Least Privilege, The Business Case for IAM - + Privileged Account Management (PAM) focusing on special control for risky high-level access. Privileged Account Management (PAM) is a mechanism for getting those special accounts under control. Introduction to Identity - Part 1: Admin-time (v2) - + Processing Defined in Article 4(2) of the GDPR: “‘processing’ means any operation or set of operations which is performed on personal data or on sets of personal data, whether or not by automated means, such as collection, recording, organisation, structuring, storage, adaptation or alteration, retrieval, consultation, use, disclosure by transmission, dissemination or otherwise making available, alignment or combination, restriction, erasure or destruction”. Note that even this long list of activities is not exhaustive: other activities may also fall within the definition of “processing”. Additional rules, in Article 22, apply to “automated individual decision-making, including profiling”. These generally have the effect of strengthening the rights of information and objection described later and may limit the use of automation for some high-impact decisions. An Introduction to the GDPR + +Profile +A collection of attributes about an individual. The individual may provide it directly, or the organization may gather it indirectly. +Introduction to Customer Identity and Access Management + +Progressive Profiling +A technique to reduce customer friction by gathering Profile, preference, and Consent information over time (when needed) rather than all at once. +Introduction to Customer Identity and Access Management + + Project A time-limited activity to achieve a defined outcome(s) Introduction to Project Management for IAM Projects - + Project Charter Documented authority for the project manager to proceed with a project; it will usually include a succinct statement of the project’s purpose Introduction to Project Management for IAM Projects - + Project Plan A document that describes a project; it will usually include a scope statement, schedule, resource plan, communications plan, and quality plan Introduction to Project Management for IAM Projects + +Protected Resource +An API in the OAuth2 terminology +An Introduction to OAuth2.0 + Public Key A key that an entity publicly distributes. It corresponds to a private key that the entity exclusively and privately controls. @@ -983,10 +1074,20 @@ via the IDPro GitHub repository: .* User Provisioning in the Enterprise +Refresh Token +The OAuth2 token that allows a client to renew an access token when it is expired without the user’s presence +An Introduction to OAuth2.0 + + Registration See Enrollment Defining the Problem – Identity Proofing Challenges + +Registration +The creation of a relationship between an individual and an online system that is initiated by the individual and results in the creation of a user account or Profile. +Introduction to Customer Identity and Access Management + Registration Authority (RA) An individual, system, or business function which provides registration and identity proofing for entities receiving certificates and manages the certificate issuance and renewal process. The most important responsibilities of an RA include identity proofing and binding the private key to the identity. @@ -1008,55 +1109,65 @@ via the IDPro GitHub repository: .* Introduction to Identity - Part 1: Admin-time (v2) +Return on Investment (ROI) +Return on Investment is the economic measure of value of an investment, using costs, revenues, interest rates, and lifecycle as parameters. +The Business Case for IAM + + Revoke Revocation is the announcement that clients should no longer trust an individual certificate.  Practical Implications of Public Key Infrastructure for Identity Professionals - + Revised Payment Systems Directive (PSD2) PSD2 (the Revised Payment Services Directive, Directive (EU) 2015/2366) is an EU Directive, administered by the European Commission (Directorate General Internal Market) to regulate payment services and payment service providers throughout the European Union (EU) and European Economic Area (EEA). It contains many requirements specifically related to Strong Client Authentication. Designing MFA for Humans - + Risk Context (RCTX) Risk Context consists of additional facts that can be brought to bear to improve the overall security of the ecosystem. Internal or external events and facts can be applied to enable, limit, or terminate access. This is similar to the section Monitors and Sensors under FICAM’s Governance Systems and to many of the inputs of the Policy Decision Point in the NIST Special Publication 800-207, a paper on Zero Trust. IAM Reference Architecture - + Role Management a way to group access rules to make them more manageable Introduction to Identity - Part 1: Admin-time (v2) - + Role-Based Access Control (RBAC) the use of roles at run-time; a way to govern who gets access to what through the use of roles. Introduction to Identity - Part 1: Admin-time (v2) - + Role-Based Access Control (RBAC) A pattern of access control system involving sets of static, manual definitions of permissions assigned to “roles”, which can be consistently and repeatably associated with users with common access needs. Role-based access control is a control scheme in which roles are granted to identities, and those roles determine what access to resources those identities should have. Basic roles might be “admin” and “read-only user” – an admin would be able to make changes to a system and a read-only user would only be able to view resources. Introduction to Policy-Based Access Controls (v2), Authentication and Authorization - + Roles A set of permissions. A role must be associated with an individual user, and the user gains the associated authorization when they are associated with the role. Practical Implications of Public Key Infrastructure for Identity Professionals - + RSA An asymmetric cryptosystem based on large prime numbers. The acronym RSA stands for the three principal inventors, Ron Rivest, Adi Shamir, and Len Adleman. Practical Implications of Public Key Infrastructure for Identity Professionals - + S/MIME A standard for constructing and sending digitally signed or encrypted messages using asymmetric cryptography Practical Implications of Public Key Infrastructure for Identity Professionals - + Schedule A document that defines the activity and resources required to achieve the planned deliverable(s) and outcome(s) Introduction to Project Management for IAM Projects + +Scope +A string designating a (part) of a protected resource that a client is authorized to access. +An Introduction to OAuth2.0 + Secure Socket Layer (SSL) A deprecated standard for encrypting data in transit; TLS has superseded it. @@ -1078,85 +1189,95 @@ via the IDPro GitHub repository: .* A Peek into the Future of Decentralized Identity +Sender Constrained Token +A token whose possession is not sufficient to enable access to a protected resource (additional proof of identity by the client application is required) +An Introduction to OAuth2.0 + + Server Account An account with privileged access rights to a server’s operation typically used for configuration purposes. Non-Human Account Management (v2) - + Server-based Certificate Validation Protocol (SCVP) A protocol that allows a client to query a server to determine whether a certificate is valid and trusted. The server does not need to be associated with the issuing CA. SCVP does two things; (1) it determines the path between the end entity and the trusted root, whereby the client doesn't need to trust any intermediate CAs. (2) it also performs delegated path validation according to policy. Practical Implications of Public Key Infrastructure for Identity Professionals - + Service Account An account used by a computer application to access other applications or services for a specific purpose. Non-Human Account Management (v2) - + Service Provider (SP) Defined by the OASIS organization, which is responsible for the SAML specification, as “A role donned by a system entity where the system entity provides services to principals or other system entities.” This usually takes the form of an application that offers services requiring authentication and authorization to a user. Federation Simplified (v2) - + Session A period of time after an authentication event when an RP grants access to resources for the principal/subject. The duration of the session and the mechanism for enforcement vary by implementation. IAM Reference Architecture - + Session Management A coordinating function provided by an IDP to control sessions of subscribing RPs. IAM Reference Architecture - + Shared Authorization Shared authorization is provided by a facility outside of the RP. It is shown here as part of the access management grouping. IAM Reference Architecture - + Signature Processing data using a cryptographic algorithm to provide integrity assurance. Practical Implications of Public Key Infrastructure for Identity Professionals - + Single Sign-On Single Sign-On is a service that enables SPs to verify the identities of End Users by facilitating communication with IdPs. SSO acts as a bridge to decouple SPs and IdPs. This can happen via numerous protocols such as agent-based integrations, direct LDAP integration, SAML, and OpenID Connect, to name a few. Federation Simplified (v2) - + Social Engineering Social engineering is a method of manipulating people so they give up confidential information, such as passwords or bank information, or grant access to their computer to secretly install malicious software. Account Recovery (v2), Designing MFA for Humans - + Sources of “Truth” where authoritative data about individuals live. Introduction to Identity - Part 1: Admin-time (v2) - + Special Category Data (SCD) Categories of data that are regarded as particularly sensitive, so subject to additional regulation. Defined in Article 9(1) of the GDPR as “personal data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, or trade union membership, and the processing of genetic data, biometric data for the purpose of uniquely identifying a natural person, data concerning health or data concerning a natural person’s sex life or sexual orientation”; Article 10’s “personal data relating to criminal convictions and offences” requires similar treatment, so is normally considered as another category of SCD. An Introduction to the GDPR - + Step-Up Authentication A method to increase the level of assurance (or confidence) the system has regarding a user’s authentication by issuing one or more additional authentication challenges, usually using factors different from the one(s) used to establish the initial authenticated session. The need for increasing the level of assurance is typically driven by the risk associated with the sensitive resource the user is attempting to access. Designing MFA for Humans - + Subject Alternative Name One or more identifiers for a certificate subject that certificate issuers can use to carry application-specific identifiers such as email address or User Principal Name (UPN). Practical Implications of Public Key Infrastructure for Identity Professionals - + Subject Distinguished Name (Subject DN) A unique identifier for the subject within the scope of the Certificate Authority. Issuers structure the subject DN like an LDAP entry name. Practical Implications of Public Key Infrastructure for Identity Professionals - + Subscriber A party enrolled in the CSP identity service. Defining the Problem – Identity Proofing Challenges + +Sunk cost +Expenses that have already been made in the past and that are unrecoverable. +The Business Case for IAM + System Account A generic term for a privileged account that has extensive permissions that enable system configuration changes. @@ -1263,21 +1384,26 @@ via the IDPro GitHub repository: .* Identity and Access Management Workforce Planning +Workforce IAM +The application of IAM sub-disciplines such as access governance, authentication, and Authorization for employees as opposed to the applications of such disciplines for customers. +Introduction to Customer Identity and Access Management + + Workforce Planning Activities that ensure an organization has the right talent to execute business and technical objectives. Identity and Access Management Workforce Planning - + X.509 An ISO standard from the X.500 series that defines the basic rules for encoding public key certificates. Practical Implications of Public Key Infrastructure for Identity Professionals - + Zero Standing Privilege (ZSP) a state where JIT access is used for all permissions and no long-standing permissions are assigned to principals. Techniques To Approach Least Privilege - + Zero Trust From NIST Draft Special Publication 800-207, “Zero trust assumes there is no implicit trust granted to assets or user accounts based solely on their physical or network location (i.e., local area networks versus the internet)” Introduction to Identity – Part 2: Access Management