ted@tedneward.com | Blog: http://blogs.tedneward.com | Twitter: tedneward | Github: tedneward | LinkedIn: tedneward
Who is this guy?
Architect, Engineering Manager/Leader, "force multiplier"
Principal -- Neward & Associates
http://www.newardassociates.com
Educative (http://educative.io) Author
Performance Management for Engineering Managers
Author
Professional F# 2.0 (w/Erickson, et al; Wrox, 2010)
Effective Enterprise Java (Addison-Wesley, 2004)
SSCLI Essentials (w/Stutz, et al; OReilly, 2003)
Server-Based Java Programming (Manning, 2000)
Am I Ted Neward?
Am I allowed to give a talk here?
Is this talk even supposed to be given at all?
How would you verify any of this?
learn what "auth-n-auth" means
learn how authentication works
learn how authorization works
Who are you?
How do I know you are who you claim to be?
How do we avoid mistakes or bad actors here?
identity: every actor has identity
claim: an assertion of identity; actors can make multiple claims
credentials: "proof" of identity, based on one or more factors
evidence: information supporting credentials
credential authority: organization issuing/validating credentials
I claim I am Ted Neward
What evidence do I have to support that?
What credentials can I present?
What other forms of evidence can there be?
What trusted third parties will vouch for me?
I claim I am Ted Neward
Evidence: (Credential) State of Washington Driver's License
Trusted third party: Washington State
Evidence: (Credential) US Passport
Trusted third party: US government
Evidence: (Credential) Birth certificate
Trusted third party: Hospital
Evidence: Photos of me on the Internet
Trusted third party: Crowdsourcing
Authentication and authorization are oftne intertwined
Driver's license:
Authenticates who I am
Authorizes me to drive a car
Passport:
Authenticates who I am
Authorizes me to exit and re-enter the US
Keep them separate in your designs/planning
Birth certificate:
No current photo
Biometrics (hands, feet) very out of date
Describes the relationship of me to my parents
Describes the location of my birth
Photos of me on the Internet
More recent visual identification
But forgeries are certainly possible
And hacks could create false links
Or somebody could get plastic surgery!
Driver's license: Call Washington State DMV
Passport: Call US Department of State
Birth Certificate: Call hospital
Internet photos: ...
something you know
something you have
something you are
based on shared secrets (passwords, pass-phrases, etc)
both sides must know the same shared secret
easy to regenerate/replace
keys (car keys, house keys, etc), badges
typically a secret is embedded somewhere in the key
easy to regenerate/replace
requires some kind of transference
biometrics (fingerprint, retinal pattern, etc)
relies on uniqueness
impossible to regenerate
omnipresent in the individual
makes it harder (not impossible) to break
airport: must slide badge and know passcode
corporate receiption: badge and receptionist "buzz"
driver's license: contains biometric data and you must have it on you
credit card: you must know your CVV and must sign
Spoofing: Attempting to create fake credentials
Tampering: Existing credentials authenticate wrong individual
"Replaying": Sending eavesdropped credentials on another's behalf
House keys can be copied at any hardware store
Fake driver's licenses can be obtained at any high school
Fake passports can be had at any Russian embassy
Databases can be hacked and copied
fingerprints can be lifted and re-applied
biometric data can also be "presented" electronically
house: change the locks
driver's license:
passwords: change the password
something you know: change what you know
something you have: re-issue a new instance
something you are: ...
an Internet protocol
for authenticating principals
on behalf of third parties
without sharing secrets
imagine you run a bar ...
that is all-ages ...
and the bartender needs to serve only 21+
User: the principal (typically a human) who has private resources stored with an OAuth-enabled site/server
Client: the app/site that wants to access User's private resources
Server: the OAuth-enabled site/server
User: Jane, who has just returned from Scotland with pictures and Scotch
Server: Faji.com, a site for storing photos
Client: Beppa.com, a site for printing and/or photos in an eco-friendly manner
Jane visits Beppa.com, to print photos stored on Faji.com
Beppa.com has a widget that says "Sign in with Faji"; Jane clicks it
Beppa.com does magic to prove to Faji.com that it's legitimate
Faji.com agrees, and Beppa sends Jane to Faji to authenticate
Faji asks Jane if she's OK with Beppa accessing her photos
If Jane says yes, she's redirected back to Beppa
Beppa now has authentication tokens to access Jane's photos
Jane can always revoke Beppa's access at any time
Dave registers Beppa.com with Faji
he receives a 'consumer key' and a 'consumer secret'
Dave puts the "sign in with Faji" widget on his website
when Jane clicks this widget, Dave takes the consumer key and secret and sends to Faji.com for a 'request token'
on success, Beppa needs to redirect Jane back to Faji.com using the request token
(still during the widget)
(Jane is asked to authorize Beppa's access to her data)
if Jane said yes, Faji.com will redirect Jane back to Beppa to a URL of Dave's choice, saying that the request token is authorized
Dave uses the request token to obtain an 'access token'
Dave uses this access token with Faji.com's API for all authorized-requiring API calls
several URL parameters emerge out of this dance:
oauth_consumer_key, oauth_signature_method
oauth_timestamp, oauth_nonce
oauth_callback
oauth_signature
oauth_token, oauth_token_secret
oauth_verifier
these can all be used for various authorization schemes
Official OAuth website
http://oauth.net
OAuth 1.0 Specification (RFC 5849)
OAuth 2.0 Specification (RFC 6749)
Google "OAuth Playground"
https://developers.google.com/oauthplayground
What are you allowed to do?
How do we control that policy?
How do we enforce that policy?
What are you allowed to do?
How do we manage what you are allowed to do?
principal: entity which is being authorised to perform an action
resource: any entity a principal is seeking access to
action: any activity a principal is seeking to undertake
policy: deliberate system of guidelines describing principals' access to resources or actions
role: grouping of principals for easier authorization decisions
things aren't quite as crystal-clear as with authentication
authorization is usually a "code"-level thing
requirements more variable
few established frameworks
here is where you will likely need to do more work
Unix "user/group/world rwx" model
Win32 ACL model
Java (and .NET) permissions-based model
authentication is the act of proving you are who you claim
authorization is the act of determining what you're allowed to do
though a lot of this stuff is complicated...
... none of it is really all that hard to understand
Books
Practical Cryptography (Schneier; 1995)