For a current project, we're using Olingo on top of hibernate, and picketlink for security and roles.
Users with different roles will have different permissions which affects read / write access to certain properties. Consider the following example:
- One entity "Person" with the properties "name", "address" and "salary"
- Two Roles - "Employee" and "Manager"
While the employee should be able to edit his own address, he certainly can't be allowed to change his salary or another persons address. And while he might be allowed to see his own salary and maybe another users address, he won't be allowed to even see the salary of others, let alone edit it. The manager on the other hand has full readwrite permissions.
This is not a problem on the backend - we can use custom bean validation there to enforce write permissions.
But I want the frontend to be able to reflect the users rights - by disabling the "salary" text field for example or by not displaying it in the first place.
For that purpose I'd like to introduce custom attributes based on user permissions into the oData meta model. Instead of
<Property Name="Address" Type="Edm.String" Nullable="false"/>
I'd like to receive
<Property Name="Address" Type="Edm.String" Nullable="false" Mode="readwrite"/>
Or something to the same effect.
So the question is: How do I introduce custom attributes into my oData meta model with Olingo?
Please do not take the above example too serious. I do realize that simply telling the interface kindly not to show the salary of others via the meta model is inherently insecure ;)
Update:
Ok, it's not that easy. I realize that now. The attributes I mentioned earlier are called "facets" in CDSL (upon which oData rests (pun intended)) and as it turns out, there is a fixed set of facet types. Consequently, Olingo doesn't bother much with abstraction here, you'll find lots of hardcoded stuff instead. I guess it would be still possible to add another facet type, but that would require touching Olingo in many places. And it would eliminate conformity with CDSL / oData - which I wouldn't care about much but which may explain the lack of solutions to the problem.
For now it looks like I'll have to either try and introduce another facet, or to intercept and modify the outgoing xml.
I'm not to enthusiastic about either option, so... Any hint towards a better solution would still be more than welcome!
