I have a few websites that are running mojoPortal and Yet Another Forum, and several custom websites with ASP.net web forms (vb.net). I plan to add additional ASP.net websites too. I would like to have a single sign on for all sites, be able to setup groups and roles per site, and store the user's full name, phone, email, and other custom fields.
Each website currently has its own ASP.net membership database. There are about 1000 total users. It would be nice to be able to import the current members into Azure AD, but it will be OK if each user has to create a new login account. I've never used active directory but it sounds like Azure AD will do what I want. I plan to move all websites to an Azure virtual machine.
Before I start testing, I want to find out if single sign on will work with various ASP.net websites, and how complicated the setup and configuration will be. Can I import users to AD? I guess if a website supports AD or LDAP, then AZure AD will work? I'm hoping it will be as easy as adding the AD connection string in web.config?
Thanks!
It probably wont be as easy as adding the connection string. The Ad SSO service needs to be implemented using WIF (Windows Identity Framework) in your application. If you are already using WIF then it could be that simple. If not then you will need to implement WIF.
See this blog post to help you get a better understanding of what is involved.
http://blogs.msdn.com/b/windowsazure/archive/2012/07/12/announcing-the-developer-preview-of-windows-azure-active-directory.aspx
Related
I am new to Azure AD. I have to implement two websites which uses Azure Single Sign On feature to login. I have gone through few documents and blogs but it wasn't helpful enough. Could anyone suggest me a relevant document or approach for beginners.
This approach I am using:
I made a new tenant.
Made a app in app registration
Assigned the users through Enterprise Application changes
But now i have to add another website to webapp and then make sure if user logs in anyone of those then it should automatically get logged in other website as well.
When you have multiple applications in your organization, it's better to use Azure AD and you are on the right path.
To configure an application for SSO there are multiple ways. Based on your requirement you can choose any SSO protocol from below for authentication.
There are protocols like OpenID Connect, OAuth, SAML, password-based etc. to configure SSO.
As you have two websites, register two webapps in Azure AD and configure SSO
While registering the webapps, make sure to add redirect URI or Reply URLs of those two websites respectively.
Make sure both webapps are using same SSO protocol.
As mentioned in the comment by #Anand Sowmithiran, while the user is authenticating, the login flow will detect that user is already authenticated and will provide the token seamlessly.
For more in detail, please refer below links to get some idea:
Can I use Azure for SSO to multiple websites - Microsoft Q&A
single sign on - SSO with multiple azure web apps - Stack Overflow
I have an ASP .Net Core 2.2 Web API hosted as an Azure App Service. Then there is an Angular SPA which consumes this API, hosted on Azure Storage as a static website.
I am currently using Auth0 as our authentication and identity server. I am looking at replacing Auth0 with Azure, but I've spent a couple of days now trying to figure out what I should be doing and I am completely lost.
So, the purpose that Auth0 is currently serving, and which I would like Azure to serve instead, is to protect my Web API, as well as give it identity services so that the API knows which user is logged in. So when the front end makes a call to the API, Auth0 automatically redirects it to a login page. Here the user can log in using an existing account (including social accounts) or she can create a new account. Once logged in, Auth0 provides the front end with an access token. The front end then includes this access token in the header of every API call. The access token includes identity information which the API uses to know which user is making the call. All users are stored in Auth0. So when a new user uses the front end web app, Auth0 redirects them to the login screen, where they select "Sign Up", and create an account in Auth0. Any user can do this btw - it is a public web app which anyone can sign up and use.
So, when looking at using Azure instead of Auth0, what first confuses me is that there are various authentication services:
In the Azure portal, under my app service, under "Authentication / Authorization", there is a toggle switch labelled "App Service Authentication". If I turn this on, I can set up Authentication Providers.
In the Azure portal, there is Azure Active Directory, which I guess ties in with the above?
There is also Azure B2C.
What is the difference between Azure App Service Authentication and Azure B2C? Which one should I be using? What is the difference between points 1 and 2 above? Some examples I've seen use point 1 and some use point 2.
Sorry if this is a very vague question. I am just struggling to figure out in which direction to head. I found Auth0 quite simple, but unfortunately I cannot say the same about Azure authentication. I basically just want to figure out which Azure option would be best suited to replace Auth0 as I am using it now. Thanks
Azure B2C is the proper option to replace user authentication, however you would have to go with OWIN or another solution to actually provide application specific identity/authorization pipeline.
For public-facing site I would not go with straight up azure AD for customer logins, that’s targeted more towards enterprise customer with identities in federated, office365 or on prem Active Directory.
To be honest I’m surprised you’re planning on moving from auth0 to AAD. I’m thinking about doing the opposite.
I think the "replacement" would be using Identity Server, but there's no PaaS version for it on Azure. So you should go with Azure AD or Azure AD B2C.
If you want just to create users and groups you should use Azure AD. But if you have plans to enable 3rd party identities to access your app (such as Facebook, Google or Linkedin), then you should use Azure AD B2C. For more info, please read: https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-overview
I am currently developing a WebApi 2 service which is hosted in Azure. I now need to add Authentication and ideally Authorization to this service. I was expecting to be able to do this with Azure Active Directory but have a number of questions
Will my users have to login via the standard Azure sign in portal?
Will my users be forced to use specific email domains (ie microsoft) when creating an account?
Will I be able to programatically add a user into the directory along with Authorization info (aka rights management)?
Will I programatically be able to modify a users details such as forgotton password etc
Sorry for the general question, but I am stuck trying to find out if I am looking at the right technology to be able to meet these requirements. If not, would really appreciate any suggestions on what to use instead.
Will my users have to login via the standard Azure sign in portal?
Yes, but the branding of the portal can be changed in the basic and premium editions of Azure AD.
Will my users be forced to use specific email domains (ie microsoft) when creating an account?
No, you can register your own domain and associate it with a directory. Or you can sync on-premise accounts to an Azure AD directory and use those email addresses.
Will I be able to programatically add a user into the directory along with Authorization info (aka rights management)?
Yes, using the Graph API you can create and manage users. You can also assign them roles or make them part of a security group.
Will I programatically be able to modify a users details such as forgotton password etc
Yes, using the Graph API.
I am wondering if anyone has faced a similar issue. We are working on enterprise client portal that would be sitting on the internet. We also would like to add managements/client services portal that would be sitting on the local network and would use the same core libraries. For the external clients we would like to use forms authentication and for the internal application we would like to use windows authentication. Right now we are leaning to use sql membership provider on the external site and active directory membership provider on the internal site. We are working with mvc 4 so we use claims principal throughout the app.
The questions are:
1. Is there a way to combine users so we can enforce username uniqueness using existing providers?
2. We are considering using user email as the key. Is this a security issue. Can I get user email from AD membership provider?
I have looked into simplemembership provider. I thought that I could utilize webpages_OAuthMembership table to store "LDAP" users. But there is no oauth provider for that so I would have to write our own.
On another hand it seems that simplemembership is just a temporary solution until ASPNET.Identity come out in Nov.
Do you have any suggestions?
Have you looked into Windows Identity Federation (WIF), ASP.NET Identity, MVC5?
All your cases can be implemented using above.
I am currently trying to understand the combination of Azure ACS with Claims-based Auth and the option of using a custom STS and I am only slowly getting through the (unfortunately few) info sources.
Before I spend more hours on this I would like to confirm if my plan is even possible.
I have multiple azure roles (web+worker) that are being accessed over the internet by both employees and customers. Additionally, employees access these roles and desktop apps from inside our local network.
User data comes from two sources. Our azure app has user data about customers and employees, our (local) AD only from employees.
To make the login experience as efficient (and ergonomic) as possible, when accessed via our local network, employees should be automatically authenticated (Windows Integrated Auth?) on both the desktop app (automatically because of Windows User Profile Context) and on the azure apps (hopefully w/o login page).
Customers, on the other hand, should enter their user credentials when accessing the azure app, but should not have to decide between different "Credential-sources", they should just get the username+password form.
In other words
Employee visits Azure app from local network -> Auto-login with Integrated Auth / AD data
Employee visits Azure app from internet -> Username+Password form
Customer visits Azure app from internet -> Username+Password form
While writing this question, two more came to mind:
1) Is it even possible to auto-login based on source/cookie/wizardry or would that require a manual user choice for selecting the "Credential-Source"?
2) If Azure ACS "knows" that AD account with Username X is the same as Azure App User Y, does it matter with which one logins? Can the app access the same claim-data on either login route?
Are you sure you need a custom STS? It sounds like to start you just want to enable your AD users to sign in to your azure applications using their windows credentials if they are on the domain (no password prompt). ADFS 2.0 and WIF will facilitate this. In addition, if you set up an ADFS proxy server so that when those same users browse to your app from outside of the domain they will get prompted for their domain credentials.
Now your AD users are set up, but if you want your applications to be accessible to users outside of your domain, you can federate ADFS with another organization's ADFS server, or use ACS to enable login using consumer identity providers such as Google, Yahoo, and LiveID, which are provided as built in options. If you did introduce ACS like this, you would configure your corporate ADFS server as an identity provider on your ACS instance alongside google, yahoo and what not, so that when your users browse to your site they will be prompted to select which identity provider they wish to sign in with.
Here's a fantastic whitepaper that demonstrates using ADFS to authenticate to cloud applications:
http://www.microsoft.com/download/en/details.aspx?id=13789
More detailed info about deploying ADFS (such as deploying the ADFS proxy) can be found in technet.
And for ACS, there are guides and samples on how to integrate it into azure applications, and how to add ADFS identity providers: http://msdn.com/acs
One thing that you could do is look at the user credentials when a page is requested in order to get the authentication info.
If you look at...
HttpContext.Current.User.Identity
You can get info about the user's identity. If they are on the domain you will see that they have a domain name and you could programmatically choose to direct them to a login page.
Let me also say that I've never tried to do this so I don't know if there's a built in way to do this by simply configuring something in web.config.