Skip to content

2025‐01‐14

Jump to bottom
Aaron Parecki edited this page Jan 15, 2025 · 2 revisions

IPSIE WG Meeting Minutes

Date: 2025-01-14

Attendees

  • Aaron Parecki (Okta)
  • Dick Hardt (Hellō)
  • Sean Miller (RSA)
  • Shannon Roddy (self/LBNL)
  • Kenn Chong (RSA)
  • Jon Bartlett (Zscaler)
  • Tom Clancy (MITRE)
  • Mark Maguire (Aujas Cybersecurity)
  • Filip Skokan (Okta)
  • Travis Tripp (HPE)
  • Mike Jones (Self-Issued Consulting)
  • Mike Kiser (SailPoint)
  • Karl McGuinness (Self)
  • Brian Soby (AppOmni)
  • Pamela Dingle (Microsoft)
  • Jen Schreiber (Workday)
  • Victor Lu (Independent)
  • Nagesh Gummadivalli (Workday)
  • Ameya Hanamsagar (Meta)

Agenda

Minutes

  • Review of Antitrust policy
  • Reviewing PR 34: Updates wording to MFA terminology to include references to NIST, PR was approved and merged
  • Reviewing PR 35: Reviewed phishing resistant authentication, provided a definition. Tim Cappalli recommended updating the definition to inculde channel bonding.
  • Reviewing PR 33: About enterprise being a resource owner. PR gave examples of resources (user directories, identity providers, relying parties etc). Karl McGuinness made the point this was not what we meant by resource owner last call. The examples are useful, but it was pointed out that it is misleading that resource owner is an identity provider. Recommended to continue offline on the GitHub thread, but looking to find a term already defined by another standard instead of creating a net new concept. Holding on merging PR 33 and waiting for more edits. "Resource Owner" creating confusion due to differences in OAuth definitions versus this use case. George Fletcher referenced there are differences between SaaS and internal apps. For internal apps, enterprises have complete control. Pam Dingle recommended we define enterprise as the driving business force. Pam suggested we say enterprise is the business force that rationalizes what participants are created. Karl mentioned that enterprises have a decider role for security decisions and IPSIE should help reduce friction on trust between resource and vendor. Aaron recommended we write a new sentence or two to capture what we discussed here. Russell Allen recommended we incorporate Pam's definition of enterprise.
    • Suggestion for Enterprise from Travis Tripp: An enterprise refers to an organization that seeks to implement enterprise-grade governance of its users, including authentication, lifecycle management, and risk mitigation. It emphasizes the scale and complexity of managing user access and authentication processes across all applications used within the organization. By centralizing these processes and utilizing an industry-standard set of protocols, the enterprise ensures secure management of user credentials and access, allowing users to manage a single set of credentials while the organization can centrally control and monitor access to various applications.
  • Aaron recommended for resource owner definition, we shorten it to avoid conflicting with other accepted IAM definitions of resource owners.
  • Pam recommended we add an aspect of policy control to the definition.
  • PR 33 was merged.
  • Conversation moved onto discussions of levels for lifecycle management
  • Karl recommended grant or revoke from central resource, highest maturity is how do I know what a user can do in the app? That is a harder problem than can I drive a business process. It is a very different process to know who can do what in the app versus different automation levels.
  • If users have more access then they should have, how do we remediate? Based off the app's architecture, there could be many different ways to determine access. Just managing groups is just a piece of the puzzle. They could have access directly in the app. To raise the security bar we need to control the blast radius and have the app's local authorization model.
  • Aaron asked if there are existing standards that can address this. Brian Soby mentioned he has never seen a large SaaS app that meets a standard like ones alluded to.
  • Nagesh Gummadivalli mentioned this is a hard problem to solve. If we define what the applications log into a central place then we can monitor, but the drift happens outside of the product.
  • Karl - companies are spending significant money trying to solve this problem building custom connectors to address this. With IPSIE if we set a high standard it could pave the way for enterprise applications to meet these better standards in the future.
  • Travis mentioned how platforms like AWS & HPE GreenLake you can give session-constrained access in a JIT fashion that only lasts for the duration of the session. Also, how does conditional access fit in? I.e. giving access only if they meet certain criteria. Might be possible with SCIM?
  • Mark Maguire: We should shift the burden of complex entitlement management to the application teams. The application should bear the responsibility for providing an interface that allows centrally managed groups to give access within the application.
  • Pam: We could just have 2 levels? Aaron: We get to pick. Pam: We are discussing the management of the account versus authorization. These can be separate things. There are a lot of ways to skin the entitlement cat. We dont need to define everything in minute detail, but today there is no simple pattern that will work in every case. If its too hard to certify against it could harm this work. 2 levels, and have authorization/entitlement world be separate / punt on it?
  • Dick Hardt: There is a huge value in being able to centrally manage groups and push that out to apps. When I think of entitlements that is a big complicated thing, so by changing this to groups it becomes more streamlined.
  • Ameya: Account may have access to certain artifacts/data. There is not any protocol / standards for guest accounts. Should we include that here?
  • Discussion if we should remove Entitlements and not be a separate column. After account provisioning, is groups the next right thing to tackle?
  • Should we have just 2 columns? JIT - which just includes groups and another which is Asyc, so I can control groups separately.
  • Aaron: Should we make level 1 JIT and account creation and level 2 being able to provision groups?
  • Mark: Would that imply that if I am an app and I support JIT and make everyone as a super user then I am IPSIE compliant? I think the security baseline should be higher than that.
  • We also are not preventing from users logging in directly with their email, even if the enterprise supports jit, could external entities do account takeovers?
  • Aaron: I like the idea that not only can accounts be created by JIT also they cannot be controlled in other ways.
  • Karl: Agreed, becomes a stronger statement for a security team.
  • Aaron: Sounds like this needs more refining. 2 main points: in JIT ensure users are not created as admins and Karl's comment about ensuring JIT from IDP is the only way accounts are created - not allowing users to sign up via email. We need to capture these requirements in the levels.
  • Pam: What we are talking about is demonstrating control. Not only can we do something, but can we do something with security controls that demonstrates the account creation process is secure. This could help us define further - not just what you do but also what you don't do.
  • Mark: Will take a first attempt at creating a PR that describes behavior and negative behavior we want to avoid.
Clone this wiki locally