NameId question

[Brewer, Edward L]

Peter,

Thanks, I am currently working on changing it to unspecified and I was considering denying transientID to this particular relying party so your advice and example is timely.  I do have some questions concerning your response that I would like to ask for clarity

Question one, your comment "Minor nit: It's not targeted, that would imply a pair-wise identifier specific to each relying party."
I pulled this definition from the wiki page NameIDAttributes 
"targeted - whether the name identifier is meant for a specific relying party, or relying party group, and not for anyone else"
So the answer to that is yes, this attribute is only for this particular relying party.  So what I am missing... and does it matter if I am only releasing this attribute to one relying party

Question two,  "... and I don't know what specifically you're doing.."  concerning use of one nameIDFormatPrecedence attribute.
For this one I was attempting to only use the one nameID for this relying party so I assumed that I should only put in what I am looking for.

Question three, " The DenyValueRule requires an IdP that's not historic, though."
I am using IdP 2.3.6... is that cool?

Thanks again for your timely responses,
Lee Brewer





-----Original Message-----
From: users-bounces at shibboleth.net [mailto:users-bounces at shibboleth.net] On Behalf Of Peter Schober
Sent: Wednesday, February 27, 2013 8:41 AM
To: users at shibboleth.net
Subject: Re: NameId question

* 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="https://test.example.org/saml" />
        <basic:Rule xsi:type="basic:AttributeRequesterString" value="https://prod,example.org/saml" />
    </afp:PolicyRequirementRule>
    <afp:AttributeRule attributeID="transientId">
       <afp:DenyValueRule xsi:type="basic:ANY" />
    </afp:AttributeRule>
    <afp:AttributeRule attributeID="concurnameid">
        <afp:PermitValueRule xsi:type="basic:ANY" />
    </afp:AttributeRule>
</afp:AttributeFilterPolicy

The DenyValueRule requires an IdP that's not historic, though.
-peter
--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net