SPNEGO authentication using JGSS

Transcript SPNEGO authentication using JGSS

SPNEGO authentication using JGSS
Jens Bo Friis
M. Sc, Technical University of Denmark
M. Cryptology from University of Aarhus
Email: [email protected]
(c) 2004, Jens Bo Friis
SPNEGO support
• Introduction
• Protocol
• SPNEGO token
• JGSS in J2SDK 1.4
• SPNEGO in PortalProtect
• Client side SPNEGO
• Conclusion
(c) 2004, Jens Bo Friis
Introduction
• SPNEGO (Simple and Protected GSS-API
Negotiation Mechanism)
• Provides a mechanism for extending a
Kerberos based single sign-on
environment to Web applications
• Kerberos is used in Windows 2k domains
• Internet Explorer 5+ supports SPNEGO.
(c) 2004, Jens Bo Friis
Web server authentication using
SPNEGO - overview
kdc.test.net
www.test.net
(2) http://www.test.net/stuff
(3) Error 401 Unauthorized
(5) SPNEGO (Kerberos ticket)
(c) 2004, Jens Bo Friis
Web server authentication using
SPNEGO – overview explained
1.
Logon towards domain test.net
2.
Browser request a protected page at www.test.net
3.
www.test.net responds with a HTTP Error 401 Unauthorized and starts the SPNEGO
protocol
4.
Browser requests a session ticket from the KDC for www.test.net server using
server principal name HTTP/[email protected]
5.
The browser resends the request for the protected page including the HTTP
Authorization header containing the ticket packaged into a SPNEGO envelope.
6.
Web server unpacks the ticket from the SPNEGO envelope and sends the ticket to
the KDC for verification.
7.
KDC verifies the ticket and returns the user name
(c) 2004, Jens Bo Friis
SPNEGO protocol details
HTTP GET /protected/stuff.html
www.test.net
ERROR 401 Unauthorized
WWW-Authentication: NEGOTIATE
HTTP GET /protected/stuff.html
Authentication: NEGOTIATE YIIEqwYG..
<html>....</html>
(c) 2004, Jens Bo Friis
HTTP Authorization header
Negotiate YIIEqwYGKwYBBQUC...
• Base64 encoded octet string
• Octet string is ASN.1 encoded blob
• ASN.1 blob is
– 0x60 <application specific>,
– an ObjectIdentifier(1.3.6.1.5.5.2) and
– a NegTokenInit defined in rfc 2478
• 1.3.6.1.5.5.2 is the OID for SPNEGO mechanism.
NegTokenInit ::= SEQUENCE {
}
mechTypes [0] MechTypeList OPTIONAL,
reqFlags [1] ContextFlags OPTIONAL,
mechToken [2] OCTET STRING OPTIONAL,
mechListMIC [3] OCTET STRING OPTIONAL
(c) 2004, Jens Bo Friis
mechToken
• is the InitialContextToken from rfc 1964.
InitialContextToken ::=
SEQUENCE {
thisMech
MechType
-- MechType is OBJECT IDENTIFIER
-- representing "Kerberos V5"
innerContextToken ANY DEFINED BY thisMech
}
• innerContextToken is the binary blob containing the Kerberos V5
KRB_AP_REQ message.
• innerContextToken is later used when we do the authentication i the
JGSS code
(c) 2004, Jens Bo Friis
JGSS connection to KDC
• GSSManager manager = GSSManager.getInstance();
• GSSName serverName = manager.createName(serverPrincipalName, null);
– Where serverPrincipalName points to the web servers servicePrincipalName entry
in ActiveDirectory – the web servers account which matches the user account
with the keytab file.
• GSSContext context = manager.createContext(serverName, krb5MechanismOid, null,
GSSContext.DEFAULT_LIFETIME);
– Create the context. Use the Kerberos OID.
– Other implementations using SPNEGO enabled JGSS implementations, specify
the SPNEGO OID.
• byte[] neg_token_targ = context.acceptSecContext(innerContextToken, 0,
innerContextToken.length);
– This calls the KDC to verify the KRB_AP_REQ message received from the browser
(c) 2004, Jens Bo Friis
JGSS context
• The GSSContext can afterwards be examined:
context.getMutualAuthState() =? True
context.isEstablished() =? True
userPrincipalName = context.getSrcName();
• User principal name is the userid of the user that logged
on to the domain.
• Since the user is authenticated, we can propagate the
userid to the security manager of the web server.
(c) 2004, Jens Bo Friis
PortalProtect SPNEGO support
• Authenticator plug-in (a servlet) in the Tunnel
(reverse proxy) which handles the NEGOTIATE
conversation. Nothing but the conversation is
handled here.
• Authentication plug-in to the Session controller.
All remaining work is done here:
– Token decoding
– ASN.1 decoding
– JGSS
(c) 2004, Jens Bo Friis
Client side SPNEGO
• Normally only the IE browser is capable of doing SSO over SPNEGO
• Mozilla also supports SPNEGO, but dont support SSO using windows domain
login
• SPNEGO tokens can be generated on client side, using nothing but JDK 1.4
• This can be run on Java applets or Java applications.
• Supports native windows ticket cache and Java ticket cache.
• Supports Windows XP and Windows 2000 clients.
• See http://appliedcrypto.com/spnego/spnego_client.html for further details.
Conclusion
• This demonstrates SPNEGO support using J2SDK 1.4 JGSS implementation
only.
• No need for 3rd party products like Wedgetail.
• Can be implemented in application server running on top of J2SDK 1.4, like
– WebLogic 8.1 server from www.bea.com.
– Tomcat 4.x and 5 from Jakarta.apache.org
• Using PortalProtect, SPNEGO support can be added to basically ANY
application server including older versions of WebLogic and WebSphere
3.5+
• Client side tokens can be generated. This adds support for Java applets and
Java applications. This means FULL client side single sign-on.
(c) 2004, Jens Bo Friis
Links
• http://appliedcrypto.com/spnego/qa.html
(SPNEGO FAQ)
• http://appliedcrypto.com/spnego/spnego_
client.html (client side SPNEGO)
(c) 2004, Jens Bo Friis