Thanks for sharing - and yes - it was expected that you would need to "polish" the code a little to adopt it to your purpose :-)
Glad to see it being used - I am pushing internally in IBM to see if this could be included in the product some time in the future (that would be a data driven approach - but the general idea is the same - and if you think it looks like Access Entitlements in other way you are right...)
Original Message:
Sent: Thu January 27, 2022 06:32 AM
From: Felipe Risalde Serrano
Subject: Getting the provisioning policy name from the context in the entitlement definition
Dear all,since this proposal was risen by Franz, I knew that someday I would use this approach which, from my point of view, provide a great flexibility working in a RBAC model. Thus, it is not needed to create and maintenance a huge number of policies, one per group, because it will be managed in one unique policy.
I would like incorporate my modesty contribution as a result of my trials when it has been tested in a production environment.
First at all, I would like to stress that if the whole of mySAPRolesJS are not being managed by this policy, be aware how the others values would be kept/removed. According to the proposed code, if an user is not granted with any managed role, a 'null' is returned, which it means that any mySAPRolesJS values are not allowed (a typical RBAC configuration is supposed: provisioning policies and services with mandatory enforcement). To avoid this behaviour a list of allowed values (Optional) should be kept, or, an easier solution, to return an allowed "dummy" value (working with AD it could be 'Domain users', or 'staff' with UNIX) to avoid 'null' will be returned. To exclude the possible values managed by the policy/code, and so, to permit the rest of them, is not an option due to the 'null' mandatory overwrites the allowed values from the Excluded.
Another question to pay attention focus is, some customizations are required if you are working with roles hierarchy to be able to analyse the parents roles of the (child) role which the user is granted.
I hope to share my experiences will be useful.
------------------------------
Felipe Risalde Serrano
Security Expert
Banco de España
Original Message:
Sent: Wed May 27, 2020 02:37 AM
From: Franz Wolfhagen
Subject: Getting the provisioning policy name from the context in the entitlement definition
Hi Felipe !
I may not have understood your usecase fully - but to me it sounds a lot like you want to simplify your role/policy management for a specific service and avoiding going the Access Entitlement route ?
If that is what you are trying to obtain I believe your pattern is not optimal for several reasons (one is of course as Grey and your self has found it veery difficult to implement).
Here is my suggestion - focus on Organizational Roles - i.e. a 1-1 relationship between a role and a group. And then have only 1 policy to manage the assignments.
The reasons for doing it this way is that :
- It is easy to build logic (SDI/LCR) that builds roles for each group in a service
- Roles are the basic externalization data you should use for external systems - "Request Catalog" data
I know this sound abstract - but time/place here is difficult to go into a deeper enterprise architectural discussion on these topics :-)
Now - there is a couple things in a design like this to consider:
- The solution must be scalable - so it may be a good idea to ensure that only relevant persons are subject to the provisioning policy. This can be ensured by having the policy that performs the calculation to be linked to a specific "gatekeeper" role - i.e. a static role for persons that can request entitlements on the service. You can do this using role hierarchies, but if KISS principle is applied this is not necessary - depend on your choice (and auto management of the role creation). Also the roles for this purpose should be "tagged" so that the policy only need to handle roles that is used for this purpose.
- You must ensure that you do not have any role name clashes - e.g. you should pre/postfix your role names. I would create a specific (invariant) attribute on the service/serviceform to hold this value - although service name may be used it has a tendency to change over time and being somewhat long....
I have done a little proof of concept here - it is for SAP NW so it includes a little extra logic to handle start/end dates. It uses a specific role classification ("sapnw7") as tag - but you can basically use any role attribute you want (on ISIM 6/7 the role schema is extensible). There is no naming pre/postfix in the code either - so that also needs to be added (this is a sample only) :
var mySAPRolesJS = new Array();var myRoles = subject.getProperty("erroles");Enrole.log("SAPNW7 Policy - Authorization Roles","SAPNW7 Policy - Authorization Roles : myRoles.length = " + myRoles.length);if (myRoles != null && myRoles.length>0) { for (i=0 ; i<myRoles.length ; i++) { //Enrole.log("SAPNW7 Policy - Authorization Roles","SAPNW7 Policy - Authorization Roles : Loop - i = " + i ); var myRole = new Role(myRoles[i]); Enrole.log("SAPNW7 Policy - Authorization Roles","SAPNW7 Policy - Authorization Roles : working with role = " + myRole.getPropertyAsString("errolename")); if (myRole.getPropertyAsString("erroleclassification").toLowerCase() == "role.classification.sapnw7" ) { Enrole.log("SAPNW7 Policy - Authorization Roles","SAPNW7 Policy - Authorization Roles : Adding role = " + myRole.getPropertyAsString("errolename")); //add the relevant role to the JS array - as this is SAP also add the start/end dates mySAPRolesJS[mySAPRolesJS.length] = myRole.getPropertyAsString("errolename") + "|19900101|99991231"; } }}if (mySAPRolesJS != null && mySAPRolesJS.length>0) { return mySAPRolesJS;} else { return null}
As a last comment - this is IMHO the way Access Entitlement/Account requests SHOULD have been implemented in ISIM (of course packed away in system policies - there would be a little more logic to it :-)) as it follows the design of ISIM.
I have only tested the above code sporadic - but I would guess it scales relatively well.
If you (or others) need more explanation on this let me know...
HTH
------------------------------
Franz Wolfhagen
IAM Technical Architect for Europe - Certified Consulting IT Specialist
IBM Security Expert Labs
Original Message:
Sent: Tue May 26, 2020 11:53 AM
From: Grey Thrasher
Subject: Getting the provisioning policy name from the context in the entitlement definition
Hi Felipe...
As you've stated above, there isn't a way to retrieve the parent policy's name from within an entitlement (at least as far as I'm aware). That said, if you already know the Group (as you'll be setting that on the Policy Name)...why not just define the Group on the entitlement directly? That would also cut down on the overhead (no need for script evaluation, etc).
------------------------------
Grey Thrasher
IBM
Original Message:
Sent: Tue May 26, 2020 06:40 AM
From: Felipe Risalde Serrano
Subject: Getting the provisioning policy name from the context in the entitlement definition
Dear colleagues,
we are integrating a new managed system in our current IAM system. We are going to define a (1) provisioning policy for each (1) managed group in the target system. Thus, the name of the group to be provisioned could be clued from the name of the provisioning policy.
I have though it could be easy to define the entitlements with an unique javascript, such as:
group=parameters.erpolicyitemname[0];
return group.substr(group.indexOf("#")+1, group.length);
Nevertheless, according to the documentation, in the ProvisioningPolicyExtension context, 'reason' and 'parameters.uid[0]' are only supported.
If so, it will be needed to extend the JavaScript interpreter to reach the goal
Please, let me know if I am wrong.
------------------------------
Felipe Risalde Serrano
Security Expert
Banco de España
------------------------------