Filter might not be enough, because SAML Authentication is based on multiple redirects: from service provider to identity provider and back. And filters in REST-assured are working above HTTP Redirects.
Also, SAML Authentication may involve manual steps in the middle of those redirects: Identity Provider discovery might be either automated or manual [2] and process of authentication is specific to selected Identity Provider.
In general, SAML protocol does not constrain Identity Provider to certain authentication method. It only requeries Identity Provider to handle SAMLRequest form service provider and respond back with SAML Response. Then service provider exchanges SAML Response for authentication token that is specific to a given service provider. SAML also does not constrain what authentication token should be included in requests to Service Provider.
What I have described above is only one of the bindings SAML 2.0 offer. It's called Service Provider Redirect POST Binding [1]. SAML 2.0 provides also other bindings and you SUT may actual support them. In sum, SAML 2.0 is pretty complex authentication protocol.
I have implemented a rough solution for the binding I discussed abot at my work. It does the job but it hard from perfect. If you don't need to handle full flow, you could mock Identity Provider (.e.g, with mock-server) that responds with SAML Response to service provider.
[1]: http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0-cd-02.html
[2]: http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-idp-discovery.html