Currently I have two applications with broken sso experience. Below is scenario :
Application 1 is Single Page Application, that uses Azure AD as an authorization end point and OAuth 2.0 implicit authorization grant to secure its web API back end (in short I refer this as Azure AD token base authentication) Almost similar to below flow :
Application 2 is a web application that uses OpenIDConnectAuthentication middleware in tandem with CookieAuthenticationMiddleWare and uses same Azure AD as authorization end point(in short I refer this as Azure AD cookie based authentication) Almost similar to below flow :
Is this broken SSO experience between application with token base authentication and application with cookie base authentication is expected ?
I accept I could have debugged and checked why and what before posting, but just wanted to see if its known issue before I go ahead with local code set up and all.
This is probably the best Azure Sample for achieving the experience you are looking for: https://github.com/Azure-Samples/active-directory-dotnet-webapp-openidconnect
You should not be prompted to enter the username and password a second time. At most you may have to click a second time to sign in but even that can be configured within the code. Here's a video my colleague and I made demonstrating how to set up this experience with two web apps using the Azure sample. Based on your description, this seems to be what you are looking to achieve.
Related
For my current ASP.NET Core MVC application I authenticate directly with a web app registered in Azure AD Portal. This provides me with an access token so on the backend of my web application I can use MS Graph with my users specific account (ie add files to their onedrive , email, etc). However, my organization also has Okta which a lot of applications authenticate against. So I was trying to determine to authenticate through Okta (which has a much cleaner sign in process IMO) as well as authenticate against Azure AD and get an access token. Through my research I found something in my web application registration in Azure AD called Workload Identity Federation. This led me to this useful video
https://www.youtube.com/watch?v=wZ0gCJYMUKI
and also microsofts info site:
https://learn.microsoft.com/en-us/azure/active-directory/develop/workload-identity-federation
This seems to answer what I want which is to use Okta but allow me to still use MS Graph for my users since it will authenticate against Azure AD (correct me if I am wrong and this is for something else). My issue is none of these resources really go into depth regarding how the access token is passed to my application so I can use MS Graph. My research this is called client credential flow since my application only has delegated permissions so it requires the users to log in and it basically allows my web app to act on their behalf when using MS Graph. So I am trying to understand and fill this void of information regarding how client credential flow fits into Workload Identity Federation and is this the solution to my problem.
I'm investigating options for adding AzureAD authentication to Angular SPA application with .NET core backend. I'm using VS 2019 MVC project with Angular (same as dotnet new Angular is producing). It's using .NET Core 3.1 and Angular 8.
From what I learned so far I have 3 options:
Built in Azure App Service Authentication
Adal.js - looks like the older brother of,
MSAL.js - which after making it work locally with Azure AD I learned on this page that "At this time, AAD V2 (including MSAL) is not supported for Azure App Services and Azure Functions. Please check back for updates." I couldn't make it work on Azure today so maybe this Note is for a good reason.
EDIT: Interestingly now point 3 works for me on Azure App Service so I'm not sure what this note means.
My requirements so far are that no screen is accessible to users unless they log in and that I will be able to read information about them from Azure AD - Roles, groups.
I never worked with Angular and I don't have any experience with Azure AD and I need someone that implemented it already to at least tell me which option I should choose and I can go from there.
My requirements so far are that no screen is accessible to users unless they log in and that I will be able to read information about them from Azure AD - Roles, groups.
I think the option 1 could meet your requirement, the configuration of Azure AD in Authentication / Authorization is higher than your code, the user could not access the app unless they log in.
To read the information about the roles, groups, you could check this good blog.
Here you have an angular E2E auth scenario using App Service built in authentication:
https://learn.microsoft.com/en-us/azure/app-service/app-service-web-tutorial-auth-aad
I believe the part you are interested in is this one:
Enable authentication and authorization for front-end app
This way app service is the one redirecting you to AAD and getting a valid token that you can just pass in to your APIs afterwards. If the APIs are hosted in App Service as well, then APP service will be the one validating the token for you, so your backend code does not need to worry about authentication (you still need to handle authorization)
I'm working on an application that has an angular 6 front end and a .net core 2.0 back-end and am trying to set it up so that my application authenticates users via Azure active directory. The issue is that I want the .net core back-end to do all the authentication programmatically when I have the front end pass an email and password. Everything that I've seen so far online suggests to have the front end redirect to the Microsoft login page but we are using our application as a boiler plate project and want to be able to change the type of authentication easily in the back-end without having to change the angular front-end. Does anyone know how I could go about this?
You can use Resource Owner Password Credentials Grant .The process will like that you collect the user credentials in Angular app and post to .net core back end , then finish the authentication in back-end app with user's credential. But that is not recommended because The ROPC flow requires a high degree of trust and user exposure and you should only use this flow when other, more secure, flows can't be used.
Also :
The Microsoft identity platform endpoint only supports ROPC for Azure AD tenants, not personal accounts. This means that you must use a tenant-specific endpoint (https://login.microsoftonline.com/{TenantId_or_Name}) or the organizations endpoint.
Personal accounts that are invited to an Azure AD tenant can't use ROPC.
Accounts that don't have passwords can't sign in through ROPC. For this scenario, we recommend that you use a different flow for your app instead.
If users need to use multi-factor authentication (MFA) to log in to the application, they will be blocked instead.
Reference : https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-oauth-ropc
New to Azure AD... So please don't be too harsh if this is off target. :-)
Technology Stack - Latest Angular 2 with C# Middle tier and latest .Net Framework.
Ideally, What we want to do is use Azure AD B2C to store user credentials and to do the authentication - but we want our 'own' forms on our site to do the login Forms capture and logging - then pass the credentials through an API (REST?) Call (using MS Graph SDK?) to Azure AD B2C and then check the call return for the Authorization content message.
Couple of reasons - control of the application flow, Logging and the "flickering of the URL" (i.e. going from our site URL to login.microsoft... URL and then back to our sites URL).
Is this doable without doing a hack?
Thank you in advance for your help and patience!
You are looking for the "Resource Owner Password Credentials".
This is not currently supported for Azure AD B2C, but you can give user feedback to the B2C team that you want this through the Azure Feedback Forum: Add support for Resource Owner Password Credentials flow in Azure AD B2C and headless authentication in Microsoft Authentication Library
You should also see updates at that location if and when they implement this feature.
The resource owner password credentials flow is now in preview.
In Azure Active Directory (Azure AD) B2C, the following options are
supported:
Native Client: User interaction during authentication happens when
code runs on a user-side device. The device can be a mobile
application that's running in a native operating system, such as
Android, or running in a browser, such as JavaScript.
Public client flow: Only user credentials, gathered by an application, are sent in
the API call. The credentials of the application are not sent.
Add new claims: The ID token contents can be changed to add new claims.
The following flows are not supported:
Server-to-server: The identity protection system needs a reliable IP
address gathered from the caller (the native client) as part of the
interaction. In a server-side API call, only the server’s IP address
is used. If a dynamic threshold of failed authentications is exceeded,
the identity protection system may identify a repeated IP address as
an attacker.
Confidential client flow: The application client ID is
validated, but the application secret is not validated.
From here.
Note that one disadvantage of doing what you're requesting is precisely that you can do "login forms capture and logging", so your application has a chance to see the credentials and perhaps take copies of them; thus your users have to trust you to behave.
The normal web-based flow means that your application doesn't need to be trusted; it never even sees the password at all.
I'm tried to build a new rich application and i'm having some problems designing the authentication process.
I've only two requirements :
An API needs to be available
An ADFS needs to be used to authentication
My first thoughts was to build the API and to use Angular.js for the frontend. However, I can't see how the authentication should work.
My API needs to be available though scripts. As far as I saw, the ADFS authentication always display t the webpage for the authentication process.
API are usually secured with OAuth2. We used an client id and a client secret to generate a token. But I can't have this behavior with an ADFS.
The only solution I see is to provide two authentications behavior with my application. One with the ADFS for the web access and in the web interface, add a possibility to generate a client id and a client secret associated with an user account that could be used for the API to the headless authentication.
Someone has already faced this kind of scenario?
Thanks a lot!
I assume the 'ADFS needs to be used for authentication' really means 'users should be able to use their Active Directory domain credentials to authenticate'.
If that is the case, you should take a look at Thinktecture IdentityServer. It's an OAuth2 authorization server that you can use with a Active Directory identity provider.
P.S. ADFS 3.0 that comes with Windows 2012R2 only supports the authorization code grant, which is not suitable for JavaScript apps.