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.
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
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:
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.
Pingback: Illustrative sample of Authentication using JSON Web Token(JWT) | Information Dynamics
Pingback: Azure AD DS Deployment | Information Dynamics
Pingback: Deploying Azure AD DS | Information Dynamics