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, we continued with how to configure our applications to support HTTPS and how to specify which pages must be served over this protocol.

We've explored the protection Wicket offers against CSRF attacks with URL encryption and the _ResourceIsolationRequestCycleListener_, or the (now deprecated) __CsrfPreventionRequestCycleListener__. This was followed by an explanation of the Content Security Policy used by Wicket and how to tune this for your application. We've also explained Cross-Origin Opener Policy and Cross-Origin Embedder policy to achieve cross-origin isolation, and how to configure the policies for your application.

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.
