Hi Jamey,
Jamey Wood wrote:
> When using container-managed authentication for a web application,
> GlassFish uses a "JSESSIONIDSSO" cookie to manage SSO. Is there any
> configuration setting which will control whether or not this cookie is
> set with the "secure" flag?
>
> The behavior I've witnessed is that the cookie will automatically be
> set as "secure" if the HTTP request came via a secure connection, and
> not if it didn't. This is certainly a reasonable default, but it'd be
> nice to have the ability to override it in special circumstances. (In
> our case, we want to ensure that SSO works on HTTP pages even when the
> initial login occurred via HTTPS.)
>
> In GlassFish's org.apache.catalina.authenticator.AuthenticatorBase, I
> see:
>
> String value = generateSessionId();
> Cookie cookie = new Cookie(Constants.SINGLE_SIGN_ON_COOKIE, value);
> cookie.setMaxAge(-1);
> cookie.setPath("/");
> cookie.setSecure(hreq.isSecure());
> hres.addCookie(cookie);
>
> So it appears that the only way to force it into a 'setSecure(false)'
> case would be if we could force our HttpServletRequest to return false
> for the isSecure call. I believe that's possible in Tomcat (setting
> 'secure="false"' in server.xml, as documented at
> http://tomcat.apache.org/tomcat-5.5-doc/config/http.html).
Sounds like a hack. :)
> Is there any similar setting in GlassFish? (In other words, is
> there a way to force isSecure() to return false for an
> HttpServletRequest even if it really is HTTPS?) Or is there some
> other approach that could handle this scenario?
You can specify a number of cookie properties in your sun-web.xml,
including "cookiePath", "cookieDomain", and "cookieComment".
Example:
<sun-web-app>
<session-config>
<cookie-properties>
<property name="cookiePath" value="/" />
<property name="cookieDomain" value="mydomain.com" />
<property name="cookieComment" value="some comment" />
</cookie-properties>
</session-config>
</sun-web-app>
These properties allow you to override the default cookie properties
assigned to your webapp's cookies by the container.
An additional cookie configuration property was recently added, but is
currently being ignored: "isSecure", whose possible values are "dynamic",
"true", and "false".
In the case of "dynamic", the cookie inherits its "secure" setting from
the request, as you have seen in AuthenticatorBase.java:
cookie.setSecure(hreq.isSecure());
However, this behaviour may be overridden (once item 1. from below has been
fixed) by setting the "isSecure" cookie property in sun-web.xml to
"true" or "false",
in which case your webapp's cookies will be marked as secure or not secure,
respectively. I think this is what you are looking for.
One additional problem is that, currently, the above cookie properties are
considered only for JSESSIONID, and not for JSESSIONIDSSO cookies.
So in summary, there are 2 issues we need to fix in GlassFish:
1. Consider the "isSecure" cookie property in sun-web.xml.
2. Consider the cookie-properties from sun-web.xml not only for JSESSIONID,
but also JSESSIONIDSSO cookies.
Does this answer your question?
If so, please feel free to file an RFE on this.
Thanks,
Jan
>
> Thanks,
> Jamey
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>