To provide Single Sign On (SSO) mechanism for users different authentication frameworks are in place viz., WS-Federation (WS-Fed), SAML, OAuth, Open ID and OpenID Connect.

WS-Fed and SAML (Security Assertion Mark-up Language) are still in use in corporate networks to allow users to connect to COTS (Commercial off the Shelf) products and bespoke applications. Federation (aka delegating authentication/authorization) is achieved using Active Directory Federation Services (ADFS) installed and configured on Windows Server OS.

The three essential components of federation are:

• Sign-in protocol > What is the mechanism to access the application
• Authentication protocol > How the user is verified
• Token Type > Once the user validated what is returned back to the user after successful identification

In the article configuring Dynamics CRM platform for Claims Based Authentication was discussed. Let us look at capture of traffic in Fiddler to see what information gets passed on in Request and Response.

Request

As highlighted accessing https://crm.idynamics.dev/seis will route the request to https://adfs.idynamics.dev containing the following parameter(s)

wa=wsignin1.0 > Indicates ADFS service to invoke login

wtrealm=https%3a%2f%2fcrm.idynamics.dev%2f > Client application using ADFS service

wctx=rm%3d1%26id%3da33a2f6c-768e-48aa-9c3c-b594ef0f60b5%26ru%3d%252fseis%252fdefault.aspx%26crmorgid%3dfa61533b-ea52-ea11-83b5-0017fb000002 > Session data sent back

wct=2020-02-20T09%3a53%3a23Z > Time the application is accessed

wauth=urn%3afederation%3aauthentication%3awindows > Mode of Authentication

Response

The response will confirm to SAML 1.1 as per specification and the following will be included as part of the “wresult” urn:oasis:names:tc:SAML:1.0:assertion

OAuth/Open ID/ OpenId Connect essentially use JWT (JSON Web Token).

JSON web token stores user information viz., id, permission set (aka claim rules) etc., in a compact format so information can be transmitted securely between client and server. The token will in the form of a string will be digitally signed using HMAC algorithm or RSA.
Available security algorithms are defined as constant string values in SecurityAlgorithms class of Microsoft.IdentityModel.Tokens namespace and in the sample project demonstrating Authentication using JWT we will be using HMAC algorithm.
JWT structure will consists of three parts [Header].[Payload].[Signature] represented as Base64-URL string
Header: A combination of token type + signing algorithm identified by claim set
typ (for token type) and alg (for signing algorithm) represented in JSON format this would look like the one below:

{
“alg”: “HS256”,
“typ:”JWT”
}
Payload: Consisting of claims about the user. A claim is represented as key/value pair combination. There are three types of claims Registered, Public and Private. The key part of the claim is limited to 3 characters
Registered: Predefined claims and can be viewed here

Public: Custom defined claims but need to be registered in public registry at

Private: Agreed custom claims between to applications.

Signature: Verifies that the message is not tampered during transmission.