logo_kerberos.gif

Difference between revisions of "KrbWeb Outline of Work"

From K5Wiki
Jump to: navigation, search
Line 4: Line 4:
   
 
===Negotiate===
  
===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.
  +
 
===Kerberos XML-Sec Profile===
  
===Kerberos XML-Sec Profile===
⚫
===Kerberos & SAML===
  
  +
−
===GSS-API & SAML===
  
  +
[https://spaces.internet2.edu/display/kerweb/WS-Security+Kerberos+Token+Profile]
−
===Credentials delegation/N-Tier===
  
  +
  +
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 isattached 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 not supported.
  +
  ⚫
===SAML===
  +
  +
[https://spaces.internet2.edu/display/kerweb/SAML]
  +
  +
There are several ways in which the SAML Web SSO profile can/could interface with Kerberos:
  +
  +
* The IdP uses kerberos to validate passwords
  +
* 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===
  +
[https://spaces.internet2.edu/display/kerweb/ID-WSF]
  +
  +
===Information Card===
  +
[https://spaces.internet2.edu/display/kerweb/Information+Card]
  +
  +
;Kerberos authentication from IS to IdP :
  +
The IS can authenticate to an IdP using Kerberos.&nbsp; The WS-Security Kerberos Token Profile is used, underlying the WS-Trust protocol that does the security token request.&nbsp; An IdP supporting Kerberos authentication would be an application server from the Kerberos point of view.&nbsp; It doesn't appear that any of the existing Infocard IdP software supports Kerberos authentication however, so this is an opportunity for improvement.&nbsp; 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.&nbsp; 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.&nbsp; Infocard has primarily used SAML tokens, e.g. for self-issued cards.&nbsp; It would be possible to define a Kerberos token.&nbsp; 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.&nbsp; 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.&nbsp; The selector concept could be extended to apply to any instance of user authentication.&nbsp; This might involve extending selectors to support other protocols, or adding the use of WS-Trust for authentication to existing systems.
  +
  +
===OAuth===
  +
  +
OAuth has no relationship to Kerberos or any other existing authentication technology at this time.
  +
  +
===OpenID===
  +
  +
OpenID has no relationship to Kerberos or any other existing authentication technology at this time.
   
 
==Browsers==
  
==Browsers==

Revision as of 16:57, 19 August 2008

This document is a draft concerning Kerberos and the Web.

Technology

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.

Kerberos XML-Sec Profile

[1]

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 isattached 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 not supported.

SAML

[2]

There are several ways in which the SAML Web SSO profile can/could interface with Kerberos:

  • The IdP uses kerberos to validate passwords
  • 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]

Information Card

[4]

Kerberos authentication from IS to IdP 

The IS 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

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

OpenID

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

Apache

Perl

Ruby

Java

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

Retrieved from "https://k5wiki.kerberos.org/wiki?title=KrbWeb_Outline_of_Work&oldid=433"