SyferLock 2018 DocumentationIntegrationsADFS IntegrationOverviewAuthentication Process (Non-Claims Aware) (copied)

Authentication Process (Non-Claims Aware) (copied)

Provides a high level overview of how the Authentication process works with an ADFS non-claims aware web appliation.

User Authentication Sequence Diagram

User Authentication Sequence Diagram

The steps in the authentication process are

  1. A request is sent from the browser to the Web Application Proxy (WAP) to access the application URL ( for e.g. http://wap.company.com/owa )
  2. The WAP checks to see if there is a Kerberos ticket associated with the user session. The first time a user access the system there will be no ticket associated with the user session.
  3. WAP responds to browser with an HTTP redirect (302), directing the browser to the ADFS server to get authenticated
  4. Browser sends request to WAP to Verify authentication status via ADFS ( for e.g. http://wap.company.com/adfs )
  5. WAP forwards request to ADFS service
  6. ADFS which has been configured to use GridGuard for authentication creates a SAML Authentication Request and forwards request to the GridGuard server
  7. GridGuard authenticates the user based on realm level configuration settings
  8. GridGuard returns back the SAML Authentication response to the ADFS server
  9. ADFS now creates a Kerberos ticket for the user (assuming that the SAML Authn Response indicated that the user was successfully authenticated)
  10. ADFS returns Kerberos ticket to the WAP
  11. WAP now sends a browser a redirect request to redirect the user back to the original target application URL
  12. Browser sends a request to the Target App URL
  13. WAP verifies that there is a Kerberos ticket associated with user session
  14. WAP forwards request to the target application. Included in the request is the Kerberos ticket information
  15. Target application that supports Integrated Windows Authentication, accepts the Kerberos ticket, validates it and grants the user access to the system
  16. The secured page is returned to the WAP
  17. WAP forwards the secured page to the browser. The user is now logged in able to access the application.