Read attributes from do-find-matching-object response

Hi, I'm just testing out a python scripting driver to interface with Okta. When I do trigger the do-find-matching-object rule in the Matching Policy on the Sub channel, it finds an existing user to match. What I'd like to do is read the current status of the user at the same time. That data is returned in the response as an attribute however i can't work out how to utilise that data in the current add operation?

Can someone please advise? L3 trace below.

 

 

 

 

 

[03/16/20 09:22:31.912]:IDMOKTAPW ST:Applying policy: % CCOKTAPW-sub-mp%-C. [03/16/20 09:22:31.913]:IDMOKTAPW ST: Applying to add #1. [03/16/20 09:22:31.913]:IDMOKTAPW ST: Evaluating selection criteria for rule 'Set uaExternalAppId from CN'. [03/16/20 09:22:31.914]:IDMOKTAPW ST: (if-attr 'uaExternalAppId' not-available) = FALSE. [03/16/20 09:22:31.915]:IDMOKTAPW ST: Rule rejected. [03/16/20 09:22:31.915]:IDMOKTAPW ST: Evaluating selection criteria for rule 'Match on uaExternalAppId'. [03/16/20 09:22:31.916]:IDMOKTAPW ST: (if-attr 'uaExternalAppId' available) = TRUE. [03/16/20 09:22:31.917]:IDMOKTAPW ST: Rule selected. [03/16/20 09:22:31.918]:IDMOKTAPW ST: Applying rule 'Match on uaExternalAppId'. [03/16/20 09:22:31.918]:IDMOKTAPW ST: Action: do-find-matching-object(scope="entry",arg-dn("okta"),arg-match-attr("uaExternalAppId")). [03/16/20 09:22:31.919]:IDMOKTAPW ST: arg-dn("okta") [03/16/20 09:22:31.919]:IDMOKTAPW ST: token-text("okta") [03/16/20 09:22:31.920]:IDMOKTAPW ST: Arg Value: "okta". [03/16/20 09:22:31.921]:IDMOKTAPW ST: arg-match-attr("uaExternalAppId") [03/16/20 09:22:31.921]:IDMOKTAPW ST: Query from policy [03/16/20 09:22:31.921]:IDMOKTAPW ST: <nds dtdversion="4.0" ndsversion="8.x"> <source> <product edition="Standard" version="4.7.1.0">DirXML</product> <contact>NetIQ Corporation</contact> </source> <input> <query class-name="User" dest-dn="okta" scope="entry"> <search-class class-name="User"/> <search-attr attr-name="uaExternalAppId"> <value timestamp="1584074274#77" type="string">a1999982@domain.com</value> </search-attr> <read-attr/> </query> </input> </nds> [03/16/20 09:22:31.929]:IDMOKTAPW ST: Fixing up association references. [03/16/20 09:22:31.929]:IDMOKTAPW ST: Applying schema mapping policies to output. [03/16/20 09:22:31.930]:IDMOKTAPW ST: Applying policy: % CCNOVLSCRGEN-smp%-C. [03/16/20 09:22:31.930]:IDMOKTAPW ST: Mapping attr-name 'uaExternalAppId' to 'login'. [03/16/20 09:22:31.931]:IDMOKTAPW ST: Mapping class-name 'User' to 'User'. [03/16/20 09:22:31.932]:IDMOKTAPW ST: Mapping class-name 'User' to 'User'. [03/16/20 09:22:31.932]:IDMOKTAPW ST: No output transformation policies. [03/16/20 09:22:31.933]:IDMOKTAPW ST: Submitting document to subscriber shim: [03/16/20 09:22:31.933]:IDMOKTAPW ST: <nds dtdversion="4.0" ndsversion="8.x"> <source> <product edition="Standard" version="4.7.1.0">DirXML</product> <contact>NetIQ Corporation</contact> </source> <input> <query class-name="User" dest-dn="okta" event-id="0" scope="entry"> <search-class class-name="User"/> <search-attr attr-name="login"> <value timestamp="1584074274#77" type="string">a1999982@domain.com</value> </search-attr> <read-attr/> </query> </input> </nds> [03/16/20 09:22:31.939]:IDMOKTAPW ST: Remote Interface Driver: Sending... [03/16/20 09:22:31.939]:IDMOKTAPW ST: <nds dtdversion="4.0" ndsversion="8.x"> <source> <product edition="Standard" version="4.7.1.0">DirXML</product> <contact>NetIQ Corporation</contact> </source> <input> <query class-name="User" dest-dn="okta" event-id="0" scope="entry"> <search-class class-name="User"/> <search-attr attr-name="login"> <value timestamp="1584074274#77" type="string">a1999982@domain.com</value> </search-attr> <read-attr/> </query> </input> </nds> [03/16/20 09:22:31.947]:IDMOKTAPW ST: Remote Interface Driver: Document sent. [03/16/20 09:22:31.947]:IDMOKTAPW ST: Remote Interface Driver: Waiting for receive... [03/16/20 09:22:33.496]:IDMOKTAPW ST: Remote Interface Driver: Received [03/16/20 09:22:33.497]:IDMOKTAPW ST: <nds dtdversion="2.0"> <source> <product build="201707161544" version="4.0.3.1"/> <contact/> </source> <output> <instance class-name="User" event-id="0" src-dn=""> <association>00uq6yry49ujtDAXL0h7</association> <attr attr-name="OKTASTATUS"> <value>DEPROVISIONED</value> </attr> </instance> <status level="success">User a1999982@domain.com found in Okta</status> </output> </nds> [03/16/20 09:22:33.503]:IDMOKTAPW ST: Remote Interface Driver: Received command: SUBSCRIBER REPLY(10). [03/16/20 09:22:33.503]:IDMOKTAPW ST: SubscriptionShim.execute() returned: [03/16/20 09:22:33.504]:IDMOKTAPW ST: <nds dtdversion="2.0"> <source> <product build="201707161544" version="4.0.3.1"/> <contact/> </source> <output> <instance class-name="User" event-id="0" src-dn=""> <association>00uq6yry49ujtDAXL0h7</association> <attr attr-name="OKTASTATUS"> <value>DEPROVISIONED</value> </attr> </instance> <status level="success">User a1999982@domain.com found in Okta</status> </output> </nds> [03/16/20 09:22:33.509]:IDMOKTAPW ST: Applying input transformation policies. [03/16/20 09:22:33.510]:IDMOKTAPW ST: Applying policy: % CCOKTAPW-pub-input%-C. [03/16/20 09:22:33.511]:IDMOKTAPW ST: Applying to instance #1. [03/16/20 09:22:33.512]:IDMOKTAPW ST: Evaluating selection criteria for rule 'Read OKTASTATUS'. [03/16/20 09:22:33.512]:IDMOKTAPW ST: (if-operation equal "instance") = TRUE. [03/16/20 09:22:33.514]:IDMOKTAPW ST: (if-op-attr 'OKTASTATUS' available) = TRUE. [03/16/20 09:22:33.515]:IDMOKTAPW ST: Rule selected. [03/16/20 09:22:33.515]:IDMOKTAPW ST: Applying rule 'Read OKTASTATUS'. [03/16/20 09:22:33.515]:IDMOKTAPW ST: Action: do-set-op-property("OKTASTATUS",token-op-attr("OKTASTATUS")). [03/16/20 09:22:33.516]:IDMOKTAPW ST: arg-string(token-op-attr("OKTASTATUS")) [03/16/20 09:22:33.517]:IDMOKTAPW ST: token-op-attr("OKTASTATUS") [03/16/20 09:22:33.517]:IDMOKTAPW ST: Token Value: "DEPROVISIONED". [03/16/20 09:22:33.518]:IDMOKTAPW ST: Arg Value: "DEPROVISIONED". [03/16/20 09:22:33.519]:IDMOKTAPW ST: Action: do-set-xml-attr("oktastatus","$current-op","deprov"). [03/16/20 09:22:33.520]:IDMOKTAPW ST: arg-string("deprov") [03/16/20 09:22:33.520]:IDMOKTAPW ST: token-text("deprov") [03/16/20 09:22:33.521]:IDMOKTAPW ST: Arg Value: "deprov". [03/16/20 09:22:33.521]:IDMOKTAPW ST: Applying to status #2. [03/16/20 09:22:33.522]:IDMOKTAPW ST: Evaluating selection criteria for rule 'Read OKTASTATUS'. [03/16/20 09:22:33.523]:IDMOKTAPW ST: (if-operation equal "instance") = FALSE. [03/16/20 09:22:33.524]:IDMOKTAPW ST: Rule rejected. [03/16/20 09:22:33.524]:IDMOKTAPW ST: Policy returned: [03/16/20 09:22:33.524]:IDMOKTAPW ST: <nds dtdversion="2.0"> <source> <product build="201707161544" version="4.0.3.1"/> <contact/> </source> <output> <instance class-name="User" event-id="0" oktastatus="deprov" src-dn=""> <association>00uq6yry49ujtDAXL0h7</association> <attr attr-name="OKTASTATUS"> <value>DEPROVISIONED</value> </attr> <operation-data OKTASTATUS="DEPROVISIONED"/> </instance> <status level="success">User a1999982@domain.com found in Okta</status> </output> </nds> [03/16/20 09:22:33.530]:IDMOKTAPW ST: Applying schema mapping policies to input. [03/16/20 09:22:33.531]:IDMOKTAPW ST: Applying policy: % CCNOVLSCRGEN-smp%-C. [03/16/20 09:22:33.531]:IDMOKTAPW ST: Mapping class-name 'User' to 'User'. [03/16/20 09:22:33.532]:IDMOKTAPW ST: Resolving association references. [03/16/20 09:22:33.532]:IDMOKTAPW ST: Query from policy result [03/16/20 09:22:33.533]:IDMOKTAPW ST: <nds dtdversion="2.0"> <source> <product build="201707161544" version="4.0.3.1"/> <contact/> </source> <output> <instance class-name="User" event-id="0" oktastatus="deprov" src-dn=""> <association>00uq6yry49ujtDAXL0h7</association> <attr attr-name="OKTASTATUS"> <value>DEPROVISIONED</value> </attr> <operation-data OKTASTATUS="DEPROVISIONED"/> </instance> <status level="success">User a1999982@domain.com found in Okta</status> </output> </nds> [03/16/20 09:22:33.538]:IDMOKTAPW ST: Match found: src-dn='' association='00uq6yry49ujtDAXL0h7'

 

 

 

 

 

Parents Reply Children
  • This is funny, but the question will be forwarded back to OKTA API.
    For example, if for query/matching you can call oktaListUsersbyAttribute (and this call doesn't return all required attributes info), you will have no other options like pass unique user identifier to oktaGetUserbyID and receive missed info.
    you can make both queries (extend "default" logic) from your query/match script.
    I can't see any other possibility.

  • I have configured the remote side so that the initial do-find-matching-object query does return both the association (Okta userID) as well as an attribute value of OKTASTATUS.

    I've managed to make it work by using the input policy on the publisher channel to set a driver scoped variable with the value. I can then read the value on the subscriber channel during the from-merge modify operation. Not the most elegant though I feel.
  • Remember to clear the value at the end.  This is a less than optimal approach.

     

    Any reason, if the Query for do-find-matching works, that a query for Source Attribute or dest attribute does not work?  I.e. Redo the query a second time (wasteful, but hey such is life).

     

  • Thanks Geoff. Yeah, I am clearing the variable as soon as I've used it.

    No reason a query wouldn't work. But we have bulk onboarding events from our source system so I was wanting to make it as efficient as possible. Another query adds significant time.

  • If you are doing bulk updates and relying on an ITP driver scoped variable, take great care, I wouold expect problems, especially if  both channels are in simulatenous use.

     

  • When using the driver global variable approach you can setup a JSON object that contains a pointer to the values you need and tie that to the association. EG:

    {
      "00uq6yry49ujtDAXL0h7" : {
        "Status":  "Deprovisioned"
      }
    }

    And remove this from the variable when processed. That makes it more reliable to get the proper value, there is no way to intercept the matching result otherwise.