Attribute Encoders and Subjects and NameID/NameIdentifier in IdP V3

[Rod Widdowson]

This cobfused me, but I think I have it now.

What we are saying is that in V2 encoders and their configuration language
actually have two different jobs:

1) To encode attributes up in a manner which is suitable for inclusion in a
<saml:Attribute/> or whatever is apposite for the underlying protocol.  This
is non controversial.
2) To signal whatever is building the <saml:Assertion/> that "this one here
is the <NameID/>

In V3 we really want the encoders to concentrate on the first.  

For the second the current mechanism is not sufficient/confusing/wrong and
we need to develop something else which gives us the control we need, while
respecting backwards compatibility (I don't think this last need be as
terrifying as I thought it was)

If this is correct, then for now I think the solution is to concentrate on
making sure that the first is implemented and works.  I'll do the minimum to
ensure that any legacy configuration in support of the second doesn't trip
us up and make sure that we have a JIRA case to track getting it done
properly.

Rod

> -----Original Message-----
> From: dev-bounces at shibboleth.net [mailto:dev-bounces at shibboleth.net]
> On Behalf Of Cantor, Scott
> Sent: 30 April 2013 16:10
> To: Shib Dev
> Subject: Re: Attribute Encoders and Subjects and NameID/NameIdentifier in
> IdP V3
> 
> On 4/30/13 11:00 AM, "Rod Widdowson" <rdw at steadingsoftware.com>
> wrote:
> 
> >[ As an update - I went back to the encoders as they are currently
> >implemented in V3 and for some reason I hadn't noticed that there is the
> >attribute encoder I had postulated, whilst there aren't any StringNameID
> >encoders, which would argue that the design assumed that we would grow
> the
> >required extra definitions during parsing - which I find slightly sleazy
]
> 
> I think it was based on the assumption they'd be removed. Remember that
> at
> the time, we assumed compatibility would be achieved by config file
> converters.
> 
> >1) Backwards compatibility.  Given the default setup and this paradigm we
> >would end up with both the TransientId and the eduPersonTargettedId as
> >candidates for the NameID, the former by legacy and the latter as per
this
> >new design.   In this case we could choose to prefer legacy encoders over
> >no
> >encoder.
> 
> None of this pertains to how NameIDs are selected. That's already an issue
> in V2, and has a lot of messy solutions we use. That also needs to be
> cleaned up, but that's a separate conversation.
> 
> >2) Which one to select?  Assume a new default with eduPersonTargettedId
> as
> >per now and TransientId as per my previous mail (but with no encoder),
> >which
> >NameID do we chose to send in the Subject?  This would matter since we
> may
> >not have the PrincipalConnectors defined to handle all the possible
> >NameIDs
> >we generate.
> 
> Again, this is a separate matter and already affects the V2 system.
> 
> >3) How do we supress sending a <NameID/> in a <Subject/>?   This may be
> a
> >stupid thing to do, but when I was kicking the wheels with V2 yesterday I
> >achieved this by supressing the encoder on the transientId.
> 
> I would rather have an explicit control point to suppress this, then imply
> it by the absence of an encoder.
> 
> -- Scott
> 
> 
> --
> To unsubscribe from this list send an email to dev-
> unsubscribe at shibboleth.net