I'm trying to follow an Azure sample to integrate Azure AD into my MVC 4.6 web app via WSFederation provided here https://github.com/Azure-Samples/active-directory-dotnet-webapp-wsfederation
This sample uses cookies to store authentication token. After reading few articles, I'm bit confused with the choice of cookies to store authentication token generated by WS-Federation. Are there recommended alternatives?
Also, this web app would host webapi controllers too as part of same project.
Thanks for your help!
The is some misunderstanding about the store the token using cookies.
When the app is redirected to Azure AD and the users enter the correct username and passwords, the app will verify the token from Azure AD and sign-in the web app.
Then the cookies authentication middle ware would append the cookies based on the claims of sign-in user for the users visit the page without login-in again.
And based on the preview threads, it seems that you want to using the token to protect the MVC application and web API. As I metioned that the MVC web page is user-oriented, cookie authentication is recommend.
Related
I am using Azure SSO Login to get authenticated to our own application.
Everything works fine except the fact that I would like to have JSON Web Token (JWT) which I could use in order to make some API calls to Microsoft Azure after login.
Azure SSO does not return JWT after login, is there any way to obtain it?
Mirko
Scenarios that you may refer to get idea in addition with #juunas suggestion:
This Microsoft docs tutorial of JavaScript single-page
application (SPA) signs in users and calls Microsoft Graph by using
the authorization code flow with PKCE. The SPA uses the Microsoft
Authentication Library (MSAL) for JavaScript v2.0.
This scenario uses js frontend and php backend with azure ad which might give an idea
Its Flow :
A user accesses front end
If the user is not authenticated, he will be redirected to Azure Active Directory (AAD) to login
AAD will redirect (on success) with an authorization token
We’ll inject this authorization token into the calls made to the backend (to prove your identity)
The backend API will validate the authorization token and verify it against the issuer (AAD)
Protect an API by using OAuth 2.0 with Azure Active Directory> This case registers two apps for azure AD - backend app and front end app ,uses validate-jwt policy to validate the OAuth token
I have two Azure Web Apps, one is a website and acting as the front-end, the other one is an API and acting as the backend. I would like to add authentication to this solution so only the front-end can access the backend. To do this, I've configured AAD authentication on the backend Web App with the express option that creates a new Azure AD application configured with the correct reply URL, API permissions (User.Read), etc. When I then navigate to the backend Web App URL, I need to sign-in with my Azure AD credentials.
Which steps do I need to take to restrict that so I as an user cannot login and only the front-end Web App can authenticate to the backend API?
For example, I can set the "Authorized client applications" on the Azure AD application of the backend API. However, I need to have an application ID to add an authorized client and I would like to use the Managed Identity of the front-end Web App for this, not a new and additional Azure AD application.
Any idea how to do this?
This is weird, if the login screen still appears, there is a problem with your code configuration, because the client credential flow does not involve user interaction.
I found a useful sample for your reference, this sample application shows how to use the Microsoft identity platform to access the data from a protected Web API, in a non-interactive process. It uses the OAuth 2 client credentials grant to acquire an access token, which is then used to call the Web API.
Scenario
There is one user store, namely an on-premises AD. ADFS provides authentication for SharePoint 2013 and Power BI.
The custom web app needs to authenticate users from AD. The web app back-end also requires access to the SharePoint REST API.
The objective is to achieve the above using a single sign on. If singed in to any one of the three applications, the user should not have to input credentials for any of the other two. As well, the custom web app displays content from SharePoint (iFrame and REST API) and Power BI (iFrame).
We have tried the following two solutions but have come across an issue in either case.
Solution 1
User inputs credentials in the web app.
The web app back-end uses these credentials to get a SAML token from ADFS.
The web app back-end uses the SAML token to authenticate the user with SharePoint through forms-based authentication and retrieves a FedAuth cookie.
The web app back-end uses the FedAuth cookie to make REST API requests to SharePoint
The web app front-end uses the SAML token to authenticate the user with SharePoint through forms-based authentication. This allows SharePoint content in iFrames.
What doesn't work: Navigating to Power BI or including it in an iFrame will redirect the user to the ADFS sign in page. This is because the user has not been authenticated with ADFS in the browser yet.
Solution 2
ADFS SSO is used for the custom web app as well.
Navigating to any of the three applications redirects the user to the ADFS sign in page
The user inputs their credentials and get redirected back to the application with a SAML token.
Navigating to any of the other two applications will redirect the user to ADFS, which will redirect back to the application with another SAML token without requiring the user to sign in again.
This allows for both SharePoint and Power BI content to be included in the web app in iFrames.
What doesn't work: The web app can't make REST API request to SharePoint using the SAML token received from ADFS for the web app. We have tried to use that SAML token to request another one from ADFS for SharePoint on behalf of the user signed in. That did not work either. As well, SharePoint 2013 on-premises may not accept an on behalf of request.
Question
Is there a way to have SSO for all three applications while also having REST API access to SharePoint from the web app? The user should have to sign in only once, and preferably only in to the web app.
Registering your applications through Azure Active Directory is probably the best way to achieve what you are looking for. You can register the applications in Azure AD and then grant permissions to users by application, tenant, or policy. https://learn.microsoft.com/en-us/power-bi/developer/embed-sample-for-customers
https://learn.microsoft.com/en-us/power-bi/developer/create-an-azure-active-directory-tenant
At the moment I have an app that uses Azure Mobile App Services to manage offline sync as well as authentiation. Authentication is done with Azure Active Directory and the way that I have it setup is that the web api is published as an app service on azure and it is configured as an app in the Active Directory Section. The Native App which is done in Xamarin.Forms is also configured in azure so that whenever the app makes a request it can properly authenticate with the api.
What I want to do now is take this web api and put it in an on-premise server. I have to do this in order to optimize some latency issues that I am having when retrieving data. My question is how can I use the offline sync functionality with the api in and on-premise server while still using Azure Active Directory as my authenticator.
Where I am mostly having issues is with the authentication part of the implementation.
I appreciate any help.
According to your description, you are using Authentication and authorization in Azure App Service for build-in authentication without having to change code on the app backend. Authentication / Authorization for Azure App Service (Easy Auth) is implemented as a native IIS module that runs on Azure side, details you could follow Architecture of Azure App Service Authentication / Authorization.
My question is how can I use the offline sync functionality with the api in and on-premise server while still using Azure Active Directory as my authenticator.
AFAIK, we could not install the native IIS module easyauth.dll. Based on your scenario, you need to do some additional work to achieve your purpose.
For .NET backend, you could use Microsoft.Azure.Mobile.Server.Authentication OWIN middleware to validate tokens (the JWT authenticationToken). Note: This middle-ware is used to local development and debugging the mobile app .net server on your side.
For Client-managed authentication flow
You need to add a additional endpoint in your app backend for receiving the access_token returned by AAD to the client user, then your app backend would use the access token to access the signed-in user endpoint (e.g. https://graph.windows.net/me?api-version=1.6) to retrieve the user basic info, then encode user info into a JWT token and return to your client. Here is an example for generating the JWT token, you could refer to it.
Note: The App Service build-in authentication would also generate the JWT authenticationToken to the mobile client. For this approach, you retrieve the signed-in user information manually and follow the custom-auth to generate the token by yourself.
For Server-managed authentication flow
You need to provide a login endpoint and redirect the user the AD authorization endpoint, then your app backend receive the authorization_code and retrieve the access_token, then access signed-in user info via the access_token, then encode the user claims to JWT authenticationToken and redirect the token (e.g. https://{your-domain}/.auth/login/done#token={the-json-string-of-LoginResult}) to the client user.
Note: The above two approaches are used to implement some similar features from Easy Auth in your on-premise server.
Moreover, you could just use the middlewares UseWindowsAzureActiveDirectoryBearerAuthentication for AAD v1.0 endpoint or UseOAuthBearerAuthentication for AAD v2.0 endpoint to project your web API instead of the authentication middleware provided by Microsoft.Azure.Mobile.Server.Authentication. Here are some tutorials, you could follow them:
Azure AD .NET Web API getting started
Secure an MVC web API with AAD v2.0 endpoint
For this approach, your mobile client could leverage the ADAL or MSAL client library for acquiring the token. Then when you implement the MobileServiceClient instance, you could specific a custom DelegatingHandler for adding the authorization header with the value to the access token you acquired as the bearer token against your Web API backend. Details you could follow the How to: Customize request headers section under Working with the client SDK.
I need to allow authentication using my ASP.Net Identity from the MVC app (merged into the Mobile App service project) and from the mobile client (Android). Furthermore, I need to allow social authentication providers (Facebook and Google, to be exactly) to be used from the mobile client.
Adrian Hall's book says that for custom auth to work we should not configure the other authentication providers. So, how can I enable both forms of authentication?
I don't remember saying that. I'll have to check. You need to be careful though.
In your MVC app, you need to decide on ASP.NET identity or App Service Identity. If you choose ASP.NET identity, then you have to decide how your mobile application is going to authenticate - you are in completely custom area. If you are using App Service Identity, you need to decide how your application is going to authenticate (since the redirect can only go to one place).
I'd probably do App Service Identity. Configure Facebook and Google first. Then create a custom mobile auth endpoint. For your MVC side, configure a redirect page that displays the "choose your auth provider" page and then directs the user to the appropriate page - Google (/.auth/login/google) or
Facebook (/.auth/login/facebook) or custom (which you will create).
All the redirects will then point back to the callback page so the tokens get stored properly.