Authentication

Authentication Mechanisms

There are 3 main ways the server and client interact in order to authenticate

  • Windows authentication
  • Basic (HTTP) authentication
  • External (pretty much everything else)

Windows Auth

  • User makes request to /Secure
  • Server sends back 401: Unauthorized
    • Has header: WWW-Authenticate
    • Values: NTLM, Negotiate
  • Browser gets authorization ticket
  • Sends the authorization ticket in each request to that domain until browser is closed
  • This ticket makes up the identity

Windows Auth

  • Kerberos is also a thing
  • That's all I know

Integrated Pipeline

  • This can ONLY be fulfilled by IIS
  • At least, without someone writing a lot of code
  • Mumble mumble Win32 API mumble

Basic (HTTP) Auth

  • User makes request to /Secure
  • Server sends back 401: Unauthorized
  • Browser prompts for username and password
  • Credentials sent up in each request to that domain until browser is closed
  • These credentials make up the identity

External

  • User makes a request to /Secure
  • Browser sends back 302: redirect to authentication provider
    • This will likely include a nonce (one-time token)
  • After signing in to whatever, a POST will usually be sent back to /Secure (or whatever the sign in URL is)
    • Contains the identity 
  • Identity often stored in an encrypted cookie, and used from then on

Identity

  • A unique sign in
  • Contains a bunch of "Claims"
    • Name
    • Email
    • Groups
    • ... whatever you want
    • (see ClaimType in System.Identity)

User

  • Zero or more identities
  • Without an identity, it's not Authenticated

Authentication

  • One is authenticated if they have an identity
  • That is, they have signed in
  • Basically, being authenticated means the system knows who you are
  • Note this doesn't necessarily mean you are authorized
  • Note on HTTP 401: Unauthorized
    • Poorly named, this almost always means you're not authenticated
  • ​Most of the time, this is application agnostic - OWIN level stuff

Authorization

  • Whether you're permitted to do something
  • Not necessarily authenticated to be authorized
  • Examples
    • Watch a public YouTube video
    • Upload a YouTube video
    • Watch a private Youtube video
  • HTTP 403: Forbidden

Using Cookies

  • When signing in using OWIN, a ticket is generated
  • A ticket contains
    • Identity
    • Expiration Date
  • This ticket is encrypted and put in a cookie
  • The cookie, being a cookie, is sent up every request
  • The ticket is unencrypted, validated and the identity is extracted

Authentication & CSRF

  • Cookie auth is vulnerable to CSRF
    • For that matter, so is NTLM
  • An alternative is to send a token up in the URL
  • Match this token with a ticket server side
  • I believe Chris Briggs will cover this at DDD

Authentication in OWIN

  • Decrypt the cookie
  • If it exists and valid
    • We're good!
  • Else
    • Handle with Authentication middleware

Katana Middleware

  • OpenIdConnect
    • AzureAD
  • WSFederatedServices
    • ADFS

Windows Auth in OWIN

  • Need IIS to handle it
  • But we don't want a bunch of ifs
  • WindowsAuthenticationMiddleware

Our Windows Auth

  • Strips out any WindowsIdentity
    • Unless it's a request that needs it
  • When signing in, it pulls the claims from the identity
  • Jams this in a cookie
  • Viola! like every other provider! Minimal hackery

Guest Access

  • To give unauthenticated users an identity
  • Kinda only necessary because we can't code
  • If we don't have an identity after the auth middleware, create a guest one and use that
  • But don't put it in a cookie, so they can log in easily
  • This is kinda different to anonymous access
  • We call it "Anonymous Viewer" because we're cool

Dynamic Authentication

Go to our codes to see dynamic authentication setup

  • Mutating the options
  • Interaction with cookies
  • Caching
Made with Slides.com