-
Notifications
You must be signed in to change notification settings - Fork 63
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
FedCM: unable to serve 'well-known file' on eTLD+1 within development environment #189
Comments
If we changed the flag to skip fetching the |
In the interim, you could simply add a fake provider URL to the well-known file to avoid exposing your dev url. e.g.
When #fedcm-without-well-known-enforcement is enabled, we'd skip matching the configURL with provider_urls. |
(replying from the very same company as @dusekjan )
Yeah, that would be great. Appreciated!
We can. It implies a rather nontrivial amount of both paperwork and implementation work; I am somewhat curious about the real motivation behind this restriction (i.e. why is it forced to publish the .well-known at eTLD+1, when compared to other well-knowns we are already publishing - for instance, our |
Like my colleague said, it would be really useful for us. Thank you! |
The reason for having the |
Thanks for the reply. It is still beyond my understanding what is the goal here; what kind of attack is this scheme trying to prevent. Is it somehow related to fedidcg/FedCM#230 ? (I am having a hard time understanding that vector as well.) And I am pretty certain that other IdPs would be interested in understanding as well, yet the FedCM explainer does not seem to actually explain the motivation. May I ask for improving the documentation with respect to the discussed requirement? In particular, could you explain the theoretical attack/privacy-denial vector that would be possible if the IdP hosted the well-known file in multiple locations? The RP is obviously free to pick any of these multiple locations... as long as they are documented and they provide the relevant FedCM endpoints/services. |
The goal is that the IdP should NOT learn about the RP and user credential at the same time before user permission. i.e. in the accounts_endpoint where IdP gets user credential, they should NOT know which RP the user is visiting. The IdP (attacker in this case) could start with the following API call on the website https://rp.example:
The IdP can then joint the RP information with user information in the manifest https://idp.example/*rp*/fedcm.json like the following:
|
By the way, feel free to go over the spec since we did try to capture most of our privacy and security considerations there. For the well-known in particular, see https://fedidcg.github.io/FedCM/#manifest-fingerprinting |
I understand that it is desirable for the IdP to NOT know about a particular RP before the assertion call is performed. While I do not see the immediate risk of revealing the RP to IdP (is there any, really? in oauth-based scenarios, providing
Now this is an interesting formulation. Even if we assume that IdP is an attacker, how can this IdP influence/modify/adjust the code that is presented on RP's webpage? I was working under the assumption that IdP and RPs are independent entities, different companies etc. We are going to provide our IdP services to multiple RPs, but we cannot control the contents of their respective pages. How could a malicious IdP cause the RP (victim?) to put this anonymity-breaking To sum my questions up:
|
Update: it appears that some (all?) of my concerns seem to be somewhat rectified in https://fedidcg.github.io/FedCM/#attack-scenarios (one section above the originally linked spec content). Just to make sure I understand correctly: we are discussing a scenario where both RP and IdP are cooperating together, not really trying to use FedCM to provide sign-in, but rather abusing the FedCM functionality to allow tracking visits between RP and IdP (or multiple different RPs), right? I am still somewhat puzzled about this scenario, as FedCM is obviously based on user interaction an browser-provided UI, so it is unclear to me how would the abuse happen without the user being presented with explicit (fake) sign-in choices. |
|
I would say that the
That is true. But the RP (still thinking about the criminal scenario with colluding RP and IdP) has two choices:
I would say that both of these variants are not suitable for a malicious RP, thus a malicious RP cannot systematically/successfully abuse FedCM to perform reliable tracking. |
Id assertion is only fetched after user chooses to perform federation. So yes of course we are ok with the IdP knowing this, once the user has gone through the flow.
If the eTLD+1 requirement was removed, the malicious RP can use their owned eTLD+1 to use a different origin every time, so no UI is ever shown. They would always just say that there are no accounts. |
I see. Well, I think I have no more questions now - all answered. Thanks a lot for you time and patience! |
Good news, the change is landed in 121.0.6144.0. It should be in Canary for some users now. If you don't get it today, it should be tomorrow. |
Great! It works as I expected. Thank you very much for your time. |
Hello,
We as IdP are trying to integrate FedCM, our production domain has this pattern
https://login.idp.com/
- I understand that well-known file must then be served from eTLD+1 so the URL would behttps://idp.com/.well-known/web-identity
.But within the development environment our domains have this pattern
https://login.dev.idp.com/
(dev.idp.com being a private DNS, not publicly accessible) and because dev.idp.com is not registered in the eTLD list (Public Suffix List) we are unable to properly test or implement FedCM. I guess the navigator requests a well-known file athttps://idp.com/.well-known/web-identity
.We need the browser to send requests to
https://login.dev.idp.com/.well-known/web-identity
. How do we do that? Is there any special flag or configuration we can use in the dev environment to satisfy the condition:The #fedcm-without-well-known-enforcement flag does not work because the error is
The fetch of the well-known file resulted in a network error: ERR_NAME_NOT_RESOLVED
and not that the returned URLs providing the configuration files do not match.The text was updated successfully, but these errors were encountered: