Merge pull request #33 from marcjansen/master

Pulled down updated doc submodule.
Add ACL schema files for several sql dbs.

The SQLs were taken from http://docs.spring.io/spring-security/site/docs/4.0.x/reference/htmlsingle/#dbschema-acl
Updated/Cleaned up xml configs in archetype.
Add ehcache and spring ctx support dependencies
Add jdbc properties for ACL database.
Add XML security cfg for ACL support in archetype

The config is based on http://krams915.blogspot.de/2011/01/spring-security-3-full-acl-tutorial_30.html
Adapt some of the ACL-schema SQL statements
Add SQL to create ACL schema and exec on startup

The added SQL script works for H2 and Postgres. It will be executed on startup as configured in the context-init.xml. This way it is ensured that the ACL database exists on after starting up the system.
Minor changes.
Enhanced security module (including test).

The SHOGun2 authentication provider will now request a user from the database. The accountName of the user will be used as the principal in the authentication object.
Make the accountName of the User model unique.
Add findByUsername-method to userService.
Add basic security annotations to the CRUD service
Content initializer creates demo users and app.

For the demonstration of the ACL usage, some access control entries were made.
Adapt the archetype to use the ACL mechanism
Add AOP dependencies to security module.

The AOP libraries will be used to intercept the saveOrUpdate and delete method of the AbstractCrudService in a next step.
Add AclManagement aspect class.

By using this aspect class, the saveOrUpdate and delete methods of the AbstractCrudService will be intercepted (if the webapp is configured properly).
Enable AOP/AspectJ in archetype.

Enabled AOP/AspectJ in archetype and use the SHOGun2 AclManagement aspect, which was commited in the previous step.
Add custom SidRetrievalStrategy implementation.

This SidRetrievalStrategy behaves like the default (SidRetrievalStrategyImpl), but checks if the principal of the current authentication object is a SHOGun2 user object. In such cases, the accountName of the SHOGun2 user will be used to build a PrincipalSid.
Use SHOGun2 user object as principal of auth.

The Shogun2AuthenticationProvider will now pass the SHOGun2-User object as the principal of the authentication. The authentication provider has also been enhanced by checking if the SHOGun2 user object actually has grantedAuthorities. (The last point is a preparation as we do not yet retrieve the authorities from our SHOGun2 database).