Configuring IdP to Work With InCommon SAML1 SPs (OhioLink)

[bleb1982]

Yes, I understand I found the issue, but the question is what could cause
this. The initial attribute resolving process gets the DN, Serach Filter,
etc just fine, then when it comes back via the attribute query request, it
has the principal name but the DN and Search filter come back as null. How
does the DN of the dn to be searched and the filter get created?

Resolving attribute uid for principal pamccain
07:50:22.393 - DEBUG
[edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.ShibbolethAttributeResolver:360]
- Resolving data connector Fisc_Shib_LDAP for principal pamccain
07:50:22.393 - TRACE
[edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.dataConnector.TemplateEngine:114]
- Populating velocity context
07:50:22.393 - TRACE
[edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.dataConnector.TemplateEngine:88]
- Populating the following shibboleth.resolver.dc.Fisc_Shib_LDAP template
07:50:22.394 - DEBUG
[edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.dataConnector.LdapDataConnector:340]
- Search filter: null
07:50:22.394 - DEBUG
[edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.dataConnector.LdapDataConnector:351]
- Performing LDAP read.  DN:null
07:50:22.394 - DEBUG
[edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.dataConnector.LdapDataConnector:441]
- LDAP data connector Fisc_Shib_LDAP - Retrieving attributes from LDAP



--
View this message in context: http://shibboleth.1660669.n2.nabble.com/Configuring-IdP-to-Work-With-InCommon-SAML1-SPs-OhioLink-tp7594414p7594560.html
Sent from the Shibboleth - Users mailing list archive at Nabble.com.