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
- 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
Authentication
By xwipeoutx
Authentication
Brief overview of authentication, and how we use it at ZAP
- 815