Hi,

I am experiencing some behavior with implicit excludes in the ISIM provisioning policies that I could use some feedback on.

Just to clarify I am experiencing the same behavior on multiple services and using multiple different versions of ISIM, so I will forgo talking about versions and specific endpoints/services.

The desired behavior is to have some groups (multivalued attribute) be provisioned based on role membership and some groups be owned by the service, to be provisioned manually either in the endpoint system or through ISIM.

I can then use explicit exclude to remove the group when the role is removed, like the following support page implies: how-implicitly-exclude-values-itim-provisioning-policies

So lets look at the following scenario on one service with one provisioning policy:

Say that I have a policy, policy1 that provisions group1 as a mandatory parameter if you are a member of role1 in ISIM. I see the following behavior:

1. I add group2 and group3 manually to an account (not based on role membership).
2. I then add the person object to role1 and enforce. Adding the person to role1 provisions group1 to the account but also removes group2 and group3 in the enforcement.

I figured out that this is the default behavior in ISIM provisioning policies according to ISIM doc (7.0.1.8, but the same is stated for earlier versions in the ISIM PDF documentation). This resource states:

• If a parameter is added for a multi-valued attribute with the parameter type as Allowed (valid), all other values for this attribute are implicitly excluded for this policy.

So is there a way to override this implicit exclude to reach our desired behavior in this case? Seems like there is one, that I stumbled upon by accident.

If you add an empty "Excluded" Group parameter using JavaScript or a Null value as the parameter type, it overrides the implicit exclude.

Is this behavior intended? Is a Null Excluded group parameter in a provisioning policy meant to override the implicit exclude?

------------------------------
Jonathan Andreasson
IAM Consultant
Enfo Sweden
GOTHENBURG
------------------------------

I dont know how many groups you have to manage through RBAC policy, i am assuming they are in hundreds if not thousands. 
The behavior you mentioned, ISIM is working as per designed (as you already found out). One way to make it work is allow * , which essentially means allow any group value (to be assigned manually in ISIM or on target). But then its quite open and there is no real RBAC. If your groups are manageable and you know what set of groups can be assigned based on person's role then you can limit the allowed list to specific set based on role membership. Something like this, role1 will have groups1 mandetory and some from optional list (allowed).  Removing the role1 should remove group1 and any assigned from optional list (unless there is overlap with other policy).

------------------------------
Sanjay Sutar
------------------------------

I agree on the observed behavior is how ISIM is expected to work (note: - that does not mean that this was the original intent of the designers - some of the finer details of ISIM provisioning policy behavior comes from misunderstanding requirements and wrong implementations according to some of the real old timer ISIM people - I will not go into deeper description here :-)). Also the functionality has been problematic due to problem with the join directive/priority not working in some scenarios (e.g. not being honored in policy preview, but working fine when submitted - I believe these bugs are all fixed in the latest fixpacks).
What is trying to be obtained here is what we historically call "hybrid provisioning" - and it is a somewhat difficult discipline with the current possibilities in ISIM.
Normally I recommend either using a naming scheme (e.g. a prefix on all entitlements (groups) that are governed through RBAC) or some attribute scheme (e.g. placement in AD OU structure). Naming schemes has the great advantage that you can then easily implement them using the regex mechanism - using attributes based schemes are more complex and requires some advanced JavaScripting.
Whether you implement the RBAC controlled entitlements using whitelisting (allows) or blacklisting is as such not important (I prefer blacklisting) - the real challenge is when you start mixing (and I sense that you may be in that area) RBAC and request based...
There is an RFE (https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=137408) that is considered adding policy enforcement to the provisioning policy level which should make this much easier - alas it is a relatively big change - but you may vote for this or create your own similar RFE (I do not know if you can actually see the RFE due to security restriction...).
I have planned for many years to document some of these details - maybe there is hope - it looks like I will get a little more time working on providing help developing materials to help the field in the future - but do not hold your breath :-)

HTH

------------------------------
Franz Wolfhagen
IAM Technical Architect for Europe - Certified Consulting IT Specialist
IBM Security Expert Labs
------------------------------

Original Message:
Sent: Mon February 24, 2020 10:59 AM
From: Sanjay Sutar
Subject: ISIM Provisioning policy implicit exclude behavior

I dont know how many groups you have to manage through RBAC policy, i am assuming they are in hundreds if not thousands. 
The behavior you mentioned, ISIM is working as per designed (as you already found out). One way to make it work is allow * , which essentially means allow any group value (to be assigned manually in ISIM or on target). But then its quite open and there is no real RBAC. If your groups are manageable and you know what set of groups can be assigned based on person's role then you can limit the allowed list to specific set based on role membership. Something like this, role1 will have groups1 mandetory and some from optional list (allowed).  Removing the role1 should remove group1 and any assigned from optional list (unless there is overlap with other policy).

------------------------------
Sanjay Sutar
------------------------------

Thank you Franz and Sanjay for your detailed answers, much appreciated.

The problem with using an implicit allow like you mention Sanjay, is that an allow will always (to my understanding) have priority over an exclude property, regardless of the priority set on the policies. In our hybrid RBAC, we want behavior that removes the entitlement when the role is removed. The entitlement set is unfortunately not small/manageable enough to rely solely on RBAC.

I do like the idea, that you mention Franz, of using a prefix for all RBAC entitlements and using regex to manage the whitelisting and blacklisting. I will pursue this as a possible solution.

You are correct Franz, we are currently mixing request-based and RBAC. I can't access the RFE, I'm not authorized. Are there any other ways of accessing its content?

Does anyone know if the Null Exclude that I mention in the post is intended? The way it overrides the implicit exclude behavior in the provisioning policy. If that is indeed an intended feature, it can technically be used to allow me to manage the RBAC entitlements through explicit whitelisting and blacklisting. This would be an acceptable short-term solution, but lacking scalability.

The problem is that, if that is not intended or regarded as a bug, we may have a situation in the future where an ISIM fixpack removes the bug/feature :) and the implicit exclude kicks in for the majority of our users, causing a massive loss of entitlements when enforced.


------------------------------
Jonathan Andreasson
------------------------------

Original Message:
Sent: Tue February 25, 2020 02:18 AM
From: Franz Wolfhagen
Subject: ISIM Provisioning policy implicit exclude behavior

I agree on the observed behavior is how ISIM is expected to work (note: - that does not mean that this was the original intent of the designers - some of the finer details of ISIM provisioning policy behavior comes from misunderstanding requirements and wrong implementations according to some of the real old timer ISIM people - I will not go into deeper description here :-)). Also the functionality has been problematic due to problem with the join directive/priority not working in some scenarios (e.g. not being honored in policy preview, but working fine when submitted - I believe these bugs are all fixed in the latest fixpacks).
What is trying to be obtained here is what we historically call "hybrid provisioning" - and it is a somewhat difficult discipline with the current possibilities in ISIM.
Normally I recommend either using a naming scheme (e.g. a prefix on all entitlements (groups) that are governed through RBAC) or some attribute scheme (e.g. placement in AD OU structure). Naming schemes has the great advantage that you can then easily implement them using the regex mechanism - using attributes based schemes are more complex and requires some advanced JavaScripting.
Whether you implement the RBAC controlled entitlements using whitelisting (allows) or blacklisting is as such not important (I prefer blacklisting) - the real challenge is when you start mixing (and I sense that you may be in that area) RBAC and request based...
There is an RFE (https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=137408) that is considered adding policy enforcement to the provisioning policy level which should make this much easier - alas it is a relatively big change - but you may vote for this or create your own similar RFE (I do not know if you can actually see the RFE due to security restriction...).
I have planned for many years to document some of these details - maybe there is hope - it looks like I will get a little more time working on providing help developing materials to help the field in the future - but do not hold your breath :-)

HTH

------------------------------
Franz Wolfhagen
IAM Technical Architect for Europe - Certified Consulting IT Specialist
IBM Security Expert Labs
------------------------------


Original Message:
Sent: Mon February 24, 2020 10:59 AM
From: Sanjay Sutar
Subject: ISIM Provisioning policy implicit exclude behavior

I dont know how many groups you have to manage through RBAC policy, i am assuming they are in hundreds if not thousands. 
The behavior you mentioned, ISIM is working as per designed (as you already found out). One way to make it work is allow * , which essentially means allow any group value (to be assigned manually in ISIM or on target). But then its quite open and there is no real RBAC. If your groups are manageable and you know what set of groups can be assigned based on person's role then you can limit the allowed list to specific set based on role membership. Something like this, role1 will have groups1 mandetory and some from optional list (allowed).  Removing the role1 should remove group1 and any assigned from optional list (unless there is overlap with other policy).

------------------------------
Sanjay Sutar

I would not be too concerned about bugs - this area is used intensively in many complex ISIM deployments - and the professional community has for the same reason been very aggressive on routing out bugs in the core flow - it does not mean that there are still corner situations that needs fixing - but they are mostly to find in the UI - not in the execution parts.
There is one golden rule in this game - and that is testing - and I can almost guess that is why we are having this discussion...
I need to understand one thing - if you create a policy parameter exclude/null (and I assume as mandatory) - why would you do that ? Is it correct that is more a special case of the exclude/javascript returning an empty list ?
In my understanding the entitlements will be joined using "join" join directive - i.e. a set of policies that applies for a user (via roles) will join the exclude lists - if null is part of it all entitlements SHOULD be allowed - the latter is only my understanding - but you may want have this confirmed by raising a case to IBM Support...

The RFE description (there are some gory details not needed right now) is the following :

1.1 Adding Policy Enforcement to Provisioning Policies
Building a "hybrid" provisioning model in ISIM (a model where a set of groups are managed "hard" (subject to mandatory policies) under an RBAC implementation and the rest is subject to a request based process (e.g. anybody can request these with optional approval process – eventual as Access Entitlements) is very complex.

Normally this is either done using a naming scheme (e.g. groups are handled as managed if having a predefined prefix utilizing regex logic in the provisioning policies) or through some attribute (e.g. AD groups that a placed in specific OUs) by some complex scripted provisioning policy.

By adding a policy enforcement to a provisioning policy this will enable the hybrid model by having some policies as "Mark Compliance" and other as "Correct Compliance".  In case of conflicts (same attribute subject to both "mark" and "correct") the provisioning policy priority should be used (as for "priority" join directives.

1.1.1 Usecase

Some Windows AD groups must be follow strict rules and only users having roles that allows these groups must have these groups. These groups must also be provisioning automatically when the user becomes member of a role specifying the group (mandatory provisioning parameter)

Groups outside this set can be allowed – but should be marked as non-compliant unless specifically having an allowed policy or approved request.

1.1.2 Business Justification

Building a hybrid provisioning model is very important to limit governance only to a relevant set of entitlements (groups). A hybrid model also can drastically reduce onboarding of new systems to ISIM and also enable automation of provisioning of a limited set of entitlements for a service hence gradually build up the governance level group by group.  

It is actively being considered for inclusion - but some push from the community would help - real clients for some reason has a larger saying than an IBM techie...

If you have the possibility to join the Nordic UG meeting in Stockholm March 26  you have the chance to discuss this with the Offering Manager (and me if I will be allowed to travel) :-)

HTH

------------------------------
Franz Wolfhagen
IAM Technical Architect for Europe - Certified Consulting IT Specialist
IBM Security Expert Labs
------------------------------

Original Message:
Sent: Tue February 25, 2020 05:12 AM
From: Jonathan Andreasson
Subject: ISIM Provisioning policy implicit exclude behavior

Thank you Franz and Sanjay for your detailed answers, much appreciated.

The problem with using an implicit allow like you mention Sanjay, is that an allow will always (to my understanding) have priority over an exclude property, regardless of the priority set on the policies. In our hybrid RBAC, we want behavior that removes the entitlement when the role is removed. The entitlement set is unfortunately not small/manageable enough to rely solely on RBAC.

I do like the idea, that you mention Franz, of using a prefix for all RBAC entitlements and using regex to manage the whitelisting and blacklisting. I will pursue this as a possible solution.

You are correct Franz, we are currently mixing request-based and RBAC. I can't access the RFE, I'm not authorized. Are there any other ways of accessing its content?

Does anyone know if the Null Exclude that I mention in the post is intended? The way it overrides the implicit exclude behavior in the provisioning policy. If that is indeed an intended feature, it can technically be used to allow me to manage the RBAC entitlements through explicit whitelisting and blacklisting. This would be an acceptable short-term solution, but lacking scalability.

The problem is that, if that is not intended or regarded as a bug, we may have a situation in the future where an ISIM fixpack removes the bug/feature :) and the implicit exclude kicks in for the majority of our users, causing a massive loss of entitlements when enforced.


------------------------------
Jonathan Andreasson
------------------------------


Original Message:
Sent: Tue February 25, 2020 02:18 AM
From: Franz Wolfhagen
Subject: ISIM Provisioning policy implicit exclude behavior

I agree on the observed behavior is how ISIM is expected to work (note: - that does not mean that this was the original intent of the designers - some of the finer details of ISIM provisioning policy behavior comes from misunderstanding requirements and wrong implementations according to some of the real old timer ISIM people - I will not go into deeper description here :-)). Also the functionality has been problematic due to problem with the join directive/priority not working in some scenarios (e.g. not being honored in policy preview, but working fine when submitted - I believe these bugs are all fixed in the latest fixpacks).
What is trying to be obtained here is what we historically call "hybrid provisioning" - and it is a somewhat difficult discipline with the current possibilities in ISIM.
Normally I recommend either using a naming scheme (e.g. a prefix on all entitlements (groups) that are governed through RBAC) or some attribute scheme (e.g. placement in AD OU structure). Naming schemes has the great advantage that you can then easily implement them using the regex mechanism - using attributes based schemes are more complex and requires some advanced JavaScripting.
Whether you implement the RBAC controlled entitlements using whitelisting (allows) or blacklisting is as such not important (I prefer blacklisting) - the real challenge is when you start mixing (and I sense that you may be in that area) RBAC and request based...
There is an RFE (https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=137408) that is considered adding policy enforcement to the provisioning policy level which should make this much easier - alas it is a relatively big change - but you may vote for this or create your own similar RFE (I do not know if you can actually see the RFE due to security restriction...).
I have planned for many years to document some of these details - maybe there is hope - it looks like I will get a little more time working on providing help developing materials to help the field in the future - but do not hold your breath :-)

HTH

------------------------------
Franz Wolfhagen
IAM Technical Architect for Europe - Certified Consulting IT Specialist
IBM Security Expert Labs


Original Message:
Sent: Mon February 24, 2020 10:59 AM
From: Sanjay Sutar
Subject: ISIM Provisioning policy implicit exclude behavior

I dont know how many groups you have to manage through RBAC policy, i am assuming they are in hundreds if not thousands. 
The behavior you mentioned, ISIM is working as per designed (as you already found out). One way to make it work is allow * , which essentially means allow any group value (to be assigned manually in ISIM or on target). But then its quite open and there is no real RBAC. If your groups are manageable and you know what set of groups can be assigned based on person's role then you can limit the allowed list to specific set based on role membership. Something like this, role1 will have groups1 mandetory and some from optional list (allowed).  Removing the role1 should remove group1 and any assigned from optional list (unless there is overlap with other policy).

------------------------------
Sanjay Sutar

As you guessed, the thing that spawned the "null" exclude was a special case where a parameter returns an empty/null value if a condition is not fulfilled.

The initial requirement was stated something like this: when the account is suspended, the non-RBAC group group1 should be removed from the account. This resulted in a simply JavaScript entitlement parameter that looked something like:

Name: Group
Template value: if (inactive) return group1 else return null
Enforcement: Exclude
Value Type: JavaScript

With further testing, we realized that if we remove this entitlement parameter a large portion of the active accounts in the service loses all their non-RBAC entitlements - this is because the implicit exclude is then automatically activated.

"In my understanding the entitlements will be joined using "join" join directive - i.e. a set of policies that applies for a user (via roles) will join the exclude lists - if null is part of it all entitlements SHOULD be allowed". This was my first assumption, but it does not correlate with the observed behavior.  We have run this by the IBM support in a PMR, but the question seems to be specific to a point where a straight answer is not readily available.

I am trying to understand how the RFE would alleviate the difficulty of a hybrid RBAC. Wouldn't we still have a situation where the RBAC assignment policy for a user would disallow all non-RBAC entitlements if not specifically filtered using name standard or attribute? Or is the idea to split the account base into RBAC based accounts and non-RBAC accounts?

I will have a look at attending the user group :). Topics look interesting.

------------------------------
Jonathan Andreasson
------------------------------

Original Message:
Sent: Tue February 25, 2020 06:27 AM
From: Franz Wolfhagen
Subject: ISIM Provisioning policy implicit exclude behavior

I would not be too concerned about bugs - this area is used intensively in many complex ISIM deployments - and the professional community has for the same reason been very aggressive on routing out bugs in the core flow - it does not mean that there are still corner situations that needs fixing - but they are mostly to find in the UI - not in the execution parts.
There is one golden rule in this game - and that is testing - and I can almost guess that is why we are having this discussion...
I need to understand one thing - if you create a policy parameter exclude/null (and I assume as mandatory) - why would you do that ? Is it correct that is more a special case of the exclude/javascript returning an empty list ?
In my understanding the entitlements will be joined using "join" join directive - i.e. a set of policies that applies for a user (via roles) will join the exclude lists - if null is part of it all entitlements SHOULD be allowed - the latter is only my understanding - but you may want have this confirmed by raising a case to IBM Support...

The RFE description (there are some gory details not needed right now) is the following :

1.1 Adding Policy Enforcement to Provisioning Policies
Building a "hybrid" provisioning model in ISIM (a model where a set of groups are managed "hard" (subject to mandatory policies) under an RBAC implementation and the rest is subject to a request based process (e.g. anybody can request these with optional approval process – eventual as Access Entitlements) is very complex.

Normally this is either done using a naming scheme (e.g. groups are handled as managed if having a predefined prefix utilizing regex logic in the provisioning policies) or through some attribute (e.g. AD groups that a placed in specific OUs) by some complex scripted provisioning policy.

By adding a policy enforcement to a provisioning policy this will enable the hybrid model by having some policies as "Mark Compliance" and other as "Correct Compliance".  In case of conflicts (same attribute subject to both "mark" and "correct") the provisioning policy priority should be used (as for "priority" join directives.

1.1.1 Usecase

Some Windows AD groups must be follow strict rules and only users having roles that allows these groups must have these groups. These groups must also be provisioning automatically when the user becomes member of a role specifying the group (mandatory provisioning parameter)

Groups outside this set can be allowed – but should be marked as non-compliant unless specifically having an allowed policy or approved request.

1.1.2 Business Justification

Building a hybrid provisioning model is very important to limit governance only to a relevant set of entitlements (groups). A hybrid model also can drastically reduce onboarding of new systems to ISIM and also enable automation of provisioning of a limited set of entitlements for a service hence gradually build up the governance level group by group.  

It is actively being considered for inclusion - but some push from the community would help - real clients for some reason has a larger saying than an IBM techie...

If you have the possibility to join the Nordic UG meeting in Stockholm March 26

https://www.ibm.com/events/wwe/grp/grp308.nsf/Registration.xsp?openform&seminar=D29J88ES&locale=en_ZZ

 you have the chance to discuss this with the Offering Manager (and me if I will be allowed to travel) :-)

HTH

------------------------------
Franz Wolfhagen
IAM Technical Architect for Europe - Certified Consulting IT Specialist
IBM Security Expert Labs
------------------------------


Original Message:
Sent: Tue February 25, 2020 05:12 AM
From: Jonathan Andreasson
Subject: ISIM Provisioning policy implicit exclude behavior

Thank you Franz and Sanjay for your detailed answers, much appreciated.

The problem with using an implicit allow like you mention Sanjay, is that an allow will always (to my understanding) have priority over an exclude property, regardless of the priority set on the policies. In our hybrid RBAC, we want behavior that removes the entitlement when the role is removed. The entitlement set is unfortunately not small/manageable enough to rely solely on RBAC.

I do like the idea, that you mention Franz, of using a prefix for all RBAC entitlements and using regex to manage the whitelisting and blacklisting. I will pursue this as a possible solution.

You are correct Franz, we are currently mixing request-based and RBAC. I can't access the RFE, I'm not authorized. Are there any other ways of accessing its content?

Does anyone know if the Null Exclude that I mention in the post is intended? The way it overrides the implicit exclude behavior in the provisioning policy. If that is indeed an intended feature, it can technically be used to allow me to manage the RBAC entitlements through explicit whitelisting and blacklisting. This would be an acceptable short-term solution, but lacking scalability.

The problem is that, if that is not intended or regarded as a bug, we may have a situation in the future where an ISIM fixpack removes the bug/feature :) and the implicit exclude kicks in for the majority of our users, causing a massive loss of entitlements when enforced.


------------------------------
Jonathan Andreasson


Original Message:
Sent: Tue February 25, 2020 02:18 AM
From: Franz Wolfhagen
Subject: ISIM Provisioning policy implicit exclude behavior

I agree on the observed behavior is how ISIM is expected to work (note: - that does not mean that this was the original intent of the designers - some of the finer details of ISIM provisioning policy behavior comes from misunderstanding requirements and wrong implementations according to some of the real old timer ISIM people - I will not go into deeper description here :-)). Also the functionality has been problematic due to problem with the join directive/priority not working in some scenarios (e.g. not being honored in policy preview, but working fine when submitted - I believe these bugs are all fixed in the latest fixpacks).
What is trying to be obtained here is what we historically call "hybrid provisioning" - and it is a somewhat difficult discipline with the current possibilities in ISIM.
Normally I recommend either using a naming scheme (e.g. a prefix on all entitlements (groups) that are governed through RBAC) or some attribute scheme (e.g. placement in AD OU structure). Naming schemes has the great advantage that you can then easily implement them using the regex mechanism - using attributes based schemes are more complex and requires some advanced JavaScripting.
Whether you implement the RBAC controlled entitlements using whitelisting (allows) or blacklisting is as such not important (I prefer blacklisting) - the real challenge is when you start mixing (and I sense that you may be in that area) RBAC and request based...
There is an RFE (https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=137408) that is considered adding policy enforcement to the provisioning policy level which should make this much easier - alas it is a relatively big change - but you may vote for this or create your own similar RFE (I do not know if you can actually see the RFE due to security restriction...).
I have planned for many years to document some of these details - maybe there is hope - it looks like I will get a little more time working on providing help developing materials to help the field in the future - but do not hold your breath :-)

HTH

------------------------------
Franz Wolfhagen
IAM Technical Architect for Europe - Certified Consulting IT Specialist
IBM Security Expert Labs


Original Message:
Sent: Mon February 24, 2020 10:59 AM
From: Sanjay Sutar
Subject: ISIM Provisioning policy implicit exclude behavior

I dont know how many groups you have to manage through RBAC policy, i am assuming they are in hundreds if not thousands. 
The behavior you mentioned, ISIM is working as per designed (as you already found out). One way to make it work is allow * , which essentially means allow any group value (to be assigned manually in ISIM or on target). But then its quite open and there is no real RBAC. If your groups are manageable and you know what set of groups can be assigned based on person's role then you can limit the allowed list to specific set based on role membership. Something like this, role1 will have groups1 mandetory and some from optional list (allowed).  Removing the role1 should remove group1 and any assigned from optional list (unless there is overlap with other policy).

------------------------------
Sanjay Sutar

Hello Jonathan,

from the Knowledgecenter I want to cite the following points, which should clarify your observed behaviour:
1.) Having only mandatory: "Mandatory attributes are set to the defined value, and all other values are not valid.". 
This explains your "implicit exclude".

2.) Having mandatory in combination with exclude: "Mandatory attributes are set to defined values. Excluded attribute values are removed (all other values can be present or set on the attribute)."
In this combination, it's not relevant if you exclude "null", an empty string, a regex, or whatever. The excluded values are no longer allowed and will be removed from the account. 

Having that said, I want to add a more general comment: If you use the hybrid approach with RBAC on some groups (and excludes on them), and non-RBAC on others, I assume that the groups will change over time (new groups, groups start to get managed via RBAC). In this case, it's important that your excludes always are up to date and exactly cover the groups which are RBAC managed. Try to find a design where this is guaranteed by design to avoid mistakes. Franz already mentioned two typical aproaches: Naming schema and some target-system-specific properties. 

HTH




------------------------------
Tobias Ernstberger
------------------------------

Original Message:
Sent: Tue February 25, 2020 05:12 AM
From: Jonathan Andreasson
Subject: ISIM Provisioning policy implicit exclude behavior

Thank you Franz and Sanjay for your detailed answers, much appreciated.

The problem with using an implicit allow like you mention Sanjay, is that an allow will always (to my understanding) have priority over an exclude property, regardless of the priority set on the policies. In our hybrid RBAC, we want behavior that removes the entitlement when the role is removed. The entitlement set is unfortunately not small/manageable enough to rely solely on RBAC.

I do like the idea, that you mention Franz, of using a prefix for all RBAC entitlements and using regex to manage the whitelisting and blacklisting. I will pursue this as a possible solution.

You are correct Franz, we are currently mixing request-based and RBAC. I can't access the RFE, I'm not authorized. Are there any other ways of accessing its content?

Does anyone know if the Null Exclude that I mention in the post is intended? The way it overrides the implicit exclude behavior in the provisioning policy. If that is indeed an intended feature, it can technically be used to allow me to manage the RBAC entitlements through explicit whitelisting and blacklisting. This would be an acceptable short-term solution, but lacking scalability.

The problem is that, if that is not intended or regarded as a bug, we may have a situation in the future where an ISIM fixpack removes the bug/feature :) and the implicit exclude kicks in for the majority of our users, causing a massive loss of entitlements when enforced.


------------------------------
Jonathan Andreasson
------------------------------


Original Message:
Sent: Tue February 25, 2020 02:18 AM
From: Franz Wolfhagen
Subject: ISIM Provisioning policy implicit exclude behavior

I agree on the observed behavior is how ISIM is expected to work (note: - that does not mean that this was the original intent of the designers - some of the finer details of ISIM provisioning policy behavior comes from misunderstanding requirements and wrong implementations according to some of the real old timer ISIM people - I will not go into deeper description here :-)). Also the functionality has been problematic due to problem with the join directive/priority not working in some scenarios (e.g. not being honored in policy preview, but working fine when submitted - I believe these bugs are all fixed in the latest fixpacks).
What is trying to be obtained here is what we historically call "hybrid provisioning" - and it is a somewhat difficult discipline with the current possibilities in ISIM.
Normally I recommend either using a naming scheme (e.g. a prefix on all entitlements (groups) that are governed through RBAC) or some attribute scheme (e.g. placement in AD OU structure). Naming schemes has the great advantage that you can then easily implement them using the regex mechanism - using attributes based schemes are more complex and requires some advanced JavaScripting.
Whether you implement the RBAC controlled entitlements using whitelisting (allows) or blacklisting is as such not important (I prefer blacklisting) - the real challenge is when you start mixing (and I sense that you may be in that area) RBAC and request based...
There is an RFE (https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=137408) that is considered adding policy enforcement to the provisioning policy level which should make this much easier - alas it is a relatively big change - but you may vote for this or create your own similar RFE (I do not know if you can actually see the RFE due to security restriction...).
I have planned for many years to document some of these details - maybe there is hope - it looks like I will get a little more time working on providing help developing materials to help the field in the future - but do not hold your breath :-)

HTH

------------------------------
Franz Wolfhagen
IAM Technical Architect for Europe - Certified Consulting IT Specialist
IBM Security Expert Labs


Original Message:
Sent: Mon February 24, 2020 10:59 AM
From: Sanjay Sutar
Subject: ISIM Provisioning policy implicit exclude behavior

I dont know how many groups you have to manage through RBAC policy, i am assuming they are in hundreds if not thousands. 
The behavior you mentioned, ISIM is working as per designed (as you already found out). One way to make it work is allow * , which essentially means allow any group value (to be assigned manually in ISIM or on target). But then its quite open and there is no real RBAC. If your groups are manageable and you know what set of groups can be assigned based on person's role then you can limit the allowed list to specific set based on role membership. Something like this, role1 will have groups1 mandetory and some from optional list (allowed).  Removing the role1 should remove group1 and any assigned from optional list (unless there is overlap with other policy).

------------------------------
Sanjay Sutar

Hi Tobias, thank you for taking the time to help out.

I agree and intend to follow up and implement a feature to assure that the exclude list is kept up-to-date automatically. Otherwise, the solution simply would not be scalable. 

As for the second point you mention, this is where my problem lies. My policy uses mandatory, default and exclude parameters for the group attribute. If I do not have a "null" exclude or one with a similar effect the implicit exclude takes precedence. In other words, if I use a constant value exclude for a specific group instead of my "null" exclude, the implicit exclude is seen in the preview.

------------------------------
Jonathan Andreasson
------------------------------

Original Message:
Sent: Tue February 25, 2020 05:37 AM
From: Tobias Ernstberger
Subject: ISIM Provisioning policy implicit exclude behavior

Hello Jonathan,

from the Knowledgecenter I want to cite the following points, which should clarify your observed behaviour:
1.) Having only mandatory: "Mandatory attributes are set to the defined value, and all other values are not valid.". 
This explains your "implicit exclude".

2.) Having mandatory in combination with exclude: "Mandatory attributes are set to defined values. Excluded attribute values are removed (all other values can be present or set on the attribute)."
In this combination, it's not relevant if you exclude "null", an empty string, a regex, or whatever. The excluded values are no longer allowed and will be removed from the account. 

Having that said, I want to add a more general comment: If you use the hybrid approach with RBAC on some groups (and excludes on them), and non-RBAC on others, I assume that the groups will change over time (new groups, groups start to get managed via RBAC). In this case, it's important that your excludes always are up to date and exactly cover the groups which are RBAC managed. Try to find a design where this is guaranteed by design to avoid mistakes. Franz already mentioned two typical aproaches: Naming schema and some target-system-specific properties. 

HTH




------------------------------
Tobias Ernstberger
------------------------------


Original Message:
Sent: Tue February 25, 2020 05:12 AM
From: Jonathan Andreasson
Subject: ISIM Provisioning policy implicit exclude behavior

Thank you Franz and Sanjay for your detailed answers, much appreciated.

The problem with using an implicit allow like you mention Sanjay, is that an allow will always (to my understanding) have priority over an exclude property, regardless of the priority set on the policies. In our hybrid RBAC, we want behavior that removes the entitlement when the role is removed. The entitlement set is unfortunately not small/manageable enough to rely solely on RBAC.

I do like the idea, that you mention Franz, of using a prefix for all RBAC entitlements and using regex to manage the whitelisting and blacklisting. I will pursue this as a possible solution.

You are correct Franz, we are currently mixing request-based and RBAC. I can't access the RFE, I'm not authorized. Are there any other ways of accessing its content?

Does anyone know if the Null Exclude that I mention in the post is intended? The way it overrides the implicit exclude behavior in the provisioning policy. If that is indeed an intended feature, it can technically be used to allow me to manage the RBAC entitlements through explicit whitelisting and blacklisting. This would be an acceptable short-term solution, but lacking scalability.

The problem is that, if that is not intended or regarded as a bug, we may have a situation in the future where an ISIM fixpack removes the bug/feature :) and the implicit exclude kicks in for the majority of our users, causing a massive loss of entitlements when enforced.


------------------------------
Jonathan Andreasson


Original Message:
Sent: Tue February 25, 2020 02:18 AM
From: Franz Wolfhagen
Subject: ISIM Provisioning policy implicit exclude behavior

I agree on the observed behavior is how ISIM is expected to work (note: - that does not mean that this was the original intent of the designers - some of the finer details of ISIM provisioning policy behavior comes from misunderstanding requirements and wrong implementations according to some of the real old timer ISIM people - I will not go into deeper description here :-)). Also the functionality has been problematic due to problem with the join directive/priority not working in some scenarios (e.g. not being honored in policy preview, but working fine when submitted - I believe these bugs are all fixed in the latest fixpacks).
What is trying to be obtained here is what we historically call "hybrid provisioning" - and it is a somewhat difficult discipline with the current possibilities in ISIM.
Normally I recommend either using a naming scheme (e.g. a prefix on all entitlements (groups) that are governed through RBAC) or some attribute scheme (e.g. placement in AD OU structure). Naming schemes has the great advantage that you can then easily implement them using the regex mechanism - using attributes based schemes are more complex and requires some advanced JavaScripting.
Whether you implement the RBAC controlled entitlements using whitelisting (allows) or blacklisting is as such not important (I prefer blacklisting) - the real challenge is when you start mixing (and I sense that you may be in that area) RBAC and request based...
There is an RFE (https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=137408) that is considered adding policy enforcement to the provisioning policy level which should make this much easier - alas it is a relatively big change - but you may vote for this or create your own similar RFE (I do not know if you can actually see the RFE due to security restriction...).
I have planned for many years to document some of these details - maybe there is hope - it looks like I will get a little more time working on providing help developing materials to help the field in the future - but do not hold your breath :-)

HTH

------------------------------
Franz Wolfhagen
IAM Technical Architect for Europe - Certified Consulting IT Specialist
IBM Security Expert Labs


Original Message:
Sent: Mon February 24, 2020 10:59 AM
From: Sanjay Sutar
Subject: ISIM Provisioning policy implicit exclude behavior

I dont know how many groups you have to manage through RBAC policy, i am assuming they are in hundreds if not thousands. 
The behavior you mentioned, ISIM is working as per designed (as you already found out). One way to make it work is allow * , which essentially means allow any group value (to be assigned manually in ISIM or on target). But then its quite open and there is no real RBAC. If your groups are manageable and you know what set of groups can be assigned based on person's role then you can limit the allowed list to specific set based on role membership. Something like this, role1 will have groups1 mandetory and some from optional list (allowed).  Removing the role1 should remove group1 and any assigned from optional list (unless there is overlap with other policy).

------------------------------
Sanjay Sutar

Hi,

Ok, so I think I figured out how the null value is impacting the provisioning policy join behavior and why. I will explain it below for documentation purposes.

Account validation logic - in this resource the null value is explained in more detail for the union policy join.

At the end of the day, we had two separate policy parameters that would return null values in some cases.

Parameter 1:
Name: Group
Template value: if x then return group1 else return null
Enforcement: Mandatory
Value Type: JavaScript
Priority: 10 100

According to the "Account validation logic" this will result in the following: A null mandatory parameter value means that all values on the corresponding attribute of a new or existing account are disallowed except those values that any other valid values permit. When any attribute values on an existing account are denied by a null mandatory parameter, such values are automatically removed.

Parameter 2:
Name: Group
Template value: if y then return group2 else return null
Enforcement: Excluded
Value Type: JavaScript
Priority: 10 000

According to the "Account validation logic" this will result in the following: A null excluded parameter means that all attribute values are allowed on the corresponding attribute of a new or existing account except those values denied by any other denying parameter value.

We were unknowingly using the mandatory null in different policies with lower priority, which forced an implicit deny on the group attribute. This effect was in turn counteracted by a separate misconfigured policy that was returning exclude null with a higher priority. This second parameter forced the default behavior back to an allow implicit + deny explicit structure.

If both these parameters are reconfigured to not return null in the else scenario we will restore the default behavior. From there we will use a naming standard to improve the exclude structure.

Thank you all for your input and help.

------------------------------
Jonathan Andreasson
------------------------------

Original Message:
Sent: Tue February 25, 2020 10:06 AM
From: Jonathan Andreasson
Subject: ISIM Provisioning policy implicit exclude behavior

Hi Tobias, thank you for taking the time to help out.

I agree and intend to follow up and implement a feature to assure that the exclude list is kept up-to-date automatically. Otherwise, the solution simply would not be scalable. 

As for the second point you mention, this is where my problem lies. My policy uses mandatory, default and exclude parameters for the group attribute. If I do not have a "null" exclude or one with a similar effect the implicit exclude takes precedence. In other words, if I use a constant value exclude for a specific group instead of my "null" exclude, the implicit exclude is seen in the preview.

------------------------------
Jonathan Andreasson
------------------------------


Original Message:
Sent: Tue February 25, 2020 05:37 AM
From: Tobias Ernstberger
Subject: ISIM Provisioning policy implicit exclude behavior

Hello Jonathan,

from the Knowledgecenter I want to cite the following points, which should clarify your observed behaviour:
1.) Having only mandatory: "Mandatory attributes are set to the defined value, and all other values are not valid.". 
This explains your "implicit exclude".

2.) Having mandatory in combination with exclude: "Mandatory attributes are set to defined values. Excluded attribute values are removed (all other values can be present or set on the attribute)."
In this combination, it's not relevant if you exclude "null", an empty string, a regex, or whatever. The excluded values are no longer allowed and will be removed from the account. 

Having that said, I want to add a more general comment: If you use the hybrid approach with RBAC on some groups (and excludes on them), and non-RBAC on others, I assume that the groups will change over time (new groups, groups start to get managed via RBAC). In this case, it's important that your excludes always are up to date and exactly cover the groups which are RBAC managed. Try to find a design where this is guaranteed by design to avoid mistakes. Franz already mentioned two typical aproaches: Naming schema and some target-system-specific properties. 

HTH




------------------------------
Tobias Ernstberger


Original Message:
Sent: Tue February 25, 2020 05:12 AM
From: Jonathan Andreasson
Subject: ISIM Provisioning policy implicit exclude behavior

Thank you Franz and Sanjay for your detailed answers, much appreciated.

The problem with using an implicit allow like you mention Sanjay, is that an allow will always (to my understanding) have priority over an exclude property, regardless of the priority set on the policies. In our hybrid RBAC, we want behavior that removes the entitlement when the role is removed. The entitlement set is unfortunately not small/manageable enough to rely solely on RBAC.

I do like the idea, that you mention Franz, of using a prefix for all RBAC entitlements and using regex to manage the whitelisting and blacklisting. I will pursue this as a possible solution.

You are correct Franz, we are currently mixing request-based and RBAC. I can't access the RFE, I'm not authorized. Are there any other ways of accessing its content?

Does anyone know if the Null Exclude that I mention in the post is intended? The way it overrides the implicit exclude behavior in the provisioning policy. If that is indeed an intended feature, it can technically be used to allow me to manage the RBAC entitlements through explicit whitelisting and blacklisting. This would be an acceptable short-term solution, but lacking scalability.

The problem is that, if that is not intended or regarded as a bug, we may have a situation in the future where an ISIM fixpack removes the bug/feature :) and the implicit exclude kicks in for the majority of our users, causing a massive loss of entitlements when enforced.


------------------------------
Jonathan Andreasson


Original Message:
Sent: Tue February 25, 2020 02:18 AM
From: Franz Wolfhagen
Subject: ISIM Provisioning policy implicit exclude behavior

I agree on the observed behavior is how ISIM is expected to work (note: - that does not mean that this was the original intent of the designers - some of the finer details of ISIM provisioning policy behavior comes from misunderstanding requirements and wrong implementations according to some of the real old timer ISIM people - I will not go into deeper description here :-)). Also the functionality has been problematic due to problem with the join directive/priority not working in some scenarios (e.g. not being honored in policy preview, but working fine when submitted - I believe these bugs are all fixed in the latest fixpacks).
What is trying to be obtained here is what we historically call "hybrid provisioning" - and it is a somewhat difficult discipline with the current possibilities in ISIM.
Normally I recommend either using a naming scheme (e.g. a prefix on all entitlements (groups) that are governed through RBAC) or some attribute scheme (e.g. placement in AD OU structure). Naming schemes has the great advantage that you can then easily implement them using the regex mechanism - using attributes based schemes are more complex and requires some advanced JavaScripting.
Whether you implement the RBAC controlled entitlements using whitelisting (allows) or blacklisting is as such not important (I prefer blacklisting) - the real challenge is when you start mixing (and I sense that you may be in that area) RBAC and request based...
There is an RFE (https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=137408) that is considered adding policy enforcement to the provisioning policy level which should make this much easier - alas it is a relatively big change - but you may vote for this or create your own similar RFE (I do not know if you can actually see the RFE due to security restriction...).
I have planned for many years to document some of these details - maybe there is hope - it looks like I will get a little more time working on providing help developing materials to help the field in the future - but do not hold your breath :-)

HTH

------------------------------
Franz Wolfhagen
IAM Technical Architect for Europe - Certified Consulting IT Specialist
IBM Security Expert Labs


Original Message:
Sent: Mon February 24, 2020 10:59 AM
From: Sanjay Sutar
Subject: ISIM Provisioning policy implicit exclude behavior

I dont know how many groups you have to manage through RBAC policy, i am assuming they are in hundreds if not thousands. 
The behavior you mentioned, ISIM is working as per designed (as you already found out). One way to make it work is allow * , which essentially means allow any group value (to be assigned manually in ISIM or on target). But then its quite open and there is no real RBAC. If your groups are manageable and you know what set of groups can be assigned based on person's role then you can limit the allowed list to specific set based on role membership. Something like this, role1 will have groups1 mandetory and some from optional list (allowed).  Removing the role1 should remove group1 and any assigned from optional list (unless there is overlap with other policy).

------------------------------
Sanjay Sutar

Thanks for confirming (and taking the time to deep dive) - I believe that this is the expected outcome.

One thing that alarms a little bit is that you talk about priority for attributes (groups) that are governed by a join directive of "Union". Priority has no impact in this case - it only has impact for attributes that has a "Priority" join directive (it may impact Compliance Alert Rules - but I thing Alert rules are broken by design and I have never seen them in real life).

Another thing to be aware of is that you have conflicting policies with the same priority ISIM just picks one - not rules about which (I think it takes the first returned from the ldap/cache - but that is only of intellectual interest for ISIM nerds).

HTH

------------------------------
Franz Wolfhagen
IAM Technical Architect for Europe - Certified Consulting IT Specialist
IBM Security Expert Labs
------------------------------

Original Message:
Sent: Wed February 26, 2020 07:55 AM
From: Jonathan Andreasson
Subject: ISIM Provisioning policy implicit exclude behavior

Hi,

Ok, so I think I figured out how the null value is impacting the provisioning policy join behavior and why. I will explain it below for documentation purposes.

Account validation logic - in this resource the null value is explained in more detail for the union policy join.

At the end of the day, we had two separate policy parameters that would return null values in some cases.

Parameter 1:
Name: Group
Template value: if x then return group1 else return null
Enforcement: Mandatory
Value Type: JavaScript
Priority: 10 100

According to the "Account validation logic" this will result in the following: A null mandatory parameter value means that all values on the corresponding attribute of a new or existing account are disallowed except those values that any other valid values permit. When any attribute values on an existing account are denied by a null mandatory parameter, such values are automatically removed.

Parameter 2:
Name: Group
Template value: if y then return group2 else return null
Enforcement: Excluded
Value Type: JavaScript
Priority: 10 000

According to the "Account validation logic" this will result in the following: A null excluded parameter means that all attribute values are allowed on the corresponding attribute of a new or existing account except those values denied by any other denying parameter value.

We were unknowingly using the mandatory null in different policies with lower priority, which forced an implicit deny on the group attribute. This effect was in turn counteracted by a separate misconfigured policy that was returning exclude null with a higher priority. This second parameter forced the default behavior back to an allow implicit + deny explicit structure.

If both these parameters are reconfigured to not return null in the else scenario we will restore the default behavior. From there we will use a naming standard to improve the exclude structure.

Thank you all for your input and help.

------------------------------
Jonathan Andreasson
------------------------------


Original Message:
Sent: Tue February 25, 2020 10:06 AM
From: Jonathan Andreasson
Subject: ISIM Provisioning policy implicit exclude behavior

Hi Tobias, thank you for taking the time to help out.

I agree and intend to follow up and implement a feature to assure that the exclude list is kept up-to-date automatically. Otherwise, the solution simply would not be scalable. 

As for the second point you mention, this is where my problem lies. My policy uses mandatory, default and exclude parameters for the group attribute. If I do not have a "null" exclude or one with a similar effect the implicit exclude takes precedence. In other words, if I use a constant value exclude for a specific group instead of my "null" exclude, the implicit exclude is seen in the preview.

------------------------------
Jonathan Andreasson


Original Message:
Sent: Tue February 25, 2020 05:37 AM
From: Tobias Ernstberger
Subject: ISIM Provisioning policy implicit exclude behavior

Hello Jonathan,

from the Knowledgecenter I want to cite the following points, which should clarify your observed behaviour:
1.) Having only mandatory: "Mandatory attributes are set to the defined value, and all other values are not valid.". 
This explains your "implicit exclude".

2.) Having mandatory in combination with exclude: "Mandatory attributes are set to defined values. Excluded attribute values are removed (all other values can be present or set on the attribute)."
In this combination, it's not relevant if you exclude "null", an empty string, a regex, or whatever. The excluded values are no longer allowed and will be removed from the account. 

Having that said, I want to add a more general comment: If you use the hybrid approach with RBAC on some groups (and excludes on them), and non-RBAC on others, I assume that the groups will change over time (new groups, groups start to get managed via RBAC). In this case, it's important that your excludes always are up to date and exactly cover the groups which are RBAC managed. Try to find a design where this is guaranteed by design to avoid mistakes. Franz already mentioned two typical aproaches: Naming schema and some target-system-specific properties. 

HTH




------------------------------
Tobias Ernstberger


Original Message:
Sent: Tue February 25, 2020 05:12 AM
From: Jonathan Andreasson
Subject: ISIM Provisioning policy implicit exclude behavior

Thank you Franz and Sanjay for your detailed answers, much appreciated.

The problem with using an implicit allow like you mention Sanjay, is that an allow will always (to my understanding) have priority over an exclude property, regardless of the priority set on the policies. In our hybrid RBAC, we want behavior that removes the entitlement when the role is removed. The entitlement set is unfortunately not small/manageable enough to rely solely on RBAC.

I do like the idea, that you mention Franz, of using a prefix for all RBAC entitlements and using regex to manage the whitelisting and blacklisting. I will pursue this as a possible solution.

You are correct Franz, we are currently mixing request-based and RBAC. I can't access the RFE, I'm not authorized. Are there any other ways of accessing its content?

Does anyone know if the Null Exclude that I mention in the post is intended? The way it overrides the implicit exclude behavior in the provisioning policy. If that is indeed an intended feature, it can technically be used to allow me to manage the RBAC entitlements through explicit whitelisting and blacklisting. This would be an acceptable short-term solution, but lacking scalability.

The problem is that, if that is not intended or regarded as a bug, we may have a situation in the future where an ISIM fixpack removes the bug/feature :) and the implicit exclude kicks in for the majority of our users, causing a massive loss of entitlements when enforced.


------------------------------
Jonathan Andreasson


Original Message:
Sent: Tue February 25, 2020 02:18 AM
From: Franz Wolfhagen
Subject: ISIM Provisioning policy implicit exclude behavior

I agree on the observed behavior is how ISIM is expected to work (note: - that does not mean that this was the original intent of the designers - some of the finer details of ISIM provisioning policy behavior comes from misunderstanding requirements and wrong implementations according to some of the real old timer ISIM people - I will not go into deeper description here :-)). Also the functionality has been problematic due to problem with the join directive/priority not working in some scenarios (e.g. not being honored in policy preview, but working fine when submitted - I believe these bugs are all fixed in the latest fixpacks).
What is trying to be obtained here is what we historically call "hybrid provisioning" - and it is a somewhat difficult discipline with the current possibilities in ISIM.
Normally I recommend either using a naming scheme (e.g. a prefix on all entitlements (groups) that are governed through RBAC) or some attribute scheme (e.g. placement in AD OU structure). Naming schemes has the great advantage that you can then easily implement them using the regex mechanism - using attributes based schemes are more complex and requires some advanced JavaScripting.
Whether you implement the RBAC controlled entitlements using whitelisting (allows) or blacklisting is as such not important (I prefer blacklisting) - the real challenge is when you start mixing (and I sense that you may be in that area) RBAC and request based...
There is an RFE (https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=137408) that is considered adding policy enforcement to the provisioning policy level which should make this much easier - alas it is a relatively big change - but you may vote for this or create your own similar RFE (I do not know if you can actually see the RFE due to security restriction...).
I have planned for many years to document some of these details - maybe there is hope - it looks like I will get a little more time working on providing help developing materials to help the field in the future - but do not hold your breath :-)

HTH

------------------------------
Franz Wolfhagen
IAM Technical Architect for Europe - Certified Consulting IT Specialist
IBM Security Expert Labs


Original Message:
Sent: Mon February 24, 2020 10:59 AM
From: Sanjay Sutar
Subject: ISIM Provisioning policy implicit exclude behavior

I dont know how many groups you have to manage through RBAC policy, i am assuming they are in hundreds if not thousands. 
The behavior you mentioned, ISIM is working as per designed (as you already found out). One way to make it work is allow * , which essentially means allow any group value (to be assigned manually in ISIM or on target). But then its quite open and there is no real RBAC. If your groups are manageable and you know what set of groups can be assigned based on person's role then you can limit the allowed list to specific set based on role membership. Something like this, role1 will have groups1 mandetory and some from optional list (allowed).  Removing the role1 should remove group1 and any assigned from optional list (unless there is overlap with other policy).

------------------------------
Sanjay Sutar

No, the priority has no particular impact, it is of course governed by the allow over deny precedence rule in this case. Thank you for clarifying.

------------------------------
Jonathan Andreasson
------------------------------

Original Message:
Sent: Wed February 26, 2020 08:17 AM
From: Franz Wolfhagen
Subject: ISIM Provisioning policy implicit exclude behavior

Thanks for confirming (and taking the time to deep dive) - I believe that this is the expected outcome.

One thing that alarms a little bit is that you talk about priority for attributes (groups) that are governed by a join directive of "Union". Priority has no impact in this case - it only has impact for attributes that has a "Priority" join directive (it may impact Compliance Alert Rules - but I thing Alert rules are broken by design and I have never seen them in real life).

Another thing to be aware of is that you have conflicting policies with the same priority ISIM just picks one - not rules about which (I think it takes the first returned from the ldap/cache - but that is only of intellectual interest for ISIM nerds).

HTH

------------------------------
Franz Wolfhagen
IAM Technical Architect for Europe - Certified Consulting IT Specialist
IBM Security Expert Labs
------------------------------


Original Message:
Sent: Wed February 26, 2020 07:55 AM
From: Jonathan Andreasson
Subject: ISIM Provisioning policy implicit exclude behavior

Hi,

Ok, so I think I figured out how the null value is impacting the provisioning policy join behavior and why. I will explain it below for documentation purposes.

Account validation logic - in this resource the null value is explained in more detail for the union policy join.

At the end of the day, we had two separate policy parameters that would return null values in some cases.

Parameter 1:
Name: Group
Template value: if x then return group1 else return null
Enforcement: Mandatory
Value Type: JavaScript
Priority: 10 100

According to the "Account validation logic" this will result in the following: A null mandatory parameter value means that all values on the corresponding attribute of a new or existing account are disallowed except those values that any other valid values permit. When any attribute values on an existing account are denied by a null mandatory parameter, such values are automatically removed.

Parameter 2:
Name: Group
Template value: if y then return group2 else return null
Enforcement: Excluded
Value Type: JavaScript
Priority: 10 000

According to the "Account validation logic" this will result in the following: A null excluded parameter means that all attribute values are allowed on the corresponding attribute of a new or existing account except those values denied by any other denying parameter value.

We were unknowingly using the mandatory null in different policies with lower priority, which forced an implicit deny on the group attribute. This effect was in turn counteracted by a separate misconfigured policy that was returning exclude null with a higher priority. This second parameter forced the default behavior back to an allow implicit + deny explicit structure.

If both these parameters are reconfigured to not return null in the else scenario we will restore the default behavior. From there we will use a naming standard to improve the exclude structure.

Thank you all for your input and help.

------------------------------
Jonathan Andreasson


Original Message:
Sent: Tue February 25, 2020 10:06 AM
From: Jonathan Andreasson
Subject: ISIM Provisioning policy implicit exclude behavior

Hi Tobias, thank you for taking the time to help out.

I agree and intend to follow up and implement a feature to assure that the exclude list is kept up-to-date automatically. Otherwise, the solution simply would not be scalable. 

As for the second point you mention, this is where my problem lies. My policy uses mandatory, default and exclude parameters for the group attribute. If I do not have a "null" exclude or one with a similar effect the implicit exclude takes precedence. In other words, if I use a constant value exclude for a specific group instead of my "null" exclude, the implicit exclude is seen in the preview.

------------------------------
Jonathan Andreasson


Original Message:
Sent: Tue February 25, 2020 05:37 AM
From: Tobias Ernstberger
Subject: ISIM Provisioning policy implicit exclude behavior

Hello Jonathan,

from the Knowledgecenter I want to cite the following points, which should clarify your observed behaviour:
1.) Having only mandatory: "Mandatory attributes are set to the defined value, and all other values are not valid.". 
This explains your "implicit exclude".

2.) Having mandatory in combination with exclude: "Mandatory attributes are set to defined values. Excluded attribute values are removed (all other values can be present or set on the attribute)."
In this combination, it's not relevant if you exclude "null", an empty string, a regex, or whatever. The excluded values are no longer allowed and will be removed from the account. 

Having that said, I want to add a more general comment: If you use the hybrid approach with RBAC on some groups (and excludes on them), and non-RBAC on others, I assume that the groups will change over time (new groups, groups start to get managed via RBAC). In this case, it's important that your excludes always are up to date and exactly cover the groups which are RBAC managed. Try to find a design where this is guaranteed by design to avoid mistakes. Franz already mentioned two typical aproaches: Naming schema and some target-system-specific properties. 

HTH




------------------------------
Tobias Ernstberger


Original Message:
Sent: Tue February 25, 2020 05:12 AM
From: Jonathan Andreasson
Subject: ISIM Provisioning policy implicit exclude behavior

Thank you Franz and Sanjay for your detailed answers, much appreciated.

The problem with using an implicit allow like you mention Sanjay, is that an allow will always (to my understanding) have priority over an exclude property, regardless of the priority set on the policies. In our hybrid RBAC, we want behavior that removes the entitlement when the role is removed. The entitlement set is unfortunately not small/manageable enough to rely solely on RBAC.

I do like the idea, that you mention Franz, of using a prefix for all RBAC entitlements and using regex to manage the whitelisting and blacklisting. I will pursue this as a possible solution.

You are correct Franz, we are currently mixing request-based and RBAC. I can't access the RFE, I'm not authorized. Are there any other ways of accessing its content?

Does anyone know if the Null Exclude that I mention in the post is intended? The way it overrides the implicit exclude behavior in the provisioning policy. If that is indeed an intended feature, it can technically be used to allow me to manage the RBAC entitlements through explicit whitelisting and blacklisting. This would be an acceptable short-term solution, but lacking scalability.

The problem is that, if that is not intended or regarded as a bug, we may have a situation in the future where an ISIM fixpack removes the bug/feature :) and the implicit exclude kicks in for the majority of our users, causing a massive loss of entitlements when enforced.


------------------------------
Jonathan Andreasson


Original Message:
Sent: Tue February 25, 2020 02:18 AM
From: Franz Wolfhagen
Subject: ISIM Provisioning policy implicit exclude behavior

I agree on the observed behavior is how ISIM is expected to work (note: - that does not mean that this was the original intent of the designers - some of the finer details of ISIM provisioning policy behavior comes from misunderstanding requirements and wrong implementations according to some of the real old timer ISIM people - I will not go into deeper description here :-)). Also the functionality has been problematic due to problem with the join directive/priority not working in some scenarios (e.g. not being honored in policy preview, but working fine when submitted - I believe these bugs are all fixed in the latest fixpacks).
What is trying to be obtained here is what we historically call "hybrid provisioning" - and it is a somewhat difficult discipline with the current possibilities in ISIM.
Normally I recommend either using a naming scheme (e.g. a prefix on all entitlements (groups) that are governed through RBAC) or some attribute scheme (e.g. placement in AD OU structure). Naming schemes has the great advantage that you can then easily implement them using the regex mechanism - using attributes based schemes are more complex and requires some advanced JavaScripting.
Whether you implement the RBAC controlled entitlements using whitelisting (allows) or blacklisting is as such not important (I prefer blacklisting) - the real challenge is when you start mixing (and I sense that you may be in that area) RBAC and request based...
There is an RFE (https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=137408) that is considered adding policy enforcement to the provisioning policy level which should make this much easier - alas it is a relatively big change - but you may vote for this or create your own similar RFE (I do not know if you can actually see the RFE due to security restriction...).
I have planned for many years to document some of these details - maybe there is hope - it looks like I will get a little more time working on providing help developing materials to help the field in the future - but do not hold your breath :-)

HTH

------------------------------
Franz Wolfhagen
IAM Technical Architect for Europe - Certified Consulting IT Specialist
IBM Security Expert Labs


Original Message:
Sent: Mon February 24, 2020 10:59 AM
From: Sanjay Sutar
Subject: ISIM Provisioning policy implicit exclude behavior

I dont know how many groups you have to manage through RBAC policy, i am assuming they are in hundreds if not thousands. 
The behavior you mentioned, ISIM is working as per designed (as you already found out). One way to make it work is allow * , which essentially means allow any group value (to be assigned manually in ISIM or on target). But then its quite open and there is no real RBAC. If your groups are manageable and you know what set of groups can be assigned based on person's role then you can limit the allowed list to specific set based on role membership. Something like this, role1 will have groups1 mandetory and some from optional list (allowed).  Removing the role1 should remove group1 and any assigned from optional list (unless there is overlap with other policy).

------------------------------
Sanjay Sutar