help with NameIDs

[Cantor, Scott]

> So, I've heard that NameIDs are dealt with in a completely new way with
> IdP v3; I've even heard that it's 'waaaaay easier now.'

Well, it's more explicit now instead of overloaded with attributes. That doesn't inherently mean easier. It is not explicitly meant to be less work to set up, though I think it is less work in some cases.

I think it's a wash, personally, but there are some things you can do now that weren't possible before, so it's a net positive.
 
> So, they were created in attribute-resolver.xml, and then one
> of them was always part of the release policy in attribute-filter.xml.

If you want to do that, you can do it. Nothing is going to stop that from working and it will work identically to before. The lone exception to that is the transient ID behavior, as that is no longer configured via attributes. That's the one thing that was entirely yanked out and replaced, but since that's automatic behavior, that doesn't matter much.

> Now, for v3, I see in the wiki that there could be at least four files I
> have to use to get this done.

I believe more files that are smaller and specifically targeted is better. All of V3 reflects that. If you like larger files that are used to do more things at once, you will not like the differences.

> There's still the attribute-resolver where
> the ePPN gets created.  Then, there's the saml-nameid.xml file where the
> NameID generators are enabled and the NameIds are generated.

Right. Again, purpose-specific (and the assumption is you already have EPPN or something like it, so you're not *also* touching the resolver here, you're using what you already did there). In other words, to configure a NameID, you edit a file for generating NameIDs. It just may happen that you want to source a NameID from an attribute, and that might mean going to the attribute files.

> But, what properties would that be if I just wanted to assign an ePPN value to a NameID?

None. There are no properties related to anything but transient and persistent formats. Nothing as delivered anyway, obviously you could create your own.

> And, finally (?), since I mentioned a NameID with an unspecified format I
> think I've seen where that now requires something in the relying-party.xml
> file to trigger a profile configured with an appropriate
> nameIDFormatPrecedence property.

It has always required that since very early in the V2 lifecycle. If you weren't doing that, you had a system that was working solely by accident before. There were very early mistakes made in the way formats were selected and once we made that explicit and controllable, that was how you did it. That is a compatible behavior between V2 and V3.

> So, I think I've found references in the wiki for each specific part of
> handling NameIDs in v3, but I'm clearly missing something about how all
> these pieces 'fit together'.

The key pieces are:

How does the Format to use get determined?
Same as V2: NameIDPolicy from SP, NameIDFormat in metadata, and nameIDFormatPrecedence in relying-party.xml (and unspecified only works with the last one)

How do I generate the different kinds of Formats?
This is covered in detail for three different cases in the wiki under NameID generation: transient, persistent, and "custom", with custom being a catch-all for anything that's not the first two.

> And, what about this stuff that
> needs added to the relying-party.xml file?  Can this new, version 3 bean
> to configure a profile to trigger the nameIDFormatPrecedence property just
> be added somewhere into an existing, legacy relying-party.xml file like
> you'd have after doing an upgrade?

You wouldn't need to. V2 already supports that feature and you'd set it in your legacy/old relying-party file in either version. Again, if you're not using that to select the unspecified Format, you have a broken configuration. That goes for V2 or V3. You're getting something that works by accident because of some kind of filter rule that happens to be winnowing out the possible NameID-compatible attributes, but that only works in V2 and it only works by accident.

-- Scott