OPA for HTTP Authorization

Open Policy Agent[1] is a promising, light weight and very generic policy engine to govern authorization is any type of domain. I found this comparion[2] very attractive in evaluating OPA for a project I am currently working on, where they demonstrate how OPA can cater same functionality defined in RBAC, RBAC with Seperation of Duty, ABAC and XACML.  
Here are the steps to a brief demonstration of OPA used for HTTP API authorization based on the sample [3], taking it another level up.
Running OPA Server First we need to download OPA from [4], based on the operating system we are running on.  For linux, curl -L -o opa https://github.com/open-policy-agent/opa/releases/download/v0.10.3/opa_linux_amd64 Make it executable, chmod 755 ./opa Once done, we can start OPA policy engine as a server.
./opa run --server Define Data and Rules Next we need to load data and authorization rules to the server, so it can make decisions. OPA defines these in files in the format of .rego. Below is a sample …

Beyond PSD2 for a Better Open Banking Expereince

PSD2 is acting as a catalyst in the digital transformation happening in the Banking industry. While meeting the compliance requirements of PSD2, financial institutes are excited to make use of the new business models and opportunities opened by this laid foundation. More the customers and partners we can reach, more the business activities and more the revenue. Making the banking functions more accessible and reactive will be a key enabler to provide a seamless experience to these parties, including internal banking staff whom directly affects the business efficiency.

IAM plays a critical role in improving business accessibility without compromising the system boundaries. PSD2 mandates strong customer authentication(SCA), setting the bar high for user authenticity, while keeping few exemptions, not to bother payment services user(PSU) with SCA for every little transactions. While adhering to this policy will make an institute PSD2 complaint, if they can react fast to the fraud rates fluctuations, utilizing the freedom given on SCA exemptions, it can act a business advantage. Also what if we select the factors for SCA in a context aware fashion and according a pre-configured user preference?

While SCA addresses the authenticity for PSU, API security addresses securely exposing banking functions to Fintecs including AISPs and PISPs. Supporting OIDC 1.0 based API security flows is plain sailing for the objective. How about having a smooth partner onboarding process, that captures all details for security checks there onwards (flexibility of making use of eIDAS network) and fine grained authorization policies for API access, along with OAuth2.0 and OIDC?

CIAM is a very sensitive aspect that need delicate handling as it’s governed by PSU’s choice as a whole and very strictly defined by PSD2 and GDPR enforcement to come. Precisely and concisely capturing user consent, honoring use consents in all business functions, providing consent mgt functionalities for both PSU and customer care officers, keeping trails of changes happened on consents and catering interoperability between consents captured by different parties still have space for more elegant solutions.


  1. Only take advice from someone you are willing to trade places with Free Commodity Tips

  2. Thank you for this post.This is very interesting information for me.

  3. This comment has been removed by the author.

  4. Enjoyed reading the article above, really explains everything in detail, the article is very interesting and effective. Thank you and good luck for the upcoming articles AWS Online Training


Post a Comment

Popular posts from this blog

Signing SOAP Messages - Generation of Enveloped XML Signatures

OPA for HTTP Authorization

How to Write a Custom User Store Manager - WSO2 Identity Server 4.5.0