Java user roles modeling
I think that implementations of TeamRole should not know how to do things.

Based on the name part: ...Role it should only know if a certain user can perform a certain action on a particular resource.

I'm expecting the TeamRole to have a method like:

public interface TeamRole {
    boolean canDelete(Entry entry);
}


And then change the TeamMember:

public class TeamMember implements TeamRole {
    // need the user to be a part of the class here
    AbstractUser user;
    public TeamMember(AbstractUser user) {
        this.user = user;
    }

    @Override
    public boolean canDelete(Entry entry) {
        if (entry == null) return false;
        return user.getUid().equals(entry.getCreator().getUid());
    }
}


You can have an alternative with a static method in TeamMember, so you can avoid the instantiation of the class, and just pass the user (requester) as a parameter:

public interface TeamRole {
    // Java 8+
    static boolean canDelete(AbstractUser requester, Entry entry);
}


So your service method will become:

public static ResponseEntity&lt;Team&gt; deleteEntry(AbstractUser requester, Team team, Entry e) {
    TeamRole role = team.findPermissionsForUser(requester);
    if (role == null)
         return new ResponseEntity("no role found...", HttpStatus.INTERNAL_SERVER_ERROR);

    if (role.canDelete(entry)) {
        try {
            team.delete(e);
            return new ResponseEntity(team, HttpStatus.OK);
        } catch (Exception error) {
            // here you have an actual error to report to 
            // the user, as something that should be done
            // failed.
            return new ResponseEntity(error.getMessage(), HttpStatus.INTERNAL_SERVER_ERROR);
        }
    }
    // So you can say to the user that nothing is wrong 
    // with the request there is just a permission 
    // issue here.
    return new ResponseEntity("user cannot delete entity", HttpStatus.METHOD_NOT_ALLOWED);        
}


Profiling users is always an hard job, and each implementation should deal with the system requirements.

A good design should try to separate as much as possible the authorization part of the logic from the business part.

Authorization, like authentication and accounting should be aspect that can be changed in you system without adding any issue on the business logic.

Please have a look at Spring Security.

I don't mean you should use it, but I think could be a good inspiration on how things could be done cleaner.

Now a couple of things I noticed on your code.

The deleteEnytry method of TeamRole return a boolean, but this is always true!

So why returning such a value?

In this case just put void as the return value.

Have void as a return value from command method is considered a best practice. Of course is not mandatory and don't cover all the case, it is just usual that a coomand should not return something.

In your EntryService you have a NullPointerException:

public class EntryService {
    public static ResponseEntity&lt;Team&gt; deleteEntry(AbstractUser requester, Team team, Entry e) {
        try {         
            // NullPointer here!
            team.findPermissionsForUser(requester)
                .deleteEntry(requester, team, e);
            return new ResponseEntity(team, HttpStatus.OK);
        } catch (IllegalAccessException e1) {
            e1.printStackTrace();
            return new ResponseEntity(e1.getMessage(), HttpStatus.INTERNAL_SERVER_ERROR);
        }
    }
}


the team.findPermissionsForUser(requester) didn't return always a value, as it returns just the value found in the Map, that is an actual TeamRole or null if no entry was found in the map.

And as you catch just the IllegalAccessException you will got an error that could be complicated to debug.