Different Templates?
You could use the same template for showing the view for the author and the guest, and modify some elements on the page based on the current user's permissions to that page's artwork. You'd only create two separate pages if the different views would be radically different, and it's more trouble than it's worth to make the page dynamic.
Spring Security for Authorization
Spring Security handles authentication (who is the current user?) and authorization (is the current user allowed to do this?). Here, we're talking about authorization.
There are different ways you can use Spring Security for authorization. One way is to use a chain of voter strategies to decide if the user is allowed to perform an action (AccessDecisionManager). Another is a full-blown ACL implementation where you maintain a set of tables that describe a person's access permissions for each resource you want to lock down. Reading from the ACLs is straightforward, but it's on you to maintain these tables. Every time permissions change, or secured objects are created, you have to insert or update the ACLs. Scroll down here to see an example.
Recommedation: Keep it Simple
I recently evaluated the different methods of authorization using Spring Security, and decided to just use the user's principal myself, and hit the database to see if the user has permissions to a resource. Spring Security is complex, and if you introduce a bug in your ACL-managing code after the site has been live, good luck tracking it down. The bug will only exist for those specific records for which the ACLs were modified.
I'd keep it simple. Create a SecurityManager with methods:
public boolean canViewArtwork(String userPrincipal, Long artworkId);
public boolean canEditArtwork(String userPrincipal, Long artworkId);
Then, call these methods when you need to do a security check. This is the sort of code you can walk away from and come back to later and understand.
Use Permissions, Not Roles
Notice the SecurityManager is checking permissions, not roles. Projects always start with two roles, "user" and "admin". Down the road, these lines always start to blur, and you end up with conditionals all over the place. You can still initially have the two roles in the system, but the SecurityManager will be the only place that deals with them. If you end up adding a third role - no problem, only your SecurityManager needs to change.