techno.blog("Dion")

Since installing mt-scode for MoveableType, I wondered if there was a Java framework that would easily allow you to add CAPTCHA style authentication to our apps.

There is an open source framework: JCAPTCHA.

There is an article on the framework Use a CAPTCHA-based authentication module for J2EE Web applications

Spam has become one of the biggest menaces on the Web. Many community-based applications force authentication only to distinguish a valid user from an automated spam-bot, which can be overkill in some cases. CAPTCHAs help in differentiating between real users and automated bots. In this article, Anand Raman uses CAPTCHAs as weak authentication mechanisms for J2EE Web applications. He begins with a quick introduction to both the J2EE Web application security model and CAPTCHAs. He then builds on these concepts to implement a JAAS (Java Authentication and Authorization Service) login module using CAPTCHAs and integrates it with an application server’s existing security infrastructure. The artifacts are based on standard J2EE security mechanisms. Hence, the module can be reused on any J2EE application or across different application servers with some minor modifications.

We have been using Acegi security recently, rather than CMS, and it would be nice to plug this in over there.

I often worry about the images. On one site I had to reload 3 times to get an image in which I could actually read!

I remember turning off the feature in my voice mail that would automatically log me in if I called from my home phone number.

Since this auto-logon is done via caller id it is NOT at all secure. There are simple services out there which enable you to look like you are coming from any number at all.

This came to light with the Paris Hilton fiasco. Hackers immediately tried to get into the voice mail of Paris and the other celebs that she had in her address book. They got into Vin Diesels, took the saved voice mail, and setup a new voice mail message. Who knows who else they did that too? :)

So, turn off auto-logon on all of your voice mail systems (in fact, the option should probably be taken away by the carriers. I know it is convenient, but it is just not safe).

A fair amount of Adigio projects have taken advantage of Acegi Security instead of container managed security. They just released version 0.7.

Dear Spring Community

I’m pleased to announce the Acegi Security System for Spring release 0.7.0 is now available from http://acegisecurity.sourceforge.net. The project provides comprehensive security services for The Spring Framework. You can read about the features in detail at http://acegisecurity.sourceforge.net.

There are many changes, improvements and fixes in release 0.7.0 (as listed at http://acegisecurity.sourceforge.net/changes-report.html). The major new feature areas are:

* Significant improvements to ACL security services
* AspectJ support (useful for instance-level security)
* Refactoring of ObjectDefinitionSources (especially useful for web URI
security)
* Automatic propagation of security identity via RMI and HttpInvoker
* Integration with Servlet Spec’s getRemoteUser()
* Refactoring of Contacts sample to use the new ACL security services
* Additional event publishing (now includes authorisation, not just
authentication)
* CVS restructure to use Maven as the build system
* A new project web site with FAQs, links to external articles etc

The new ACL security services deserve special mention, as they make it possible to develop applications that require complex instance-based security without any custom code. The entire configuration of such applications can be declared in the IoC container using standard Acegi Security services, so this should help significantly improve architecture and development time.

As per the Apache APR project versioning guidelines, this is a major release. We expect the next major release will be 1.0.0, although release 0.7.0 should be considered stable enough for most projects to use. There are detailed upgrade instructions included in the release ZIP and on the Acegi Security home page.

For Maven users, Acegi Security’s latest JARs are available from http://acegisecurity.sourceforge.net/maven/acegisecurity/jars. We will also be adding release 0.7.0 and above to iBiblio.

We hope you find this new release useful in your projects.

Best regards
Ben

I understand that a lot of standards end up being lowest common denominators. That is one of the issues with design by commitee.

However, I wish that the standards would have defined hooks that allow you to write code which uses the standard but adds on functionality.

Take the Servlet API for an example. This is one of the better APIs in J2EE. It is pretty darn portable. I try really hard to be able to have a .war that can be placed in a container and have it just run, but this isn’t always the case. If I have to open up a server.xml I think I failed :)

One example is Container Managed Security. Their are a couple of features that I really wish were in the spec. How about the ability to LOG OUT (not just nuking the session!). What about enhancing the security piece?

Take a login box. Form-based security allows you to setup a username and password and get authentication/authorization going. However, what if you want to do something like a ‘Remember me?’ check box, or the security image that I talked about last week.

Since the spec doesn’t have any hooks, and doesn’t easily allow a filter to kick in before the security piece, this becomes really tough. Well, on some servlet containers. Remember Me? functionality is built into Resin. I don’t have to do a thing. But, unless I know that I want to only run on Resin, I am kinda stuck.

I said before that I wanted to be able to create a .war file that runs in any container. To do this now I use another system for handling security. Trying to get around the CMS system is more trouble than it is worth. Is there a nice programatic API to log someone in and out? No.

For this reason I end up using something like Acegi Security for Spring.

Come on guys, give me some hooks!

And, let’s not get started on JAAS and how there isn’t a standard API to create users/groups in the system! Argh!

CP has talked about porting web app security between different application servers.

Whenever I read about these things, I wish that the specs would cover more, so we didn’t have to do this kind of infrastructure work.

The Servlet spec does a good job and giving us portability among app servers (unlike the EJB experience), however there is still room for improvement.

You can’t just drop a war file in, if you are doing wacky security stuff. It would be nice if this info could be put in the standard, so we COULD. Cookie auth should be a flag that you can just turn on. There should be a standard Realm interface which you can extend and tie together in the web.xml to handle the authentication, etc etc. All should be pluggable, and defined in one place.

J2EE always seems to only go part of the way there when it comes to items like this. Another example is how JAAS allows you to have pluggable authentication/authorization, but how about a standard was to actually manage users? How about a standard createUser(…)/edit/delete?

This is what we have available in PAM on Unix, and we want it at an API level in J2EE!

Although some people think that having billions of Java devices is a “business opportunity”, I also think it is a worry!

I shouldn’t say Java devices. What I mean is devices that are on the network. it is tough enough to manage viruses with a few million computers, but when we get to the next step when even your toothpick is bluetooth enabled? Yowser.

Vulnerability hits Java for cell phones