## 5 Evaluation
### Qualitative Comparison with Related Work  
As the related work does not offer the same delegated authorization capabilities as the ones proposed in our framework, a systematic quantitative assessment comparing performance improvements is not feasible. Instead, we carry out a qualitative comparison to contrast the strengths and weaknesses with other state-of-practice authorization frameworks. A key characteristic that our framework shares with other authorization solutions is that users or subjects must be identified such that authorization policies can be correctly evaluated. The authentication step precedes any authorization decision and provides a set of subject attributes that can be used in authorization policy decisions. In principle, a dedicated microservice could add username/password authentication relying on a database or LDAPserver to store all user attributes and credentials. However, our framework treats the verification of identities as a separate concern. It implements federated Single Sign On (SSO) on top of ForgeRock's OpenAM ([[https://www.forgerock.com/platform/access-management/](https://www.forgerock.com/platform/access-management/)]([https://www.forgerock.com/platform/access-management/](https://www.forgerock.com/platform/access-management/))) identity and access management framework, as we have done in previous work [28], to create a federation of trust between identity providers for authentication and service providers enforcing authorization. It relies on established standards, such as OpenID Connect and SAML, to exchange user attributes stored at the identity provider with the microservices. Digitally-signed JSON Web Tokens (JWT) offered by the identity provider ensure the authenticity of the user attributes. Two well-known authorization frameworks are XACML 3.0 ([[http://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html](http://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html)]([http://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html](http://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html))) and OAuth 2.0 ([[https://tools.ietf.org/html/rfc6749](https://tools.ietf.org/html/rfc6749)]([https://tools.ietf.org/html/rfc6749](https://tools.ietf.org/html/rfc6749))). However,  
Figure 16: Performance trade-offs of delegated policy evaluation vs. local policy evaluation. there are fundamental differences between both solutions. OAuth is an access delegation framework that allows someone to do something on behalf of another user. From a high-level point of view, the protocol relies on access tokens that are obtained after user authentication and validated with each service request. In microservice deployments, OAuth access tokens are usually exchanged for signed JWT tokens at a token exchange point. These JWT tokens are then with each request passed downstream to each microservice where they are subsequently validated. However, the scope part of the OAuth protocol is not sufficiently rich to express access control conditions in a fine-grained manner. This is the goal of the XACML authorization language. XACML is a domain-specific language to define permissions that declare whether a given user can perform a given action on a particular resource. However, both OAuth and XACML can be combined to have the best of both worlds. When the OAuth authorization server verifies the validity of the access token, it can also submit a subsequent XACML request to an XACML policy engine when fine-grained authorization beyond OAuth scopes is required. Note that, contrary to our approach, both the access token validation and the policy evaluation are atomic operations, whereas our framework supports partial policy evaluation. Several vertical domains have their own security and privacy standards.