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.
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.
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.
© ALL RIGHTS RESERVED. Feedback 이용 약관 개인정보 보호정책 Cookie Preference Center
