peter.schober at univie.ac.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:
<basic:Rule xsi:type="basic:AttributeRequesterString" value="https://test.example.org/saml" />
<basic:Rule xsi:type="basic:AttributeRequesterString" value="https://prod,example.org/saml" />
<afp:DenyValueRule xsi:type="basic:ANY" />
<afp:PermitValueRule xsi:type="basic:ANY" />
The DenyValueRule requires an IdP that's not historic, though.
More information about the users