[JIRA] Updated: (JSPT-1) Add support for reading and writing secure HTTP cookies

[Chad La Joie (JIRA)]

     [ https://issues.shibboleth.net/jira/browse/JSPT-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Chad La Joie updated JSPT-1:
----------------------------

    Fix Version/s: 1.1.0

> Add support for reading and writing secure HTTP cookies
> -------------------------------------------------------
>
>                 Key: JSPT-1
>                 URL: https://issues.shibboleth.net/jira/browse/JSPT-1
>             Project: Java Support
>          Issue Type: New Feature
>          Components: net
>            Reporter: Chad La Joie
>            Assignee: Chad La Joie
>             Fix For: 1.1.0
>
>   Original Estimate: 3 days
>  Remaining Estimate: 3 days
>
> Add support for reading and writing secure HTTP cookies based on the following Shib dev email:
> So, an issue that comes up now and again with IdPv2 is its use of
> cookies.  As the plan is to use cookies more in IdPv3, as a means of
> carrying longer-term state, I wanted to post my current thinking.  I
> recommend anyone who really cares about this reads RFC6256[1] first.
> Also, most of these items are interrelated in various ways so read
> through the whole mail (probably a couple times) before commenting.
> - Cookie names will be determined by a naming strategy and will
> contain a 2-digit numeric suffix used for ordering the cookies when
> they are sent back to the server
> - If the value of a cookie would exceed 4k, the value will be chunked
> and distributed across multiple cookies
> - The cookie will use the Expires attribute (as opposed to Max-Age) to
> convey the expiration time (if any)
> - The cookie will use the server's hostname, or a configured hostname,
> as the value for the Domain attribute
> - The cookie will use the Servlet's context path, or a configured
> path, as the value of the Path attribute
> - The cookie will set the Secure attribute if the scheme of the
> request is HTTPS; a configuration option will be available to disable
> setting this attribute
> - The cookie will set the HttpOnly attribute; a configuration option
> will be available to disable setting this option
> - In addition to the value given for the cookie, the following
> information may also (indicated by configuration options) be encoded
> into the cookie value: user agent IP, cookie domain, server port,
> Servlet context path, whether the cookie was sent to the user agent
> over a secure transport, a signature.
> - If the cookie is signed the signature will be over the user supplied
> value, the previously mentioned additional data, and an indicator that
> the content was signed
> - The whole cookie value string may be encrypted
> - Upon receipt of the cookie the service may, as determined by
> configuration, check:
>   - that the user agent IP address matches the IP encoded in the cookie value
>   - that the server host that received the cookie matches, or is a
> subdomain, the domain encoded in the cookie value
>   - that the server port that received the cookie is the same as the
> port encoded in the cookie value
>   - that the request path is the same as, or a subpath, of the path
> encoded in the cookie value
>   - that if the cookie was returned over HTTPS if it was provided to
> the user agent over HTTPS
>   - that the cookie was signed
>   - that the cookie signature is valid
> Many of the previously mentioned checks are, in theory, performed by
> the user-agent.  However, as noted in RFC6265, there are ways to
> circumvent these features.  When the server performs the checks, it
> can at least protect itself from some forms of attack.  If there are
> additional checks that could be performed, feel free to suggest them.
> [1] http://tools.ietf.org/html/rfc6265

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira