Entitlements vs. Attribute Changes



A Forum reader recently asked:

"As I understand it, an attribute or an entitlement can be used as criteria for granting/revoking resource in the connected system. I have been using entitlements duing my testing. But when I think about it, I can use a attribute to represent the grant and remove. So what are the advantages of using an entitlement to grant/revoke resource in the connected system? Are there situations where I absolutely need to use entitlements?"

And here's the response from Lothar Haegar ...


If you can decide based on one or two attribute values, that's a clean and easy approach. Entitlements are a lot more flexible, though - they are basically dynamic groups, and whoever is in the group will get the entitlement. That makes it easy to manually add technical users to it, or change selection criteria in the future without having to touch the driver config. Also, entitlements can query values from an application (like potential AD group names a user can become member of) and provide priorization when granted more than once. That's very powerful.

On the other hand, if it's as simple as checking one attribute value, the use of entitlement is a lot of overhead. You have to edit them in iManager, which may become a pain with the more entitlements you are using. Also, you can't run a driverset that has the RBE driver in it on multiple servers simultaneously.

In a nutshell: if your criteria are very simple, using an attribute instead is fine. The more complex your selection rules become, the more sense it makes to let RBE handle the stuff.

Father Ramon adds:

The primary advantage of entitlements over attributes is that you don't need to extend the schema every time you need a new one.


How To-Best Practice
Comment List