Identity & Access Management
Control Access to Applications with OPA
Integrate OPA with the WSO2 Identity Server for fine-grained authorization
Open Policy Agent (OPA) is an open-source, general-purpose policy engine. It is one of the practical solutions for the critical security and policy challenges of cloud-native ecosystems spanning various domains including Identity & Access Management(IAM), data monitoring, and risk analysis. OPA is currently used in production at giants such as Netflix, Intuit, Medallia, Chef, etc.
OPA Flow
First, we must define a policy using Rego and upload it to the policy engine. And at the time of service consumption, the service interacts with the OPA policy engine, making a query regarding the policy decision. Based on the stored policy and the data, a policy decision will be made and a decision will be conveyed to the enforcer. Based on the decision policy will be enforced at the adaptive scripts of the service provider.
Rego
Rego is OPA’s very own policy language which is a very user-friendly construct. Rego is extended from Datalog, an old query language to support structured document models such as JSON. Defining the policy using Rego makes it easy to read and write for the developers. As Rego is a declarative language, it makes the lives easier for developers (or policy authors) as they can focus on what they require rather than wanting to learn how to obtain a decision.
Integrate with WSO2 Identity-Server
After understanding the fundamentals of the OPA flow, let's focus on how we can integrate OPA with WSO2 Identity Server. Though we have several events and requests that we could use OPA for since we are focusing on controlling access to applications, we have to engage OPA at authentication and authorization flow. The ideal place would be to engage through an adaptive authentication script, which already provides higher extensibility and also a place where policy authors can enforce authentication based on the policy decisions. Here, for authorization, we will be focusing on the role-based adaptive authentication script. Here our policy enforcement should be to allow or block access based on the permission or privileges of the user (roles to be precise) who is trying to log in. The enforcement will be carried out by the authentication framework of the Identity Server. The policy has to be for the roles. Having discussed the policy, event, enforcement, enforcing component, let's move towards :
Integrate OPA with WSO2 Identity Server
- Download the latest version of the WSO2 Identity Server(5.11) and start the server
- Configure sample Service Provider (Eg: SAML Pickup-dispatch)
- Configure SMS-OTP Authenticator
- Setup OPA
- Download for Linux using
curl -L -o opa https://openpolicyagent.org/downloads/latest/opa_linux_amd64- configure,
chmod 755 ./opa- and up the server
./opa run — server- Write the Policy
- Upload the policy
curl -X PUT http://localhost:8181/v1/policies/myapi --data-binary @ispolicy.rego- Validate the policy. As mentioned earlier, testing of policies is made easy which ensures more interactiveness.
curl -X POST http://localhost:8181/v1/data/play/policy --data-binary '{ "input": { "attribute": "manager" } }' | jqThe response should be the policy decision
{
"result": {
"permit" : true
}
}5. Configure SAML service Provider for (role-based) Adaptive authentication with the first step being basic and the second step SMS-OTP authenticator as the authentication steps.
6. Create new roles: manager & customer.
7. Create two new users for Eg: Bob and Alice. Let Alice have the role of customer and Bob has the role of admin.
8. Try the flow with those users. Considering Bob, here, the authentication request can be considered the event at the service of the Authentication framework (adaptive script). Then the script communicates with the OPA engine about the user who is trying to log in and based on the policy which allows only the admin to log in OPA returns back a policy decision of allowing the user access to the application.
Note that: We call the OPA engine using httpPost()
Benefits of OPA
OPA can be deployed either as an operating system daemon, inside a container, or as a library (for ex: GO). The nature of deployment has led to the vast adaption even by the giants of NetFlix. OPA is easy to manage. Administrators can update and manage policies dynamically without requiring changes to their services which leads to efficient policy management. OPA is compatible with various languages as it is a REST API, that works on HTTP and JSON. It is developed from scratch in a way that it could reduce performance impact which makes it OPA responsive. It is highly interactive since developers can define and test on the go very easily.
This was done as a part of #IdentityIn15 session hosted byWSO2 Identity & Access Management team. Have hereby annexing the URL for the sessions.
References
[1] https://www.openpolicyagent.org/docs/latest/
[2] https://is.docs.wso2.com/en/latest/learn/using-opa-policies-for-adaptive-auth/
