지금 지원 담당자와 채팅
지원 담당자와 채팅

Single Sign-On for Java 3.3.2 - Administration Guide

About this guide Introducing Single Sign-on for Java Preparing for Single Sign-on for Java Deploying Single Sign-on for Java
Getting started with Single Sign-on for Java Single Sign-on for Java and your web applications Setting up logging Controlling access to resources
Security Issues Maintenance and Troubleshooting Appendix: Configuration Parameters Appendix: Using the JKTools

Non-Internet Explorer browsers

Problem:

When using a non-Internet Explorer browser, rather than presenting a username and password dialog box, the browser gives an error message indicating that the authentication mechanism is not supported.

Cause:

The filter has not been configured to allow fallback authentication for non-Internet Explorer browsers.

Resolution:

You need to ensure that the filter is configured with the idm.allowFallback option set to true. Without this, non-Internet Explorer browsers are not supported.

Authentication

Problem:

Servlet/JSP configured with AuthFilter fails to start.

This is commonly caused by a configuration problem with the AuthFilter filter. You need to check your application server’s log file to determine the root cause. Possible log entries are:

  • ServletException: Need to set idm.realm.

    The idm.realm parameter determines the Kerberos realm that will be use by the SSO solution to authenticate clients. It must be set in the deployment descriptor.

  • ConfigException: Only one of “idm.keytab” or “com.wedgetail.idm.sso.password” should be specified.

    Only one of idm.keytab or com.wedgetail.idm.sso.password may be specified. For production systems, idm.keytab is to be preferred.

  • ConfigException: Must configure either idm.keytab or com.wedgetail.idm.sso.password.

    The deployer must specify one or the other — with keytab preferred for production systems.

  • Config Exception: Must use a keytab if idm.allowFallback configured.

    The idm.allowFallback parameter allows the deployer to specify whether the AuthFilter filter should allow users to authenticate using basic authentication and act as an authentication proxy to perform a Kerberos login to the key distribution center on the user's behalf. If fallback mode is enabled, then user-to-service mode must be used, and hence a keytab must be specified via the idm.keytab parameter, or the keytab password specified by the com.wedgetail.idm.sso.password system property.

  • ConfigException: <keytab> not found

    The keytab specified by idm.keytab could not be loaded. The keytab must be at the path specified. Ensure that the file is present and that the correct path and file name is specified in the idm.keytab parameter.

  • ConfigException: No keytab entries for <principal>@<realm> in <keytab>

    The specified keytab did not contain any keys for the principal that was configured using idm.principal and idm.realm. If idm.principal was not specified then entry will be of the form:

    HTTP/<host.domain>@<realm>

    Where <host> is the fully qualified name of the host on which the filter is deployed.

    You can use the Kerberos klist command to check the keytab entries. Under UNIX this command is supplied as part of the Kerberos distribution and under Windows is supplied with JDK 1.4. Ensure that there is an entry for the specified principal.

  • ConfigException: Could not load keytab “<keytab>”

    The keytab could not be loaded for some reason. Possibly this was due to corruption, or an incorrectly formatted file.

  • ConfigException: Invalid KDC host “<kdc>”
  • The hostname for the key distribution center specified by the parameter idm.kdc is invalid. Ensure that the correct hostname is supplied.

  • ProtocolException: Could not get service ticket for principal name [caused by: com.dstc.security.kerberos.CryptoException: Integrity check failure]

    The realm specified in idm.realm is case-sensitive and is usually uppercase. If the case does not match, the DES keys for the service will be incorrect, as they are derived from the fully-qualified principal name.

  • Filter could not be loaded: com.dstc.security.util.licensing.InvalidLicense: Error verifying license: Cannot open resource jcsi.licensing.cert.pem

    The licensing code can not find a license, either because it has not been installed, or Java 2 Security has been enabled, without a suitable policy file.

Problem:

Why is Internet Explorer trying to do NTLM?

Cause:

Single Sign-on for Java is designed to work with Windows Integrated Authentication using Kerberos. However, if your browser or Active Directory is not configured correctly this will fail, and Internet Explorer will attempt to fallback to NTLM authentication.

If you have NTLM disabled in Single Sign-on for Java you may be presented with a username/ password dialog, and you will see the following message in the error log:

Could not authorize request: com.wedgetail.idm.sso.NtlmNegotiatedException

Generally, fallback to NTLM will occur for one of the following reasons:

  • You are using a browser which does not support Kerberos.
  • You are not logged in to the domain.
  • You are trying to connect from a browser on the same host as that on which the application server is running.
  • The Service Principal Name (SPN) is not correctly mapped to the service account used by Single Sign-on for Java.
  • Internet Explorer is not configured properly. In particular, the site you are connecting to is not considered part of the Intranet Zone. You also need to ensure that Windows Integrated Authentication is enabled.

One way to test whether it is either of the latter two possibilities is to install a packet sniffer. One Identity recommends Wireshark (http://www.wireshark.org). If SPN mapping for Single Sign-on for Java is not correct, Wireshark should provide the following output:

HTTPresponse 401 Unauthorized

KRB_AP_REQ

KRB_AP_REP (Indicating a Kerberos Error)

HTTP request with the broken negotiate header.

If you are certain the SPN has been correctly set up, send the Wireshark trace to https://support.oneidentity.com/ and one of our experienced support engineers will assist you in identifying the problem.

If your browser has not been configured correctly as explained above, no Kerberos traffic will be visible in the Wireshark trace.

Keytabs

Problem:

When using a keytab I get Could not verify PAC in auth data

Cause:

When generating a keytab using ktpass the default key type is DES-CBC-CRC. There is a known problem using these types of keys.

Resolution:

You must specify -crypto DES-CBC-MD5 when generating the keytab.

Problem:

I am getting a No keytab entry for decrypting. Data encrypted with key type 23... message.

Cause:

This error is caused when the keytab used contains only DES keys but the account is not set to Use DES only.

Resolution:

This can be fixed by either adding an RC4 key to the keytab, or setting the user account to Use DES only.

Network connections

Problem:

When attempting to connect to a URL protected by the filter you receive an error message: 403 Forbidden This Connection Must be secured.

Cause:

By default, Single Sign-on for Java requires that communications be performed securely (for example using HTTPS).

There are two reasons for this:

  • Once a session is authenticated, the filter does not require authentication for subsequent requests using the same session ID. If it were, this would require an extra round-trip (or in some cases, two) to authenticate each request. However, this means an attacker who is able to sniff the session ID would be able to hijack an authenticated session. Note: even if every request were authenticated, the SPNEGO protocol does not tie any of the content in the HTTP request to the authentication information, so an active attacker could still hijack session requests.
  • If the fallback mechanism is supported for non-Internet Explorer browsers, Kerberos usernames and passwords are sent unprotected over the network.
Resolution:

One Identity strongly recommends using SSL to secure communications for these reasons. However, should you wish to use the SSO solution to authenticate clients over unprotected connections (for example, for testing, or where there is a very low risk of attackers hijacking sessions), you may set the idm.allowUnsecured option to true.

관련 문서

The document was helpful.

평가 결과 선택

I easily found the information I needed.

평가 결과 선택