SharePoint And ADFS: SecurityTokenException – The issuer of the token is not a trusted issuer

This is a pretty common ADFS error, and there are all sorts of reasons that it could happen.

The stack trace will be this:


Microsoft.SharePoint.IdentityModel.SPTrustedIssuerNameRegistry.GetIssuerName(SecurityToken securityToken)

   at Microsoft.SharePoint.IdentityModel.SPPassiveIssuerNameRegistry.GetIssuerName(SecurityToken securityToken)

   at Microsoft.IdentityModel.Tokens.Saml11.Saml11SecurityTokenHandler.CreateClaims(SamlSecurityToken samlSecurityToken)

   at Microsoft.IdentityModel.Tokens.Saml11.Saml11SecurityTokenHandler.ValidateToken(SecurityToken token)

   at Microsoft.IdentityModel.Web.TokenReceiver.AuthenticateToken(SecurityToken token, Boolean ensureBearerToken, String endpointUri)

   at Microsoft.IdentityModel.Web.WSFederationAuthenticationModule.SignInWithResponseMessage(HttpRequest request)

   at Microsoft.IdentityModel.Web.WSFederationAuthenticationModule.OnAuthenticateRequest(Object sender, EventArgs args)

   at System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()

   at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)


At the end of the day though, don’t sit around and fiddle with the SharePoint trusted authorities and yada yada yada, it boils down to a certificate problem. Basically the one that was specified as the signing certificate, when exported during the ADFS setup, is either malformed (the certificate chain is incomplete) or plainwrong wrong when the trusted issuer was being built up in SharePoint ala powershell. So to get around the error follow two pretty basic steps.

  1. Verify the appropriate certificate chain is present on the SharePoint server in both the trusted root authorities as well as in the SharePoint folder within the Certificate MMC snap-in. Never ever, ever delete the self issued ones that SharePoint provisioned within that folder. You will cause a Micheal Bay-spolosion. To verify the chain, just popup open the certificate details within some interface (like, the MMC :) ) doesn’t really matter what and verify that the chain is trusted and existent.
  2. Next, verify that you actually used the right certificate when specifying the certificate path when building the System.Security.Cryptography.X509Certificates.X509Certificate2 object to pass into your SPTrustedIdentityTokenIssuer. This is pretty easy to mess up when troubleshooting if you are swapping certs all over the place.

Both of these are in place, then that error will go away. Not that another won’t popup :)


Industry Standards for SharePoint Claims Based Authentication Cheat Sheet

Here is some quick reference material when reading through the claims stuff on the site to help with some of the terminology.

SAML Security Assertion Markup Language

The SAML is an XML based standard and it allows for the exchanges between authorizing and authenticating data that is sent from an issuer to an application. There are several functions of the SAML but the main one is to offer a way for the web browser to be used with a one time sign on process. This is acceptable because the SAML sees that the user has an identity in place and it can be authenticated.

Yet the SAML won’t be able to specifically tell you how to go about implementing these types of services. It really isn’t concerned at all about how the authentication process is implemented. Of course that isn’t the case when you are talking about the individual applications involved. Any application is going to rely on the issuer to successfully identify who the user is.

Once the user requests it, the SAML will apply the policies and rules that are in place. A decision will be made once everything has been assessed.


The purpose of the WS-Federation is to extend the WS-Trust so that the structure of the identity can be created at the core. It is also there to help separate the trust from the security for the tokens. This means that a given service model can be offered to provide security to the protocol address for the web applications and web services regardless of the types of trust relationships you are talking about.

These features are offered for direct use to the clients of SOAP and web services. The WS-Federation is where the syntax for the WS-Trust protocol and the WS-Federation extensions take place in the browser use environment.

There is also the WS-Federation Passive Requestor Profile that is a web based service that works directly with the WS Federation. The details of it show how applications are able to make requests. This includes the use of web browsers which are often referred to as passive due to the way in which they go about making such a request.


WS-Security offers a method of communication so that the security can be successfully put into motion. It was originally designed through the joint efforts of VeriSign, IBM, and Microsoft. Today there is a committee called the Oasis Open that oversees it. This protocol is very important as it helps to get the rules followed for the confidentiality to be enforced. This includes the use of the SAML, X 509, and Kerberos.

This also is attached to signatures so that they can be encrypted with headers that are SOAP messages. To attach security tokens and certifications to messages the WS-Security has to be in place. It works in all of the layers of the application too so that there is security in place from start to finish for each of them.


The WS-Trust is actually an extension of the WS-Security. However, the specific areas that it covers include the issuing, renewing, and then validation process of the tokens for security. It also allows for the various trust relationships to be securely exchanged through messaging. Using the WS-Trust, applications are able to secure that effective communication is in place.


Adam Likes SAML

Indeed I do. So much, I will be writing a series of articles dedicated to SAML and SharePoint integration. Well, I don’t know if it will be a series in order, but I wrote a large shared class library for general SAML / SharePoint functionality that will help you write SAML applications for SharePoint / that target SharePoint, and I will be writing articles around how to use the base class library. Some of the articles will be going over what SAML is, how it used in business cases, and others will be 100% dedicated to SAML / SharePoint functionality.
I think people will find this concept interesting since it really expands the level of SharePoint security mechanisms that you can introduce into your environment. If you have any ideas about SAML / SharePoint integration, needs, or general ideas that you would like to see, it would be sweet to hear about em.