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.
Related
I am having an unusual hard time finding an example of how to develop a multi-user Xamarin.Forms app. Imagine you wanted to develop an app for UWP, iOS and Android that users can log into and then "do stuff".
It does not matter what - for example taking notes for later access.
Since I am using Microsoft Azure, I would love to have an example which makes use of Azure Active Directory B2C for authentication (including the usage of identity providers such as Microsoft, Facebook, Google, etc.) and Azure Mobile App Service / Azure SQL, etc.
While there are samples available that show how to use ADB2C I didn't find anything related to how you would implement a multi-user app (e.g. best strategies for the database schema, access management and how this works best with an own Restful API backend and how to include it in your client code, i.e. Model, Controller,...)
Does anyone of you happen to know an end-to-end sample for this type of Scenario?
Best regards,
Christian.
To setup authentication for B2C, I would recommend MSAL. Here are some samples:
https://github.com/Azure-Samples/active-directory-b2c-xamarin-native
There are also samples available for the WebApi.
This is a simple Xamarin Forms app showcasing how to use MSAL to authenticate users via Azure Active Directory B2C, and access an ASP.NET Web API with the resulting token.
If you want to know how to setup your database to actually store user data, I would recommend using the claims provided in the token to identify the user. The best way identify the user reliably would be to use the objectId claim. It stays the same even if the user changes their email address.
The claims can also be used to show user information in your app, e.g. display name or email. You need to add the scope profile to your authentication request to get this data.
We need to build a desktop (using angular4) and a mobile application (using react-native) that supports single sign on for our clients who are using ADFS in their organisations. We are looking forward to implement outh2 authentication on desktop and mobile app.
Can someone please guide how can we implement it. Should the app(s) be registered at azure-portal or apps.dev.microsoft.com? Do we need a backend API, what would this backend api do?
Thanks.
You need to register your app on azure.portal if you want to support sign in with Active Directory organizational or work accounts, which I believe is your case.
The apps.dev.microsoft.com portal is for registering apps that want to support sign in with both AD work accounts and Microsoft personal accounts.
You can read this article to get an idea of the different application types and platforms that are supported.
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:
I am looking at Windows Azure ACS as an alternative to implementing my own username / password scheme in my app. This will be a publicly available website.
In addition to using SSO providers such as Google or Facebook, can I use Windows Azure ACS to support username/password authentication?
I see that it supports Active Directory as a provider. I am not sure this is the right thing as I have always thought of Active Directory as an "enterprise" provider.
Windows Azure ACS does not support username/password authentication in the form you need. Shahin outlined it in details.
Your options really are:
Windows Azure Active Directory (WAAD)
Identity Server (IdSVR)
While classic on-premises Active Directory deployed with a Domain Controller option is indeed quite enterprisy, WAAD is not exact copy of the same in the Cloud. I would actually recommend that you give a shot and try out. Using the WAAD Graph API you can fully automate user management in WAAD.
Your second option is based on IdSVR. This is full-featured Identity Server and Security Token Service. It is developed against the best practices in security and is quite easily extensible! While it does not provide out of the box support for user management (user registration, password reset, etc.) it is ASP.NET MVC 4 application. So you can very easily add this features yourself. There actually is an open enhancement planned for User Management API and UI.
Both WAAD and IdSVR integrate well with ACS, so you can provide seamless support for social identities along with own login.
Another service that is still in Beta/Preview is the SocialSTS project. It is kind of extension to Azure ACS and is designed to help you add more identity providers (such as LinkedIn, Twitter, GitHUB, Amazon Login, etc) to your Access Control Service.
You can authenticate directly with the ACS by using Service Identities, but they are not intended to be used for end-user authentication, as the page explains:
Service identities are not intended to be used as end-user credentials. In ACS, service identities are most commonly used in REST web service scenarios, over the OAuth WRAP protocol, where a client requests a SWT token directly from ACS to present to the web service.
I believe this is the only way to directly get a token from the ACS.
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