I am trying an application setup in JBOSS AS 7 and Struts 1.2.8.
We have a monstrous project which needs to be broken down into separate deployments so that we can micromanage different modules (i.e. do hot deploy or ONLY deploy the bits that need changes).
So there is a Portal - which has several modules inside it - and though the modules share some common functionality like interacting with some (not all) common databases and same ESB in the backend. However functionally all the modules are pretty independent. Hence we want to deploy a Common.war - which will have the Login page and will manage authentication and authorization. Then all other modules will be deployed on their own wars. Any common functionality like communication with Databases and ESB will be pushed to JNDI Datasources and Stateless EJBs.
Now say when a user logs in he will go to
https://myportal.com/login - this is hosted and serviced by the Common.war
Once logged in he will be stored in session and redirected to a url https://myportal.com/module1/action1
The 2nd url will be serviced by the war module1.war. Now when this Action tries to access the session and check if the user is the one who logged in - will it be able to access the session for Common.war deployment? Not too sure if a session will be per war or per application server. Any work around if not?
All common back end integration logic will be deployed as EJBs - so I guess that will be accessible by any war. Or is there a better alternative?
You have to introduce session replication and single-sign-on to have the different webapps to share the login (and other) information. I am not sure how you can do it on JBoss, I tried on Glassfish, it worked.
Maybe this link or that link could be useful.
Related
Azure VM, Cloud service or Web job?
I have a configurable console application which runs continuosly. Currently it is running on a VM and consumes lot of memory (it is basically doing data mining).
The current requirement is to have multiple instances of this application with different set of configuration which can be changed by specific users.
So where should I host this application such that the configuration can be modified using some front end which provides access managements(like Sharepoint),ability to stop it/restart (like WCF service) without logging on the VM?
I am open to any suggestions/ideas. Thanks
I don't think there's any sold answer to this question as there is the preference variable but for what it's worth, if it were up to me I would deploy it against individual azure VM's for each specific set of users. That way if the server resources went up because of config changes the user group made it is isolated to that group, and with azure, will scale automatically to meet the resource demand. Then just build a little .net web app to allow user to authenticate and change configuration settings.
You could expose an "admin" endpoint for your service (obviously you need authentication here!) that:
1. can return the current configuration
2. accept new configuration
3. restart the service (if needed). Stopping the service will be harder, since that leaves the question on how to start it again.
Then you need to write your own (or use a 3-party (like sharepoint or a CMS)) application that will handle your users and under the hood consume your "admin" endpoint.
Edit: The hosting part: If I understand you correctly your app is just an console application today, and you don't know how to host it? Well, there are many answers to that question. If you have a operations department go talk to them, if you are on your own play around and see what fits you and your environment best!
My tip: go for a http/https protocol/interface - just because there are many web host out there, and you can easy find tools for that protocol. if you are on the .NET platform check out Web.API or OWASP
Azure now has Machine learning to process data mining.
You should check if it's suit to you.
Otherwise, you can use Webjob:
Allow you to have multiple instances of your long time running job (Webjon scaling out).
AppSettings can be change from the Azure Portal or using the Azure Management API
Does the glassfish SSO implementation implement any standards? If so, which ones?
If I have a dependency on Glassfish SSO for my applications, will my applications be portable - will the SSO work if I deploy my applications to another web container such as tomcat?
Glassfish, like many (all?) containers, uses the concept of a Realm when working with container-based security. I don't know if there's a standard to define a Realm, but certainly code that we've written that delegates to the Realm runs in Tomcat, Glassfish and Jetty, and OSGi containers like Apache Karaf also have Realms that seem to be the same (but I haven't actually tried that one yet).
The SSO implementation is entirely on the container side - if several applications use the same realm, then you can configure the container to enable SSO across those applications. The fact that the Glassfish implementation of SSO is a tomcat valve is entirely hidden to the application - so long as the container supports realms, and can be configured to enable sso across applications using those realms, then the application is portable across any such container.
Caveat - this is all based on my (limited) real-world experience. I don't know how common Realms are, nor if there's any standards compliance between them. But for our use, they seem (so far) to be a reasonable, portable abstraction.
It seems that the GlassFish implementation is based on the Tomcat valve org.apache.catalina.authenticator.SingleSignOn and not on a Java/Java EE standard.
It should be possible to port applications to other app servers that are based on Tomcat, though I would recommend doing some tests first.
I'm migrating a lot of websites from Resin 3 to Tomcat 7 (centos 4/apache 2.20) and I'm struggling to determine what type of configuration matches my requirements. In particular:
proxy_ajp vs mod_jk vs mod_proxy for passing requests to Tomcat/Railo
automating deployment of new sites
putting WEB-INF outside the site roots (to simplify cloning sites)
using apache itk with tomcat so each vhost runs as a different user and process
having a single shared railo server administrator config
support for SES URLs with no extension (ie: /path/to/page)
SSL support required
I've read a lot of howtos already but most are out of date or provide conflicting advice. I would like to see some examples from people who run many railo vhosts and deploy them automatically or programmatically. In general I'd prefer efficiency/speed over simplicity as I want to get the most out of limited resources.
I could have asked these questions separately but I want to be sure any answers take into account all the above factors (assuming the requirements are actually compatible).
firstly, check out the vivotech installers - they are a hosting company, so use their installers as your base, they are flawless. (it uses tomcat)
railo 3.3 makes it a lot easier to deploy contexts from admin, so scripting this shouldn't be that hard.
web-inf should be automatically put into a site when it is defined in tomcat
if you give each user a new context-root, then they will have their own admin
every webserver (apache/iis2k8/even tomcat) supports url-rewrite
everything supports ssl
you might also want to look at how you're going to tune your jvm's for this senario, then do some load testing to see how they fare.
drop an email to sean corfield, google railo and his name and you'll get his email.
LDAP authentication in different J2EE servers is different, unfortunately.
Eg. If I develop a code in JBoss for LDAP authentication with LDAP login module of JBoss, 99% chances are that it will not run in WebSphere or any other J2EE containers. Maybe if I import that library jar files, it might work. I’m looking at just porting the application and not having to worry about library files, unless we have written the libraries. Libraries of J2EE servers must not be copied from one server to the other. I don’t know if that could be called code ethics!!
Is there a J2EE server independent module for LDAP or way of programming for doing this?
Is the solution – code from scratch using JNDI the only method? Please advice.
I'd suspect that most J2EE container already have an LDAP module for the authentication, in which case the problem you're having isn't really about programming, but about adapting the configuration from one container to another. Little to no actual code should be required for this. It's not clear why you would develop your own code for LDAP authentication then.
If you really want this configuration to be container independent, you'll certainly need to embed the authentication within the webapp itself.
The Restlet framework, for example, can do that, but it's part of a wider architectural choice, which may or may not be what you're after.
Even if you program your own LDAP code via JNDI or JAAS for example, you're likely to have to tweak the configuration of the container, perhaps for its security manager to let the connections to your LDAP server through (if enabled) or at least to configure which LDAP server to use when deploying the application.
I think in the general case, it's probably wiser to use the container's module (which will vary depending on the container). It ultimately depends on how you configure your webapps when deploying them.
When testing various authentication solutions (my own LoginModule etc) in JBoss, it seemed to me that sometimes when I redeployed a change or otherwise provoked the login form to show, that JBoss didn't actually call the authentication module.
Just wondering if there is some type of short term caching going on?
I tested both from a web application (taking care to delete cookies etc) and from a fat RMI java client.
Of course, If I restarted JBoss, the full authentication process was followed.
Is there a cache, and if so, can it be disabled for development purposes?
Yes, JBoss caches authentication information by default for a few minutes.
To disable caching, set DefaultCacheTimeout to 0 in the configuration for the JaasSecurityManagerService. The configuration is in the "jboss-service.xml" file.
For more info and various ways to flush the cache, see CachingLoginCredentials at jboss.org.