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
We are experiencing a strange behaviour, we have an application (jsf 2.2.4 embedded) that has a login form, glassfish has sso enabled and a custom realm (LDAP). We have also several applications (some with jsf 2.2.4 embedded, others using jsf implementation of glassfish) that are linked by the application that contains the login form.
For some reason when glassfish has created 300 - 400 sessions approximately or cpu is at high rate or maybe at a random moment, and we navigate from the main application to the others and then return to the main application, at some point glassfish changes the jsessionidsso cookie, assigning a new one. The thing is that sometimes that cookie represents the session of another user, so thats where we have a session mix and can see the information of another user.
We are running Glassfish-3.0.1 on a Centos-6.5, no proxy.
We have already tried updating weld following this guide http://www.andygibson.net/blog/quickbyte/updating-weld-in-glassfish-v3/ but we are currently experiencing the same behaviour.
Can someone point us to the right direction? What could it be?
Thanks so much!
Regards,
Mateo.
We have the same problem and don't know the reason yet. Our temporary solution: we attach the user ID to every user request and we check the permissions of that particular user every time, because we unfortunately can not trust to the session id. If the session does not belong to the user ID, we reject the request and ask the user to initiate a new session. The problem affects less than 1 percent of sessions.
We suspected the load ballancer system in front of the Glassfish servers, but if someone has the same experience without load ballancer layer, the problem hides somewhere else.
We have a weblogic application that needs to support being served from multiple domains (e.g. "foo.com" and "bar.com"). Once a user initiates a session on one of these domains they can visit to subdomains off that primary domain (e.g. "a.foo.com", "b.foo.com") and share that session across all of these subdomains. If a user jumps from "foo.com" to "bar.com", they will lose their session, which is fine.
We were able to successfully implement this on JBoss/Tomcat by customizing a 'Valve' to rewrite the session cookie to always be at the top level domain for the serverName that is being requested (i.e. request.getServerName()).
However, we are currently in the process of migrating our application from JBoss to Weblogic and are trying to figure out how to support the same requirement. We have found that weblogic does allow for sharing sessions across multiple subdomains of a single domain by setting the 'cookie-domain' property within the weblogic.xml:
<session-descriptor>
<cookie-path>/store</cookie-path >
<cookie-domain>.foo.com</cookie-domain>
</session-descriptor>
However, we haven't figured out how to configure support for multiple domains (i.e. both foo.com and bar.com). From what we can tell, the weblogic.xml file doesn't support this.
If we only configure one of the domains in the weblogic.xml, sessions do not work properly for the domain that is not configured (i.e. every request leads to a new session).
Any ideas on how we can support sessions across different domains for a single web-app on weblogic?
We are running on Weblogic 12c.
As of WebLogic 12c, Oracle confirmed that what we were trying to do is not currently supported. There are also no immediate plans to implement such a feature.
The workaround that we chose to implement was to use mod_rewrite to rewrite the domain of the JSESSIONID cookie at the HTTP server level to be the domain of the request.
I believe such an option should NOT be supported. If it is allowed then nothing prevents hotmail.com from configuring yahoo.com (say) in its configuration file and getting access to yahoo's JSESSIONID value.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed last year.
The community reviewed whether to reopen this question last year and left it closed:
Opinion-based Update the question so it can be answered with facts and citations by editing this post.
Improve this question
Warning! I'm on a bit of a fishing trip here, and I'm not even sure if the questions that I'm asking entirely make sense. Please be kind with your responses! :)
I recently took over a project that is currently based on a Java + Linux + Tomcat + MySQL. Right now, the system is basically just a website with a few cron jobs in the back-ground to move some data around, etc. In working with the product manager to develop a prioritized backlog, it’s clear from what he wants to do that I need to start developing a service-oriented architecture (SOA <-- buzz word warning!), and I will end up with a blend of web servers and application servers. Note: I’m strongly considering moving to Glassfish v3.
Currently, authentication and authorizations are handled in Java code with user information being stored in the MySQL database. At the bare minimum, it seems to me that I will need to split this out into a separate authentication service (otherwise, will end up with a bunch of duplicate code all over the place to handle user authentication and authorizations).
I’ve been looking into single sign-on (SSO) type solutions and doing some research. From what I can gather, OpenSSO has been officially dropped by Oracle, but picked up by ForgeRock and now is called OpenAM. This appears to be very close to what I want, but since I already have a MySQL-based system, I would prefer to have something that supports it (or some other kind of RDBMS). I found this on Stack Overflow and it seems to indicate that it’s basically LDAP or nothing.
Is there a way to make OpenSSO/OpenAM talk to Database for its authentication and authorization?
My questions are:
What other options are out there to OpenSSO/OpenAM? Is LDAP the way to go? Note: doing a “OpenAM vs” google search doesn’t yield much. Do people tend to just “roll their own”?
Any thoughts/suggestions/links on this topic that will help educate me will be greatly appreciated. Thanks in advance for your patience and help.
Are you integrating existing applications, or do you just want to support your own applications?
Are you looking for actual SSO or simply shared credentials? SSO is logging in to a single application, and having that credential propagate to another application (such as logging in to Gmail and being automatically logged in to Blogger). Shared credential is you can use the same login name and password across applications, but the credential itself is not automatically propagated.
LDAP is a common system used to manage a shared credential. Many systems allow you to point their authentication store to an existing LDAP server.
For example, if you had several apps deployed in a Java EE container, and also, say, an email server and web based email client, all of these diverse applications could be pointed to the same LDAP server and your users would have a single login and password for all of the different systems, all written in different languages, all deployed on different machines. This is a bread and butter use case of LDAP, and pretty much every system can handle this out of the box. Glassfish and Tomcat can both readily validate against an LDAP server. So can Apache (Web server), Postgres (Database), Postfix (email), etc. etc.
So if you want simply a shared credential, you get that "for free", right now, by installing an LDAP server. LDAP is a bit of a different beast than something like a DBMS, but once you study it a little and "get it", it's really quite nice. OpenLDAP is a popular LDAP server, but I'm partial to ApacheDS.
The way to set that up in a Java EE container is to set up a "Realm". GF and Tomcat both have LDAP realms out of the box, I imagine the rest do to. But the nut there is that you need to use Java EE security to leverage the Realm.
See, the detail with a Java EE Realm is that it's an aspect of the CONTAINER, not the application. Just like a connection pool is a container resource that your application leverages. Most people want security to be a part of their application, where they feel they have more control over it.
That's all well and good until you start getting a bunch of different applications and everyone is configured differently and has separate user lists, and password policies, etc. etc.
LDAP can fix a lot of that, since you configure them all to use the same credential store.
The Realm fills that need on a Java EE server. Your application is configured to use a Realm provided by the container. If you have several applications, and a single Realm, then they all get to share the credentials within that Realm (regardless of the Realm type).
Realms can be anything: file based, db based, LDAP, etc. Realms also cluster if the container clusters (which can be handy).
The dark side of Java EE security, and why most apps avoid it is that, since, again, the Realm is part of the container, and not the application, it can be a little ungainly to use, and perhaps not offer the features you like in terms of user management, password policies, etc.
But the bright side of Java EE security is that once you're under its umbrella, you can leverage the credential all over in your code easily. A person logs in to the web site, and that credential can be used there in the web app, or automatically propagated back to the EJB tier (ever a remote EJB tier), and the information is always handy.
You can point your web apps at a realm, you EJBs, your web services. They all leverage the same pieces.
In order to get kind of the best of both worlds is to leverage container specific mechanisms to access the containers security. This is the other dark side of Java EE security.
Things like Realms, and direct access to container security are not portable across containers. GF does it different than Tomcat does it different from WebLogic. It's all really close, but differs in details so your code won't port seamlessly.
The bright side is for in house apps, most folks simply leverage the container they have, put a reasonable abstraction around the container dependent code, and call it day noting that yes, they will have to port this if and when they move to a different container. But, in practice. much like a database, once a container platform is chosen, folks tend to snuggle in tight and stick with it.
Finally, Servlet 3.0 (In GF3 and Tomcat 7) standardizes more of the programmatic login issues to make them more portable across containers, but the underlying concepts are the same.
Now, SSO.
SSO is a different beast. But, out the gate, both GF and Tomcat support SSO for web apps. This lets you log in to one web app and have be able to easily access others without having to log in to them. But the SSO is a little bit limited since it relies more heavily on the container security and its lifecycle, rather than a more flexible one under the control of the application. Mind, not just on Realms (that's a given), but on the actual container based FORM login, rather than a custom programmatic login. FORM login is not spectacular, but it's functional and it works. Implement a Realm, deploy your apps to a single instance of Tomcat or GF (or a cluster in GF 3.1), and you get SSO for free, so if that's important, it's kind of nice really. It's usability is fine for back office apps, but not perhaps the public internet.
If you want a more sophisticated SSO solution, then you need look at custom implementations. OpenSSO is one of those, and it relies on SAML and the SAML web profile. However, there are others. There's CAS, Atlassian Cloud, Kerberos, and OAuth as well. Those are all using different protocols than SAML. If you want to stick with SAML you can also look at Shibboleth, or even SimpleSAML (SimpleSAML is a PHP server that acts as a SAML Identity Provider, among other things, but you still need a Service Provider within your applications).
Whatever protocol you choose, the process is basically the same (detailed here -- Cross Domain Login - How to login a user automatically when transferred from one domain to another).
But the devil is in the details. And, boy, are there devils.
All of these systems are complicated. SSO is complicated. For example, now that you have Single Sign On, what about Single Sign Out? What about Single Time Out? What about credential changes while users are logged in? What about an STS (Secure Token Service) for your Web Services? (STS offers a similar delegated authentication mechanism for web services.)
SAML introduces you to a whole lot of new vocabulary, and a lot of configuration. It's not readily picked up since the documentation isn't stellar and relies a lot on standards documents which talk to a higher level of generic things, and not to you and your application specifically.
If you don't need really need SSO, then you'll likely be content with something like a central LDAP store and going on from there.
All that said, as an example, our applications support both a DB and LDAP backend. They use Glassfish, and Java EE security. We completely control the user experience. We also support SSO via SAML (we wrote our own Identity and Service Providers), and we have both shared credentials via LDAP and SSO across Java and other applications, using our code and third party code. The bright side is this is all standards based. The dark side is that standards are communicated in english, and english is subject to interpretation.
I say this simply to say it can be done. I have also written ad hoc, back of the napkin SSO implementations, both same domain and cross domain (same domain is simple with a shared cookie) using simple Servlet Filters. Password policies, password recovery, keep alive timers, multiple window timeout and session management (that's a hoot), roles, privileges, etc. etc. Been there, done that.
Also, I would be remiss to not mention Spring and Spring Security which offers all of this on top of Spring. I have not used it (I'm not a Spring person), but those folks do know what they are doing so it's worth looking at.
Please note that "Is there a way to make OpenSSO/OpenAM talk to Database for its authentication and authorization?" is phrased wrong. The question details and answers only deal with the authorization aspect. OpenAM works great with a MySQL database of users and passwords (authentication), and can use it's hidden/embedded LDAP server for storing policies and other settings.
It sounds like you still need to flesh out your security model, but you will likely find you do not need something like OpenAM at all, and can just use container/framework provided security.
This list might provide a good starting point:
http://en.wikipedia.org/wiki/List_of_single_sign-on_implementations
with JOSSO and Shibboleth springing to mind.
OpenAM has two separate stores, a User Store, where users and all the accompanying properties are stored and a Configuration Store, which holds the configuration. There is a database User Store, which is available in OpenAM however I have never tried it. The SO question you were pointing to was referring primarily to the config store, which while LDAP only, is embedded in OpenAM (so doesn't require direct management).
Personally I am a fan of Tomcat over Glassfish, as it is a fast and light Servlet container, without all the associated bloat which goes with a full J2EE container.
You can use OpenAm with RDBMs. I am using JBDC based user store in OpenAm
OpenAM seems to have the ability to plug in your own authentication module.
Presumably, you can make your DB calls from within your extentsion of the AMLoginModule.
I have successfully build a custom user repository for OpenAm. Since this question have not been active for a while and because it would be too long to describe in details here how to do it, I will just give a few hints. If you need help on specifics, fell free to ask me.
Your basic entry point needs to extends com.sun.identity.idm.IdRepo.
You need to register your custom repository using ssoadm.jsp?cmd=add-sub-schema.
From this point, your repository type will be listed among the other types when you create a data store for a realm.
Good luck !
I'm having an inconvenient dealing with sessions..
I have this:
www.mydomain.com
sub1.mydomain.com
sub2.mydomain.com
sub3.mydomain.com
and when I log into "www", then I change to "sub2" (for example) I
figure out it creates another session :S
why is that??
I need the same session for www, sub1, sub2, sub3, and so on.. ALL in
"mydomain.com"..
what can I do?? is it like that and I have to make a trick?? or is
there a "legal" solution for what I want??
The JSESSIONID cookie is issued by the container, and the cookie domain and path is always that of the web application's domain and context root.
It appears as if you have multiple applications in which case, the JSESSIONID issued by one application will not be recognized by another, due to a change in either the domain or the context root, even if the applications are in the same container.
There are multiple ways to deal with this:
If you are not dealing with a high-value application, and if you can guarantee that no 'rogue' applications will be deployed on the server, you can configure the server to share sessions across applications. Weblogic Server can be configured to do this.
Use a central authentication and session management provider - SSO.
Use TLS/SSL - most servers do not issue a JSESSIONID cookie when communication is over SSL, and instead use SSL itself to store state. You will have mixed results here.
Update:
Glassfish v3 allows you to set the domain for the session cookie. This is done via the session-config element in sun-web.xml. I'm not sure if this is available in v2 or lower versions of Glassfish.
Yes, it is like that because you will have separate session cookie for every different domain. Which web server do you use ? You may implement SSO related solution to share data across the domains.
Look at this tutorial: http://javadude.wordpress.com/2011/05/12/glassfish-3-1-%e2%80%93-clustering-tutorial-part2-sessions/
I summarized all steps for Glassfish 3.1 and session replication