I'm trying to achieve completely "serverless" status for my app with some simple CRUD operations, so my current approach is Blazor WASM on front-end and CosmosDB as records storage. I've configured AAD (Azure Active Directory) authentication in my Blazor App, and as for now, I'm wondering, if there is any way to to restrict CosmosDB client in Blazor to read only records which belongs to current user specifically (each record has UserId field)?
So, the main thing that I want to know, if it is possible at all?
Because I've found a plenty of different documentation, but because of lack of experience with Azure, I can't completely figure it out.
Thank you in advance!
P.S. The main solution I would like to approach - completely avoid any backend (API/servers/Azure Functions), because I really want to make it just Client App <-> CosmosDB, and AFAIK Firebase with JavaScript FrontEnd allows to do such a trick, but I'm interested in Azure-specific solution here
I don't have a simple walkthrough for Blazor, but overall the process would be similar to this guidance: Authenticate Users with an Azure Cosmos DB Document Database and Xamarin.Forms but it requires setup of an API service to broker the connections, which you specifically have asked to avoid.
If you didn't use an automated Resource Token Broker then in your logic somewhere you would need to store a map of somekind to resolve the Cosmos DB Resource Tokens for the logged in user.
In the following guidance, replace Xamarin with Blazor and Facebook with Azure AD:
On login, the Blazor WASM contacts Azure App Service to initiate an authentication flow.
Azure App Service performs an Open Auth flow with Azure AD. After the authentication flow completes, the Blazor WASM receives an access token.
The Blazor WASM uses the access token to request a resource token from the resource token broker.
The resource token broker uses the access token to request the user's identity from Azure AD. The user's identity is then used to request a resource token from Cosmos DB, which is used to grant read/write access to the authenticated user's partitioned collection.
The Blazor WASM uses the resource token to directly access Cosmos DB resources with the permissions defined by the resource token.
Related
I'm creating a centralized authentication system for multiple mobile applications. Its architecture is based on the OpenID Connect flow through the use of OAuth2.0 with IdentityServer4 on ASP.NET Core Identity.
I have researched a lot and in the main implementations with the Authorization Code Flow observed there is always the redirection of the user from the mobile app UI to the server web views, to allow the management of its profile.
This is very uncomfortable, because it significantly compromises the UX. I would like the user to be able to register and authenticate himself directly from the app interface without any redirection that involves opening a browser. Is there a way to do this with only API calls, from the client backend to the centralized authorization server?
You can use the Resource Owner Password Credentials grant type where you can pass the user credentials to the token endpoint and receive an access token. But usage of the ROPC grant type is highly discouraged as you can read in this blog post from Scott Brady, one of the creators of Identity Server.
What I can propose to you is to use Authorization Code flow to login the user and get access token for them, and then creating your custom API endpoints on identity server for user management. More on custom api endpoints here
We have a SPA(Single Page Application) with a .net core web api backend.
We want to use Azure AD for the authentication and authorisation as we will have at least 3 separate clients using AD, but looking online there is no definitive approach and its like piecing together a 50,000 piece jigsaw!
I have setup the azure api with Authentication and Authorisation, as shown in the image below, but is this the right place? as I believe I want this in the web API code, so I can then get the claims (permissions/roles) specific to the application.
There is mention of Identity but do I want to use Identity? as this sounds like it is your own database and not AD.
Should we be using B2C or B2B authentication? and does this support authorisation, as the end goal is to definer custom claims specific to the application, so we can grant and deny specific actions.
What you are using now is the built-in authentication for Azure App Service. You can sign in users and access data by writing minimal or no code in your web api. But it is not appropriate for complex scenario.
As you want to custom the application permissions/roles to specific users, it is recommended that you protect your webapi with Azure AD yourself. It is more flexible to custom your authentication. You can refer to this sample,the TodoListService part.
Should we be using B2C or B2B authentication?
Azure AD B2B is not a separate service but a feature in Azure AD.
Azure AD B2C is an independent service for building a consumer application identity repository. If you need a service to handle email or Facebook login – it is there for you.
Based on your description, I guess Azure AD is your option.
Reference:
Add authorization using app roles & roles claims to an ASP.NET Core web app thats signs-in users with the Microsoft identity platform
Compare B2B collaboration and B2C in Azure Active Directory
I watched this video on pluralsight
https://app.pluralsight.com/library/courses/authentication-authorization-aspnet-core/table-of-contents
This helped to make a bit more sense of it, actually near the end he shows that you can just create a .net core web app and then change authentication and choose a multi Azure AD option as shown in the below example. This then just works out the box! Not fully for a Vue Single page app though which is still a problem.
I'm not really sure what to call this but basically I have a service app that just serves up an API while occasional calling external APIs in the background to keep the data updated. Aside from authenticating to the external APIs there is no other authentication on this app.
Then, I have a front end app that uses the API of the service app to get data and display it to the user, and optionally modify some of the data. This app is setup to authenticate against Azure AD and has app roles setup to restrict access to various sections.
How would I secure the service app API so only calls from the front end app are served, and everything else gets rejected with 401?
You can protect the API by using OAuth with Azure AD. The below overview can help you out with your scenario:
Register an application in Azure AD to represent the API. Reference
Basically in this step, you will be making sure only the application (your app) who has permission can access the API.
Register another application in Azure AD to represent a client application.
Reference.
In this step, you are creating another application representing your app so that trust can be created between API and your app.
Grant permission in Azure AD. Reference.
In this step, you are giving permission to your app to access your API.
Make use of Client Credential flow to authenticate your app to your API. Reference.
In this step, you will be configuring your app with the information of Azure AD application of the API. Using that information, you will be retrieving access token and you need to pass this access token to your API.
I am trialling Azure B2C Customer Preview and have configured a new application, set up policies e.t.c and I now want to write some integration tests that use a non-interactive flow to connect and interact with my protected WebApi services.
However, I have just read the following quote:
Daemons/Server Side Apps
Apps that contain long running processes or that operate without the
presence of a user also need a way to access secured resources, such
as Web APIs. These apps can authenticate and get tokens using the
app's identity (rather than a user's delegated identity) using the
OAuth 2.0 client credentials flow.
This flow is not currently supported by Azure AD B2C - which is to say
that apps can only get tokens after an interactive user flow has
occurred. The client credentials flow will be added in the near
future.
from this link which suggests that what I am trying to do is not yet possible. Can anyone from the Azure team tell me whether this information is up to date, and better yet a rough timescale for delivery on this feature?
I have a Web API application and I've understood OAuth would be the standard security model for APIs where an Authentication Server would become responsible to generate Authorization Tokens so that the user can send to our server and consume the services.
I'm very new to this but I understand the roles involved:
Resource Owner
Client
Resource Server
Authorization Server
But what is OAuth exactly in practice, not in theory? Is it a .NET library? Is it a service provided by a separate Company? Is it something I can configure on my local development machine and see how it works?
How to get started with OAuth to secure a Web API application?
OAuth is a protocol; the current version is OAuth 2.0. More to your question, that link lists several implementations of the protocol in various technologies. For use with the .NET Web API you're probably interested in DotNetOpenAuth which provides implementations of both OAuth 1 and OAuth 2.
I'm using DotNetOpenAuth in an app I'm working on now to secure a .NET Web API. I've got an OAuth2Handler which extends DelegatingHandler which is inserted into the Web API pipeline before incoming requests reach any controllers. OAuth2Handler does the following:
Instantiates a DotNetOpenAuth ResourceServer
Calls ResourceServer.GetPrincipal() which reads and decrypts an access
token (issued elsewhere by the AuthorizationServer and returns an
OAuthPrincipal (In my case I'm reading additional data that the DotNetOpenAuth implementation allows you to pass and creating a ClaimsPrincipal.)
Assigning the IPrincipal containing the user information read from the access token to the User property of the thread and current HTTP context so it is available from the ApiController.User property in the service controllers: httpContext.User = Thread.CurrentPrincipal = principal;
Honestly, getting this all working (e.g. setting up the authorization server, resource server, certificates, etc.) isn't trivial. Unfortunately there didn't seem to be a good guide on the DotNetOpenAuth site. Here's a few other tasks you'll have ahead of you if you go this route:
Implement IAuthorizationServer - This is the interface provided by
DotNetOpenAuth that allows you to plug in to the library and use
their implementation to issue OAuth2 access tokens. You'll also need to implement INonceStore and ICryptoKeyStore which I did using an EntityFramework context for storage.
Configure Certificates - The AuthorizationServer and ResourceServer each use certificates to encrypt/decrypt the access token ensuring they are only accessible to each other. I built some custom configuration so I could manage this configuration in the web.config files of my authorization server app and my Web API services (resource server).
Manage Refresh Token - When first requesting an access token from the authorization server you'll get back (depending on your configuration) both an OAuth2 refresh token and an access token. The services use the access token which should be short-lived. The refresh token is used to get more access tokens. The refresh token should be kept secret (whatever that means in your scenario). For me it means the refresh token is never exposed to client-side javascript in my web app.
I hope that helps give you a high level idea of how to get started with OAuth and .NET Web API. Here's a blog post demonstrating some of these steps. This SO answer gives a few more high level details of the client side of the picture.
(The DotNetOpenAuth online docs appear to be down right now... sorry for no links to them; Apparently it has happened before).