I have been looking for quite awhile for solution to have one spring security for 2 or more applications.
Basically I have a main app (/) running on tomcat, where the user can interact with it etc, and second one, in separate a context (/player).
I want to use one spring security to secure both app. So when user will login to main app (/) will be also able to access another context.
This is the point where I got stuck. If anyone has any idea how to set it up, that would be more then great.
In my opinion, you can use security for two contexts, if they are part of one application only. Means, both are deployed with one war itself.
If two applications are deployed with separate wars - I do not think that you can use single security context.
A basic example (& some google) might help you.
you should try single sign with spring security
http://www.disasterarea.co.uk/blog/saml-based-single-sign-on-sso-in-spring-security-applications/
Related
I created a simple two-player game (Connect 4) with a Java/Spring backend and React.js frontend. I understand it would be simpler to create the entire app in React, but I’m studying Java development and decided to learn React to demonstrate my understanding and create a portfolio website.
I’m struggling to decide how best to deploy the app. I deployed the backend on its own to GC App Engine. After a few false starts it eventually worked. However, if I visit the project url from two separate browsers/devices, both devices are looking at the same instance of the backend, i.e. two individual users are looking at the same ‘game’, which is not what I intended.
What is the best approach to deploy the front & backend so each user is playing their own individual game?
This is literally my first foray into any kind of web development, so I may have bitten off more than I can chew.
Thanks.
I would suggest you use multiple services on your project. You can either use the same deployment command for deploying or updating the services that make up your application.
services in App Engines behave like microservices and therefore you can deploy multiple services to run as a set of microservices.
Here are the requirements for deploying multiple services:
You must initially deploy a version of your application to the default service before you can create and deploy subsequent services.
The ID of each of your services must be specified in their corresponding app.yaml configuration files. To specify the service ID, include the service element definition in each configuration file. By default, excluding this element definition from your configuration file deploys the version to the default service.
You can deploy one service as frontend and the other as backend.
You can check this documentation on services for additional information.
I looked at the documentation regarding services but I still don’t understand their use in the context of my problem. I may have misunderstood your explanation, but I don’t think I explained my problem clearly. Having looked at the documentation, my use of the word ‘instance’ is not the same as an app engine instance.
It would make sense to me to have two services in my project; one for the backend and one for the frontend. To solve the problem of each individual player interacting with the same backend API, and so unwittingly interacting with the same single Connect4 game, generating multiple services would not be a solution. Is my understanding correct?
The comment from NoCommandLine on my original post is probably a better description of what I want to achieve.
I have a Spring web application that consists of the following parts:
Web GUI for Users
Background processes
Webservice-like API
It's all in one application. For every update, the whole application has to be stopped and redeployed, which of course means that all users are kicked out and the API is temporarily unavailable.
I am wondering whether there a ways to seperate the application into several applications/services which could be deployed seperately. All applications would need access to the DAOs and to several utility classes/services.
I know there will be no ready-made solution for this. But maybe you can show some 'best practice examples' or show me some direction where I could go.
But if some part of the application is offline while redeployment, the complete application will not work, so this is likely that the split is not the solution.
If the problem is just that the users session is killed, then you should have a look at values stored in the session that are not able to been serialized.
If your probem is that the application is offline for some time, then you need a second server and some switch (loadbalancer) to implement a blue-green-deployment
Which one is the best approach/method to implement security in Java EE?(JPA/JSPs)
I'm working on a personal project so I can learn Java EE and I am a little confused on how to approach the AUTHORIZATION and AUTHENTICATION process on my website.
I have different roles and I don't want certain users to access certain parts of the website. So I've been searching for docs and tutorials and etc, but everything I find dates to more than 3-4 years ago. Is there anything more recent that I should look into?
Here are some of the things I found:
http://www.oracle.com/technetwork/developer-tools/jdev/oc4j-jaas-login-module-083975.html
Any help would be greatly appreciated!!! :)
Spring Security. Although it is branded as Spring, you might find it useful for web applications; do note that you don't need to write a Spring app to use Spring Security.
If you wish to stick to JAAS, I would suggest using one of the container's login modules, just to get started, before you attempt to write your own login module. Be forewarned that you might end up writing one, if the container supplied modules do not meet your requirements. And, there is a good book on JAAS to help you understand it in detail.
Moreover, take a look at Servlet spec 3.0, to see how annotations can be used declare the roles (#DeclareRoles, which came in servlet spec 2.5) in the servlet itself, before defining what roles have access to what HTTP method (using #RolesAllowed). You can also employ annotations like #DenyAll and #PermitAll, to permit or forbid access to all users. #TransportProtected will ensure that the HTTP method is accessed over HTTPS. All one needs to do, is to map these roles in the source code, to actual roles in the JAAS realm; this often done using a container specific descriptor file.
ADDENDUM
Since you are using JSPs and not Facelets or any other technology for the presentation tier, you might be interested in the JSP tags offered by Spring Security. It is much cleaner that maintaining all of the authorization metadata in a humongous web.xml file.
As far as JPAs are concerned, well, the underlying access to them is usually enforced at the servlets or EJBs. Of course, you can build in more programmatic security, based on your needs - using entity listeners would help in this process as you would be able to intercept load, update and persist operations (if you are that particular, but for the most part building security before your business logic is executed usually is sufficient).
And oh, take a look at JBoss Seam (and Seam security), for it is a complete application development framework built on Java EE.
Something more recent than JAAS is the Spring Security framework. It supports JSR-350 (EJB 3) and thus would work fine in Java EE.
I worked on a Java EE application recently with JAAS. It's pretty current, you can check it's home page at Oracle.
It works with roles, authentication, etc.
You can use it in JBoss and Glassfish, probably the rest of the ASs too.
Spring security tutorial https://www.packtpub.com/spring-security-3/book. Highly recommended.
I need to perform pre- and post-processing of all incomming requests to a web server. The functionality is both url-level access restriction and language translation but also other special cases that need to be handled globaly.
Typically this can be achieved with servlet filters but when the number of web applications grow it becomes desirable not to bundle the filters with every application since all applications need to be rebuilt and re-deployed when making a change to a filter.
Instead I would like to install the filters globally on the server and I have found two possible solutions of which I'm not satisfied with any of them.
On Tomcat it is possible to deploy server-wide filters in the "lib" directory and configure the server web.xml to map them to incoming requests. The problem I see is that any filter dependencies also need to be deployed globally in the lib directory. From what I understand this can cause hard to solve dependency conflicts with installed applications. (Does Tomcat load the same library file into memory twice if they are in two web apps?)
Deploying the filters in a simple web application that mainly acts as a proxy would at least bundle the filters with their corresponding dependencies. This application can then be deployed on the server and take all incoming requests before forwarding them to the target application using the crossContext config parameter. (RequestDispatcher forward between Tomcat instances) However, this requires fiddling with the urls such that all links point to the "proxy".
Neither of these solutions seem to be satisfactory. They are both platform dependent since they rely on Tomcat. They also both seem to have possible problems and require special handling of dependencies.
What is the best practise when using server wide functionality?
This is my untested thought (so not a best practice) - which is a variation of option 2 in your list.
You can use Sitemesh (which is actually meant for decorating your multiple web apps with a common header/footer - but in this case dont use the header/footer).
Host the Sitemesh as a separate web app with crossContext = true.
Sitemesh will be invoked as a Filter for each web app, so the URLs that the end user sees will not change at all. But you will have to define the decortaor.xml for each web app.
You can write your actual Filter processor and chain it after the Sitemesh Filter. All requests will go to the Sitemesh app first - then to your Filter - then to the individual servlet within the web app.
I have been trying to figure out a way to create shared Hibernate session service on Tomcat 6.
basically, I need to have this service: 1. to be re-deployable (which exclude the JNDI service); 2. all the web applications can share the same Hibernate sessions (cache). The Tomcat class loading mechanism seems make sharing the db sessions impossible. I could create a web application with the Spring HttpInvoker which can be used by other web applications. Or I could go with the Spring dm-Server but it seems the complexity of the solution would comparable to that of an application server (JBoss or Glassfish).
What would be the viable solution?
You can use the 2nd level cache
Apart from that - let's assume you want to modularize you application and that's the reason for having two (or more) webapps. But if you want to cache entities from two different webapps, that means the same entity classes exist in both. Which by itself isn't that wrong, but having the same cache for these entities in different contexts seems wrong. Perhaps you don't need two web apps after all?
If you are certain that you need this, you can try implementing a custom Tomcat valve, but I can give you neither recommendations nor details about it.