When a user browses to a relying party (RP) application in which the IP-STS or RP-STS is
AD FS 2.0, the user provides credentials to the STS and subsequently fails before the STS response is posted either to the RP or the RP-STS (depending on your deployment scenario).
Event Viewer shows Error Event 111 in the AD FS 2.0/Admin log with the following detail:
The Federation Service encountered an error while processing the WS-Trust request.
Request type: http://schemas.xmlsoap.org/ws/2005/02/trust/RST/Issue
System.ArgumentException: ID4216: The ClaimType '<some-value>' must be of format 'namespace'/'name'.
Parameter name: claimType
at Microsoft.IdentityModel.Threading.AsyncResult.End(IAsyncResult result)
at Microsoft.IdentityModel.Protocols.WSTrust.WSTrustServiceContract.ProcessCoreAsyncResult.End(IAsyncResult ar)
at Microsoft.IdentityModel.Protocols.WSTrust.WSTrustServiceContract.EndProcessCore(IAsyncResult ar, String requestAction, String responseAction, String trustNamespace)
If you test this scenario using IDP-initiated sign-on, you may find that access to the RP works with no error.
The URL to test IDP-initiated sign-on to
AD FS 2.0 is: https://<sts-DNS-name>/adfs/ls/idpinitiatedsignon.aspx
In short, the STS has a Claim Description with a Claim Type (URI) which does not meet the format requirements for the SAML token requested.
SAML tokens have URI (ClaimType) rules that will differ based on the version of the SAML
token you intend to issue.
AD FS 2.0 supports WS-Federation, WS-Trust, and SAML 2.0 protocols. WS-Federation
protocol only supports SAML 1.1 tokens. WS-Trust
protocol can work with multiple token types. SAML 2.0
protocol only supports SAML 2.0 tokens.
SAML 1.1 tokens have strict URI rules which state that the format must be 'namespace'/'name'. These can be constructed many ways, and here are a few common examples:
SAML 2.0 tokens do not have the same URI requirements, and simple names can be used. Examples:
When you are browsing to the RP application first, you are performing RP-initiated sign-on which could result in a request on any of the supported protocols. If your RP is protected by WIF, then your request will be WS-Federation which means a SAML 1.1 token.
A Fiddler trace will clue you in to which protocol you are using. If you are doing IDP-initiated sign-on, then you are utilizing SAML 2.0 protocol, which means you get a SAML 2.0 token. This explains why the IDP-initiated sign-on scenario may be working for
The easiest solution is to change your Claim Descriptions to only include Claim Types which are compliant with SAML 1.1 token rules. That way, it doesn't matter which protocol or token type you are using, and the Claim Description will be versatile for any
protocol scenario (consider protocol transition).
If there is some reason the claim type cannot be changed, then you need to ensure that your RP-initiated request utilizes a request for a SAML 2.0 token, or you could move toward a IDP-initiated solution which would guarantee the use of a SAML 2.0 token.
is this still the case that when using WS-federation it only supports SAML1.1 and no 2.0 after applying the hotfix 3?