Identity Broker wishlist

Hi Eddie,

Thanks for your requests. Adam and I's responses are below (you were right about some features already existing and I've still responded below, but we're not having a go or anything, just including for completeness and to help improve your knowledge).

"Search" entities in connector or adapter - it would be great to have an option to enter search criteria first rather than have to list all then sort.
It is probably not so bad in many sites, but DET as an example, takes an age to load 109,000 entities, which is a pain when we only want to look at one.

Agree wholeheartedly. This will likely have to be limited in some way (probably "Starts with" on any field you want, but not "Contains"), but otherwise this should be no problem.

It would also be really nice to have an option to do a limited import based on similar criteria (so as well as full import or delta import to have an option to import all sn=smith or something. That is of most use during set up and troubleshooting so maybe an "admin" feature.

I guess what would achieve the same (and be more operationally useful) would be a filter option to include or exclude specific entities - based on attributes and built up like an SQL query or an LDAP query.

Are you talking about adding a "limited import" for the adapter or the connector?

If it's for the adapter, my understand is that FIM does not support anything else. You either have to do present just the changes in the form of change records (which should already be fast enough) or present all items and anything not presented gets removed.

If it's for the connector, unfortunately most systems do not support retrieving a particular subset of data, or at least not to the level of flexibility required.

Scheduling.
The polling intervals being set in ticks is horrible, so something in seconds or minutes would be far nicer.
Better still would be some form of schedulting in the product that offers more than get full import every 30 minutes, get deltas every 5 mins etc.
Something along the lines of the scheduling that can be set up in EB would be great, but even if there was just the option to not run on certain days or between certain times.
I guess a hook into EB would work too.

Identity Broker already supports timings in hours, minutes and seconds and has for some time - see here. Some of the others you mentioned already are too. Anything that is present in Event Broker v3 and not in Identity Broker v3 has already been moved in to the Identity Broker v4 code base and will be available next version.

GUIDs
I was talking to Nick Mathas about a problem in the Novell world, where clearing the connector also clears the GUIDs which stuffs up the Novell IDM association value (unique key). He and I think this is something that needs to be addressed in the NIM adapter or the NIM end of the system rather than the IdB engine, but would there be a possibility to have a configuration item that could allow the source system unique key to be used as the IdB unique key in place of the IdB GUID?
i.e. If you do not select a unique key, you get IdB generated GUID and clearing the Connector and re-importing will generate new keys, but if you have selected that, for example, detnumber from a Chris connector should be the unique key, it will use that (relying on the source to guarantee uniqueness) and clearing the connector and re-importing will bring entities in exactly the same.

For technical reasons on our side, no, it's not possible to use the connector/adapter key in place of the IdB GUID for a number of reasons - for example, the key of the connector/adapter may change, and some connectors support the actual value of the key being changed, which would throw off the relations between objects within connectors/adapters, not to mention with external systems.

However, I completely understand the actual problem you're getting at here, and I've already made some changes to Identity Broker for NIM (as you know) which from the identity management end solves this exact problem. This will be more fleshed out in the next version of IdB for NIM with support for composite keys, etc.

Please see question regarding "limited import" option.

Hey Patrick,

Thanks for the responses. For limited import I was talking connector and I realise that it may not be doable or may only be possible for some connectors.

Where I was coming from really was the idea of either a limited run - import until we have imported 10 users type of thing, which is really useful when testing and troubleshooting - especially when we are normally dealing with hundreds of thousands of users. The other approach, which could also be useful for similar reasons, would be if we could apply some sort of filter to the import process. Such as, import all users where surname starts with "a". I realise that many systems would not support such a query, but would it be possible to get all users as we do for a standard full import and then run through a filter to discard those we do not want. Again, I am reallly looking at things that could be done to allow more rapid testing or more controlled rollout for customers with a large user base.

Cheers,

Eddie

Assigned to Adam for comment in my absence.

Hi Eddie,

With the upcoming version of Identity Broker, the limited import could not be as powerful as you may hope for, due to limitations in the data access layer, and the way in which the entities are accessed. It would be possible to limit the number of items that are retrieved, but the items would be ordered by the IdBID. This would have two negative side affects:

1. If the exported item has an IdBID that falls in the range of the other items, it would bump a previously known item out of the import.
2. If the exported item has an IdBID that falls outside the range of the other items, it would not be retrieved in a confirming import.

This option would also cause huge problems if it was turned on in PROD for example, as the partial import would be exposed as the Full Import to FIM (FIM limitation).

With the above limitations and risks, does this still seem like a useful option?

Thanks.

In view of all that, probably not, but thanks for the clear explanation.