MSIS1001: The SAML authentication request element 'Scoping' is not supported.

Question

I have a case where the SP is supplying a Scoping element in an authentication request via a browser and we're seeing this error in the event viewer:

 

The Federation Service encountered an error while processing the SAML authentication request.
...
Exception details:

Microsoft.IdentityServer.Web.UnsupportedSamlRequestException: MSIS1001: The SAML authentication request element 'Scoping' is not supported.

 

Here's the request:

 

<?xml version="1.0" encoding="UTF-8"?>
<saml2p:AuthnRequest xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" AssertionConsumerServiceURL="https://sp.example.com:443/spring-security-saml2-sample/saml/SSO" Destination="https://idp.example.com/adfs/ls/" ForceAuthn="false" ID="age66173g7ii1gb3jhc11hhfgg9203" IsPassive="false" IssueInstant="2010-03-26T21:15:46.221Z" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Version="2.0">
	<saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">https://sp.example.com:443/spring-security-saml2-sample</saml2:Issuer>
	<saml2p:Scoping ProxyCount="2">
		<saml2p:IDPList>
			<saml2p:IDPEntry Loc="https://idp.example.com/adfs/ls/" ProviderID="http://idp.example.com/adfs/services/trust"/>
		</saml2p:IDPList>
	</saml2p:Scoping>
</saml2p:AuthnRequest>

The message seems pretty clear here but I just thought it might be worth checking that there's not something that can be done to address this. It's unclear to me whether the SP should expect that this might occur and fallback to some other behavior or if it's the case that the standard recommends or requires this element be supported for this profile.

Thanks,

roborative

 

Answer 1

Hi roborative,

Correct - AD FS does not support the Scoping element.  The SP will need to send the request without this element for it to succeed.

Can you expand on the scenario you're trying to achieve?

Thanks,
Colin

Answer 2

Thanks for the reply, Colin.

I'm using ADFS as the IDP and our SP is using a 3rd party SAML library (Spring Security Extensions: http://static.springsource.org/spring-security/site/extensions.html) which utilizes the OpenSAML library. It appears that the Spring Security Extensions implementation assumes that the IDP will support scoping. I've been attempting to determine if that's a valid assumption in terms of the SAML standards and, if so, if there's a way to know from the IDP metadata whether scoping is supported or not so that the code could work out whether it should send a scoping element or not. I've seen references to the effect that the IDP should support the lack of a scoping element but nothing suggesting that it must support the presence of one.

Rob

Answer 3

I'm curious if there's a rationale to not supporting scoping. I'm thinking that it's not supported by design rather than because of the work involved and would like to understand why, if so.

Thanks,

Rob

Answer 4

The SAML specification does not directly address this issue, but a relying party are not obligated to adhere to the Scoping element. Hence this element should be ignored if not understood. I do not think that replying with an error in this case is the correct behaviour.

Answer 5

So in the case where the SP can't (or won't) make the change, has anyone seen ways to strip that out or otherwise 'fix up' the request? 

---

Frank C. Drewes III - Senior Consultant: Oxford Computer Group

Answer 6

I had the same issue and ended up writing an HttpModule that decoded the SAMLRequest, removed the scoping element, re-encoded, and did a HttpContext.Current.RewritePath.  It's not pretty but that was the only option and it seems to work.  I agree that the Scoping element should be ignored.  Decoding/encoding the SAML request was more complex than I anticipated.  To decode (get request) you need to:

1. URL decode SAMLRequest query string param

2. Convert to string from base64

3. Zlib decompress the message.  I used http://dotnetzip.codeplex.com/ to do this.

To encode the message you just reverse the steps.

Answer 7

The correct behaviour is to ignore the element, as long as you are not proxying the request. In that case you have to respect the ProxyCount attribute if present.

In this case it is not correct to display an error to the user. You should either ignore the element and proceed your normal flow or return a urn:oasis:names:tc:SAML:2.0:status:NoAvailableIDP or urn:oasis:names:tc:SAML:2.0:status:NoSupportedIDP StatusCode (assuming we are using the Web SSO profile).