So I recently started exploring Azure Identity Platform for this user authorization use case I'm trying to implement. After a bit of research I came across using Graph API and creating ROPC flows to handle SingUp and Login via REST API from my application. My requirement is also to allow users to use login credentials from another app (I'm not sure yet if it implements a SAML based Identity Provider method) to use services in my application. This is a typical SSO requirement, but I'm not sure if it is possible to implement alongside username-password based authentication using Azure AD B2C.
I would appreciate any leads. Thank you.
Edit: To be more precise, I am working with Java-Spring. The demo application mentioned in Azure AD documentation (Woodgrove groceries) is exactly what I'm trying to achieve. A quick google search for the same provides me with github repos with sample code that uses .Net I believe. Are there any Java sample codes that demonstrate the same?
ROPC does not support SSO if that's what you want to achieve.
Related
We have on-prem sql server database which is connected to a legacy application. The on-prem database contains the username and password for the users. We are in process of migrating the existing solution to Cloud, and using Azure AD B2C for Authentication.
As the existing system is very big, so there is a phased transition we need to do which means keeping the both system running, allowing the users to login to the existing app as well as through Azure AD B2C in the cloud app.
I stumbled across API connectors for Azure AD B2C. I want to know if its possible to implement API connector for Sign In flow, in a way that it does the authentication against the external database store (legacy database) instead of Azure AD B2C.
From whatever I researched on google, it seems that API connector is called after authentication only. Also all the samples were related to Sign up flow. Can someone please guide me for a sample to achieve the login through external database using API connector ?
B2C supports integrating external identity providers. You can find a full list of them here:
https://learn.microsoft.com/en-us/azure/active-directory-b2c/identity-provider-local?pivots=b2c-custom-policy
However, you are seeking to use a custom (generic) identity provider (IDP). This scenario is supported if the custom IDP supports either the OpenID Connector (OIDC) or SAML protocols. Please check that list in the URL above to review these options.
Regarding using the API connector, you can invoke the API connector before the authentication occurs in B2C using a validation technical profile in a custom policy. However, that does not achieve the actual authentication based on OIDC. Instead, it would be considered a validation step.
An overview of when you can use API Connectors is here.
You might be able to achieve a type of workaround using a custom policy to invoke your API connector to authenticate before authenticating in B2C and returning a success flag.
However, I think a better idea is to implement password synchronization. This seems like a perfect fit for you based on what you described. Users would be able to log into both your local system and Azure B2C simultaneously until you decommission your legacy authentication mechanism.
Your main requirement is that you have use a Microsoft Graph API SDK to update the B2C account password via your application backend. The bottom line is that you just need to keep the passwords the same in both systems. This is very easy to achieve with the Graph API, especially if you are developing in C# / .NET.
You also have to figure out how the B2C accounts get provisioned in the first place. This can happen in several different ways depending on your business requirements: Graph API, user sign up flow, import operation, etc.
API connectors only work for sign-up.
There's an example here but you will have to use custom policies.
I have created a web application using Django and embedded the azure chatbot after publishing it. Once the user logs into the Web App, i would like to transmit login info to the chatbot embedded on the app in order to give customized interactions e.g. "Hello Richard, How may i help you?" etc.. I believe Azure AD SSO is a good option. But couldn't find good resources on how to implement it for my use case.
Is AAD SSO the best option?,
If yes, can anyone please guide me to resources that i can refer to implement it.
If no, please provide some info on what's the most optimal approach for this use case.
Here's the samples for Bot Authentication and Bot Authentication with Azure and MSGraph, as well as the documentation on user auth in bots.
If your users can be authenticated using Azure AD SSO, then yes, it's a good solution.
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.
I am trying to authenticate user against Azure AD using a web API.We are trying build a SPA and native app for iOS, we are trying to have the API take care of the authentication for us.I looked at this and this and understood that its not possible.
I just want to find out if there is any work around for my scenario.
This question is not a duplicate
#juunas is correct. You want to use something like ADAL to allow the user to authenticate against AAD for access to the Graph API and then use that auth token to access the graph. Microsoft has an example which may be useful to you over here. It's written in objective C, but there are other SPA examples out there if you search for ADAL, SPA, and Graph API.
I am building a Xamarin app that will need to have users authenticated and each user will have a role. Would Azure AD OAuth 2.0 be a good solution for this scenario? Each person that downloads my app would register which would create an Azure AD user? At first I thought Azure AD was strictly for managing users within an organizations and not a way to authorize thousands of users of an app. Would I be able to seamlessly integrate Azure OAuth into my app without having to leave my app (like I would need to do with Google or Facebook OAuth)? Thanks for any clarification that would help me better understand!!
The Xamarin experience can leverage ADAL / MSAL PCL libraries for authentication (in Alpha right now) - available on nuget. You need to look at the new Azure AD Business to Consumer (B2C) offering (in preview right now).
Note that the OAuth experience this provides leverages WebViews inside of your app to perform user authentication so it doesn't differ from what you wish to avoid.
While you could theoretically change that behaviour by custom coding a solution it's probably worth considering the benefits of handing off authentication and only having to deal with the resulting tokens.