Shibboleth Developers

[Brent Putman <>]

Hi Halm,

On 7/21/10 1:02 AM, Halm Reusser wrote:
> 09:39:22.946 - WARN 
> [edu.internet2.middleware.shibboleth.idp.ext.delegation.profile.LibertyIDWSFSSOSProfileHandler:844] 
> - No SAML 2.0 Assertion token was available in the WS-Security context


Assuming that you've examined the SOAP message from the SP (ECP) to the 
IdP over the Liberty profile portion of the flow, and the Assertion 
token really is there in the SOAP header:

There's a minor bug which apparently never got fixed, which is that the 
error message about the missing token might be wrong and misleading.  
Here's a snippet from a thread on the delegation/uPortal list from 
that.  You need to make sure that the IdP has the proper Liberty profile 
config for the SP (ECP) in question.

> This particular error is happening because of a misconfiguration in 
> your relying-party.xml.  The portal (ECP) is identifying itself as 
> https://cmoredev.uchicago.edu/portal, but in the relying-party.xml  
> you do not have a entry for that.  You need a RelyingParty config for 
> that, containing at a minimum ProfileConfigurations for the 2 
> delegation related profiles (SSO and Liberty).
>
> Note: You do have one for: 
> https://cmoredev.uchicago.edu/portal/myCoursesStudent.php (which 
> probably isn't the best entity ID, btw).  Not sure if that's a 
> cut-and-paste typo, or if that is intended to be one of the WSP's 
> behind the portal.
> The error message about no token presented is misleading.  What's 
> happening is that there is no effective security policy running, 
> because there is no profile config for that relying party, so in the 
> profile handler there is no token that has been extracted .  The 
> profile handler is not  doing the configuration sanity checks at the 
> right time - needs to be earlier on in the flow - so I'll fix that up 
> so we get a correct error message under a misconfiguration scenario 
> such as this. 


Hope that helps,
Brent