By using the SAML token in the client, it is possible to set up the principal and identity objects also on the client side, which will make it possible for the client to also ask for if a user belongs to a certain role and so on. The problem though is that the client cannot deserialize the SAML token if not using asymmetric key pairs.
I first tried to use asymmetric key pairs and it worked fine for the client to call the STS, decrypt the SAML token, use it in the client and also call the business service. But the problem with this model is that the client hangs on the private key used to encrypt the token when calling the business service. This is a problem if the business service needs to call another business service with the SAML token attached, because then the business service is not able to encrypt the SAML token. Asymmetric keys are also less secure since the client needs to hold a reference in memory to the private key (almost comparable with needing to hold a reference to a username/password in memory).
My original plan was to base the principal object on the SAML token, but since it isn't possible to deserialize on the client side I could not. Instead I will have to base the principal object on a SecurityToken and a list of claims. It is the claims that contains the information valuable for the principal object (for example roles) and the claims can be manually constructed from the SAML token.