This is just my opinion, but I feel like I disagree with Ewan in some ways.
I think it depends.
I think I definitely wouldn't be returning the EF objects to your client. I would use a package like AutoMapper or whatever to map them to DTO objects that is used only for transporting data to and from client.
However, I don't think it's necessarily bad ...
Best practice is to hide the EF stuff.
This allows you to share you models without forcing the EF dependency, maintain a separate data layer, run unit tests etc etc
You can do this by mapping the EF generated to your models, or by using code first models if you don't end up having to add attributes to them.
I would add an extra Project.Repository to ...
Its generally better to provide fine grained permissions, this makes it possible to change the exact set of information and actions available to a given user. But as you've noted this means being uber specific.
One solution is to order your permission names hierarchically, and use a matching technique like prefix matches, or full regexs.
A role is set of functionality grouped as one like in your case SALESMAN what a salesman can do is driven by permissions, so permission define what functionality is allowed or not.
Basically now there is user which is performing SALESMAN role for which user gets certain functionalities based on permissions which it can perform. Now when a user with SALESMAN ...