ADFS Simple Explanation RRS feed

  • Question

  • Active Directory Federation Services 
    ADFS is a service from Microsoft for accessing any third-party or intranet web application using our own domain credentials with mutual trust being enabled from both the companies.
    Use Cases: 
    1.	Access to office365 or any third-party websites (Udemy/Pluralsight or Payroll portal or Client sites) from your company using domain credentials.
    2.	Access to your intranet web applications (HR portal, Finance portal) with your company domain credentials using single-sign-on.
    Again different logon-on options like single-sign-on, MFA Multifactor Authentication, PIN or Virtual digital badge types can be configured in ADFS for logon methods.
    Passive Requestor - A passive requestor is an HTTP browser or application capable of broadly supported HTTP.
    Claim - A claim is a declaration made by an entity (e.g. name, identity, key, group, privilege, capability, etc).
    Security Token - A security token represents a collection of claims.
    Identity Provider (IP) or Claims Provider - Identity Provider is an entity that acts as a peer entity authentication service to end users and data origin authentication service to service providers (e.g. security token service)
    Let us quickly jump in to architecture and workflow of ADFS. The Below picture illustrates the 11 steps workflow of ADFS.
    Consider a user from one partner (known as the "account" partner) who attempts to access an AD FS enabled Web application hosted by another partner (known as the "resource" partner). 
    1. User hits the URL of web application using a web-browser – means a claim is made to the web-server.
    2. The resource partner's Web server intercepts the request and checks whether the user has an appropriate AD FS cookie. If so, the user is given access to the Web application. If not, the user is redirected to the resource partner's AD FS server.
    3. The resource partner's AD FS checks for a security (SAML) token from the user.
    4. if the token is not found with user, resource partner`s ADFS server orchestrates "home realm" discovery. Home realm discovery is the process of determining the federation server associated with the user either implicitly or by presenting the user with a Web page to make an explicit choice. 
    Once determined, a self-identifier is added to the request so that the account partner's federation server knows who is requesting a security token and the user is redirected to the account partner's federation server.
    5. User then reaches out to its own ADFS server to receive the token demanded by resource partner`s ADFS server.
    6. Account Partner`s ADFS server uses IWA (Integrated Windows Authentication) to verify the user with the Domain Controller. . It is important to recognize that the user is authenticated by the user's own organization.
    7. On-Successful Authentication, ADFS server provides a token to the user containing identity information (in the form of "claims") 
    8. User then post the token to the resource partner`s ADFS server.
    9. Resource Partner`s ADFS server verifies it is from one of its trusted account partners and ensures claim rules abide by the trust policies and again provide user with a second SAML token that contains the resource partner claims, writes the contents to a cookie on the user's computer, and redirects the user back to the Web application.
    10. User present token to the webserver.
    11. Web server discover the cookies, parses the SAML token, and allows access to the Web application. This Web application instantiates a SingleSignOnIdentity object, which contains the claims parsed from the SAML token, and uses these claims to make authorization decisions.

    Wednesday, October 3, 2018 4:12 PM