Disabling SAML namespaces from assertions

In response to /samlValidate requests, the CAS 3.5 release line produces SAML assertions that, when marshalized to XML, are namespaced with saml1 and samlp as the example below demonstrates:

<saml1p:Response xmlns:saml1p="urn:oasis:names:tc:SAML:1.0:protocol" 
                 IssueInstant="2013-07-31T18:20:33.499Z" MajorVersion="1" MinorVersion="1" 
                 Recipient="UNKNOWN" ResponseID="_d8ef8678d0e88699bed29ab60925e134">
    <saml1p:Status>
        <saml1p:StatusCode Value="saml1p:Success"/>
    </saml1p:Status>
    <saml1:Assertion xmlns:saml1="urn:oasis:names:tc:SAML:1.0:assertion" 
                     AssertionID="_ee20513ac051019c6da474ebead6859a" IssueInstant="2013-07-31T18:20:33.499Z" 
                     Issuer="testIssuer" MajorVersion="1" MinorVersion="1">
       <saml1:Conditions NotBefore="2013-07-31T18:20:33.499Z" NotOnOrAfter="2013-07-31T18:20:34.499Z">
           <saml1:AudienceRestrictionCondition>
               <saml1:Audience>test</saml1:Audience>
           </saml1:AudienceRestrictionCondition>
       </saml1:Conditions>
...

CAS v3.4 compliant applications that consume SAML assertions manually without the use of an official CAS client may run into issues with parsing namespaces. To generate CAS 3.4 compliant assertions, there exists a facility in cas-addons as of v1.7 that can support such applications by removing the namespace element.

Modify CAS with the following changes:

In src/main/webapp/WEB-INF/classes/protocol_views.properties, change the SAML Views to match this instead:

casSamlServiceSuccessView.(class)=net.unicon.cas.addons.response.view.saml.Saml10SuccessResponseView