NameId question

Peter Schober peter.schober at
Wed Feb 27 09:40:33 EST 2013

* Brewer, Edward L <lee.brewer at Vanderbilt.Edu> [2013-02-27 15:08]:
> Good question and sorry for the delay.  Ultimately the choice of
> transient is not the best and I am working on how to classify the
> name-id format.  By definition this nameID format is transparent,
> permanent, targeted, non-revocable, and non-reassignable.

Minor nit: It's not targeted, that would imply a pair-wise identifier
specific to each relying party.

I see why it's easy to get it working the way you did because the IdP
already has rules to release transient NameIDs. Still I'd consider
that incorrect (even though using "unspecified" won't get you any new
features or anything).

The nameIDFormatPrecedence attribute does work (I have an actual
precedence list with several values in my DefaultRelyingParty; not
sure what it does with only a single value in it) and I don't know
what specifically you're doing (something else might fail even before
the precedence is being evaluated), but there are other ways to
achieve the release of this id instead of transient.
IMO the easiest one is having a specific rule for this RP in the
attribute filter with a DenyValueRule for the transientId attribute,
and PermitValueRule for your custom "concurnameid", something like:

<afp:AttributeFilterPolicy id="weirdId">
    <afp:PolicyRequirementRule xsi:type="basic:OR"> 
        <basic:Rule xsi:type="basic:AttributeRequesterString" value="" />
        <basic:Rule xsi:type="basic:AttributeRequesterString" value="https://prod," />
    <afp:AttributeRule attributeID="transientId">
       <afp:DenyValueRule xsi:type="basic:ANY" />
    <afp:AttributeRule attributeID="concurnameid">
        <afp:PermitValueRule xsi:type="basic:ANY" />

The DenyValueRule requires an IdP that's not historic, though.

More information about the users mailing list