2. Agenda
Authentication is more challenging than it looks like:
• Cookies and clients
• Locking and unlocking
• SLO - logout
• Q/A
• LDAP proxy accounts, any proxy accounts ….
4. Cookies and clients
Cookies
• are NOT designed for authentication
• are managed by the user or by the device administrator
• each browser can be configured in a different way
• each browser has own cookies
• Cookie (token) authenticates https channel
• guess – how many browsers the user might use?
• cookie is the critical weakness of SAML and JWT
5. Cookies and clients
Client works in a different way:
• client authenticates the user
• client, not the system, knows, who is the user
• client shares the user‘s identity – Kerberos, NTLM, Native
messaging, Radius Accounting, NAC, various APIs
• user needs only one client with something, which proves the
user‘s identity in a trusted way
6. Cookies and clients
If the client is fast and efficient enough, both SPs and IdPs can be directly
integrated:
• Not necessary to change existing setup
• IdP doesn‘t use cookies
• IdP talks to the client instead
This is technical debate, nothing else.
Ask Simon if he knows, what can serve more than 10.000 authentication
requests in a single second
Yes, it is roughly 600.000 per minute
7. Locking and UNLOCKING
User is required to protect an authenticated device anytime he or
she leaves
Even for a short while
For Windows users, protection is (windows_key plus L)
This seems to be EASY
But, unlocking is implemented as yet another authentication
Again, again, again
How many times a typical user leaves the computer in a day?
Coffee, tea, meetings, lunch, smoking, prostate ….
8. Locking and UNLOCKING
Users are enforced to:
• use long and complex passwords
• wait for certificate authentication
• use two chained authenticatons (usually called 2FA)
• change their passwords regularly
This is why they complain. Users COMPLAIN
Real authentication solution must offer first strong authentication
and many easy and efficient unlockings (security = only if done
within a reasonable period)
9. SLO - logout
Standard implementation needs – browser
But browser is usually not available, when the the user:
• Reset
• Reboot
• Close
• Sleep
• Disconnect
• etc
10. SLO - logout
Real Authentication Solution
• should handle SLO from the server side
• must track all the trusted user‘s identity proofs in the matter of
time
• anything older then maximum age must be invalidated
• Maximum age should not exceed 6 hours
• or 8 hours, 12 hours or a day if users are stronger than you