SSO Failed to determinate SAML connection

Support
,
#1

Hi there,

I have a problem with SSO add-on. We configure Azure AD as SAML IP and all works fine for first time login.
But when we try to login second time (the IP session is still valid) we are getting error:

java.lang.RuntimeException: Failed to determinate SAML connection
at com.haulmont.addon.saml.saml.internal.impl.SamlConnectionContextProviderImpl.populateConnection(SamlConnectionContextProviderImpl.java:157) ~[na:na]
at com.haulmont.addon.saml.saml.internal.impl.SamlConnectionContextProviderImpl.getLocalEntity(SamlConnectionContextProviderImpl.java:109) ~[na:na]
at org.springframework.security.saml.SAMLProcessingFilter.attemptAuthentication(SAMLProcessingFilter.java:84) ~[na:na]
at org.springframework.security.web.authentication.AbstractAuthenticationProcessingFilter.doFilter(AbstractAuthenticationProcessingFilter.java:212) ~[na:na]

cuba version: 7.2.5
com.haulmont.addon.saml:saml-addon-global:0.4.2

I saw the other issue raised earlier (link: Saml add-on Failed to determinate SAML connection - CUBA.Platform).
We do have attribute ‘tenant’ configured for all login attempts.

Kind regards

#3

Hi, @dmitry.likane

The problem comes from the recent security update in Chrome regarding the handling of the SameSite attribute in cookies.
The reason is that JSESSIONID cookie doesn’t have attribute SameSite specified. Chrome defaults it to SameSite=Lax and then blocks it because the request was made from a different site (IDP). It leads to invalidating the current session and losing the tenant attribute which causes the error above.

At the moment we are thinking of some workaround for SAML add-on, but you can try overcoming this issue by using SameSite=None; Secure cookie policy.

Regards,
Gleb

#5

Hi @shalyganov, thanks for your guidance on this issue. We have tried to set the SameSite attribute ourselves but it doesn’t seem to be setting correctly for us. What we have tried is the following right before initiating the request to our IdP. Should we be trying to modify the session at a different entry point perhaps?

VaadinSession.getCurrent().getSession().setAttribute("SameSite", "None; Secure");
VaadinSession.getCurrent().getSession().setAttribute("tenant", connection.getSsoPath());
Page.getCurrent().setLocation(getLoginUrl());

Do you have any idea when a fix to the add-on might be released?

#6

Actually, this cookie setting is configured on the servlet container side. For example, in case of Tomcat it can be achieved by declaring the CookieProcessor as described here. Unfortunately, current version of Cuba plugin depends on the Tomcat 9.0.27, in which this approach doesn’t work because of the bug. We are planning to update the tomcat version in the next bugfix release, which is expected in early November. Nevertheless, you can build a WAR and deploy it to the more recent version of Tomcat.
In case of UberJar, Jetty version also needs to be updated.

Regards,
Gleb

1 Like
#7

The above worked for me. It has resolved the issue where logging into AD using SAML didn’t always work. Fix for me is to use tomcat 9.0.37 with the following line added to /opt/tomcat/webapps/ROOT/META-INF/context.xml , enclosed in <>
CookieProcessor sameSiteCookies=“none” Thank you @shalyganov :slight_smile:

1 Like
#8

@shalyganov hi getting same issue here, How can i fix it for uberJar?

#9

Hi, @igor.sovcik

Open the web.xml in the web-module: web/WEB-INF/web.xml. Specify the following session-config:

</web-app>
   ...
    <session-config>
        <cookie-config>
            <comment>__SAME_SITE_NONE__</comment>
        </cookie-config>
    </session-config>
</web-app>

Re-build uberJar.
Note that this method works for CUBA gradle plugin from 7.2.9 version.

Regards,
Gleb

1 Like
#10

hi @shalyganov,

Trying to fix the issue with your suggested configuration.
When you mentioned CUBA gradle plugin from 7.2.9

Did u mean:

  • independent CUBA studio version
  • or IntelliJ IDE CUBA plugin

Sorry it’s been a while and CUBA has evolved to JMIX so a little hard for me to navigating among those 2.

#11

Another question please:
In case of using UberJar, where do I upgrade the Jetty version in order to have the same-site cookie in effect?

#12

Hi, @nghpham

It actually means that CUBA framework version from 7.2.9 should be used (ext.cubaVersion property in build.gradle file). Corresponding CUBA gradle plugin version will be applied automatically due to the following block:

    dependencies {
        classpath "com.haulmont.gradle:cuba-plugin:$cubaVersion"
    }

So, it is nothing to do with the IDE plugin.

When using CUBA > 7.2.9, UberJar will be generated using Jetty version that supports same-site cookie. Follow the step I described in the previous post for the cookie config to take effect.

Regards,
Gleb

#13

@shalyganov,

Thanks so much for the clarification