Hi folks,
Another suggestion we had from public draft was to use some of the
servlet security annotations to define security on an endpoint.
(
http://java.net/jira/browse/WEBSOCKET_SPEC-81)
Currently, as you will know, we are allowing websocket developers to
leverage web container security by providing a <security-constraint> in
the web.xml to limit access on the endpoint to certain users and
confidentiality level. This I think will work well for the basic use
cases, and will be somewhat natural to web developers. I've added an
example to the spec document for clarity.
The request here was to allow websocket developers to annotate their
endpoint with the servlet security annotations. Looking at these, it
looks like the most appropriate application would be to take the
HttpConstraint
(
http://docs.oracle.com/javaee/6/api/javax/servlet/annotation/HttpConstraint.html)
and allow it at the class level of an endpoint.
Something like
@HttpConstraint(
rolesAllowed="gold_users", "platinum_users"
)
I think it could work, even while the naming is clearly awkward.
But I think I would like this version of the spec to be conservative in
this area. We already have a basic mechanism, via the web.xml and
websocket security seems to be an evolving area.
I'd like to leave the design of security annotations to a later version,
when we have had time to see more use cases, which might inform the
design of annotations best suited to websockets. Such designs might not
be easy to shoe-horn back into servlet-based annotations if we went with
that now.
Let me know if anyone has a strong preference to the contrary,
Thanks,
- Danny
--
<http://www.oracle.com> *Danny Coward *
Java EE
Oracle Corporation