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:
Related
I am not entirely sure about what can guest users in Azure can do.
as to my understanding guest users gain accesses to my azure portal if I allow them. But, is there any possibility to authenticate guest users in my application using the ADAL library? or the ADAL library are looking for a created Microsoft Azure User? I would like for the authentication to take place in my .NET based server. I look at this guide:
https://learn.microsoft.com/en-us/azure/active-directory/develop/tutorial-v2-asp-webapp
and it says:
"At the end of this guide, your application will be able to accept sign-ins of personal accounts (including outlook.com, live.com, and others) as well as work and school accounts from any company or organization that has integrated with Azure Active Directory."
How can I able my guest users to access as well?
Thanks!
How can I able my guest users to access as well?
First step is to have these external users add to your Azure AD. Any arbitrary user will not be able to sign in into your application.
Next, in your requests for authentication/authorization, you will need to use your tenant endpoint i.e. yourazureadname.onmicrosoft.com instead of common endpoint.
Step 9 in the link you shared, you would need to change the value of tenant configuration setting:
<add key="Tenant" value="yourazureadname.onmicrosoft.com" />
<add key="Authority" value="https://login.microsoftonline.com/{0}/v2.0" />
there are two main questions regarding the architecture of your application and your audience or users.
as described in here:
https://learn.microsoft.com/en-us/azure/active-directory/develop/azure-ad-endpoint-comparison
if you're application is targeting people with personal emails (outlook, gmail).. you should think of B2C authentication
if you're targeting companies that have azure ad, then you have a B2B scenario.
you can find a comparison in here:
https://learn.microsoft.com/en-us/azure/active-directory/b2b/compare-with-b2c
if you are using AAD V2 Endpoint you have to use the Microsoft Authentication Library (MSAL) is designed to work with the Azure AD v2.0 endpoint.
https://learn.microsoft.com/en-us/azure/active-directory/develop/reference-v2-libraries
Azure Guest users are external users to your AAD subscription, Guest users from other tenants can be invited by administrators or by other users. This capability also applies to social identities such as Microsoft accounts which can be more of security issue or hard to manage to some organizations.
https://learn.microsoft.com/en-us/azure/active-directory/governance/manage-guest-access-with-access-reviews
I've got the Unity Xbox Live services example up and running allowing me to sign-in to my Microsoft Account via Xbox Live services in Unity.
I've also got Azure App Services (Mobile services) running in Unity to query and persist my data. App Services supports authentication out of the box including Microsoft Account support.
Does anyone know if I can use the authentication from Xbox Live services sign-in to authentication my web calls against my Microsoft Account in App Services?
It gets complicated :) although I can understand the frustration. Let me give a quick overview, but I'm happy to give more details as needed.
When dealing with sign-in, the first step is authentication - and there are three choices on such systems with Microsoft
1. MSA, or Microsoft Account, which is what most consumer systems use, such as Xbox.
2. AAD, or Azure Active Directory, which is typically for enterprise applications.
3. S2S, or Server to Server, which is typically done either with an SSL certificate or shared secret. (Note this is also similar to the app secret mentioned above, although app secret is less secure since the secret is with the app itself, but this and MSA do go together).
These three systems are very different in goals, designs and requirements so there isn't really an option to unify them.
Now lets assume that you are using only #1 above - signing in with MSA. You might wonder why you can't take the token returned for one set of services and use it with another. Now we are into the realm of user privacy and security isolation. Have you noticed when you sign into a game on the PC with XboxLive that you get a dialog box asking if it is okay? That is the consent dialog and is required so that malicious apps can't steal a token for one part of a system (say your outlook.com sign-in) and use it to grab data from elsewhere (onedrive, xbox, etc) without the user saying "yes, that is okay". This same thing happens with systems like Facebook, etc - it is a fairly standard system.
So, to enable this, each time you ask MSA for a token, you have to specify the site you are going to use it with, so MSA knows what consent to ask for - and to ensure it stays only to that site.
tl;dr - doing security right means more hassles :) But the good news is that the underlying system should be able to detect these and prevent the user from having to present a sign-in for each site - just one sign-in, but possibly multiple consent dialogs. And more code for the developer...
Does anyone know if I can use the authentication from Xbox Live services sign-in to authentication my web calls against my Microsoft Account in App Services?
AFAIK, for app service authentication with Microsoft Account, you need to create the application in Microsoft Account Developer Center, then you need to add Client Id and Client Secret for your Microsoft Account provider under "Settings > Authentication / Authorization" of your App Service application. For more details, you could refer to Microsoft Account authentication.
Based on your scenario, you could only use the Client-managed authentication for Microsoft Account. Additionally, the app service authentication for Microsoft Account uses LiveSDK for initiating the sign-in process. Though, I'm not familiar with Xbox Live services sign-in, based on my understanding, I assumed that you could not achieve this purpose for now.
I am creating a web api application that will be secured using Oauth for authentication. Can I set up the authentication to be a blend of individual accounts and organizational accounts?
Scenario: One set of users belongs to an organization that uses Office 365. Another set of users may not. The ultimate goal is to allow all the users to login, but in the case of the organizational users, I will also want to allow them to integrate with the Office365 apis that are tied to their organization.
Is there a solution design that would allow me to choose where to authenticate the user - either using the application's Azure AD or the subscribing organization's AD?
For just authenticating MSAs and AAD orgs, you can use the new Microsoft Graph (http://graph.microsoft.io) - it is the unified endpoint for all Microsoft identities and for requesting access to things like mail, calendar, etc. It uses the v2 AAD endpoint (mentioned below) and app registrations are universal, so you can sign in with org or personal accounts.
You can extend that with Azure B2C as the owning directory.
Add Microsoft Account as an identity provider, and
use the v2 endpoint
at which point users could sign in with a consumer account (Facebook, Microsoft, google, whatever). By extension, since, for MSAs it uses the new v2 endpoint you can prompt users to sign in with an MSA or an org cccount - users get a prompt like this below. Note 'work or school, or personal microsoft account.'
v2 has some limitations, however: https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-v2-compare so make sure you can do everything you want before diving in. Some of the reply URL and on-behalf-of flows (like you'd see in APIs) have some domain/audience restrictions.
I'm creating a Node app that uses OAuth2 to login a user and use the Office365 API to send and receive email, and possibly contacts and calendar events.
I have no need for Azure Active Directory that I know of. However, I am unsure of whether or not I need to register the app with Azure for the OAuth flow.
At first I followed this tutorial, which involves registering the app in the "Application Registration Portal." The OAuth token I receive currently works with the REST API for Outlook. No Azure.
Then I saw this tutorial, which seems to suggest that any app using the Office365 APIs should register an app with Azure. I don't want to do this if I don't have to, mainly because of the cost.
It is not clear to me why I need to sign up for one or the other, and my main concern is that the first tutorial is dated to the point that my app's registration with the "Application Registration Portal" will become deprecated and I will need to switch over to registration with Azure at some point. I have seen plenty of outdated tutorials and information from MS that are not clearly marked as deprecated. Can anyone help clear this up?
Sorry for the confusion. The short answer is that both these methods are still relevant, so none of them are deprecated yet.
Firstly, you're right that you need to register your app to call the Office 365 APIs.
And, you're also right that there are currently two different places to register an app: the App Registration Portal and the Active Directory section under the Azure Management Portal.
Registering on either one of these is enough to get you to a comfortable state where you can call the Office 365 APIs.
However, the convergence of the Outlook.com stack with the Exchange stack means that you are now also able to use the Office 365 Mail, Calendar and Contacts API against consumer Outlook.com accounts in addition to Office 365 accounts. If you wish to take advantage of this, you should register your app in the Application Registration Portal and NOT the Azure Management Portal.
Another advantage of registering through the Application Registration Portal is the support of dynamic permissions scopes. You don't have to specify upfront when you register your app what permissions it requires; rather, you can request permissions at runtime using the scopes parameter.
This new v2 app model for apps registered in the Application Registration Portal is currently in preview. A reason not to register apps in the Application Registration Portal is if they will be using more than just the Mail, Calendar and Contacts APIs. e.g. if your app is also using the OneDrive for Business Files API, you wouldn't be able to request tokens using the v2 app model's endpoint. In that case, you should register your app in the Active Directory section under the Azure Management Portal.
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