Shibboleth Developers

[Chad La Joie <>]

Can you attached your IdPs metadata?  I think I know what the issue is
but I need to see that to confirm it.

Rod Widdowson wrote:
> 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...

-- 
Chad La Joie             2052-C Harris Bldg
OIS-Middleware           202.687.0124