PrincipalName dependencies

Tom Poage tfpoage at
Tue Sep 13 21:11:26 BST 2011

I'm having a little trouble ironing out how to get a principal name rule
(cf. to compose NameID) to fire in the attribute resolver, and it seems
to hinge in my config on whether (or not) an LDAP entry exists.

All but a couple of attribute definitions are listed as dependent upon
on a particular LDAP DataConnector:

<resolver:AttributeDefinition ....>
  <resolver:Dependency ref="LDAP1"/>
[lots more definitions that depend on LDAP1]
<resolver:DataConnector id="LDAP1" ...

A couple of attributes depend on a different LDAP data connector:

<resolver:AttributeDefinition ....>
  <resolver:Dependency ref="LDAP2"/>
<resolver:DataConnector id="LDAP2" ...

(both LDAP connectors use the typical "$requestContext.principalName" in
the search filter)

Then, for a particular application, I have:

<resolver:AttributeDefinition id="princ" xsi:type="ad:PrincipalName" />

<resolver:AttributeDefinition id="mynameid" xsi:type="ad:Template">
  <resolver:Dependency ref="princ"/>
  <resolver:AttributeEncoder xsi:type="enc:SAML1StringNameIdentifier" />
  <resolver:AttributeEncoder xsi:type="enc:SAML2StringNameID" />

These last two definitions don't depend on an LDAP entry.

The thing I'm puzzling over is when an entry exists in LDAP1, the
"mynameid" attribute is properly delivered as a SAML NameID, but when an
entry does not exist in LDAP1, the "princ" rule never fires and the name
identifier is not inserted into the SAML Response.

    SPNameQualifier="theirsp">foo at adomain</saml2:NameID>



Hints at what am I might be missing? Something backwards?


More information about the users mailing list