I am migrating a public website away from ASP.NET Membership. My plan so far has been to use ASP.NET Identity with Entity Framework and SQL provider. However before doing this work, I am considering other options including Azure Active Directory for authentication management. What are the pros and cons of using Azure AD compared to ASP.NET Identity?
That all depends on your requirement .
Maintaining your own identity system has a higher degree of freedom ,you could adjust the identity system on the basis of detailed application requirements.
Azure AD is a multi-tenant cloud based directory and identity management service ,lets you focus on building your application by making it fast and simple to integrate with a world class identity management solution used by millions of organizations around the world ,if requirement is implementing Single SignOn( SSO) using on premises identity, Cloud only identity, Federation (or authentication) against Cloud SaaS applications,you can take advantage of AAD. please click here for introduction about Azure AD .
Related
What is the best way to configure an application startup.cs to use both Azure AD and Azure B2C in .netcore? I see a lot of referencing indictating to use only Azure B2C, but due to the circumstances I need to use both Identity providers separately giving the users the option to choose which service.
But I am not sure how to go about it, and after configuring the startup, how would I use distinct "Authorize" on the actions within the same controller?
You can use the Azure AD B2C custom policy and Azure ad can be set as an identity provider.The end result is as shown below, where users can choose to log in with an ad account.
Found that adding multiple Azure Active Directory authentication providers in the same app using the current release of the Microsoft Identity Web library is not available (https://github.com/AzureAD/microsoft-identity-web/issues/549 ) but will hopefully be added soon.
Is it possible to mix authentication types in a C# ASP.NET MVC web application hosted in Azure?
I have an ASP.NET MVC application written in C# that uses ASP.NET Identity as its authentication system.
A customer has asked if they can sign into the application using their Azure Active Directory (SSO using openconnect id).
I can recreate the application using openconnectid and assign their tenant as the AAD directory but users from my company can not log into the application because we do not exist in the customers Azure Active Directory.
We need to be able to log into the application because we perform data entry tasks for them using the web app.
Has anyone come across a similar issue?
Regards,
Graham
You may need to show login screen with 2 possible options. You redirect the user to their respective identity provider , they get authenticated and bring back the access_token/Id_token to access application resources.
Very much like different OpenID connect providers in the same application(FB, Google, Microsoft etc) and regardless of which provider user choose to get authenticated the token is same to access resources.
Background
I'm building an application that I want to use ASP.NET identity to manage my authorization to a web api module that I will be deploying to azure (1 project is an azure web app the other is an azure api service).
I'm a bit confused as to how I should leverage roles and claims to work together with how to structure the application or if there is another built in feature in the identity system that would work better for my solution.
My front end is built using Angular and my APIs are in C# (.net 4.6)
My project is:
Each user belongs to one or more group(s). Each user has different permissions in each group. Users can switch between groups (or see aggregate data across all groups they belong to) after they have logged in (i.e. 1 jwt token per login and that token needs to define what groups and what permissions per group the user has).
Question:
I'm not entirely sure how Asp.net identity best practice is to structure this. Should I create a role for each group that exists in the system (potentially thousands) and then give a claim for each permission that a user has within that group (role)?
I am currently evaluating possible Identity Management (IdM) solutions that enable single user identity store and SSO across applications.
I am leaning heavily toward Thinktecture IdentityServer v2, but I am not able to validate that all of the following requirements can be met with it.
I am also familiar with and have used the MembershipReboot project as a replacement for the ASP.NET Membership Provider. I like it that MR provides a lot of the self-serve and pwd mgmt requirements I'd need, but I don't fully understand how this would "fit in" with IdentityServer - and by that I don't mean the actual implementation of the I*Repository interfaces, but rather from a high level architecture.
Would someone tell me which of the following are (or are not) possible with it, and perhaps provide other options that may better address these requirements?
Support for ASP.NET (WebForms and MVC)
Maintain central user identity store
Self service password management
Password policy configuration
Ability to authenticate both AD users as well as user in SQL store (centralized)
store (forms) - this means we want to have some internal users (AD) and some custom (forms/sql) users in the same application
Customization of pages (e.g. login, self service, etc.)
Roles/Claims management specific to each application (I know this is
Authorization, not Authentication, but I need to understand how to
manage app-specific claims related to central user identities)
Permissions management (not sure if this should this be in app, or centralized)
SSO across different domains
Support for token standards like SAML 2.0, JWT, WsFed
Open Source, or Low Cost
Extensible (lower priority)
Any suggestions/recommendations or comments based on the above requirements?
If you're using IdentityServer then you're doing single sign-on. This means your app can be any tech as long as you have a library that can handle whatever protocol your IdP supports. IdentityServer v2 supports WS-Fed primarily for browser-based applications. IdentityServer v3 will first be focused on OIDC (OpenID Connect) but will eventually also support WS-Fed.
MembershipReboot is an identity management library. This means it stores things like passwords and other identity data for your users. It can be used by both IdentityServer v2 and v3.
Most, if not all, of the things you list can be achieved with either platform. Some will require custom coding on your part.
IdentityServer v3 will be in alpha very soon.
I am using VS 2013 Asp.net 4.5.1 and created an internal webforms app using the Individual User Accounts option for Authentication. I want to use LDAP to authenticate the users and use the SQL DB that was created for Individual User Accounts option to hold the users info and roles. We don’t have Active Directory Federation Services (AD FS) so I can’t use the On-Premise Authentication method.
The AD username will be stored in the SQL DB
How can I authenticate the users using LDAP and then use the AspNet.Identity.EntityFramework to get to the users info and roles from the SQL DB?
You can use this implementation like an example, it is a customer UserStore for RavenDB:
Customizing ASPNET Authentication for RavenDB
There's this series of videos explaining how to work with security in .NET (the second video explains how to do it).
Customizing ASPNET Authentication with Identity
Brock Allen discusses how to implement an "external login" in his comprehensive article on the new identity patterns using External Logins.
Active Directory Federation Services (ADFS) supports a lot of identity protocols including SSO. However, If it's just POWA (plain ol' windows authentication), IIS will support that out of the box. You would simply specify your Active Directory(AD) user/AD Group in your web.config Authentication node and leverage the Identity.Name field to look-up users' info in a lazy-load and / or request-cached fashion.
If 's claim's based authentication using ADFS, you can emulate how that works using the Identity and Access Tool and choosing the "Use Local STS" option.
Why not keep the profiles and roles in LDAP (ADLDS) as well? ADLDS does an excellent job of tracking multi-valued attributes which I find useful. The role (group membership) in ADLDS is reflexive (you can query the role for members or query a user for their membership in roles). ADLDS also insures the referential integrity - you cannot have a member in a role if the member doesn't exist. I think you are facing some severe referential integrity problems by having accounts and profiles in two separate stores or learn to love the distributed transaction coordinator.