I have a web application that I need to secure.
We phased the development tasks/epics to help the focus and meet the deadlines:
Phase 1:
User authentication/authorization from active directory
Custom login page
Custom user names (let users choose something like "John Doe" as a user name, I mean, spaces, no email address format)
Phase 2:
External active directory integration (Federation Services)
Phase 3:
Open ID integration for users (Microsoft account, Facebook account, ...)
Additional info:
We have created a Windows Azure Active Directory but that seem to be problematic with both the user name and the login page. WAAD was chosen as it removes the pain of having to create a "custom" user management platform and because of the "as a service" approach.
I can't find anybody doing this on the web.
Would anybody have an idea to know how to start based on the requirements?
I would recommend starting by reading up on the Claims-based Identity model. The current version of WIF (Windows Identity Framework) supports claims based identity.
In a nutshell this model is much more extensible (say Federation) and you don't have to worry about the nitty gritty details of security code. You can start using claims now against your existing AD and then easily move to phase 2 and 3 by just pointing to, or adding, a new identity provider that you 'trust'.
Azure AD will enable your customers to be able to sign in to your application using their on-premises (federated) AD identities or pure cloud managed identities (many O365 customers are pure cloud managed). Consumer IdP federation (MSA, Facebook, Google) isn't available with Azure AD yet - but it is something that is on our radar. Azure AD customers can already customize the sign-in page to add branding of their Organization - however the customization of sign-in page per application isn't available yet (also on our radar).
I am curious about the requirement of having arbitrary strings as username - why is this so important?
thanks
Related
I'm exploring options I have when it comes to implementing user authentication and authorization in Angular app with ASP.NET Core 3.1 backend that will be deployed to Azure AppService.
Only selected, invited users will be allowed to use application. There will be no "Create account" page accessible to everyone. There is a possibility that subset of those users will be our company users so leveraging their Active Directory identity and allowing SSO would be great. Application will be multi-tenant. Multi factor authentication might be needed for selected tenants/users (based on role for example). We don't want to allow logging in with 3rd party Identity Providers like FB, Google and so on.
Based on my explorations on I have 2 (4?) options.
ASP.NET Core Identity - simple, builtin, well known. But probably won't allow me to to implement SSO and users will need another login/pass. I'm not sure if it supports inviting users (out of the box) or is this something I would need to implement myself. Same with password resets. It allows me to add custom properties to stored user entity (TenantId) to allow me to implement multitenancy, but I need to deploy SQL Server database and manage it myself.
Azure AD (B2B, B2C) - this is new to me. How I understand it is that with Azure AD Connect I could synchronize users between AD and Azure AD and this would allow me to implement SSO for our company users. Only selected OU's could be synchronized and based on groups in AD they could be assigned different roles in our app. Then assigning roles is responsibility of people which are already managing those users in AD. If person is released and their account is removed/locked in AD they lose access to our app. If they're removed from specific group they lose access to our app. And probably all our company users are already in Azure AD - I see myself and my colleagues in it when I use my work e-mail to login to Azure portal. When it comes to supporting users which are not in our AD I tested that I can add "Guest users". At first I thought this is something I would need Azure AD B2C for but looks like it's not the case. Then what is Azure B2B and B2C for? In this case I don't need to manage SQL database and have user managment for free. Both on AD and Azure Portal site. I don't know if I can add custom properties to users (TenantId).
Which one of those options is better? Maybe there are other options?
Azure AD B2B is indeed the way to go for your requirements.
B2C is required when you would like to open up your application to external users while allowing them to login using social providers.
You can read more about the differences between Azure AD B2B and B2C.
I see the following message "To view and manage your registrations for converged applications, please visit the Microsoft Application Console." (screenshot) under AD app registration screen in Azure Portal? what is this all about?
Clicking on that link takes me to a different page where I can perform App Registrations, trying to understand the difference between registering in Azure portal and in other external site.
It appears that Microsoft has released a new feature in Azure Authentication to support Microsoft account and Organisation account authentication in a single Azure Active Directory v2 authentication endpoint.
Here is the link for the complete article https://blogs.technet.microsoft.com/enterprisemobility/2016/02/23/for-developers-the-first-use-cases-of-the-converged-microsoft-account-and-azure-active-directory-programming-model-are-now-ga/
Key extract from the article
Today I am excited to tell you that the first set of uses cases supported by the Azure Active Directory v2 authentication endpoint are generally available. With the v2 endpoint, you can now build applications that let users sign in using their Azure AD backed work, or school account, or their Microsoft Account using a single button.
Federated sign in has many benefits. If you accept sign ins from Microsoft, you can:
Store fewer passwords in your application and make yourself a less attractive target for attackers,
Avoid your users having to remember another name and password,
Give your users a single sign on experience if they are already signed in to Windows 10, Office 365, Outlook.com, OneDrive, or other Microsoft property,
Seamlessly integrate a user’s data such as their calendar or contacts,
Take advantage of Microsoft’s advanced anomalous sign in detection technology, and let us help you defend your user’s accounts.
With federated sign in, Microsoft can handle identity management for you. With the Azure Active Directory v2 endpoint, we’re making this easier than ever before. Until now, building an application that worked with both Microsoft work and school accounts and Microsoft personal accounts required adding two technology stacks to your application: the Microsoft account stack and the Azure Active Directory stack. We’re bringing these two systems together so that you can integrate once and enable both kinds of users to sign in using a single button:
This converged programming model is exposed by the Azure AD v2 authentication endpoint. Today we are excited to announce GA of the first two scenarios supported by the v2 endpoint:
iam currently researching how to implement Single Sign On for our WebService.
This is what i came up with so far.
If a customer of our WebService has an AzureActiveDirectory they can log on with their active directory user account to our WebService if we provide the nessecary interfaces for SAML, Oauth2, OpenID or whatever authorization protocoll we chose and azure supports.
The customers could also have their local network Active Directory synced to their Azure AD and use their Domain accounts to log on to our WebApplication.
Customers need to use the myapps.microsoft.com portal to "wrap" authentication.
Once everything is set up correctly the Identity Provider (AzureAD) would provide use with (e.g) an authenticated User Identity.
Here is were my problem begins.
Of course i need to somehow map the identity provided by the AzureAD to a certain Account for our WebService - we cannot simply use the provided identity.
As far as i understand it, you can grant AzureAD the right to create an Account on the target WebService in the name of the user which is currently signing in.
(Its called : enabling automatic user provisioning in the azure management portal).
However, when testing this with the Box, Canvas or Google apps i failed. Either i got an error or in the case of google apps i was just promted to login with my azure AD test account and then asked for a password and username of my google account (i set up SSO as an azure AD trust relation- so this should not happen)
Can someone provide some insights on how to accomplish the following?
Once the user is authenticated by SSO I want to create an account for our WebSerivce and then save the credentials for that user only in the Active directory of that particular user.
So if the user logs in the second time we can check wether there is an account already existing and log in the user with this account.
(I was told by microsoft that this might be possible with Azure Rights Management, but i cannot really find good documentation on that)
Storing the relationship: "Microsoft AD Identity <-> our WebServiceAccount Credentials" on our side is not desired because we cannot securly encrypt the data in a way that we DONT know whats in there. (or there is , and i dont know of it yet)
"Bonus Question":
Can i support SSO for a desktop application too? (Do i need a provide proxy web application or can the desktop app do this directly?)
Please see my answer to a similar question here: asp.net azure active directory user profile data
However - I'm trying to understand if you need something different. Are you expecting your customers to already have a directory and Azure AD accounts (maybe through having Office 365 subscriptions), and use those to sign in to your web app, or does your app scenario require creation/provisioning of user accounts into your customer's Azure AD directory? Provisioning can be done through graph API (as per your link), as long as the admin of your customer grants consent to allow your app to write to their directory. You can find some samples on github, and I recommend you look through https://msdn.microsoft.com/en-us/library/azure/dn499820.aspx and https://msdn.microsoft.com/en-us/library/azure/dn646737.aspx for code samples.
HTHs,
I think, without testing it. That using the Graph API enables me to save custom data for any Directory User effectively enabling my desired functionality.
This is the documentation i found very usefull.
https://msdn.microsoft.com/en-us/library/hh974476.aspx
We want to create a MVC web application using claims-based authentication, expecting roles as one of the claims. We want to Federate authentication providers using the Azure Access Control Service to manage this federation. One of the authentication providers is our Azure AD.
The problem is that Azure AD doesn't seem to be able to generate role (or even group) claims. What is the appropriate method to manage group or role access in Azure AD and have role claims served by Azure Access Control Service.
Thanks.
Edit:
A previous comment asked for details: We want to provide access to our cloud application to 3rd parties using their active directory (to simplify user management for them). Our application has a few levels of access to information that the 3rd parties can configure. We were hoping they could do this in their AD (based on our instructions). Groups seemed like the obvious choice, but if there is another way that works, as long as we can provide instructions, it'll work.
We want our application to get claims for a user's level of access. If we had only one partner that was using Azure AD, we could use the graph API against that endpoint, but with multiple partners changing over time, we wanted to federate them so our application only needs to trust the federation server. We were assuming that we needed Azure ACS to manage the federation.
AAD does support roles / groups and you can administer them from the Azure Portal.
Howeve, these are not passed in the "canned" set of claims.
You need to use the Graph API and then convert them e.g. Windows Azure Active Directory: Converting group memberships to role claims.
Update:
ACS requires something to federate with. You can't hook a customer AD up to ACS - you need something like ADFS on top of their AD.
I assume your cloud app. runs in Azure?
Then make your app. multi-tenanted. If your customers have their own Azure tenant, it will work. You just need to add the Graph API code to your app. ACS is not required.
Your customers then run DirSync. This keeps their Azure tenant in sync. with their AD changes.
So two options:
Customer does not have Azure tenant. They install ADFS and federate with AAD.
Customer's who do have Azure tenant use DirSync.
Good news: we have recently turned on the Application Roles and Groups Claim features in Azure AD.
Get a quick overview here: http://blogs.technet.com/b/ad/archive/2014/12/18/azure-active-directory-now-with-group-claims-and-application-roles.aspx
Deep dive post and video on app roles feature is here: http://www.dushyantgill.com/blog/2014/12/10/roles-based-access-control-in-cloud-applications-using-azure-ad/
Deep dive post and video on app roles feature is here: http://www.dushyantgill.com/blog/2014/12/10/authorization-cloud-applications-using-ad-groups/
Hope that helps.
Groups aren't the best choice because they are unique within each directory. Unless you get your customers to define a set of groups that have well-known names and match against the strings, that is (the object IDs of a group is different per directory even if they have the same name). I'm actually from the Azure AD team and we are seriously considering releasing a feature to allow you to define roles in your app that your customers can assign their users to. Please stay tuned on this. In the meantime, unfortunately groups are the only way to go. You would have to call "GetMemberGroups" using the Graph to retrieve the groups that the user is assigned to.
What are your timelines for releasing this application? You can contact me directly to see if we can work with your scenario.
I understand that WAAD is meant for internal organizational accounts. I understand the concepts behind ADFS and other "AD in the cloud" related topics. But is there really anything that is preventing WAAD to be used for public accounts?
I want to build a public facing web site using ASP.Net MVC. I will use WIF to implement claims authentication and plan to use ACS as a claims federation provider. I want to allow the end users to login using Social Network Accounts (out of the box with ACS). But I also want to allow users to register their own user name and passwords for my web site. Can I use WAAD for this part?
Of course I could build my own custom STS. Or I could use Thinktecture IdentityServer for this purpose. But there are some clear advantages of sticking with WAAD:
simplicity (to set up WAAD as a STS to ACS takes just few clicks)
performance, security, reliability guaranteed by Azure SLAs
Is there any disadvantage to this approach?
You certainly can use WAAD for creating user accounts. You, also of course, have to force users to use e-mail style logins.
There is however one (BIG in my opinion) disadvantage of WAAD against ThinkTecture's Identity Server: WAAD does not have a user registration / password management / password reset flow.
UPDATE (29.07.2014)
Today WAAD provides Self-service-password-reset as part of Premium Features. However still no self-service-user-registration. Frankly I do not expect to ever see self service user registration, as WAAD is targeting enterprises, and not your specific scenario.
To implement mentioned flow in WAAD, you have to developed your own MVC App from scratch, that uses the Graph API for all mentioned scenarios.
On the other side, you have Identity Server, which has thousands of downloads, which is developed by the Gurus of Claims based authentication and security. Identity server has very rich and easy to use extensible structure. While it also does not provide the user registration and password reset flows out of the box, it is already an MVC 4 application with very rich extensibility points.
Setting up an Identity server for run in Azure is also extremely easy. And setting up Identity Server as Identity provider in Azure ACS is just couple of clicks on the management portal.
You say that WAAD is SLA backed, highly available, etc. But your Identity Server deployment on a Cloud Service will be SLA backed too if use at least 2 instances of a Web Role.
If I have to chose whether to extend Identity Server to support user registration etc, or to create entirely new application from scratch that uses WAAD GRaph API for that feature - I would use Identity Server.
As of September this year the Azure B2C preview is there. This should satisfy the scenerio of self service user registration and different identity providers (Facebook, Google, Microsoft...). These are all serviced from AzureAD.
Azure AD b2c
There is als a complete MVC sample available
Azure AD b2c MVC Sample