Waffle at NYCJavaSig
•Download as PPT, PDF•
1 like•3,900 views
Windows Authentication for Java with WAFFLE presented at NYJavaSig, February 2012
![[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommended
More Related Content
What's hot
Viewers also liked
Viewers also liked (17)
Similar to Waffle at NYCJavaSig
Similar to Waffle at NYCJavaSig (20)
More from Daniel Doubrovkine
More from Daniel Doubrovkine (20)
Recently uploaded
Recently uploaded (20)
Waffle at NYCJavaSig
- 1. Daniel Doubrovkine | @ dblockdotorg
Editor's Notes
- The local computer is the computer from which LogonUser was called (advapi32.dll).
- The security context is the user account that the system uses to enforce security when a thread attempts to access a securable object.
- On Windows, this works because of the Security Support Provider Interface, aka SSPI . SSPI is a well-defined API for obtaining integrated security services for, among other things, authentication for any distributed application protocol. A client-server conversation is an example of such an application. SSPI is a Microsoft proprietary implementation of GSSAPI , an IETF standard. Security Support Provider (SSP) A dynamic-link library (DLL) that implements the SSPI by making one or more security packages available to applications. Each security package provides mappings between an application's SSPI function calls and an actual security model's functions. Security packages support security protocols such as Kerberos authentication and the Microsoft LAN Manager (Windows NT Challenge/Response (NTLM)). Negotiate: A security support provider (SSP) that acts as an application layer between Security Support Provider Interface (SSPI) and the other SSPs. Negotiate analyzes the request and picks the best SSP to handle the request based on customer-configured security policy.
- When a client wants to authenticate to a server, it needs to supply credentials and send them to the server. The server needs to validate this, reply that the credentials were kosher and possibly continue executing code on behalf of the client. Credentials can come in a variety of forms, such as a username and password or a notarized birth certificate from City Hall. Sending those to the server needs to be secure: you don’t want to send credentials to the wrong server, the server wants to make sure you’re really who you claim to be and nobody should be able to intercept this data on the wire and reuse it. The how part of this is the job of the authentication protocol, such as, for example, NTLM or Kerberos. Because there’re many protocols, SSPI exchanges so called tokens , opaque blobs of data. the protocol can put anything in the blobs. Protocols often require several exchanges. For example, I may need to obtain the server’s public key, encrypt credentials, send them with my public key and receive an encrypted confirmation of success. Therefore both client and server maintain a so called security context during this conversation. SSPI allows you to do all this with any protocol or SSPI provider. There’s an NTLM SSPI provider, Kerberos SSPI provider, etc. SSPI describes three important calls that do all of the above.