M-Files is a 2025 Gartner Peer Insights Customers' Choice for Document Management
➡️Download the report!

Options
  • Locked Locked
  • Replies 4 replies
  • Subscribers 9 subscribers
  • Views 438 views
  • Users 0 members are here
Related
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

SingleSignOn SameSite Attribute

EPmstrauss
Hi,

if there is a web application which uses SSO for authentication, we get a cookie container object after the request of the WebServiceSSO.aspx.

In our constellation the web application is hostet at another domain. Because of that SSO doesn't work. In the cookies is the SameSite attribute set, so all modern browsers block the SSO because of the different domain.

Is there any possibility to solve this? Is there any configuration which can affect the same site attribute?

Greetings

Michael
Parents
  • I'm not sure there is a "correct answer" here, as it depends largely on the architectural setup. What I think you probably have is this:


    • User connects to web application A via SSO. Web application A knows the user it's running as and can access things like the user's name and email and things.

    • Web application A attempts to make a connection to MFWS using SSO.

    • Requests to MFWS fail due to authentication issues.



    In this case what's probably happening is related to the double-hop problem whereby the Windows credentials can only be used on web application A, and not used to subsequently authenticate to a second machine. This isn't something I've ever had to configure myself (it's outside of the direct context of either the development aspect of the integration and also the M-Files implementation), but my understanding is that the solution involves configuring the authentication to allow delegation. In this case you probably need to speak to someone who understands authentication providers far better than I.

    But I may be completely wrong in my assumptions, hence my question.

    Regards,

    Craig.
Reply
  • I'm not sure there is a "correct answer" here, as it depends largely on the architectural setup. What I think you probably have is this:


    • User connects to web application A via SSO. Web application A knows the user it's running as and can access things like the user's name and email and things.

    • Web application A attempts to make a connection to MFWS using SSO.

    • Requests to MFWS fail due to authentication issues.



    In this case what's probably happening is related to the double-hop problem whereby the Windows credentials can only be used on web application A, and not used to subsequently authenticate to a second machine. This isn't something I've ever had to configure myself (it's outside of the direct context of either the development aspect of the integration and also the M-Files implementation), but my understanding is that the solution involves configuring the authentication to allow delegation. In this case you probably need to speak to someone who understands authentication providers far better than I.

    But I may be completely wrong in my assumptions, hence my question.

    Regards,

    Craig.
Children
No Data
M-Files
M-Files Support


© 2025 M-Files, All Rights Reserved.