== Obtaining the Authorization Context

When policy enforcement is enabled, the permissions obtained from the server are available through `org.keycloak.AuthorizationContext`.
This class provides several methods from where you can use to obtain permissions and check whether a permission was granted for a particular resource or scope.

Obtaining the Authorization Context in a Servlet Container
```java
    HttpServletRequest request = ... // obtain javax.servlet.http.HttpServletRequest
    KeycloakSecurityContext keycloakSecurityContext =
        (KeycloakSecurityContext) request
            .getAttribute(KeycloakSecurityContext.class.getName());
    AuthorizationContext authzContext =
        keycloakSecurityContext.getAuthorizationContext();
```

[NOTE]
Check the adapter configuration for more details about how you can obtain a `KeycloakSecurityContext`. The example above should be enough
to obtain the context when running an application using any of the servlet containers supported by {{book.project.name}}.

The authorization context helps give you even more control over the decisions taken and returned by the server. For instance, you can use it
to build a dynamic menu where the items are hidden/shown depending on the permissions associated with a resource or scope.

```java
if (authzContext.hasResourcePermission("Project Resource")) {
    // user can access the Project Resource
}

if (authzContext.hasResourcePermission("Admin Resource")) {
    // user can access administration resources
}

if (authzContext.hasScopePermission("urn:project.com:project:create")) {
    // user can create new projects
}
```

The `AuthorizationContext` represents one of the main capabilities of {{book.project.name}} {{book.project.module}}. From the examples above, you may notice that the protected resource is not
directly associated with the policies that govern them.

Consider some similar code using RBAC:

```java
if (User.hasRole('user')) {
    // user can access the Project Resource
}

if (User.hasRole('admin')) {
    // user can access administration resources
}

if (User.hasRole('project-manager')) {
    // user can create new projects
}
```

Although both examples address the same requirements, they do it in different ways. In RBAC, roles only _implicitly_ define access for their resources. With {{book.project.name}} you gain the capability to create more manageable code that focuses directly on your resources whether you are using RBAC, ABAC, or any other BAC variant. Either you have the permission for a given resource or scope, or you don't.

Now, suppose your security requirements have changed and beside project managers, PMOs can also create new projects.

Security requirements change, but with {{book.project.name}} you don't need to change your application code to address new requirements. Once your application is based on the resource and scope identifier,
 you need only change the configuration of the permissions or policies associated with a particular resource in the authorization server. In this case, we would change the permissions and policies associated with the `Project Resource` and/or the scope `urn:project.com:project:create`.