[midPoint] XML attributes
Deepak Natarajan
dnataraj at trilobytesystems.com
Sat Jul 5 11:05:43 CEST 2014
Hi Radovan -
Thanks for the explanation.
I really would like to use the (kind, intent) tuples - they seem to be
powerful concepts if used correctly. I need to study these and get back
to the drawing board - I'm getting a bit tired with hacking my way
around problems rather than using the actual Midpoint constructs meant
to solve them!
I'll write to the list if/when I get confused!
Thanks
-deepak
Radovan Semancik wrote:
> Hi,
>
> I can see two slightly separate issues here:
>
> Issue 1: Complex attribute that is created in two mappings.
>
> If both mappings are inbound mappings in the same resource you may try
> to use this:
> <inbound>
> <source><path>attributes/foo</path></source>
> <source><path>attributes/bar</path></source>
> <expression>.....</expression>
> <target><path>extension/whatever</path></target>
> </inbound>
>
> The inbound mappings and outbound mappings and user template mappings -
> all work in the same way. The inbound mappings just have default pre-set
> source. But you might be able to override it. The mechanism was designed
> for this. But we have never tested this override and therefore I'm not
> sure if it works.
>
> If the mappings are not from the same resource then it will get very
> tricky. You may try to use two separate mappings to get the "id" and
> "value" into user extension and then combine it in object template. But
> this will get very (I mean VERY) complex as this attribute is obviously
> multi-valued.
>
> Maybe you can simplify the situation by avoiding the XML. E.g. use
> string values of "1:a", "2:b" and so on. This is not so elegant but as
> we are slowly moving away from XML this may in fact be a better solution
> for the future.
>
> But ... maybe you do not need this at all ... because:
>
> Issue 2: Handling many types of groups
>
> MidPoint is designed for this. There is a mechanism called "intent".
> This is something like "account type" or "group type". The intent is
> something like a unique identifier of account/group/whatever that is
> linked to a user (or role or org). Therefore if you have a specific user
> that has a linked shadows, each shadow must have unique combination of
> (resourceOid,kind,intent) triple. See
> https://wiki.evolveum.com/display/midPoint/Kind%2C+Intent+and+ObjectClass
>
> So, you can use "intent" as your group type identifier. Intents are
> defined in schemaHandling, therefore they can be modified on runtime. We
> are using a very similar mechanism in one of our solution. We are
> creating the groups in different OUs as well. I'm sure Ivan can provide
> more details on this.
>
> --
>
> Radovan Semancik
> Software Architect
> evolveum.com
>
>
>
>
> On 07/03/2014 06:40 PM, Deepak Natarajan wrote:
>>
>> Hi Radovan -
>>
>> I would like to return to this issue we discussed earlier.
>>
>> You mentioned :
>>
>> "When it comes to your specific case I'm sure that the data can be
>> represented in an alternative way without the use of attributes. Of
>> course you can use this:
>> <group>
>> <id>1</id>
>> <value>a</value>
>> </group>
>> <group>
>> <id>2</id>
>> <value>b</value>
>> </group> "
>>
>> I would like to use this, but am wondering how the inbound mappings
>> would be set up in order to set <id> and <value> in separate mappings.
>> (and they should be for the same <group> instance)
>>
>>
>> In our use case, we have different group "types". What this boils down
>> to is that these groups belong in different OU's (i.e group Foo with
>> type A is under ou=A,o=root,.. and group boo with Type B has a dn
>> cn=Boo, ou=B, o=root etc.) - And more types can arise in the future.
>>
>> In your org sync example, you kept it simple and added all the groups
>> under on OU. I took this a bit further and examine the group name for
>> clues as to where it belongs (it was obvious at one point - but our
>> customer has introduced some new ideas *sigh*)
>>
>> I am trying to build an elegant, flexible solution for this. To
>> somehow propagate these "group types" to my Midpoint User (who has a
>> sequence of <group>'s), onto my Roles and then finally use this to
>> provision the groups correctly in the various OU's.
>>
>> I started off by trying to have a better extension schema :
>> <groups>
>> <group>
>> <name>foo</name>
>> <type>A</type>
>> <group>
>> ...
>> ...
>> </groups>
>>
>> I'm not sure if this is possible (I have read your detailed input on
>> XML usage within Midpoint) and how I would do inbound mapping for such
>> extension elements (considering that my source feed can provide group
>> name and type)
>>
>> And then I would have to deal with role mappings in the user template
>> in order to propagate this as an extension atttribute of Role, and
>> then use this value to figure out the base dn for the group (I have
>> installed my static custom class in Midpoint that returns this value).
>> The idea is to be able to inject new group types at runtime.
>>
>> Essentially I'm looking for a pattern to solve the general case of
>> mapping our source systems rich attributes onto various extended
>> attributes for key Midpoint focal objects such as User & Group.
>>
>> A use case for us is that when a department has a new attribute in the
>> source system (e.g this department is only for "managers"), we need
>> this to translate to a group that is under a specific OU (and this is
>> independent of org sync - i.e users assigned to orgs).
>>
>> I've dumped a lot here, but any thoughts? :)
>>
>> As always, thanks in advance.
>>
>> BR/Deepak
>>
>>> Radovan Semancik <mailto:radovan.semancik at evolveum.com>
>>> May 28, 2014 at 7:54 PM
>>> Hi Deepak,
>>>
>>> I guess I have a bad news for you. But this is quite a long story, so
>>> let's start at the beginning.
>>>
>>> When we have designed midPoint a couple of years ago we have built it
>>> quite tightly on top of XML. That was still the obvious choice at
>>> that time and also some kind of a best practice. And it was not a bad
>>> choice. Especially considering that alternatives such as JSON were
>>> still it their infancy ... and actually they haven't evolved a bit in
>>> all these years - but that's a different story. So, we have built
>>> midPoint on top of XML.
>>>
>>> But the XML stroke back. I was not naive and I was aware that XML is
>>> not perfect when we started with midPoint. But I somehow expected
>>> that we can live with it at least for few years. I was wrong. XML and
>>> XSD and WSDL are terribly bad at handling dynamic schemas. I mean
>>> schemas that are only available at runtime. MidPoint schema extension
>>> is one example of such schema. But there are many more examples:
>>> resource schema, connector schema, reports, ...
>>>
>>> Most other IDM system obviously deal with this problem by ignoring
>>> it. They do not support schema at all. But this was not the path that
>>> we wanted to take with midPoint. MidPoint is fully schema-based from
>>> the bottom (connectors) to the top (GUI). And there are huge
>>> advantages to this architecture. But there are also challenges. And
>>> dealing with XSD and especially Sun XML libraries was a huge challenge.
>>>
>>> And that was the origin of "Prism Objects". We started to slowly
>>> replace XML libraries with a more generic data representation layer.
>>> See:
>>> https://wiki.evolveum.com/display/midPoint/Prism+Objects
>>>
>>> That was approximately the time when JSON became more popular than
>>> XML. And midPoint users started to ask about JSON support. I
>>> personally do not like JSON way of doing things. But we need to
>>> listen to user requests. And we have realized that we can easily
>>> support JSON and also other languages with our Prism layer. And I
>>> actually see an advantage in using readable languages such as YAML.
>>> Therefore we have chosen to go for language independence. XML is just
>>> one of possible data representation languages now. JSON and YAML will
>>> be available soon.
>>>
>>> Currently midPoint (v3.0) is almost completely based on Prism. It is
>>> not using the XML layer directly perhaps except for several places
>>> that we plan to rewrite in next releases. This gives us the ability
>>> to represent data theoretically in any reasonable format. XML is the
>>> primary one. But it is not the only one.
>>>
>>> And now it gets to the point of XML attributes. XML is a very strange
>>> format for data representation. It has nice features (such as safe
>>> extensibility with namespaces) and it has really bad features.
>>> Attributes are one of the worse features. Non-structured data item
>>> can be represented both as an attribute and as an sub-element. This
>>> creates a dichotomy that puzzled software engineers almost since XML
>>> was created. And it is a deadly trap for language-neutral data
>>> abstractions such as our Prism. Also languages such as JSON do not
>>> have attributes at all. And even though we try to have complete
>>> schema for everything there are some corner cases when we need to
>>> work without a schema. And then there may be problem whether to
>>> represent JSON key as XML attribute or sub-element.
>>>
>>> Therefore we have decided to slowly phase out the support for XML
>>> attributes. MidPoint version 3.0 interprets attributes in the same
>>> way as sub-elements. And in fact these are interchangeable at many
>>> places in midPoint XML structures. And more places will appear in
>>> next versions. This is the plan for the entire 3.x generation. The
>>> 4.x versions will probably not use attributes at all.
>>>
>>> So, the use of attributes is still somehow supported. But not
>>> recommended. And the way how you try to use the attributes as a map
>>> will not work in midPoint 3.x. It is not compatible with our data
>>> representation.
>>>
>>> When it comes to your specific case I'm sure that the data can be
>>> represented in an alternative way without the use of attributes. Of
>>> course you can use this:
>>> <group>
>>> <id>1</id>
>>> <value>a</value>
>>> </group>
>>> <group>
>>> <id>2</id>
>>> <value>b</value>
>>> </group>
>>>
>>> And there is another catch. As we are moving away from XML we also
>>> have to move away from XML-dependent mechanisms. Such as XPath.
>>> Therefore XPath has limited capabilities in midPoint 3.x. In fact if
>>> you define a schema then midPoint will not think about the data in
>>> XML terms. It will not see XML elements any more. It does not see the
>>> document, it sees the data. It will see the data structure as
>>> multi-value structured property "group". XPath may not be applicable
>>> here.
>>>
>>> Therefore I guess this is still not the best way to represent your
>>> data. Maybe I could help you design the data structure if you
>>> describe the way how you plan to use the group data from the user
>>> object.
>>>
>>> Deepak Natarajan <mailto:dnataraj at trilobytesystems.com>
>>> May 26, 2014 at 1:32 PM
>>> Hi everyone -
>>>
>>> I am trying to achieve the following inbound mapping :
>>>
>>> from resource :
>>> "groups" : "a_1,b_2,c_3,d_4"
>>>
>>> to
>>>
>>> <user>
>>> <group id="1">a</group>
>>> <group id="2">b</group>
>>> <group id="3">c</group>
>>> </user>
>>>
>>> My custom schema extension seems to be accepted by Midpoint. I have
>>> extended the UserType to support a multi-valued child element <group>
>>> with an "id" attribute (I have a GroupType defined in my custom schema).
>>>
>>> I can achieve the simple case, without the "id" attribute. So I can see
>>> in the Admin Console that the User has several groups, which I do with
>>> the following mapping :
>>>
>>> <attribute>
>>> <ref>ri:groups</ref>
>>> <inbound>
>>> <expression>
>>> <script>
>>> <code>
>>> [parse input and return array of string [a, b,
>>> c...]
>>> </code>
>>> </script>
>>> </expression>
>>> <target>
>>> <path>$user/extension/my:group</path>
>>> </target>
>>> </inbound>
>>> </attribute>
>>>
>>> Now I'm trying to map attributes for the group element
>>> ($user/extension/my:group/@id)
>>>
>>> Has anyone tried this? Thanks for any input!
>>>
>>> BR/
>>
>> --
>> Deepak Natarajan
>> Director
>>
>> Trilobyte Systems ApS
>>
>> Falkoner Alle 1, 3 Frederikinkatu 61A, 6th Floor
>> 2000 Frederiksberg Business Center Papula
>> Denmark 00100 Helsinki
>> Finland
>>
>> Tel : +45 29375068
>> http://www.trilobytesystems.com
>>
>>
>>
>>
>> _______________________________________________
>> midPoint mailing list
>> midPoint at lists.evolveum.com
>> http://lists.evolveum.com/mailman/listinfo/midpoint
>
>
> _______________________________________________
> midPoint mailing list
> midPoint at lists.evolveum.com
> http://lists.evolveum.com/mailman/listinfo/midpoint
--
Deepak Natarajan
Director
Trilobyte Systems ApS
Falkoner Alle 1, 3 Frederikinkatu 61A, 6th Floor
2000 Frederiksberg Business Center Papula
Denmark 00100 Helsinki
Finland
Tel : +45 29375068
http://www.trilobytesystems.com
More information about the midPoint
mailing list