Saml add-on Failed to determinate SAML connection

Add-ons
#1

Hi CUBA team,

I’m using saml-addon and followed the instruction on this link to setup SSO with Azure AD

Everything looks good, I’m able to login using my AD account. However, few of my team members got the below error:

HTTP ERROR 500
Problem accessing /roadway/saml/login. Reason:

Server Error

Caused by:
java.lang.RuntimeException: Failed to determinate SAML connection
at com.haulmont.addon.saml.saml.internal.impl.SamlConnectionContextProviderImpl.populateConnection(SamlConnectionContextProviderImpl.java:157)
at com.haulmont.addon.saml.saml.internal.impl.SamlConnectionContextProviderImpl.getLocalAndPeerEntity(SamlConnectionContextProviderImpl.java:130)
at org.springframework.security.saml.SAMLEntryPoint.commence(SAMLEntryPoint.java:145)
at org.springframework.security.saml.SAMLEntryPoint.doFilter(SAMLEntryPoint.java:106)
at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:331)
at org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:214)
at org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:185)
at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:331)
at org.springframework.security.web.header.HeaderWriterFilter.doFilterInternal(HeaderWriterFilter.java:66)
at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:331)
at org.springframework.security.web.context.request.async.WebAsyncManagerIntegrationFilter.doFilterInternal(WebAsyncManagerIntegrationFilter.java:56)
at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:331)
at org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:105)
at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:331)
at org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:214)
at org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:177)
at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:347)
at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:263)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
at org.springframework.web.filter.CompositeFilter$VirtualFilterChain.doFilter(CompositeFilter.java:107)
at com.haulmont.addon.saml.web.security.saml.SamlLoginHttpRequestFilter.doFilter(SamlLoginHttpRequestFilter.java:81)
at org.springframework.web.filter.CompositeFilter$VirtualFilterChain.doFilter(CompositeFilter.java:112)
at org.springframework.web.filter.CompositeFilter.doFilter(CompositeFilter.java:73)
at com.haulmont.cuba.web.sys.CubaHttpFilter.doFilter(CubaHttpFilter.java:107)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
at org.eclipse.jetty.server.Server.handle(Server.java:499)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:311)
at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:258)
at org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:544)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
at java.lang.Thread.run(Thread.java:748)

That happened as soon as they hit SSO dropdown and change the value, it didn’t bring up the login form.

I dig into the code and notice the exception was from this class: SamlConnectionContextProviderImpl

  protected void populateConnection(HttpServletRequest request, HttpServletResponse response, SAMLMessageContext context) {
        if (context instanceof SamlConnectionMessageContext) {
            String code = (String) request.getSession().getAttribute(SamlSessionPrincipal.SAML_CONNECTION_CODE);
            if (StringUtils.isEmpty(code)) {
                String[] params = request.getParameterMap().get(SamlSessionPrincipal.SAML_CONNECTION_CODE);
                if (params != null && params.length > 0) {
                    code = params[0];
                }
                if (!StringUtils.isEmpty(code)) {
                    request.getSession().setAttribute(SamlSessionPrincipal.SAML_CONNECTION_CODE, code);
                }
            }
            if (StringUtils.isEmpty(code)) {
                throw new RuntimeException("Failed to determinate SAML connection");
            }
            ((SamlConnectionMessageContext) context).setConnectionCode(code);
        }
    }

Still have no idea what seem to be the problem, any idea would be much appreciated

Thanks

#3

Hi @nghiapht1990

it seems like the request does not have saml connection attribute ‘tenant’, that’s why the program could not determine saml connection.
Please, check that in your login screen you are setting this value to session. You could find an example in demo project, line 99 in login screen (link).
If possible, you could share login screen page code for investigating.

Regards,
Mikhail

#4

Hi @strokov ,

I followed the github instruction from that link. Below is a piece of code for login screen:

@Override
    public void init(Map<String, Object> params) {
        super.init(params);

        uiAccessor = backgroundWorker.getUIAccessor();

        ssoLookupField.setOptionsList(getActiveConnections());
//        ssoLookupFieldLabel.setVisible(!CollectionUtils.isEmpty(ssoLookupField.getOptionsList()));
        ssoLookupField.setVisible(!CollectionUtils.isEmpty(ssoLookupField.getOptionsList()));
        ssoLookupField.addValueChangeListener(e -> {
            if (e.getValue() != null) {
                SamlConnection connection = (SamlConnection) e.getValue();
                VaadinSession.getCurrent().getSession().setAttribute(SamlSessionPrincipal.SAML_CONNECTION_CODE, connection.getSsoPath());
                Page.getCurrent().setLocation(getLoginUrl());
            }
            ssoLookupField.setValue(null);
        });
    }

As you see, it does have the line that set that attribute.

#5

Hi @nghiapht1990,

I hazard a guess that probably you have custom filters or interceptors for catching request for redirecting to MS, doing some manipulations which could affect session attributes. Please, check it. (too hard to analyze w/o code 'cause it’s working with 3rd party).

Regards,
Mikhail

#6

Hi @strokov,

Thanks a lot for your time. Actually that was my mistake when I used 2 different domains pointing to the same instance of application. The second domain was configed inside web-app.properties and may have messed up the session attribute. I corrected and that worked.

Thanks again for your support.

1 Like
#8

@strokov , recently I got this issue again but with different scenario.

First time I tried to log in -> successfully
Everything was fine if I kept the logged in session.
However,
if I logged out (after 60s logged in) then logged in again, then the exception came out.
if I logged out (within 60s after logged in) then logged in again, then the exception didn’t happen.

After the exception, If I go back with the home page then login, it went through.

I already double checked and made sure I’m using the consistent domain.

Any idea would be appreciated.

More info:
CUBA Platform version: platform-6.10.10
SAML addon version: com.haulmont.addon.saml:saml-addon-global:0.1.2

#10

Hi, @nghiapht1990

Could you please clarify whether you get the same exception that was mentioned in the first post? It is happened after you choose a value from the SSO dropdown list?
If yes, then it is occurred because of a session does not have attribute tenant specified. As it was mentioned earlier, you can check whether your application has some custom filters that could affect session attributes. Could you please also check the logs, maybe there was another exception that led to the error? Finally, i would recommend you to verify the settings of your Azure AD account.

Regards,
Gleb

#14

Thanks @shalyganov for the response.

  • I checked the custom filters and found nothing else.

  • checked log and found the same exception similar to my first post:
    Caused by:
    java.lang.RuntimeException: Failed to determinate SAML connection
    at com.haulmont.addon.saml.saml.internal.impl.SamlConnectionContextProviderImpl.populateConnection(SamlConnectionContextProviderImpl.java:157)
    at

  • most likely that was because the Azure AD account setting. And that was the only external thing I wasn’t aware of. The same code was working previously. I’ll try to do more investigation on this. Thanks for the good point.

#15

If you go to the browser and clear cookies for your site it most likely that exception will go away. Very weird bug. That helped me to fix it.
But I cannot fix it for 500 users that get the same error :frowning:

#16

@rvaleev there were 2 issues I got and mentioned in this post:

1/ I used diff domain pointing to the same instance of CUBA, however inside the CUBA web-app.properties I could just used 1 for cuba.webAppUrl. Then this somehow messed up the cookies. My work-around was just use 1 domain instead then I was able to fix it.

2/ The second issue was the symptom I mentioned on March 26, it happened with the second attempt to login after 60s. And the root cause I figured out was a network layer standing between my end user and the application server. That somehow was configured and have the cookies expired earlier then it was supposed to be. That could be a load-balancer or a firewall or a VPN. I wan’t very good at network stuff so I talked to network guys and problem solved.

Hope that help

#18

Hi,

The root cause of this problem comes from the recent security update in Chrome (i described it in the related topic). To fix it, SameSite=None; Secure cookie policy should be used. Unfortunately, it is impossible with the current versions of Tomcat and Jetty used in Cuba plugin, but we are planning to update them in the next bugfix release.

Regards,
Gleb

1 Like