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.
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.
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
I am trying to write an app that, upon receiving the credentials of an Azure user, will be able to show him various pieces of information using the Azure billing apis.
However, the following git sample that shows how to use one of those apis, lists a series of steps that should be done in the Azure cloud platform in order for things to work, and these steps need to be done by the user himself. Specifically, step 1 talks about registering an app and configuring it so that it has access and permissions to use the apis.
Only after those steps, will I be able to access the billing apis and retrieve his information.
Seeing as how I don't want the user to have to do anything after he gives me his username and password, is there an API or some other automated way with which I can register my app to view his account?
https://github.com/Azure-Samples/billing-dotnet-usage-api
Ideally, I would want some sort of imaginary code that maybe looks like:
someObj obj = someAPI.loginToAzureWithCredentials("123456", "someUserName")
obj.registerApplication();
Obviously the "code" is very lacking in details, but it's just for emphasizing what I'm searching for.
I'm trying to get my head around SSO concepts and how they fit to my situation, and I've got to the point where I'm a bit stuck. Assuming we use something like Azure AD, or Ping Identity or something along those lines, we want to enable social login (google account / facebook etc) - that is all fine. The bit I keep getting stuck on is how do I control the claims to attach to that identity?
Process (in my head) overview:
- User logs in with google (facebook etc) account, they associate the google account with their 'legacy' account (i.e. link up their social login with their internal identifier that we as a business identify them as) what what ever that process is, does not matter for this discussion (i dont think).
Now when a user logs in with their social account, how do I perform the lookup of that mapping to their internal identifier to add it as a claim, and add the related other claim for that user based on information my organisation knows about them (e.g. If they are over 21, what 'level' of a member they are etc).
I get that if we had one RP using SSO, it as the RP could perform this logic, but we have the situation where we have several internal (and potentially externally managed) systems (4-5 currently) we want to tie together using SSO - which will rely on these claims for access / personalisation etc.
The closest I have seen to this is the concept of a RP-STS - which would effectively from what I could work out sit in front of Ping / AZ AD to form part of the chain, so so it can do the internal lookup and add additional claims as necessary - does that make sense as a concept? Is that the right approach?
I'm sure this can't be un-common - but i can't seem to find any good example / documentation around the full integration (plenty on just AZ AD / Ping etc) that we need. There must be off the shelf products that can do this? (We really dont want custom SSO implementation / components if possible)
The closest I have seen to this is the concept of a RP-STS - which
would effectively from what I could work out sit in front of Ping / AZ
AD to form part of the chain, so so it can do the internal lookup and
add additional claims as necessary - does that make sense as a
concept? Is that the right approach?
That is exactly the role of an RP-STS (or "Federation Provider" in some of the literature). It sits in between your apps and multiple "Identity Providers" and is usually responsible for 2 things:
Protocol transition (e.g. your app might be WS-Fed or SAML, but Facebook is OAuth2)
Claims transformation and enrichment (e.g. add, remove, transform claims based on some logic).
There are several implementations of this with various degrees of sophistication/flexibility, and trade-offs:
Azure Access Control Service can do #1 and (somewhat limited) #2. But it is unclear whether the service has any future or if it will be subsumed by Azure AD.
IdentityServer can do all. It is OSS so you "own" it (e.g. host, operate, customize, etc). It's a great implementation, used in production, written by experts (Dominick Baier & Brock Allen) and very flexible.
ADFS can do some (limited # of protocols, proprietary claim transformation language that is complex to debug, but works). You have to host ADFS yourself. This is a MSFT product.
The company I work for offers similar capabilities too.
I'm working with Azure ACS and incorporating it into an SSO strategy for my .NET 4.0 website. I see on the Rule Groups page that a bunch of different claims can be stored and passed back to the RP (e.g. country, streetaddress, phone, etc.). It looks like you can also return back any claim type you want to create. This got me thinking about many questions relating to storing information for users:
Does it make sense to store user information (other than the nameidentifier) in ACS vs local database tables?
It sounded like you could make unlimited rule groups and rules inside of them. Is that correct?
I would be dealing with different companies and users inside the company. Would creating a rule group for each company and then making rules for each user be a wise choice?
It appears that the API is pretty robust and would enable this to be done automatically as a result of a sign up page, etc. Correct or incorrect?
Would it be feasible and recommended to run a query against ACS to return information back about a user (e.g. query for their email address when they're offline to send them a message about something)
Could you grab bulk information for reporting purposes off of ACS?
The short answer is generally "yes", but of course there's a longer answer :-).
Does it make sense to store user information (other than the nameidentifier) in ACS vs local database tables?
Yes it could make sense. But for optimization purposes you might keep a copy of some of the user profile information somewhere else (local to the app). ACS rules information would be the "master record" you would update the values in your local store whenever you get a token and check whether there've been changes or not.
It sounded like you could make unlimited rule groups and rules inside of them. Is that correct?
No, "unlimited" is a big number. There are limits in the number of namespaces, relying parties and rules. Check the documentation. ACS also supports "cascading" transformations, which can help you reduce the number of rules.
For example:
email: eugeniop#mail.com -> company:Contoso
Company: Contoso -> Language: English
The 2nd rule will be triggered whenever a claim of type "Company", value "Contoso" is issued.
Then you can have:
email: rob#othermail.com -> company: Contoso
The "language" claim will be automatically added.
I would be dealing with different companies and users inside the company. Would creating a rule group for each company and then making rules for each user be a wise choice?
In a multi-tenant environment, it might be better to have a Relying Party per tenant. This is what we do in sample 7 (Federation With Multiple Partners) available here: http://claimsid.codeplex.com
It appears that the API is pretty robust and would enable this to be done automatically as a result of a sign up page, etc. Correct or incorrect?
Yes
Would it be feasible and recommended to run a query against ACS to return information back about a user (e.g. query for their email address when they're offline to send them a message about something)
It is possible. However, there's no concept of "user" in ACS. So yuou would have to decode that from the rules. You can't have a call like "GetUserprofile( string user)"
Could you grab bulk information for reporting purposes off of ACS?
The API supports bulk info, but for reporting it might be better to have replicated information on your own database.
One last thought: ACS rules engine today is very simple and only does simple transformations (plus cascading), but nothing compared to what ADFS can do today, where rules can be really complex (e.g. db lookups, etc)