We want to build a Sass application. We separated individual servers/instances and DB for every customer.
Our sass model:
As part of our app, we want to use Azure Ad (Multitenant) for Identity management. We have a few cases:
Our few customers don't have organizational email then how can we manage them in Azure ad (they have maybe Gmail)
We decided to set application-level roles/permission for every API endpoint, for this scenario how to manage those roles/permission in the azure ad, Who is responsible for assigning those roles to every client's users after onboarding?
For every company, we have a users limit then how can we restrict a company's users (like only 5 users from a company able to use our application)
We have a special case like module-based permission for our customers. How can we manage this?
When an organization/company starts to use our application, If we want to give them an admin panel where they are able to manage their permission-related stuff, like adding or removing roles to their users, is it possible? (all roles/permissions are fixed from our side, they only assigned those roles to their users)
++Our few customers don't have organizational email then how can we manage them in Azure ad
->You can invite them into the tenant, then they can use their gmail account to sign in the tenant.
++set application-level roles/permission for every API endpoint ... how to manage... responsible for assigning ..
->I can't understand it but I think it's based on your requirement, user who has admin role may take the responsibility.
++have a users limit then how can we restrict a company's users...
->follow this document to set who can use the azure ad application you registered for the authentication to sign in the application.
++module-based permission for our customers
-> role management?
++adding or removing roles to their users, is it possible
-> if there's no admin panel for each company, then you may follow this answer to set role for users and validate if the access token contained correct role so that this user can access the page.
Let's assume you had an application which has a frontend app as the client and an web api project as the server. Then in the front app, you need to integrate msal lib to let users sign in with their user#xx.onmicrosoft.com account or gmail account. Then the frontend app need to generate access token and call api via it. The token should contain enough information so that the api can validate if the token had enough priority to get the data. And in the frontend app, you also need to control the page direct via the access token or id token.
Then here's the official sample document.
In the end, azure ad provides user management and sign in feature. It also provides api management feature. If you have any other questions, I recommend you creating a new question with more specific requirement.
Related
I'm new to using MVC and Web API, and I need to create an API with the individual user accounts security so that external users can register and login.
But then I want internal administrators within the company to be able to manage the API user accounts. These admins are already logged on to their local machines with windows AD accounts, and I don't want them to have to log on again to the API.
So far the only way I've found to do this is to have the API, and then a separate MVC site for the internal admins that use windows account logins.
It seems a bit messy / awkward though, is there a better way of doing this? Am I looking at it completely the wrong way?
I am new to Azure Active Directory and I am bit confused about the concept and its capabilities.
I am developing an API and a native client application that will consume this API. I registered both the API and the client app in AAD and
I managed the authorization of the client application using my Admin credentials (Azure Account). But I still don't get it.
I want the users of my client application to be able to register to the app service and then use it.
Should I handle that myself within the API (user/password in database) ?
Or
programmatically create users in AAD when users signup for my application ?
Which solution is better if I plan to offer more APIs ?
If using AAD is the case I will be grateful if you provide explanations, useful links or code examples if possible.
Your question is quite broad, and is comprised of several questions, so it is hard to answer concisely.
If your users are already in your Azure AD, you should use that as the user store. If however, they are outside of your organization, you could use Azure AD B2C, which contains functionality for selfservice account creation. Or take a look at https://stackoverflow.com/a/16068340 for a suggestion on how to use AAD for public users.
If the users are already present in your AAD, and you haven't set up user assignment on the application in AAD, they can already log on to the application.
You can use role based security to grant users different levels of access to the API methods if you are interested in that.
If I have an email example "abc#xyz.com". For an application that uses AAD authentication, If xyz.com is a domain for an AAD tenant, while login I will redirected to that tenant's home page. If it is gmail/outlook/yahoo I will be sent to live.com and others it will say "we could not find an account".
If I want to achieve this kind of functionality in code? checking if It is part of "some" tenant (may be not part of my subscription) or if it will be treated as live (gmail or yahoo).
Are you talking about Azure AD B2C, or just Azure AD? Because Azure AD does not support Google/Yahoo, etc. accounts. The "normal" Azure AD only supports LiveID as external accounts.
What you are trying to achieve is called Home-Realm Discovery and you cannot fully automate it. You can however get pretty close when you first ask your user for their e-mail address and then pass it to the Azure AD sign-in request message as login_hint optional parameter. This will trigger the Home-Realm discovery mechanism on the Azure AD side and will do the respective actions - either redirect the user to the LiveID login page, or prompt the user for his credentials (including custom branding if configured for the users tenant).
I am developing MVC based web application and want to authenticate every users with their own Office365 account. Once signed in successfully, it should provide the details of that user. The users are not specific to my organization only, they can be from any organization.
I have tried below link to achieve the same.
http://graph.microsoft.io/en-us/docs/platform/aspnetmvc
The above link has a very first step to register the application in the azure active directory, but if i will do that then it will only authenticate users from my organization. But in my case, every user has to be authenticated by their own organization.
So i want to know that is it possible? If yes, then how do i achieve that?
Registering you application in your Azure Active Directory does not preclude you from authenticating external users.
With OAUTH you have 3 actors; the Application, the Provider and the User. Each of these actors needs to trust the others. The connection between the Provider and the User is the User Account (i.e. User ID). The connection between the Provider and the Application is the Application Account (i.e. App ID).
When you register your application in Azure Active Directory you are simply establishing an Application ID. The only requirement for the User account is that it also lives within an Azure Active Directory. This does not however have to be the same AAD.
If this is a public facing website, you may want to use the newer v2 endpoint instead. Under the covers it is very similar to the workflow you've been looking at but the registration and permissions process is far more straightforward.
Yes, it is possible you need to enable multi-tenancy on your app. On the app configuration page in the Windows Azure Portal you will find the toggle for "Application is Multi-tenant". For more information about multi-tenant apps: https://azure.microsoft.com/en-us/documentation/articles/active-directory-authentication-scenarios/#application-types-and-scenarios
Just going to start making a web application and was wondering which was better, or at least what are the main differences between them (as it probably matters what I am using them for)?
Windows Authentication
Passport Authentication
Form Authentication
I would say it greatly depends on what your web app will be doing, as each one has its place. Here is some brief details about each one.
Windows authentication enables you to identify users without creating a custom page.
Credentials are stored in the Web server s local user database or an Active Directory domain. Once identified you can use the user s credentials to gain access to resources that are protected by Windows authorization.
Forms authentication enables you to identify users with a custom database such as an ASP.NET membership database. Alternatively you can implement your own custom database. Once authenticated
you can reference the roles the user is in to restrict access to portions of your Web site.
Passport authentication relies on a centralized service provided by Microsoft. Passport authentication identifies a user with using his or her e-mail address and a password and a single Passport account can be used with many different Web sites.
Passport authentication is primarily used for public Web sites with thousands of users.
Anonymous authentication does not require the user to provide credentials.
http://msdn.microsoft.com/en-us/library/eeyk640h.aspx - ASP.NET Authentication further details on forms and window authentication
Edit
Rushyo link is better: http://msdn.microsoft.com/en-us/library/ee817643.aspx
Situation as when you can use what :
Windows Authentication : As you will be using the login & password used in a domain... If you use windows authentication, your webapp will (generally) have to be deployed in a network server and all your users should (generally) have a login created for them in the domain. Though cross domain operations are possible, primarily you wont be able to use it in non-domain based environment like public websites. It will be tough if you want to include some users who are outside your domain.
Forms Authentication : Here you are deciding to act independently. You will assign each user a separate userId and password and will manage them yourself. The overhead here is you should provide and restrict the ways users are created and removed. Here you are not restricted to any domain. For any user to gain access to your webapp should get registered with your webapp. This is similar to any mail sites you see on internet.
Passport Authentication : You are depending on MS to validate your users. This will give you a global status to your application, but if you are going to deploy it only to a small group of users, you will be forcing them to create a passport account (if they don't have) so that they can access your application.
To make it more clear.. Whichever method you follow You can still restrict who can access your webapp, and can also define your own roles for each users.
This should cover everything you're looking for (and more):
http://msdn.microsoft.com/en-us/library/ee817643.aspx
[Snap - I was totally going to use that exact same quote as well ;)]
Windows Authentication : As you will be using the login & password used in a domain... If you use windows authentication, your webapp will (generally) have to be deployed in a network server and all your users should (generally) have a login created for them in the domain. Though cross domain operations are possible, primarily you wont be able to use it in non-domain based environment like public websites. It will be tough if you want to include some users who are outside your domain.
Forms Authentication : Here you are deciding to act independently. You will assign each user a separate userId and password and will manage them yourself. The overhead here is you should provide and restrict the ways users are created and removed. Here you are not restricted to any domain. For any user to gain access to your webapp should get registered with your webapp. This is similar to any mail sites you see on internet.
Passport Authentication : You are depending on MS to validate your users. This will give you a global status to your application, but if you are going to deploy it only to a small group of users, you will be forcing them to create a passport account (if they don't have) so that they can access your application.
To make it more clear.. Whichever method you follow You can still restrict who can access your webapp, and can also define your own roles for each users.