Verification of SubjectLocality by the SAML extension

[mpr]

I'am using the SAML Extension in our web application and it's usually working very well.

A few days ago we had to authenticate against a new Shibboleth Identity Provider that is externally provided.

This provider sends an AuthnStatement including a SubjectLocality like

   <saml2:AuthnStatement AuthnInstant="2011-02-01T11:05:56.628Z" SessionIndex="..." xmlns:saml2="ur
n:oasis:names:tc:SAML:2.0:assertion">
      <saml2:SubjectLocality Address="10.10.0.30"/>
      <saml2:AuthnContext>
         <saml2:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Pass
wordProtectedTransport</saml2:AuthnContextClassRef>
      </saml2:AuthnContext>
   </saml2:AuthnStatement>

In this case the authentication did not work because the WebSSOProfileConsumerImpl.verifyAuthenticationStat ement() fails in

        if (auth.getSubjectLocality() != null) {
            HTTPInTransport httpInTransport = (HTTPInTransport) context.getInboundMessageTransport();
            if (auth.getSubjectLocality().getAddress() != null) {
                if (!httpInTransport.getPeerAddress().equals(auth.getSubjectLocality().getAddress())) {
                    throw new BadCredentialsException("User is accessing the service from invalid address");
                }
            }
        }

In my case auth.getSubjectLocality().getAddress() = 10.10.0.30 and httpInTransport.getPeerAddress() = <IP of my client pc> and these two IP's are not equal. 10.10.0.30 seems to be a private address in the system of the IDP and the other address is from my client PC. These two can never match.

I wonder if the IDP has a faulty setup or if the validation function of the SAML library makes a wrong assumption.

Unfortunately the oasis documentation only has a very brief description for the SubjectLocality and it does not tell me what address should be used here.

I would appreciate any comment on this matter.

[ScottCantor]

Address checking is optional in SAML SSO, because of NATs and proxies, so SP implementations either don't check addresses, or they have options to bypass the check.

[jamescox]

I am not overly familiar with the SAML Extension. But, if the extension is trying to validate the address of the client, it should be using the Address attribute of the SubjectConfirmationData as outlined in 4.1.4.3 of saml-profiles.

[ScottCantor]

I am not overly familiar with the SAML Extension. But, if the extension is trying to validate the address of the client, it should be using the Address attribute of the SubjectConfirmationData as outlined in 4.1.4.3 of saml-profiles.

Yes, that's true. Same issue would apply, though, and if the extension can't be told to skip the check, it will be unusable in these scenarios.

[mpr]

Thanks for your feedback.

I also thought that the checking should be optional, but I wanted to get some opinions before creating an issue in the tracker.

Encouraged by your posts I will do this now.

[vsch]

You're right Martin, in this case the values can never match. In my opinion the server is sending a wrong value, the field should contain "IP address for the system from which the assertion subject was authenticated" which I so far interpreted as "IP of the client computer".

But anyway, the SubjectLocality is just an advisory field and Scott is absolutely right that the value can be wrong due to other reasons. I'll remove the check/make it optional in the next release.

And thanks for opening the Jira issue.

[robmoore]

I can't find the JIRA referenced in this thread. I'd appreciate the issue ID if anyone knows it. Thanks!

[vsch]

It's SES-66 - https://jira.springsource.org/browse/SES-66

-- Vladimír