Identity Broker support for exporting to reference attributes (dns)

Bob,

I should just clarify, as it is not mentioned on this issue. Are you still referring to writing back to constructed dn field, not regular reference fields? Because reference fields can be written back to.

Thanks.

Yes Adam, although I'm trying to imagine what non-constructed reference fields would look like because I've never seen these configured with FIM. I guess you could argue that the anchor itself is a reference, in which case I know CRUD works for that, but if I had a database connector for say "person" with say a guid FK to "role" (i.e. RoleID) I only know how to make sense of that relationship using an adapter-constructed dn. If I then wanted FIM to be able to alter that role relationship I don't know how I'd write back a new guid to RoleID ...

Hey Bob,

Thanks for the issue, definitely an interesting idea. I can see this as a nice to have, but there's significant performance implications that I think would make this technically infeasible.

Firstly I just want to make sure I've understood what you're explaining here, so i'll come up with my own definition:

1. If I update the actual DN itself, this will have an effect on the underlying data
2. If I update a grouping of DNs that are generated through a membership, that will have an effect on the relative members.

The only way to achieve this is to have backlinks from the 'meaning' of the DN (values, and whether its a member) to the DN instance. What I mean by that, is if I have relational data in my DN, then I need to have a backlink to define that relationship.

That's going to be an unavoidable performance hit if we went ahead and did it, and you wouldn't be able to turn it off. People not using this feature would hurt for it.

The alternative is just to update the values, and then delta import to update the DN which is how it's achieved right now. Where this can get a little tricky is that the values can be in a relational connector, meaning you have to have the capacity to update a related object class in FIM.

An easier way would be to be able to edit the related data of relationship in the single adapter. I think that the capacity for updating relational data from adapters (that reference them through Relational

transformations) is interesting.

Talked with both Adam and Matt before and we all agree it might be technically feasible, so we've created an issue:

IDB-940

But as for updating collections of DNs, or the DNs themselves, and having an effect is technically infeasible.

Some of the power behind IDB is that DNs only matter in what creates them, and what reads them. They mean nothing outside of their incidental usage in the identity management systems.

This would hurt performance significantly and systematically, there wouldn't be a way to turn it off, and the implementation effort required just wouldn't justify it.

If you have any thoughts on updating relational data through a single adapter feel free to comment on the above issue.

Thanks

Hi Bob,

I'm assigning this to you for Tony's comment. Could you please close this issue once you have acknowledged it?

Thanks.

Thanks Tony Sheehy and Adam van Vliet - if I understand this correctly, DNs should remain read-only because of context and performance reasons, and if updates are required to the underlying data this should be done via a secondary adapter. If this is correct then please close. The "nice to have" aspect of this request doesn't go away, but clearly understanding the constraints for now is enough.

Tony - please close if I have got this right.

Thanks Bob that's right.