[midPoint] How is it possible to create a new object
Andreas Küstner
andreas.kuestner at daasi.de
Fri Jun 24 09:11:46 CEST 2016
Hello Radovan,
thank you for your good explanation!
We do a research here to compare some of the well known IDMs, and yes
your right, i've tried to get a similar approach in MidPoint like in the
"other" IDM.
So i will try to go the MidPoint way.
Thanks again for this good information!
Andy
Am 23.06.2016 um 17:20 schrieb Radovan Semancik:
> Hi,
>
> Yes and no ...
>
> MidPoint philosophy is to have an handful of very generic reusable
> object types. Such as user, org, role, service. These objects can be
> used to represent almost any concept in the IDM field. E.g. role can
> represent security roles, work positions, responsiblities; org can
> represent functional organizational units (divisions, sections), but
> also projects or ad-hoc teams. Services can represent devices, servers,
> networks, etc. Each object has appropriate typing property (roleType,
> orgType, ...) that can be used to distinguish these subtypes and sill
> have very efficient data storage, scalability, etc. My estimate is that
> 90% of all IDM use cases can be implemented by using this method. E.g.
> your costcenter can be modeled as a role or org in midPoint. This is
> also somehow well supported in GUI, especially for organizational units
> (not so well for roles yet).
>
> In addition to that every focal object (user, role, org, service) can
> have assignments. Assignments represent policy-base relations between
> objects. Assignment is also an extensible data structure and it can have
> custom properties. Therefore your Employment object can be represented
> as assignment. In fact assignment already has description and
> organizational unit link. Parametric assignments like these work
> perfectly in midPoint core and we are using them is several projects.
> However they are only partially supported in GUI.
>
> We have decided to go this way because if you base your data model on
> existing concepts you will automatically gain all the advantages that we
> have already implemented. E.g. if you base your Employment concept on
> assignment you will automatically gain ability to create new employments
> in GUI, you will be able to use authorizations to select which
> employment types are assignable by which employees (operators), they
> will be automatically considered in reconciliation code, etc. This saves
> a huge amount of customization effort.
>
> Maybe it is just me, but I can feel the taste of one particular
> competing IDM system in this question :-) ... and that's right, midPoint
> does not have such an extreme flexibility. But we have a working GUI
> that you can just reuse and you do not need to develop a completely
> custom GUI by yourself, you do not need to reimplement the
> synchronization logic for each object type and so on. We strongly prefer
> reuse of code and concepts over reinventing everything from scratch for
> each and every deployment.
>
> Yet, there are two more alternative ways:
>
> Your Costcenter concept is very simple and you can implement is as a
> simple lookup table. This is reasonably well supported out-of-the-box
> although it is not well documented. So I have written a very basic
> documentation here:
> https://wiki.evolveum.com/display/midPoint/Lookup+Tables
>
> Second option is to use the GenericObjectType. This object type was
> designed to cover the remaining 10% of cases. But actually it looks like
> it almost never used. I assume that the reason is that all practical
> cases can be modeled using the normal midPoint approch. And as nobody is
> asking for better GenericObjectType support then naturally the midPoint
> support for GenericObjectType is very ... minimal. It should work well
> in midPoint core, however it is not very well tested and it is not
> supported in the GUI at all.
>
> I would strongly recommend to use the common midPoint approach, model
> your Employment as an assignment, model your Costcenter as a lookup
> table or a role. If there are some parts that you are missing in
> midPoint GUI we will be happy to implement them given the right
> motivations. I would recommend you to secure appropriate subscription
> which can cover the development of the missing part. Or maybe to sponsor
> the missing features or to develop them yourself and contribute them.
>
More information about the midPoint
mailing list