Problems setting up ADFS and Shibboleth
Steven Barnhart
SBarnhart at esue.ohio-state.edu
Wed Dec 21 22:09:18 GMT 2011
Okay, thanks for pointing me in the right direction Scott. I got it working, but had to change signResponses to "conditional". Does that make sense?
<rp:ProfileConfiguration xsi:type="saml:SAML2SSOProfile" includeAttributeStatement="true"
assertionLifetime="PT5M" assertionProxyCount="0"
signResponses="conditional" signAssertions="always"
encryptAssertions="conditional" encryptNameIds="never"/>
--Also, to Paul - I read that guide and that's what I had started off following. One specific section seems to be wrong as it stops Shibboleth from working (around Step 4) in the AttributePolicy snippet of attribute-filter.xml, I had to change <AttributeFilterPolicy> to <afp:AttributeFilterPolicy> and the other tags of that section.
Steven Barnhart
Systems Specialist
Enrollment Services & Undergraduate Education
The Ohio State University
sbarnhart at esue.ohio-state.edu
-----Original Message-----
From: users-bounces at shibboleth.net [mailto:users-bounces at shibboleth.net] On Behalf Of Cantor, Scott
Sent: Wednesday, December 21, 2011 4:56 PM
To: Shib Users
Subject: RE: Problems setting up ADFS and Shibboleth
> Exception details:
>
> ID4152: The Saml2SecurityToken cannot be validated because the
> IssuerToken property is not set. Unsigned SAML2:Assertions cannot be
> validated.
I don't know that I'd take it literally at its word, but if it really is complaining that the IdP isn't signing the assertion, you can fix that by adjusting the properties on the SAML 2 profile handler in the relying-party.xml file. But the default in the current versions is to sign the assertion, so that doesn't seem likely to help.
And there's no way the resolver change would have any impact on how the SAML trust processing is done by ADFS, so I'm not sure what you're seeing.
-- Scott
--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
More information about the users
mailing list