Shibboleth Developers

["Rod Widdowson" <>]

Thanks for Will for putting me onto this.

After some experimentation and code walking here is my understanding.  I'm 
hoping that Chad and others will shoot me down...

The <NameIdentifier> which precede's the <Assertion> and the 
<AttributeStatement> is populated from the attributes (neat idea!).

The way you tell the resolver that this is an atribute which can be put into 
<NameIdentifier> is by defining an AttributeEncoder of type 
"SAML1StringNameIdentifier" (for SAML1, it looks as though it's 
"Saml2StringNameID" for SAML2).

What can cause confusion is that when the IdP issues the <Assertion> it 
looks for a nameFormat of 
"urn:oasis:names:tc:SAML:1.0:nameid-format:unspecified", but when it issues 
the <AttributeStatement> it is looking for a nameFormat of 
"urn:mace:shibboleth:1.0:nameIdentifier".

to get around this I added the following

       <resolver:AttributeEncoder xsi:type="SAML1StringNameIdentifier" 
xmlns="urn:mace:shibboleth:2.0:attribute:encoder"/>

to my attribute-resolver.xml (for principal - I haven't had a chance to play 
with using a transient as the NameIdentifier yet).

What suprised me is that attributes of type SAML1StringNameIdentifier are 
issued as "normal" attributes as well (or are, if they are the only SAML1 
attribute encodings defined)
Further, if I define an attribute with encoding "SAML1String", it seems to 
forget its name

<saml:Attribute 
AttributeNamespace="urn:mace:shibboleth:1.0:attributeNamespace:uri">

But I've not spent much time chasing that so its probably a misconfiguration 
on my part - I'll get onto this this afternoon...