I am creating a distributed application which will use ASP.NET Web API to support a Single-Page web Application (SPA) and other potential native mobile app platforms. My current architecture uses Thinktecture Identity Server as a STS which will provide authorization tokens for my clients to use to access the WebAPI. In the backend I will have persistence and business logic which will be exposed by a WCF service in a separate app domain from my WebAPI. The WebAPI will call the service layer to access data and perform actions on the domain.
My question is around authorization. I will be using Claims Based Authorization and can augment the list of claims from domain data held about the user from my WCF exposed business layer. But where should I carry out the authorization? With .NET 4.5, ASP.NET now has an extensible model to enable me to separate out authorization logic from my controllers into a separate authorization module - using the ClaimsAuthorizationManager. Also, Thinktecture.IdentityModel does a really good job of providing all the plumbing to do this within my WebAPI application. However, I cannot help thinking that the authorization logic should be sitting in my business layer, behind the WCF service, and that the client-facing WebAPI should not be tasked with enforcing this. Should I require other client facing hosted apps to consume my WCF based business layer, then they would also need to implement security code. On the downside, it does mean that an unauthorized request gets quite far into the application before being rejected.
Question: should I use the Claims based authorization capabilities in ASP.NET or should I wrap authorization around my business layer behind the WCF service?
When possible, you should always try to use the authorization tools the framework you use gives you. In Microsoft's case, it's claims-based authorization. The benefit is that you're isolating your authorization logic in a layer of its own rather than within your business logic.
Claims-based authorization is one of many approaches to authorization. Another would be to use XACML. I recently gave a talk on XACML for developers (albeit Java developers). You can read more about it here. I also wrote an article on .NET and XACML which you can check out here.
Related
I am developing ASP.Net Core App with Backend For Frontend pattern using Ocelot. For now there will be a single API service but in the future I might migrate to microservices. Let's say it will be an e-commerce system where I will create different web apps for customers and for employees. I may also have Mobile app for customers.
From my research I know that should have my main API, then two API Gateways and two client (angular) apps. There also needs to be separate IdentityServer app.
So my question is - is there a way to configure the IdentityServer and gateways in such a way, that when I log in app for employees I won't be authenticated in customer app? I cannot understand if it should be possible with right configuration of scopes, claims or audiences. I saw many examples where that properties were set completely differently. I can prevent user from accesing some endpoints with the use of Roles but I think that it's not the right way to do this.
Or maybe since IdentityServer has built in SSO I should not use it and move to different authentication provider?
You should let the authorization sub-system in ASP.NET Core decide if the user is allowed or not, typically based on the claims in the access token.
You need to understand that you handle authentication and authorization separately in ASP.NET Core as the picture from one of my training classes show:
For more details:
Introduction to authorization in ASP.NET Core
Policy-based authorization in ASP.NET Core
Claims-based authorization in ASP.NET Core
In an attempt to understand what I may use for OpenId Connect Server implementation, I have looked into what each of them is:
IdentityServer4:
an OpenID Connect and OAuth 2.0 framework for ASP.NET Core 2.
AspNet.Security.OpenIdConnect.Server:
is an advanced OAuth2/OpenID Connect server framework for both ASP.NET Core 1.x/2.x and OWIN/Katana 3.x/4.x, designed to offer a low-level, protocol-first approach.
OpenIddict:
OpenIddict aims at providing a simple and easy-to-use solution to implement an OpenID Connect server in any ASP.NET Core 1.x or 2.x application.
OpenIddict is based on AspNet.Security.OpenIdConnect.Server to control the OpenID Connect authentication flow and can be used with any membership stack, including ASP.NET Core Identity.
Also have checked that all of them use well the ASP.NET Core Identity as a membership system.
And so my current understanding is that IdentityServer4 and OpenIdConnect.Server are two alternative frameworks that solve the same problem. The main difference is the list of supported ASP.NET Core versions.
Regarding Openiddict - it is a kind of extension to simplify server creation based on AspNet.Security.OpenIdConnect.Server.
Have I missed something, or this is how things in general are?
EDIT (01/28/2021): as part of the 3.0 update, AspNet.Security.OpenIdConnect.Server and OpenIddict were merged to form a single/unified codebase under the OpenIddict umbrella, which should offer the best of both worlds: you still have the same experience as before, but can now opt in for the degraded mode, giving advanced users the same lower-level approach as AspNet.Security.OpenIdConnect.Server.
And so my current understanding is that IdentityServer4 and OpenIdConnect.Server are two alternative frameworks that solve the same problem. The main difference is the list of supported ASP.NET Core versions.
Actually, I believe the most important difference is that these two libs don't share the same objective. ASOS' only mission is to help you deal with the raw OAuth 2.0/OIDC protocol details: everything else is totally out of scope. Concretely, this means that concepts like users, applications or stores - that you can find in OpenIddict and IdentityServer - are completely inexistant in ASOS (which means you're free to bring your own implementation... and your own abstraction).
While IdentityServer will expose many abstractions and services allowing to configure specific features, ASOS - that was forked from Katana's OAuthAuthorizationServerMiddleware - has a centralized low-level events-based API (named OpenIdConnectServerProvider) that behaves exactly the same way as the ASP.NET Core security middleware developed by MSFT.
When working with ASOS, you have to deal with raw OpenID Connect requests and implement potentially sensitive things like client authentication (e.g using a database containing the client credentials) and that's why ASOS' core target is people who understand how the OAuth2/OIDC protocol work. OpenIddict and IdentityServer, on the other hand, will implement these things for you.
Regarding Openiddict - it is a kind of extension to simplify server creation based on AspNet.Security.OpenIdConnect.Server.
Initially, that's indeed how I was asked to design it. OpenIddict was created for non-experts who don't feel super comfortable with the protocol details of OAuth 2.0 and OpenID Connect.
While it will give you full flexibility to implement the user authentication part (e.g in your own authorization controller, using ASP.NET Core Identity or your own authentication method), it will handle the complex request validation process and make it transparent for your app, without drowning you with tons of configuration options.
Unlike ASOS (that tries to be as flexible and as close to the specifications as possible), OpenIddict generally comes with more restrictive validation routines that I personally consider as best practices. For instance, it will automatically reject authorization requests that contain response_type=token if the client is a confidential application, even if that's not prohibited by the OpenID Connect specification.
I am making a choice between ASP.NET Web API and WCF.
I am not quite sure about the authentication part. Could some one shed some light on the differences?
I suppose there would be no actual difference under the hood. After all, the authenticaton mechanism refers to the HTTP request level on the ASP.NET engine integrated in IIS. It should have nothing to do with whether the module responding the specific HTTP request is implemented as an ASP.NET web page, WCF or Web API endpoint.
Nevertheless, there would be some differences in modelling and perhaps in configuration. WCF models the authentication mechanism as a "WCF authentication service" while Web API uses the normal security model of ASP.NET.
Use this WCF and ASP.NET security guide and this Web API security guides as a reference.
Hope I helped!
I have an web application built using RESTful services (JAX-RS).
There are REST calls, and simple JSPs with js files to handle data.
Now I want to implement authentication and authorization in service. What I did earlier was to implement simple filter and inside each service check for #HttpRequestContext for if session has user object. Since it I want to expose service to say, external webapp, I will have to hard code system as there is no standard.
I feel this is not good design. Is there a design pattern to solve this common issue ?
We write a WCF web service.
How can we call it's methods in JSON format?
An additional issue is how can we secure our web services.
I'd like to use Microsoft Membership and Roles providers for users authentication and authorization. The question is how to do this. Is it possible to do authentication and authorization behind-the-scenes (in context of WCF), or I must call ValidateUser() and IsUserInRole() in every web method for every user call?
Whether I restricted to use webHttpBinding (over wsHttpBinding) because our client-side programmer familiar with AJAX/JSON? Whether there are any restrictions of webHttpBinding concerning using Membership/Roles comparably comparably to wsHttpBinding?
Thanks a lot in advance!
Ilan.