I have a Spring-boot web application that uses Apache Shiro for security management. The web application also uses the Atmosphere framework for socket communication.
Whilst working with it I have a requirement to authenticate a user who is currently logged in when I receive /socket request to atmosphere. However, when trying to access the Shiro Subject I get the following error:
No SecurityManager accessible to the calling code, either bound to the org.apache.shiro.util.ThreadContext or as a vm static singleton. This is an invalid application configuration.
I also have a filter added to my SecurityManager for /socket. Regardless, I continue to get the above error when I try to authenticate the user with atmosphere for socket connections.
I have searched up quite a lot on the web and haven't found an answer that explains what's happening thoroughly. I found many posts that mentioned something about the thread pool used by atmosphere is different from that which is allocated to servlet requests. Thus, async requests that reach atmosphere have no context of the original user. I also read a workaround here, which is quite old. I tried some of the things mentioned in the comments too.
Note: I am a newbie to the Spring, Shiro and Atmosphere frameworks. I understand things in a more systems-level perspective.
I would highly appreciate if I can get some explanation (or some link that might help) as to what is happening with each of these things and why it is producing the error above. Most of the online material I have read regarding this seems to be very vague and does not cover as an exclusive answer.
If I am not mistaken when the Spring application launches it also loads the Shiro and Atmosphere, related classes. The requests arrive at the Apache server and are delegated to a class based on annotations. Spring/Apache stores per request info (some cookie or session token) and subsequent requests are mapped according to this. However, the information stored between requests that hit the Atmosphere related (ex: onRequest) endpoints and the rest are not shared, hence I cannot use the same subject info.
I have sincerely searched a lot trying to understand and would like an elaborate explanation. I hope this question is not regarded unsuitable to the forum.
Thank you
Shabir
Take a look at the doc for Thread Association in Shiro
Your assumption seems correct (guessing as I've never used Atmosphere). The thread pools are different. There are generally two ways to deal with this. Some frameworks allow you to add data to a "context" and you can pull that data out from your running thread (much like a Servlet or Spring context). The other option (assuming you have access to manage the Atmosphere threads), you can wrap them in:
Subject.execute(...)
Related
I'm completing a python grpc server function-wise and being ready for deployment. Thusfar I have unsecure communication (pretty much the helloworld example when it comes to security). I thought I could put in place an authentication mechanism for my server in a reasonable amount of time after I observed that there was some documentation on this very topic provided by google. Closer investigation let me to believe otherwise.
The case is simple: Users (fellow colleagues of mine) login to their company mail (gmail) and use the resulting token (JWT, OAuth, OAuth2, I don't care) to gain access to the grpc server I wrote. No one else gets in.
Since googling grpc+authentication has been fruitless so far I believe I'm on the wrong track on how I should approach this kind of problem. So therefore the questions:
Given this use case, should my grpc server have any concern with authentication? If so, are there examples? Or should this be handled by a different system? If so, what system?
I noticed a lot of articles mentioning Envoy+gRPC. Can Envoy help me out here? Is it designed to deal with this?
The gRPC authentication can follow the same approach of a normal HTTP, the only thing you need to have in mind is that the authentication check would be placed in an gRPC interceptor and you will be looking at the metadata to get the creadentials. Unfortunately, I don't have an example to do it with Python but you can search in "how to add gRPC Server interceptors in Python" and then "how to work with gRPC metadata in Python"
Here an example in Golang, maybe it can give you the idea
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.
I have a sample web API hosted in an OWIN process (self hosted, not in IIS). I get a JWT token in my controller and I want to be able to retreive it in another part of the application, a class that implements NserviceBus IMutateOutgoingTransportMessages. In my other web application POC (hosted in IIS), I used a simple session variable and it works just fine. But I'd like to know what would be the best way to do it in my new OWIN self hosted environment ? Static property in static class ?
This question is really broad and difficult to answer without detailed knowledge of your specific needs. Here's my interpretation of your issue:
You're already signing each request, perhaps storing the token in the browser sessionStorage (or even localStorage), but this does not suffice
You need to retrieve the token outside of or not in relation to any request cycle (if not, this is probably where you should be looking for answers)
Your application does not need to be stateless
Just one static property for one token in a static class would of course start breaking as soon as more than one request hits the application at the same time. Implementing a class that maintains a list of tokens may be a solution, although I can't tell what key you should use to identify each token. Interface details would vary depending on things like if you need to retrieve the token more than once.
Thread safety issues would apply to all handling and implementation of such a class. Using Immutable Collections and functional programming practices as an inspiration may help.
If lingering tokens poses a problem (and they probably would from a security perspective, if nothing else), you need to figure out how to make sure that tokens do not outstay their welcome, even if the cycle is for some reason not completed.
Seeing how you used Session as a solution in your POC, I'm assuming you want some similar behavior, and that one user should not be allowed to carry two tokens at the same time. You could store the tokens i a database, or even in the local file system, making maintenance and validity a separate issue all together.
There are implementations of cache-like functionality already available for OWIN self-hosted applications, and maybe one of those would serve as a shortcut to implementing everything yourself.
If this token business in fact is the only reason for introducing state in your application, then the best solution IMHO would be to rethink your architecture so that the application can remain stateless.
I'm facing a similar dilemma on a server i'm currently developing for a customer. My problem is that the server must make calls (and retain a live connection) with a legacy, multithreaded DLL, (aka the SDK).
I struggled to get this working on IIS with a regular Web API project. Failed badly since IIS recycles threads when it determines that a thread is going rogue... witch is what the SDK thread looks like in that perspective. Also, the SDK must be able to callback on the caller (client - single page app) and for this I'm using SignalR.
I then tried a multi-part system (single page + web api on IIS + WCF service for the SDK integration). But it is a real nightmare to manage because of the 2 way async communication that must occur between all apps. Again: failure.
So I reverted to a single self hosted OWIN + WebAPI service in a console app (for now). My problem is that some of the calls are lengthy and are processed in a worker thread. I managed to pass the SignalR client id in each ajax calls via headers. I can extract the id when in web api controller. But when the task goes async, I need to get the id (via an Unity injected service) from the class that manages the async task. This is where my problem is similar to yours. In IIS hosted apps, we have HttpContext. It is contextualized on each client calls, and follows any thread changes in the pipeline... But not in self hosted OWIN WCF apps...
I'm looking into Thread Local Storage, CallContext... and other means of keeping track of the original caller info during the lifecycle of the async call. I have read about OWIN pipeline, I can capture the info in a OWIN middleware... but how to safely keep that info for use in injected services? I'm still searching for an answer...
I was wondering if you have found a solution to this rather interesting problem ?
I prefer adding to your thread rather than start another parallel thread / SO question.
We have a multi-system solution: several web sites and a separate App-Tier implemented / exposed as WCF services. The web sites all use EntLibs to log stuff - but they need to log to a central DB which is only accessible by the App-Tier.
To get around this we're looking at implementing a WCF service that can have LogEntires sent to it (via a Custom Trace Listener that sends the Log Entries to it).
The decision to use a WCF service is that it's in keeping with the rest of the architecture - and we don't have a lot of time to go doing much else.
I also looked at this and started wondering if we're on the wrong track altogether (from a performance perspective).
So, my question is:
Is this such a bad idea that I should just stop?
If it's viable, what are the traps I need to look out for?
The answer in the question you linked to covers it quite well, if you read between the lines:
Call the WCF logging service with "Is One way" = true, so that your client program does not wait for the logging to complete.
Set the WCF settings such that the client does not throttle the number of requests
I'm having a hard time getting my head around this, and Google just isn't being helpful.
I'm looking at converting some legacy code to use the following technologies: ASP.NET, WCF, jQuery.
The ASP.NET conversion isn't an issue, nor is accessing the WCF service for data, on the server-side.
However, what I'm having an issue with is potentially being able to secure the service so that I can return JSON-formatted data, requested via jQuery on the client-side, but lock it down to prevent external access.
For this particular implementation, it's not that big of a deal, since the ... quasi-Ajax-like functionality has been in place for quite a while, and there hasn't been abuse.
But, once this project is complete, I'd like to take what I've learned and convert another form, which is often abused, and allow for a slicker display.
If I want to do client-side calls to a Web service, am I stuck making my Web service open to anonymous access?
Short of securing the Web interface down to a specific subset of users (I see no issue with securing the added functionality to logged in users), are there any other strategies on securing a Web service in this scenario? Am I just overlooking something obvious?
Require an authenticated session for both the server-side page and its caller via ajax, with both behind HTTPS.
Another strategy is to use a token that is bound to the session during the last page load to confirm that the session itself has not been high-jacked. This is done when the client loads the page. The server tracks what the next token must be to confirm a valid request.