Chatta subito con l'assistenza
Chat con il supporto

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

Client issues with security

Cookies

Unlike some Web SSO implementations, Single Sign-on for Java does not use cookies to store encrypted passwords. Instead, it relies on the caching of Kerberos tickets to provide SSO functions. For Microsoft Windows clients, these credentials are stored in memory, and never written to disk, so the chance of compromise is very low. However, cookies are commonly used to store session ID state. For more information, see Session IDs..

Because authentication in Single Sign-on for Java is bound to the session state, these cookies present a security risk if they are leaked or sent in clear across the network. This means that communication between the browser and application server should always be done via SSL to protect session IDs.

Most application servers use transient cookies for tracking session state, with the browser only keeping them in memory, without writing them to disk. This means there is a low risk of compromise of session ID information from the client.

Alternatively, you may want to develop your applications to use URL rewriting instead of cookies for session state. This has the advantage that it works for all browsers, regardless of whether they have cookies enabled or not.

Caching of passwords for basic fallback

For non-Internet Explorer clients, or clients that do not support Kerberos, Single Sign-on for Java provides a mechanism for authenticating via the standard basic HTTP authentication mechanism. This sends a password in clear over HTTP, which is then used by the Single Sign-on for Java-protected Filter/Servlet to perform a standard Kerberos authentication. Because most clients support password managers and/or caching of passwords when using basic authentication, care should be taken to ensure that this information is not leaked or sent over the network. Again, this means ensuring that the password is not saved on a network volume, and that authentication should be done over SSL. For more information, see Basic fallback. Consult your browser documentation to ensure that it is configured appropriately.

SPNEGO/Windows authentication

Single Sign-on for Java uses the SPNEGO protocol to perform Windows Integrated Authentication via HTTP. This protocol uses the Kerberos GSS-API protocol to mutually authenticate clients and servers via HTTP headers. While the GSS-API protocol itself is secure, this protocol does not ensure that the content of the HTTP request is securely bound to the message. This means that a man-in-the-middle attack could be used to modify the HTTP content while keeping the authentication headers intact. For this reason, unless the risk is very low, you should ensure that authentication is done over SSL.

Related Documents

The document was helpful.

Seleziona valutazione

I easily found the information I needed.

Seleziona valutazione