7G/ LEAKED CREDS 101 - How Leaked Creds are Used to Compromise IAM Systems?

From IIW

Backchannel Logout and SSE


Session Convener: Heather Flanagan, Vittorio Bertocci

Notes-taker(s): Heather Flanagan

Tags / links to resources / technology discussed, related to this session:


Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:


As browsers kick in new privacy requirements, underlying primitives that let federated identity work will break. Some technologies may serve as alternatives.

Backchannel logout is still in draft.

In front channel, OP will have iFrames with 3pc to each RP that used it to login in order to then logout.

In Backchannel, the RP will have to expose an endpoint. The RP will clear its own cookie, and then the OP will do a server-to-server communication to the other RP endpoints to logout.


Challenges:

  • the endpoint need to be visible outside firewalls;
  • the RP needs to be stateful (save the SID and wait for the browser to touch it so it can then do the logout)


This can be packaged into an SDK but it requires RPs to have infrastructure to do this. Of course, not everyone has infrastructure, and not every infrastructure is the same.

Adoption rate? Mostly adopted in the financial industry, but otherwise not broadly adopted.

Use case that caused the spec to happen: a person from a brokerage house in the OID workshop said he had a use case of stock trading on a website, but the bond trading happens in an iFrame with a third-party vendor. When you logout of the stock trading site, want to be certain that logout has also happened with the bond trading site.

It is not considered a developer-friendly solution.


Shared Signal and Events (SSE) is a large stack of specs across different standards orgs:

  • CAEP and RISC, (OIDF)
  • SSE, (OIDF)
  • RFC 8935, RFC 8936, Subject Identifiers (I-D), (IETF)
  • RFC 8417, (IETF)
  • Jose Family (IETF)


A true browser-based logout event, SSE could be a good option, though it is also a bit heavy weight One group is trying to bring together OIDC, SCIM, FastFed, and SSE as a complete identity stack. This is definitely complicated.

Unclear how this will work with SAML.

The majority of requirements for SLO in the enterprise is based on on-prem services. If the OP is in the cloud, it might not talk directly to the RPs in the enterprise.

Parts of the SAML ecosystem no longer have developers working on it; putting changes into a SAML stack is formidable.

Logout is an asynchronous problem, and both OIDC and SAML try to handle it in a synchronous way.

The solutions between the new app-driven world and traditional webSSO is a mismatch.

For deployment challenges - percentage that’s solved for enterprise using device management? It varies by sector.

Alternative directions: user preferences and controls; browser APIs are another, to help developers expose the options. There is more acceptance of a managed profile in the browser than a managed device; the user can always use a different browser for different purposes. There needs to be otherways to push the policy. Should an IdP host a well-known file that holds that profile for the browser? That might be an option to explore.

With on-prem constraints (which include a lot of SAML) then the only thing that has access inside the firewall is the browser; there is no direct communication between the OP and the RP. Backchannel logout would therefore not be viable. SAML is also an entirely a non-started, and SAML is the larger use case (larger than OIDC) in this case. In one case, “enterprise apps” are just another name for SAML services.

What’s urgent for browsers - any new changes require redeployment of the RP, so if 3pc are going to be killed in Q32023 (which is an absolute) can Backchannel be deployed by then? No, absolutely not. If there is an option that allows the functionality to work even if there is bad UX, that’s ok, because that will just be incentive to move.

The assumption is that it’s easier to change the IdP/OP than it is to change the SP/RP. So if the API is something the IdP would call that would result in an interaction with the user “would you like to log in” that might be more deployable.

FedCMs goal is for the API to give the browser all the URLs and load them in parallel as if they were iFrames. Right now, they are GET requests, but doesn’t allow the RP to use JavaScript to clear the code (and that’s critical to some, not just to clear cookies but also to clear browser local storage). There will be more value when FedCM can take over some of the responsibility for logout. If the browser knows what’s supposed to logout, it can keep trying to logout until successful. As long as the RP sees exactly the same thing it sees today so they don’t have to make changes.

Backchannel won’t save everything. What can we put into the OP/RP interaction that will provide enough friction to support the privacy requirements while still allowing existing functionality to work.

Would like to not live in a world where vendors ask customers to remove protections.

To continue the conversation: https://www.w3.org/community/fed-id/


Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

Retrieved from "https://iiw.identitycommons.net/index.php?title=7G/_LEAKED_CREDS_101_-_How_Leaked_Creds_are_Used_to_Compromise_IAM_Systems%3F&oldid=24272"