LW-SSO limitations

The following limitations apply to LW-SSO authentication:

  • Client access to the application

    If a domain is defined in the LW-SSO configuration:

    • The application's clients must access the application with a fully qualified domain name (FQDN) in the login URL. For example, http://myserver.companydomain.com/WebApp

    • LW-SSO cannot support URLs with an IP address. For example, http://192.168.12.13/WebApp

    • LW-SSO cannot support URLs without a domain. For example,
      http://myserver/WebApp

      If a domain is not defined in the LW-SSO configuration. If a domain is not defined in the LW-SSO configuration, the client can access the application without a FQDN in the logon URL. Note that, in this case, a LW-SSO session cookie is created specifically for a single machine without any domain information, and, therefore, is not delegated by the browser to another, and does not pass to other computers located in the same DNS domain. This means that SSO will not work in the same domain.

  • LW-SSO framework integration

    Applications can leverage and use LW-SSO capabilities only if you integrate them within the LW-SSO framework in advance.

  • Multi domain support

    • Multi domain functionality is based on the HTTP referer. Therefore, LW-SSO supports links from one application to another and does not support typing a URL into a browser window, except when both applications are in the same domain.

    • The first cross-domain link that uses HTTP POST is not supported. Multi domain functionality does not support the first HTTP POST request to a second application (only the HTTP GET request is supported). For example, if your application has an HTTP link to a second application, an HTTP GET request is supported, but an HTTP FORM request is not supported. All requests after the first can be either HTTP POST or HTTP GET.

    • LW-SSO Token size. The amount of information that LW-SSO can transfer from one application in one domain to another application in another domain is limited to 15 Groups/Roles/Attributes. (Each item may be an average of 15 characters long.)

    • Linking from protected (HTTPS) to unprotected (HTTP) pages in a multi domain scenario. Multi domain functionality does not work when linking from a protected (HTTPS) to an unprotected (HTTP) page. This is a browser limitation where the referer header is not sent when linking from a protected to a non-protected resource.

    • Third-party cookie behavior in Internet Explorer

      Microsoft Internet Explorer 6 contains a module that supports the "Platform for Privacy Preferences (P3P) Project", which means that cookies coming from a third party domain are blocked by default in the Internet security zone. Internet Explorer also treats session cookies as third-party cookies. These are therefore blocked, which causes LW-SSO to stop working.

      To solve this issue and make sure that cookies are accepted, add the launched application (or a DNS domain subset as *.<mydomain>.com) to the Intranet/Trusted zone on your computer. (In Microsoft Internet Explorer, select Menu > Tools > Internet Options > Security > Local Intranet > Sites > Advanced.)

      Note: The LW-SSO session cookie is only one of the cookies used by third-party applications that are blocked.

    • Multi domain functionality is based on the HTTP referer. Therefore, LW-SSO supports links from one application to another and does not support typing a URL into a browser window, except when both applications are in the same domain.

    • The first cross-domain link that uses HTTP POST is not supported. Multi domain functionality does not support the first HTTP POST request to a second application (only the HTTP GET request is supported). For example, if your application has an HTTP link to a second application, an HTTP GET request is supported, but an HTTP FORM request is not supported. All requests after the first can be either HTTP POST or HTTP GET.

    • LW-SSO Token size. The amount of information that LW-SSO can transfer from one application in one domain to another application in another domain is limited to 15 Groups/Roles/Attributes. (Each item may be an average of 15 characters long.)

    • Linking from protected (HTTPS) to unprotected (HTTP) pages in a multi domain scenario. Multi domain functionality does not work when linking from a protected (HTTPS) to an unprotected (HTTP) page. This is a browser limitation where the referer header is not sent when linking from a protected to a non-protected resource.

    • Third-party cookie behavior in Internet Explorer

      Microsoft Internet Explorer 6 contains a module that supports the "Platform for Privacy Preferences (P3P) Project", which means that cookies coming from a third party domain are blocked by default in the Internet security zone. Internet Explorer also treats session cookies as third-party cookies. These are therefore blocked, which causes LW-SSO to stop working.

      To solve this issue and make sure that cookies are accepted, add the launched application (or a DNS domain subset as *.<mydomain>.com) to the Intranet/Trusted zone on your computer. (In Microsoft Internet Explorer, select Menu > Tools > Internet Options > Security > Local Intranet > Sites > Advanced.)

      Note: The LW-SSO session cookie is only one of the cookies used by third-party applications that are blocked.

  • SAML2 token

    • Logout functionality is not supported if the SAML2 token is used. Therefore, if the SAML2 token is used to access a second application, then a user who logs out of the first application is not logged out of the second application.

    • The SAML2 token's expiration is not reflected in the application's session management. Therefore, if the SAML2 token is used to access a second application, then each application's session management is handled independently.

  • JAAS Realm

    The JAAS Realm in Tomcat is not supported.

  • Using spaces in Tomcat directories

    Using spaces in Tomcat directories is not supported. You cannot use LW-SSO if the Tomcat installation path includes spaces (for example, \Program Files\) and the LW-SSO configuration file resides in the common\classes Tomcat folder.

  • Load balancer configuration

    A load balancer deployed with LW-SSO must be configured to use sticky sessions.

  • Demo mode

    In Demo mode, LW-SSO supports links from one application to another but, because there is no HTTP referer header, does not support typing a URL into a browser window.