I have build a web application based on Azure. I have a web api service as backend and angularjs as frontend hostet in Azure.
I want to create a login page with individual user accounts. After some reading I found different user authentification strategies. Some use SQL database for managing user accounts. Some use Azure Active Directory. When I have to use Azure AD and when SQL databese?
my opinion is to compare what the benefits you will get
Azure AD:
https://azure.microsoft.com/en-us/documentation/articles/active-directory-whatis/
For IT Admins, Azure AD provides an affordable, easy to use solution
to give employees and business partners single sign-on (SSO) access to
thousands of cloud SaaS Applications like Office365, Salesforce.com,
DropBox, and Concur.
For application developers, Azure AD 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.
Azure AD also includes a full suite of identity management
capabilities including multi-factor authentication, device
registration, self-service password management, self-service group
management, privileged account management, role based access control,
application usage monitoring, rich auditing and security monitoring
and alerting. These capabilities can help secure cloud based
applications, streamline IT processes, cut costs and help assure
corporate compliance goals are met.
Do it yourself with your database,you will have to do all above yourself e.g SSO with Office365
So you have to ask yourself what your app does? and choose the approach fits your needs
The application managing its own user accounts in SQL is called forms based authentication. It's how most internet applications used to work, but it came with a lot of downsides.
Users had to remember a password for each site, but often reused passwords across multiple sites. If one site got hacked and lots the password database, user's accounts on other sites could become compromised.
To prevent this, sites had to make sure that they stored passwords correctly (salted and hashed with a slow algorithm) and apply other kinds of operational security to protected the database.
Then token based authentication came along which let applications delegate the authentication piece to an external 3rd party. This allows users to log in to multiple apps with the same username and password.
Most of these 3rd party login providers like Google, Microsoft, Facebook etc. have specialist working on these services and are therefore more likely to be secure than anything you create yourself.
So, unless you have really good reasons not to, I would recommend using a 3rd party login provider like Azure AD and possibly others.
Related
I'm adding an external identity provider, Azure multi-tenant, as a login option. I have local accounts right now and they know nothing about Azure AD users.
I want to create an Azure Enterprise App that other tenants can use to set up SSO using OpenID Connect. Also I want the app to support User Provisioning by setting up a SCIM API.
I can't really find any documents on how to handle linking Azure AD users with the existing accounts in my IDP. I've seen examples where users can login using their local account, authenticate with Azure, and then their local account is updated to have the Azure AD User ID. This approach still seems pretty manual. Another thought was to have a step in the login journey, where if no local account has the Azure AD User ID then find a local account with the same email. I don't like this approach either since the emails might not always match. Is there an approach where an admin can automatically link all accounts with a sync or upload?
SYSTEMS
First it's worth clarifying roles:
Role
Details
Authorization Server (AS)
Your UIs and APIs receive tokens from this. It is where accounts and linked accounts are stored. It is where you use SCIM to update account records. It is where you apply account linking logic.
Identity Provider (IDP)
There can be multiple of these. When your apps call the AS it manages connections to them, and exchanges IDP tokens for AS tokens that are returned to apps. It is not usual to use SCIM against an IDP.
You are using IdentityServer as the AS so your UIs and APIs will continue to use IdentityServer tokens and remain simple. Meanwhile Azure AD will become an alternative IDP. So on the data side of things your architecture is in a good place.
AUTHENTICATION ACTIONS
I would aim to solve your problems via custom authentication actions, and to design this in a vendor agnostic way. Not all providers support these concepts, but IdentityServer has some pretty good extensibility features, so hopefully it has what you need.
A bit of code, configuration and technical investigations in IdentityServer feel like the correct direction, with no complexity added to your applications. I will describe techniques in terms of Curity (where I work), but the same principles can apply to any system.
USERNAME AUTHENTICATOR
A great way to deal with user specific differences is to make the initial screen prompt only for an email. See this example for how that looks. Later, when authentication has completed, you could set a cookie so that this screen is not shown on subsequent logins.
Then, before asking for credentials, apply some scripted logic, eg to look up existing account attributes, and decide how the user should authenticate. You might decide to route unknown users to Azure AD or do something based on business partner email suffixes.
DATA UPDATES
Something simple that might work in advance of adding Azure AD support is to assign all users a Tenant ID, and perhaps existing users get a Tenant ID of 1. Only those users are allowed to sign in with Identity Server - all others have to use Azure AD.
SCRIPTED LOGIC AND ACCOUNT LINKING
For a worked example of how this looks, see this Account Linking with Facebook tutorial. In this example the objective is to update the main account with a new linked account. This account linking doc may give you some additional ideas for your scenario. It should be possible to run custom logic before triggering authentication or once your have the Azure IDP attributes.
INVOLVE THE USER IF NEEDED
It may also be useful to present a custom screen to ask the user if they have an existing account when they first login via Azure AD. If not then an Azure AD login can create the primary account in IdentityServer data in addition to a linked account.
USERS AND PARTNERS
How users onboard is interesting, and discussed in this detailed article. I always start by getting a feel for the type of assets involved:
Type
Description
Personal Assets
You allow any user to sign up and they only have access to their own assets
Corporate Assets
Users are provisioned by an administrator, eg a banker is granted access to financial data according to business rules
In your case it feels like users are from the second category, so to enable a user to fully sign up you need data from the partner, either fed in manually or by getting them to call your API, before you can assign the user the correct tenant ID. This might eventually result in TenantID=23, but there is nothing to stop you initially allowing users to onboard and placing them in a default TenantID=0 bucket.
Ultimately this all comes down to data, claims and API authorization. Eg APIs could return certain data to TenantID=0 users but only return privileged data to users whose tenant ID has been asserted by an administrator. Not sure if these thoughts of mine match your scenario but hopefully they provide a useful hint or two.
SUMMARY
Reliable account linking is tricky, but it should be solvable via the building blocks of the Authorization Server, using the above techniques. The end result should be deterministic user data, with no duplicate users.
I know Azure AD would probably be pretty good for crediting a enterprise-class application, i.e. something used inside a corp. However what about if I am creating a public facing internet application. I need typical identity components, sign-in, sign-out, etc. Let's just say 10,000 users. Would azure AD be good for this?
I think azure ad b2c will meet the demand.It provides business-to-customer identity as a service. Your customers use their preferred social, enterprise, or local account identities to get single sign-on access to your applications and APIs.You can customize the entire user experience with your brand.Azure AD B2C uses standards-based authentication protocols including OpenID Connect, OAuth 2.0, and SAML. It integrates with most modern applications and commercial off-the-shelf software etc.You can refer to this.
I have crawlers running on VMs in Azure. After work is finished the Data crawled needs to be distributed to users across the internet depending on their access level. What I need help with:
1. How to onboard users? My idea was to use Azure AD
2. How to organize pipeline from the crawlers to end users but some access rules and data filters need to be applied before using. What is the most effective way? My idea was to use Azure Functions and then Azure siglalR so my clients (desktop, mobile) can get data very fast. All that would be organized as a Logical app?
Please help. I am just starting my programming experience so sorry if my question is naive.
How to onboard users?
Azure AD would be a good choice for you. With Azure AD, it will be convenient to manage the users.
How to organize pipeline from the crawlers to end users but some access rules and data filters need to be applied before using.
Based on the description you provided, you will expose the data crawled as rest api, right? If so, you can integrate your api with Azure AD, then you can control the user access as you need. You can add app roles in your application and assign users and groups to roles, then different users will have different roles to access your api.
Reference:
How to: Add app roles in your application and receive them in the token
Integrating with Azure Active Directory
We want to build a central authority to do authentication and authorization for our various applications (.net). We see IdentityServer4 is open source and free, while Auth0 cost money. Does anyone use both of these? Can anyone provide suggestion which one to choose and why?
IdentityServer is a library that implements various authentication (not authorization!) protocols and let's you consolidate access control into a single system. You can host it in a typical ASP.NET webapp, console app or anything else, as long as the HTTP endpoints are available. It also lets you store the user data anywhere you want, whether in-memory, databases, flat files, the asp.net core membership system, or anywhere else.
Auth0 is a company that provides a managed service that handles authentication for you. They run the infrastructure and provide access through their website and APIs. It's similar to having someone run IdentityServer4 for you and there are several competitors like Okta for Devs, AWS Cognito, Azure AD B2C, Google Cloud Identity/Firebase, and more.
Choose IdentityServer if:
You want free open-source software.
You have the time and effort to run it yourself.
You want to control the backing data store (SQL database, Redis, JSON file, etc).
You want to manage all the data yourself due to regulations, privacy, etc.
You need complete control and flexibility around what happens during authentication (for example, merging user accounts in your database when someone signs in). It's all just C# code so you can do whatever you want.
Choose Auth0 if:
You want to save time and effort on implementation and operation.
Price is not an issue (as it can get expensive for some features).
The limited customizations offered by Auth0 are enough for your app.
You want the other features they offer like password-breach monitoring.
You don't want to manage user data, or don't mind having it stored by them.
Update as of Oct 2020 - IdentityServer is now a product from Duende Software with a new commercial open-source license to sustain development. There are other alternatives like OpenIddict that are still free.
Identity Server means building a server application to handle authentication and authorization, which can replicate what Auth0 does for OpenIdConnect (OIDC) there will be a few things to implement even if you use IdentityServer4. You will need to build that first, then integrate your application.
Auth0 allows you to integrate immediately with OIDC with additional & enterprise features.
Both of them implement federated protocols i.e. WS-Fed, SAML and OpenID Connect.
In order to use them your apps. need the appropriate client-side stack.
If they don't have this, you can't use the products.
The only alternative is pass-through, i.e. Auth0.
Or look at ADFS which has pass-through via the ADFS WAP.
If you do have the stacks, both will do the job.
idsrv4 does not have a user management portal e.g. create user, add group to users OOTB.
Auth0 does.
idsrv4 essentially adds features by code. Auth0 has config. via wizard.
idsrv4 is open source so you can customise to your heart's content. I find it really useful to bridge systems.
Azure AD is another option.
I'm using passport-azure-ad library to authenticate people into our app. We are using v2.0 endpoint. I have created multiple applications in Microsoft app registration portal. And have a lot of redirect url's because we have a lot of different environment apps. It was registered under my Microsoft employee account. Now I need to transfer ownership to another developer. How can I do it? Do I need to recreate all this apps in another account? I assume that this will create a new app id's and thus will ask for permissions for all users again. Is there a way to transfer ownership and not recreate all apps again?
Assuming you created your applications using your Azure Active Directory account (like your Microsoft Employee Account) you will have access to an "Owners" field where you can add new owners to the application which are in the same tenant as you.
If you are trying to transfer an application to a user from a different Tenant or using an MSA account, that is not currently supported, but something that is being considered for the future.
If you need to create a new application id, you will not be able to transfer the consent that you had from the first app over to this second one. That is just not really possible nor something we would look to support due to the security implications.