An entitlement is just a value, assigned to a user in a specific format.  The driver that implements it knows what to do with that value.

NetIQ is flexible in its Entitlements can be several values, and the implementation can use them to do clever things.  Other competitors have but a single piece of info allowed in all Entitlements.  All examples are in complex systems that are not common... But imagine SAP where you can 'fan out' one account to many systems.  So you can specify the system, as well as the entitelement.

A resource is just an abstraction so you can tag a 'name' to that Entitlement value.  For example, AD Gropups (most common by far) have an Entitlement value of a GUID.  I can give you a GUID value, can you find the AD Group that maps to?  Not so helpful.  In later versions of the driver NetIQ added a second parameter for the Group DN, which is actually a BAD idea, since now renaming a group that has users assigned via entitlements is a pain,  But that is a story for another day.

But that is adding it into the Entitlement value, the 'payload' if you will.  The Resource is much easier to name and rename.  So often people will have a policy in their AD driver, when an AD group is created in some specific container, or with some flag, to create a Resource for it with the Group name in it the name.

Now you have much easier groups to pick and add to your Roles, then trying to find them by GUID's.

You can also add an Approval step to a Resource, so no matter which Role assigns you the resource, the approval is needed, even if the ROle does not need approval.  Protect the Resource.

I have seen that the use of resources and entitlements for the active directory driver is quite useful but, for example, for a REST driver with few roles is it just as useful and/or necessary?

So you would instead assign the Entitlement direct to the Role?  You can do that of course. (or were they deprecating that? I forget now).

But your general assignment of permissions would be done at the Role level, regardless.  I.e. Any Business Logic driver (Loopback?) that tries to manage birthright roles (Based on say Department, Location, Cost Center, or whatever) would only assign Roles usually. Not Resources. 

So to rephrase your question, in a simple driver, that has a few simple entitlement values, what gain do you get out of using a Resource instead of assigning the entitlement value to the Role. Regardless of how you assign roles?

And other than consistency I am not sure.  If SoD's could be defined at the Resource level, then that would be a good example.  But they are at the Role level only.  Maybe per Resource approvals. 

Geoffrey Carman said:

So you would instead assign the Entitlement direct to the Role?  You can do that of course. (or were they deprecating that? I forget now).

This option has been removed.

I was pretty sure that was true.  So then back to the original poster, what were you thinking then?