Hosted microservice, SpringSecurityContextProvider : Security context not available - cumulocity

I developed a microservice using microservice SDK 9.9.0. The microservice is running hosted at Cumulocity and is working fine. I get only many WARN messages in the logging file:
...
2018-08-24 12:44:41.400 WARN 11 --- [http-nio-80-exec-9] .c.m.s.f.p.SpringSecurityContextProvider : Security context not available.
...
What exactly does it mean and has this some negative impact?

The logging is caused by the health check.
The health check is executed without any credentials and therefore spring is logging this statement as it cannot create the security context.
As the health endpoint in the SDK does not require any credentials it is no problem.
You can also raise the log level for this class if the entries are spamming the log file too much.

Related

.NET Core Fallback Logging

I have two 3rd-party logging providers in my ASP.NET Core GRPC Service. Can I somehow "chain" these logging providers? I mean, can logging provider 2 perform logging only in situations when logging provider 1 failed to log.
For example, if I have an Application Insights provider and NLog File provider, can I log into the file only if my service can't connect to Application Insights infrastructure?
You can do everything mentioned using different NLog targets. So there is a target for Azure Application Insight: https://www.nuget.org/packages/Microsoft.ApplicationInsights.NLogTarget/.
Moreover if you have doubts that some of your targets can proceed slowly you can use asynchronous logging for it: https://github.com/NLog/NLog/wiki/AsyncWrapper-target
In my humble opinion, setting some rule to make 2 kinds of logging providers work like a chain is not necessary and maybe impossible.
What we usually do is making them work at the same time, just like using NLog to write log to files and send log to azure application insights as well.
By the way, azure application insight may not work because of some accident, but it's a small probability event. The scenario that the logging module not working is more likely to be the application crashed, then all the modules in your application are down including both the logging modules. So even have the feature to make Nlog work when application insight doesn't work, it's high probably to have a result that when application insight doesn't work, Nlog can't work too.

Azure Application Gateway with API as a backend pool is not working

I have .net core API inside the web app and that web app is backend pool for azure application gateway. while trying to access the web app got below error.
"502 - Web server received an invalid response while acting as a gateway or proxy server."
On app GW, health prob for that web app in unhealthy but while access the API as a https://abc.azurewebsites.net/api/values then it works.
When we deploy API in Web App Service then apiname.azurewebsites.net does not work give any probes to application gateway and treat unhealthy. API works like xxx.azurewebsites.net/api/values and Application Gateway also know this path. We have to put /api/values in override backend path of http settings. Same have to do in health probes.
Yes, you can first verify if the backend API could access directly without app gateway. Then this error may happen due to the following main reasons:
NSG, UDR or Custom DNS is blocking access to backend pool members.
Back-end VMs or instances of virtual machine scale set are not responding to the default health probe.
Invalid or improper configuration of custom health probes.
Azure Application Gateway's back-end pool is not configured or empty.
None of the VMs or instances in virtual machine scale set are healthy.
Request time-out or connectivity issues with user requests.
Generally, the Backend healthy status and details could point it out and show some clues. You could also verify all of the above reasons one by one according to this DOC.

How to make simple JAAS login module work (EJBs, Tomcat, WebLogic)?

I want to create a simple login module which authenticates users so they can, through a servlet using the weblogic client, access EJB's methods annotated with #RolesAllowed. As you probably noted, I have two seperate tiers - one with a webapp (Tomcat) and one containing business logic (WebLogic).
Generally speaking, I followed this JAAS tutorial (setting things accordingly).
According to the answer to this question, the principals should be propaged to the business tier (even having the tiers on separate machines?)
However, what I'm getting is an error page with following header: HTTP Status 500 - [EJB:010160]Security violation: User <anonymous> has insufficient permission to access EJB type=<ejb>
Also, I created corresponding roles in the WebLogic console.
Some tests from the servlet's GET method (without calling Bean's annotaed method):
request.getUserPrincipal().getName(): ADMIN
request.getParameter("role"): null
request.isUserInRole("admins"): true
(request is obtained from the argument #Context HttpServletRequest request)
Is there any additional thing to do to make it work? Or is it sufficient but there may be an error somewhere?
Let me also point I'm quite new in creating Java EE applications.
Help appreciated
The integration of security information between a servlet container and an EJB container is vendor specific. The question that you cited refers to remote calls between containers from the same vendor.
In your case, you have two different vendors - Apache Tomcat and Oracle WebLogic. Therefore, you are going to have more work to do.
You don't state which version of WebLogic that you're using, however the article Using JAAS Authentication in Java Clients describes the additional steps that you need to do in order to correctly propogate the security context from Tomcat to WebLogic 11g. You will likely be able to find similar information for other WebLogic versions.

WCF Data Service - logging and authentication

I'm evaluating the WCF Data Service approach for my next project. As I would need to be flexible on logging and authentication I have a couple of questions that maybe you are able to answer.
1) Am I able to log different level of events, ex. warnings, errors, and redirect them to a different logging sources as database, text file, event log?
2) A link that shows how to perform the requested on question 1
3) Is there a way to introduce a simple authentication based on user name and password and how it is done?
4) Do you have by direct experience discovered any limitation on using Data Services instead of creating a WS-* WCF service for what concerns logging and authentication?
Thanks
There's a good series of blogs about auth over OData service here: http://blogs.msdn.com/b/astoriateam/archive/tags/authentication/
For logging you should be able to use your web server's logging facilities (typically IIS I assume), since all errors are reported as error responses by the service.
You can also override the DataService.HandleException method and implement your own logging in any way you want.
For logging of general non-error things there's also the processing pipeline (DataService.ProcessingPipeline). You can register a handler and implement your own logging of these as well.
I don't know of a sample of this tough.

Is there a service for monitoring secured WCF endpoints in the same way that HTTP monitoring services do?

A service I have in WCF occasionally goes down due a problem with a COM component. While I am troubleshooting I would like to setup another host to make regular calls to this service to monitor availability.
It is slightly more complicated that a simple HTTP call though as the service is secured by SSL and WCF authentication (username / password). I'd also like to be able to parse successful calls to see if they return warning / fail states from my code.
Would you recommend any monitoring providers for this or is it beyond the simple monitoring they normally provide?
Regards
Ryan
You could enable WCF logging and auditing facilities either on the server or the client to produce a log of all traffic. Then you can analyze the results using the WCF Service Trace Viewer Tool provided in .NET Framework 3.0 and 3.5 SDK.
In your situation I would probably enable logging only at the message level. This will reduce the amount of information that ends up in the log file and will help you focus on analyzing the data that's actually being sent back and forth from the services.