All posts by Raji Sivasubramaniam

Secure and simplify account setup and access management with new Amazon QuickSight administrative controls

Post Syndicated from Raji Sivasubramaniam original https://aws.amazon.com/blogs/big-data/secure-and-simplify-account-setup-and-access-management-with-new-amazon-quicksight-administrative-controls/

Amazon QuickSight is a fully-managed, cloud-native business intelligence (BI) service that makes it easy to connect to your data, create interactive dashboards, and share these with tens of thousands of users, either within the QuickSight interface, or embedded in software as a service (SaaS) applications or web portals. Unlike many BI solutions in the market today, QuickSight requires no server deployments or management for scaling to tens of thousands of users, and authors build dashboards using a web-based interface, without any client downloads needed. QuickSight also supports private VPC connectivity to AWS databases and analytics services such as Amazon Relational Database Service (Amazon RDS) and Amazon Redshift, and AWS Identity and Access Management (IAM) permissions-based access to Amazon Simple Storage Service (Amazon S3) and Amazon Athena, making it secure and easy to access data in AWS via QuickSight.

In this post, we explore three new features in QuickSight that enable administrators to further simplify QuickSight setup and access controls, which makes it easier than ever to scale QuickSight to all your AWS accounts.

Overview of new QuickSight features

Administrators can take advantage of the following new features in QuickSight:

  • Service control policy based sign-up controls – Admins can now use service control policies (SCPs) to restrict QuickSight sign-up options within your organization. You can restrict the QuickSight edition (Standard or Enterprise), and also the type of identity mechanisms that can be used. For example, admins can set up service control policies that deny sign-ups for a QuickSight Standard Edition and turn off the ability to invite any users other than those possible via federated single sign-on (SSO). For more information, see Using Service Control Policies to Restrict Amazon QuickSight Sign-up Options.
  • Automated email sync for federated SSO users – Admins can set up QuickSight and SSO such that email addresses for end-users are automatically synced at first-time login. This avoids any manual errors during entry, and prevents use of personal email addresses (such as Gmail or Hotmail). For example, administrators can make it so that only corporate-assigned email addresses are used when users are provisioned to their QuickSight account through their identity provider (IdP). For more information, see Configuring Email Syncing for Federated Users in Amazon QuickSight.
  • Bring your own role during QuickSight account setup – QuickSight allows you to bring in data stored in several AWS services to create datasets, analyses, and dashboards. QuickSight uses an IAM role to specify permissions to the AWS resources (such as Amazon S3 or Athena) at the QuickSight account level (which you can further control within QuickSight). This service role was previously created during QuickSight sign-up, and required the user signing up to have permissions to create this role. Now, administrators signing up to QuickSight can pick from an existing role in their AWS account instead of QuickSight creating a custom service role for the account. This allows you to set up your own role for a group of codependent AWS services and QuickSight that you want to work together. For more information, see Passing IAM Roles to Amazon QuickSight.

Use case overview

Let’s walk through a use case for these features.

OkTank is an enterprise in the healthcare space, where it owns and manages multiple hospitals. OkTank’s IT infrastructure is managed centrally by a team that is responsible for ensuring security and governance of the entire IT infrastructure. Each individual facility has its own AWS account, which is a member of OkTank’s central AWS Organizations account.

Each hospital needs its own QuickSight account for gathering business intelligence and improving the healthcare service they provide to their customers. The central IT team requires that each hospital when setting up their QuickSight account only signs up for Enterprise edition. In addition, they want to authenticate each hospital’s QuickSight users (admins, authors, and readers) using Okta, which is their corporate IdP. This helps them make sure that QuickSight administrators can’t invite non-federated users intentionally or by mistake.

Administrators also want to make sure that when users get an invitation to sign up for their hospital’s QuickSight account, they only use pre-approved email address as configured in Okta and don’t enter their personal email address. This provides a seamless sign-up experience for new users because they don’t have to enter an email address anymore, and it provides more security because users can’t use their personal email for sign-up and future logins.

Finally, because AWS administrators manages other services such as Amazon S3 and Athena, which are being used by QuickSight, they have configured roles for each of these services. Administrators want to make sure they can use preconfigured roles when external services are being used by QuickSight. This makes sure that users and QuickSight admins can’t create their own roles for these services, and the roles can be enforced by administrators of those external services.

To enable all these setup and access controls, OkTank’s Organizations administrator and the hospital’s QuickSight administrator use the new features in the following order:

  • Bring your own role during QuickSight account setup
  • SCP-based sign-up controls
  • Automated email sync for federated SSO users

Bring your own role during QuickSight account setup

OkTank uses Amazon S3 for storage, and wants to use it as a data source in all the hospitals’ QuickSight accounts. An IT administrator creates an IAM role for Amazon S3 that only allows read-only access to a QuickSight account and its users. During QuickSight account creation, the administrator can select the read-only Amazon S3 role. OkTank’s Organizations administrator for each hospital’s AWS account completes the following steps to create an Amazon S3 role and configure it to be used by QuickSight:

  1. On the IAM console, choose Roles in the navigation pane.
  2. Choose Create role.
  3. Choose AWS Service and choose S3.
  4. Choose Next: Permissions.
  5. Search for S3 and select AmazonS3ReadOnlyAccess.
  6. Choose Next: Tags.
  7. Choose Next: Review.
  8. For Role name, enter QuickSightS3Role.
  9. Choose Create role.
  10. Choose the newly created role.
  11. On the Trust relationships tab,
  12. Choose Edit trust relationship.
  13. Enter the following JSON:
    {
    "Version": "2012-10-17",
    "Statement": [
    {
    "Effect": "Allow",
    "Principal": {
    "Service": "quicksight.amazonaws.com"
    },
    "Action": "sts:AssumeRole"
    }
    ]
    }

  14. Choose Update Trust Policy.

This newly created role is now available for the administrator to choose while creating a QuickSight account in the next section.

SCP-based sign-up controls

To ensure that hospitals when creating their QuickSight account only choose Enterprise edition and their users are only invited via Okta, OkTank’s Organizations administrator completes the following steps:

  1. On the Organizations console, choose Policies in the navigation pane.
  2. Choose Service control policies.
  3. Choose Create policy.
  4. For Policy name, enter QuickSightSCP.
  5. Enter the following JSON in the policy section:
    {
    "Version": "2012-10-17",
    "Statement": [
    {
    "Sid": "Statement1",
    "Effect": "Deny",
    "Action": [
    "quicksight:Subscribe"
    ],
    "Resource": [
    "*"
    ],
    "Condition": {
    "ForAnyValue:StringEquals": {
    "quicksight:DirectoryType": [
    "microsoft_ad",
    "quicksight",
    "ad_connector"
    ]
    }
    }
    },
    {
    "Sid": "Statement2",
    "Effect": "Deny",
    "Action": [
    "quicksight:Subscribe"
    ],
    "Resource": [
    "*"
    ],
    "Condition": {
    "StringEquals": {
    "quicksight:Edition": "standard"
    }
    }
    }
    ]
    }

  6. Choose Create policy.
  7. Choose AWS accounts in the navigation pane.
  8. Choose the Root account.
  9. On the Policies tab, under Service control policies, choose Attach.
  10. Select the policy QuickSightSCP that you created earlier and choose Attach policy.

Now the newly created policy is attached to all the hospital’s AWS accounts.

Test the sign-up controls

As the hospital’s AWS admin, you can test the sign-up controls to make sure they prevent you from using Standard Edition.

  1. When signing up for a QuickSight account, choose Standard.
  2. Select Use IAM federated identities & QuickSight-managed users.

You’re presented with the following error message.

As per the new SCP policy attached to the hospital’s AWS account, the admin has to choose Enterprise Edition and use IAM federated identities in order to successfully set up a QuickSight account.

  1. Choose Enterprise.
  2. Select Use IAM federated identities only.

The Amazon S3 read-only role that you created earlier is available in QuickSight.

  1. Select Use an existing role and choose QuickSightS3Role.
  2. Choose Finish.

After you make your selections per the SCP policy and the custom role for Amazon S3 read-only access, this QuickSight account is created successfully for the hospital.

Automated email sync for federated SSO users

The hospital’s QuickSight account is now set up to only accept users invited through federated SSO. In this case, they use Okta, which is their corporate IdP. After authentication via Okta is complete, the QuickSight users are asked to enter their email address when they log in for the very first time.

This email request may create confusion for some users as to which email address they should use.

The hospital’s QuickSight admin team wants to streamline the user login process and prevent users from entering any emails other than their corporate email. To ensure that, the hospital’s QuickSight admin decides to use the new automated email sync feature for federated SSO users. With this new feature, admins can set up QuickSight and SSO such that email addresses for end-users are automatically synced at first-time login. This prevents any manual errors during entry, or users signing up with personal email addresses. OkTank’s administrators can set up controls so that only corporate-assigned email addresses are used when users are provisioned to their QuickSight account through their IdP.

The hospital’s admin completes the following steps to use this feature:

  1. On the IAM console, choose Roles in the navigation pane.
  2. Search for the role you use with AssumeRoleWithSAML (for this post, it’s called QuickSightOktaFederatedRole).
  3. On the Trust relationships tab, choose Edit trust relationship.
  4. For the policy details, enter the following JSON:
    {
    "Version": "2012-10-17",
    "Statement": [
    {
    "Effect": "Allow",
    "Principal": {
    "Federated": "arn:aws:iam::xxxxxxxxxx:saml-provider/Okta"
    },
    "Action": "sts:AssumeRoleWithSAML",
    "Condition": {
    "StringEquals": {
    "SAML:aud": "https://signin.aws.amazon.com/saml"
    }
    }
    },
    {
    "Effect": "Allow",
    "Principal": {
    "Federated": "arn:aws:iam::xxxxxxxxxx:saml-provider/Okta"
    },
    "Action": "sts:TagSession",
    "Condition": {
    "StringLike": {
    "aws:RequestTag/Email": "*"
    }
    }
    }
    ]
    }

  5. Choose Update Trust Policy.

OkTank’s central IT administrator (responsible for managing Okta’s configuration) makes the following changes in the Okta configuration via Okta’s admin console:

  1. Log in to the Okta admin console.
  2. Choose Applications in the navigation pane.
  3. Choose the Okta application for QuickSight federation (in this case, it’s called AWS Account Federation – QuickSight).
  4. Choose the Sign On tab.
  5. In the Settings section, choose Edit.
  6. Select SAML 2.0 and expand the Attributes section.
  7. Add an attribute statement as follows:
    1. For Name, enter https://aws.amazon.com/SAML/Attributes/PrincipalTag:Email.
    2. For Name format, select URI reference.
    3. For Value, select user.email.
  8. Choose Save.

Finally, after you update the trust relationship for the IAM role with AssumeRoleWithSAML and add a SAML attribute for the IAM Principal tag in Okta, the next step is to turn on email syncing for federated users in QuickSight.

OkTank’s central IT administrator (responsible for managing Okta’s configuration) makes the following changes in the Okta configuration via Okta’s admin console.

  1. On the QuickSight console, on the user name menu, choose Manage QuickSight.
  2. Choose Single sign-on (SSO) in the navigation pane.
  3. In the Email Syncing for Federated Users section, select ON.

Once turned on, users when launching the QuickSight application via the Okta console for the first time bypass the email request and are redirected to the QuickSight console.

Conclusion

With these features, administrators can now strengthen controls around QuickSight accounts and open up QuickSight access to more AWS accounts within your organization. Try out these features to strengthen the security of your QuickSight account and simplify end-user access, and share your feedback and questions in the comments.

Stay tuned for more new admin capabilities, and check out what’s new for the latest updates.


About the Authors

Raji Sivasubramaniam is a Specialist Solutions Architect at AWS, focusing on Analytics. Raji has 20 years of experience in architecting end-to-end Enterprise Data Management, Business Intelligence and Analytics solutions for Fortune 500 and Fortune 100 companies across the globe. She has in-depth experience in integrated healthcare data and analytics with wide variety of healthcare datasets including managed market, physician targeting and patient analytics. In her spare time, Raji enjoys hiking, yoga and gardening.

Mayank Agarwal is a product manager for Amazon QuickSight, AWS’ cloud-native, fully managed BI service. He focuses on account administration, governance and developer experience. He started his career as an embedded software engineer developing handheld devices. Prior to QuickSight he was leading engineering teams at Credence ID, developing custom mobile embedded device and web solutions using AWS services that make biometric enrollment and identification fast, intuitive, and cost-effective for Government sector, healthcare and transaction security applications.

Embed multi-tenant dashboards in SaaS apps using Amazon QuickSight without provisioning or managing users

Post Syndicated from Raji Sivasubramaniam original https://aws.amazon.com/blogs/big-data/embed-multi-tenant-dashboards-in-saas-apps-using-amazon-quicksight-without-provisioning-or-managing-users/

Amazon QuickSight is a fully-managed, cloud-native business intelligence (BI) service that makes it easy to connect to your data, create interactive dashboards, and share these with tens of thousands of users, either within QuickSight itself, or embedded in software as a service (SaaS) apps.

QuickSight Enterprise Edition recently added row-level security (RLS) using tags, a new feature that allows developers to share a single dashboard with tens of thousands of users, while ensuring that each user can only see and have access to particular data. This means that when an independent software vendor (ISV) adds a QuickSight-embedded dashboard in their app, they don’t have to provision their end-users in QuickSight, and can simply set up tags to filter data based on who the dashboard is being served to. For example, if an ISV wanted to set up a dashboard that was to be shared with 20,000 users across 100 customers of an app, with all users within a customer having access to identical data, this new feature allows you to share a single dashboard for all users, without having to set up or manage the 20,000 users in QuickSight.

RLS enforced using tags makes sure that each end-user only sees data that is relevant to them, while QuickSight automatically scales to meet user concurrency to ensure every end-user sees consistently fast performance. In this post, we look at how this can be implemented.

Solution overview

To embed dashboards without user provisioning, we use the API GenerateEmbedURLForAnonymousUser, which works with QuickSight’s session capacity pricing. With this API, the embedding server (logic in the SaaS app) determines and manages the identity of the user to whom the dashboard is being displayed (as opposed to this identity being provisioned and managed within QuickSight).

The following diagram shows an example workflow of embedded dashboards that secures data based on who is accessing the application using RLS with tags.

In this case, an ISV has a SaaS application that is accessed by two end-users. One is a manager and other is a site supervisor. Both users access the same application and the same QuickSight dashboard embedded in the application and they’re not provisioned in QuickSight. When the site supervisor accesses the dashboard, they only see data pertaining to their site, and when the manager accesses the dashboard, they see data pertaining to all the sites they manage.

To achieve this behavior, we use a new feature that enables configuring the row-level security using tags. This method of securing data on embedded dashboards works only when dashboards are embedded without user provisioning (also called anonymous embedding). The process includes two steps:

  1. Set up tag keys on the columns of the datasets used to build the dashboard.
  2. Set values for the tag keys at runtime when embedding the dashboard anonymously.

Set up tag keys on columns in the datasets used to build the dashboard

ISVs or developers can set columns on the datasets using the CreateDataset or UpdateDataset APIs as follows:

create-data-set
--aws-account-id 
--data-set-id 
--name 
--physical-table-map 
[--logical-table-map ]
--import-mode 
[--column-groups ]
[--field-folders ]
[--permissions ]
[--row-level-permission-data-set ]
[--column-level-permission-rules ]
[--tags ]
[--cli-input-json ]
[--generate-cli-skeleton ]
[--row-level-permission-tag-configuration //upto 50 tagkeys can be added at this time
    '{
       "Status": "ENABLED",
       "TagRules": 
        [
            {
               "TagKey": "tag_name_1", //upto 128 characters
               "ColumnName": "column_name_1",
               "TagMultiValueDelimiter": ",",
               "MatchAllValue": "*"
            },
            {
               "TagKey": "tag_name_2", //upto 128 characters
               "ColumnName": "column_name_2"
            }
        ]
    }'
]
update-data-set
--aws-account-id <value>
--data-set-id <value>
--name <value>
--physical-table-map <value>
[--logical-table-map <value>]
--import-mode <value>
[--column-groups <value>]
[--field-folders <value>]
[--row-level-permission-data-set <value>]
[--column-level-permission-rules <value>]
[--cli-input-json <value>]
[--generate-cli-skeleton <value>]
[--row-level-permission-tag-configuration //upto 50 tagkeys can be added at this time
    '{
       "Status": "ENABLED",
       "TagRules": 
        [
            {
               "TagKey": "tag_name_1", //upto 128 characters
               "ColumnName": "column_name_1",
               "TagMultiValueDelimiter": ",",
               "MatchAllValue": "*"
            },
            {
               "TagKey": "tag_name_2", //upto 128 characters
               "ColumnName": "column_name_2",
               "MatchAllValue": "*"
            },
           {
               "TagKey": "tag_name_3", //upto 128 characters
               "ColumnName": "column_name_3"
           } 
        ]
    }'
]

In the preceding example code, row-level-permission-tag-configuration is the element that you can use to define tag keys on the columns of a dataset. For each tag, you can define the following optional items:

  1. TagMultiValueDelimiter – This option when set on a column enables you to pass more than one value to the tag at runtime, and the values are delimited by the string set for this option. In this sample, a comma is set as a delimiter string.
  2. MatchAllValue – This option when set on a column enables you to pass all values of a column at runtime, and the values are represented by the string set for this option. In this sample, an asterisk is set as a match all string.

After we define our tags, we can enable or disable these rules using the Status element of the API. In this case the value is set to ENABLED. To disable the rules, the value is DISABLED. After the tags are enabled, we can pass values to the tags at runtime to secure the data displayed based on who is accessing the dashboard.

Each dataset can have up to 50 tag keys.

We receive the following response for the CreateDataset or UpdateDataset API:

{
"Status": 201,
“Arn”: “string”, //ARN of the dataset
“DataSetId”: “string”, //ID of the dataset
“RequestId”: “string”
}

Enable authors to access data protected by tag keys when authoring analysis

After tags keys are set and enabled on the dataset, it is secured. Authors when using this dataset to author a dashboard don’t see any data. They must be given permissions to see any of the data in the dataset when authoring a dashboard. To give QuickSight authors permission to see data in the dataset, create a permissions file or a rules dataset. For more information, see Creating Dataset Rules for Row-Level Security. The following is an example rules dataset.

UserName column_name_1 column_name_2 column_name_3
admin/sampleauthor

In this sample dataset, we have the author’s username listed in the UserName column. The other three columns are the columns from the dataset on which we set tag keys. The values are left empty for these columns for the author added to this table. This enables the author to see all the data in these columns without any restriction when they’re authoring analyses.

Set values to the tag keys at runtime when embedding the dashboard

After the tag keys are set for columns of the datasets, developers set values to the keys at runtime when embedding the dashboard. Developers call the API GenerateDashboardEmbedURLForAnonymousUser to embed the dashboard and pass values to the tag keys in the element SessionTags, as shown in the following example code:

POST /accounts//embed-url/anonymous-user HTTP/1.1
Content-type: application/json
{
    "AwsAccountId": "string",
    "SessionLifetimeInMinutes": integer,
    "Namespace": "string", 
    "SessionTags": 
        [ 
            {
                "Key": "tag_name_1", // Length: [1-128]
                "Value": "value1, value2" // Length: [0-256]
            }
            {
               "Key": "tag_name_2", // Length: [1-128]
               "Value": "*" // Length: [0-256]
            }
            {
               "Key": "tag_name_3", // Length: [1-128]
               "Value": "value3" // Length: [0-256]
            }
        ],
    "AuthorizedResourceArns": 
        [ 
            // Length: [1-25]
            // Dashboard ARNs in the same AWS Account
            "string" 
        ],
        
        "ExperienceConfiguration": 
        {
            "Dashboard": 
            {
                "InitialDashboardId": "string" 
            }
        }
    }
} 

Because this feature secures data for users not provisioned in QuickSight, the API call is for AnonymousUser only and therefore this feature works only with the API GenerateDashboardEmbedURLForAnonymousUser.

The preceding example code has the following components:

  • For tag_name_1, you set two values (value1 and value2) using the TagMultiValueDelimiter defined when setting the tag keys (in this case, a comma).
  • For tag_name_2, you set one value as an asterisk. This enables this tag key to have all values for that column assigned because we defined asterisk as the MatchAllValue when setting a tag key on the column earlier.
  • For tag_name_3, you set one value (value3).

API response definition

The response of the API has the EmbedURL, Status, and RequestID. You can embed this URL in your HTML page. Data in this dashboard is secured based on the values passed to the tag keys when calling the embedding API GenerateDashboardEmbedURLForAnonymousUser:

  • EmbedUrl (string) – A single-use URL that you can put into your server-side webpage to embed your dashboard. This URL is valid for 5 minutes. The API operation provides the URL with an auth_code value that enables one (and only one) sign-on to a user session that is valid for up to 10 hours. This URL renders the dashboard with RLS rules applied based on the values set for the RLS tag keys.
  • Status (integer) – The HTTP status of the request.
  • RequestId (string) – The AWS request ID for this operation.

Fine-grained access control

You can achieve fine-grained access control by using dynamic AWS Identity and Access Management (IAM) policy generation. For more information, see Isolating SaaS Tenants with Dynamically Generated IAM Policies. When using the GenerateEmbedUrlForAnonymousUser API for embedding, you need to mention two resource types in the IAM policy: the namespace ARNs your anonymous users virtually belong to, and the dashboard ARNs that can be used in the AuthorizedResourceArns input parameter value. The sessions generated using this API can access the authorized resources and the ones (dashboards) shared with the namespace.

Because anonymous users are part of a namespace, any dashboards shared with the namespace are accessible to them, regardless of whether they are passed explicitly via the AuthorizedResourceArns parameter.

To allow the caller identity to generate a URL for any user and any dashboard, the Resource block of the policy can be set to *. To allow the caller identity to generate a URL for any anonymous user in a specific namespace (such as Tenant1), the Resource part of the policy can be set to arn:aws:quicksight:us-east-1:<YOUR_AWS_ACCOUNT_ID>:namespace/Tenant1. This is the same for the dashboard ID. For dynamic policy generation, you can also use placeholders for the namespace and users.

The following code is an example IAM policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "QuickSightEmbeddingRole",
      "Effect": "Allow",
      "Action": [
        "quicksight:GenerateEmbedUrlForAnonymousUser"
      ],
      "Resource": [
        "arn:aws:quicksight:us-east-1::namespace/tenant1",
        "arn:aws:quicksight:us-east-1::dashboard/dashboard-id-123"
 
        // You can add specific Namespace IDs (tenant IDs), or namespace prefixes here
        // e.g. "arn:aws:quicksight:us-east-1::namespace/{{tenant-id}}" will allow the role to
        // generate embedding URL for namespace dynamically substituted
        // into the placeholder {{tenant-id}}
 
        // or "arn:aws:quicksight:us-east-1::namespace/MyTenantIdPrefix*" will allow the role to
        // generate embedding URL for namespaces having prefix MyTenantIdPrefix.
        
        
        // You can add specific Dashboard IDs, or ID prefixes here
        // e.g. "arn:aws:quicksight:us-east-1::dashboard/{{dashboard-id}}" will allow the role to
        // generate embedding URL for dashboard dynamically substituted
        // into the placeholder {{dashboard-id}}
 
        // or "arn:aws:quicksight:us-east-1::dashboard/MyDashboardIdPrefix*" will allow the role to
        // generate embedding URL for namespaces having prefix MyDashboardIdPrefix.
      ]
    }
  ]
}

Use case

OkTank is an ISV in the healthcare space. They have a SaaS application that is used by different hospitals across different regions of the country to manage their revenue. OkTank has thousands of healthcare employees accessing their application and has embedded operations related to their business in a QuickSight dashboard in their application. OkTank doesn’t want to manage their users in QuickSight separately, and wants to secure data based on which user from which hospital is accessing their application. OkTank is securing the data on the dashboards at runtime using row-level security using tags.

OkTank has hospitals (North Hospital, South Hospital, and Downtown Hospital) in regions Central, East, South, and West.

In this example, the following users access OkTank’s application and the embedded dashboard. Each user has a certain level of restriction rules that define what data they can access in the dashboards. PowerUser is a super user that can see the data for all hospitals and regions.

OkTank’s application’s user Hospital Region
NorthUser North Hospital Central and East
NorthAdmin North Hospital All regions
SouthUser South Hospital South
SouthAdmin South Hospital All regions
PowerUser All hospitals All regions

None of these users have been provisioned in QuickSight. OkTank manages these users in its own application and therefore knows which region and hospital each user belongs to. When any of these users access the embedded QuickSight dashboard in the application, OkTank must secure the data on the dashboard so that users can only see the data for their region and hospital.

First, OkTank created tag keys on the dataset they’re using to power the dashboard. In their UpdateDataset API call, the RowLevelPermissionTagConfiguration element on the dataset is as follows:

"RowLevelPermissionTagConfiguration": 
        {
            "Status": "ENABLED",
            "TagRules": [
                {
                    "TagKey": "customer_region",
                    "ColumnName": "region",
                    "TagMultiValueDelimiter": ",",
                    "MatchAllValue": "*"
                },
                {
                    "TagKey": "customer_hospital",
                    "ColumnName": "hospital",
                    "TagMultiValueDelimiter": ",",
                    "MatchAllValue": "*"
                }
            ]
        }

Second, at runtime when embedding the dashboard via the GenerateDashboardEmbedURLForAnonymousUser API, they set SessionTags for each user.

SessionTags for NorthUser in the GenerateDashboardEmbedURLForAnonymousUser API call are as follows:

"SessionTags": 
        [ 
            {
                "Key": "customer_hospital",
                "Value": "North Hospital"
            },
            {
               "Key": " customer_region",
               "Value": "Central, East"
            }
        ]

SessionTags for NorthAdmin are as follows:

"SessionTags": 
        [ 
            {
                "Key": " customer_hospital",
                "Value": "North Hospital"
            },
            {
               "Key": " customer_region",
               "Value": "*"
            }
        ]

SessionTags for SouthUser are as follows:

"SessionTags": 
        [ 
            {
                "Key": " customer_hospital",
                "Value": "South Hospital"
            },
            {
               "Key": " customer_region",
               "Value": "South"
            }
        ]

SessionTags for SouthAdmin are as follows:

"SessionTags": 
        [ 
            {
                "Key": " customer_hospital",
                "Value": "South Hospital"
            },
            {
               "Key": " customer_region",
               "Value": "*"
            }
        ]

SessionTags for PowerUser are as follows:

"SessionTags": 
        [ 
            {
                "Key": " customer_hospital",
                "Value": "*"
            },
            {
               "Key": " customer_region",
               "Value": "*"
            }
        ]

The following screenshot shows what SouthUser sees pertaining to South Hospital in the South region.

The following screenshot shows what SouthAdmin sees pertaining to South Hospital in all regions.

The following screenshot shows what PowerUser sees pertaining to all hospitals in all regions.

Based on session tags, OkTank has secured data on the embedded dashboards such that each user only sees specific data based on their access. You can access the dashboard as one of the users (by changing the user in the drop-down menu on the top right) and see how the data changes based on the user selected.

Overall, with row-level security using tags, OkTank is able to provide a compelling analytics experience within their SaaS application, while making sure that each user only sees the appropriate data without having to provision and manage users in QuickSight. QuickSight provides a highly scalable, secure analytics option that you can set up and roll out to production in days, instead of weeks or months previously.

Conclusion

The combination of embedding dashboard for users not provisioned in QuickSight and row-level security using tags enables developers and ISVs to quickly and easily set up sophisticated, customized analytics for their application users—all without any infrastructure setup or management while scaling to millions of users. For more updates from QuickSight embedded analytics, see What’s New in the Amazon QuickSight User Guide.


About the Authors

Raji Sivasubramaniam is a Specialist Solutions Architect at AWS, focusing on Analytics. Raji has 20 years of experience in architecting end-to-end Enterprise Data Management, Business Intelligence and Analytics solutions for Fortune 500 and Fortune 100 companies across the globe. She has in-depth experience in integrated healthcare data and analytics with wide variety of healthcare datasets including managed market, physician targeting and patient analytics. In her spare time, Raji enjoys hiking, yoga and gardening.

Srikanth Baheti is a Specialized World Wide Sr. Solution Architect for Amazon QuickSight. He started his career as a consultant and worked for multiple private and government organizations. Later he worked for PerkinElmer Health and Sciences & eResearch Technology Inc, where he was responsible for designing and developing high traffic web applications, highly scalable and maintainable data pipelines for reporting platforms using AWS services and Serverless computing.

Kareem Syed-Mohammed is a Product Manager at Amazon QuickSight. He focuses on embedded analytics, APIs, and developer experience. Prior to QuickSight he has been with AWS Marketplace and Amazon retail as a PM. Kareem started his career as a developer and then PM for call center technologies, Local Expert and Ads for Expedia. He worked as a consultant with McKinsey and Company for a short while.