I have an ASP.NET Core 3.1 API which already uses OAuth for authorization. I added healthchecks middleware and I would like to make it protected with basic auth so that client which check the health status can simply provide credentials to check the service health.
So far I did not manage to configure it for the healthcheck endpoint.
Any clue how this can be added?
You can use RequireAuthorization method. For example:
app.UseEndpoints(endpoints =>
{
endpoints.MapHealthChecks("/health").RequireAuthorization();
});
Related
Background
I have two microservices that require access to IWindowsPrincipal of the calling user.
I am writing an API Gateway using .Net Core 3.1 that will act as a reverse proxy for these services.
I have configured Authentication and Authorization in the API Gateway as follows:
public void ConfigureServices(IServiceCollection services)
{
services.AddCors(options =>
{
options.AddPolicy("All allowed",
builder =>
{
builder
.AllowAnyOrigin()
.AllowAnyMethod()
.AllowAnyHeader();
});
});
services.AddAuthentication(NegotiateDefaults.AuthenticationScheme)
.AddNegotiate();
services.AddAuthorization();
services.AddControllers();
services.AddHttpForwarder();
services.AddOcelot();
services.AddSwaggerForOcelot(_configuration);
}
public void Configure(IApplicationBuilder app)
{
app.UseCors("All allowed");
app.UseRouting();
app.UseAuthentication();
app.UseAuthorization();
app.UseEndpoints(endpoints =>
{
endpoints.MapControllers();
});
app.UseSwaggerForOcelotUI(options =>
{
options.PathToSwaggerGenerator = "/swagger/docs";
});
app.UseOcelot();
}
Requirement
I would like to access the calling user's identity using HttpContext.User.Identity
in the method of the microservices.
Actual Result
In the methods of the microservices, HttpContext.User.Identity.IsAuthenticated is false and the identity information is empty.
Question
Is there a way to configure Ocelot in the gateway so that it will Challenge the caller if necessary receive Windows Authentication information and pass it on to the microservices?
If this is not possible, is the recommend way to achieve my goal, to perform implement Windows Authentication in each of the microservices?
Isn't Ocelot supposed to allow me to handle Authentication in one place for all microservices?
Follow on Question 1
Ocelot's documentation refers to Authentication using a JWT.
Should I conclude that Ocelot only provides JWT configuration?
Follow on Question 2
I have read a little about Yarp (https://microsoft.github.io/reverse-proxy/)
Should I be using Yarp instead of Ocelot to achieve my goal?
I thought the answer is No
Is there a way to configure Ocelot in the gateway so that it will Challenge the caller if necessary receive Windows Authentication information and pass it on to the microservices?
The problem is Windows Authentication is stateful, server and client are in the same Active Directory , you can find the note in .NET Core Windows Authentication
Windows Authentication is a stateful scenario primarily used in an intranet, where a proxy or load balancer doesn't usually handle traffic between clients and servers.
Microservices architecture requires a stateless instead stateful (means the server and client are in different AD/OS/Network). And Gateway is a stateless component in Microservices picture.
The only way Ocelot can authenticate Windows User is using Active Directory Federated Services (ADFS) with OpenID Connect (OIDC) or constructing Identity Server in the IIS Server by yourself. You can read the scenario in ADFS or Azure AD for more details.
Beside, there are my answers for two following questions:
No, Ocelot just provides the add-in feature to detect which claims of JWT must be included before it allows the request to go through downstream. You can build the custom Authentication/Authorization middleware to allow/deny the correct upstream.
No, YARP is the same meaning of Ocelot in your requirement.
I have a single ASP.NET Core 3.1.8 web application which uses ASP.NET Identity.
Now I've added some externally callable REST API.
I am stuck on how to add token(?) based authentication to my API.
It seems that ASP.NET Identity does not support API authentication. In my old .NET Framework Web App I used
app.UseOAuthBearerTokens(OAuthOptions);
so I had a token endpoint, where external client could ask for a valid token.
Now I read about to have API authentication I should use either AD or AD B2C or IdentityServer 4. I am OK with IdentityServer 4 option, but something is not clear
IdentityServer will completely replace my ASP.NET Identity? I still want to use the login UI and my existing interactive login logic and UI.
I've read about plug in ASP Identity to IdentityServer 4. So do I have to integrate my existing ASP Identity with IdentityServer 4?
Is it OK to host IdentityServer 4 within the very same Web App, where the UI, and the API is hosted?
I've tried to read the ASP.NET Core repo's source both the 3.1.8 and 5.0.0-rc.1, to get some direction. I would not like to go in some direction what will be considered as suboptimal in the next .NET 5 release. I know that there is a complete another way to solve this: AD or AD B2C, and I also have a solution template for that. As an alternative I would like to have a "self contained" solution too, so that's why I invested to ASP Identity. What would be the righ future direction in this track (self-contained) to implement external API authentication?
To protect the API itself you typically use the following:
services.AddAuthentication("Bearer")
.AddJwtBearer("Bearer", options =>
{
options.Authority = "https://localhost:5001";
options.TokenValidationParameters = new TokenValidationParameters
{
ValidateAudience = false
};
});
I recommend that if you use IdentityServer, you should put it on its own service, because otherwise its really hard to figure out what's going on and who is doing what.
IdentityServer does not deal with users, so you need to implement the user database (signup/forgotten password...) by yourself. You can use ASP.NET Identity for that.
IdentityServer will completely replace my ASP.NET Identity?
I would say that it depends on your needs, in some cases IdentityServer replaces ASP.NET Identity, and in some cases not. If you just have a single service to protect, then IdentityServer is probably overkill, because there's a lot to learn.
I am trying to get the [Authroize] tag working on .NET Core 2.1 Web API project built on .NET Framework. There is no IAppBuilder.UseAuthorization(). I wrote my own JWT custom auth handler and tried the following in the Startup:
services.AddAuthentication("Basic")
.AddScheme<BasicAuthenticationOptions, EdcAuthenticationHandler>("Basic", null);
services.AddAuthorization();
I also have
app.UseAuthentication();
but, again, there is no app.UseAuthorization()
I want to be able to add [Authorize] attributes (with roles as well) and be able to access the User object inside my controller methods.
Any insight would be appreciated.
Turns out it was simple. I needed the authorization tag like this:
[Authorize(AuthenticationSchemes = JwtBearerDefaults.AuthenticationScheme)]
And
services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
.AddScheme<BasicAuthenticationOptions, EdcAuthenticationHandler>(JwtBearerDefaults.AuthenticationScheme, null);
There was no need for:
app.UseAuthorization();
Sorry for the trouble. Just couldn't figure out that I needed the scheme name in the authorize tag.
I am currently using 3 middleware in my .netcore api application.
app.UseAuthentication();
app.UseMultiTenancy();
app.UseMvc();
From my understanding each middleware is run based on the sequence they are added to the pipeline.
For some reasons, the UseMultiTenancy is run before UseAuthentication.
Note, all my API controllers are marked with authorize attributes.
I would expect the authentication middleware to check whether the user has been authentication and then call the UseMultiTenancy .
Is this correct understanding? If not, is there a way to run UseMultiTenancy after authentication?
Is there an example of using .NET Core authorization policies with ServiceStack based apis?
I have setup a .net core based ServiceStack site, I also have created an authorization policy. The next step, which I am having trouble with is injecting the authorization service into the ServiceStack implementation and passing in the user principal to the authorization service.
Whilst ServiceStack doesn't know anything about .NET Core's Authentication, you can access the User assigned to the underlying .NET Core Request in your filters with:
GlobalRequestFilters.Add((req, res, requestDto) => {
if (req.OriginalRequest is HttpRequest netcoreReq)
{
var user = netcoreReq.HttpContext.user;
}
});