DEV Community: Stefan Weber

Get Started with OutSystems and Amazon Bedrock

Stefan Weber — Fri, 03 Nov 2023 05:43:09 +0000

In this guide, we will explore the essential steps it takes to build your first or next Generative AI application with Amazon Bedrock in OutSystems. Specifically, you will learn how to set up Amazon Bedrock and your OutSystems application to utilize one or more Foundational Models for Text-to-Text and Text-to-Image generation.

Amazon Bedrock

Amazon Bedrock is a fully AWS managed service that gives you unified access to a selection of foundation models (FMs) from leading AI companies. By the time of writing Bedrock features models from AI21 Labs, Anthropic, Cohere, Stability AI, and Amazon and you can expect more models to be added over time.

Build Generative AI Applications with Foundation Models – Amazon Bedrock – AWS

Amazon Bedrock provides lots of additional and easy to use features. The possibility of privately customizing (fine-tune) any foundation model with your own data without writing a single line of code is just one example. Find out more about Amazon Bedrock features, foundation models and use-cases by clicking on the link above.

Note that at the time of writing not all additional features are yet available.

Preparations

Before we delve into the technical aspects, there are some preliminary tasks that need to be addressed.

AWS Bedrock Runtime Forge component and Demo application

Download and install my AWS Bedrock Runtime Integration component from OutSystems Forge.

AWS Bedrock Runtime - Overview | OutSystems

Make sure that you also download the attached Demo application, which we will use to walk through the technical implementation of the Integration component.

Identity and Access Management (IAM) User

To interact with an Amazon Bedrock Foundation Model we need an IAM user account with permission to invoke model APIs.

In the AWS console switch to Identity and Access Management
Create a new policy BedrockInvokeModel with the following permissions

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": "bedrock:InvokeModel",
            "Resource": "arn:aws:bedrock:*::foundation-model/*"
        }
    ]
}

This grants permission to invoke any Foundation Model in any region. In a production environment you may want to further restrict this to only specific models and regions.

Create a new user os-bedrock (programmatic access only) and attach the BedrockInvokeModel policy directly to the user.
Next Create an Access Key for the os-bedrock. Make sure to copy the Access Key and Secret Access Key before you proceed. We will need both in a bit.

Amazon Bedrock

Before you can use a Foundation Model of Amazon Bedrock you need to explicitly request access to a model.

In AWS console switch to Amazon Bedrock

All features of Amazon Bedrock are made available first in US East N. Virginia (us-east-1) region.

In the left menu select Model Access
Click on Edit and select all Foundation Models you want to request access to.

To try out all examples from the demo application you need to request access to the following models

Amazon Titan Embeddings G1 — Text
Anthropic Claude
Stability AI Stable Diffusion XL

Note that it can take up to 24 hours until access to a specific model is granted.

Demo Application

Make sure that you have downloaded the Demo application that is attached to the AWS Bedrock Runtime Forge component.

Open Service Center and under Factory — Modules open the AWSBedrockDemoApplication module.
Switch to the Site Properties tab and fill in the values for AWSAccessKey, AWSSecretAccessKey and AWSRegion.

Make sure to use the system name of the region where you provisioned the foundation models (e.g. us-east-1 for US East N. Virginia).

As usual the security reminder here: Secrets shouldn’t be stored in site properties but instead in a secure credentials management solution like AWS Secrets Manager or Hashicorp Vault.

Try the Demo

With all preparational steps completed you should now be able to try out the demo application.

For now, the demo application allows you to try out Text-To-Text generation with Anthropics Claude Version 2 and Cohere Command models, Text-to-Image generation with Stability.AIs Stable Diffusion XL model and Text-to-Embeddings with Amazons Titan Embeddings G1 model.

Start with asking Anthropic Claude Version 2 something. For example, “Human: Why is OutSystems the leading Low-Code application platform on the market.

Assistant:”.

Make sure to read the Prompt Design Section of Anthropic Claude documentation on how to construct prompts.

Introduction to Prompt Design (anthropic.com )

Next generate an image from text with the Stability.AI Stable Diffusion XL model. I used “Debris floating in space”.

Lastly turn text into vector embeddings of 1536 dimension with Amazons Titan Embeddings G1 model. I used the following text:

Amazon Bedrock is a fully managed service that offers a choice of high-performing foundation models (FMs) from leading AI companies like AI21 Labs, Anthropic, Cohere, Meta, Stability AI, and Amazon via a single API, along with a broad set of capabilities you need to build generative AI applications, simplifying development while maintaining privacy and security. With Amazon Bedrock’s comprehensive capabilities, you can easily experiment with a variety of top FMs, privately customize them with your data using techniques such as fine-tuning and retrieval augmented generation (RAG), and create managed agents that execute complex business tasks—from booking travel and processing insurance claims to creating ad campaigns and managing inventory—all without writing any code. Since Amazon Bedrock is serverless, you don't have to manage any infrastructure, and you can securely integrate and deploy generative AI capabilities into your applications using the AWS services you are already familiar with.

The demo outputs only the first ten dimensions. Titan Embeddings G1 generate vector embeddings with a fixed length of 1536 dimension.

Vector embeddings are essential for adding semantic search and Retrieval Augmented Generation. You can read more about the two topics in my articles

OutSystems, OpenAI Embeddings and Qdrant Vector Database — Find Similar | by Stefan Weber | Aug, 2023 | Medium | ITNEXT

OutSystems, OpenAI Embeddings and Qdrant Vector Database — Answer Right | by Stefan Weber | Aug, 2023 | ITNEXT

Technical Walkthrough

One of the major advantages of Amazon Bedrock is that it unifies accessing multiple foundation models. If you know how to interact with one model, you know how to interact with all models — besides some model specific parameters.

The AWS Bedrock Runtime Forge component abstracts the unified model invocation API of Bedrock making it extremely simple to use a foundation model.

Open the Demo application in Service Studio
In the Logic Tab under Server Actions open the AnthropicClaudePrompt.

The AnthropicClaudePrompt server action wraps the Anthropic_Claude_TextToText server action from the AWS Bedrock Runtime component (AWS_BedrockRuntime_IS module).

We use this one as an example as all other server actions from the AWS_BedrockRuntime_IS follow the same approach.

The wrapper server action takes a single input parameter Prompt which is the text you entered in the default screen of the demo application and outputs a Result which is the generated text displayed next to the textarea.

The wrapper executes the Anthropic_Claude_TextToText server action from the AWS_BedrockRuntime_IS module first which in turn invokes the corresponding Bedrock API.

All model operations from the AWS Bedrock Runtime Forge component need your AWS credentials to authorize your request. You can choose between

IAM credentials — AccessKey and SecretAccessKey from a created IAM user account with programmatic access.
STS credentials — Temporary credentials by assuming an IAM role with AccessKey, SecretAccessKey and SessionToken.

STS credentials are a more advanced topic, but strongly recommended. My Forge Component AWS Security Token Service can be used to assume a role and retrieve temporary credentials.

AWS Security Token Service - Overview | OutSystems

In addition, you must specify the Region where you provisioned Foundation Models. The AWS Bedrock Runtime Forge component contains a static entity to select the region.

The Model input parameter specifies which Claude Version to use. For Anthropic Claude models you can specify one of the following values:

claude-v2:1
claude-v2
claude-v1
claude-instant-v1

All model specific parameters can be found in the Request structure. Parameters differ from model to model, and you will find information about the various parameters in the AWS Bedrock documentation.

Inference parameters for foundation models - Amazon Bedrock

The rest of the wrapping server action should be self-explaining.

Next open the PromptOnClick client action of the Demo screen that calls the wrapper.

The form value of the text area is passed as an input parameter and the result of the server action is then assigned to the Result attribute of the form structure.

Model Values

Some of the server actions accept a specific model version as input parameters. Here is a complete list of all possible values

Anthropic_Claude_TextToText

claude-v2:1
claude-v2
claude-v1
claude-instant-v1

AI21_Jurassic_TextToText

j2-ultra-v1
j2-mid-v1

Amazon_Titan_TextToText

titan-text-lite-v1
titan-text-express-v1

Cohere_Command_TextToText

command-text-v14
command-light-text-v14

Meta_Llama_TextToText

llama2-13b-chat-v1
llama2-70b-chat-v1

Stability_StableDiffusion_TextToImage

stable-diffusion-xl-v0
stability.stable-diffusion-xl-v1

Cohere_Command_TextToEmbeddings

embed-english-v3
embed-multilingual-v3

Summary

Amazon Bedrock together with the AWS Bedrock Runtime Forge component provides easy access to multiple foundation modules. With only a few preparational steps you are up and running in minutes to build your own Generative AI application.

You can expect that both the Integration Forge component and the Demo application evolve over time.

Thank you for reading. I hope you liked it and that i have explained the important parts well. Let me know if not 😊

If you have difficulties in getting up and running, please use the OutSystems Forum to get help. Suggestions on how to improve this article are very welcome. Send me a message via my OutSystems Profile or write a comment.

Fine Grained Authorization in OutSystems with Amazon Verified Permissions

Stefan Weber — Wed, 01 Nov 2023 06:25:40 +0000

A couple of months ago, I had the chance to participate in a project where we implemented a front-end application on top of a document management system. The document management system used had a very sophisticated permission system, where you could set permissions for users and groups on a hierarchical level with inheritance, on an object level, and additionally based on specific metadata bound to an object. I then wondered how this could be done in OutSystems and experimented with building a central authorization system as a service application. After a while, I came to the conclusion that it was a huge effort to build it, and with a growing number of securables and especially hierarchical permission inheritance, it was no longer performant, so I stopped working on it. Later in the year, I noticed that Amazon released a new service called Amazon Verified Permissions, which seemed like a perfect solution for a fine-grained authorization system.

Amazon Verified Permissions

Verified Permissions is a policy-based authorization service. At a glance, it checks a principal's request to act (action) on a resource against one or more authorization policies.

Principal - A principal represents a role, user, service, or any other identity that can request to perform an action.
Action - For example a server or service action of your OutSystems application or service. In other words - an operation that is requested by a principal.
Resource - Something that can be accessed or modified by the specified action.

Policies are written in Cedar, a language specifically designed for defining permissions as policies. Originally developed by AWS, the Cedar specification and reference implementation is an Apache 2.0 open-source project. At the time of writing, Cedar has already been adopted by other vendors and open-source projects.

Cedar is easy to learn and simple to read, yet it still allows for the definition of complex role-based or attribute-based authorization models.

When and Why You Should Care

By default, the only built-in authorization method in OutSystems is application roles. User accounts can be associated either directly with roles or multiple roles can be assigned to user groups. Roles can then be used to protect screens, and you can use the predefined role actions in server actions to check if a user is associated with a specific role.

It becomes more challenging when you need finer-grained authorization control over resources, such as a record in one of your entities. The OutSystems documentation suggests implementing an ACL (Access Control List) based access system. However, this can lead to varying implementations in different applications and services, making maintenance and tracing of access rights more tedious - and may increase your Application Object count drastically.

Additionally, you must implement all aspects within your business logic. To track how a user gains access to a specific resource, you would need to examine your code. Even the slightest change to your authorization logic would require a code modification and redeployment.

Considering complex authorization logic, such as nested group structures, attribute-based conditions, or a combination of "allow" and "deny" access controls, there is a possibility that implementing the authorization logic may take longer to develop than the actual application itself. Additionally, you may experience a significant performance decrease due solely to authorization checks.

Using Amazon Verified Permissions or any other external authorization decision management solution can be extremely beneficial in this situation. It can considerably reduce the effort needed to create and maintain fine-grained authorization logic. Moreover, Amazon Verified Permissions and the Cedar policy are designed for rapid evaluation of access controls, thereby ensuring consistently high performance.

The Cedar Policy Language

Before exploring how to integrate Verified Permissions with OutSystems, let's take a closer look at the Cedar policy language.

💡
We'll keep this section brief, as the focus of this article is on integrating OutSystems with Amazon Verified Permissions. Cedar is an incredibly potent expression language. For a more in-depth tutorial on Cedar policies in Verified Permissions, refer to the tutorial series by my fellow AWS Community Builder Daniel Aniszkiewicz.

Basic Policies

Below is a very simple policy. If a request satisfies the expression between the brackets the policy returns true, otherwise false. The example expression is satisfied when

The principal is an entity of type User and has an ID of 56 and
The requested action to perform is an entity of type Action with an ID of Edit and
The resource that is targeted by the action is an entity of type Case and has an ID of 155

The term entity describes the combination of a namespace (CaseManager), a type (e.g. User) and a unique identifier (e.g. 56).

permit(
  principal == CaseManager::User::"56",
  action in [CaseManager::Action::"Edit"],
  resource == CaseManager::Case::"155"
);

Policies can either permit or deny (forbid) a request, with deny policies taking precedence over permit policies.

💡
You can have an unlimited number of policies, and Verified Permissions ensures that all applicable policies are evaluated before returning the final result of either Allow or Deny.

The following example incorporates an extra condition:

permit(
  principal == CaseManager::User::"56",
  action in [CaseManager::Action::"Edit"],
  resource == CaseManager::Case::"155"
) unless {
  resource.IsSensitive == true
};

This policy evaluates as true unless the resource - an entity of type case with ID 155 - has the attribute "IsSensitive" set to true. Quite simple to understand, isn't it?

Let us see what a policy could look like to check if a principal belongs to a group.

permit(
  principal in CaseManager::Group::"Counsel",
  action,
  resource
);

Note the "in" operator following the principal. The "in" operator instructs Cedar to determine if the principal is a member of another entity's hierarchy. In our case, it refers to the entity of type Group with the ID "Counsel".

💡
Hierarchy, in this context, refers to a user who is either a member of the "Counsel" group or a member of a group that is a member of the "Counsel" group asf.

Both action and resource do not have a following operator which means any action on any resource.

Evaluation Data and Relations for Authorization Checks

But how does Cedar determine the hierarchy?

Well, we must inform Cedar about the relationships between these entities whenever we check authorization. Additionally, we need to provide any entities and essential entity attributes and their corresponding values required for policy evaluation.

Consider the following example Cedar policy

permit(
  principal in CaseManager::Group::"Counsel",
  action in [CaseManager::Action::"Edit"],
  resource == CaseManager::Case::"155"
) unless {
  resource.IsSensitive == true
};

In our scenario, a user with an ID of 25 is a member of the Counsel Group, and we want to determine if that user is permitted to edit Case 155. As mentioned earlier, we need to provide all relevant data and relationships to Verified Permissions, which are necessary for evaluating one or more applicable policies. Here we would pass to the IsAuthorized operation:

principal set to CaseManager::User::"25", which is our User entity.
action set to CaseManager::Action::"Edit"
resource set to CaseManager::Case::"155"

In addition, we need to provide two additional information

for the User entity we have to define a parent relation with the CaseManager::Group::"Counsel" entity
for the Case entity we have to add an attribute IsSensitive set to false (to satisfy the policy condition)

Strict Mode with Schema

The next question we address is: what happens if you fail to provide additional data that is crucial for authorization checks? Imagine having thousands of policies created using various entity attributes for conditional checks, and you want to ensure that those attributes are always present during an authorization check.

Although not mandatory, you can set a Policy Store in Amazon Verified Permission to Strict mode and establish a Schema.

The Schema defines all valid entities, entity relations, and attributes. Applying a schema ensures that:

1. You can only create a policy using entities and attributes defined in your schema, thus preventing the creation of policies that would never apply due to missing data.

2. Authorization checks include all essential data necessary to determine applicable policies and perform policy evaluation.

Template Linked Policies

Let's say you created thousands of policies for a specific principal-action-resource combination individually and now you have a requirement to change or add an attribute condition. In that case, you would have to iterate over all those policies and change them one by one. Furthermore, it is sometimes not that easy to identify all applicable policies that need to be changed.

Fortunately, Amazon Verified Permissions offers the ability to create Policy templates and then generate policies linked to a specific template. If you need to change a condition, you can simply modify the template, which will immediately impact all policies associated with that template.

permit(
  principal in CaseManager::Group::"Clerk",
  action in [CaseManager::Action::"Edit",CaseManager::Action::"View"],
  resource == ?resource
) unless {
  resource.IsSensitive == true
};

Above is a sample template. principal and action are static while resource is compared with ?resource. The question mark in front indicates that this parameter must be given when creating a policy based on this template.

Now if you want to change the condition resource.IsSensitive later on to compare with false then all bound policies would be changed at once.

Preparations

Now that you have a basic understanding of Cedar and Amazon Verified Permissions, we can begin exploring how to integrate with OutSystems. Let's start by tackling some preparatory tasks.

💡
You need permission to manage Amazon Verified Permissions within an AWS account, as well as permission to create an IAM Policy and User.

Create and Configure AVP Policy Store - Create an Amazon Verified Permissions (AVP) Policy Store, import a schema, and establish baseline policies and policy templates.
Create IAM Policy and User - Create an IAM User with programmatic access and an associated policy that grants access to Amazon Verified Permissions operations. This account will be used for interacting with AVP from OutSystems.
Download and install Forge components - Install the AVP Forge component and the accompanying demo application for this article.
Add a Group to OutSystems User Provider - Create Group in the OutSystems User Provider and assign user accounts.
Configure Demo application - Configure site properties of the Demo application.

Create and Configure AVP Policy Store

Go to the AWS console and log in. Make sure that your preferred region is selected.
In the Search box search for Amazon Verified Permissions and browse to the service.
Click on "View Policy Stores" and then "Create new policy store".
Select "Empty policy store" from the options then click on "Create policy store"

After successful creation copy the value on the left under "Current policy store". We will need this Policy Store Identifier later.

In the menu on the left select "Schema", then click on "Create schema"
Switch to JSON mode and paste the following schema, replacing the current JSON. Then click "Save changes".

{
    "CaseManager": {
        "entityTypes": {
            "Case": {
                "shape": {
                    "type": "Record",
                    "attributes": {
                        "AssignedTo": {
                            "name": "User",
                            "required": true,
                            "type": "Entity"
                        },
                        "IsSensitive": {
                            "required": true,
                            "type": "Boolean"
                        }
                    }
                },
                "memberOfTypes": []
            },
            "Application": {
                "shape": {
                    "attributes": {},
                    "type": "Record"
                },
                "memberOfTypes": []
            },
            "Group": {
                "shape": {
                    "attributes": {},
                    "type": "Record"
                },
                "memberOfTypes": []
            },
            "User": {
                "shape": {
                    "attributes": {},
                    "type": "Record"
                },
                "memberOfTypes": [
                    "Group"
                ]
            }
        },
        "actions": {
            "AddCase": {
                "memberOf": [],
                "appliesTo": {
                    "principalTypes": [
                        "User"
                    ],
                    "resourceTypes": [
                        "Application"
                    ],
                    "context": {
                        "type": "Record",
                        "attributes": {}
                    }
                }
            },
            "GetCase": {
                "memberOf": [],
                "appliesTo": {
                    "resourceTypes": [
                        "Case"
                    ],
                    "context": {
                        "type": "Record",
                        "attributes": {}
                    },
                    "principalTypes": [
                        "User"
                    ]
                }
            },
            "AssignCase": {
                "memberOf": [],
                "appliesTo": {
                    "context": {
                        "type": "Record",
                        "attributes": {}
                    },
                    "resourceTypes": [
                        "Case"
                    ],
                    "principalTypes": [
                        "User"
                    ]
                }
            },
            "ToggleSensitivity": {
                "appliesTo": {
                    "context": {
                        "attributes": {},
                        "type": "Record"
                    },
                    "principalTypes": [
                        "User"
                    ],
                    "resourceTypes": [
                        "Case"
                    ]
                },
                "memberOf": []
            },
            "DeleteCase": {
                "appliesTo": {
                    "resourceTypes": [
                        "Case"
                    ],
                    "principalTypes": [
                        "User"
                    ],
                    "context": {
                        "attributes": {},
                        "type": "Record"
                    }
                },
                "memberOf": []
            },
            "UpdateCase": {
                "appliesTo": {
                    "resourceTypes": [
                        "Case"
                    ],
                    "principalTypes": [
                        "User"
                    ],
                    "context": {
                        "type": "Record",
                        "attributes": {}
                    }
                },
                "memberOf": []
            }
        }
    }
}

In the menu on the left select "Policy templates", then click "Create policy template"
Enter "Case Viewers" as Description.
Copy the following policy expression to "Policy Statement", then click on "Create policy template". Name the policy "Case Viewer Template". Copy the Policy Template ID which we will need later.

permit(
  principal == ?principal,
  action in [CaseManager::Action::"GetCase"],
  resource == ?resource
) unless {
  resource.IsSensitive == true
};

In the menu on the left select "Policies"
Create the following Static Policies (skip the visual assistant and copy the policy expression directly)

Case Managers can create cases

permit(
  principal in CaseManager::Group::"os-case-manager",
  action in [CaseManager::Action::"AddCase"],
  resource == CaseManager::Application::"CaseManager"
);

Case Managers can perform any case action

permit(
  principal in CaseManager::Group::"os-case-manager",
  action in [CaseManager::Action::"GetCase",CaseManager::Action::"UpdateCase",CaseManager::Action::"DeleteCase",CaseManager::Action::"AssignCase",CaseManager::Action::"ToggleSensitivity"],
  resource
);

Assignee can read and update an assigned case

permit(
  principal,
  action in [CaseManager::Action::"GetCase",CaseManager::Action::"UpdateCase"],
  resource
) when {
  resource.IsSensitive == false && resource.AssignedTo == principal
};

Create IAM Policy and User

Next, we need an IAM user with programmatic access and an associated policy that grants specific permissions to the created Policy Store.

In the AWS console switch to Identity and Access Management Service (IAM).
In the menu on the left select Policies and click on "Create policy"
Switch to JSON edit mode and copy the following Permission Definition. Make sure to change the placeholders for "<AWSAccount>" and "<PolicyStoreId>" to your AWS Account ID and the ID of the Policy Store you created.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "verifiedpermissions:DeletePolicy",
                "verifiedpermissions:CreatePolicy",
                "verifiedpermissions:ListPolicies",
                "verifiedpermissions:IsAuthorized",
                "verifiedpermissions:GetPolicy"
            ],
            "Resource": "arn:aws:verifiedpermissions::<AWSAccount>:policy-store/<PolicyStoreId>
        }
    ]
}

Complete the Policy creation.
In the Users menu create a new user and attach the created policy directly.
In the details page of the created user in the "Security credentials" tab generate a new access key pair.

Make sure to copy both the "Access Key" and "Secret Access Key". We will need both later.

Download and install Forge components

Download and install "AWS Verified Permissions" from OutSystems Forge - This is the connector component.
Attached to the connector, there is also a Demo Application. Download this too, as we will use it to examine some implementation specifics.

Add a Group to OutSystems User Provider

Open the Users Provider Frontend in your environment (https://<youroutsystemsenvironment>/Users)
Add a new group with the exact name "os-case-manager". The name is used as an identifier in some policies you imported earlier. Add at least one user to this group. Members of this group have full permissions.

Configure Demo application

In Service Center (https://youroutsystemsenvironment>/servicecenter) open the VerifiedPermissionsAuthService_IS module.
In Site Properties set the values for AWSAccessKey, AWSSecretAccessKey, AWSRegion and AVPPolicyStoreId to match your IAM User and Policy Store Identifier.
Next, go to the VerifiedPermissionsDemo module and set the site property AVPPolicyStoreId to the policy store identifier you copied above. Set the AVPViewerTemplateId to the Policy Template ID you created above.

💡
As usual the security reminder here: Secrets shouldn’t be stored in site properties but instead in a secure credentials management solution like AWS Secrets Manager or Hashicorp Vault.

Now that all preparatory tasks are completed, you are ready to test the sample application.

Demo Application Overview

The demo application is very simple. It allows a member of the os-case-manager group to create a case with a title and a description. Cases can be assigned to any user account and an assigned user can view the details and update the details. The first assigned user is the creator of the case.

💡
The demo application only performs permission checks when executing a server action. I have not implemented permission checks on the front end, which is why everything is accessible.

Modules

The Demo Application consists of two modules

VerifiedPermissionsDemo - The actual web application
VerifiedPermissionsAuthService_IS - This module is designed to serve as a central authorization service. In a real OutSystems Factory, it should function as a central service that provides Service Actions for all other applications.

Permissions

There are some basic permissions represented by the static policies you created.

Case Managers can create cases

This policy allows members of the os-case-manager group to add a new case to the application.

Case Managers can perform any case action

This policy allows members of the os-case-manager group to perform all case-related actions.

GetCase - Retrieve the details of a case
UpdateCase - Update the details of a case
DeleteCase - Permanently delete a case
AssignCase - Assign a case to a user or add or remove a viewer of a case
ToggleSensitivity - Switch case to Sensitive and back

Assignee can read and update an assigned case

A user that is assigned to a case can perform the following actions

GetCase - Retrieve the details of a case
UpdateCase - Update the details of a case

However, if the case is marked as sensitive, even the assignee cannot access or edit the case details.

Case Viewer Template

In addition, policies are created at runtime whenever a member of the os-case-manager groups adds another viewer to a case. Those policies are created using the Policy Template "Case Viewer Template" you created which grants the following permission

GetCase - Retrieve the details of a case

However, similar to the assignee permission, this applies only if the case is not sensitive.

Try out

Before delving into the technical implementation details, it is recommended that you explore the demo application. Alter group memberships and experiment with various user accounts to observe how these changes impact specific actions and the error messages you may encounter.

Implementation Details

In this article, I will walk you through the most important implementation steps related to authorization.

Open both modules of the demo application in Service Studio (VerifiedPermissionsDemo and VerifiedPermissionsAuthService_IS)

Authorization Service

We'll begin by examining the VerifiedPermissionsAuthService_IS module. As previously mentioned, this service module is intended to function as a central authorization service, which means it can be utilized across multiple applications.

The module exposes four actions (exposed as service actions)

CheckAuthorization - Used to check if a user has permission to act on a resource
CreatePolicyFromTemplate - Used to create a new policy based on a policy template. In the demo, this action is used whenever a new viewer gets added to a case
DeletePolicy - Used to delete a policy. In the demo, this action is used when a viewer is removed from a case.
ListTemplateLinkedPolicies - Used to discover all policies affecting a principal or a resource or both

Open the CheckAuthorizationAction server action.

💡
In Amazon Verified Permissions, principals (such as users), actions, and resources are referred to as entities. Each entity has a type and an identifier. The type consists of the namespace, as declared in the schema, followed by the actual type, such as User or Case. The identifier is a unique ID, for example, the user identifier. In addition, entities can have parent entities and attributes.

This action flow

Builds the user entity hierarchy by retrieving all group memberships for the given user. It returns an entity for the user along with the parent group identifiers. With this entity, AVP can evaluate group memberships. GetUserEntityItem
This entity along with all other entities given as input parameters is then used to perform the authorization check against AVP policies.

Next, open the ListTemplateLinkedPoliciesAction server action

This action is used whenever we need to determine which policies affect a given principal or resource. In the demo, this action is used to determine the current allowed viewers of a case.

Next, open the CreatePolicyFromTemplateAction

This one is pretty easy. It takes a template identifier and principal and creates a template-linked policy.

Lastly, open the DeletePolicyAction

This action deletes a policy using the given policy identifier.

💡
To get more insights on the various Verified Permissions actions used I recommend reading the API Reference.

Case Manager

Switch to the VerifiedPermissionsDemo. In the logic tab review the server actions in the Business_Logic folder.

Each action here relates to a task a user can perform on the UI and each of it contains an authorization check before processing the request.

The application has two general types of authorization check

On the application level using the CheckApplicationAuthorization server action
On the case level using the CheckCaseAuthorization action

The only difference between the two is, that in the later case, the database is queried for the case details and an AVP entity is created using the CaseToEntityItem server action and added to the input parameters of the CheckAuthorizationOperation.

Both actions take an Action as input which is an entity identified by its namespace e.g. "CaseManager::Action" and its identifier e.g. "GetCase".

I guess most of the business logic is easy to read, so I will not get into details. But there is one server action we should take a closer look.

Open the CaseManager_GetViewers server action.

This server action uses the ListTemplateLinkedPolices service action of the VerifiedPermissionsAuthService_IS module to retrieve all applicable policies for the given case.

It then cycles through the policies to get all principal identifiers and builds a list of retrieved user identifiers.

Lastly, it performs an advanced SQL statement with an IN clause to retrieve all viewer user accounts.

💡
Note that the service action is only performed once and that AVP returns a max of 50 policies. In case you have more you would need to implement pagination with the NextToken.

And that's it. I hope you don't mind that I didn't go into every detail of the implementation. I believe that most parts are pretty much self-explaining. Let me know if you have any difficulties.

Summary

AVP and Cedar can be a great addition to your OutSystems factory or even just to a single application. It can drastically reduce the efforts of building complex authorization logic. But AVP does not only have advantages. Personally, I am missing

The ability to send bulk authorization requests which would be very helpful to check a principal's permission to entries of a list of records.
The ability to retrieve a list of actions a principal can perform on a resource.

By the time of writing Amazon Verified Permissions is still brand-new, so we can expect some nice additions in the future.

Thank you for reading. I hope you liked it and that i have explained the important parts well. Let me know if not 😊

DEV Community: Stefan Weber

Get Started with OutSystems and Amazon Bedrock

Amazon Bedrock

Preparations

AWS Bedrock Runtime Forge component and Demo application

Identity and Access Management (IAM) User

Amazon Bedrock

Demo Application

Try the Demo

Technical Walkthrough

Model Values

Summary

Fine Grained Authorization in OutSystems with Amazon Verified Permissions

Amazon Verified Permissions

When and Why You Should Care

The Cedar Policy Language

Basic Policies

Evaluation Data and Relations for Authorization Checks

Strict Mode with Schema

Template Linked Policies

More on Cedar and Amazon Verified Permissions

Preparations

Create and Configure AVP Policy Store

Create IAM Policy and User

Download and install Forge components

Add a Group to OutSystems User Provider

Configure Demo application

Demo Application Overview

Modules

Permissions

Try out

Implementation Details

Authorization Service

Case Manager

Summary