WSO2 folks,
I'm looking at WSO2 Application Server, and I created a web app to invoke System.exit(), which brings down the whole app server. I'm asking because the apps from multiple tenants could be running on the same Application Server, and we need to prevent a malicous tenant from killing the whole JVM.
My first thought was to use a SecurityManager to restrict the access, but I'm not sure where should I set the SecurityManager, and how should I code the SecurityManager to ensure a secure app server.
Is SecurityManager the correct approach, or is there some other way to accomplish my requirement?
It has been protected using Java Security Manager and system is configured with policies ,which do not allow such calls.
Related
I'm building a desktop client app (win/linux/mac) with a backend hosted in GCP (I'm considering other cloud platforms too). The desktop app should be minimalistic and provide access to local machine resources to the backend. And I'm looking for a way to invoke my app from the server (when some event occurs) and then the app would do some work on a local machine. Here's what I've tried so far.
Google Cloud Pub/Sub. Seems like it does what I need, but to make it work I have to create a service account, generate JSON key and store it locally, which is not good. I can restrict the service account access permissions, of course, but still it doesn't look good to me. Maybe there are other ways to auth my app running at the end user machine? I want to keep my desktop app minimal (ideally without UI, just an "agent" console process / Windows service). Maybe I could consider a login screen to connect the app with the backend, if that solves the problem, but I don't want to overcomplicate.
Google Cloud Run + SignalR / WebSockets. This solution also looks good, but it has one significant disadvantage. As long as there's at least one open WebSocket the Cloud Run instance is considered active and therefore billed. There are other difficulties related to scalability and container instances synchronization too.
What do you think about the options above, and what are the other possibilities? Am I left with REST API and polling for updates? I'm quite new to the cloud stuff so any help is appreciated. Thanks!
If you want to be able to invoke your local app from Google Cloud, you need 2 things
The first one, to register your app on Google Cloud, with, preferably, a auth mecanism (can be an API key for example). Like this, the GCP backend know where to call you app (which IP/port) and how (the auth mechanism)
The second is to have your app up and running and listen external communication. HTTP is the easiest way. Wait a HTTP call on the IP/port defined during the registration, check the auth and perform the process.
You can store the data (location and the auth) in firestore for example, and use Cloud Run to perform the HTTP call.
You can also inverse the solution and to poll (long polling or regular poll) the backend from the local app when it is running.
The 2 approach are possible, the second one slightly easier but can be challenging to manage the security.
I want to use an existing developed PhoneGap app I have developed and deploy it onto Good.
What I don't understand is how authentication of remote api calls will work within Good?
For example
Within the app I make remote calls to a webservice end point
The webservice is strictly only available to authenticated users' within
the network (It's behind a firewall)
Questions
Does Good provide a proxy, where the url of the webservice is pointed to the Good server which in turn calls the actual webservice end point?
If so, is the proxy 'automatically; created or does a proxy alias have to be created in good and it is this alias as what I specify within the phonegap app? i.e. Do I have to change the web service url in the PhoneGap app
Any ideas how fire-walled web services are configured in Good?
Is the authentication of the user passed through Good which effectively is setup to access resources within the fire-walled internal network?
Do I have to package the PhoneGap app into a 'Good' app?
Thanks
Edit
I have seen that 'Containerizing via App Wrapping' may come into this somewhere?
I am using Axis2 (1.5.3 currently) and Tomcat (6.0.26 currently) and am running a web service. I would like to also host HTML pages for configuring the web service.
What is the best way to go about this? I assume keeping the same context is key, but perhaps it is not.
My current distribution is located under a folder structure similar to this:
Tomcat/webapps/mycompany
With the actual service code here:
Tomcat/webapps/mycompany/WEB-INF/services/myService
In a browser, I can hit my web service by going to here:
/mycompany/services/myService
I note that I can drop actual HTML files in this path and Tomcat will, indeed serve them up.
For instance, if I put "index.html" under Tomcat/webapps/mycompany, I can navigate to /mycompany/index.html and see my html.
What I want to do is have this HTML be attached to JAR/class files that can interact with the already-existing service class files in the same context as the service. Therefore, I can have the browser configure the web service directly.
Is this possible, and is there a tutorial or something out there that will help me with this? Note that I have been working with Tomcat and Axis2 for a while now for this particular web service, but I have never actually deployed a web application/html using Tomcat before.
Thanks.
First of all what do you mean by a configuring a service. Normally in SOA world services are analogous to interfaces. IMHO you can just change a service, since their are other users that rely on the services you are exposing.
If i want to change a service i would rather introduce a new version of the service after deprecating the existing one.
Are you talking about applying QoS to existing serviecs. Then that makes sense.
Anyway, If you want to have a web-app alongside with axis2 service engine, it is possible. If you look inside the axis2 war file you'll find the web.xml entry to Axis2Servlet. It is this servlet that serves the web services requests.
So, what you need is the Axis2Servlet mapping in your web-app along with your usual servlet-mappings. Number of possible ways to configure your services using web-app files. One options is to use web-services call itself to (with authentication) to configure it.
By "configure a service", take this example:
The service has a set of datasets.
Each dataset exists in a separate database.
The service can manage 0..n datasets.
The service must be configured to know about each dataset.
This is what I'm configuring. I'm not trying to configure Axis itself or redefine the service.
I would like to host the HTML using the same instance of Tomcat that I'm hosting the web service with. It needs to manage sessions, have login capability, an whatnot, and has to be able to configure the web service live.
From what I'm reading, it's probably best to make an interface to the web service that the web application module can call into from a different context.
Is there a better way?
I'm learning about web services and most of the resources I've been reading talk about registering your web service once it's ready for use by others. Is registering a web service required to use the service?
For example, let's say I have a web application on a company intranet and I create another web service app that retrieves some sort of useful information to be displayed on this private intranet site. Would this new web service require being registered just so my web app can use it or can the web app simply interface directly to the new web service (following the WSDL file) without the need of some sort of UDDI registry?
You can certainly use the service without the UDDI registry.
I have created several Web Services and have immediately used them without registering them. Registration gives others confidence that your Web Service is legitimate and descriptions of how to interact with those services.
Imagine doing development where you have to register any Web Service before using it. Yikes!
No, not at all.
You are probably talking about API directories you may register your WS at. Like UDDI or what it’s named. Entirely optional.
Nobody uses UDDI anymore. It's an idea whose time has come and gone.
It was thought that there would be public registries of web services that everyone would use to find a web service to meet their needs. That never happened.
How could either the service or the app know whether or not the service was registered?
Furthermore, why would they care?
If you're trying to use service orientation the right way, your web services should be registered within a service registry. The registry should contain the published contract of the services and any meta-data that helps the discovery process.
A different questions is: does a service consumer program need to look up a registry and dynamically bind the service it needs to call? NO, NOT AT ALL.
But then, what discovery process am I talking about?
I'm referring to a human (developer, architect, etc.) who is designing/developing a program that needs to call a service. This person should have means to search what services are available in his/her organization. If not, the benefit of reusing services is compromised.
Discovery is also about humans finding out there's a service somewhere in the IT organization that offers the functionality they want.
In this case, the registry can be as simple as an html report that is created and updated manually or generated by parsing (xslt comes handy) the wsdl files.
I have developed a web service which accepts the login credentials from the XML message passed to it. I have concerns over this method as the developer who consumes the service can easily share the login credentials and my service can be called from some other application that uses the same credentials.
Is there any way that I can issue a 'license' to some specific applications? So that, even if credentials are shared among the consuming apps, only authorized ones can successfully consume the service.
P.S: I thought about implementing IP restrictions but that doesn't serve the purpose as we may have different applications installed on a same server (we do have such a scenario implemented).
Did you look into having security certificates installed on the client machines. Verisign and other companies like it issue certificates that your client will need to install on there calling machine.
This of course comes for a fee!