Answer is No. JBoss is as secure as you want it to be.
Well, according to a recent study by Fortify Software (that has been widely reported everywhere in media), Open Source software poses security risks. The report has considered a set of factors to come to their conclusion.
According to Fortify, JBoss scored very well in security aspects (except that we lacked an email address to privately report security vulnerabilities). That is fixed with basically modifying the html of appropriate pages on the web to display the email address.
In a nutshell, if you have a security vulnerability to report to JBoss, then send an email (privacy guaranteed) to (security AT jboss DOT com) or (security AT jboss DOT org).
a) I just returned from Oslo, Norway where we held the W3C WSC working group face to face meeting at the Opera Software HQ. We basically discussed items/text that would go in to the 'last call for June', a deliverable for June 30, 2008. What this means is that with a few months of usability testing, the specification should be public in about a year.
What is XACML? As you are aware, the authorization space is pretty complex unlike the authentication landscape. Access Control requirements can become extremely complex and unmanageable.
Enterprises typically employ proprietary mechanisms such as ACLs to handle access control use cases. Oasis XACML is the only standard that is making an attempt at addressing the complex access control landscape.
In my opinion, the Java EE specifications covering security have been proceeding at a slower pace in comparison to the growing needs of the complex heterogeneous enterprises (Mergers and Acquisitions are happening at a healthy pace).
Recently, I was fortunate enough to participate in a OASIS XACML Panel at the IDTrust 2008 workshop at NIST, Gaithersburg, MD. XACML is certainly a positive step in defining a language for the complex space of access control. Whether xacml is the perfect solution to meet growing complex fine grained authorization needs of the Java EE space, remains to be seen, but it certainly has the goods to meet the current needs. I made a case for extending Java EE specs to incorporate Identity and Access Control needs for the various containers.
At JBoss, we take security pretty seriously. I am on the technical committees of many of the standards at Oasis, JCP and the W3C. Some of the standards where I work include the Oasis SSTC (responsible for SAML), WS-Federation, XACML and Enterprise Key Management Initiative (EKMI).
Why is XACML Important? - Unlike Authentication, AccessControl/Authorization is a complex area where Role Based Access Control (RBAC) is inadequate in many enterprise situations. XACML is a specification that tries to mitigate this with complex policies that can be woven around a combination of subjects (users/user-agents etc), resources (on which the access control is desired) and Environment (IPAddress, Date, Time etc). You should be able to declaratively (via XML or construct policies) to say things like "Allow this portion of the web site to 18 year olds when the time is between 9am and 5pm", "You should update your own payroll information and can do it when you are employed and on Fridays only" etc. - Enterprises have been doing this via ACLs and other proprietary mechanisms. Now they can use a standard way.
Dependencies: JDK 5 and later (Need JAXBv2) Sun JAXB v2.0 and later ( I used v2.1.4). You can use the one from here: Sun JAXB Sun XACML v2.0 Use the one from here: SunXACML V2.0 JBoss v5.0 JavaEE Jar (javax.xml.stream support. You can get this from JDK6 or any EE distibution). JBoss JavaEE
Hal Lockhart, Bill Parducci, Anne Anderson (of the Oasis XACML TC for the specification), Rich Levinson, Dennis Pilipchuck (Oasis XACML Interoperability) and Seth Proctor (SunXACML Implementation) We use the SunXACML implementation for the business logic, policy evaluation etc. It is an implementation detail. The users of JBossXACML will have to concern themselves with JBossXACML's interfaces and object model (and not deal with SunXACML).
How do you want to get involved?
Why don't you sign up for zero-spam mailing list for the JBoss Security Beta Program at. JBoss Security Beta Mailing List ? Please remember the email address would be jboss-security-beta AT redhat DOT com Once you sign up as a beta participant, you can have a close collaboration/interaction with the JBoss Security team.
We had the first Beta version of JBoss Federated SSO v1.0.0 released a few days ago. Going by the download count and the questions asked by the users in the forums, we have got to assume that it has been well received by the community.
At JBoss World Berlin, there was a presentation on the framework. The room was filled beyond our expectations. Addditional chairs had to be brought in, which made little difference to a number of people who had to stand (some even outside the room). Considering it was a large room, we have got to accept that SSO is a big requirement for enterprises. The feedback from the attendees at the end was positive.
If you would like to take a peek at a demo showing federated SSO happening between two JBoss SEAM based applications (a DVD store and a Hotel Booking application), I invite you to check the following SWF file(you can open in a browser like Firefox). Flash Demo
Every year, when I watch the July 4th fireworks in the US, I think of one thing: Freedom and what it has meant to me. The fireworks at Disneyland in California was excellent when I visited in 2001. It was all about democacy and freedom.
A similar freedom is given to me by open source software - be it linux, be it Open Office, be it JBoss. Free of licensing costs - free of closed source. Just as democracy may have some issues, open source may have issues - but in the long run, they both signify the same - FREEDOM.
I would like to remind users to always use response.setEncodeURL(url) to encode the url just in case the client's browser does not eat cookies.
Generally, users want to invalidate sessions on logout. So they invalidate the session on the serverside. But do send back a cookie with MaxAge set to 0, so that lingering session cookies in the browser do not create problems in your servlet code.
Last night I attended a good presentation on security. The presenter appraised the audience on securing web applications against SQL Injection, HTML injection, cross-site scripting and other things. He did mention that there are a whole bunch of legislations like HIPAA, SOX etc that as an external facing web app , you will have to comply. Now the question is "How much security is enough?"
J2EE provides decent security facility in the spec. You can create security settings in the web container, in the EJB container and all the way to the data access layer. When vendors provide products, they cannot assume reasonable defaults for security. Security is mostly disabled by default. Hence the responsibility of ensuring security in the application is on the developers developing the application. But the question is if the developers themselves are new to J2EE, new to Java , new to programming, is it possible for the application to embrace security? There is JAAS which provides a good pluggable framework for authentication and authorization in the Java world. Is it practical for developers to embrace JAAS or the container settings or Tomcat Valves etc to provide security as an aspect of the application, without instrumenting their business code? It should be. But is it??? This brings us to a good topic: importance of filters, handlers, valves and interceptors. These give me the options to plugin logging, security, tx and other aspects to my business code that can sit in servlets/EJBs/Web Service endpoints. I can get cleaner business code.
Providing security to anything in the computer world is viewed as an overhead but it is a necessity. Security and performance many times do not see eye to eye.
If I am a developer, - would I care about defensive programming? - would I care about maintainability of my code? - would I care to get it code reviewed? - would I think about good exception handling? - would I think about coding guidelines?
I SHOULD, right???
There is xml security that provides message level security and then there is transport level security (SSL). Message level security has some tangible benefits like you can encrypt portions of your message that needs to be secure. With SSL, the whole communication is secure. But the question is, is the xml encryption foolproof?
Identity Management, SAML, Liberty Alliance: One stop storage of credentials at providers. Applications will ask the provider for authentication/authorization, via assertions. Can these providers be foolproof?
As you can see that when I think of security, there are various directions in which my though process goes. I have listed them under various sections. What do you guys think?
Security is a ocean, where every ship needs to be, either reluctantly or with full consent.
Many of the open source projects are going the Axis path. JBossWS went that way until the 4.0 version(that got certified for J2EE 1.4 compliance). To achieve compliance, JBossWS had to fork Axis 1.1 and make it compliant with Enterprise Web Services. The Axis project has moved onto Axis 1.2 version. I do not think they will need our forked code back!
Currently, development is happening to implement our own stack for Web Services. Starting JBAS 5.0, JbossWS will not use Axis but its own stack, to do web services. At the same time (or later), JBAS 4.0 will get the backported JBossWS new stack.
At JBossWorld in March, Thomas Diesler, JBossWS Project Lead, will showcase JBossWS using its own stack.
In a related area, I am working towards integrating Apache jUDDI/Apache Scout to replace the open source ebxmlrr project that is being shipped with 4.0 for JAXR (Java API for XML Registries) compliance. I am also working towards providing Web Services Tools similar to wscompile provided in JWSDP.
For the 5.0 release, we should have a solid JBossWS implementation with tools, documentation and Jaxr support (with an integrated UDDI registry). After that there will be a backport into 4.0.
On our roadmap, we do plan to implement JSR 181: Web Services Metadata for the Java Platform ( http://www.jcp.org/en/jsr/detail?id=181) that will provide annotational support to implement web services.
Stay tuned and give us feedback. If you have the interest to weather state of the art programming and want to contribute, look at the JIRA for tasks and start helping out.
Looks like Bangalore has welcomed JBoss. There is going to be another JBoss Advanced Training in February. If you are interested, look at Bangalore Training Info . See you in Bangalore. Feedback from the first training is at: Feedback Link
I disagree with Allen with his current thoughts on open source.
I read Allen Holub's columns every time a SD Times copy drops in my mailbox. Sometimes he touches on topics that are thought provoking. For example, he said in an old article that when newcomers to any technology, ask questions in a list, they are frowned at by the experienced people, are rudely treated etc. He questioned the whole meaning of "User Lists" and the idea of a community in the online world.(http://www.sdtimes.com/cols/javawatch_109.htm) I think that is a good observation and a lesson to remember for the online community.
In his latest article, Allen opines that the tomcat and hibernate codebase are a mess. I am surprised at this because the popularity, acceptance and the userbase for both these projects are on the rise and many books have been written.
Ok. Back to the question: "Why do I love open source?". I love open source projects because they give me a choice while keeping my costs down. Also when I am developing code and I hit an issue with a library and that happens to be an open source project, then I can download the library code and step through the code in an IDE and figure out if the problem is in my code or is it in the library code. This small exercise can save me a lot of time, if the issue is in my code. Lets say I am using an open source parser to parse some of my XMLs and suddenly I get an exception from the parser with not much information. Now how do I know what the parser is expecting and what it is actually getting. I can download the parser code, step through it in an IDE to the location where it is throwing an exception and see whats wrong. Either it is a bug in the parser (most likely not) or I am doing something stupid (most likely). Imagine if I was dealing with a closed source product and I am facing problems. I have to knock on the doors of the company with a hope that my cries will be heard. If I am lucky, it may entered as a bug or I may get a fix. Considerable time will be spent if the cries go unanswered. If all I wanted to know is whether the problem was in my code or in the dependent library code.
Let me name a few open source projects which have become popular in the community - Linux, Apache Http Server, Mozilla, Struts, Tomcat, JBoss,Hibernate,OpenLdap, Apache Xerces, Eclipse and many more. The acceptance of these projects in production environments has changed the perspective of many individuals towards open source projects. I may not be wrong if some of the naysayers may be contributing to open source projects they deal with, via bug fixes, questions etc.
It is true that in many open source projects, developers do not get paid and they develop code in their free time, while burning the midnight oil. Documentation and QA may take a backseat. But as these open source/voluntary projects become popular/get accepted, the wheel rotates. More developers jump in, more users show up, lots of questions get asked and importantly, bugs get fixed. Many experts end up writing books for the benefit of the community. JBoss with its motto, 'Professional Open Source' has greatly encouraged open source developers to develop what they love to do while getting a salary.