Altough SharePoint 2013 fully supports claim based windows authentication and SAML claim authentication, it is very important to know that using SAML claim authentication will probably breaks the BI stuff.
Indeed SharePoint Services applications like Excel Services and Power Pivot services won’t delegate SAML user identity to the back-end. Even if the SAML token contains a Windows UPN.
SharePoint 2013 internally use claim based authentication even if the authentication was not claim based (FBA, classic windows,…).
If an Excel workbook has a data model with a connection to a back-end (SQL Server relational database or Analysis Services), the user identity will be delegated to this backend only if the authentication was windows based, not SAML based.
Indeed SharePoint Service application (like Excel services) delegate use identity by using the Windows Identity Framework component C2WTS (Claim to Windows Identity), to delegate the call by extracting the windows user identity from the windows claim. But some (most?) SAML token don’t have any Windows UPN, therefore Excel Service won’t even call C2WTS in this specific case.
Be able to delegate SAML identity to the backend is one of the major weakness of the Microsoft BI stack. Even if Reporting Service supports SAML, recent SQL Server Services like SQL 2014 (both relational and Analysis service) don’t.
As workaround, the pattern I see is to have a custom backend web service taking a SAML token and generating workbooks on the fly (and storing these workbooks in secured SharePoint document libraries).
…and read this excellent whitepaper