Repository: wicket Updated Branches: refs/heads/wicket-7.x 74aa7983f -> beb7421e7
Added documentation for external security checks Project: http://git-wip-us.apache.org/repos/asf/wicket/repo Commit: http://git-wip-us.apache.org/repos/asf/wicket/commit/beb7421e Tree: http://git-wip-us.apache.org/repos/asf/wicket/tree/beb7421e Diff: http://git-wip-us.apache.org/repos/asf/wicket/diff/beb7421e Branch: refs/heads/wicket-7.x Commit: beb7421e76ebad65245c7c12506a88a88c5f53d2 Parents: 74aa798 Author: Tobias Soloschenko <[email protected]> Authored: Sun Aug 28 16:43:52 2016 +0200 Committer: Tobias Soloschenko <[email protected]> Committed: Sun Aug 28 16:46:25 2016 +0200 ---------------------------------------------------------------------- .../src/docs/guide/security/security_6.gdoc | 55 +++++++++++++++----- .../src/docs/guide/security/security_7.gdoc | 14 +++++ wicket-user-guide/src/docs/guide/toc.yml | 3 +- 3 files changed, 57 insertions(+), 15 deletions(-) ---------------------------------------------------------------------- http://git-wip-us.apache.org/repos/asf/wicket/blob/beb7421e/wicket-user-guide/src/docs/guide/security/security_6.gdoc ---------------------------------------------------------------------- diff --git a/wicket-user-guide/src/docs/guide/security/security_6.gdoc b/wicket-user-guide/src/docs/guide/security/security_6.gdoc index 4ec812f..bbb0316 100644 --- a/wicket-user-guide/src/docs/guide/security/security_6.gdoc +++ b/wicket-user-guide/src/docs/guide/security/security_6.gdoc @@ -1,14 +1,41 @@ - - - In this chapter we have seen the components and the mechanisms that allow us to implement security policies in our Wicket-based applications. Wicket comes with an out of the box support for both authorization and authentication. - -The central element of authorization mechanism is the interface @IAuthorizationStrategy@ which decouples our components from any detail about security strategy. The implementations of this interface must decide if a user is allowed to instantiate a given page or component and if she/he can perform a given action on it. - -Wicket natively supports role-based authorizations with strategies @MetaDataRoleAuthorizationStrategy@ and @AnnotationsRoleAuthorizationStrategy@. The difference between these two strategies is that the first offers a programmatic approach for role handling while the second promotes a declarative approach using built-in annotations. - -After having explored how Wicket internally implements authentication and authorization, in the last part of the chapter we have learnt how to configure our applications to support HTTPS and how to specify which pages must be served over this protocol. - -In the last paragraph we have seen how Wicket protects package resources with a guard entity that allows us to decide which package resources can be accessed from users. - - - +Since Mozilla released their site to check if web pages have security issues named [Mozilla Observatory|https://observatory.mozilla.org] there are +a few things which can be done to get a high grade within this ranking without using further frameworks. + +Add a request cycle listener to your web application and adjust the headers to fit your requirements: +{code} +@Override +protected void init() +{ + super.init(); + + getRequestCycleListeners().add(new AbstractRequestCycleListener(){ + + @Override + public void onEndRequest(RequestCycle cycle) + { + ((WebResponse)cycle.getResponse()).setHeader("X-XSS-Protection", "1; mode=block"); + ((WebResponse)cycle.getResponse()).setHeader("Strict-Transport-Security", "max-age=31536000;" + + " includeSubDomains; preload"); + ((WebResponse)cycle.getResponse()).setHeader("X-Content-Type-Options", "nosniff"); + ((WebResponse)cycle.getResponse()).setHeader("X-Frame-Options", "DENY"); + ((WebResponse)cycle.getResponse()).setHeader("Content-Security-Policy", "default-src https:"); + } + }); +} +{code} + +Add this configuration to your web.xml (or let your server redirect to https): +{code:xml} +<?xml version="1.0" encoding="UTF-8"?> +<security-constraint> + <web-resource-collection> + <web-resource-name>Entire Application</web-resource-name> + <url-pattern>/*</url-pattern> + </web-resource-collection> + <user-data-constraint> + <transport-guarantee>CONFIDENTIAL</transport-guarantee> + </user-data-constraint> +</security-constraint> +{code} + +After this changes you have to check if your web application continues to work because it fits the requirements given with this header files. For example that resources must not requested from other domains anymore. \ No newline at end of file http://git-wip-us.apache.org/repos/asf/wicket/blob/beb7421e/wicket-user-guide/src/docs/guide/security/security_7.gdoc ---------------------------------------------------------------------- diff --git a/wicket-user-guide/src/docs/guide/security/security_7.gdoc b/wicket-user-guide/src/docs/guide/security/security_7.gdoc new file mode 100644 index 0000000..4ec812f --- /dev/null +++ b/wicket-user-guide/src/docs/guide/security/security_7.gdoc @@ -0,0 +1,14 @@ + + + In this chapter we have seen the components and the mechanisms that allow us to implement security policies in our Wicket-based applications. Wicket comes with an out of the box support for both authorization and authentication. + +The central element of authorization mechanism is the interface @IAuthorizationStrategy@ which decouples our components from any detail about security strategy. The implementations of this interface must decide if a user is allowed to instantiate a given page or component and if she/he can perform a given action on it. + +Wicket natively supports role-based authorizations with strategies @MetaDataRoleAuthorizationStrategy@ and @AnnotationsRoleAuthorizationStrategy@. The difference between these two strategies is that the first offers a programmatic approach for role handling while the second promotes a declarative approach using built-in annotations. + +After having explored how Wicket internally implements authentication and authorization, in the last part of the chapter we have learnt how to configure our applications to support HTTPS and how to specify which pages must be served over this protocol. + +In the last paragraph we have seen how Wicket protects package resources with a guard entity that allows us to decide which package resources can be accessed from users. + + + http://git-wip-us.apache.org/repos/asf/wicket/blob/beb7421e/wicket-user-guide/src/docs/guide/toc.yml ---------------------------------------------------------------------- diff --git a/wicket-user-guide/src/docs/guide/toc.yml b/wicket-user-guide/src/docs/guide/toc.yml index 537ae51..e3e0603 100644 --- a/wicket-user-guide/src/docs/guide/toc.yml +++ b/wicket-user-guide/src/docs/guide/toc.yml @@ -177,7 +177,8 @@ security: security_3: Using HTTPS protocol security_4: URLs encryption in detail security_5: Package Resource Guard - security_6: Summary + security_6: External Security Checks + security_7: Summary testing: title: Test Driven Development with Wicket testing_1: Utility class WicketTester
