Configuring IdP to Work With InCommon SAML1 SPs (OhioLink)
Cantor, Scott
cantor.2 at osu.edu
Mon Feb 3 14:01:14 EST 2014
On 2/3/14, 1:47 PM, "bleb1982" <btl at fischerinternational.com> wrote:
>Thanks for all the help. Finally got it working.
>
>The reason was that there was an LDAP read implemented using DN as the
>value
>for normal SAML2 attribute resolver configurations, however, this was not
>extended down to the Attribute Query. So when it came back the LDAP filter
>was not configured correctly. What I did was created an Additional LDAP
>Data
>Connector for this particular SP which used this additional LDAP Data
>Connector doing a search with CN (which is stored in the directory). After
>making the changes the user was able to get into the SAML1 SP.
There's nothing special about queries, they operate the same way the
resolver would operate during a non-query. There's no difference unless
you are using custom name identifier types to do queries, and there's no
way OhioLink is. Or you could have a screwed up system in regards to
clustering causing problems with transient ID handling, I suppose.
-- Scott
More information about the users
mailing list