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 :)


SharePoint Claims Based Authentication Architectures Explained Part 8 Design Principles for Claims Based Applications

It can prove to be difficult to give guidance in the area of designed claims due to the fact that they work independently off of a given application. This next section is going to help answer questions you may have though and to offer a look at some different approaches you may want to consider implementing.

The Fundamentals of a Good Claim

There isn’t always a clear answer when it comes to the design for claims based applications. This is why it is important for you to understand the different variables and the tradeoffs that each one of them can offer you. With these examples though you should get a solid understanding of what types of elements need to be present in order for you to have a good claim.

The email address of the user is one thing to consider. When you have a candidate for a claim in a given system an email address is a good way to identify them. Just about everyone out there has an email for business purposes and it will be required for you to federate identity across realms. With an email name, you will be able to get your system personalized for each user.

There is some personalized data that can be used too. For example a user may have a specific skin or theme that they wish to use for a website. This is also a type of date that is specific for a given application. Choosing a skin or a theme here doesn’t make sense because it isn’t part of the users identity according to the verification process. Therefore this should be managed as a whole rather than individually.

There are users that will have permission to access date in your application. It can make sense to model permissions as claims but you nee to realize that soon you may end up with too many of them within your levels of authorization. A better way to handle such issues is to develop a boundary that will separate the authorization data from claims and that which you can handle another way.

A good example is that you have a cross realm federation that can be a benefit by allowing realms to be authorized for high level roles. The application will map these roles into fine detailed permissions with various tools. A common one used is Windows Authorization Manager. You do need an issuer that is designed to handle this fine detailed permission process though so that you can keep your claims at a higher level.

Here are a couple of questions that you need to ask before you go about attributing a claim:

  • Is the data going to be a core part of what I use for identity?
  • Will the date be used by only one application or several?
  • Will an issuer manage this data for me or should I have it handled directly through my own application?