├── .github └── CONTRIBUTING.md ├── README.md ├── CHARTER.md ├── ipsie-levels.md ├── ipsie-terminology.md └── ipsie-v1-draft.md /.github/CONTRIBUTING.md: -------------------------------------------------------------------------------- 1 | # How to Contribute 2 | 3 | The OpenID IPSIE working group page is https://openid.net/wg/ipsie/. It describes how to participate in the working groups including IPSIE. 4 | 5 | You can send feedback on the specifications in a way that enables the working group to act upon it by 6 | 7 | 1. signing the contribution agreement at https://openid.net/intellectual-property/ to join the working group (please specify that you are joining the IPSIE working group on your contribution agreement), 8 | 2. joining the working group mailing list at https://lists.openid.net/mailman/listinfo/openid-specs-ipsie/, and 9 | 3. sending your feedback to the list. 10 | 11 | Working group members can also contribute via GitHub. 12 | 13 | When contributing, please adhere to the following guidelines: 14 | 15 | - **Issues**: Use the issue tracker to report problems or suggest enhancements. 16 | - **Pull Requests**: Submit pull requests linked to Issues that were approved during a Working Group call. 17 | - **Commit Messages**: Use clear and descriptive commit messages. 18 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # IPSIE 2 | OpenID IPSIE Working Group Repository 3 | 4 | The [Interoperability Profiling for Secure Identity in the Enterprise (IPSIE) Work Group](https://openid.net/wg/ipsie/) develops interoperability and security profiles of existing specifications that enable secure identity management within the enterprise. 5 | 6 | The current state of identity within an enterprise extends well beyond single-sign-on. Many aspects of enterprise identity are covered by specifications inside and outside of the OIDF community: OpenID Connect, Shared Signals, OAuth 2.0, SCIM, and more. 7 | 8 | These specifications enable a wide range of capabilities – many of which go beyond the minimum requirements for enterprise and include features that are irrelevant in that context. Importantly, they are often frameworks that contain significant levels of optionality, reducing the likelihood that independent implementations will interoperate. 9 | 10 | This Work Group will develop profiles of existing specifications with a primary goal of achieving interoperability between independent implementations. It will do this while prioritizing secure defaults. 11 | 12 | The initial problem space focuses on: 13 | * Single Sign-On 14 | * User Lifecycle Management 15 | * Entitlements 16 | * Risk Signal Sharing 17 | * Logout 18 | * Token Revocation 19 | 20 | It may also address problems, like: 21 | 22 | Discoverability of specific features within the above capabilities 23 | * New user onboarding and account recovery 24 | * Discovering the application used within an enterprise 25 | * Monitoring and provisioning application usage 26 | * Managing restrictions on application usage 27 | -------------------------------------------------------------------------------- /CHARTER.md: -------------------------------------------------------------------------------- 1 | ## Working Group name 2 | Interoperability Profiling for Secure Identity in the Enterprise (IPSIE) Work Group. 3 | 4 | ## Purpose 5 | The purpose of this working group is to develop interoperability and security profiles of existing specifications that enable secure identity management within the enterprise. 6 | 7 | The current state of identity within an enterprise extends well beyond single-sign-on. Many aspects of enterprise identity are covered by specifications both within and outside the OpenID Foundation, such as OpenID Connect, Shared Signals Framework, OAuth, and SCIM. These specifications often enable a wide range of capabilities – in many cases these capabilities that go beyond the minimum requirements for enterprise identity management, and sometimes also include features that are not relevant in an enterprise context. Additionally, many of these specifications are frameworks and contain optionality to the point of two independent implementations not being guaranteed to be interoperable without further coordination. 8 | 9 | This working group will develop profiles of existing specifications with the primary goal of achieving independent implementations being interoperable, while also prioritizing secure defaults within the specifications. 10 | 11 | The initial problem space of the working group is focused around: 12 | 13 | * Single Sign-On 14 | * User Lifecycle Management 15 | * Entitlements 16 | * Risk Signal Sharing 17 | * Logout 18 | * Token Revocation 19 | 20 | The working group may also address problems such as: 21 | 22 | * Discoverability of specific features within the above-mentioned capabilities 23 | * New user onboarding and account recovery 24 | * Discovering the applications used within an enterprise 25 | * Monitoring and provisioning application usage 26 | * Managing restrictions on application usage 27 | 28 | ## Scope & Objectives 29 | The scope of the working group includes: 30 | 31 | * Develop profiles of existing specifications with the goal of interoperability within the enterprise ecosystem. 32 | * Define an interoperability profile of OpenID Connect that meets the needs and security requirements of the enterprise. 33 | * Define an interoperability profile of Shared Signals Framework that enables sharing signals about threat detection and device posture. 34 | * Define an interoperability profile of SCIM that enables user account lifecycle and entitlements management. 35 | * Define an interoperability profile of logout specifications to enable an identity provider to revoke sessions and tokens of downstream applications. 36 | 37 | Out of scope: 38 | 39 | Developing new general-purpose specifications, technologies, or features is out of scope of this working group. Profiles are created by including or excluding parts of existing specifications. 40 | 41 | If a pertinent problem space without an existing specification is identified, an effort will first be made to find an existing working group or standards body where development of the specification may be more appropriate. If none is found, consideration will be given to creating a new specification within this working group. 42 | 43 | The working group will actively coordinate with the following working groups doing related work: 44 | 45 | * OpenID Connect 46 | * FAPI 47 | * iGov 48 | * Shared Signals 49 | * OAuth 50 | * SCIM 51 | 52 | ## Proposed specifications 53 | The initial proposed deliverable by the group is: Interoperability Profile for Secure Identity in the Enterprise (IPSIE) This specification will be divided into sections for each use case, with subsections for each specification that this profiles. The group may provide additional interoperability profile specifications that address the concerns of specific use cases or certain specifications that require interoperability profiles. 54 | 55 | ## Anticipated audience or users 56 | Identity Providers that serve an enterprise customer market SaaS apps that sell to enterprise customers, also known as Independent Software Vendors (ISVs) Developers of tools, libraries, and other resources in support of either of the previous two audiences 57 | 58 | ## Language 59 | English. 60 | 61 | ## Method of work 62 | Mailing list and telephone/internet conference calls combined with face-to-face (where needed) and information sharing/collaborative working via online tools. 63 | 64 | ## Basis for determining when the work is completed 65 | Approved “final” specifications consistent with the purpose and scope that have been through the OpenID Foundation process including vote by the membership and running code in one or more proof-of-concept, interoperability event, or commercial projects. 66 | -------------------------------------------------------------------------------- /ipsie-levels.md: -------------------------------------------------------------------------------- 1 | # IPSIE Levels 2 | 3 | - *SL* - Session Lifecycle 4 | - *IL* - Identity Lifecycle 5 | 6 | Each level includes the previous level (_e.g._ SL3 includes the requirements of SL1 and SL2). Each set of levels is _independent_ from other levels (e.g. an application may achieve IL3 while all other sets are at Level 1). 7 | 8 | | IPSIE
LEVEL| Applications
(aka RP) | Identity Services | 9 | |---------------|----------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------| 10 | | SL1 | - MUST meet NIST800-63rev3 FAL2 compliance
- Session lifetime MUST match assertion lifetime | - MUST meet NIST800-63rev3 FAL2 Compliance
- MUST enforce MFA and communicate an authentication class to the application | 11 | | SL2 | - MUST terminate sessions at the request of the Identity Service| - MUST enforce authentication method requests from Applications | 12 | | SL3 | - MUST communicate session state changes to Identity Services | - MUST communicate user, session, and device state changes to the Application | 13 | |||| 14 | | IL1 | - MUST support JIT provisioning of users via SSO
- MUST accept user attributes during provisioning
- Out of band provisioning/self provisioning users to the organization SHALL NOT be allowed | | 15 | | IL2 | - MUST support pre-provisioning of users by the Identity Services prior to signin
- MUST support deprovisioning of users by Identity Services
- MUST support mapping group claims to application roles | - MUST send selected group claims to Applications | 16 | | IL3 | - MUST expose application roles to the Identity Service | - MUST consume application roles and map to users
- MUST include roles as user attributes in JIT and async provisioning | 17 | 18 | ----- 19 | ### IPSIE Session Lifecycle SL1 - Single Sign-On & Session Lifetime Controls 20 | 21 | Level SL1 enables basic single sign-on from applications to the identity provider, communicating identity statements about the user. Single sign-on in Level SL1 meets the requirements of [FAL2](https://pages.nist.gov/800-63-4/sp800-63c/fal/). 22 | 23 | The Application respects the session lifetime as communicated by the Identity Service in the assertion, and reauthenticates the user through the Identity Service after the expiration. 24 | 25 | ### IPSIE Session Lifecycle SL2 - MFA, Logout, & Session Termination 26 | Level SL2 adds the ability to communicate information about the user's authentication method between Identity Service and Application. The Identity Service includes claims about the authentication level in the assertion to the Application. The Application can request a specific authentication level of the Identity Service. 27 | 28 | The Identity Services must be able to communicate a session termination event. The Application must act upon session termination requests from the Identity Services. 29 | 30 | ### IPSIE Session Lifecycle SL3 - Continuous Access 31 | 32 | Level SL3 adds continuous access to the authentication between Identity Service and application. 33 | 34 | The app communicates session changes to the Identity Service such as IP address change, enabling the Identity Service to be aware of more context around what is happening to users' sessions after the initial sign-in. 35 | 36 | The Identity Service communicates changes in the account and device posture to the application, enabling the application to take actions it determines are necessary based on its own policies about these changes. Neither application nor identity services are obliged to act upon any state changes, the policies for responding to state changes are not in scope for SL3. 37 | 38 | ### IPSIE Identity Lifecycle Level IL1 - JIT User Provisioning Control 39 | 40 | IPSIE Provisioning Level IL1 requires the Identity Service to provision users in the application when they log in via SSO. Users must not exist in the application prior to the user logging in for the first time, eliminating alternative pathways for user provisioning (e.g. self-provisioning). 41 | 42 | ### IPSIE Identity Lifecycle Level IL2 - User Pre-Provisioning and Deprovisioning Control 43 | 44 | Level IL2 adds the ability to provision and deprovision users in the application before they have logged in. Prior to level IL2, users were only JIT-provisioned in the application as part of SSO. An application at IL2 MUST support pre-provisioning and deprovisioning of users. Identity Services and Apps at IL2 MAY support JIT provisioning for downward compatability with an Identity Service / Application operating at Level IL1. 45 | 46 | Level IL2 also adds group provisioning and deprovisioning into applications. Applications MUST support group and group membership provisioning from the Identity Service, and use the groups to map to application roles. 47 | 48 | ### IPSIE Identity Lifecycle Level IL3 - Group and Group Membership Pre-Provisioning and Deprovisioning Control 49 | 50 | Level IL3 enables the enterprise to manage application roles at the Identity Service. Applications MUST support exposing application roles to the Identity Service, so that the enterprise can assign application roles to users at the Identity Service. The Identity Service MUST include the application roles assigned to users in the user attributes during JIT and async provisioning. 51 | 52 | 53 | 54 | 55 | -------------------------------------------------------------------------------- /ipsie-terminology.md: -------------------------------------------------------------------------------- 1 | # IPSIE Terminology 2 | 3 | ## Roles 4 | 5 | ### Enterprise 6 | 7 | Enterprises are generally defined as entities - e.g. corportations, non-profit organizations, partnerships. Enterprises have a workforce comprised of employees, contractors, volunteers, and others who operate on behalf of the enterprise. Enterprises deploy applications and services to support their organizational needs. Government, non-governmental organizations, educational entities, small businesses, and others may consider themselves enterprises. 8 | 9 | Ultimately, the goal of the IPSIE standard is to better serve the enterprise organization. Enterprises prefer to centralize the authentication process of all the applications used across the enterprise. Among other benefits, this allows users to have only one set of credentials to manage, and enables the company to manage which users can access which applications in a central location. In this framing, enterprises have identity services, applications, data, and the policies that are used to grant, suspend, and revoke user access. 10 | 11 | The enterprise company is also referred to as the "customer", since they may be a customer of the Identity Service provider(s) and multiple Applications. 12 | 13 | ### Identity Service 14 | 15 | The enterprise's "Identity Service" the logical set of services used by the enterprise to manage users within their organization. The Identity Service is often purchased by the enterprise company as a service or set of services, but can also be open source software or developed in-house. The identity service may be a single component, or multiple components with discrete functionality. 16 | 17 | The identity service is where the users' access to applications and other resources is managed and enforced. 18 | 19 | ### Application 20 | 21 | The "Application" is ultimately used by people within the enterprise company during their day to day work. Applications have their own resources, and users may be limited in which applications they can access or what they can do within an application. Applications use the Identity Service to authenticate users through a "single sign-on" process. Users and entitlements are provisioned to applications through the identity service. 22 | 23 | Applications may be purchased by the enterprise company as a service from the application vendor, in which case they are commonly referred to "Software as a Service" (SaaS). 24 | 25 | ### User 26 | 27 | The "User" is part of the workforce of the enterprise company, and is able to use the Identity Service to log in to applications. 28 | 29 | ## Terminology 30 | 31 | ### Workforce 32 | 33 | The people engaged in work for a particular organization. Employees, contractors, and university faculty and staff are common examples of these people within a workforce. 34 | 35 | ### Tenant 36 | 37 | In a multitenant system, a tenant represents an organization or group of consumers, such as partners, customers, business units, departments, projects, or environments (e.g., production or test) within a larger entity. Each tenant has users and resources assigned to them, and only these users can access the resources within their specific tenant. Tenancy can be hierarchical, allowing a parent tenant to have sub-tenants, with resources potentially shared among them. 38 | 39 | Isolation between tenants varies along a spectrum based on business needs. At one end, physical resources are shared by trusted parties with minimal disruption, while at the other end, tenants are completely unaware of each other and may have dedicated resources. High-end solutions ensure full privacy between untrusted parties, whereas lower-end solutions allow for reduced isolation among trusted parties sharing a system. 40 | 41 | ### User Group 42 | 43 | A group is a collection of users that typically share a common set of permissions or access rights. Groups are used to simplify access management by allowing administrators to assign permissions to multiple users at once, based on their membership in the group. This makes it easier to manage and maintain consistent access controls across an organization. 44 | 45 | ### User Provisioning 46 | 47 | User provisioning is the process of creating, updating, and managing user accounts. 48 | 49 | #### Just-In-Time (JIT) Provisioning 50 | 51 | A method of user provisioning that automatically creates and manages user accounts on-demand, typically as users attempt to access resources for the first time. JIT provisioning reduces the need for manual account creation and management, and helps ensure that users have access to the resources they need when they need them. 52 | 53 | ### User Sign-on 54 | 55 | Sign-on is the process by which a user gains access to a computer system, network, or application by providing valid credentials, typically a username and password combination. The sign-on process is a crucial component of Identity and Access Management (IAM), as it helps to verify the user's identity and ensure that only authorized individuals can access protected resources. Sign-on is often the first step in the authentication and authorization process, which is followed by granting or denying access to specific resources based on the user's assigned permissions and roles. Additionally, sign-on mechanisms can be enhanced with various security measures, such as multi-factor authentication (MFA) or single sign-on (SSO), to provide an extra layer of protection against unauthorized access or potential security threats. 56 | 57 | ### Single sign-on (SSO) 58 | 59 | A user authentication process that allows users to access multiple applications, services, or systems with a single set of credentials. Single Sign-On simplifies the user experience by eliminating the need for users to remember and enter multiple sets of credentials for different resources. SSO can be implemented using various protocols, such as SAML and OpenID Connect. 60 | 61 | ### Multi-Factor Authentication (MFA) 62 | 63 | An authentication method that requires users to provide more than one independent factors to verify their identity. MFA typically combines something the user knows (e.g., password), something the user has (e.g., smartphone), and/or something the user is (e.g., fingerprint). MFA enhances security by making it more difficult for unauthorized individuals to access accounts, even if they have obtained the user's password. 64 | 65 | MFA mechanisms vary greatly in their security properties. Enterprises should choose authentication mechanisms, including MFA, which meet their authentication assurance needs. [NIST SP800-63 B](https://pages.nist.gov/800-63-3/sp800-63b.html) provides a useful resource for enterprises to understand an academic view of authentication assurance. Under the SP800-63 B, multi-factor authentication is classified as [Authentication Assurance Level 2](https://pages.nist.gov/800-63-3/sp800-63b.html#sec4) (AAL2). AAL2 is generally considered the minimum bar for authentication to sensitive enterprise resources. AAL1 may be considered for non-sensitive data such as access to the corporate cafeteria lunch menu. 66 | 67 | ### Governance 68 | 69 | In a general context, refers to the process of establishing and implementing policies, procedures, and frameworks to effectively manage and control an organization or system. In the context of Identity and Access Management (IAM), governance involves overseeing the use of digital identities and their access to resources across an organization. This includes setting standards, guidelines, and best practices for managing identities and access, as well as defining roles and responsibilities for IAM stakeholders, such as administrators, users, and auditors. 70 | 71 | ### Phishing Resistant Authentication 72 | 73 | Phishing resistant authentication mechanisms are those which effectively prevent remote account access through relayed secrets or assertion. These mechanisms rely on verifier impersonation resistance, achieved through techniques like [verifier name binding](FUTURE LINK) or [channel binding](FUTURE LINK), which block malicious services from impersonating legitimate verifiers. Examples of phishing-resistant authentication mechanisms include FIDO2/WebAuthn and mutual TLS. 74 | 75 | ## Protocols 76 | 77 | A protocol is a set of rules and guidelines for communicating and exchanging data between different systems or entities. IAM protocols define standardized methods for user authentication, authorization, and access management, and enable different applications and services to interoperate and share identity information. Some of the commonly used IAM protocols include SAML (Security Assertion Markup Language), OAuth (Open Authorization), OpenID Connect, and SCIM (System for Cross-domain Identity Management). These protocols provide a common language and framework for implementing IAM solutions, and help ensure interoperability and compatibility across different systems and applications. 78 | 79 | ### Continuous Access Evaluation Protocol (CAEP) 80 | 81 | TBD 82 | 83 | ### OAuth 2.0 84 | 85 | OAuth 2.0 is a widely-used authorization (authZ) protocol that enables both first-party and third-party applications to obtain limited access to user resources without exposing user credentials. It is a cornerstone of modern Identity and Access Management (IAM) systems, facilitating secure interactions between users and applications. OAuth 2.0 operates on a token-based mechanism, where an authorization server issues an access token to an application after the user consents. This token allows the application to access specific resources on the user's behalf, such as social media profiles or cloud storage, without requiring the user to share their login details directly with the application. OAuth 2.0 supports a variety of deployment models, making it versatile for different use cases and environments. 86 | 87 | ### OpenID Connect (OIDC) 88 | 89 | A protocol built on top of the OAuth 2.0 framework of specification (IETF RFC 6749 and 6750), used for authentication purposes. OIDC allows for the exchange of identity information between parties, such as an Identity Service and a relying party (e.g., a web application). It is designed to provide single sign-on (SSO) capabilities, as well as support for user authentication using JSON Web Tokens (JWTs). OIDC is widely used in modern IAM solutions and is supported by many popular Identity Services and service providers. 90 | 91 | ### SAML 92 | 93 | Security Assertion Markup Language (SAML) is an XML-based protocol used for securely exchanging authentication and authorization information between different systems. It enables single sign-on (SSO) by allowing users to authenticate once and gain access to multiple applications or services without needing to log in separately to each one. SAML facilitates interoperability between identity providers and service providers, ensuring that user credentials are not directly shared between systems. 94 | 95 | ### Risk Information Sharing & Collaboration 96 | 97 | TBD 98 | 99 | ### SAML 100 | 101 | TBD 102 | 103 | ### Shared Signals Framework (SSF) 104 | 105 | TBD 106 | 107 | ### System for Cross-domain Identity Management (SCIM) 108 | 109 | A standard protocol used for automating the exchange of user identity and access information between different systems or domains. SCIM is designed to simplify the management of digital identities and reduce the need for manual provisioning and deprovisioning of users across multiple systems. It enables organizations to automate user onboarding and offboarding, enforce consistent access policies, and reduce the risk of errors and inconsistencies. SCIM is widely used in IAM solutions, especially in cloud-based environments where multiple applications and services need to share identity information. 110 | 111 | 112 | 113 | -------------------------------------------------------------------------------- /ipsie-v1-draft.md: -------------------------------------------------------------------------------- 1 | ## Framing 2 | 3 | As a developer building a new business application, which will be used by many organizations (also known as a B2B SaaS application), I need to: 4 | 5 | * set up user and group provisioning and deprovisioning between a customer's workforce IdP and my application 6 | * set up user authentication via federated relationship with a customer's workforce IdP 7 | * ensure end users only have access to what they need in my application at any given point in time 8 | * be able to convey to the customer's IdP that I require a certain authentication level, require step-up authentication, or require re-authentication (e.g. due to policy enforcement at the RP) 9 | * know whether that authentication level was met at the IdP during a sign-in 10 | * be able to convey to the customer's IDP that I require a certain identity verification level and/or require additional identity attributes (e.g. due to policy enforcement at the RP) 11 | * know whether the requested identity verification was met at the IDP 12 | * be notified when tokens have been revoked 13 | * be notified when sessions have been invalidated 14 | * receive real-time signals about changes in account posture or integrity 15 | * receive real-time signals about changes in the device posture or integrity. 16 | * receive enterprise required policy that the new business application must enforce (e.g. identities authenticated by the enterprise IDP MUST NOT access the RP via a VPN) 17 | * only enforce the enterprise defined policy for users authenticated by the enterprise IDP 18 | 19 | To make that happen, I need to know: 20 | 21 | * which protocols I should use 22 | * how to securely implement and deploy those protocols at scale 23 | * how to implement those protocols in an interoperable manner 24 | 25 | --- 26 | 27 | ## User Authentication via Workforce IdP 28 | 29 | > set up user authentication via federated relationship with a customer's workforce IdP 30 | 31 | ## User Provisioning and Deprovisioning 32 | 33 | > set up user provisioning and deprovisioning between a customer's workforce IdP and my application 34 | 35 | ## Group Provisioning and Deprovisioning 36 | 37 | > set up group provisioning and deprovisioning between a customer's workforce IdP and my application 38 | 39 | ## Ensure Least Privileged Access 40 | 41 | > ensure end users only have access to what they need in my application at any given point in time 42 | 43 | ## Convey Required Authentication Level to the IdP 44 | 45 | > be able to convey to the customer's IdP that I require a certain authentication level, request step-up, or request re-authentication of the user via the customer's IdP 46 | 47 | ## Know whether Required Authentication Level was Met at the IdP 48 | 49 | > know whether that authentication level was met at the IdP during a sign-in, step-up, or re-authentication event 50 | 51 | ## Receive Notifications of Revoked Tokens 52 | 53 | > be notified when tokens have been revoked 54 | 55 | ## Receive Notifications of Invalidated Sessions 56 | 57 | > be notified when sessions have been invalidated 58 | 59 | ## Receive Signals about Account Posture or Integrity Changes 60 | 61 | > receive real-time signals about changes in account posture or integrity 62 | 63 | ## Receive Signals about Device Posture or Integrity Changes 64 | 65 | > receive real-time signals about changes in the device posture or integrity (e.g. from device management services, EDR, etc.) 66 | 67 | --- 68 | 69 | ### **1. Authentication** 70 | 1. **As a B2B SaaS developer, I want to set up user authentication via a federated relationship with a customer's IdP, so that end users can log in using their enterprise credentials.** 71 | 2. **As a B2B SaaS developer, I want to enable each enterprise tenant to configure their own IdP(s) for authentication, so that multi-tenant customers can manage their users independently.** 72 | 3. **As a B2B SaaS developer, I want to convey to the customer's IdP that the application requires a specific authentication level, so that access policies like MFA can be enforced.** 73 | 4. **As a B2B SaaS developer, I want to know whether the specified authentication level was met at the IdP during sign-in, so that I can ensure compliance with security requirements.** 74 | 5. **As a B2B SaaS developer, I need to bind the customer's uuid and IdP entity to an internal UUID, so that accidental user impersonation cannot happen when multiple customer IdPs are configured.** 75 | 76 | --- 77 | 78 | ### **2. Authorization** 79 | 1. **As a B2B SaaS developer, I want to ensure end users only have access to what they need in my application at any given point in time, so that I maintain the principle of least privilege.** 80 | 2. **As a B2B SaaS developer, I want to allow enterprises to dynamically assign roles based on user attributes, so that access permissions stay aligned with organizational changes.** 81 | 3. **As a B2B SaaS developer, I want to issue tokens scoped to specific permissions so that users or services have only the access they need.** 82 | 4. **As a B2B SaaS developer, I want to allow enterprises to dynamically assign policies to specific permissions, so that enterprises have flexibility in assignment of access.** 83 | 84 | --- 85 | 86 | ### **3. User and Group Lifecycle Management** 87 | 1. **As a B2B SaaS developer, I want to set up user provisioning and de-provisioning between a customer's workforce IdP and my application, so that user accounts are automatically managed.** 88 | 2. **As a B2B SaaS developer, I want to set up group provisioning and de-provisioning between a customer's workforce IdP and my application, so that user group memberships are synchronized.** 89 | 3. **As a B2B SaaS developer, I want to provision user accounts dynamically upon successful authentication, so that onboarding is seamless.** 90 | 4. **As a B2B SaaS developer, I want to automatically deactivate user accounts when permissions change or users leave the enterprise, so that access remains secure.** 91 | 5. **As a B2B SaaS developer, I want to allow enterprises to define and assign their own access policies, so that they can dynamically allow just-in-time access to my application's permissions.** 92 | 93 | --- 94 | 95 | ### **4. Identity Federation** 96 | 1. **As a B2B SaaS developer, I want to automate the exchange and update of federation metadata with enterprise IdPs, so that customers experience seamless integrations.** 97 | 2. **As a B2B SaaS developer, I want to support multi-IdP configurations per tenant, so that enterprises with complex structures can connect multiple directories.** 98 | 3. **As a B2B SaaS developer, I want to provide tools to debug and monitor federation flows, so that enterprise clients can troubleshoot issues effectively.** 99 | 4. **As a B2B SaaS developer, I want to advertise what entity categories (or domains and subject areas) of attributes I support, so that enterprise clients can more easily integrate their standard attributes and groups into my application.** 100 | 5. **As a B2B SaaS developer, I want to define a data catalog with element names, allowed values, functional descriptions, data types, data use, and versioning, so that enterprise clients can more easily integrate their standards into the system.** 101 | 102 | --- 103 | 104 | ### **5. Risk Signal Sharing and Posture Updates** 105 | 1. **As a B2B SaaS developer, I want to receive real-time signals about changes in account posture or integrity, so that I can take action to protect the application.** 106 | 2. **As a B2B SaaS developer, I want to support conditional access policies based on real-time risk signals, so that enterprises can enforce dynamic access controls.** 107 | 3. **As a B2B SaaS developer, I want to send real-time signals about changes in account posture or integrity, so that my enterprise customers can take action to protect their data.** 108 | 109 | --- 110 | 111 | ### **6. Session Management** 112 | 1. **As a B2B SaaS developer, I want to be notified when tokens have been revoked, so that I can terminate access for affected sessions.** 113 | 2. **As a B2B SaaS developer, I want to be notified when sessions have been invalidated, so that I can ensure the application enforces session termination.** 114 | 115 | --- 116 | 117 | ### **7. Protocols and Standards** 118 | 1. **As a B2B SaaS developer, I want to identify which protocols (e.g., SAML, SCIM, OIDC, OAuth 2.0) I should use, so that I meet enterprise customer requirements.** 119 | 2. **As a B2B SaaS developer, I want to securely implement and deploy these protocols at scale through community-driven SDKs, so that my application remains reliable and secure without becoming an identity expert.** 120 | 3. **As a B2B SaaS developer, I want to implement protocols in an interoperable manner, so that my application works with diverse enterprise IdP configurations.** 121 | 122 | --- 123 | 124 | ### **8. Security and Compliance** 125 | 1. **As a B2B SaaS developer, I want to provide APIs to revoke tokens and sessions, so that enterprises can respond to incidents immediately.** 126 | 2. **As a B2B SaaS developer, I want to log and report IAM-related activities, so that enterprise customers can meet their compliance requirements.** 127 | 3. **As a B2B SaaS developer, I want to allow my enterprise customers to pull logs from my application into their enterprise SIEM, so that the can meet their compliance requirements.** 128 | 4. **As a B2B SaaS developer, I want to ensure my application and enterprise customers can support multiple signing and encryption keys, so we can independently rotate them without major operational impacts.** 129 | 130 | --- 131 | 132 | ### **9. Tenant Management and Customization** 133 | 1. **As a B2B SaaS developer, I want to ensure data and configurations are securely isolated between tenants, so that enterprise customers can operate securely.** 134 | 2. **As a B2B SaaS developer, I want to protect data and configurations with customer-managed keys so that enterprise customers can operate securely.** 135 | 3. **As a B2B SaaS developer, I want to enable enterprise clients to customize the application interface and login page with their branding, so that the application aligns with their identity.** 136 | 4. **As a B2B SaaS developer, I want to allow enterprises to define and enforce unique IAM policies for their users, so that they can meet their security requirements.** 137 | 138 | --- 139 | 140 | ### **10. Developer and Client Support** 141 | 1. **As a B2B SaaS developer, I want to consume SDKs and APIs to simplify IAM integrations, so that enterprise clients can integrate with my application quickly.** 142 | 2. **As a B2B SaaS developer, I want to offer a sandbox environment for testing IAM configurations, so that clients can validate their setups before going live.** 143 | 3. **As a B2B SaaS developer, I want to consume sandbox environments for testing IAM configurations, so that I can validate their setups before going live.** 144 | 4. **As a B2B SaaS developer, I want to provide clear error messages and debugging tools, so that clients can troubleshoot integration issues quickly.** 145 | 146 | --- 147 | # Additional Security Operations Related Stories 148 | 149 | --- 150 | 151 | ### **1. Secure Authentication Mechanisms** 152 | 1. **As a developer, I want to force re-authentication of the user with a stronger credential during privileged actions, so that my customers have an additional layer of security during their tenant configuration changes.** 153 | 2. **As a developer, I want to implement adaptive authentication, so that access policies can adjust dynamically based on contextual signals.** 154 | 3. **As a developer, I need to be able to classify credential strength and communicate that classification in a manner that can be compared easily. (If we stop at a NIST AAL 1,2 or 3 then we have failed)** 155 | 156 | --- 157 | 158 | ### **2. Session and Token Management** 159 | 1. **As a developer, I want to store tokens securely and prevent long-lived token usage, so that stolen tokens cannot be exploited.** 160 | 2. **As a developer, I want to implement short-lived access tokens and automatic refresh token rotation, so that token misuse is minimized.** 161 | 3. **As a developer, I want to detect and terminate sessions from suspicious IP addresses, so that session hijacking is prevented.** 162 | 4. **As a developer, I want to bind tokens to specific devices or sessions, so that token replay attacks can be mitigated.** 163 | 5. **As a developer, I want to detect changes, such as the use of suspicious IP addresses, non-compliance with device management practices, or the presence of malware on the end user's device, so that I may factor that into my application's risk profile and go so far as to terminate sessions and block continued access from that IP address, device, etc. for that same user or all users from those devices/locations.** 164 | 165 | --- 166 | 167 | ### **3. Identity Governance and Compliance** 168 | 1. **As a compliance officer, I want to maintain detailed, immutable logs of all identity-related events, so that we meet regulatory and audit requirements.** 169 | 2. **As an admin, I want to regularly pull current user profiles, group memberships, and entitlements, so that access controls stay aligned with organizational needs.** 170 | 3. **As a developer, I want to encrypt all data in transit and at rest, so that sensitive information is protected against unauthorized access.** 171 | 172 | --- 173 | 174 | ### **4. Account Security and Threat Mitigation** 175 | 1. **As a security officer, I want to detect unusual login patterns or behavior, so that potential account compromises can be flagged.** 176 | 2. **As a user, I want to be notified of suspicious activity on my account, so that I can take corrective actions quickly.** 177 | 178 | --- 179 | 180 | ### **5. Advanced Identity Management** 181 | 1. **As a developer, I want to support non-person entity (NPE) authentication, so that services and APIs can securely access resources.** 182 | 2. **As a developer, I want to provide fine-grained attribute-based access controls, so that enterprise customers can create highly specific permissions.** (potentially a repeat of above) 183 | 3. **As a developer, I want to implement dynamic entitlements, so that user access can adapt in real-time to changing conditions.** (potentially a repeat of above) 184 | 185 | --- 186 | 187 | ### **7. Defense Against Identity-Based Cyber Attacks** 188 | 1. **As a developer, I want to enforce HTTPS with strong TLS, so that man-in-the-middle attacks are prevented.** 189 | 2. **As a security officer, I want to monitor privileged account activities, so that insider threats can be detected and mitigated.** 190 | 191 | --- 192 | 193 | ### **8. Monitoring and Incident Response** 194 | 1. **As a security officer, I want to receive real-time alerts for critical identity-related events, so that I can respond quickly to potential threats.** 195 | 2. **As a compliance officer, I want to integrate with enterprise SIEM systems, so that all logs are centralized for easier analysis.** 196 | 3. **As an admin, I want to automate incident response workflows, so that compromised accounts are immediately secured.** 197 | 198 | --- 199 | 200 | ### **9. Development and Testing Best Practices** 201 | 1. **As a developer, I want to follow secure development practices and perform regular threat modeling, so that potential vulnerabilities are identified early.** 202 | 2. **As a developer, I want to be proactively alerted when CVEs are created against community-contributed SDKs and APIs that I utilize, so that potential vulnerabilities are identified early.** 203 | 3. **As a developer, I want to be proactively provided indicators of compromise for CVEs are created against community-contributed SDKs and APIs that I utilize, so that potential indicators of compromise are identified early.** 204 | 4. **As a developer, I want to secure APIs with authentication and input validation, so that unauthorized access and injection attacks are prevented.** 205 | 206 | --- 207 | 208 | ### **10. Customer and Admin Controls** 209 | 1. **As an enterprise admin, I want to define custom IAM policies for my users, so that I can enforce my organization’s unique security requirements.** 210 | 2. **As an admin, I want to delegate access and policy review responsibilities to team leads, so that permissions are managed efficiently at scale.** 211 | 3. **As a user, I want to manage my consent for data usage, so that I can comply with privacy regulations like GDPR.** 212 | 213 | --- 214 | 215 | --------------------------------------------------------------------------------