logo_kerberos.gif

Difference between revisions of "KrbWeb Outline of Work"

From K5Wiki
Jump to: navigation, search
(Browsers)
(Use Cases)
Line 119: Line 119:
 
==Use Cases==
 
==Use Cases==
   
===Enterprise===
+
===Intra Enterprise===
  +
  +
A large organization (eg a university or large company) is deploying an increasing number of web services. Initial deployments (which are typically few in number) relied on user name+password sometimes (but not always) with TLS. HTTP is almost always used as a transport for SOAP. Message-layer authentication is very uncommon in these situations.
  +
  +
As the deployment grows the job of keeping track of and provisioning passwords for these services becomes an issue. In some cases the security issues involved are part of the discussion. The most common action taken is to try to move to the use of client certificates but mostly an organization in this situation will buy a webservice-governance solution. Such products are often based on an ESB (enterprise service bus) and sometimes employ other transports besides HTTP, eg various message-oriented protocols such as MQ or XMPP.
  +
  +
The motivation for Kerberos in this type of situation will be because it can simplify the security-management. An enterprise-wide deployment of SOAP-based web services are seldom perceived to have security issues and is often treated as a single administrative domain isolated from everything except the business systems which are connected using the web services. This means that the security properties of Kerberos won't be an important part of evaluating it against alternative mechanisms. It also means that Kerberos administration, in order to be a viable option, must integrate into the various web service governance solutions that exist.
  +
 
===B2B===
 
===B2B===
===B2C===
 
   
  +
In this situation a business, possibly with an existing enterprise-wide SOAP-deployment, needs to integrate with another business using an app2app SOAP-based web service. The security model is typically fairly simple one - the applications trust each other and there are no n-tier issues involved. A common way to provide basic authentication is to setup some form of tunnel between the business-entities (eg an ipsec tunnel) TLS with user name and password is used. The use of anything other than HTTP-transport for SOAP is probably very uncommon in this situation.
  +
  +
The motivation for Kerberos in this situation may rely on cross-realm trust between the business-entities and the desire to use this infrastructure instead of setting up a separate trust-model (eg based on certificates or passwords). The main difference between this case and the previous one is the fact that for each pair of B2B relationship a very small number (typically) of web services are involved. This means that maintaining cross-realm trust must be perceived as a low barrier.
  +
 
===B2C===
   
 
==User Stories==
 
==User Stories==

Revision as of 15:36, 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

Most browsers supports Negotiate by default but

Safari

Mozilla/Firefox

The Mozilla and Firefox family browsers include native support for Negotiate using the Kerberos GSS-API mechanism. This feature is not turned on by default though and must be turned on manually by editing the prefs.js-file. Credentials delegation is supported but must also be turned on manually. There are a few plugins implementing Information Card for firefox/mozilla. It is unclear if any of them supports kerberos authentication for Information Card IdPs.

Internet Explorer

Konqueror

Konqueror is the browser included in the KDE desktop framework. Konqueror supports Negotiate and enables Negotiate for sites in the same domain as the client. There is no support for Information Card yet in Konqueror.

Application environments & Libraries

IIS

IIS naturally has native support for Negotiate using the SPNEGO GSS-API mechanism.

.NET

The .NET framework supports the kerberos xml-sec token profile aswell as Negotiate natively.

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

WSS4J is the primary free implementation of XML security (from the apache project). It does not include an implementation of the kerberos token profile.

Use Cases

Intra Enterprise

A large organization (eg a university or large company) is deploying an increasing number of web services. Initial deployments (which are typically few in number) relied on user name+password sometimes (but not always) with TLS. HTTP is almost always used as a transport for SOAP. Message-layer authentication is very uncommon in these situations.

As the deployment grows the job of keeping track of and provisioning passwords for these services becomes an issue. In some cases the security issues involved are part of the discussion. The most common action taken is to try to move to the use of client certificates but mostly an organization in this situation will buy a webservice-governance solution. Such products are often based on an ESB (enterprise service bus) and sometimes employ other transports besides HTTP, eg various message-oriented protocols such as MQ or XMPP.

The motivation for Kerberos in this type of situation will be because it can simplify the security-management. An enterprise-wide deployment of SOAP-based web services are seldom perceived to have security issues and is often treated as a single administrative domain isolated from everything except the business systems which are connected using the web services. This means that the security properties of Kerberos won't be an important part of evaluating it against alternative mechanisms. It also means that Kerberos administration, in order to be a viable option, must integrate into the various web service governance solutions that exist.

B2B

In this situation a business, possibly with an existing enterprise-wide SOAP-deployment, needs to integrate with another business using an app2app SOAP-based web service. The security model is typically fairly simple one - the applications trust each other and there are no n-tier issues involved. A common way to provide basic authentication is to setup some form of tunnel between the business-entities (eg an ipsec tunnel) TLS with user name and password is used. The use of anything other than HTTP-transport for SOAP is probably very uncommon in this situation.

The motivation for Kerberos in this situation may rely on cross-realm trust between the business-entities and the desire to use this infrastructure instead of setting up a separate trust-model (eg based on certificates or passwords). The main difference between this case and the previous one is the fact that for each pair of B2B relationship a very small number (typically) of web services are involved. This means that maintaining cross-realm trust must be perceived as a low barrier.

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