CODEWITHSUNDEEP
asp.netasp.net-coreasp.net-web-apiocelot
Arthos
Arthos

Reputation: 453

Documentation for Ocelot - Authentication

I am trying to learn and look into splitting up my current asp.net api into a bunch of smaller apis to try and make a microservices application (Mainly for learning purposes). I am using Ocelot as gateway and I have found Ocelot nice and easy to set up. However, I am finding it difficult to find proper documentation on for instance how to add authentication, as the ocelot.readthedocs.io feels scarse in this regards. I have a hard time figuring out if I should make my register and login methods inside my gateway api or still keep this seperate in the microservice that holds the user database? Maybe I should connect my gateway api to the user database for direct interactions? (feels like it defeats the purpose of microservices).

To me, it also sounds kind of insecure to only authenticate the reroutes, compared to authenticating the http methods as you do in a monolithic application. But I might just have missed the whole point. Otherwise, if you guys know any great source of information it would be great, as I am having a hard time finding artciles, tutorial, courses or anything of that nature for ocelot and asp.net microservices.

Upvotes: 3

Views: 4960

Answers (1)

SNO
SNO

Reputation: 866

We are doing the same microservice approach and we solved it by overwriting the standard ocelot authentication middleware.

In startup (.net core) in the Configure section we implemented it as follows:

 public async void Configure(IApplicationBuilder app, IHostingEnvironment env)
        {
            OcelotPipelineConfiguration ocelotConfig = new OcelotPipelineConfiguration
            {
                AuthenticationMiddleware = async (ctx, next) =>
                {
                    try
                    {
                        AuthenticationClient.Authenticate(Configuration, ctx.HttpContext, new List<string>());
                        IEnumerable<string> allowedRoles = ctx.DownstreamReRoute.RouteClaimsRequirement.Select(e => e.Value).ToList();
                        if(allowedRoles != null && allowedRoles.Count() > 0)
                        {
                            string userId= AuthenticationClient.Authenticate(Configuration, ctx.HttpContext, allowedRoles);
                            ctx.DownstreamReRoute.AddHeadersToDownstream.Add(new AddHeader("userId", userId));
                        }
                    }catch(ApiGateway.Core.Exceptions.ForbiddenException e)
                    {
                        ctx.Errors.Add(new ApiGateway.WebApi.Exceptions.ForbiddenException(e.Message, Ocelot.Errors.OcelotErrorCode.UnauthorizedError));
                    }
                    catch(Exception e)
                    {
                        ctx.Errors.Add(new UnauthenticatedError(e.Message));
                    }
                    await next.Invoke();
                },
                AuthorisationMiddleware = async (ctx, next) =>
                {
                    await next.Invoke();
                }
            };

Explanation:

First the user gets authenticated using the bearer-jwt-token (or Basic) from the http-Header.

Then read the allowed Roles/Permissions (We have active directory groups as roles) from Ocelot-Settings (Section RouteClaimsRequirement).

If the user has one of the allowed roles/permissions, we get the userId and add it to the http-request header that is forwarded to the respective service. So, the target service knows the user.

To me, it also sounds kind of insecure to only authenticate the reroutes,

Usually the microservices itself are not directly accessible and are deployed a server layer behind. Only the API-Gateway is allowed to access them. The advantage is, that your micro-services don't need to care about authentication, authorization etc.

Hope it can clarify you question.

Upvotes: 4

Related Questions