Consolidation of PX Policies. Best practices?

[ScottHamilton]

We have a number of Identity policies that CA Support has suggested to convert into PX policies. A number of these identity policies have a lot of fiddly rules in them (if user is in this org and has this job id, etc etc) that really pile up. Making lots of PXes seems like a bad idea. In theory, I could boil the ID policies into a single PX with a LOT of condition-based actions.

 

What are the best practices around whether to have PX policies with lots of condition-based actions vs. having multiple PX policies with small sets of actions? What sort of things should I keep in mind when making the decisions on how to group up these converted ID policies?

 

And, secondarily, how does this apply in general? We have a lot of PX policies flying around all of the time. When is it better to consolidate versus separating?

[SumeetM]

Hi Scott,

 

Please have a look on following two URLs, these may be useful:

 

https://communities.ca.com/docs/DOC-97432298

https://communities.ca.com/docs/DOC-100185921

 

Regards,

Sumeet

 

[Ken Rayman]

Hi Scott,

I had the same issue with client:

I had to set the user class according to 3 attributes that each can have different values, the priority between the attributes was known, for example:

if attribute1 = 100

userclass = 1

if attribute1 = 200

userclass = 2

else

if attribute2 = yes

userclass = 3

else

if attribute3 = USA

userclass = 4

else (default)

userclass = 0

 

Instead of building a ton entry rules, I build a simple database table that hold all this information and with a simple query I got as a data element the user class from the table.

I don't know exactly what you use case is and how your conditions are built, but consider it as a solution.

I do agree that an external to IM work will have to be done to create and manage this information, but, from my experience it's easier to manage data on a database table than on a complex PX logic.