What are the pros/cons of using .NET Identity 2.1 versus Azure Active Directory (Premium)?
We currently have an MVC 5.x application using Identity 2.1 for registration, sign-in, password resets, etc. A Microsoft consultant is suggesting we should swap to Azure Active Directory to remove the complexity of "maintaining your own security".
What are the reasons to make the swap and why wouldn't you?
I wouldn't say the two are mutually exclusive. Asp Identity has that functionality built in but you don't have to use it. Actually, you could create your own userstores, managers etc. that poll the azure AD for this info. Identity allows you to use it, override it, or skip it entirely.
Why you wouldn't want to do this? Not everyone has AD. Not everyone needs it. The bare-bones approach that the templates use are simply application managed users and claims.
If you are targeting multiple applications and want SSO and have AD then you can take advantage of it. Developing your own at this point is redundant and more work/maintenance as the consultant pointed out.
You will still probably have a Users table and possibly others in your app database because you may have business functions unrelated to AD but boilerplate stuff would all be managed via AD.
Another issue you may run into is the need to authenticate app specific users outside your AD. At that point you may choose to implement a mixed solution. One half polling AD for internal users, and the other falling back on Identity for external users.
Related
I'm mid-way through a task to migrate a legacy .NET MVC app to use Single Sign On (SSO) to make integration with a to-be-developed mobile app possible. I'm planning on using Azure AD B2C to facilitate this and based on my researched, I need to use custom policies to achieve the required functionality.
Work on this migration is proceeding very slowly. I'm finding the custom policy XML very clunky to work with. It's going to take quite some time to achieve parity with the existing system given the current velocity. I'm wondering whether it would be wise to sidestep a lot of the migration headaches by using the Microsoft Graph API in place of custom policies.
Take registration for example. It appears common to redirect the user to a SignUp.xml custom policy (or the integrated SignUpOrSignIn.xml) to handle adding the user record in the AD B2C data store. Part of this policy would involve calling a REST API to create a corresponding record for this user in the app's database (stores email settings and such). Instead of using these custom policies, my plan would be to instead take the existing registration process and simply add a step which creates the user record on the B2C side using the Microsoft Graph API.
It appears like most things I need may be achieved using the Microsoft Graph API. Things I'd need that I can see are not available are:
logging in to a user account and;
sending verification emails
Are there any other common authentication-related tasks I'm likely to need that couldn't be achieved using the Graph API?
As far as downsides, the fact I'd be handling user passwords (even if it was just to create the user and nothing else) is an obvious concern, but perhaps acceptable. The main thing I'm after is a simple SSO solution that generates secure access tokens (incl. handling reset tokens, etc). I hope then, that this could be a feasible option.
You will miss out on password reset, profile edit, SSO and token expiration etc.
A better way may be to use the base custom policies and achieve a lot of what you need by having the policy call REST API's.
What is your use case?
I recently switched to a new company where my manager wants me to develop entirely new cloud based project in MVC. I have never worked on a project from the start and I think this is a good opportunity for me to lead.
However, I think the requirements of the clients are bit confusing.
Here is what he wants:
Client should be able to access the cloud hosted application from his network with single sign on. He wants to use his active directory for that.
There are different users in active directory, they will have different roles (I think we can handle this on database side. Create different roles and assign roles to users).
Client has to add vendor info in the application. But for this, system should send an email to vendor with the url of the cloud application. He wants user to login to the application using 2 Factor Authentication. So, send dummy password with url, and send OTP to his mobile number. Just like registering to any system.
Now my questions are:
Is it possible to have 2 different types of login mechanisms in the same application? SSO for client and 2FA for outside vendors?
If yes, could you please guide me in the right direction?
what things I need? Which framework, design pattern should I prefer?
How do I proceed ?
I'm writing an application that will be the backend for a react website. The website is to be used by our customers, but we will fully control the permissions of the user. We have decided to use Azure AD to secure requests, but will also be exposing the API for end users to use directly if desired.
My understanding is in Azure AD I will have to create an application that will allow web based implicit authentication (for the react site), as well as a native application that will allow a dameon based application to authenticate to the API.
This I believe means I will have two audience ids in my application.
I'm trying to get claims to include groups, and I can see if I edit the meta data of both applicaitons in azure AD to include "groupMembershipClaims": "SecurityGroup" I can get claims with the group IDs in, but no names.
I think I can also use appRoles to set roles the application uses, but I've yet to get that to come through as claims in the JWT, but I'm assuming it can be done, however I'd need to setup the roles on each applicaiton, then add the user twice which isn't really ideal. I also think that because my app is multi-teanated that external users could use this to set their own permissions, which isn't what I want to do.
Sorry I'm just totally lost and the documentation is beyond confusing given how frequently this appears to change!
TLDR: Do I need two applicaitons configured in azure ad, and if so whats the best way to set permissions (claims). Also is oAuth 2 the right choice here, or should I look at open id?
Right away I gotta fix one misunderstanding.
Daemon apps usually have to be registered as Web/API, i.e. publicClient: false.
That's because a native app can't have client secrets.
Of course the daemon can't run on a user's device then.
Since that's what a native app. An app that runs on a user's device.
This I believe means I will have two audience ids in my application.
You will have two applications, at least. If you want, the back-end and React front can share one app (with implicit flow enabled). And the daemon will need another registration.
I'm trying to get claims to include groups, and I can see if I edit the meta data of both applicaitons in azure AD to include "groupMembershipClaims": "SecurityGroup" I can get claims with the group IDs in, but no names.
Yes, ids are included only. If you need names, you go to Graph API to get them. But why do you need them? For display? Otherwise, you need to be using the ids to setup permissions. Names always change and then your code breaks.
I think I can also use appRoles to set roles the application uses, but I've yet to get that to come through as claims in the JWT, but I'm assuming it can be done, however I'd need to setup the roles on each applicaiton, then add the user twice which isn't really ideal. I also think that because my app is multi-teanated that external users could use this to set their own permissions, which isn't what I want to do.
Your thoughts for multi-tenant scenarios are correct. If you did want to implement these though, I made an article on it: https://joonasw.net/view/defining-permissions-and-roles-in-aad.
Why would you need to setup the roles in multiple apps though? Wouldn't they only apply in the web app?
If the native app is a daemon, there is no user.
Overall, I can see your problem. You have people from other orgs, who want access to your app, but you want to control their access rights.
Honestly, the best way might be to make the app single-tenant in some tenant which you control. Then invite the external users there as guests (there's an API for this). Then you can assign them roles by using groups or appRoles.
If I misunderstood something, drop a comment and I'll fix up my answer.
Azure AD is of course a powerful system, though I also find the OAuth aspects confusing since these aspects are very mixed up:
Standards Based OAuth 2.0 and Open Id Connect
Microsoft Vendor Specific Behaviour
ROLE RELATED ANSWERS
This is not an area I know much about - Juunas seems like a great guy to help you with this.
OAUTH STANDARDS AND AZURE
I struggled through this a while back for a tutorial based OAuth blog I'm writing. Maybe some of the stuff I learned and wrote up is useful to you.
AZURE SPA AND API CODE SAMPLE
My sample shows how to use the Implicit Flow in an SPA to log the user in via Azure AD, then how to validate received tokens in a custom API:
Code Sample
Write Up
Not sure how much of this is relevant to your use case, but I hope it helps a little on the tech side of things...
I am currently setting up an ASP.NET MVC application that will be hosted on the Windows Azure platform. The application may be used by hundreds of third parties, each with their own group of individual users, which will need to be authenticated by logging in. I am looking at using Windows Azure Active Directory (WAAD) for the authentication piece.
Obviously I can use WAAD to set up individual logins for each user, then add them to a group which has been set up for the third party they belong to.
This will likely be sufficient for most third parties. However, some may already have their own Active Directory (AD), which may or may not be a WAAD, with all of their users as members. I am wondering if there is a way that I can, relatively easily, provide a way for them to connect their Active Directory to my WAAD, allowing their directory users to authenticate with our WAAD.
I have read about integrating an on-premises AD with WAAD, either through synchronisation or using a federated login. However, all of the articles seem to be aimed at "your" on-premises AD linked with "your" WAAD. Obviously since you manage both directories there is inherent trust there. However, for obvious reasons, I only trust third parties to authenticate their users and do not want to open up a mechanism where they may be able to manage my WAAD and affect other people's users or groups.
So...
Can I connect a third party AD with my WAAD and let them authenticate their users for my application, without compromising the security of my WAAD?
If so, what is the best way to configure this set-up? Would I use the standard federated services software, for example, or is there something more suitable?
1) You can definitely expose Azure AD applications to users from other Azure AD tenants, without the need to manage their directories or give them any access to yours. The Azure AD documentation refers to those kind of app as "multi-tenant". You can find a detailed example in https://azure.microsoft.com/en-us/documentation/samples/active-directory-dotnet-webapp-multitenant-openidconnect/.
2) multi-tenant applications operate under the assumption that all the participating directories have their corresponding Azure ADS tenant. That is the case when, for example, they did set up Office365 or any other cloud service. Direct federation would not work in this scenario, given that the just in time provisioning of apps and the enforcement of permission and access rules relies on the directories and users being stored in shared infrastructure (though still completely isolated form each other, as is always the case in sound multitenant systems).
Please try the sample, hopefully it will help making the above more concrete. HTH
You can also look at the Azure AD B2B and B2C (in preview) options - https://blogs.technet.microsoft.com/ad/2015/09/16/azure-ad-b2c-and-b2b-are-now-in-public-preview/
I've been research WIF a lot recently and am still quite a bit confused about some of the specifics. I understand that if you're using ADFS that it's great, but that is not my scenario. Within my organization there are at least 3 main security systems. I have tried to get the company to use AD for all internal uses, but it's just not going to happen. In order to create a unified programming model, I've contemplated building add'l STS's for authenticating/authorizing.
Is this really wise? Most of the stuff I've read says just use ADFS. If not, then don't bother. Is it worth using WIF for the unified claims model when the process of creating custom STS's can be difficult?
What do you do in a case where not every user has an AD login to map to. For example, we have many seasonal employees that never actually log in to a machine with a personal account. The machine is logged in in the morning by a supervisor and the employee scans his/her badge and the employee id is used.
We are creating a new application whose code base will be accessed by at least three different sets of users. One group is internal (using AD) the other two would probably use asp.net default membership (okay, so two different sets of user stores). I'd love to be able to use WIF to unify authorization/auth, but with WIF it seems to want to go in the opposite direction. It de-emphasizes authentication and just kind of assumes it's all good when in many case that is the main concern. How could I leverage WIF in this scenario, if at all?
I've tried reading this article:
http://msdn.microsoft.com/en-us/library/ff359105.aspx
and I read up on StarterSTS which I still need to read up on a bit more. I've also watched the videos by the author of StarterSTS. I'm failing to really put everything together. It feels like WIF won't be useful for me, but I feel like it should since all I'm really after is a unified model of authentication and authorization. Thanks
What you want is similar to the Federated Identity model. You can build a Federated STS (like StarterSTS) that would normalize your claims for your application. You can then use something like ACS / AD FS V2 to federate these Identity Providers. Reading the Claims Based Identity Guide is a good start as well. When you Claims enable your application you can add more and more Identity Providers and use the Federation Provider to control the claims and set rules.
We just released a new version of the guide on CodePlex (the docs and code) while it goes through the production process.