We are trying to implement Row Level Security in Azure Data Explorer (ADX). Out of the box, ADX doesn't provide RLS. Is there any way/ workaround we can implement RLS?
We are trying out below option but no success :
Creating 2 separate databases (DbNonSecure, DbSecure)
DbNonSecure is non-secured, all the rows can be accessible by an authenticated user
DbSecure is secured database and can not be accessible by anyone except AAD APP or some other service account
From DbNonSecure, we are thinking to call functions that access data in DbSecure (using AAD APP or Service Account) and check Row Level Security.
We couldn't find a way to call functions that access data in DbSecure using ADD APP or Service Account.
Also, we know we can add a middle tier (Separate UI) to achieve this but we don't have that much time freedom to develop middle tier.
you're correct - Kusto/ADX doesn't support row level security at the moment (you can upvote the feature request # https://aka.ms/adx.uservoice)
We couldn't find a way to call functions that access data in DbSecure using ADD APP or Service Account.
AAD application authentication is a valid means of authentication to a Kusto/ADX database. There's a full guide on how to set that up here: https://learn.microsoft.com/en-us/azure/kusto/management/access-control/how-to-provision-aad-app
-> Once you've granted the required access to your AAD Application, it can be used for querying the database. Referencing stored functions is simply part of a query, and doesn't require any special setup (asides from, obviously, creating the stored function)
Side note: you may also find interest in the Restricted view access policy (it may or may not fit your requirements).
Just a heads up, ADX Row Level Security is in preview now: https://learn.microsoft.com/en-us/azure/data-explorer/kusto/management/rowlevelsecuritypolicy
Related
I am building a Microsoft Teams application and I need to store sensitive user data (access tokens and some additional stuff) for each user using my application.
My requirement is that this data can only be accessible from the user and no one else - and it needs to potentially serve tens of thousands of users. Furthermore, this data shall be accessible from any Microsoft product (i.e. not bound to MS Teams, but let's say, as long as I get a the JWT, then I would be able to access the data).
What are my options using Azure? Is there some kind of storage I can use OOTB? Or, would I need to select an Azure service for this? If yes, which service would be the best? Can I instantiate such service for ALL the users I need to serve, or would I need a separate instance for each tenant the user is coming from (e.g. its company?).
Thanks a lot for helping me out, I tried to figure this out already and I got some ideas, but I am still confused.
Based on the requirement, you can store the sensitive user data with the following options
Azure keyvault: For Secrets Management, Key Management and Certificate Management.
Azure storage tables: To store and retrieve the access tokens, users data and the conversation.
I've been using Azure API Management recently, and I would like to know if there is a way to detect the sign up process performed from the included Developer Portal.
Basically I need to be able to get the user unique id, to be able to map data stored in a database.
Is configuring Delegation the only way to capture this event?
Try to enable the Resource Logs, it includes the userId.
Reference - https://learn.microsoft.com/en-us/azure/api-management/api-management-howto-use-azure-monitor#resource-logs
I have some doubts regarding the custom connector we are trying to build for docusign : -
Regarding the license plan that need to be bought by the customers who will be granting access for our connector to collect data from their docusign organization account. I am looking at the link https://www.docusign.com/products-and-pricing. API access support is mentioned in only the advanced solution. So I was wondering whether only we need to have "Advanced solutions plan with APIs support" plan or all our customers need to API access support in order to fetch their data.
As per the documentation, to make the REST API calls we need two fields 'base_uri' and 'account_id' (https://developers.docusign.com/esign-rest-api/guides/authentication/user-info-endpoints). Now, the response of userInfo API call gives an array of accounts and its respective fields. My doubt is, if multiple authenticated users (more than one accounts) are returned in this array but all are part of same organization, will they all have different account_ids. Main concern here is, will there be several Base Paths (https://developers.docusign.com/esign-rest-api/guides/authentication/user-info-endpoints#form-your-base-path) to make API calls?
2a. Further question is, what is the significance of 'is_default' field?
Is this related to main account (if is_default is true) using which we will create our Base Path?
Since this is a tech/engineering forum I'm going to answer only question #2 as question #1 is more of a business/sales question.
The reason you may get multiple accounts is that an authenticated user in DocuSign can be a member of multiple accounts. That said, it's the same user. Meaning, say foobar#blah.com has an account 123 with company X and account 456 with his school, then it's possible that when foobar#blah.com authenticates (With the same password!) to DocuSign we have a list of accounts associated with that user. We give you all of them when you make the API call. The default one is the main one that you would see when you log into our web app. You can decide yourself as the user which one is the default. Users who log into our web-app then see an option at the top-right to change accounts.
and yes, every API call is associated with a specific account. So when you construct the urls for your API - you do need to know which account for this user you are making the API call for. Your application can decide how to handle this.
Hope this helps.
I have an Azure Active Directory Application (and associated Service Principal). That Service Principal needs to be able to add and remove members from an Azure Active Directory Group...so I have added Read and write directory data under Application Permissions:
And I have code that uses the Client ID and Client Secret to get an Authentication Token an perform these operations using the Azure Graph API.
However, this permission is far too broad. I need the Application/Service Principal to only have the ability to add and remove members from specific groups (not all)...and not the ability to perform other types of operations.
Is there a way to do this?
Thank you.
There is a preview feature that partly fits your requirement: "Group.ReadWrite.All". It lets your principal create and update groups and their navigation properties (incl. members). It does not however reduce the permissions to modify only certain groups.
AAD permission scopes are described here: https://msdn.microsoft.com/Library/Azure/Ad/Graph/howto/azure-ad-graph-api-permission-scopes
Preview features may be subject to change and you'll have to agree to reduced service terms etc.: https://azure.microsoft.com/en-us/services/preview/
I would like to build some functionality that will allow me to analyse how users of my public web sites use various identity providers to log-in.
I have multiple web sites connected to ACS through WIF. ACS provides identity federation with Social Network logins and also with my custom STS.
I would like to be able to retrieve the "Activity Log" from ACS. Something along the following lines:
1. RP: Web1; IdP: Google; Claims: [email: user1#gmail.com, name: User One]; Time: 15:37
2. RP: Web2; IdP: Custom; Claims: [email: user2#custom.com, name: User Two]; Time: 15:38
3. RP: Web1; IdP: Facebook; Claims: [email: user3#email.com, name: User Three]; Time: 15:39
(this is just a simplification, I understand each provider sends different claims, etc).
I was hoping I could retrieve something like that using management service, but I can't find a way.
Other option I explored is to add RP-STS to the claims chain: Web -> RP-STS -> ACS -> IdP. But it feels like bit of an overkill to add another hop to the chain just to collect the usage information. Is there any smarter way to achieve this?
Nope. I am afraid you cannot retrieve such information today. You have to do the audit logging yourself. Which, if you need that simplified version of the information would not be very hard to achieve without the intermediate STS.
I would do the following:
Pick up some event from the WsFederationAuthenticationModule (SessionSecurityTokenCreated might be a good choice)
In that event handler gather everything I need, including current running application identification, and write it asynchronously to Azure Table Storage
pack the above code in separate class library and reference it from all Web Apps I have
My idea is to write to an Azure Storage Table, because I think it just fits perfectly for the scenario. I can have practically unlimited number of web apps writing to Azure Table Service. And if I choose the Partition Key/Row Key combinations carefully I will have infinite audit log store. The main question for designing the Azure Table is really about how you are going to read the data.