authorization_matrix

15 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

Authorization matrix two-dimensional model

An authorization matrix typically contains two elements or dimensions: the Feature and the Logical Role that accesses it. Sometimes a third dimension named Data is added to define access that includes filtering at business data level. The logical roles in authorization testing are sometimes called a Point Of View (POV).

Authorization matrix XML structure for REST services

The authorization matrix in XML format contains three main sections: the roles node describes logical roles and their authorization levels; the services node lists available services exposed by the system with their URI, HTTP method, associated logical roles, and HTTP response codes for allowed (http-response-code-for-access-allowed) and denied (http-response-code-for-access-denied) access; the services-testing node provides test payloads for each service that uses input data other than URL or path parameters. Placeholders between curly braces mark locations where test values must be inserted by integration tests.

Authorization matrix formalization requirements

Before automating authorization matrix tests, the matrix must be formalized in a pivot format file (such as XML) to: allow easy programmatic processing; allow humans to read and update the matrix; set up a hierarchy of authorizations for easy combination creation; create maximum independence from the technology and design used to implement the application.

Authorization matrix XML service element attributes

Each service element in the authorization matrix XML has the following attributes: name (unique identifier), uri (endpoint path, may contain placeholders like {messageId}), http-method (GET, PUT, DELETE, etc.), http-response-code-for-access-allowed (integer status code when access is permitted), http-response-code-for-access-denied (integer status code when access is denied). Each service contains child role elements that list which logical roles can access that service.

Authorization matrix XML role element attributes

Each role element in the authorization matrix XML has the following attributes: name (unique identifier for the role), description (explanation of the role and its authorization level). Example roles include ANONYMOUS (no authorization required), BASIC (standard user with lowest access rights above anonymous), and ADMIN (administrator user with highest access rights).

Authorization matrix XML payload element attributes

In the services-testing section, each service payload element may have a content-type attribute (e.g., application/json) specifying the MIME type of the request body. The payload element contains the test data as text content, which can be formatted as JSON or other formats depending on the content-type.

Authorization testing integration test structure

Authorization integration tests should use maximum factorized code and implement one test case per Point Of View (logical role) to profile verifications by access level. Each test case calls all services sequentially using the specified POV, checks if the HTTP response code matches the expected code for allowed or denied access as defined in the authorization matrix, and collects any inconsistencies as errors. When authorization issues are detected, the test output reports the service name, POV, the response code received, and the expected response code.

Authorization matrix test implementation with XML parsing

Authorization tests should parse and marshal the authorization matrix XML file into Java objects using JAXB. The SAXParserFactory must disable external entity processing by setting three features to false: http://xml.org/sax/features/external-general-entities, http://xml.org/sax/features/external-parameter-entities, and http://apache.org/xml/features/nonvalidating/load-external-dtd to prevent XXE attacks. The parsed AuthorizationMatrix object is accessed to iterate through services and roles, and test payloads are retrieved from the services-testing section.

Authorization test HTTP request execution logic

For each service in the authorization matrix, the integration test must construct and execute an HTTP request using the specified HTTP method (GET, DELETE, PUT, etc.), append the service URI to the base URL while replacing placeholders like {messageId} with test values, add the test payload if present with the correct content-type header, include the access token in the Authorization header (empty string for ANONYMOUS role), capture the HTTP response code, and verify it matches the expected code for the given POV.

Authorization matrix consistency verification logic

For each service call in the authorization matrix test, the verification logic checks: if the response code equals http-response-code-for-access-allowed and the role is not in the service's allowed roles list, it is an error; if the response code equals http-response-code-for-access-denied and the role IS in the service's allowed roles list, it is an error; if the response code is neither the allowed nor denied code, it is an unexpected response code error. Errors are collected with the service name, POV name, received response code, and expected response code.

Authorization matrix test case example: anonymous user POV

The testAccessUsingAnonymousUserPointOfView test method calls executeTestWithPointOfView with SecurityRole.ANONYMOUS and no access token (null), runs tests against all services, and asserts that no errors are detected. If errors occur, they are formatted and included in the assertion failure message.

Authorization matrix test case example: authenticated user POV

The testAccessUsingBasicUserPointOfView test method first calls generateTestCaseAccessToken to obtain a JWT access token for the 'basic' user with SecurityRole.BASIC role, then passes the token to executeTestWithPointOfView to test all services from the perspective of an authenticated basic user, and asserts that no errors are detected.

Authorization matrix test output example with detected errors

When authorization issues are detected in test output, they are reported as: 'The service [SERVICE_NAME] when called with POV [ROLE_NAME] return a response code [ACTUAL_CODE] that is not the expected one ([EXPECTED_CODE] expected).' For example: 'The service DeleteMessage when called with POV ANONYMOUS return a response code 200 that is not the expected one (403 expected).' indicates a service returned success (200) when it should have denied access (403) to an anonymous user.

Authorization matrix visualization with XSL stylesheet

An XSLT stylesheet can transform the authorization matrix XML into HTML for visual audit and review. The stylesheet renders a list of roles with descriptions (color-coded by role: ADMIN in warning color, BASIC in info color, ANONYMOUS in danger color) and a table with columns for Service, URI, Method, and Role, with each role cell color-coded by role type. This facilitates spotting inconsistencies and discussing the authorization matrix with stakeholders.

Authorization matrix automation benefits

Automating authorization matrix testing ensures the team knows if changes to the application will conflict with the authorization definition or implementation, addresses the problem that authorization issues often occur when features are added or modified in updated releases without determining their effect on authorizations, and provides a clear indication of which authorization combination does not respect the matrix when a test fails.

Give your agent this brain