agorian Respected Contributor.
Respected Contributor.
533 views

Roles or resources? That's the question...

Hi all,

Introduced in IDM 3.7, resource model fulfill some requirements that roles doesn’t, but brings no SoD, keeping roles level 10 as application permission representation. But, as resource “should be” associated with entitlements “not” roles, mainly all permissions should be duplicated, so we have roles  resources  entitlements associations. With 800+ applications integrated or represented in IDM, million of roles and users associates with close to 1800 level 10 roles each, adding more 1800 resources to RRSD process seen to be unnecessary work.

IDM 4.7 graphical interface brings with possibility to associate entitlements directly to roles, leaving resource to other kind of stuff, like cellular, badge, and so on. Ok, some difficulties will happen, like PCRS and IG integration will not work.

As develop a custom SoD based on resources is out of scope, what architecture is the best way to implement this?

Best wishes.
Labels (1)
0 Likes
2 Replies
ScorpionSting Absent Member.
Absent Member.

Re: Roles or resources? That's the question...

agorian;2485900 wrote:
Hi all,

Introduced in IDM 3.7, resource model fulfill some requirements that roles doesn’t, but brings no SoD, keeping roles level 10 as application permission representation. But, as resource “should be” associated with entitlements “not” roles, mainly all permissions should be duplicated, so we have roles  resources  entitlements associations. With 800+ applications integrated or represented in IDM, million of roles and users associates with close to 1800 level 10 roles each, adding more 1800 resources to RRSD process seen to be unnecessary work.

IDM 4.7 graphical interface brings with possibility to associate entitlements directly to roles, leaving resource to other kind of stuff, like cellular, badge, and so on. Ok, some difficulties will happen, like PCRS and IG integration will not work.

As develop a custom SoD based on resources is out of scope, what architecture is the best way to implement this?

Best wishes.


Probably need to go back to the basics of what the definitions of each component means.

[/HR]
Entitlement:


  1. the fact of having a right to something.
  2. the amount to which a person has a right.
  3. the belief that one is inherently deserving of privileges or special treatment.


    So an "entitlement" can be an account within an end system and/or an access level within an end system.

    [/HR]
    Resource:



    1. a stock or supply of money, materials, staff, and other assets that can be drawn on by a person or organization in order to function effectively.
    2. an action or strategy which may be adopted in adverse circumstances.


      So, a "resource" may be "HR" which requires both an account entitlement as well as one or more access level entitlements and may also contain entitlements to files systems, etc.

      [/HR]
      Role:



      1. an actor's part in a play, film, etc.
      2. the function assumed or part played by a person or thing in a particular situation.


        So, a "Role" may be "Recruiter" that requires HR resource, Onboarding resource, etc. which inherit the entitlements granted as part of that resource

        [/HR]
        Separation of duties (SoD):




        1. is the concept of having more than one person required to complete a task. In business the separation by sharing of more than one individual in one single task is an internal control intended to prevent fraud and error.


          So, as an example, a "SoD" would make sure that someone who has a role of Procurement doesn't have the role of Accounts Payable (chance of Fraud).

          [/HR]
          PCRS makes all this easier by simplifying the Resource and Entitlement configuration, especially in large complex environments, along with performance and attestation improvements.

          You should primarily consider the Identity's Role versus what SoD Policies govern your organisation as this is of importance to IG within your organisation. Trying to do this at the Resource/Entitlement level is just not feasible, technical, or practical.


          It also sounds like you have severe role explosion....a whole different topic. Probably need to look at revisiting the Roles that requires SoD as a primary starting point.

Visit my Website for links to Cool Solution articles.
agorian Respected Contributor.
Respected Contributor.

Re: Roles or resources? That's the question...

Hi,

Ok about definitions, but my point is: Entitlement “must” be associated with one resource, so this can be usable through User Application. Resource must have just one entitlement reference an roles have one or more entitlements associated.

Using your example (this is the case), an user with Procurement role should not have Accounts Payable roll but in practical way, this user should not have some resource because this grants Account Payable functionalities inside the application.

Putting it in a SAP-ECC reality (like other ERP), Standard Role XPTO123 conflicts (SoD) with Standard Role ABCD456 inside the application and if I represent it like resources, user with IDM role Procurement (XPTO123 inherited) will not conflict with resource ABCD456. But, if instead of roles and resources I can use Role 20 and Role 10 to represent it.

But, if for each role I must have one resource, some bottlenecks in RRSD will occur (yes, is occurring). If I map roles to entitlements, I loose PCRS, Identity Governance standard integration and so on.

So, I’m trying to understand the best and most original model to use in this situation.
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.