I'm developing an Windows Azure web application and I would like to understand if I should use Windows Azure Control Service (ACS) in my Architecture or not. So, my questions are:
Is the Windows Azure Control Service (ACS) a valid option to manage users?
I mean, should I consider it as an "Authentication System" for my application instead of implement my own database (using Membership for example)?
Well "valid" as in it works and is supported, yes! But I'd say the value is more as a way to map identities and claims presented from other identity providers - like Live, Google, etc. - to claims for your application to respond to.
You can certainly set up your own users via the ACS portal, but for a true membership system you want the user to be able to change passwords, profile information, etc. Much of that can be accomplished via the ACS Management REST API but I don't know of any higher level abstractions or framework that you might be able to leverage. It seems like it would be a LOT of work that isn't really a core part of your application.
Related
I am looking at a solution to secure on-premise applications using a centralized Identity and Access Management (IAM) solution instead of baking a custom IAM solution. These on-premise application could be deployed across several of our customers globally.
I have looked at using the Azure AD B2C for this purpose but it looks like it can only provide Authentication solution and not Authorization, at least not out of the box. I haven't found a single working sample with does both AuthZ and AuthN. I am also not sure if Azure AD B2C is the solution for implementing a centralized AuthZ and AuthN solution. I have looked at Azure B2B briefly and feel this could be right for our use cases, but it is a bit confusing as to when to choose B2C vs B2B.
I am hoping to get any guidance towards the right approach to have a centralized AuthN and AuthZ solution for on-premise applications.
B2B is for partners, B2C is for customers.
You can get authorisation in the application by the application looking at the claims that are returned.
A better way is to implement conditional access.
"Control access based on location, groups, and apps. Conditional Access can also be used to control non-risk based situations. For example, you can require MFA for customers accessing a specific app, or block access from specified geographies."
This is more of an 'Is this possible' question. A developer on the team suggested using Azure AD for user management, but one of the requirements is that the app admin be able to add/manage user access through the application without having to go to the Azure Portal.
So the question is, is the Graph API (or some other mechanism) full featured enough to replace the portal (at least for basic user set up and management) and allow all actions to be done from the application UI?
Thanks.
Simple answer to your question is Yes. Graph API can be used to manage users and their access to applications instead of using Azure Portal. In fact, Azure Portal itself makes use of Graph API to perform these operations.
You may also need to use Azure REST API if you're planning on managing Azure resources as well through this custom application especially Authorization APIs if you want to manage access to Azure resources (Azure Role-based access control) through your application.
As explained here, you have to register your FHIR API with Azure AD in order to make calls to the API.
Azure AD is free for Single Sign-On for up to 10 apps: https://azure.microsoft.com/en-us/pricing/details/active-directory/
Q: Given a scenario where I have more than 10 FHIR APIs accessed through a single Web platform by multiple users, do I need to assign an account for each actor and pay $6 user/month(Premium P1)?
Or could I have a single account that is used to make calls to the APIs and authenticate the actors through another method? If you have hundreds of users it is pretty expensive to pay 6$ for each just for authentication.
Do I understand Azure AD correctly? Is there any other better method?
Answer: No. It's very likely you can get away with less than 10 app registrations without losing the ability to authorize each individual user. The only limit you should be worried about is the 500,000 object limit.
Explanation:
The concept of App Registration is well explained here, and I won't make an attempt to do a better job.
The key thing in the context of this question is that you can use the same App Registration with as many "applications" as you want. The only consequence is that you won't be able to assign different permissions to each of those applications.
From your question is not very clear what "10 APIs" mean.
In the simplest case, you have 10 different endpoints hosted under the same application, in which case the solution is trivial: use a single app registration with as many "app roles" as necessary to control access as granularly as you need/supported by FHIR.
Worst case, you have 10 applications hosted independently, in which case you can still use the app manifest to create as many app roles as necessary, most likely using some prefixing: app1_admin, app1_readonly, app2_readonly, etc. Then use those app roles to grant permissions to your endpoints.
See this documentation about how to create app roles in your app manifest.
A picture is worth more than a thousand words. This one should illustrate how you can use the same App Registration for as many applications as you wish.
I have four Azure AppServices which are complete independent applications. I want to provide a kind of a portal that aggregates those four. When a user logs in he sees all applications he has access to depending on his scope. From the portal he can navigate to the other applications and do the user management stuff like adding new users and grant access to a specific application.
Is the picture above a good pattern to do it?
If I would start from scratch, what would be a better idea?
App services don't have access to different app's directories, so I do not think this is possible.
Your best bet might be to make a feature request to the product team on User Voice. https://feedback.azure.com/forums/169401-azure-active-directory
I am trying to make my way through a lot of Azure documentation on multitenant identity management, for a bespoke ASP.NET MVC SaaS site. It is difficult as it seems that a lot of the online examples and articles are now outdated and not applicable to latest VS templates, and other vague aspects, such as determining what is Preview and what is not. Also, MS tend to use the word "multitenant" when specifically dealing with partner companies who have their own Azure AD, which is not our case.
Our proposed system will offer a web application to different customers. The backend will have a separate db per customer (tenant). The front end will select which db connection (and probably use impersonation) depending on the logged in user. The identity management would preferably be offloaded to Azure ACS, so that in future if we want to integrate with corporations with their own Federation identity provider we can, but for those smaller companies that don't have their own domain, we want to create accounts on their behalf.
I am thinking that a good way to do this is by using Azure ACS (for federating with corporate customers) and a general Azure AD directory (for everyone else), where in the second case I create a group per tenant (customer). Then, in Azure ACS, I translate all claims, either the group from my own AD, or the company name from the federated identity provider, and use that in the MVC app to establish the tenant.
Is this an OK way to do it? Am I overlooking some standard, simple way that Azure already offers? Is this future proof wrt to the Azure roadmap?
for the latest multi tenant samples please see https://github.com/Azure-samples?utf8=%E2%9C%93&query=multiten. We are about to release more documentation on how to handle multi tenancy in Azure AD. I would strongly advise against using ACS in any new project, given that we are no longer adding any features and we are actively working on migrating functionality from ACS to Azure AD. See http://blogs.technet.com/b/ad/archive/2015/02/12/the-future-of-azure-acs-is-azure-active-directory.aspx for more details.