Say I have 2 web applications. One is on a tomcat server and uses java. Abother is written in ASP.NET and is on an IIS server.
I want users to be able to log in on the IIS web application handling authentication, and if through a link they access a page hosted on my tomcat, I want them to be logged in. Both systems can access any/all databases in the background. I also have reverse proxies (F5 devices) at my disposal. The separate systems How could I achieve this?
One solution is to use something called Jespa: http://www.ioplex.com/
Here is another SO question regarding this setup: Tomcat Integrated Windows Authentication across Multiple Domains
My suggestion:
Generate a signature binding with userID and store it somewhere if some one succeeds in loggin in
Add this signature to the url on the IIS web page,and then goes to tomcat pages
Validate this signature which stored before and create session by the userID
Related
I have a legacy application that runs on Spring 1.0 with Acegi security on JBoss 4. Our plan is to migrate one subset of the application to Tomacat 7 and Spring 4. The user will login to the legacy application but if they want to navigate to the subset that is being migrated they would be redirected to the new app.
My question is how would I maintain session information between the two so that the user can seamlessly navigate between the two apps and maintain SSO. There would be no other information exchanged between the two servers. One constraint we have is that we have to make minimal changes to the existing legacy app.
Any help would be much appreciated.
You can't seemlessly maintain session information as far as I can tell.
You might be able to get insanely lucky by configuring JBoss and Tomcat to be clustered using Tomcat's clustering (and assuming that the Tomcat version shipped with JBoss is compatible with the standalone Tomcat you are running), and then enabling SSO on both JBoss and Tomcat, but then you have to be very careful not to place anything in your JBoss session that is not going to be loadable by the standalone Tomcat instance.
You are probably better-off implementing some other solution like using SAML that will likely be less fragile.
You said you didn't want to make too many changes, but if you are willing to get your hands dirty, you could use a shared URL-space between the web applications, use different session id cookies, and then cross-check incoming requests for unauthenticated users by calling-over to the "other" server to fetch their authentication information (which you'll have to make available in the session in some way). I'd advise against storing passwords in the user's session.. instead allow one application to obtain the username of the user in the other application using the session cookie from the first. Trust that the username is accurate and that the user has been correctly authenticated already in the first application, then perform an auto-login into the second.
Whatever you do, it's going to get messy, since your requirements are fairly messy.
We are having website which is hosted in real time server
we have developed a swing application through which we are connecting our remote database of our website .This application also provides feature to upload files to our website from the system like picassa software.Now we are planing to place this application in our website so that others can download and use it.
If I do like that others may extract my .exe file to jar file.May see the property file and can get database and ftp client passwords.So how should I provide security for my property file.
How softwares like picassa is protecting their passwords from us.
Please give an idea about these questions so that we can further proceed.
Thanks in advance ,
Does your website with the remote database have an application server that is serving the web content? If not, what is the database for?
If so, you should write a REST service or web service that the Swing application communicates with, so that all database connections are made from the application server to the database, not from your Swing application directly to the database. This has multiple benefits: apart from security, which you have already outlined, there is much less latency between the application server and the database than between your Swing application and the database. Furthermore, it gives you the opportunity to encapsulate business logic on the server and reuse code from your web application, thus extracting it from the Swing application.
Of course, you then need to secure the service itself. To do that, you can use a user authentication system like Spring Security to ensure that only certain users can access your service. This typically takes the form of a login API that establishes an ephemeral session token, and then all subsequent requests to the service supply that token to the service in a header (SOAP header, HTTP header, whatever).
For the FTP requirement, you could do this on the service side as well, although you would be transferring potentially large files to your server just to upload them to an FTP site. Alternatively, if feasible, you could have different usernames and passwords for your different users, and make then enter their credentials before being able to FTP their content. Then there is no shared FTP password and you do not have to worry about exposing it.
I have an application with login Id and password. From this application, onclick of a certain menu item, I want to redirect to a different application which also has login Id and password.
I am trying to do this with session.setattribute but going nowhere.
Both the applications are built on Java EE using Struts and Hibernate. Can someone suggest how to do it?
What you are looking for here is what's called "Single Sign On", that is different applications sharing a users credentials between them so the user only has to log in once.
As you have already discovered, sessions are not shared between web applications. Indeed, there are no provisions in the Java Servlet specification for this. Depending on what application server you are using and your deployment architectyure, there are a number of proprietary solutions for this purpose. Simplest example is of you are using tomcat and all your applications are deployed to the same virtual host and realm (and using the same domain). Then you can use the single sign-on valve.
As, your applications are deployed on the same domain, you can add a cookie with authentication token in the response and read the value of authentication token in the request in the other application.
Other option I can think of is, Create a Authenticated value and put it in database, and send the redirect request to other application with this value as a request parameter. Your other application can read that auth value and validate with database and let the user pass login and password page.
You cannot communicate directly through the HttpSession between 2 separate applications. What you need to do is use cookies in order to achieve this communication.
Also take a look at this thread, as yours seems to be a possible duplicate of that one.
I am curious as to how, for example Beanstalk and Server Density, create custom domains (e.g. custom.beanstalkapp.com, custom.serverdensity.com) for each sign-up. I would like to do something similar so that clients and their staff access the web-app at their own sub-domain. Each app either uses LDAP or our own native user storage depending on client choice and would share a common API.
Does each custom domain share the same web app code base?
Taking this further what if I wanted to allow a completely custom domain as you can get with bit.ly pro. I'd imagine in this case the customer would point the A record for their domain to our web servers and then we would have to programatically edit our Apache configuration to add a new virtual host for that domain?
In this application the API is written in Java (using Restlet) with the front-end written in GWT. The data layer is built in MongoDB.
You can use wildcard dns and name based virtual hosts in apache to accomplish the subdomain bit.
You want a web server where you can programatically change the configuration notably for the virtual hosts.
This will most likely mean that you will want an embeddable server to have full control of what goes on instead of hacking on a stand-alone server. That is the first step. Do that first.
I have two application. I need to do a single signon from application a to application b.
I thinking of using web service. I wonder how do i go about that approach.
Can anyone advise?
Assuming these are web applications - you must implement some type of shared trust model between the applications.
Under no circumstance should you write your own. That is too easy to screw up and there are plenty of existing (both open and commercial) to choose from.
Here are following options:
1 - If everyone is running Windows - you could just Windows Native Authentication (aka SPNEGO)
2 - You could implement some type of SSO system. Popular systems are CAS, Oracle Access Manager, CA SiteMinder, Sun SSO and IBM Tivoli Access Manager. While CAS is open-source, the others will also allow you to implement authorization as well, while CAS only does authentication.
Finally - make sure whatever option you choose - that it integrates with your language's native authentication & authorization framework. In Java this would be JAAS. In .NET it would be the .NET security framework. For PHP/Perl - you can leverage Apache modules. The benefit is that you don't have to become a security expert and it will make it easier to use external systems for authentication & authorization without having to re-code your app.
You could use a public key authentication scheme.
Create a keypair with a public and private key (using Java's keytool, GNU GPG or a similiar tool). Use the private key to sign a piece of information (for example a username) on application A and create a link to application B that is accessible from application A and contains the signed data. Application B can then log the user on after verifying with the public key that the request indeed came from application A (which it must have if it is able to decrypt the string).
You could of course create a opposite keypair for navigating the other way as well, or you could just use the public key and keep it secret (effectively making it a shared-secret system).
If the user tries to access application B directly you could also redirect him to application A with a parameter that says he came from application B (or do a referrer check). If he is already logged on to application A create the link with the signed data and redirect to it, otherwise present him with a logon screen and redirect after logon.
Hope that helps!
You could use an existing open source product, CAS and just implement it instead of develop your own. That way you'll be able to integrate with other applications that support the same protocol. Even if you decide to implement your own instead of using their code, there are a lot of ideas presented at the web site that would be useful for you to consider.
If the applications are hosted in the same server, then you could configure it to use single sign on. For example, in Tomcat this is achieved with a Valve.
If the applications are in different environments, then a secured Web Service is a good idea. You could for example create a public - private key pair and have application b (server) authenticating application a (client) on the client certificate. This means that application a will sign all requests to application b with the client certificate. More details about the architecture are needed for a full solution.
Are you using an application server? What is the environment for your applications?
There is a standard for propagating identity using web services called Web Service Security UsernameToken Profile. Here's a quick overview. You can send username/password or various tokens such as X.509 certificate or a SAML assertion. Some application servers web services stacks will handle WSS UsernameToken Profile, JBoss, Websphere, and WebLogic. Otherwise the web service code has to handle it. This approach may be too cumbersome depending on your environment.
There is a standard for single sign-on, called SAML. Again, this may be too heavy weight for your use-case.
In Oracle land I know there is the concept of a trusted application. Basically if you have control of both applications you can set it up like so:
Application A sends Application B, 1) Application A's username and password and 2) the current user's username. Since B knows and trusts Application A it doesn't need to verify the user's credentials, since it knows application A has already done that for it.
I assume that if you have a custom application B you might be able to do something like this. If your SSO implementation supports this then you probably don't have to do a whole lot except design your web services.
Good Luck