Full Access to DEBUG Page Without Granting System Administrator

[brandonmoxley]

Which IIQ version are you inquiring about?

8.4p1 e243e6f4783-20240325-035201

Please share any images or screenshots, if relevant.

Please share any other relevant files that may be required (for example, logs).

LogFile.txt (23.5 KB)

Share all details about your problem, including any error messages you may have received.

We are attempting to build out a new Capability within IdentityIQ. We’ve named it “FullAccessDebug”. The intended purpose is to give some folks more than simply view-only access to the IdentityIQ DEBUG page, without assigning full System Admin permissions. We need both for these people to be able to view objects within DEBUG, but also to be able to both edit and run rules from within DEBUG.

Our Capability is below in its current state. We have, at this point, assigned 3 separate SPRights to it. If we remove ‘ViewAccessDebugPage’, then users with this capability cannot access DEBUG at all, which generates the attached log file which states “User does not have access to this work item”. With ‘ViewAccessDebugPage’ assigned, users can access DEBUG, however things like the ‘Run Rule’ and ‘Save’ buttons, and the ‘Select an action’ dropdown, are all grayed out / disabled (screenshot).

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE Capability PUBLIC "sailpoint.dtd" "sailpoint.dtd">
<Capability name="FullAccessDebug">
  <Description>Capability for accessing full debug page</Description>
  <RightRefs>
    <Reference class="sailpoint.object.SPRight" name="FullAccessDebugPage"/>
    <Reference class="sailpoint.object.SPRight" name="ViewAccessDebugPage"/>
    <Reference class="sailpoint.object.SPRight" name="ManageRules"/>
  </RightRefs>
</Capability>

Also including all of the currently SPRight objects below.

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE SPRight PUBLIC "sailpoint.dtd" "sailpoint.dtd">
<SPRight displayName="right_full_access_debug_page" name="FullAccessDebugPage">
  <Description>right_desc_full_access_debug_page</Description>
</SPRight>

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE SPRight PUBLIC "sailpoint.dtd" "sailpoint.dtd">
<SPRight displayName="right_view_access_debug_page" name="ViewAccessDebugPage">
  <Description>right_desc_view_access_debug_page</Description>
</SPRight>

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE SPRight PUBLIC "sailpoint.dtd" "sailpoint.dtd">
<SPRight displayName="right_manage_rules" name="ManageRules">
  <Description>right_desc_manage_rules</Description>
</SPRight>

All SPRight objects used here already existed, and we created net new the ‘FullAccessDebug’ Capability.

After creation and after every modification, we have cycled Tomcat services and attempted accessing DEBUG after a fresh authentication.

Guessing this is something trivial, but I am not seeing it at this time and would appreciate any assistance!

[tharshith (Harshith Thondamnati)]

Hi @brandonmoxley

I checked your custom capability. This seems to be working properly in my local. Try to check clearing cache in both Sailpoint and browser.

Also try in this way →

1. Login with user for whom you want this capability before assigning it.
2. Try accessing debug page which should throw error.
3. Now try assigning that capability. Do not just refresh the debug page in test user session. Logout and login back - This kills the previous session and creates new one with newly assigned capability.

Thanks,
Harshith

[brandonmoxley]

@tharshith thanks for the reply!

I cleared cache and tested with another Identity. I’ve already done several Tomcat restarts)

Without the new capability, accessing DEBUG gives this, as expected.

I then added the capability.

It grants read only access to DEBUG, but doesn’t allow me to do any of the following functions.

• Run Rule
• Save any objects
• Click the ‘Select an action’ button

When you tested in your local, did you have access to these functions?

[vishal_kejriwal1 (Vishal Kejriwal)]

I understand you ask that FullAccessDebugPage as SPRight should give access , but I think only System Administrator capability able to write the object from debug page.
I would suggest create a ticket with sailpoint .

[brandonmoxley]

Hey @vishal_kejriwal1 , thanks for the response! That’s what I was worried would be the answer - We’ll open a ticket and see what they say!

[tharshith (Harshith Thondamnati)]

Hi @brandonmoxley ,

Your SPRights will only give you read-only access to debug pages as you need. These SPRights won’t include options to Run rules, select actions & save objects because all these actions will be considered as Write operation.
So in readonly mode, this is want you get to see in debug page. If you want to access the above mentioned options, you’ll have to change the SPRights and therefore it’ll never be considered as Readonly.

Thanks,
Harshith

[drardin (Dalton Rardin)]

Anyone who has the ability to write and run arbitrary rules in debug is able to give themselves full SystemAdministrator access. Even if they don’t give themselves sysadmin access, they’re still able to stealthily modify any configuration or data inside of IIQ and can also give themselves additional permissions on any application that IIQ has provisioning capabilities on. I’m not sure what your exact use case is, but you might as well just give them the SystemAdministrator capability in almost every scenario.

[phodgdon (Paul Hodgdon)]

We have an open source plugin that you can give users access to that will let them open rules, edit them and run them. It’s basically an IDE within SailPoint. Not sure what the objectives are for debug access but thought I would share: IIQ Rule Runner - Instrumental Identity

[brandonmoxley]

Hey @tharshith ,
We aren’t trying for read-only rights, but if we do not include ‘ViewAccessDebugPage’, we get no rights at all to the DEBUG page. We only added that to confirm that we can get there in the first place, but unfortunately the ‘FullAccessDebugPage’ seems to only grant permissions outside of editing code objects and running rules. By the name, ‘FullAccessDebugPage’ felt like it would be the right thing for what we require.

[brandonmoxley]

Hey @drardin , it is a solid point about how they’d also gain the ability to grant themselves System Administrator rights if they so chose. This is something we’ve also thought of.

Ultimately, we want to give someone additional rights to edit/run rules, as we have a collection of rules to run from DEBUG where an identity name (or names) needs to be entered into the rule before running it. Those rules then loop through and process whatever provisioning we’ve designed out in the rule. These are quick rules we’ve built to do things like “prepare identity for joiner”, in the event we need to reprocess an LCE, for instance. We know this can also be done via direct Identity modifications, but wish to leave this as a rule.

We want to avoid giving someone everything else that comes along with the System Administrator permissions, such as all the additional menu options they’d see. The folks we want to apply this to are going to be assisting in a form of support role alongside primary IdentityIQ Engineers, and are individuals we’re willing to trust with full System Administrator rights if required. We’re just trying to avoid it if possible.

[brandonmoxley]

Thanks @phodgdon ! This looks like it could be a solid option, if we’re unable to accommodate without any external/custom tools. We’re still working with SailPoint on a case, they’ve opened an Engineering ticket with this marked as a defect, though not sure how quickly that will move or where to. I’ll try and check this out more this week, as this plugin may just be the route we need to go.

Can you confirm what rights it requires? Specifically, can this be leveraged without System Administrator permissions?

[drardin (Dalton Rardin)]

Ah, gotcha. That makes sense. What we do to handle that use case is to create a rule and use the “Run Rule” task type. It lets you create a task with custom inputs that can be modified and run by anyone with access to run tasks.

There’s a little bit of info about it in this Tasks Guide.

8.4 IdentityIQ Tasks Guide

[brandonmoxley]

Thanks again, @drardin ! We’ve used it before, but haven’t lately due to the larger number of small rules we’ve created like this. That said, it is worth looking into again for this use case to avoid System Administrator rights - Thank you!

[drardin (Dalton Rardin)]

No worries! Just throwing this out there, but you could probably make a Run Rule task that takes a list of Identities and a list of Rules as inputs. Then inside your Run Rule rule, you loop through the list of selected Rules and Identities to process them. That way, they can still run an arbitrary rule but with a little better UX and no additional access.

Something like this:

[phodgdon (Paul Hodgdon)]

Correct it has its own SPRight so you can assign that to whatever users you want.

[brandonmoxley]

Thanks @drardin ! I think adding a list in this way is a great suggestion, thank you!

While not granting access to DEBUG as intended in the original post, marking yours as the official answer as it will fully accomplish what we need

[brandonmoxley]

@phodgdon thanks for the additional information! I’ve been told to hold on pursuing the open-source plugin at this time, however we’ll keep this information handy if other avenues don’t work out!