ADFS Authentication Needs
To understand what is required to authenticate, you can access the ADFS server and identify, based on your preferred authentication approach, the policy can be reviewed. ADFS metadata is published from the ADFS server, for example, at https://auth.demo.local/adfs/services/trust/mex.
Let's say you want to use a username and password to authenticate, you can find the specific binding endpoint by looking at the list included in the XML from the above metadata:
The specification says to access the policy reference UsernameWSTrustBinding_IWSTrust13Async_policy which is included in the same document. That snippet looks like:
It is this policy that is transmitted to user agents that wish to authenticate. The policy section contains policy assertions which are at a top level specified in WS-SecurityPolicy. This particular assertion indicates that:
TransportBinding: Indicates that message protection is provided by means other than techniques described in WS-SecurityPolicy, for example, by HTTPS. The assertion above indicates this by TransportToken policy HttpsToken which says that HTTPS is supported, the header must be laid out strictly (vs lax) and that the algorithm suite for performing cryptographic operations is Basic256. Basic256 indicates that SHA1 should be used for digest calculation.
sp:IncludeTimestamp: A policy assertion that indicates that the security header should include a Timestamp element. Since Transport security is used, the Timestamp must be part of a signature calculation—which is called a supporting token.
wsaw:UsingAddressing: A policy that indicates that the endpoint conforms to the * WS-Addressing specification. There are three separate WS Services Addressing specification documents: core, WSDL and SOAP. wsaw refers to the WS Services Addressing - WSDL. With this assertion, ReplyTo, Action and and To should be included in the headers. The use of the "mustUnderstand" attribute is also described in this specification.
SupportingTokens: Additional tokens may also be included to enhance message security. This is referred to as "augmenting the claims." Since Transport security is used, the supporting token (a signature) must include a Timestamp element and included in the Security header. Additional elements can be signed as part of creating a supporting token as well and these additional elements would be specified in SignedParts. The policy above suggests two additional supporting tokens:
SignedEncryptedSupportingTokens: This policy indicates that an additional token, a UsernameToken, should be included in the RST. The contents of a UsernameToken are specified in a WS specification: http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0.pdf. This specific policy element does not indicate whether the password is allowed to be clear text or encrypted in some way. We can use clear text password content fortunately, as HTTPS requires the entire message to be encrypted.
EndorsingSupportedTokens: This policy indicates that the Signature element is signed. It may seem duplicative but the approach is quite common, that is, you sign a signature. The policy here says to sign the To field that is present from WS-Addressing. However, the KeyValueToken:Optional=true indicates that this is optional and hence you can ignore the EndorsingSupportedTokens policy if you wish to.
Trust13: This assertion indicates which WS-Trust (version) 1.3 options are supported. This is a straightforward list that can be lookup in the WS-Trust specification.
Based on interpreting the policy assertions above, what's needed when requesting authentication?
A Timestamp token (element) in the Security header.
A UsernameToken. This means that a username and some form of password must be provided.
For example, when authenticated to an on-premise IFD deployment, the authentication request can look like:
The Security header elements includes these two parts in the RST. The request itself is in the Body.
Last updated