logo_kerberos.gif

Projects/KerberosInSAML

From K5Wiki
< Projects(Difference between revisions)
Jump to: navigation, search
(Background)
(Background)
Line 5: Line 5:
 
==Background==
 
==Background==
   
Specify and implement a means for embedding Kerberos tickets in SAML assertions. The main first use-case is that of SAML2.0 Web Single Sign On (Web-SSO) profile. The idea here is to make the Identity Provider (IdP) a service principal that can validate a service-ticket contained within an AP_REQ message. After authenticating the client (user), the IdP will then issue a (signed) SAML assertion that identities the Kerberos client principal, and optionally carries the original AP_REQ request (encoded in base64).
+
Specify and implement a means for extending (or transferring) trust from a Kerberos service ticket to a SAML assertion. Optionally, include the original AP_REQ message or the service-ticket portion within the SAML assertion.
  +
  +
Currently there are a number of limitations in using Kerberos for authentication within the SAML2.0 architecture. Previous work in the space of the Web-Services Security (WSS) resulted in the publication of the [WSS Kerberos Token Profile 1.1][http://www.oasis-open.org/committees/download.php/16788/wss-v1.1-spec-os-KerberosTokenProfile.pdf].
  +
  +
The main first use-case is that of SAML2.0 Web Single Sign On (Web-SSO) profile. The idea here is to make the Identity Provider (IdP) a service principal that can validate a service-ticket contained within an AP_REQ message. After authenticating the client (user), the IdP will then issue a (signed) SAML assertion that identities the Kerberos client principal, and optionally carries the original AP_REQ request (encoded in base64).
   
 
In this SAML2.0 Web-SSO use case, there is an assumed dependence of the Service Provider (SP) upon the IdP. Thus, the SP is a true relying party.
 
In this SAML2.0 Web-SSO use case, there is an assumed dependence of the Service Provider (SP) upon the IdP. Thus, the SP is a true relying party.

Revision as of 14:54, 4 December 2009

This is an early stage project for MIT Kerberos. It is being fleshed out by its proponents. Feel free to help flesh out the details of this project. After the project is ready, it will be presented for review and approval.



Contents

Background

Specify and implement a means for extending (or transferring) trust from a Kerberos service ticket to a SAML assertion. Optionally, include the original AP_REQ message or the service-ticket portion within the SAML assertion.

Currently there are a number of limitations in using Kerberos for authentication within the SAML2.0 architecture. Previous work in the space of the Web-Services Security (WSS) resulted in the publication of the [WSS Kerberos Token Profile 1.1][1].

The main first use-case is that of SAML2.0 Web Single Sign On (Web-SSO) profile. The idea here is to make the Identity Provider (IdP) a service principal that can validate a service-ticket contained within an AP_REQ message. After authenticating the client (user), the IdP will then issue a (signed) SAML assertion that identities the Kerberos client principal, and optionally carries the original AP_REQ request (encoded in base64).

In this SAML2.0 Web-SSO use case, there is an assumed dependence of the Service Provider (SP) upon the IdP. Thus, the SP is a true relying party.

Architecture

Implementation

Open issues

Status

Personal tools