How to model a bi-directional relationship and make it mandatory? - alloy

Question

I'm developing a simple role-based authorization model, using https://profsandhu.com/journals/tissec/p207-ahn.pdf as an inspiration. The code so far is:
abstract sig Object {}
abstract sig Operation {}
sig User, Transaction extends Object {
by: some Permission
} {
by.on = this
}
one sig View, Update, Add, Delete extends Operation {}
sig Permission {
to: one Operation,
on: one Object
}
pred show {
#Permission > 0
}
run show
The first instance generated already shows two issues with my model:
When a permission has an "on" relationship to a user, the reverse relationship "by" must be there as well;
Two permissions on the same user can delete it, which doesn't make sense. There should be always zero or one permission for a particular operation on a user.
Any ideas on how to solve?

Answer 1

You can add these constraints as "facts":
fact {
all p: Permission, u: User | p.on = u implies p in u.by
all u: User | all disj p1,p2 : u.by | p1.to != p2.to
}
Now to verify the last fact, you might also want to check that two permission to the same operation are never owned by the same user:
assert sameOperationImpliesDifferentUser {
all disj p1, p2: Permission | p1.to = p2.to implies no (p1.on & p2.on & User)
}
check sameOperationImpliesDifferentUser

Answer 2

The first instance generated already shows two issues with my model:
When a permission has an "on" relationship to a user, the reverse relationship "by" must be there as well;
It is generally bad idea to have bidirectional links in Alloy since it is so easy to traverse in both directions. Models are significantly easier when you just make them in the most convenient direction. You can always use a function or macro to traverse them backwards. #wmeyer shows you correctly how to constrain the reverse link but your model gets a lot more complex and therefore harder to debug.
Two permissions on the same user can delete it, which doesn't make sense. There should be always zero or one permission for a particular operation on a user.
Why doesn't that make sense? These kind of constraints are hard to enforce and provide as far as I can see very little value. If you get roles in this model, I could see you could end up with multiple identical permissions for an Object. Constraining the model might then cause the model to have no solutions. Daniel Jackson also indicates that the best way to work is to minimize the constraints.
If you still want to enforce no duplicate permissions, I would introduce a Role object that holds the permissions.
I understand (I think) why you want a User to extend Object but it does make the model's solutions awkward to browse. A Role can also help here.
So my 2cts model would be:
abstract sig Object {}
enum Operation { View, Update, Add, Delete }
sig Transaction extends Object {}
sig User extends Object {
role : set Role
}
sig Role {
permit : Operation lone -> Object
}
With a solution:
┌─────────┬─────┐
│this/User│role │
├─────────┼─────┤
│User⁰ │Role²│
│ ├─────┤
│ │Role³│
├─────────┼─────┤
│User¹ │Role⁰│
│ ├─────┤
│ │Role¹│
│ ├─────┤
│ │Role³│
└─────────┴─────┘
┌─────────┬─────────────┐
│this/Role│permit │
├─────────┼───────┬─────┤
│Role⁰ │Delete⁰│User¹│
├─────────┼───────┼─────┤
│Role¹ │Update⁰│User⁰│
│ ├───────┼─────┤
│ │View⁰ │User¹│
├─────────┼────┬──┴─────┤
│Role² │Add⁰│User¹ │
├─────────┼────┴──┬─────┤
│Role³ │Add⁰ │User⁰│
│ ├───────┼─────┤
│ │Update⁰│User¹│
└─────────┴───────┴─────┘