Troubleshooting and Limitations - LW-SSO Authentication

This section describes known issues and limitations when working with LW-SSO authentication.

Known Issues

This section describes known issues for LW-SSO authentication.

• Security context. The LW-SSO security context supports only one attribute value per attribute name.

  Therefore, when the SAML2 token sends more than one value for the same attribute name, only one value is accepted by the LW-SSO framework.

  Similarly, if the IdM token is configured to send more than one value for the same attribute name, only one value is accepted by the LW-SSO framework.

• Multi-domain logout functionality when using Internet Explorer 7. Multi-domain logout functionality may fail under the following conditions:

  • The browser used is Internet Explorer 7 and the application is invoking more than three consecutive HTTP 302 redirect verbs in the logout procedure.

  In this case, Internet Explorer 7 may mishandle the HTTP 302 redirect response and display an Internet Explorer cannot display the webpage error page instead.

  As a workaround, it is recommended to reduce, if possible, the number of application redirect commands in the logout sequence.

Limitations

Note the following limitations when working with LW-SSO authentication:

• Client access to the application.

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

  • The application clients must access the application with a Fully Qualified Domain Name (FQDN) in the login URL, for example, http://myserver.companydomain.com/WebApp.

    Note The length of the FQDN cannot be longer than the value of the Maximum domain extension length setting in the Infrastructure Settings Manager. The default value is 8.

  • 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: The client can access the application without a FQDN in the login URL. In this case, a LW-SSO session cookie is created specifically for a single machine without any domain information. Therefore, the cookie is not delegated by the browser to another, and does not pass to other computers located in the same DNS domain. This means that LW-SSO does not work in the same domain.

• LW-SSO framework integration. Applications can leverage and use LW-SSO capabilities only if integrated within the LW-SSO framework in advance.

• Multi-Domain Support.

  • Multi-domain functionality is based on the HTTP referrer. 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 using 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 size 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 (note that each item may be an average of 15 characters long).

  • Linking from Protected (HTTPS) to non-protected (HTTP) in a multi-domain scenario:

    Multi domain functionality does not work when linking from a protected (HTTPS) to a non-protected (HTTP) page. This is a browser limitation where the referrer header is not sent when linking from a protected to a non-protected resource. For an example, see: http://support.microsoft.com/support/kb/articles/Q178/0/66.ASP

  • Third-Party cookie behavior in Internet Explorer:

    Microsoft Internet Explorer 6 contains a module that supports the "Platform for Privacy Preferences (P3P) Project," meaning that cookies coming from a Third Party domain are blocked by default in the Internet security zone. Session cookies are also considered Third Party cookies by IE, and therefore are blocked, causing LW-SSO to stop working. For details, see: http://support.microsoft.com/kb/323752/en-us.

    To solve this issue, 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), which causes the cookies to be accepted.

    Caution The LW-SSO session cookie is only one of the cookies used by the Third Party application that is blocked.

• SAML2 token

  • Logout functionality is not supported when the SAML2 token is used.

    Therefore, if the SAML2 token is used to access a second application, 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, 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.

  It is not possible to use LW-SSO when a Tomcat installation path (folders) includes spaces (for example, Program Files) and the LW-SSO configuration file is located 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 does not support typing a URL into a browser window, due to an HTTP referrer header absence in this case.