I've scoured the web, the book, and the forums but I have not been able to figure out how to do this:

1. Create an Audit whenever an insert, update, or delete transaction starts. The audit would have an id, username, and date.

2. Keep a record of what the entity looked like before the change in a history table that stores the audit id and entity's class name, primary key, and toString().

3. Apply the audit id to the inserted or updated entities.

All of the above needs to rollback if any of the logging fails. I think most of the solutions can't guarantee that all the logging and all the changes will rollback because they advocate creating a new transaction to do the logging.

Is Hibernate powerful enough to handle this?

If you want everything to roll back if Auditing fails than you have to do the audit stuff in the same transaction.

All the solutions advocate creating a new transaction to do the logging as Logging is just the side task and you would not want your Business Logic changes to roll back because of some logging did not occurred properly.

Its just the requirement thing,if in your case Auditing is very critical than do it in same transaction and hibernate will take care of Rollbacks in any failure condition.

Hibernate interceptor will help you in this, hibernate provides call back method duing a transaction through interceptor. You can implement hibernate interceptor interface and add your audits logic. Interceptor provides methods like afterTransactionBegin, beforeTransactionCompletion you can use them if you want to audit at the transactional level.
onSave or onFlushDirt will help you see what has been changed in the entity you can use that information to form the audit log . Save these audits using current session. you can obtained reference to current session object from SessionFactory before transaction ends (dont try to save in interceptor methods onSave, onFlushDirty), since all of these will be in one transaction every thing will be rolled back if audit log failed.
I am not clear about your 3 point, do you want to apply the audit id to entities ? If that is the case, i dont think it is good idea because an entity may go under many updates during its life cycles and there will be many audits which are generated for this entity.

Thanks so much for your replies.

I reread some of the book, and I think things are cleared up now. The part I was most worried about was the transaction wrapping all the auditing. The solutions I had read were suggesting to create a new temporary session inside of onSave-- and I thought they were suggesting a new transaction, too. I now see that the temporary session is created inside the same transaction.

About point 3: The purpose is to replace data such as last modified by and last modified data.