[midPoint] Disable instead of delete

[Richard Frovarp]

Thank you for the extraordinary help. Been a long day here, but had a chance to get a decent understanding of what you've said, and even give it a bit of a test. More comments inline.

On Wed, 2020-08-26 at 10:24 +0200, Pavol Mederly via midPoint wrote:


Most probably yes. I was confused originally a little bit as well, because I do not know this part of midPoint into great depth.

This is crucial (from https://wiki.evolveum.com/display/midPoint/Disable+instead+of+Delete):

        "That means if there is a valid assignment for that account or if the account is allowed by any other policy (such as Projection Policy<https://wiki.evolveum.com/display/midPoint/Projection+Policy>)."

In your case, the default (relative) projection policy ensures that - assuming there is no change in the assignment - any existing account is considered legal. On the contrary, under full projection policy, only really assigned accounts are considered legal. (As I say, I didn't realize this fact.)

Working on getting those values correct for our different resources and how we want it to work. I understand why the default is the default for the software, but it's a confusing bit to come to on one's own. Getting this right will eliminate some of the confusion I've bumped into with other resources. For anyone else following along, I'm going with full projection policy by default, then source resources are getting a none with a legalize on them. It feels like this is touched on somewhere, probably the book(?) but it isn't coming to me right now. I'll have to review other documentation I've seen in the past.


Yes. The XML document is so large because it contains almost everything I need to analyze the situation - all evaluations of all scripts/mappings, almost all objects used, detailed logs from the processing, etc. It is so to avoid round trips with customers like "send me logs from X", then "run it again and please give me also Y and Z", etc.

And yes, it can contain sensitive information. I thought you have only a kind of playground installation, so no real data. Anyway, as you said, you managed to remove sensitive info. (You can now remove the whole file.)

BTW, here is also the reason one should use config properties for passwords, etc: such properties will not be part of these trace files, only if there would be a bug somewhere. (Unlike things that are present in resource XML objects. They are part of these files by design.)

Yeah, we're using constants from the config file for pretty much everything. There was one encrypted password in there I think for the admin account that I removed. Then there were things like my DoB and employee number that I took care of a little bit. Config properties are awesome.




This is a point I don't understand: The Target - Grouper NDSU Subjects is your target resource. You are managing its content from midPoint. And you use the content in Grouper. So far so good.

But why you use this same resource as a source for midPoint (using live sync)? Was it just for the sake of demonstration of this issue?

No. I think we had a misunderstanding on how to make such resources work.



Well, this is about what level of details you set in the trace viewer. (What kinds of operations should it show.) So if I select e.g. only an overview, I will see all the mappings, but with no particular context. If I select all operations, I will find the context but then I can get lost in the processing. (I am speaking of the viewer used in IntelliJ IDEA plugin, because I haven't used the web GUI viewer for a long time.) So, currently the viewers require some amount of midPoint knowledge to be used effectively. I hope that gradually they will be improved to be suitable also for wider audience.

But, overall, you managed to find the issue and resolution yourself, so I think it was of some help to you. :-)

Yes it was of some help. I'll have to give the IntelliJ IDEA plugin a try later this fall. I have the Eclipse one working for managing the XML, which serves me well enough for now.


---

A personal note: The analysis I have done for you is something that I really love to do. We do that regularly for our customers. I did it here just because I liked your work (e.g. the blogpost about Grouper integration) and your approach to midPoint. And I love the academy as such, being myself from this environment. But it's not sustainable - I did this on my own time (which I have almost zero, and this work was almost 2 hours for me), and now I have to return to work for our customers and midPoint development as such. So, please, do really consider purchasing a subscription. Maybe you'll be surprised that the price is not that high for HE sector. Then we would be able to cooperate in a regular way, not on "best effort" (which I have depleted for longer time now) basis. :-)



Thank you very much for this extra personal effort. It certainly wasn't expected. Higher education funding in the US is complicated right now to put it lightly. As time allows, I will be trying to actively contribute back the best I can to the community. Doesn't pay the bills right now, but hopefully will get more involved in the community. That particular blog post went up quick because I wrote it as I did it on one system, and then used it to make the correct changes on another. I have several more to write.

Thank you once again,
Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20200827/d378d77c/attachment.htm>