+d...@wso2.com +architect...@wso2.com
On Thu, Mar 12, 2020 at 5:20 PM Nimasha Fernando <nima...@wso2.com> wrote:
> Hi all,
>
> Open Policy Agent (OPA) is a policy engine that can be used to implement
> fine-grained access control for your application and It provides greater
> flexibility and expressiveness than hard-coded service logic or ad-hoc
> domain-specific languages and comes with powerful tooling to help anyone
> get started and also expresses policies in a high-level, declarative
> language called Rego which promotes safe and fine-grained controls. In
> Identity Server, currently we are using XACML to write authorization
> policies. We are planning to integrate OPA as well, because it is a highly
> practical solution for the critical security and policy challenges of the
> cloud-native ecosystems.
>
> Based on our findings we have two ways of integrating OPA with IS,
>
> 1. Using Script Based Adaptive Authentication
> 2. Using an Authorization Handler
>
>
> Mainly we can use OPA with WSO2 IS to achieve following use-cases.
>
> 1. To define authorization policies (e.g role based authorization,
> user-attribute based authorization).
> 2. To define authentication policies in OPA. I.e pass the set of
> authenticators of an authentication step to OPA, and based on the OPA
> policy result, construct the authentication step dynamically.
> 3. To completely delegate authentication sequence generation to OPA.
> E.g. pass cookies, ip-address to OPA and OPA can evaluate the policies
> based on the data that we send and send us back the authentication
> sequence.
>
>
> As the first step to implement above use-cases, I have introduced a
> generalized OPA function called "invokeOPA" in adaptive scripts to be able
> to pass any JSON object as the payload, and from OPA it is possible to
> process the data object and extract the required information. Then OPA
> engine will execute the defined policies and will send back a JSON response
> to WSO2 IS. Then the final authentication or authorization decision will be
> made by OPA according to the policies that have defined. Following diagram
> illustrates the information flow.
>
> [image: Untitled Document(1).png]
>
> *Following is a sample OPA policy for role based authorization.*
>
> package play.policy
>
> import input
>
> default permit = false
> permit{
> role = ["manager" , "admin"]
> user := input.userDetails.roles[_]
> user == role[_]
> }
>
> *Sample adaptive authentication script to execute the above policy using
> WSO2 IS.*
>
> var onLoginRequest = function(context) {
> executeStep(1, {
> onSuccess: function (context) {
>
> invokeOPA('http://localhost:8181/v1/data/play/policy',
> {"context" :context,"ip_address": "111.222.333.333"},{"sendClaims" :
> "false", "sendRoles": "true"}, {
> onSuccess : function(context, data) {
>
>
> var permit = data.result.permit;
> Log.info('permit '+ permit);
>
> Log.info("Successfully posted data.");
>
> if (permit) {
> executeStep(2);
> }
> }, onFail : function(context) {
> Log.info("Failed to post data");
> }
> });
> }
> });
> };
>
> As the next steps, I am going to
>
> - Introduce a new function to construct the authentication sequence
> based on the response from OPA
> - Evaluate the possibility to construct the authentication sequence by
> directly invoking OPA without utilizing Nashorn
> - Introduce a cache for OPA response.
>
> Appreciate your suggestions/concerns on this.
>
> [1]https://www.openpolicyagent.org/docs/latest/
> [2]
> https://is.docs.wso2.com/en/next/learn/configuring-a-service-provider-for-adaptive-authentication/
> [3]
> https://is.docs.wso2.com/en/next/learn/configuring-role-based-adaptive-authentication/
>
--
*W.Nimasha Fernando*| Intern Engineering | WSO2 Inc. <http://wso2.com/>
(M)+94 711886714 | (E) nima...@wso2.com[image: https://wso2.com/signature]
<https://wso2.com/signature>
_______________________________________________
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
