Test multi-value concatenation in FIM and create default dn generator using the schema key

Using the format in RFC2253 and confirmed by http://msdn.microsoft.com/en-us/library/ff771507.aspx, FIM supports multi-part RDNs. I have tested this using a FIM LDIF MA and reading from a file, with a successful rename occurring. See screenshot.

On clarification with Adam, the aim is to have the DN represent a multikey as appropriately as possible. The above check was on a multi-part RDN, which Identity Broker does not currently support (and would involve a large overhaul over anything that uses the distinguished name type - engine, connectors, adapters etc.). A proposed alternative of using a "+" symbol to concatenate the values (eg. CN=Key1+Key2) results in a dn-not-ldap-conformant error in FIM.

Unsure why a "large overhaul" is required - the object model is specifically to avoid those types of issues.

CN=Key1+Key2 is not a valid RDN, so not surprise that it's non conformant.

OU=Sales+CN=J. Smith,O=Widget Inc.,C=US is the sample from the RFC that I was expecting to see the output as, and your screenshot shows that working in FIM.

Each RDN component is specifically created as an interface of the part of the RDN it represents. IDistinguishedNameComponent could easily have a superinterface extracted, such as IDistinguishedNameComponentBase and IDistinguishedName accepts the list of that. You can then retain DistinguishedNameComponent and create a new IMultiValueDistinguishedNameComponent : IDistinguishedNameComponenetBase which has a property of IEnumerable<IDistinguishedNameComponent> (to stop multi-value components being used inside multi-value components).

Happy to discuss with you and/or Adam.

(And yes, you would probably have to work on DistinguishedNameConversionFromString

Matthew, we'll have a chat today on this when you get in.

Multipart support added to distinguished name implementation. A few notes on the following DN formats:

UID=1001+O=location,DC=Test is the form of a DN containing a multipart component.

UID=1001+O=loc\+at\+ion,DC=Test

is the proper form for handling of components containing additional plus signs, and successfully converts to and from its string representation. This is detailed in the RFC, as well as in various implementation documentation (eg. Microsoft, IBM).

UID=1001+O=loc+at+ion,DC=Test throws an error as the special characters have not been correctly escaped.

In addition to a new key DN component generator being added, we have also talked about adding another generator encapsulating others and creating a multipart component (similar to what is done for composite adapters).

The key generator type has been added with UI, and creates a multipart component if there are multiple keys. Current work is on a multipart component generator

Multipart component generator has been created, but there is not currently a UI mechanism for creating it. The proposed idea was to have a check box next to each component information on the DNGeneration page, and enable groups of components to be promoted to multipart components. Deletion should be changed to work in the same way.

Recent work was on testing the editing, moving and deleting of components inside a multipart component via the interface, although this may not be functioning as expected yet.

Entity Key and Multi Part Component Generators, including UI, are functionally complete. Pending further aesthetic work. Marked as resolved. Please confirm resolution.

Reopening due to bugs found in testing that have been progressively resolved.

Moreover, having tested what happens when this goes wrong in IDBFIM-11, the UI should display more than "CN=SchemaKey" in order to make it easier to resolve cases where the provisioning logic does not match the DN configuration. This should also be passed on in the error message.

In IdentityServiceClient.GetDistinguishedNameComponent, is the first check supposed to be a null check or a type check?

Thanks.

Updating remaining estimate for updating error messages and schema display throughout, and confirmation against the FIM adapter.

The schema key generator does not seem to be being set properly even when the key is marked as required.

AvV: Please confirm. May want to show the schema key (as discussed).

Past issues confirmed as fixed, and remaining feature moved to IDB-526. Issue closed.