For digital services to be monetised, business rules are applied that may or may not be explicit. These business rules are often ad hoc and implemented by the back-end applications. For example: a consumer can read an article if they have a paid subscription, or, if they have read less than 3 articles this month, or, they have participated in a promotion, or, they are sponsored by a paying third party, or…
When a suite of services are offered, it becomes natural to externalise the evaluation of those business rules. In fact, to avoid revenue leaks and to measure success of targeted campaigns, it may become crucial to apply an overarching business policy that is more formally governed by all relevant stakeholders. This post covers the externalisation of such policy enforcement. Policies may cover business rules as well as security conditions.
Introducing the concept of a Policy Server
When a user requests access to a protected content server (or in general, access to a ‘sensitive function’), there are two distinct steps:
- take the decision to grant/deny access thereby applying a business and security policy
- execute the decision and actually honour the request respectively return an error.
A policy server is the generic term we use to implement step 1. According to Gartner, a policy server belongs to the CASB category, a cloud access security broker (see Notes). The OAuth 2 standard refers to a policy server as “Authorisation Server” that issues tokens. The XACML 3 standards refers to it as “Policy Decision Point”.
A policy server verifies whether the business and security policy are complied with, given the user and their context. To be able to evaluate those rules and obtain details about the consumer, this service may consult other sources such as an identity store , a customer management system, a subscription database and a campaign management system. See our post on policy-based authorisation.
This decision made by the policy server drives the reaction of the content server: either the user request is honoured, or, an authorisation error is returned.
How can step 2, the execution of the decision (the so-called policy enforcement), be implemented? This post describes the most common implementation methods.
In our post Becoming employee-centric as HR services provider, you see an illustration of how a Policy Server can help you become API-centric to monetise digital content.
Method-1 Client-side policy enforcement
Client-side policy enforcement is typically implemented using Javascript (for browser access) or natively inside mobile apps and fat clients.
The end user’s device running the browser or app, however, should be considered an untrusted device: it is in the hands of a user who may or may not be security-aware and whose device may be infected with malware or contain unauthorised software. As such, this solution is not preferable. Nevertheless, older CIAM systems still propose implementations like this.
Even though it is still a popular method, do not implement this method for sensitive records or for paywalls. Really, do not. The access control logic is easily bypassed by end users, as is illustrated by numerous posts such as here on Reddit.
Method-2 Server-side policy enforcement
A more secure solution is implemented by directly connecting the content server to the policy server.
Even though this solution looks simpler, it requires a strong trust relationship between the content server(s) and the policy server. This may not necessarily be the case when they belong to different domains or are supported by different parties.
Moreover, as soon as there is more than one content server, this solution becomes cumbersome to maintain and operate.
Method-3 Gated policy enforcement
A more flexible solution that can serve multiple content servers and other web-based services is putting an API gateway in front of them that can then taken care of the interaction with the policy server. Older configurations can also use a reverse proxy in front of the content servers.
This scheme engages the API gateway as a gatekeeper that does the policy enforcement on behalf of the connected content servers.
Method-4 Token-based policy enforcement
With the advent of token-based authorisation such as SAML and OAuth 2, policy decisions can be wrapped inside a token. The so-called OAuth 2 Client Credentials Grant Flow is as follows:
This solution is versatile and flexible: thanks to the standardisation of the protocol, it is available on all mobile platforms, web servers and API gateways. Additionally, the content server could pass on the access token to back-end applications, so that security extends beyond web access to back-end applications. Note that a Policy Server is called ‘Authorisation Server’ by OAuth 2 (see Notes).
Method-5 Gated token-based policy enforcement
The token-based policy enforcement of method-4 can be combined with the API gateway of method-3.
This architecture has become most prevalent in API-centric organisations, where the API gateway fulfills the role of API orchestration. See more on this in our post on How to industrialise API development? Additionally, this approach enables layered authorisations: coarse-grained access control at the API gateway, and fine-grained authorisations by the microservices or applications behind the API gateway.
Notes
1. Caution about OAuth
Even though token-based policy enforcement can be implemented with top-level security, there are some security concerns when implemented without due care. In case the tokens are issued adopting OAuth 2, please observe the security best practices here, which can be summarised as:
- do not use OAuth 2.0 itself for authentication: use OpenID Connect instead (see our post here or use method 2 for authentication (see our post here),
- choose the correct mechanism
- do not use the OAuth 2.0 implicit grant type (which has been abandoned in OAuth 2.1)
- return the access token in the body of HTTP response to POST request using CORS
- the client credentials mechanism should only be used when the client application and policy server are owned by the same authority
- use the access token correctly
- verify access token signature and expiration
- implement short-lived and one-time use access tokens
- buffer it securely and defend your frontend applications from XSS attacks that could steal tokens from localStorage
- deliver the access token securely
- secure the redirection by registering the redirection url
- use state parameter to prevent Cross-Site Request Forgery attacks
- harden it with Proof Key for Code Exchange
2. Gartner CASB
According to Gartner (see here), “a cloud access security broker (CASB) is an on-premises or cloud-based security policy enforcement point that is placed between cloud service consumers and cloud service providers to combine and interject enterprise security policies as cloud-based resources are accessed. Organisations are increasingly turning to CASB vendors to address cloud service risks, enforce security policies, and comply with regulations, even when cloud services are beyond their perimeter and out of their direct control.”
Controlled AI services 