From 55b0f102b0363662613897e70e5735a261e4ecd6 Mon Sep 17 00:00:00 2001 From: WalkerWatch Date: Wed, 27 Sep 2017 14:37:39 -0400 Subject: [PATCH] Adding authorization examples for #1850. --- .../configuring/security/authentication.adoc | 94 ++++++++++++++++--- 1 file changed, 83 insertions(+), 11 deletions(-) diff --git a/jetty-documentation/src/main/asciidoc/configuring/security/authentication.adoc b/jetty-documentation/src/main/asciidoc/configuring/security/authentication.adoc index 5e27fd9cb7f..c03b18258ae 100644 --- a/jetty-documentation/src/main/asciidoc/configuring/security/authentication.adoc +++ b/jetty-documentation/src/main/asciidoc/configuring/security/authentication.adoc @@ -362,28 +362,100 @@ You define a `JDBCLoginService` with the name of the realm and the location of t [source, xml, subs="{sub-order}"] ---- - Test JDBC Realm etc/jdbcRealm.properties - ---- ==== Authorization -As far as the http://jcp.org/aboutJava/communityprocess/final/jsr340/[Servlet Specification] is concerned, authorization is based on roles. -As we have seen, a LoginService associates a user with a set of roles. -When a user requests a resource that is access protected, the LoginService will be asked to authenticate the user if they are not already, and then asked to confirm if that user possesses one of the roles permitted access to the resource. +As far as the https://jcp.org/en/jsr/detail?id=340[Servlet Specification] is concerned, authorization is based on roles. +As we have seen, a `LoginService` associates a user with a set of roles. +When a user requests a resource that is access protected, the `LoginService` will be asked to authenticate the user if they are not already, and then asked to confirm if that user possesses one of the roles permitted access to the resource. Until Servlet 3.1, role-based authorization could define: -* Access granted to a set of named roles -* Access totally forbidden, regardless of role -* Access granted to a user in any of the roles defined in the effective web.xml. -This is indicated by the special value of `*` for the `` of a `` in the `` +* Access granted to a set of named roles: -With the advent of Servlet 3.1, there is now another authorization: +[source, xml, subs="{sub-order}"] +---- + + + Foo Admin Data + /foo/admin/* + + + admin + manager + + +---- + +* Access totally forbidden, regardless of role: + +[source, xml, subs="{sub-order}"] +---- + + + Foo Protected Data + /foo/protected/* + + + + +---- +* Access granted to a user in any of the roles defined in the effective `web.xml`. +This is indicated by the special value of `*` for the `` of a `` in the ``: + +[source, xml, subs="{sub-order}"] +---- + + + Foo Role Data + /foo/role/* + + + * + + +---- + +Servlet 3.1 introduced an additional authorization: * Access granted to any user who is authenticated, regardless of roles. -This is indicated by the special value of `**` for the `` of a `` in the `` +This is indicated by the special value of `**` for the `` of a `` in the ``: + +[source, xml, subs="{sub-order}"] +---- + + + Foo Authenticated Data + /foo/authenticated/* + + + ** + + +---- + +Additionally, when configuring your security constraints you can protect various HTTP methods as well, such as `PUT`, `GET`, `POST`, `HEAD` or `DELETE`. +This is done by adding the method you want to protect as a `` in the ``. +You can then define roles that should be able to perform these protected methods in an ``: + +[source, xml, subs="{sub-order}"] +---- + + + Foo Authenticated Data + /foo/authenticated/* + DELETE + POST + + + admin + + +---- + +In the above example, only users with an `admin` role will be able to perform `DELETE` or `POST` methods.