Configuring IdP to Work With InCommon SAML1 SPs (OhioLink)

[bleb1982]

I am trying to get configuration for OhioLink up and running. OhioLink
consists of about 4 SPs. Most of them use SAML2, but one of them
(proxy.ohiolink.edu (i believe)) is still using SAML1 which is trying to do
a pull of the attributes. However, I cannot seem to get this to work. Here
is my configuration 

1) IdP is front ended by Load balancer with a VIP configured for 443 traffic
and off loading SSL for normal requests. 
2) IdP is front ended by Load Balancer with a VIP configured for 8443
traffic and this is doing a pass through (no ssl offloading) 
3) Relying Party is: 

        <rp:RelyingParty id="urn:mace:incommon" 
                provider="https://sso.cedarville.edu/idp/shibboleth"
                defaultSigningCredentialRef="IdPCredential">
                <rp:ProfileConfiguration
xsi:type="saml:ShibbolethSSOProfile" 
                        includeAttributeStatement="true" />
                <rp:ProfileConfiguration
xsi:type="saml:SAML1AttributeQueryProfile" />
                <rp:ProfileConfiguration
xsi:type="saml:SAML1ArtifactResolutionProfile" />
                <rp:ProfileConfiguration xsi:type="saml:SAML2SSOProfile"
encryptAssertions="never" encryptNameIds="never" />
                <rp:ProfileConfiguration
xsi:type="saml:SAML2AttributeQueryProfile" />
                <rp:ProfileConfiguration
xsi:type="saml:SAML2ArtifactResolutionProfile" />
        </rp:RelyingParty>

I am getting that it still seems like the Attribute Request that is coming
in, it is having the IdP push the attribute like SAML2 still.



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