-
Notifications
You must be signed in to change notification settings - Fork 5
2024‐10‐08
Aaron Parecki edited this page Nov 13, 2024
·
1 revision
October 8, 2024
- Aaron Parecki (Okta)
- Mike Leszcz (OIDF)
- Dean H Saxe (Beyond Identity)
- Karl McGuinness
- Mike Kiser (Sailpoint)
- Joseph Heenan (Authlete)
- Mike L introduced the antitrust statement
- Aaron introduced the charter and problem statement
- Dean - should we put together specific enterprise use cases to solve and figure out how to plug the piece together?
- Aaron - agreed, but worried about deep diving too far on use cases
- Karl - what are the outcomes we are trying to define? “enterprise” isn’t detailed enough, but also worried about analysis paralysis
- Aaron - focus on secure by default and interoperability
- Dean - been seeing a lot of WS-Fed even with SaaS
- Karl - I’d advocate to not go down that route because MS IdP does support OIDC
- Karl - enterprise outcome is strong multifactor authentication to all my applications. so if the application is using SAML, how do I ensure that and how do I do step-up in SAML.
- Dean - how do we get to parity between SAML and OIDC so we can communicate the same message about the authentication strength - those are clear good outcomes for enterprises
- Dean - Properties of the authenticators - whether credential can be shared or not shared, phishing resistant
- Karl - is this different from the attributes defined in NIST?
- Dean - NIST hasn't defined a way to communicate the specific properties looking for and what was used. Will present about this at Authenticate next week with Pam.
- Step-up outcomes that Pam has been working on with SAML, maybe can continue that work here
- Karl - how to consistently layer OIDC configurations on top of SAML integrations - to avoid needing to require upgrading SAML to OIDC for SSO
- Aaron - also handling differences with user identifiers between SAML and OIDC
- Dean - we should take a pointed stance on what user identifiers should be to minimize bad outcomes, e.g. avoiding email address as identifiers
- Karl - it's an account linking problem, when a SaaS app goes from self service signup to linked to the enterprise IdP. apps have to implement logic to solve this, so usually fall back to email
- Mike K - how to interweave shared signals and SCIM events
- Karl - the broader goal is keeping things up to date, the menu of options available is too large at the moment
- Dean - timeliness is a challenge
- Dean - how does FedCM play into this?
- Karl - "how does a user who shows up at a SaaS app log in with their enterprise IdP by default instead of email reg / shadow IT by default"
- Aaron - how do we get more SaaS vendors in the conversations?
- Aaron - next meeting is during Authenticate and Oktane, so next meeting will be Oct 22
- Secure by default
- Ensure hardware-backed phishing-resistant MFA is enforced into apps
- ensure every account has MFA enabled
- define the interoperability of authenticator attributes
- Secure configuration of IdP and RP
- Enable automated credential rotation
- Step-up authentication - including what that looks like for SAML
- "how does a user who shows up at a SaaS app log in with their enterprise IdP by default instead of email reg / shadow IT by default"
- Zero trust
- Continuous authentication
- Zero standing privilege - capability to know that privileges are managed, not unknown and unmanaged
- Minimizing optionality for interoperability goals
- Stretch goal - configuration of these integrations (like FastFed?)