Now that the *app-authz-vanilla* resource server (or client) is properly configured and authorization services are enabled, it can be deployed to the server.
The project and code for the application you are going to deploy is available in link:{{book.quickstartRepo.link}}[{{book.quickstartRepo.name}}]. You will need the following
You can obtain the code by cloning the repository at {{book.quickstartRepo.link}}. The default branch corresponds to the latest release of {{book.project.name}}. Follow these steps to download the code.
. Click the *Installation* tab. From the Format Option dropdown list, select *Keycloak OIDC JSON*. The adapter configuration is displayed in JSON format. Click *Download*.
. (optional) By default, the policy enforcer responds with a `403` status code when the user lacks permission to access protected resources on the resource server. However, you can also specify a redirection URL for unauthorized users. To specify a redirection URL, edit the *keycloak.json* file you updated in step 3 and replace the `policy-enforcer` configuration with the following:
This change specifies to the policy enforcer to redirect users to a `/app-authz-vanilla/error.jsp` page if a user does not have the necessary permissions to access a protected resource, rather than an unhelpful `403 Unauthorized` message.
If your application was successfully deployed you can access it at http://localhost:8080/app-authz-vanilla[http://localhost:8080/app-authz-vanilla]. The {{book.project.name}} Login page opens.
The <<fake/../../../resource-server/default-config.adoc#_resource_server_default_config, default settings>> defined by {{book.project.name}} when you enable authorization services for a client application provide a simple
There are a plenty of things you can do now to test this application. For example, you can change the default policy by clicking the Authorization tab for the client, then `Policies` tab, then click on `Default Policy` in the list to allow you to change it as follows:
Let's fix that now, but instead of changing the `Default Policy` code we are going to change the `Logic` to `Negative` using the dropdown list below the policy code text area.
That re-enables access to the application as we are negating the result of that policy, which is by default denying all requests for access. Again, before testing this change, be sure to log out and log in again.
* Create a scope, define a policy and permission for it, and test it on the application side. Can the user perform an action (or anything else represented by the scope you created)?
* Create different types of policies such as <<fake/../../../policy/role-policy.adoc#_policy_rbac, role-based>>, <<fake/../../../policy/user-policy.adoc#_policy_user, user-based>>, <<fake/../../../policy/time-policy.adoc#_policy_time, time-based>>, <<fake/../../../policy/aggregated-policy.adoc#_policy_aggregated, aggregated policies>>, or <<fake/../../../policy/drools-policy.adoc#_policy_drools, rule-based>>, and associate these policies with the `Default Permission`.
* Apply multiple policies to the `Default Permission` and test the behavior. For example, combine multiple policies and change the `Decision Strategy` accordingly.
* For more information about how to view and test permissions inside your application see <<fake/../../../enforcer/authorization-context.adoc#_enforcer_authorization_context, Obtaining the Authorization Context>>.