Difference between revisions of "KrbWeb Outline of Work"

Revision as of 15:01, 31 August 2008

This document is a draft concerning Kerberos and the Web.

Related Pages

"Backlog" Page

Steve's "slides and notes from the Consortium Board meeting" from 24-Jul-2008

Technologies

Negotiate

Negotiate is the collected name of a loosely defined set of HTTP authentication mechanisms which provide a simple 2-way GSS-API handshake with the HTTP server. The most commonly deployed variant is described in RFC 4559 uses the SPNEGO GSS-API mechanism. Other implementations use the Kerberos5 GSS-API mechanism instead. Updates to RFC 4559 have been discussed. It is worth to note that Negotiate authentication does not protect the headers of the request since they are sent unprotected during the GSS-API handshake. In particular this means that REST-style webservices cannont in general be protected using Negotiate.

WS-Security Kerberos Token Profile

[1] (reference material)

The WS-Security Kerberos Token Profile defines how to use Kerberos service tickets (specifically, the KRB-AP-REQ message) as a security token. Acquisition of the token is out-of-scope.

The Kerberos message is attached to SOAP messages using the <wsse:BinarySecurityToken> element. Six different types are supported, including RFC 1510-style, RFC 4120-style and their equivalent GSS-API encapulsations. The octet sequence is encoded using the indicated method.

This specification does not support the KRB-AP-REP message, and so consequently neither Kerberos mutual authentication, nor GSS-API channel bindings, are supported.

SAML

[2] (reference material)

There are several ways in which SAML, in terms of either SAML assertions themselves or the SAML Web SSO profile, can/could interface with Kerberos:

• The IdP uses kerberos to validate usernames and passwords supplied by users on webpage forms
• The IdP uses kerberos authentication at the HTTP layer - eg Negotiate or NTLM
• The IdP issues SAML assertions containing kerberos tickets as an attribute
• The KDC includes a SAML assertion and/or authentication response message encapsulated in KDC-issued authorization data
• The SP needs access to a kerberos ticket in order to call n-tier services.
• The SP uses Negotiate to find the preferred IdP of the user (aka IdP discovery) based on the realm of the GSSAPI authentication request.
• A GSSAPI peer implementing the proposed GSSAPI naming extensions receives a SAML attribute assertion as part of a GSSAPI protocol exchange.

ID-WSF

[3] (reference material)

Identity Web Services Framework (ID-WSF - from the Liberty Alliance) is a full-featured web services "stack" that leverages WS-Security as its encapsulating security token format. Thus it is possible to leverage Kerberos-based authentication in an ID-WSF-based web services context, although at this time the limitations noted above with respect to the WS-Security Kerberos Token Profile will apply.

WS-*

[4] (reference material)

WS-* ("dubya ess star") denotes a suite of web services specifications promulgated by IBM+Microsoft and various collaborators. The WS-Security specification, along with the aforementioned WS-Security Kerberos Token Profile specification are components of WS-*. Thus Kerberos is applicable in this context in a fashion similar to its applicability in ID-WSF.

Note that the WS-Trust protocol -- a component of WS-* -- plays a key role in the Information Cards technology, described next.

Information Card

[5] (reference material)

Kerberos authentication from Identity Selector to IdP 

The Identity Selector (IS; an end-user client-side tool) can authenticate to an IdP using Kerberos.  The WS-Security Kerberos Token Profile is used, underlying the WS-Trust protocol that does the security token request.  An IdP supporting Kerberos authentication would be an application server from the Kerberos point of view.  It doesn't appear that any of the existing Infocard IdP software supports Kerberos authentication however, so this is an opportunity for improvement.  Microsoft's IdP (which probably won't be available until 2009) will support all four defined methods, including Kerberos.

Kerberos token delivery to the RP 

WS-Trust operates by delivering security tokens to RPs to authenticate clients.  WS-Trust is (or claims to be) token agnostic, meaning it can carry anything, but for a token format to be used interoperably its nature and handling by IdP and RP must be specified.  Infocard has primarily used SAML tokens, e.g. for self-issued cards.  It would be possible to define a Kerberos token.  Such a token (presumably a KRB_AP_REQ) would be generated by the IdP, carried by WS-Trust from IdP to IS and from IS to RP, and processed by Kerberos software at the RP.  There is no such token defined at this time.

Identity Selector as standard authentication UI 

Infocard technology has been introduced as an approach to web authentication, since that space is obviously the most widely-used and most urgently in need of better solutions.  The selector concept could be extended to apply to any instance of user authentication.  This might involve extending selectors to support other protocols, or adding the use of WS-Trust for authentication to existing systems.

OAuth

[6] (reference material)

OAuth has no relationship to Kerberos or any other existing authentication technology at this time.

OpenID

[7] (reference material)

OpenID has no relationship to Kerberos or any other existing authentication technology at this time.

Browsers

Safari

Mozilla/Firefox

Internet Explorer

Application environments & Libraries

IIS

IIS naturally has native support for Negotiate using the SPNEGO GSS-API mechanism. The .NET framework supports the kerberos xml-sec token profile.

Apache

Apache has add-on modules supporting Negotiate using both SPNEGO and Kerberos GSS-API,

Perl

The LPW::Authen::Negotiate module implements Negotiate using the GSSAPI perl module which in turn uses either heimdal or MIT kerberos libraries. This means that LPW::Authen::Negotiate can support both SPNEGO and Kerberos GSS-API.

Ruby

There is a GSS-API library for ruby which similar to the perl GSS-API library supports either MIT or heimdal kerberos. However the Ruby HTTP client library does not natively support Negotiate (it does support NTLM though). There have been working patches but they are not maintained. Ruby is one of the language of choice for "web 2.0" applications especially in combination with the Rails framework. These applications are known to prefer REST-style webservices to more "enterprise"-style SOAP-based webservices.

Java

Java has native support for the Kerberos GSS-API mechahism since JDK 1.4. A number of implementations of Negotiate exists for various application servers (eg Tomcat and JBoss). There are not free implementations of SPNEGO although there are at least two commercial implementations.

WSS4j

Use Cases

Enterprise

B2B

B2C

User Stories

       Banking
       Federation(federated realms)
       N-Tier authentication/authorization access to web services

Implementation issues

       degree of difficulty matched against impact of result.

Recommendations for next steps