JDBC Connector entitlement revocation support

Identity Security Cloud (ISC) ISC Discussion and Questions
, ,
1

Hi all, I’ve looked around and have an idea that this isn’t supported, but was hoping for a little more direct confirmation.

We’re looking integrating a legacy source backed by a JDBC-compliant DB (and without any API support for Web Services connector usage) into a certification campaign process for user access reviews. A piece of that is figuring out if automatic revocations would be supported. I’m pretty sure that is simply NOT supported using the JDBC connector, given the connector docs and that the “Query Settings” part of configuration implies only account aggregation support. But, if someone had already tackled a case like this before and could confirm my suspicions that would be great.

We have purchased the “Provisioning” feature of JDBC connectors, though I’m pretty sure that functionality lies outside the domain of certification campaign revocations as well?

2

You would need to leverage the JDBC Provision Rule in this case and write the query to Delete/Update the record for any entitlement removed during certification.

3

Thanks for response. Just so I’m clear: a revoked entitlement in the certification campaign would result in a ProvisioningPlan to be generated that would hopefully hit this code block for AccountRequest.Operation.Modify (as grabbed from the example code block in the Dev Community post you linked)? Then we’d simply have to write up SQL logic to remove an entitlement? Do you know if it’s possible to make API requests from within the Provisioning Rule context, as there could be additional logic we’d need in order to revoke certain entitlements?

For default JDBC sources pulled into cert campaigns, would revocations simply result in a “failed” ProvisioningPlan since that operation is not supported OOB by the connector?

else if ( AccountRequest.Operation.Modify.equals( account.getOperation() ) ) {

            // Modify account request -- change role

            PreparedStatement statement = connection.prepareStatement( "update users set role = ? where login = ?" );
            statement.setString ( 2, (String) account.getNativeIdentity() );
            if ( account != null ) {
              AttributeRequest attrReq = account.getAttributeRequest("role");
              if ( attrReq != null && ProvisioningPlan.Operation.Remove.equals(attrReq.getOperation()) ) {
                statement.setNull ( 1, Types.NULL );
                statement.executeUpdate();
              } else {
                statement.setString(1,attrReq.getValue());
                statement.executeUpdate();
              }
            }
            result.setStatus( ProvisioningResult.STATUS_COMMITTED );

          }
4

I have used classes from org.apache.http.client.methods library to connect to APIs in Web Services BeforeOperation rules, and don’t see why they won’t work in JDBC rules. I think it’s worth giving a try.

And, in your below code you need to add attrReq != null to else as well. Or, just wrap the whole if/else with another if(attrReq != null) and remove the condition from original if

Also I would move the common line statement.executeUpdate() out of if/else blocks

1 Like
5

Hi Ian! In addition, OOTB connector only performs aggregation. Take this in mind because provisioning is offered as a service by Sailpoint. You can sure develop the rule, but Sailpoint will not support your rule (or perhaps yeas with some charge). Saying that, all provisioning operations must be performed on the rule.

When all provisioning operatins are working, like create account, modify attribute, grant or revoke entitlements, enable/disable account, etc (you are not due to implement all operations), then it will work from all above layers (that is, if you go to entitlement - revoke and it works, it will also work with other features like certifications, role removal, etc.

This is working for me in some connector I have on a production Tenant:

..................
List accounts = plan.getAccountRequests();
Iterator accountsIterator = accounts.iterator();
while (accountsIterator.hasNext()) {
    AccountRequest account = (AccountRequest) accountsIterator.next();
    Map accountAttributes = new HashMap();
    List attributesRequestList = account.getAttributeRequests();
    Iterator attributesRequesIterator = attributesRequestList.iterator();
    while (attributesRequesIterator.hasNext()) {
		AttributeRequest attributeRequest = (AttributeRequest) attributesRequesIterator.next();
                if(attributeRequest.getName().equals("ENTITLEMENT_ATTRIBUTE"))  // this must be the name of the entitlement as you define on connector schema
                    String ENTITLEMENT_VALUE  = attributeRequest.getValue(); // only comes with value when adding or removing entitlement, else come nuuls						
.....................
if (AccountRequest.Operation.Create.equals(account.getOperation())) {
.....................
} else if (AccountRequest.Operation.Modify.equals(account.getOperation())) {
    if(ENTITLEMENT_VALUE != null && !ENTITLEMENT_VALUE.equalsIgnoreCase("null")) {
        List attributeRequests = account.getAttributeRequests();
        Iterator attributeRequestsIterator = attributeRequests.iterator();
        while (attributeRequestsIterator.hasNext()) {
            AttributeRequest attributeRequest = (AttributeRequest) attributeRequestsIterator.next();
	    String operation = attributeRequest.getOp().toString();
            if(operation.equalsIgnoreCase("Add")) {
                // put SQL statements here to add the profile to the user
            } else if(operation.equalsIgnoreCase("Remove")) {
                // put SQL statements here to remove the profile to the user
            }
-----------------------
1 Like
6

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.