[midPoint] programmatically "reconcile a user"
Dharmendra Parakh
dharmendra at confluxsys.com
Tue Mar 3 05:01:01 CET 2015
Hi Pavol
Thanks for the information.
I think it is nice and sufficient information. As you have mentioned there
are very few icf attributes, I will modify my code to set the appropriate
namespace so there should not be any issue.
Thanks!
On Tue, Mar 3, 2015 at 3:26 AM, Pavol Mederly <mederly at evolveum.com> wrote:
> Hello Dharmendra,
>
> generally speaking, the <ref> element in the inducement requires the
> namespace to be present and to be declared in order to function correctly.
> Maybe in 3.2 we'll change this, as is discussed in MID-2191
> <https://jira.evolveum.com/browse/MID-2191>, but for 3.1 it is definitely
> so.
>
> We have added this inducement by web-service client and at that point we
> do not have information about correct namespace so how can we get rid of
> this.
> The problem we have is at that point we do not know if the attribute is
> icf attribute or not so we cannot add the namespace. So is it necessary to
> have the correct namespace or is it a problem in midpoint?
>
>
> I'm not sure I understand you fully.
>
> I think you can safely add the following namespace:
>
> Either *xmlns:ri="http://midpoint.evolveum.com/xml/ns/public/resource/instance-3"
> <http://midpoint.evolveum.com/xml/ns/public/resource/instance-3>* for
> majority of attribute names, or
> *xmlns:icfs="http://midpoint.evolveum.com/xml/ns/public/connector/icf-1/resource-schema-3"
> <http://midpoint.evolveum.com/xml/ns/public/connector/icf-1/resource-schema-3>*
> for special names, like icfs:name, icfs:uid, icfs:groups and a few others,
> less frequently used.
>
> It does not matter if you create a role or its inducement via GUI, import
> objects, or via web service. In all the cases you can (and should) use the
> correct namespace.
>
> One note regarding undeclared namespaces (like qn43:groups without
> declaring qn43). In midPoint 3.1, these are not checked, and result of
> using them is generally unpredictable. In current master, we added a code
> that checks for such situations, and forbids using object with such
> undeclared namespaces (as described in MID-2191). This check can be
> temporarily turned off via Configuration->Internals
> configuration->Internals config->Tolerate undeclared prefixes...); when
> releasing 3.1.1 it will be probably turned OFF by default. Maybe the role
> search in your case is failing because of this (but I'm not sure); please
> check the midPoint logs. Anyway, it is strictly necessary to use correctly
> defined namespaces in <ref> elements.
>
> Hope this helps,
> Pavol
>
> PS: I'm on a vacation this week. So perhaps someone else on this list
> would be able to help you further, or I'll be back on March 8th (or perhaps
> during evenings/nights, but without warranty).
>
>
>
> On 2. 3. 2015 8:36, Dharmendra Parakh wrote:
>
> Hi
>
> I have a situation where my role search is failing when i search by
> name/oid or type.
>
> As per my observation this role has an inducement in which there is
> certain attribute without namespace defined:
>
> <inducement id="2">
>
> <construction>
>
> <resourceRef oid="ef2bc95b-76e0-48e2-86d6-3d4f02d3eaef"
> type="ResourceType"><!-- Active Directory Resource --></resourceRef>
>
> <attribute>
>
> <ref>qn43:groups</ref>
>
> <outbound>
>
> <strength>strong</strength>
>
> <expression>
>
>
> <value>cn=portal_support,ou=groups,dc=confluxsys,dc=com</value>
>
> </expression>
>
> </outbound>
>
> </attribute>
>
> </construction>
>
> </inducement>
>
>
> Now when i added appropriate namespace it worked for me.
>
> <inducement id="2">
>
> <construction>
>
> <resourceRef oid="ef2bc95b-76e0-48e2-86d6-3d4f02d3eaef"
> type="ResourceType"><!-- Active Directory Resource --></resourceRef>
>
> <attribute>
>
> <ref xmlns:qn43="
> http://midpoint.evolveum.com/xml/ns/public/connector/icf-1/resource-schema-3
> ">qn43:groups</ref>
>
> <outbound>
>
> <strength>strong</strength>
>
> <expression>
>
>
> <value>cn=portal_support,ou=groups,dc=confluxsys,dc=com</value>
>
> </expression>
>
> </outbound>
>
> </attribute>
>
> </construction>
>
> </inducement>
>
>
>
> We have added this inducement by web-service client and at that point we
> do not have information about correct namespace so how can we get rid of
> this.
> The problem we have is at that point we do not know if the attribute is
> icf attribute or not so we cannot add the namespace. So is it necessary to
> have the correct namespace or is it a problem in midpoint?
>
> Please provide some assistance on this.
>
>
> Thanks
> Dharmendra
>
>
> On Thu, Feb 12, 2015 at 6:57 PM, Dharmendra Parakh <
> dharmendra at confluxsys.com> wrote:
>
>> Hey Pavol
>>
>> I missed that equal thing.
>>
>> Thanks, that worked like a charm.
>>
>> Regards
>> Dharmendra
>>
>>
>> On Thu, Feb 12, 2015 at 6:34 PM, Pavol Mederly <mederly at evolveum.com>
>> wrote:
>>
>>> Dharmendra,
>>>
>>> it is not supported to test references using <equal> condition. You have
>>> to use <ref> one.
>>>
>>> So I suggest to replace "<equal ..." section in .parseSearchFilterType()
>>> call with this one
>>>
>>> <ref>
>>> <path>assignment/targetRef</path>
>>> <value>
>>> <oid>* ... put roleOid here ... *</oid>
>>> <type>RoleType</type>
>>> </value>
>>> </ref>
>>>
>>> It should work. :-) If not, please let me know.
>>>
>>> Best regards,
>>> Pavol
>>>
>>> HI
>>>
>>> I tried it but didn't work for me, I am using following code:
>>>
>>> private static List<UserType> searchRoleMembers(ModelPortType
>>> modelPort, String roleOid) throws SAXException, IOException, FaultMessage,
>>> JAXBException {
>>> // WARNING: in a real case make sure that the username is properly
>>> // escaped before putting it in XML
>>> SearchFilterType filter = ModelClientUtil
>>> .parseSearchFilterType("<equal xmlns='
>>> http://prism.evolveum.com/xml/ns/public/query-3' xmlns:c='
>>> http://midpoint.evolveum.com/xml/ns/public/common/common-3' >"
>>> + "<path>assignment/targetRef</path>" + "<value><oid>" + roleOid +
>>> "</oid> <type>RoleType</type> </value>" + "</equal>");
>>> QueryType query = new QueryType();
>>> query.setFilter(filter);
>>> SelectorQualifiedGetOptionsType options = new
>>> SelectorQualifiedGetOptionsType();
>>> Holder<ObjectListType> objectListHolder = new Holder<ObjectListType>();
>>> Holder<OperationResultType> resultHolder = new
>>> Holder<OperationResultType>();
>>>
>>> modelPort.searchObjects(ModelClientUtil.getTypeQName(UserType.class),
>>> query, options, objectListHolder, resultHolder);
>>>
>>> ObjectListType objectList = objectListHolder.value;
>>> List<ObjectType> objects = objectList.getObject();
>>> if (objects.isEmpty()) {
>>> return null;
>>> }
>>> List<UserType> result = new ArrayList<>(objects.size());
>>> for(ObjectType object: objects ){
>>> result.add((UserType) object);
>>> }
>>> return result;
>>> }
>>> Am i doing anything wrong?
>>>
>>> Thanks!
>>>
>>>
>>> On Thu, Feb 12, 2015 at 4:36 PM, Pavol Mederly <mederly at evolveum.com>
>>> wrote:
>>>
>>>> You can easily get all users that have *directly* assigned a role -
>>>> it is a search on UserType using the following criteria:
>>>>
>>>> <ref>
>>>> <path>assignment/targetRef</path>
>>>> <value>
>>>> <oid>00000000-0000-0000-0000-000000000004</oid>
>>>> <type>RoleType</type>
>>>> </value>
>>>> </ref>
>>>>
>>>> (replace 00000000-0000-0000-0000-000000000004 with the OID of your role)
>>>>
>>>> However, this does not find users that have such a role assigned
>>>> indirectly (e.g. as inducement in another role). This is not currently
>>>> supported.
>>>>
>>>> Best regards,
>>>> Pavol
>>>>
>>>> HI
>>>>
>>>> Thanks for the information, this works.
>>>>
>>>> One more thing Our requirement is to reconcile users associated to
>>>> some specific role, So is there a way to get the users associated to a role
>>>> without iterating all the users.
>>>>
>>>>
>>>> Thanks!
>>>>
>>>> On Thu, Feb 12, 2015 at 3:27 PM, Pavol Mederly <mederly at evolveum.com>
>>>> wrote:
>>>>
>>>>> Hello Manish,
>>>>>
>>>>> I've just pushed a sample code that demonstrates this.
>>>>>
>>>>> Here is the java code - actually, it's an empty modification with
>>>>> RECONCILE option set (see red lines):
>>>>>
>>>>> private static void reconcileUser(ModelPortType modelPort, String
>>>>> oid) throws FaultMessage {
>>>>>
>>>>>
>>>>> ObjectDeltaType userDelta = new ObjectDeltaType();
>>>>>
>>>>> userDelta.setOid(oid);
>>>>>
>>>>>
>>>>> userDelta.setObjectType(ModelClientUtil.getTypeQName(UserType.class));
>>>>>
>>>>> userDelta.setChangeType(ChangeTypeType.MODIFY);
>>>>>
>>>>>
>>>>>
>>>>> ObjectDeltaListType deltaList = new ObjectDeltaListType();
>>>>>
>>>>> deltaList.getDelta().add(userDelta);
>>>>>
>>>>>
>>>>>
>>>>> ModelExecuteOptionsType optionsType = new
>>>>> ModelExecuteOptionsType();
>>>>>
>>>>> optionsType.setReconcile(true);
>>>>>
>>>>> modelPort.executeChanges(deltaList, optionsType);
>>>>>
>>>>> }
>>>>>
>>>>> This is how it looks like in XML:
>>>>>
>>>>> <soap:Body>
>>>>> <ns8:executeChanges
>>>>> xmlns:ns2=
>>>>> "http://prism.evolveum.com/xml/ns/public/types-3"
>>>>> <http://prism.evolveum.com/xml/ns/public/types-3>
>>>>> xmlns:ns3=
>>>>> "http://midpoint.evolveum.com/xml/ns/public/common/common-3"
>>>>> <http://midpoint.evolveum.com/xml/ns/public/common/common-3>
>>>>> xmlns:ns8=
>>>>> "http://midpoint.evolveum.com/xml/ns/public/model/model-3"
>>>>> <http://midpoint.evolveum.com/xml/ns/public/model/model-3>
>>>>> xmlns:ns9=
>>>>> "http://midpoint.evolveum.com/xml/ns/public/common/api-types-3"
>>>>> <http://midpoint.evolveum.com/xml/ns/public/common/api-types-3>>
>>>>>
>>>>> <ns8:deltaList>
>>>>> <ns9:delta>
>>>>> <ns2:changeType>modify</ns2:changeType>
>>>>> <ns2:objectType>ns3:UserType</ns2:objectType>
>>>>>
>>>>> <ns2:oid>c0c010c0-d34d-b33f-f00d-11111111ec1e</ns2:oid>
>>>>> </ns9:delta>
>>>>> </ns8:deltaList>
>>>>> <ns8:options>
>>>>> <ns3:reconcile>true</ns3:reconcile>
>>>>> </ns8:options>
>>>>> </ns8:executeChanges>
>>>>> </soap:Body>
>>>>>
>>>>> Hope this helps.
>>>>> Pavol
>>>>>
>>>>>
>>>>> On 10. 2. 2015 22:40, Manish Baid wrote:
>>>>>
>>>>> Hi,
>>>>> Using webservice client, can you please share some pointers on how to:
>>>>> programmatically "reconcile a user"?
>>>>>
>>>>> Basically, we are trying to re-enforce role-inducement updates to
>>>>> "affected" users.
>>>>>
>>>>>
>>>>> Thanks
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> midPoint mailing listmidPoint at lists.evolveum.comhttp://lists.evolveum.com/mailman/listinfo/midpoint
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> midPoint mailing listmidPoint at lists.evolveum.comhttp://lists.evolveum.com/mailman/listinfo/midpoint
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> midPoint mailing list
>>>> midPoint at lists.evolveum.com
>>>> http://lists.evolveum.com/mailman/listinfo/midpoint
>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> midPoint mailing listmidPoint at lists.evolveum.comhttp://lists.evolveum.com/mailman/listinfo/midpoint
>>>
>>>
>>>
>>> _______________________________________________
>>> midPoint mailing list
>>> midPoint at lists.evolveum.com
>>> http://lists.evolveum.com/mailman/listinfo/midpoint
>>>
>>>
>>
>
>
> _______________________________________________
> midPoint mailing listmidPoint at lists.evolveum.comhttp://lists.evolveum.com/mailman/listinfo/midpoint
>
>
>
> _______________________________________________
> midPoint mailing list
> midPoint at lists.evolveum.com
> http://lists.evolveum.com/mailman/listinfo/midpoint
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20150303/19d82675/attachment.htm>
More information about the midPoint
mailing list