Shiro + Keys stored as strings = failure point or unnecessary concern?

Not getting into too many specifics, this is a high level question.

I've always gone by the idea that it is never a good idea to store primary keys in places that does not have a constraint. For example, storing a primary key in a EAV style architecture ("USER_ID",144). If that user is ever deleted it will not be reflected in the EAV mapping and cause issues farther down the road.

So I'm creating a new application using shiro as a security/permission framework and I need users to be able to edit themselves but not other users, I also need other users to be able to edit anyone. Simple enough:

user1 = "user:441:edit"

user2 = "user:edit"

In addition, I could have someone that can only edit a subset of users, something like this

user3 = "user:459:edit","user:460:edit","user:461:edit"

Or, someone that can edit users that are in a department but only that department

user4 = "department:5898:user:edit"

If someone from user3's list is deleted there's no way to update that user's permissions without magic (going through all the permissions and finding the ones to remove).

Now I don't plan to reset the keys but if it was to ever happen and I DON'T clean up the old keys I could have users suddenly being able to edit users who were recently created after reusing the old keys.

I could mitigate some of this by using a generated code ("user:ciS84nFSHK:edit") that is uniq开发者_高级运维ue across ALL TABLES to manage deletion of permissions. However, adding in a few hundred million records makes me think this can grow unwieldy quickly.

Am I using Shiro improperly? Am I simply overfocused on keys getting mangled? Have you solved these issues? Any help would be appreciated.

After doing some more research with Shrio I've decided to go with pst's suggestion and simply reference the values via a GUID (maybe a 10-digit-alphanumeric instead to preserve space).

So user1 = "user:441:edit" would become "user:96aae854-fc40-42ff-b948-c8944c2fca92:edit" this will help negate the concern about storing keys as strings.