We will in this example use the Barracuda authentication and authorization resources together with a user database and a Security Realm for designing a secure photo album. The Security Realm, which implements the SecurityRealmIntf interface class, will be designed such that it uses principals and roles.
In order to customize security, we must have an understanding of principals and roles. A principal basically identifies an entity that can interact or perform work with a system. It can be a person, company, process - just about anything in fact.
A role groups certain actions together, and we can then specify certain principals as having particular roles, thus giving those principals clearance to perform the actions.
This is similar to a concept of users and groups in a UNIX system, where users are generally people that may access the system, and groups represent the position that users can hold. For example, a company system may have a user called Allen Smith, who belongs to the group, human resources.
We will in this example create a user database with four users: guest, mom, dad and kids. We will also design a Security Realm, which restricts what a principal can do. The following roles will be created:
|guest||guest, mom, dad, kids|
|family||mom, dad, kids|
The Security Realm we design in this example will give the following access rights to the roles.
The HTTP GET command is used when reading the photo album and the HTTP POST command is used when simulating an upload i.e. when the user wants to change the photo album. As you can see from the above diagram, The HTTP POST command is more restricted than the HTTP GET command.
The security constraints are designed such that the constraint for a directory also applies to any subdirectory unless overridden. For example, the path 'album/noSuchDir' has the same access rights as the path to 'album'.